The term 10x Developer is a myth. It is a belief that there are some people who are so good, they can solve software problems in 1/10th the time and do it ten times better.
Let’s analyze a couple of places this belief might have come from.
Steve Jobs?
In 1995, Steve Jobs said:
I observed something fairly early on at Apple, which I didn’t know how to explain then, but have thought a lot about it since. Most things in life have a dynamic range in which average to best is at most 2:1. For example if you go to New York City and get an average taxi cab driver versus the best taxi cab driver, you’ll probably get to your destination with the best taxi driver 30% faster. And an automobile; What’s the difference between the average car and the best? Maybe 20% ? The best CD player versus the average CD player? Maybe 20% ? So 2:1 is a big dynamic range for most things in life. Now, in software, and it used to be the case in hardware, the difference between the average software developer and the best is 50:1; Maybe even 100:1. Very few things in life are like this, but what I was lucky enough to spend my life doing, which is software, is like this. So I’ve built a lot of my success on finding these truly gifted people, and not settling for ‘B’ and ‘C’ players, but really going for the ‘A’ players. And I found something… I found that when you get enough ‘A’ players together; when you go through the incredible work to find these ‘A’ players, they really like working with each other. Because most have never had the chance to do that before. And they dont work with ‘B’ and ‘C’ players, so its self policing. They only want to hire ‘A’ players. So you build these pockets of ‘A’ players and it just propagates.
(Source: Cringely, R. X. (2012). Steve Jobs: The Lost Interview [Film]. United States; Magnolia Pictures.)
This quote appears in Steve Jobs: The Lost Interview; an 70-minute interview recorded in 1995 and released in 2012. This was after he had left Apple but before Apple bought NeXT.
Let’s break it down a little. He proposes:
- Software development is somehow different from “most things in life” — other professional fields?
- It is better to put the effort in to find the “A” players, rather than settling for B and C players.
- “A” players are also good at hiring other A players.
Thiiis may or may not be true. Hmm.
But there’s also an older source.
Coding War Games
Software engineers Tom DeMarco and Tim Lister, authors of the book Peopleware: Productive Projects in Teams (1987), conducted a productivity survey called the Coding War Games beginning in 1977. According to data from over 600 developers, they concluded:
- Choice of programming language had little impact on productivity, with the exception of assembly language.
- There wasn’t a correlation between performance and experience, except that developers with less than six months of experience in a language were not as productive.
- There were huge difference between organizations, with the best organization working 11.1 times faster than the worst. The study authors attributed this to the workplace environment—quiet, private, dedicated working space leads to better performance.
This might be where the ten in “10x” comes from, since the best organization was about ten times faster than the worst. However, this isn’t a measure of individuals, and the third bullet point here emphasizes likely causes for the difference in performance.
Other notes
Linus Torvalds and John Carmack exist, sure, but your boss can’t hire them to work on your random web project. You might spend your whole life and not do what Torvalds did, but nobody needs to invent Linux twice. If you set up Carmack to do something he doesn’t know or care about, he would not be productive either. Resist the urge to mythologize prominent programmers and compare everybody to them.
What you can actually do to be more productive?
- reduce distractions and allow flow to happen
- develop deep subject matter expertise in a relevant problem; or choose problems relevant to your area of expertise.
- know that it’s okay to be a “rocket turtle”; somebody who is slow at first (reading documentation, following tutorials, etc) but speeds up and leaves clean code behind.
- sometimes it’s okay to drop everything to focus on a tough problem
https://medium.com/ingeniouslysimple/the-origins-of-the-10x-developer-2e0177ecef60
https://www.simplethread.com/the-10x-programmer-myth/ - offers a manager’s perspectives on developer archetypes that might get extra praise or too little praise.