We’ve all heard the term “10x Developer” before. And if you haven’t up until this point, consider yourself lucky.
As the legend goes, some developers are 10x more productive than their peers. Meaning a single 10x developer could potentially replace a whole team of 10 other developers.
Most of us however, have come to associate this term with these three types of jerks:
- The Talented Jerk: A person who’s undoubtedly talented, but believes that gives him the right to treat everyone else like garbage. Other people hate to work with them despite their abilities.
- The Untalented Jerk: They believe they’re 10x developers with no basis in reality. Usually this is a combo of innate arrogance + the fact that they “don’t know what they don’t know.”
- The Jerk Manager: A manager who says she only hires “10x developers” and everyone on her team is “10x” (compared to what?!) This is a big red flag if you ever encounter it in an interview.
Despite the bad reputation, there were a few questions I couldn’t shake off.
Do 10x developers actually exist? Am I one of them? If not, what can I do about it?
I’ll try to answer these questions, as well figure out whether being a “10x developer” is all it’s cracked to be.
The 10x Developer Myth: Confirmed or Busted?
I’m going the lay some hard truth on you. This “myth” is 100%, unequivocally, beyond any reasonable doubt, confirmed.
But before you go nuts, please keep this in mind: The fact that 10x developers are real doesn’t mean that every two-bit developer fresh off of coding boot camp is one of them.
Jeff always thinks he knows the answer to everything, doesn’t consult with anyone even when coding infrastructure for the entire team. That doesn’t make him 10x. Especially when shit breaks down in production and no one can understand what he was trying to do.
I don’t care how fast Jeff wrote the thing, the end result is a setback for the entire team. And my Saturday.
God I hate Jeff.
The Research Behind 10x developer
I know we now live in a world where facts don’t matter and an orange caricature is the President-Elect of the United States (WTF America?!) However, I still think facts matter. So let’s set the record straight on 10x developers.
The term originates from research done back in 1968. Researchers timed developers with similar experience levels while coding and debugging a set of problems. The study found, even after accounting for measuring errors, a performance difference of 10x between the worst and best programmers.
We know for a fact that such variations do exist. The reason for that is numerous studies were made since the original who were able to reproduce similar results.
If you want, you can read more about the validity of the underlying research as well a full list of the studies in question.
So, what do these findings tell us about you?
Why you probably are a 10x JavaScript developer
I want you to take a short pause, and think about the worst developer you’ve ever encountered. We’ll refer to him as Jim.
You might have had the pleasure of working beside Jim, interview him or meet him at a local meetup. Regardless of how you got to know Jim, it didn’t take long for you to realize he has absolutely no idea of what he’s talking about.
I mean, how can a person with 7+ years of JavaScript experience doesn’t know what a Promise is?! How is that even possible?
How could Jim write on his CV that he’s a “JavaScript OOP Expert” and not even know what prototypal inheritance is. I’m not talking about syntax or implementation, he was completely oblivious to the entire concept.
Compared to Jim, I think it’s safe to say that both you and I are 10x JavaScript developers.
Why you probably are not a 10x JavaScript developer
There is no NBA for JavaScript developers. Although that would be awesome.
The reason for that (besides the lack of Nike endorsements) is it’s very hard to rate developers on a unified global scale. There’s no point system like there is in sports, and the “rules” vary widely between companies and projects.
But taking all of that into account there are still those who are insanely talented and productive. Some developers are so far off the scale it makes others wonder if they’re even real,or part of a conspiracy.
Like any other complex human ability, some are just incredibly gifted. But they’re so few and far between you’ve most likely never even encountered one.
But JavaScript fame doesn’t come to those who are most productive, there is no pointing system. Except Github stars, they’re the ultimate measure of self worth and your place in the universe 😉
This is because coding is not a competitive sport. Our “star performers” aren’t judged by how fast they debug their code or how many tickets they close in an hour.
What truly matters to us are the things our best developers create, and the way in which they create them.
So let’s start focusing on what matters.
Forgetting About 10x: Focusing on what matters
Molly and Magen are both colleagues working in the same team. Jerald is their manager.
Molly is by far the quickest on the team. When Jerald hands her a project, he knows exactly what he’s going to get. Molly is a hard worker who gets things done on time, sometimes even earlier.
When Jerald hands a project to Magen, he knows she’ll get the job done on time, even though her estimates are usually longer than Molly’s. Yet he trusts Magen more with the bigger projects.
Magen has a tendency to recognize design flaws in their original plan and raise flags early. She identifies and extracts crosscutting concerns to the team’s shared libraries, or even ask permission to open source things she thinks it will benefit the community.
When Magen asks Jerald for a two-day extension to implement that new logging framework they’ve been talking about, he approves gladly. He knows everyone will end up benefiting from Magen’s experience.
You see, every time Jerald hands a project to Magen he doesn’t know exactly what’s going to happen. But he does know that he can count on Magen and that everyone’s going to be better off when she’s done.
This makes me start to wonder, how much time and mental energy should we spend on trying to be the fastest, most efficient developers? Perhaps instead we should be asking ourselves “What should I learn today in order to become a better JavaScript developer?” Or maybe “What could I develop that would really help the team out?”
Answering these questions would be a far better use of your time. I’m sure they’ll take you much farther professionally.
Because at the of end the day who would you rather be, a Magen or a Molly?
Taking Initiative
As developers, we have the privilege to provide great value by doing a fine job of doing what we’re asked to do.
But our greatest value, by orders magnitude, comes from our ability to take a step back and look at the bigger picture. It comes from doing the things no one asked us to do. From our ability to say “This what I think we need, and this is how I plan to do it.”
And then comes the most important part: Following through.
When we decide to develop something we’re not 100% sure is going to work, or when it’s our initiative, it makes our stomachs feel a little uneasy. But that’s exactly how you know you’re on to something.
A few years back, a developer named Jordan Walke encountered a problem at Facebook. Their existing tools didn’t solve it properly even though they were using all the best practices at the time. He then decided to try something new.
Jordan’s new library was based on a weird concept from a PHP library that was already working well for Facebook at the time, but there was nothing similar to it in JavaScript. So he made the argument to get some time and create something new.
Jordan ended up creating a nifty little library. Facebook even decided to open source it after extensive internal use.
That library’s name is React.
So do you think anyone cares how fast Jordan’s debugging speed is? Or how quickly he closes tickets? I know I don’t.
But I sure do love using React.
“Imagination is more important than knowledge. For knowledge is limited, whereas imagination embraces the entire world, stimulating progress, giving birth to evolution.” – Albert Einstein