TLDR: 10x programmers might exist, but not in the way most people think. There are a few behaviors of engineers, when mixed with a little creative storytelling, that has led us to create the myth of the 10x programmer.
I wrote a post last week called 20 Things I’ve Learned in my 20 Years as a Software Engineer. The post struck a chord with a lot of people, but as with anything on the internet a disproportionate amount of time was spent discussing seven words out of the entire piece. Those seven words were:
“The 10x programmer is a silly myth.”
Within the context of the post, the point of that item was that we should be far more worried about avoiding unproductive developers, or net negative developers, than we should be about hunting down the mythical 10x developer.
A lot of people took issue with that statement though, because as many people would point out, they knew a 10x programmer! They once worked with this person who was a genius, and they just cranked out reams of code. Amazing code! Perfect code! No matter what the task, they knew the solution before you even started describing the problem! Plus, they only slept two hours per night!
I’m obviously exaggerating, but I think you get my point. Most of us have worked with developers who are really productive. They solve problems quickly, they are able to focus, they can crank out really good code. But could these people be 10x more productive than another solid developer? Let’s just say I have my doubts.
But can 10x programmers exist out there somewhere? Let’s explore that a bit…
What is a 10x programmer?
Let’s first try to define what we mean by a 10x programmer. What most people mean is that there are developers who are 10x more productive than most other competent developers. I don’t mean 10x more productive than the worst developer you can think of, 10x more productive than other good software engineers. A single developer, when given most tasks, can accomplish in one day what it would take another good developer 10 days.
To me this is a really interesting distinction. I’ve worked with really bad team members in the past. I’ve worked with what folks would call “net negative” developers, which is developers who are so bad that people actively avoid giving them tasks or just give them busy work, because all of their code needs to be rewritten or thrown out. Compared to someone like this, everyone is a 10x programmer!
But the idea of the 10x programmer is that there are superhuman programmers out there who, if we could just find them, would catapult us to productivity Nirvana. And honestly, I think that just isn’t reality.
The 10,000x Software Engineer
Many people point to engineers like John Carmack and Linus Torvalds as examples of 10x software engineers. Most of us couldn’t do what John Carmack did even given a lifetime of effort. In that sense, these folks aren’t just 10x programmers, they are 10,000x programmers. People who are incredibly intelligent, have incredibly deep subject matter expertise, ridiculous work ethics, and most importantly, can see things in a way that nobody else can.
But here’s the thing, you don’t just go out and hire these folks. And even if you could, they aren’t going to work on your software. They work in a very focused area, and won’t have any interest in working on your software unless your interests perfectly align. If John Carmack was dropped into the average web development project, he wouldn’t be very happy or effective, and all of his knowledge around shadow volumes and binary space partitioning would be more of a hindrance than an asset.
These aren’t the folks the 10x software engineer myth was built around.
The 10x software engineer myth has become so pervasive because there are developers that often feel like they are heads and shoulders above their peers. These developers, good and bad, when mixed with a bit of lore, gave rise to the myth of the magical 10x software engineer.
Warning: Caricatures ahead. All of these are just exaggerated archetypes of engineers put together as a fun exercise. They aren’t people. People don’t fit cleanly into buckets, and people change given their environment, their day, their mood, and their incentives. Use this as a tool for understanding and empathy, not as a tool to label people.
The types of engineers that lead companies to think they have a 10x software engineer
These are some examples of the types of behaviors or archetypes that lead certain people to believe that they have a 10x engineer in their midst. From the outside these behaviors appear to be highly productive, but only because the true costs of their behaviors aren’t always apparent. And believe me, these aren’t permanent, I’ve fallen into a few of these buckets many times over my career.
The Code Fountain – A never ending stream of code
There are a lot of developers that are able to churn out reams of code. In some environments, like startups, this might be desirable. But quite often this code is rushed, and of poor quality and leads to teammates having to come back and fix it later. So while this developer might seem incredibly productive, really all they are doing is leaning on the rest of the team to make themselves look productive.
The Point Hog – Always picks the easy tasks
You know the type of developer, the one who always grabs the low point tasks off the Scrum board. At the end of every sprint they have so many cards done! “How can you possibly get so much done? You’re amazing!” says the manager. These folks don’t fool other engineers, but many non-engineer folks can be dazzled by their “productivity.”
The Overcomplicator – Turns everything into a Rube Goldberg machine
There is no problem so simple that this engineer can’t turn it into a quagmire. They get a simple technical exercise asking them to sort an array and they deliver a React UI with a backend API that sorts the array and stores the results in a database. Score number one for complexity! But in all seriousness you might be asking yourself how anyone could see these folks as 10x engineers? Well, they wouldn’t, except a lot of these folks loooooove to make a lot of noise about how big and complex the problems they are tackling are. Folks hear this and are blown away with this person’s productivity solving so many challenging problems!
The 80 Percenter – Get tasks done… almost
We’ve all been there, you’re cranking through an application making tons of progress, you run up against some annoying crap slowing you down and you switch to something else and keep pushing forward. This feels really good for a while, and in small doses can be a good way to break past a productivity block, but if you keep this up for too long you’ll create a huge mess. Folks who make a career of working like this will appear really productive to non-engineers, but other folks on their team will quickly become sick of cleaning up after them.
The types of engineers that make up the mythical 10x software engineer
These are a few archetypes I’ve noticed that some software engineers fit into that make them certainly more productive than most software engineers. If you have any of these folks on your team, you should count yourself lucky and do everything you can to keep them around.
The Focuser – Focuses and reduces distractions
The average office worker checks email once every 6 minutes. Software engineers are no exception. If you can reduce distractions, focus, and get into flow, then you’ll automatically be more effective than most software engineers. The focuser just naturally has this inclination, and can sometimes annoy coworkers since we’ve become so accustomed to people always being available. If you trend in this direction, don’t allow yourself to be distracted, work with your team to figure out a flow that works for you, and block off chunks of your day for focused and uninterrupted work.
The Professor – Has deep subject matter expertise
The vast majority of software engineers are generalists. And don’t get me wrong, nothing at all wrong with being a generalist. Generalists are amazing because they can fit into almost any environment and provide a solid contribution. But Professors are myopically focused on a particular problem. They are those members of the team that only want to work in one small area, and within that area, they seem to know everything and can solve every problem as if it were nothing.
The Rocket Turtle – Slows down to speed up
You might have worked with one of these folks. A person who seems to get off to a really slow start, but then suddenly… boom! Everything comes together. They don’t get a task and then just dive straight into writing code. Even if the solution seems obvious, even if they’ve solved something similar before, they still poke and prod the problem to see if there is a better way to solve it. If they have to pick up a new tool, they don’t just ham-fist their way into it, they seek out tutorials, best practices, and experts to make sure they are wielding the tool properly. Once they reach a solution, you can be sure that people aren’t going to have to come behind them and clean things up.
The Obsessor – Can’t stop, won’t stop
Most developers like to solve problems. But some developers are downright offended by a tough problem that won’t quit. Tough problems cause these people to dig-in and go on a war-footing. Sometimes they might disappear and work on a problem for many hours on end, not realizing how much time has passed. Some might get the problem stuck in their head for days or weeks, thinking about it almost every waking moment. Until it is solved, these engineers just won’t let go.
The Interrogator – Questions everything
The Interrogator probably annoys people, but they are obsessed with not solving problems that don’t need to be solved. They ask why again and again, making people spell out very quickly why something needs to be built, or why it needs to be built in a particular way. By avoiding a lot of extra software and overly complex processes, these developers can save their teams countless hours. Sadly they rarely get credit for their efforts.
The Subcontractor – Prefers to farm it all out
Some developers absolutely love to reinvent the wheel. Other developers are just annoyed by problems that already have good solutions. They will go out of their way to find a library, an API, or a tool that will solve a problem for them. If they can’t, they will redesign the problem in a way that allows them to fit it into an existing mold. While this isn’t always a good thing, far more often than not this can save teams tons of time and energy.
The Simplifier – Always finds an easier way
This person always seems to find an easier way to solve a problem. The kind of software engineer where you think you have a gnarly problem, then you go and look at their pull request and go “Is this all?” Followed by “Oh, interesting. Wow, yeah, that makes sense.” They just seem to effortlessly dissect problems, discard the distracting elements, and reframe it in a way that makes it far more tractable.
All of these engineer archetypes can have positive effects on a team, but when taken to the extreme or put in the wrong environment, can quickly turn negative. That is why it is so important that we understand that these are just archetypes, not people, and every individual will have different needs in order to perform their best.
A reframing of the 10x programmer
As I said in my previous post, instead of looking for “10x programmers” it is far more important that we try to avoid the programmers who will drag the rest of the team down. But as we seek to improve the productivity of our teams, by understanding where the myth of the 10x programmer came from, we can leverage that knowledge to create environments and foster practices that enable our teams to do their best work.
Loved the article? Hated it? Didn’t even read it?
We’d love to hear from you.
This is the second post of yours that I have read. Good read again. Looking forward to the next one!
Thank you!
Thank you very much for this. Much appreciated 🙏🏾🙏🏾🙏🏾.
I think you are right insofar as there isn’t a statistically relevant subclass of engineers that magically crank out 10x code… but the “myth” does have roots in a particular type of engineer that can crank out more in a solitary environment born of a reality I think you didn’t touch too much on: they work alone because no one wants to work with them.
I thought this was a myth too, until a friend of mine, serving as CTO, contracted me to look over a “10xers” code to make sure it was legit. He mentioned the guy was a complete a$^#^%e, condescending, and just horrid to even meet with. But, as I learned, he was able to crank out the framework for a 3D application with a store and backend remarkably fast.
So the moral was, even if you can find this mythical 10x developer, don’t hire them. Just 1099 them to do a piece in solitude, because they will destroy team culture and morale if integrated into the team.
Great article again!
I’ll add to that, a Lone Ranger Code Fountain. After that person leaves, the next coder must be a
Code Archaeologist to figure what the previous civilization left behind.
Ha, love it!
Stop posting your opinionated propaganda. Bottom line is everyone is different and some people are 10x or 100x as productive as others. You obviously are just brooding over not being one of them. Maybe if you coded more and blogged less.
One perk of having worked as a software tester is that I learned to examine definitions, concepts and baked-in assumptions with a critical eye. Often times definitions are sloppy and incomplete, leading to diverging opinions just because no one can agree on what the hell is in even under debate. And, just as often, the solution is to go back to the source of said definition, and ask “why” — why did the author phrase things that way?
Well, debating on “10x programmers/engineers” seems to follow the same kind of pattern. There is a vague concept/definition, we try to pin it down, but since there is no one authoritative voice, a consensus is never reached, and people keep on merrily “debating” by rehashing similar points for years. So I got curious: who even coined the notion?
I googled the term. It seems that the notion of 10x programmers appeared in .. 1968, in an article in Communications of the ACM. That’s a huge red flag, debating on a vague concept that appeared more than 50 years ago. I believe the landscape in the software development profession has changed in a LOT of ways since then — in most aspects, including available tools, expectations from teams of programmers, and how programmers are supposed to manage their work.
So.. long story short, I propose a more radical thing: let’s retire the notion of “10x/ninja programmers” completely. It is not even useless, it is detrimental; by existing, it soaks up valuable time that we spend debating on the topic.
Instead, I would propose a new term, borrowing a concept from online team games: “carry programmer”. A carry is the kind of team player that ends up supporting others around him. A carry is the kind of team member that is strong, can tackle the challenges of the end-game, and still protect the lower-powered team members around him. It translates beautifully to the landscape of today:
– A carry does have deep knowledge, both in the programming language he uses, AND in the domain they work in.
– Additionally, a carry writes legible, documented code that remains understandable months and years after.
– Additionally, a carry carves out some time to mentor team members, to share information, to explain how he’s doing things, but also is humble enough to learn from coworkers. No one way of doing things is perfect.
– Additionally, a carry has the balls to stand up to management and give them a thrashing if there’s a push to write code faster by incurring technical debt, or any time there is a push to do things faster as opposed to right.
Just my 2 cents. Sorry it ended up being a wall o’ text.
I agree with the idea that debating this term is mostly fruitless, and yet I find myself doing exactly that! I love the idea of the “carry” programmer, it sounds like the kind of person everyone needs on their team.
You say there’s a 10000x programmer, but not a 10x. So much for the intermediate value theorem. Is it inconceivable that a person embodies all of the positive traits and archetypes that you mentioned?
The reason that one should not pursue hiring such people is that they are unicorns, and one’s efforts are better spent elsewhere.
At some point, this just becomes a matter of semantics. Half of all programmers are, by definition, below average, and the average isn’t that spectacular because there’s way too many 0.1x programmers out there in the workforce. Naturally, the best programmers are going to be much, much better than that half of the population of programmers.
So what do you measure your 10x against? Drop the 0.1x programmers and measure against the average of the remaining, “competent” programmers? That would certainly raise the bar for 10x qualification, but wouldn’t reflect the reality of the workplace.
I think the idea of the “10x” programmer originated with the observation that 10% of the programming staff seem to get 90% of the work done. Maybe this 10/90 ratio isn’t completely accurate, but I’d bet that a lot of people have noticed something similar.
Well… I was researching why the user facing software is not that complex when the business use cases almost always are complex. I ended up reading your take on that in another post.
Havent heard about 10x programmer but then again I have not been able to have luck to have the ivy league degrees required to be in presence of some great programmers. I may have some bad quality of an Overcomplicator but with some Rock Turtle(Research a lot, like now), Obesessor(Been at pretty tough problems for some years now) and Simplifier(this is bare necessity for all good programmers) mixed in. But I believe I would be “The Seer” type if I were to ever be amongst these 10x dudes, on a high level, someone who constructs software such that when it comes together in the end will have satisfy hand picked properties that would have been predicted beforehand but were cognitively hard to imagine/foresee beforehand because of the complexity involved.
I too feel the most terrifying programmers are the ones that woek in very niche area where they align every star and planet to maximize their productivity. And in today’s rapidly changing work environment where people come and go, this can become rare event to witness even within the company since all great things take time to accumulate. Even though a lot of open source projects seems to have a lot of bright people hacking at them and you have geniuses creating their own subdomains within already niche domains but these people are just far too specialized for me to know if I should feel 10,000x vibe from them.
The most intimidating people that I experienced as a programmer were not much of programmers at all but pure strategists that gave “The Professor” kind of vibe. One person I met 7 years ago had a knack for creating novel strategies for business, and you know its not a fluke when you see miracles being performed on a daily basis. Watching outcome of their actions transform the landscape is quite the show.
The other person that I found quite intimidating was a programmer but you may call that type “The Underachiever” since it does not want to express too much of its genius except when it absolutely must be expressed. This person I met had a “The Simplifier” vibe, seem to even guess the problems before they manifested and have solutions to almost all problems. The only limitation I felt was the lack of novelty, since the solution should be a combination of previously experienced events or the solution is not instant without going into the “The Subcontractor” mode.
There’s a little bit of every description you gave, at the heart of a good programmer. Being a good programmer, means constantly learning, and part of that process, is finding a balance between all those “personality’s”
I’d leave it at the fact that extremes, of any kind, is never a good thing … which includes ignoring things entirely on the basis of having experienced an extreme version of it.
I disagree with this article. In every area of science or arts, there are people who are very talented. Some people can learn languages WAY faster than most. Some people can learn and play music instruments WAY better than the average students. Some people solve complex math problems as if it was nothing. Probably everyone has seen one or the other talent at school. This is not so rare at all. You wouldn’t call it a myth. I am 100% sure that there are people who are similarly talented in software development. People who are just way faster in translating complex problems into clean code. People who can abstact better and faster, due to their mathematical skills. Of course there are. And such talent translates into the ability to solve coding tasks much faster than the average dev.
I have seen a few very talented people at school. I have seen a few during my studying, I have seen a few in job. This is not a myth. Say if you have a bigger company with 100 devs, there is a good chance to have a few of these talent in there already. Maybe it is not 10x. Surely not if you cut out all the 0.1x devs from your calculation (and there are a lot of them). Still I’d say, if you have one of these very talented devs on your team, and you manage to keep them motivated and support them, they can solve tasks 3x – 5x as fast as a normal good dev, with high code quality, easily doubling the output of you average agile team.
What I agree is that it does not make sense to actively search for these. You won’t find out in a job interview. Even if you hire them, it will take time for them to get onboard, get to know the team, the projects, the technologies used. All you can do is create a great work environment for all your devs, using agile methods, keeping everyone’s motivation high. This will allow everyone in the team to unlock their potential.
Well said. I’ll add that it is all about mastering complexity. If you have the right skills and are capable of structuring highly complex tasks cleanly, then you can also distill excellent well written code much, much faster. You focus on what truly matters and cast away a ton of chaff.
To give you an example, I am researching how AI truly works, how space, time and reality emerge and how chaotic systems order themselves (the innate intelligence these exhibit). It’s so far different from the approach Google, Apple, MS follow, that even if these big corporations would hire 1,000 people to work on my approach, they wouldn’t be able to compete with me, because it is all about understanding the highly complex interdependent systems. It requires recognition, deduction, intuition and other skills that are very hard to mirror as a team with members that only have subsets of these skills.
There is also the issue that true innovators have their own vision. While they could work on a specific project with set goals, they are infinitely better if they can work on something that is a perfect match for their skills. As a project manager it is a challenge to structure a project in a way to elicit this trait.
So I’d say whether there are projects where 10x programmers could excel, depends to a large degree on how you structure a project, how big a share of the work could actually be completed basically by labour vs smart structuring and finding elegant highly efficient solutions.
Great article, thanks for writing.
However, I disagree that 10x programmers don’t exist. You did point out John Carmack and Linus Torvalds. Oh, they are out there doing miraculous things.
The big question is, do you really need one on your team and how many of them to meet your goals? I would say in the average web project, you don’t really need one and you can succeed with just solid average dependable people.
Now, if I’m writing code for NASA and we need to save the world from an incoming asteroid, I would get all the 10x programmers I could get. (Or maybe not, the Avengers, after all, did suffer from a lot of infighting and disagreements…)
Hey! Just wanted to say I really appreciate you for writing this post. I’m probably around your age (40), but only 5 years XP in dev with the rest in QA (10 years) and electrical engineering.
I’ve worked in some crappy companies to get my foot in the door, and I was a “junior” dev to them I guess. I felt like the 10x dev myth was in place to justify the fact that they used me to beat up on to feel better about themselves. I’m confident enough with myself to say if someone is genuinely smarter or better than me at this, and I can say, yes there were a few. However, I can tell you that none of them were 10x better than me, and I WAS offended by other people being labeled that and put on a pedestal while I was treated like the red-haired stepchild.
I wish people would let this go and accept that we’re all human, and stop trying to use arbitrary labels to justify our actions.
You have entirely dissolved this quagmire through a decomposition of vague terminology
10x blog post
Didn’t the notion of a 10x Developer originate from studies discussed in the book Peopleware where they found that some developers were 10x productive in general?
My interpretation from reading the book was that those developers worked for companies that didn’t cut their productivity by a factor of 10.
One small nit: you say that there are “net negative” developers and that “everyone” is a 10x developer compared to such people. Actually, one would hope not! Let’s say a “net negative” developer causes the team to lose one day of productivity for every day they work. Compared to such a person, a 10x developer would be someone who causes the team to lose ten days of productivity for every day they work. You certainly wouldn’t want to be that person–and I certainly would hope most developers are NOT like that!
Ha! Touché!
The three point most are missing are,
1, A view caused by failed managment.
2, A method used to abuse people.
3, It’s from a long not short environment.
It comes from a time when (3) was the norm, not as it is these days the exception.
Importantly the mess created is not at the moment one creating “mangled human remains” as very little software is given control.
As we know the self drive code from 10x and above programers in EV’s is racking up more kills than an FPS game. The problem, the blood guts and dismemberment is “for real” and their loved ones are not happy.
We are on the cusp of Internet of Things getting physical control and be driven by AI systems that can not be explained. Hopefully people will wakeup before the average age of death drops to far.