Developer Productivity - I
February 10, 2021
Tags: productivity | tooling

I used to be very passionate about developer productivity for years. I guess I still am. But my outlook and methods have changed a lot. I want to write all this down before I forget it. Yes, my memory is short.

Ten years ago

I had just joined a medium-sized company from a tiny startup and I immediately began noticing how much my productivity had come down. And I found fault with the tools and the version control system being used. Most of the blogs and stackoverflow posts I read confirmed my suspicions - ClearCase was the root of all suffering!

I wasn’t a cynic or a complainer - at least not back then. So I did what I could. I was a Vim user for more than five years - I learned Emacs and moved to that (I still am on emacs). I wrote scripts and automated my tedious tasks as and when needed. I tried to improve the build time of our codebase a few years later, when a very senior colleague was doing a pilot project around parallel builds.

Things start to change

After seven years in my company, I finally saw developer tooling changes. The first was a move to a new version control system (Perforce). I was surprised by how long it actually took. Then came some steps towards continuous integration. While all of this was going on I became a father and started juggling work and life for the first time. Two years passed by before I even knew it.

Getting deeper into productivity improvement

I started noticing that my productivity was not great, even with some improvements in the tools around me. I also started thinking what productivity really meant. Eight years ago I simply wanted to produce more code changes - that was my passion. I had no problem putting in much more time at work than most of my colleagues. I didn’t even realize I was doing that - because it never felt like that. The output I was producing mattered to me, and that was not a lot.

Now I started putting much more value in how much my efforts were rewarded by subsequent visible output. In short, the new formula was

my_productivity = what_I_accomplish / how_much_time_I_spent_at_it

I started realizing that the way to increase this ratio had much less to do with version control systems or scripts provided to me. There are many more factors, like

Most of these factors are in my control. I started to take charge of my productivity as a developer, as measured by this new formula.

More kinds of productivity

As I spent more and more time in the software industry, and in the same company, I started seeing things from a higher level. I realized that individual developer productivity may not help my team’s productivity, or that of my company. Because, changing source code doesn’t solve all the problems a product runs into. Well-crafted e-mails can accomplish much more at times. Such e-mails require the knowledge gathered from hundreds of hours of source code changes, and perhaps more. A coffee chat with some human beings explaining a bunch of changes before they are typed in is also very powerful at times.

The other way to be more productive is to be choosy in what you do. Doing the wrong thing with enormous speed won’t get you far. The right change at the right place can work wonders.

So what do I do?

Even after realizing so much, I still have the desire to produce more code changes. I found out that there is a good way to do this - have side projects. At work, at your home - wherever you are. No one needs to be bothered by what you are doing. You can create a new project every few days and throw it away whenever you want to. If all of your ideas are around your work assignments - try to organize a hackathon at work. Or simply create a new branch of your source code and see where you go with your modifications. Who knows, you might come up with a new product idea for your company!

Learning

Developer productivity is very important. But not more than developer sanity. The latter is probably going to be much more important for most of your life.

Made using Hugo (source)