During a recent job interview I was asked “Do you think you are a 10x developer”. The concept of a “10x” developer and developer productivity is something I have thought a lot about. Fundamentally the hard part is figuring out what to measure. I don’t have any good answers but here is how I think about it today.
Since programming is a fairly creative activity it will always be difficult to find a measure that cannot be gamed.
A simple but flawed measure is something like “lines of code” or “features completed” or “bugs fixed”. These measurements are flawed because they are only loosely linked to the things users of the code actually care about. In University I met someone that allegedly completed a 5 hour coding interview in 1.5 hours with code that passed all the unit tests. If true this is impressive and a testament to that particular developers skills. I doubt I would ever be able to match such a feat.
Just as a person has many personality facets, a developer can work on different facets of productivity. I like the word facets because each is unique while still contributing to the whole.
An important skill is the ability to produce “error-free” code. I think computer programming is unique in that a single bug can cost millions of dollars to fix. Even perfectly correct code can require rewriting when the requirements or execution environment changes. Examples of insanely expensive bugs include OpenSSL HeartBleed, Intel Meltdown and more. These bugs cause the users damage and also generate rework for the entire industry.
Programming is a continuous tradeoff between getting the code working for a specific use-case and making it robust enough to handle multiple use-cases. Figuring how much it will cost to develop a feature is hard enough and the risk of expensive bug is rarely factored in. There isn’t an easy way to measure the cost of expensive bugs. The cost to fix bugs is also hard to measure and not accounted as an engineering cost.
Developing the skill of writing code that doesn’t result in expensive bugs often requires:
In the wrong environment an inexperienced developer can introduce programming errors that will cost more than their contributions. Everyone likes to talk about “10x” programmers, but I think we should also talk about “negative productivity” programmers and what can be done to reduce the cost of these errors by catching and preventing them earlier.
Debugging is a specific developer skill. It is difficult to teach and hard to explain the instincts of a good debugger to an inexperienced developer. Being able to make an intermittent bug easily reproducible or use gdb to track down some memory corruption are critical skills at the right time. I also saw a talk by a Google engineer that was investigating a 99th percentile latency outlier and found a Linux kernel scheduler bug that saved Google millions of dollars a year. As systems become more complex, the bugs also become harder to fix. I wish there were better ways to capture and train debugging expertise.
One of the amazing properties of software is leverage where a single tool can make a large group of developers more productive. The goal of every manager should also be to make their team more productive. The goal of almost every software product is to make their customers more productive. Being able to find and address productivity bottlenecks in a team is another developer skill. Developing this skill often requires:
This assumes that the team works well together. A toxic team member can reduce the productivity of an entire team. Language, timezone and cultural differences can also hinder productivity.
Even the most perfect code is useless if it doesn’t solve the right problems. Keeping development aligned with business needs can contribute to team productivity by eliminating rework. Some of the skills required to do this well are:
It is impossible to be excellent in all these skills. The most important is to constantly find ways to improve individual and team productivity. I suspect this isn’t the answer that an interviewer is expecting. I need to come up with a shorter answer.