Freek.dev

Bill Jordan wrote an absolutely amazing piece on the things he learned in the twenty-eight years he worked in the software industry. There are so many good insights that I can nearly quote the entire article.

Here are some of the things that resonated with me:

Odds are far better than good that your high performers are achieving what appears to be high levels of productivity by building technical debt into the application by taking shortcuts whether intentionally or unintentionally. These kinds of high performers are actually low performers when when TCO is factored in.

Encourage developers to improve the application while working on their projects. Examples of improvements are creating reusable objects out of copypasta code and breaking up large objects that are difficult to maintain into smaller objects that individually are easier to reason about. Improve the database schema even if it hurts in the short term. Delete old and unused code. With the benefit of hindsight update the user interface to improve user experience — sometimes even just changing a word or two makes a big difference.

When continual improvement is part of the DNA of your team you’ll be amazed with the results, but give those results some time to become apparent — it won’t happen overnight. It also means management will need to recognize that things will take more time since developers will be working on their primary project while simultaneously making incremental improvements.

Be sure to read the entire post: https://medium.com/@billjordan1/the-quiet-crisis-unfolding-in-software-development-cffbdafbf450#.1j7a7qos3

Read more

Sandi Metz solved the Roman numerals kata in a very interesting way. Along the way she makes the case for keeping code simple.

The desire for simplicity means that I abhor special cases. I am willing to trade CPU cycles to achieve sameness. I'll happily perform unnecessary operations on objects that are already perfectly okay if that lets me treat them interchangeably. Code is read many more times that it is written, and computers are fast. This trade is a bargain that I'll take every time.

http://www.sandimetz.com/blog/2016/6/9/make-everything-the-same

Amen to that. I did not know that additive Roman numerals are perfectly valid.

If you want to read more posts by Sandi, be sure to subscribe to her newsletter.

Read more

Some great coding tips written down by Joeri Timmermans on the Intracto blog.

As a developer it's your duty to take good care of your code. It's not enough for your code to work, you also have to make sure it's well written and readable. If we spend 10 times more time reading code versus actually writing it, this means the readability of your code is directly related to your output and the output of your co-workers. So providing cheaper reads will not only create happier co-workers, but also increase the productivity of your whole team.

http://blog.intracto.com/how-to-save-a-kitten-by-writing-clean-code

Read more

Jeremy Kendall dissects bad PHP code on his site csiphp.com.

It all began with a new gig and an amazingly horrific codebase. I began tweeting the most unbelievable, most frustrating snippets I could find. After quite a few of those tweets, Chris Hartjes replied with, “Looking at your tweets I cannot even fathom what your job is. CSI:PHP?” A concept was born.

Twitter’s 140 characters are rarely enough to share the horrors of bad code, and I don’t want to give short shrift to the nefarious and misguided scripts that I’ve found. Behold the CSI: PHP blog, where I investigate criminally bad codebases and share the evidence with you, my fellow developers.

http://csiphp.com/

Read more

In a post on his blog Michael Stivala looks back on his own code written a year ago. Because he learned a lot of stuff in a year time, he seems a lot of room for improvement.

As I’m picking up the codebase ahead of this Summer’s updates, I can’t help but review and refactor the existing code. It’s interesting to dissect previous design decisions. Also, I’ve learnt so much in the last year that it’s only natural for me to want to bring the standard of an older project up a bit.

https://michaelstivala.com/things-i-used-to-do-that-arent-cool-now/ If you look at your own code from a year (or longer ago) and think "this is allright, I can't improve on this", chances are you're not learning enough.

Read more

When starting out programming many developers are quite happy when their code just works. More seasoned programmers know that making working code is just a first step. Not improving your initial code will lead to professional suicide (not my phrasing, I'm sure I've read this in a book at some point).

In an article on his blog, Colin DeCarlo demonstrates how an initial solution can be vastly improved in just a few iterations.

From time to time a friend and I play a programming game that I consider to be a version of Code Golf. Typically, the goal of Code Golf is to solve some challenge using as little bytes as possible. In the version of the game we play however, the limitation is the use of certain language features. Specifically, we try to use as little variables, conditionals and explicit loops as possible.

...

My method to accomplishing these challenges is to first write the algorithm in the simplest, most straight forward manner and then chip away at that solution until I’ve satisfied the challenge conditions.

The focus in the article is on removing conditionals, and limiting the use of variables. Keep in mind that, in most cases, this shouldn't be your main goal. Maximizing the readabilty is what your should pursue. Don't try to be too clever or terse. In some cases limiting conditionals and variables goes hand in hand with improving readability, in other cases not. It all depends on context.

Read more

A few days ago Toon Verwerft gave an uncon talk at PHP Benelux Conference about a new code quality checking tool he has been developing. It's called GrumPHP. It can automatically perform various code quality checks when you try to commit some code.

Sick and tired of defending code quality over and over again? GrumPHP will do it for you! This composer plugin will register some git hooks in your package repository. When somebody commits changes, GrumPHP will run some tests on the committed code. If the tests fail, you won't be able to commit your changes. This handy tool will not only improve your codebase, it will also teach your co-workers to write better code following the best practices you've determined as a team.

https://github.com/phpro/grumphp

The slides of Toon's talk can be found on speakerdeck.

Read more

Matthias Noback published the second article in his programming guidelines series. This time he explains why using null in a function isn't a good idea. In my opinion it's great advice that most devs can immediately apply in their projects.

It's certainly a good idea to get rid of the uncertainty and vagueness that null brings to your code. Besides, most of the time when you encounter an actual null value in your program, you probably weren't expecting it. You just call a method on it, thinking that it is an object and PHP will rightfully let your program crash.

...

Every particular null situation requires a different solution, but at least I'll list several common solutions for you.

https://www.ibuildings.nl/blog/2016/01/programming-guidelines-php-developers-part-2-getting-rid-null

Read more

Matthias Noback, author of "Principles of Package Design", published the first article in a new series on programming best practices on the iBuildings blog. The subject of the first article is reducing complexity.

Inside your method or function bodies, reduce complexity as much as possible. A lower complexity leads to a lower mental burden for anyone who reads the code. Therefore, it will also reduce the number of misunderstandings about how the code works, how it can be modified, or how it should be fixed.

https://www.ibuildings.nl/blog/2016/01/programming-guidelines-php-developers-part-1-reducing-complexity

Read more

Correctly naming things is the most difficult programming task (except for documenting). However, this is only because we often afford these tasks insufficient consideration. As with most things, the more we do it the easier it becomes. In this article we will discover how to choose correct names for our methods.

http://codelegance.com/semantic-method-naming/

Read more