10x Programmers: The True Way to Increase Software Engineering Productivity

The Mythical 10x Programmer. A Creature as Elusive as Bigfoot.

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.

What is a 10x Programmer?

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,

• lines of bug-free code,
• number of production-ready features released,
• lines of readable and maintainable code,
• amount of work completed in the last sprint or epic as shown in a burndown chart, to give just a few examples.

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 industries 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.”.

What Does This Say About a 10x Programmer?

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.

How To Achieve 10x Software Engineering Productivity

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.

1. Pre-built components help increase productivity in complex engineering processes.

   
   

   The video certainly calls to mind the motto we just mentioned from Titus Winters’ book on Software Engineering at Google: “If you’re writing it from scratch, you’re doing it wrong!”

   
   

   By compiling and assembling pre-built elements that others have created, the construction crew was able to a 30-story building in just 15 days. This calls to mind frameworks, libraries or packages in software development.

   
   

2. Software development frameworks or libraries, such as Ruby on Rails, Laravel or React, increase software developers’ productivity by providing pre-built, open-source standards for application development. By providing a structure and starting point for creating, deploying and maintaining your application, frameworks allow developers to focus on creating applications quickly.

   
   

3. These frameworks and libraries are essentially higher levels of abstractions compared to traditional development. By providing anything ranging from authentication to prebuilt UI components and everything in between, frameworks are predefined, best-practice solutions to common software development challenges.

   
   

4. Not everybody in your software engineering team needs to be a 10x programmer to achieve 10x outcomes.

   
   

   Better tools and processes can create outcomes that even a team of highly-talented 10x programmers would struggle to achieve. For example, the team members of the construction crew are more likely not all 10x construction engineers. Nor will every software team only consist of highly talented team members.

   
   

   Every development team consists of a mix of more or less junior and senior developers. To unlock a software engineering team’s productivity, making sure that the team follows a clear set of instructions, and communicates well is probably more important than having a team of superstar 10x programmers. Agile and quick iteration, as opposed to the traditional waterfall project management methodology, can go a long way toward making sure teams perform well and rectify errors quickly.

   
   

5. The trade-off in writing code and producing software is between the speed of development and customizability.

   
   

   Expect to sacrifice some customization in return for faster speed of development. But also expect that this trade-off will be less and less pronounced in the future.

   
   

   For example, low-code tools such as Five currently excel in the rapid development of custom applications that would usually require a lot of boilerplate code.

   
   

   To give some examples, internal tools, departmental apps, or operations software, all usually share a similar set of requirements and features, such as forms, permissions, charts, workflows, or notifications.

   
   

   In Five, these commonly used application features can all be created quickly and without writing (or with significantly less) code than in traditional development. Low-code attempts to take the pain out of development by easing common tasks used in most web projects, without taking the joy out of development.

10x Programmers: Conclusion

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 skills 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.