How We Should Define a 10x Developer

We’ve all heard of the concept. There’s this mythical software uber dev who can produce ten-times the amount of code as the rest of us. And if we could just hire one, the bosses say, we’d never miss another deadline again.

Mind you, no one’s ever actually worked with the 10x dev directly, but a friend of mine once told me about this guy…It was on a triage call where the whole stack was blowing up. But, two seconds before the Boss was about to call the Big Boss, the 10x dev interrupts, tells everyone the exact line number that has the bug—from a class that wasn’t even in the documentation—and everyone cheers like when Luke landed after blowing up the Death Star. Come to think of it, my friend told me this story while out celebrating a big release. So that story might have been exaggerated a little.

We’ve all heard enough variations of the story that the rumor persists. Worse, a whole lot of tech management buys into the idea of the 10x dev. They create processes that assume a room full of these wizards churn away in cubes just outside their offices. They write interview questions that only a true 10x dev could answer. And, worst of all, they evaluate their developers on individual output, lauding the one who ate up story points like Pac-Man and made the other nine look bad.

And if making nine other developers look bad counts someone among those lofty ranks, then I sincerely hope to never actually encounter a 10x dev. But what if we measured a 10x developer by their ability to make nine of their peers better instead?

#

Back in the days when my employers still let me write code, I never saw myself as a terribly good programmer. I got the job done. Nothing special. But over time, I noticed people starting to come to me for help. At first, I didn’t quite get this. Sure, I had a little tenure-based seniority, but I’d been in code reviews with my teammates. They could code circles around me. So why did these folks act like I had some knowledge that was useful to them? Because, the answer turned out, they knew I wanted to help them and that sometimes, just working through a problem with someone who wants to help solve it opens the path forward.

The more I worked there, the more this became my role. I was lucky at that early time in my career. I had a boss that saw and recognized this for what it was—an opportunity to make his team better. I don’t know how my career would’ve turned out if that boss only looked at the code I’d actually written myself. But through that boss encouraging me to exercise those nascent abilities, I started to learn that this mediocre programmer could be a damned good developer.

The team started counting on me more and more, and not for my code. Eventually, I stopped getting assigned my own projects. I was on every project. I was the guy who trained new teammates. I was the guy who hosted workshops. I became the guy who worked with our customers and, from there, I dove headfirst into their business objectives. I learned my customer’s needs as well as they did.

But that’s not what might make me a 10x developer. When one of my former teammates stopped a project because his team were coding to the wrong requirements; when that former teammate convinced his customer that there was a better approach; and when that former teammate saved his team from an expensive rewrite; that’s when I felt like a success. If I’m ever to be a 10x developer, it’s through the people around me and showing them how to make the people around them better.

#

I’ve been in IT leadership and management roles for years now. I don’t get to code. That’s probably for the better. I’ve gone through a dozen waterfall processes and survived multiple agile transformations. I’ve written a few bad processes myself and I’ve definitely had to use more than one bad “formula” for evaluating a teammate’s contribution. But the thing I’ll never do is contribute to the fiction that any one dev is better than another because of the number of commits, the accumulation of story points, or the sheer count of code lines written.

The myth of the 10x dev needs to end. We need to stop poisoning our younger teammates’ minds with this fool notion and stop applauding when a junior developer eschews all other life skills in favor of insular thinking and the pursuit of the most unreasonable of expectations.

We get better by helping others. The team gets better when you encourage them to help each other.

Disclaimers:

1. Opinions expressed are solely my own and do not express the views or opinions of my employer.
2. Any people referenced in this article are fictitious.