The 10x Programmer Myth - Simple Thread

October’s donation was made to the International Rescue Committee for Afghan Refugees.

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.