The 10x Developer: A Myth

Have you heard of this concept of a 10x developer? It's someone brilliant who manages to magically output 10 times as much as other developers.

Have you ever met one? I haven't! And I've been working with software developers (as a software developer myself) for almost 10 years now! (It will be 10 years this August).

Now don't get me wrong - I've met people who were considered by others around me to be 10x developers. I just never seem to agree.

After a conversation with a friend the other week, I was inspired to write this blogpost. You see, my friend (also a software developer) has an alleged 10x developer on her team. But the more she gets to know him, the less brilliant he seems. In fact, it seems that all he is is arrogant & confident--not superhumanly productive at all. When she was telling me this story, it rang a bell. Because this has been my exact experience with these "10x developers".

So I've come to the conclusion that they don't exist. There are no super-humans. There is no way to be 10 times as productive as other people doing the same job. (If there was, we would all adopt the practices making that person so much more productive.) I have encountered some extremely talented developers during my career. But I wouldn't consider any of them 10x. Not by a long shot. I will talk about each one of them below. (Names have been changed to avoid having to track these individuals down and get their permission - I don't want to have to wait on them in order to publish this blogpost.)

---

Paul

I met Paul at my first job. He mostly did web development at that time. Paul is the type who could do a big, foundational chunk of work in a small amount of time. What I mean by that is that he could set up the foundations for a web app in a day or two. However. This was not magic. This was a result of years of experience and experimentation. He had done this many times before and he had tried building apps in many different ways. Here's an analogy for you. When I first learned to sew, any project took me pretty long. Let's say I wanted to sew a T-shirt. It took me a long time. Maybe an entire week of sewing every day. I wasn't good at cutting out fabric. I misunderstood instructions. I made mistakes and had to unpick seams. I had a hard time easing the sleeves into the armholes. I struggled with the neckband. Now, a few years later, sewing a T-shirt does not take me long at all. I can do it in an evening or two. Of course, by now, I've made several T-shirts, so I've had lots of practice. I've also sewn many other types of garments, which advanced my sewing skills even further. See how that works? No magic whatsoever. Same story with Paul. I think he was already in his 30s by the time I met him (by contrast, I was 24 and had literally zero experience in software development). He ran his own business on the side. He had also worked as a full-time employee of an e-commerce company for several years prior. He was contracting when I met him. So a real breadth of experience! I have no idea how long he'd been working by the time I met him, but I think it was a long time (10 years?). Another thing that made Paul seem extremely smart was that he could articulate concepts and ideas as clearly as if he were reciting information from a textbook. He was an excellent communicator. He could explain anything in a way that was easy to understand. This made him appear (to me) like some sort of genius. Paul was not arrogant at all. Quite humble. Always learning. And very laidback, not super loud, but also not super quiet. Everyone around him thought he was very talented. And the reason they thought that was because it was clear every day how good he was at his job. We were all learning lots from him all the time. He was extremely helpful. And he had lots of experience to draw from. So, while his intelligence and vast amounts of knowledge seemed quite magical to me at the time, and he is without a doubt a very talented developer, he is by no means "10x".

---

John John was a manager of mine (and had been an iOS developer before becoming a manager). He is the type of guy where, you present some problem to him, and some brilliant solution that you have come up with after an agonizing struggle, and he always seems to have a better, simpler, more obvious solution--after only being familiar with the problem for 5 minutes. That is John's brand of "10x." I believe what this really is is an extremely well-developed and long-practiced habit of logical thinking. It's remembering to always check one's assumptions. (A habit/quality that will save any developer tons of time.) John is, like Paul, an excellent communicator which adds to the impression that he is very smart. Additionally, even though John is a manager, he still somehow finds time to write code. Which I find incredibly impressive. Not only does he find the time, but he seems to finish hard tasks quickly and easily. Again - this is not so much magic - as it is him choosing tasks that he has lots of context / domain knowledge / background experience with. So these tasks are easier for him than they would be for someone else.

---

George I think what makes George seem 10x is his excellent follow-through. He seems to accomplish a LOT - and what makes this really noticeable is that he finishes everything he starts. He never seems to let things drop off his radar. I assume this is more of a time management skill than it is a magical "10x" quality. (Plus maybe a personal aversion to leaving things unfinished.)

George is 6 years younger than me - but he seems to know SO MUCH. The other day I asked him how he knows so much - he said it's a combination of insomnia and having no social life. I must also add that he has a uni degree in CS - so he's been tinkering with this stuff and reading about it even longer than he's been working as a developer. When he mentioned the bit about no social life, it immediately reminded me of Lars Petrus who was in a documentary I watched about speed-solving Rubik's cubes (and last I checked is a software developer at Google). They asked him how he'd become so good at it. And he said something like "It helps if you don't have a lot of friends." If a person has lots of time on their hands and uses it to learn, they will generally accumulate more knowledge than others! Nothin super-human there.

---

I think it's probably possible to be twice as productive as other developers. I think it would require really excellent habits, endless energy (could be provided by living a very healthy and balanced lifestyle), and lots of experience. I think that's possible. But that's about it. I do not believe it is possible to be 10 times as productive as other developers.

Of course - I must mention at this point some unpleasant truths. It's important to remember that the playing field isn't always level. (Who are we kidding? It's almost never level.) And when it comes to software developers, we must acknowledge that there are a decent amount of male software developers who have wives that take care of the kids, cook and clean for them, and do their laundry, and the grocery shopping, and manage the household, and run all the errands, and so on and so on.

Someone like me, who is single and must do all of that stuff myself, cannot compete with those men (should they choose to use their excessive amount of spare time and energy to improve at their craft, read software books, take classes, or maybe even write software books).

Of course not all men in software are like this. But there are some. So just remember when comparing yourself to someone else, it's possible that they have an absolutely huge advantage over you that you are unaware of. In general, I like Robert C. Martin's books. But when I read "The Clean Coder", there was one part in it that said you should spend 20 hours per week improving your skills. Outside of work. I mentioned this to my mom - and god bless her - her immediate reaction was "Erin, is this a man with a wife that potentially does all of the housework for him?" Anyway - I digress.

---

When you come across an individual who has a reputation as a "10x" developer, here's what you should do:

1. Be skeptical.

2. Get an opportunity to pair program with this dev. This will go one of two ways:

• You will learn all his/her tricks and become a "10x" developer yourself

• It will be unpleasant and you will learn nothing because this person will be terrible at pair programming and sharing knowledge

3. Review this dev's code. Learn as much as you can from them (I predict you won't learn as much about software as you will learn about the fact that this person really isn't "10x" and just takes a lot of shortcuts). Here are the places I generally see these so-called "10x" developers taking shortcuts:

1. They do crappy code reviews. They do not spend the time to do a good job reviewing other developers' code. Some of them just don't review code at all.

2. Everyone assumes they are awesome, and as a result, does not review their code very thoroughly. So their code gets through review very quickly.

3. They skip writing unit tests (or they write a few unit tests to cover their bases, but are missing tests for a lot of scenarios).

4. They reach for workarounds and hacks immediately. Rather than first trying to find an elegant solution.

5. They use band-aid fixes for bugs. Rather than first determining the root cause of the bug and then determining a solution.

6. They avoid pair programming like the plague.

7. They don't write integration tests (or again, they write a few, but leave large gaps - I assume unintentionally).

8. They never stop to write the necessary documentation (and if they do, it's crap)

9. They don't address error-handling in the code they write.

10. They make a lot of assumptions in their code - rather than going and tracking down answers to questions.

11. They leave their code littered with TODOs and FIXMEs

12. When they put a TODO or FIXME in the code, they don't create a ticket for it (and they certainly don't add the ticket link to the TODO in the code)

13. They don't spend much time helping others. It may appear like they do, because they are often asked for help. But the extent of their "helpfulness" is sending a link. They never sit down next to their fellow dev to help by getting their hands dirty. They never check back to ask how the link worked out.

14. They don't bother with analytics or error-tracking. That's someone else's problem.

15. They create large PRs that are impossible to review, and people just approve the PRs without reviewing them thoroughly. (Sometimes there is someone like me attempting to do a thorough review, but as soon as they get an approval, they push that PR through - they don't care about waiting for my feedback.)

---

When someone on your team seems to be majorly out-performing the other team members, be very careful about how you interpret this situation. I'd be cautious about assuming that this person is extra smart or extra productive. Dig in and find out what's really going on. Is this person leaving behind huge messes that everyone else is stuck cleaning up? Is this person not doing their fair share of code review? Or not writing their fair share of tests? Are they cutting some very important corners? You don't want to hold someone like that up as a role model for the rest of the team. I'd like people to shy away from this concept of a "10x" developer. It's so rarely the actual story. (I honestly think it's never the actual story.) Additionally, if there truly was a real-life 10x developer on your team, what you need to ask yourself is: "Is this person sharing their productivity tips? Are they making everyone on the team more productive?" If not . . . well, I'm not really sure how I feel about this person's character. . . or intelligence . . . doesn't it benefit them for all of their teammates to be just as productive?? Why do they want to do the lion's share of the work? It's not like they are going to be paid 10x as much. Anyway, all of those questions are pointless because 10x developers do not exist. I think that believing they exist, chasing this designation, or using it to refer to others all contributes to toxic workplace culture.