Code Readability is a Feature

If you are developing a product and working with a team of engineers writing code, you would have definitely faced the horror of reading someone else’s code. Many times it is your own code written a few months back.

My failed challenge

When I started out as a junior developer in my first company, I came up with a brilliant one-liner in python involving bitwise operators, instead of writing a 4 line if-else block. I was explaining about that line of code to everyone and was proud of myself.

My CTO said “If that code ever goes into SVN (yes it was a long time ago) you are dead”. I was disappointed and tried to argue with him. He wanted the code base to be clean and understandable and the way he drove home the point was through a challenge. He challenged me to show it to any programmer in office and if they can understand what it does without me explaining, he would allow it.

As predicted, I failed the challenge and had to rewrite it.

Readability, not performance is a feature

Jeff Atwood during his StackOverflow days had explained in a podcast episode why he wanted StackOverflow to be as fast as possible – he considers Speed as a Feature. He explains in a blog post on how to optimize the site for performance.

I would say more than performance, Code Readability is an important feature in your codebase/product. You can write in some obscure language with all sorts of compiler optimizations and assembly code embedded in to get that extra 3 milliseconds off your API call. But is it worth it?

Programs are written for people first

Code and Programs are written for people to understand first. The computer able to execute it is a nice side effect to have. Remember that you are just trying to solve people’s problems. They don’t care if you solve it using a web app or a hardware device or using pen and paper.

Writing a program to solve problems is easy as it costs nothing to build a prototype. But many times, the prototypes eventually get used as the product. Initially, the customer wouldn’t care how bad the code is or how slow it runs as long as it solves his problem. When the time comes to build the V1 of the product, always prioritize readability before performance.

If you try to optimize a messy code, you are going to have a very fast mess. No one except you would like to touch that code even with a 10 foot pole. They will be afraid that they are going to break it.

As the team grows it is going to be even more hard to scale it and you will eventually rewrite the entire product. Instead, if you start off with a well-written, modular piece of code, you now have the ability to profile and improve the performance of each individual modules.

You will make the lives of each developer on your team better. They will be willing to work with you and improve your code base instead of dreading to touch it.

Code Reviews to the Rescue

Regular code reviews are very important in ensuring everyone writes clean and good code. Any small change I make, I get another pair of eyes to look at it and see if they understand it and that I am not making any obvious mistakes.

If it is a big module that I built completely, I call the entire team and explain why and how I have developed it. If the junior-most person in your team isn’t able to understand your code, scrape it and rewrite it.

Remember, the best measure of good code isn’t the least number of lines of code, but the most number of developers understanding your code.