The myth of the 10x developer is so pervasive, debate as to whether it actually exists continues to this day.
Crazy talk! Next thing you know, they'll be claiming there's such a thing as a manager that actually cares about your psychological well-being. The audacity of such a thought! How foolish! How positively naive!
Allow me to propose a radical notion: What if they do exist, but are just so hard to find, nobody believes it?
Allow me to propose one more: What if we're having a hard time finding them because we can't agree on what defines such a creature?
Crazy talk! Next thing you know, they'll be claiming there's such a thing as a manager that actually cares about your psychological well-being. The audacity of such a thought! How foolish! How positively naive!
Allow me to propose a radical notion: What if they do exist, but are just so hard to find, nobody believes it?
Allow me to propose one more: What if we're having a hard time finding them because we can't agree on what defines such a creature?
Not A Thing
Let's start with what a 10x developer is not (something we can all agree on!)- A 10x developer is not a developer that writes ten times more code than their peers,
- A 10x developer is not measured by SPH (Semi-colons Per Hour), and
- A 10x developer is not someone who makes their teammates 10x better.
1. Amount of Code: Doesn't Matter
Ask any programmer worth their salt and they will tell you straight up: more code doesn't necessarily make a better piece of software. So attempting to measure a 10x developer by their LOC (Lines of Code) count is worthless. Don't do it.
2. How Fast They Code: Doesn't Matter*
*(sort of)
This one is tricky to parse, so let me be painfully clear on two points:
- A programmer that knows how to type (hands on the home row, asdf, jkl;, etc.) is always going to be a faster developer than one who doesn't know how to type (ie. is always looking down at the keys, finger sniping at random, then looking back up at the screen to confirm what they wrote).
- The faster one types, the more prone to mistakes they become.
So, given two programmers, one that knows how to type, and one that doesn't: in nearly every case, the typist will outperform the non-typist. But this attribute should only be examined as a means of personal growth. It is not, nor should it ever be, a measure of 10x performance overall.
Think of this one as a bell curve. On the near end, non-typists (and their slow speed) will definitely be a handicap. On the far end, typists that behave like a professional race car driver may produce reams of code at the snap of a figure...but that doesn't necessarily make it quality code.
In short: speed is one key facet of a 10x developer, but its existence alone doesn't magically produce a 10x developer. And (with many things in life) too much of it can be a detriment.
3. How Effectively They Train And Mentor Others: Doesn't Matter**
**(it matters, but not for being a 10x developer)
In a perfect world, development teams would not only be efficient producers of magnificent code, they'd support one another, guiding each other into success, and acting as a support to each other in times of need.
In reality, programmers are awkward. Things go unsaid. They challenge one another as to who can out do who -- who can garner the most praise, produce the most beautiful algorithm, who can work the longest hours without collapsing. In short: programmers (for whatever reason) often value/prioritize the wrong things.
It isn't unheard of to have a team member take their expert pattern matching ability and apply it to their peers -- documenting processes to educate them, participating in code reviews to mentor them -- in the hope of producing a team that jells.
Make no mistake: This is a wonderful thing to have. This is a leader.
A leader is not the same as a 10x developer.
(I've covered why the differentiation is important in a separate post.)
(I've covered why the differentiation is important in a separate post.)
Definitely a Thing
While a leader that is also a 10x developer would be a truly marvelous thing indeed, let's not get ahead of ourselves. If we want to bring an end to the insanity of this never-ending debate, we need to agree on what constitutes a 10x developer. And since it is so tricky, the wording must be precise:
A '10x developer' is one that can take software from concept to production-ready in an order of magnitude less time than a peer of matching experience utilizing the same technologies and delivering the same functionality.
Here's a breakdown of the wording and why it matters:
- '10x developer' is in quotes because, like it or not, that's the term we continue to use...but it should never reflect a literal performance gain of ten times more/faster/better. If there was ever a time to declare YMMV, this is it.
- from concept to production-ready: if programmer A builds an app in 1 week and programmer B builds an app in 4 days...but programmer A's app takes 3 days to debug and programmer B's takes another week with the help of a second developer...who exactly is the 10x developer?
(hint: you still don't know the answer...because neither of them have launched yet -- another set of variables that affect the assessment of a 10xer.)
Remember: when comparing developers in order to gauge a 10xer, you must look at the end-to-end turnaround. Anything less is equivalent to comparing the speed of two carpenters hammering a single nail in order to judge house construction time.
- an order of magnitude less time: As stated earlier, 10x should never be taken literally -- but it will be noticeable enough to raise eyebrows. Adhering to the earlier rule, once you examine a developer's turnaround time for a completed task, it should be painfully obvious if a 10xer is present.
You can always expect marginal differences between every developer. If three developers are tasked with implementing a theme (of equal difficulty!) into a Wordpress site, they may come in at different durations -- 7 days, 5 days, 8 days -- but you can see they're (for the most part) producing at a comparable rate.
When that mythological beast shows up and implements the same theme into a Wordpress site in 6 hours...you can begin to suspect you might possibly have a 10xer on your hands. Is 6 hours exactly 10x more than the previous average? Well, here's the math:
7 days / 5 days / 8 days = 56 hours / 40 hours / 64 hours (8 hrs in a workday) = 53.3 hrs average dev time for the first three devs.
53.3 hrs = x * 6 hrs.
x = 8.88.
Answer: No, your fourth developer wasn't 10x faster...technically, they were only 8.88x faster. But you get the idea. The factor may not have been exactly 10x, but it's clear you have a potential diamond in the rough on your hands. Clear enough that we didn't even really have to do the math. Once you heard "6 hours", you should've immediately known something was up. And that's usually the indicator: Enough to take notice. - a peer of matching experience: I shouldn't have to clarify that comparing a developer with 3 years experience to one with 20 years of experience is foolishly shortsighted...but I will anyway. Expertise goes hand-in-hand with experience, so resist the urge to compare developers with a different number of work hours under their belt.
- utilizing the same technologies: As with the above rule, don't compare the turnaround time of two developers doing what appears to the same thing but in actuality is not. This would be another foolish and shortsighted assessment. If developer A installs and configures a Wordpress site in 6 hours, and developer B installs and configures a Ghost site in 30 minutes, do you have 10xer on your hands?
Not necessarily, considering they are two radically different content managements systems. Yes, the end result is they let make blog posts, but one is PHP, one is Node.js; one has a streamlined installer, one requires more hands-on configuration; one prefers MySQL as the back-end, one defaults to SQLLite, the list goes on and on.
So, again, don't compare turnaround time unless the technologies leveraged match.
- delivering the same functionality: Just as with the previous two bullets, don't attempt to assess a 10xer when the delivered software you're comparing has vastly different functionality. If programmer A takes a week to build a blogging tool, and programmer B only takes 4 days...but programmer A's produces an RSS feed as well as built-in Markdown support...and programmer B's doesn't...should you just ignore that and call programmer B the 10xer?
Uh, no. You shouldn't.
Don't compare the turnaround time for tasks whose functionality doesn't match. Yes. Once again, I'm going to call you foolish and shortsighted if you do that.
Thing One And Thing "Do"
You now have an accurate definition of a 10x developer. The next logical step is how to determine what makes these 10xers so damn efficient. I've covered it in a separate post.
For now, let's let the dust settle and agree to agree on something: there are developers that perform well...and there are developers that perform extremely well...and as long as what you use to compare them adheres to the definition above, you may just find they aren't so mythological after all.