Programming

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.

Yesterday I wrote about how to use a very simple timing context manager to measure how much time your python code/functions take. There might be times when you want to restrict how long your code executes. Python’s resource module in the standard library gives you an easy way to do that and more.

I use zsh as my primary shell and have Oh My Zsh which has lot of helpful plugins, themes and functions which make using the terminal easy. One neat command/alias I found out was when I typed d by mistake.

Disclaimer: Persons/organisations mentioned in this story are based on real-life. Any resemblance to persons/organizations living/dead is intentional.

Imagine you run a startup called Super Duper Software Inc and you have a decent dev team. You now need to hire programmers and you see two fresh off the college programmers applying.

First programmer (fake named Aakash) who knows nothing more than a “hello world” program that he wrote in C in the second year of his college. He can’t even write or understand basic for loops or if statements. Any algorithm or data structure he learnt is forgotten the instant he steps out of the exam hall. Unfortunately because of an inefficient interview process you hire him.

The second programmer (fake named Ashok) is also fresh out of college, but is slightly above average programmer for his age, can think logically and who has already worked on other personal/open source projects or has interned with other startups and has done his final year project on his own instead of buying it off the shelf. You hire him too.

You pay both the same salary, say Rs. 25,000 per month. They are under probation for 3 months and would get a raise based on their performance after probation.

Probation Period

Let’s assume they both go through some basic training and they start working on projects. You assign a mentor (fake named: Suresh) to both who has slightly more experience.

Its not tough to guess that Ashok requires very little hand-holding and is productive from Day 1. He churns out code which works, even if inefficient at first and is eager to correct & improve it.

But Aakash is a tough nut to crack and for every problem Suresh has to sit with him and explain how to use basic data structures like arrays or maps and how to iterate through the input data and how to store it so that he can get the output he wants.

Even then he isn’t able to apply whatever he has learned during the training to solve a generic problem. He takes a few hours to solve a very simple problem (say print the Fibonacci series till N) and if the problem is slightly changed to return the sum of all Fibonacci series till N, he is flummoxed. And he takes an equal amount of time to write a program for that.

And don’t even get me started on code reusability, debugability or proper formatting. In other words, he has no clue on what he is doing.

On an average, whatever Ashok finishes in say 15 minutes, he finishes in 8 hours (also wasting 2 hours of Suresh’ time). Assuming they both work for 8 hours daily (without counting any break), it is easy to see that Ashok is 32 times more productive than Aakash. Or in other words, the Return on Investment on Ashok is 3200% more compared to Aakash.

Note here that I didn’t even factor in the salary you spend for Suresh’s time wasted, which he could instead work on some other productive task.

Performance Review

Now when it comes to the performance review after probation, it isn’t too difficult to decide who gets the higher raise. Lets say you decide that Aakash gets a raise of Rs.5000 (making his salary to Rs.30,000) then would you give Ashok 32× more than Aakash’s raise? Rs.5000×32 = Rs.1,60,000 (making his salary Rs. 1,85,000)?

Wow Ashok! Congratulations on living in the ideal world!

But in real life, Ashok would also get about the same amount of raise (don’t be surprised if its even lower). Now what would Ashok do? If he was really as intelligent as I described him, he would quit on the spot and go find a better job.

If this process is repeated for all hires, “Super Duper Software Inc” become this barren waste land of below average employees.

Solution 1

Now what could be done to prevent this? Yes, the answer is easy.

Give Ashok a much better raise.

Not 32×, but at least twice as much as you give Aakash. Bonus points if you could find creative ways to encourage him – like review every 6 months, stock options, bean bags, video games, better computers, etc.

What happens to Suresh? He would be super bored because all he sees are people who are sucking his time & brain and soon he would just quit and maybe start his own startup (learning from all your mistakes).

Solution 2

So the ideal solution is to not hire Aakash in the first place and instead use his budgeted salary to hire another Ashok.

Now this isn’t something new that I am saying here. Some one much intelligent than me has already said it years before. And for many startup founders he is almost a God.

A-players like to work with other A-players and don’t want to work with B and C players.

— Steve Jobs

TL;DR: Stop hiring B and C players and hire only A-players. If you can’t afford A-players today, at least don’t go for the C-players.

PS: Damn you interviewer Prakash. Just because you couldn’t say No, you just made Suresh’ life miserable.

Primary Sidebar

Search this website

I am Srinivasan Rangarajan, (AKA) cnu.

I love talking about Technology, Startups, Product Design, Marketing and related stuff. I have helped many startups build and scale their SaaS products to millions of users.