Developers love to debate whether 10x programmers really exist.
Search “10x programmer” on HackerNews, and you’ll find many heated online debates on the topic. Expect nuggets of wisdom such as “Being a “real” 10X programmer is like being a savant. It’s about being […] SMART.”
We’re not going to weigh in on the debate of the 10x programmer. At least not in relation to individual talent. Instead, we want to look at it from the perspective of modern development tools.
A 10x programmer is a software developer that outperforms the average programmer in terms of productivity by at least 10x.
There are a few difficulties in identifying 10x programmers, starting with the very fundamental problem that it’s difficult to measure software engineering productivity.
Usually, it’s easy to compare two workers’ performance through output metrics: Worker 1 produces 2 widgets per hour. Worker 2 produces 20 widgets per hour. Worker 2 is 10x as productive as Worker 1.
But in software development, it’s much harder to measure output or productivity. It could be measured in many different ways. For example,
But as written elsewhere, lines of code or any purely output-related metrics are hardly an accurate, nor a recommended measure for software developers’ productivity. Especially lines of code is highly unreliable and can differ substantially across different programming languages, for example.
Plus, software development is a team sport: finding out whether code is bug-free or production-ready first requires testers to ascertain whether there are bugs or not. And whether or not code is considered readable is very much in the eye of the beholder (and again somewhat dependent on the programming language used).
Moreover, software development defies conventional logic in that the less a software engineer produces, the better.
In our example above, Worker 2 is clearly more productive. But in software development, the same cannot be said for two programmers.
If Programmer 1 writes 5 lines of code in an hour and Programmer 2 writes 50 lines of code per hour, is Programmer 2 ten times more productive than Programmer 1? Probably not. Maybe Programmer 2’s coding style is just more verbose.
Or maybe Programmer 1 was using a more readable and less wordy programming language such as Python, whereas Programmer 2 was writing code in JavaScript or C#.
The author of “Clean Code – A Handbook of Agile Software Craftmanship“, the author Robert C. Martin says about his experience writing code:
“The first rule of functions is that they should be small. The second rule of functions is that they should be smaller than that. This is not an assertion that I can justify. I can’t provide any references to research that shows that very small functions are better. What I can tell you is that for nearly four decades I have written functions of all different sizes. I’ve written several nasty 3,000-line abominations. I’ve written scads of functions in the 100 to 300 line range. And I’ve written functions that were 20 to 30 lines long. What this experience has taught me, through long trial and error, is that functions should be very small.”
Moreover, software development is also unusual in that the reuse of code is generally encouraged and comes at zero cost.
Open-source libraries, packages, or application development frameworks all provide solutions to common coding challenges. And these free helpers are usually developed and maintained by the brightest and smartest in the industry: React was originally developed and is maintained by Meta. Material UI, the design library, implements Google’s Material Design. In what other industry do industry leaders open-source their secret ingredients to make them available to the general public?
Lastly, with tools such as GitHub’s co-pilot, developers can produce code ever faster by writing just a few comments.
Reuse of code is so highly encouraged that in “Software Engineering at Google“, the author Titus Winters writes that “If you’re writing it from scratch, you’re doing it wrong.”
He goes on to say that at Google, custom code is considered a liability. A necessary liability as we cannot do without code, but a liability nevertheless: “Code is simply a maintenance task to someone somewhere down the line. Much like the fuel that an airplane carries, it has weight, though it is, of course, necessary for that airplane to fly.”.
A 10x programmer is a problem-solver using code as their primary tool. However, it’s hard to determine what exactly a 10x Programmer is, or what the term stands for in terms of measurable output or metrics. The way that software development works makes it hard to find any objective standard for a quantifiable measurement of the 10x programmer.
So instead of obsessing over 10x programmers, let’s think about software engineering productivity as a whole and how it has evolved over time.
Let’s look at an impressive engineering project – this time in civil engineering – to draw some comparisons with software engineering.
Remember the story of the 30-story hotel built in China in just 15 days? If not, we recommend watching the video first before continuing to read.
Here are three lessons we can learn from the video regarding software engineering.
What is the overall conclusion regarding 10x programmers?
Process improvements, be it through better dev tools and approaches, such as low-code solutions, management techniques, or even organization culture, can trump individual skill and help increase software engineering productivity.
As mentioned above, a 10x programmer can be defined as a problem-solver. In software development, solving problems oftentimes comes down to choosing the right tool for the problem at hand. Last but not least, on a team level, software engineering is best managed as an engineering process. And outcomes are driven by making this process as efficient as possible.