You may have seen a thread circulating around on Twitter recently about "10x engineers". If you haven't, you can read it in all its glory:
Shekhar Kirani @Accel@skirani
10x engineers
Founders if you ever come across this rare breed of engineers, grab them. If you have a 10x engineer as part of your first few engineers, you increase the odds of your startup success significantly.
OK, here is a tough question.
How do you spot a 10x engineer?13:02 PM - 11 Jul 2019
The summary of it is, unless you fit some super narrow and stereotypical view of being a developer, you are not a "10x engineer".
Many will say a "10x engineer" doesn't exist as being 10x better at something than someone/most people would be pretty damn hard. Even if the person doesn't literally mean "10x", it is still trying to say there is someone significantly better at everything.
Personally I hate the term "10x engineer". Like "rockstar developer", they are poor descriptions and definitions of what great developers are.
It would be disingenuous to say that all developers are equal. Just a few minutes of looking at different developers on Twitter, I can already see many developers that know a hell of a lot more than I do. That said, talking about this "10x engineer" like they can significantly increase the odds of your business being successful is pretty ridiculous.
Enough about beating down that terrible stereotype of "10x engineer", let's talk about the things that really make great developers (aka the real "10x engineer").
1. They are smart but know their limits
Unless it is some trivially small code base, they don't know every line of code that has gone into production. Sure they can solve a lot of problems by themselves but they know when they are stuck and know when to ask for help.
Nothing is wrong about asking for help, no matter your skill level!
2. Strong independently but still make a kick-ass team
There are times for programming independently and there are times for programming in a team. These developers don't just take a task and run off into a corner to work on it in silo to everyone else. Development beyond the smallest scale requires constant collaboration with a team - whether that be paired programming, code reviews, bouncing ideas, helping with debugging etc.
That isn't to say that a great developer isn't more comfortable working by themselves on certain tasks but large scale development is practically impossible without strong collaboration.
3. They help others with problems
Have you ever asked a colleague for help and they did? Congratulations, they might be a great developer. We might look at documentation or even Stack Overflow for help but sometimes we actually need help from someone who knows our code base. If you're a developer who knows something that could help a colleague, help them!
4. They are kind and understanding
Being a great developer isn't about being a smart ass, showing off your intellect, disregarding meetings because you're better than those people. Being a great developer is also about being good with the non-technical things. If you're "helping" a colleague by yelling at them and criticising their code, just stop.
5. They challenge you (in the right way)
This might sound controversial but a great developer isn't going to give you the answers all the time. That might sound in contradiction to #2 and #3 however this isn't meant to hold something over you. A great developer is someone who can give you just enough so you can solve it yourself. These little challenges help make you a better developer and allow you to understand what things you might need to learn more about.
6. They understand "new shiny" isn't the solution for everything
Not to say these developers aren't checking out new tools and languages (they can do whatever they want in that regard) but they do understand new tools aren't magically going to solve every problem.
James Hickey 🇨🇦👨‍💻@jamesmh_devWe are obsessed with learning about more tools and languages!
If your architecture is bad, you're solving the wrong problems, your client doesn't understand when you try to explain things... then shiny tools don't help.
And these are fundamental to your business' success!18:54 PM - 27 Jun 2019
7. They know it doesn't matter when you program and what editor theme you use
Stereotypes of programmers aside, why would the time when you program actually make a difference? Program in the middle of the night if you want/are allowed by the company and don't do it if you don't want to. The only reason time should be coming into play is when you've been programming for too long and haven't slept! The actual time of the day doesn't matter unless it affects your team (eg. you work at midnight programming to intentionally avoid everyone).
Same with editor themes, why would a dark theme actually make you better? I'll give you a hint, it doesn't. Dark themes have their purpose but that sure isn't it.
8. They don't go out of their way to make something more complex
This might be obvious but there was another Twitter thread the previous week talking about programming something complexly like that is a good thing to do. When was making our job and the jobs of our colleagues harder a good thing?
There are definitely times we can end up programming a complex solution like perhaps we don't (yet) fully understand the problem. This can happen on our first attempt at programming the solution, that's when you usually hear people talking about refactoring code or not being "proud" of code they wrote the previous week/month/year.
9. They don't think of the "me" in "team"
Unless they truly have written every line of source code themselves from the compiler up through all the business logic, they know it was a team effort. They don't try and take the spotlight from anyone else on the team - they highlight all the contributions that made a project a success.
When a project goes poorly, they don't go ahead and blame everyone. Team projects fail as a team, not as an individual (unless malicious intent). They help the whole team learn from the mistakes and help prevent them happening again.
10. You actually want to work with them
At the end of the day, these great developers are people you actually enjoying working with. You rock up at work (or remote in) and are happy to be working with such an awesome team.
If you know any developers that sound like this, tell them how awesome they are and how you're happy working with them. 🙂
Top comments (46)
As I've matured as a developer, and having fit a few of these stereotypes myself, I've realized that the real 10x developers aren't the ones described there. It's possible that, yes, that caricature or a developer may produce more output than the rest of the team, but, at best, they generally have a slight impact on the team and, more often, I've seen them drag the team down. By cutting themselves off from the rest of the team, they negatively impact the team dynamic and often produce code that is not maintainable by anyone but themselves - but they don't want to maintain it, because that's not as fun as "real coding."
As I said, I've been that developer. Luckily, I grew out of it. I've realized that the only true 10x developer is the one who makes the whole team 10x more productive - mentoring others, sharing good ideas, accepting feedback, cleaning up code as they maintain it, writing good documentation, and making the organization the kind of social environment where people want to work. Most of the time, software development is not a single-player game, it's a team sport.
(Edit - Posted on accident before I finished typing - that's what I get for typing one-handed on my phone. The extra bit starts here.)
There's a military term that I find applies to these kinds of developers - Force Multiplier. Simply put, a force multiplier is some factor that makes a force more effective than it would be otherwise - for example, having access to satellite navigation can make a small force as effective as, say, a force 5x larger that doesn't have it.
A great developer is one who acts as a force multiplier for the team. They don't increase productivity by doing more themselves, they help everyone else be more productive.
As a retired Infantryman this is exactly what force multiplier means. I actually started to reply with almost the exactly same points and then I found this comment.
I've always thought of a "10x engineer" as referring to a force multiplier, not someone who actually does 10x more work. That's not sustainable and would be a TERRIBLE person to build a codebase around. If they leave, what will you do then?
Pardon the sports metaphor, but it reminds me of the LA Lakers and Kobe Bryant. Towards the end of his career, they built the team around him. He was, admittedly, very talented, but every time he got hurt, the team fell apart.
If you compare that with the Michael Jordan-era Bulls, they were lead by an incredible player, but he was surrounded by other great players. Their dominance in the 90s was a team effort, and when Jordan briefly switched to baseball, they didn't completely fall apart. They weren't as good as they were with him, but they still did very well.
(Sports and military references in the same thread? This conversation is bringing out a different side of me.)
^
We really do need to kill this idea of a 10x Engineer/Developer. Associated with this idea is tons of baggage, unacceptable team behavior, etc. I think there are much better ways to foster success and grow people than accepting that we need to have a 10x-er on staff.
This comment is a Force Multiplier to original post. Thank you, sir.
True helping the others get better is better than being way better.
Hey! That's [almost] the term I use as a team lead. I went with "bonus multiplier." My output goes down, but [hopefully] my team's collectively rises and is more than it was before. Great analogy!
Spot on
Good list, but like it or not, the existance of the "10x developer" is a statistical certainty, and has to do with productivity not volume of knowledge. The pareto distribution shows that in almost any field, 20% of the people do 80% of the work. For those that are in the 20%, they are the "10x".
The problem is less about some developers doing more work than others but the combination of stereotypes that make this "10x developer". Nearly every use of "10x developer" I've seen comes with caveats like "programs through the night", "doesn't like meetings", "only uses dark themes", "knows every line of code", "doesn't work well in teams" etc.
What makes a developer good or not is none of those points (who cares what theme someone uses). The best developers people will more likely match up with the 10 points I've listed. Programming at any reasonable scale requires working with a team and I doubt the productivity of a single "10x developer" would be able to "beat" a team of developers who are smart/helpful/work well with each other.
I also think that it's a misconception that 10x refers to speed or productivity. You won't see them doing a 2 week sprint in 2 days, they might even appear to be progressing slower because they are thinking designs through for hours, paying attention to small details and researching connections between concepts. But at the end of the day, they are able to solve really difficult problems and produce more maintainable systems.
When I see a job listing asking for a rockstar developer, I read that in my head as "We hope you get energized working weekends and holding an understaffed team together!"
Interesting take. Do you have some data to back that up?
I think the myth of the 10x developer is well established. But its a myth. People remember it from the book Peopleware by Tom DeMarco, et. al. But often forget the main lesson of the book that I will quote here:
"You May Want to Hide This from Your Boss
Among our findings of what did correlate positively to good performance was
this rather unexpected one: It mattered a lot who your pair mate was. If you
were paired with someone who did well, you did well, too. If your pair mate
took forever to finish, so did you. If your pair mate didn’t finish the exercise
at all, you probably didn’t either. For the average competing pair, the performances differed by only 21 percent.
"Now, why is that so important? Because even though the pairs didn’t work
together, the two members of the pair came from the same organization. (In
most cases, they were the only ones from that organization.) They worked in
the same physical environment and shared the same corporate culture. The
fact that they had nearly identical performances suggests that the wide spread
of capabilities observed across the whole sample may not apply within the
organization: Two people from the same organization tend to perform alike.
That means the best performers are clustering in some organizations while
the worst performers are clustering in others. This is the effect that software
pioneer Harlan Mills predicted in 1981:
'While this [10 to 1] productivity differential among programmers
is understandable, there is also a 10 to 1 difference in productivity
among software organizations.1'
(H. D. Mills, Software Productivity (New York: Dorset House Publishing, 1988), p. 266. )
"Our study found that there were huge differences between the 92 competing organizations. Over the whole sample, the best organization (the one with the best average performance of its representatives) worked more than ten times faster than the worst organization. In addition to their speed, all competitors from the fastest organization developed code that passed the major acceptance test.
"This is more than a little unsettling. Managers for years have affected a
certain fatalism about individual differences. They reasoned that the differences were innate, so you couldn’t do much about them. It’s harder to be fatalistic about the clustering effect. Some companies are doing a lot worse than others. Something about their environment and corporate culture is failing to attract and keep good people or is making it impossible for even good people to work effectively." (De Marco, et al. Peopleware 3rd Ed 2013. p46-47)
The book basically concludes by proposing that the better organizations are those that create better working environments. The book that originally came out in 1987 is probably the reason many companies like Microsoft and others gave every developer their own office in the 90s.
People have forgotten the main point of the book and actually look at the very things that the "statistics" showed did not matter so much.
At work you probably notice a guy that's way better than you. But such a guy in a better company would be even more awesome. And in a worse company he'd look like a chump to you even if you're a junior.
The pareto distribution is very well known and studied. I'll leave it up to you to google it and read up on it.
The Pareto principle doesn’t mean that 80% of the code is written by 20% of the developers. It was observed in wealth distribution and even then it was observed that 20% of people “owned” 80% of wealth, not “generated”.
The only data I can find in software development is from Microsoft who found that “80 percent of the errors and crashes in Windows and Office are caused by 20 percent of the entire pool of bugs detected”.
If 20% of your team are doing 80% of the work then surely there are serious issues with the team...
The pareto distribution has been observed in more than just economics, it has also been observed in many different workplaces. I doubt if you looked for specific references of it to developer workplaces you probably won't find much, but it is considered to be near-universal across different types of industries, and there is nothing unique about the industry of software dev.
"If 20% of your team are doing 80% of the work then surely there are serious issues with the team..."
Absolutely, which explains why many workplaces are such a mess (particularly large corporate ones where they have enough staff to fit the mean).
I think your point was a little obscured by the way it was made.
Yes, in literally any system there is some sort of distribution curve. There is definitely such a thing as a bad, passable, good, better, best spectrum in any line of work. There is a 20th percentile and an 80th percentile and maybe those in the top 20 percent are "10x" developers according to your definition.
Do they perform ten times the work of anyone else in the shop? Hard to say. If so, then you probably have a mess of a workplace.
This article is focusing on some of the prevalent stereotypes and how they aren't necessarily indicative of whether or not someone is in the top 20 percent, making the argument that instead of pure evaluation of "productivity" (which is nebulous at best... Is that Lines of Code? Completed stories? Impact to team velocity? Speed at solving fizzbuzz?) that there are instead some other non-technical and leadership aspects to the "10x" engineer that pushes the whole team forward rather than being a purely individual contributor divorced from their team...
So I think there's some common ground here for everyone :D
Well, no. The Pareto Distribution is a parametrisable line on a graph - without evidence, it shows nothing. You clearly have faith that it applies to productivity of developers, and indeed it might, but without data statistics tells you nothing. This is without trying to get into defining what "productivity" means, which is terribly difficult.
With my statistician hat on, a far more sound argument for the data-minimalist is as follows: Given the number of developers in existence the probability there there does not exist a developer who is ten times more productive than the mean is vanishingly small by the law of large numbers, therefore the 10x developer exists. This statement holds pretty much regardless of the definitions of "productive" (assuming the distribution of the productivity of developers is long-tailed) or even "developer".
Whether or not the above statement has any worth is left as an exercise to the reader.
My gut feeling is that it'll follow a normal distribution curve (bell curve) rather than a Pareto distribution, possibly skewed up or down depending on various factors like team morale, buy-in to the project, and environmental factors (Oh WHEN are they going to fix the air-con in here?! It's too hot to think!). Most people don't like to do worse than average for the team because obviously they don't want to be seen as dragging their velocity down - but equally if one person does so much more than anyone else it can create bad feeling because it's putting pressure on everyone else to perform better than they're comfortable doing & it's making people look bad. Nobody likes a teacher's pet, so to speak.
Forget about 10x engineers, we need more 10y engineers!
Good engineers ask why before they start building something. The best engineers ask more of them.
That's just my humble opinion on the subject.
First sentence sounds like a joke, but actually you've got a point. A good one. In the last months I wished some of my co-workers had asked 'why?' more often. Wouldn't have lead to days of work wasted.
Where does the tweet thread say that?
A (purposely) stupid analogy:
Someone says "Humans have hair on the head"
and everyone going "OP says: Bald people are not human"
Based on the Twitter thread, to be a "10x engineer" you have to:
These 3 statements are absolutes (ie. there is no "most" or "sometimes" or "might") as raised by the original Twitter thread. That is a fairly specific set of minimum requirements to have for a "10x engineer".
When absolutes were not used, strong generalisations were used instead:
While generalisations are just that (not covering every case), the specific phrasing indicates a "more often than not" to a "far more often than not" set of additional criteria for a "10x engineer".
With my summary, the "narrow and stereotypical view" covers the absolutes. The "super" (though also "stereotypical" again) covers the generalisations. At most, I'm probably over emphasising the absolute criteria in my summary.
Refer to my hair/bald analogy.
Just because there is no generalization like "Most humans have hair on the head" people are interpreting a seemingly harmless statement as :
"In order for you to be called a human, you MUST have hair on the head"
Even if every absolute they gave was a generalization, they are listing strong generalisations for a "most often" case. This "most often" case happens to be a stereotype-ridden person.
It isn't that one statement was taken out of context, they did a series of tweets along the same lines and many people drew the same conclusions. Either their message is exactly like we are interpreting or their message has come across very poorly and needs a better explanation.
If you're adamant that they were just misinterpreted, write an article explaining where we've gone wrong and what the real intention of the "10x engineer" thread actually was.
I think this discussion is going in the wrong direction.
My apologies.
No need to apologise - you were kind and respectful. Have a nice day! 🙂
Wait, that's the same thing.
Love this!
I agree with your points, I actually just heard of the term "10x engineer" after reading this book. I'm concerned about a company's desire to hire developers who don't have any interest in working with others as long as their work increases the company's business.
Hey great article! I read the original twitter thread and to be honest I couldn't be too offended, mostly because I really couldn't tell if Kirani was being serious or satirical. Sure lot's of descriptions of 10x Engineers are very misinformed, but some of his points lack any redeeming qualities, even for the bottom line!
Yeah, I really like to think it was satirical but with how many people didn't then get the "joke", I have a feeling we interpreted it the "right" way.
Thanks for this, a much better idea of an ideal programmer than whatever 10x is. I once saw myself as a rockstar, unicorn, etc. as a young programmer but the traits above are the mature and truely more important aspects to develop as a programmer.
”x10” is an unhelpful myth. the programmer that I most respect explained the phenomena as ”a minority of programmers have optimised things to get stuff done and focus on what counts. the majority haven't and so have a lot lower total output”. This correlates with my experiences and observing others. When I am in my flow I can get great stuff done. When I am caught up shaving someone else herd of yaks between a week full of meetings nothing concrete gets achieved over many days. The lesson is not that there is special 10x pixie dust. The lesson is that you need to remove all the meetings and yak shaving and incidental complexity and get into your flow. Some people are more practised at that. If you find your flow and remove the incidental complexity and optimize your tools you will go at full 1x speed like the minority. If you keep on with waiting for slow deployments to then test your code you will go at 0.1x speed like the majority.
They’re out there and that’s where the legend comes from but they’re rare. And increasingly becoming rarer.
I’ve been in a team that was assigned a list of bugs to work through. I had my Silicon Valley mentality, I wanted to prove in worth having there, and I just like getting things done.
So after a week I had fixed 35 bugs. Analyzed each issue, found core cause, developed correct fix and regression tested each one. Fun!
The other two team members had fixed .... 1.
This was bad for team dynamics obviously.
Other teams I’ve been in I was always the fastest blasting through bugs and having reputation with the QA team. But for Dev speed I was certainly not getting 10x more features done than other good engineers. It’s hard to compare features - each are different and they’re not all same sized. So who knows. But feeling wise I was just on par with other good engineers I knew, faster than poor engineers.
But I know some hardcore geeks who always did stuff I couldn’t do like program 3D fractal generators in assembler. Or the legend at apple who I once had to visit with a problem nobody could figure out - he didn’t know anything about our team or the project but he provided a solution inside 5 minutes and half coded it in that time too. That’s a legend. PhDs and scientists I worked with the advanced technology group at apppe spoke about him in hushed voices. He was the guy to go to when nobody knew what to do. Won’t mention his name but it was a memorable experience. How could he even understand what we were doing so fast let alone come up with a solution nobody had thought of .... myths!!
But in practical situations I am 100% with the top comment here - team matters way more than individuals. It’s like any team sports. The team that plays together the best wins, not the team with the most talented individuals.
As someone who has reasonable experience founding a company, hiring, training, motivating and managing developers and teams, I feel I can tell you what I really believe:
Forget 10x developers. Forget berating developers for checking in code that doesn’t compile.
If you are planning to build a real growing company, You need to progressively put more stress on your SYSTEM. That is your job.
Have a kickass onboarding set of tutorials and documentation for everyone. Have a culture that anyone can assign an issue to anyone, instead of interrupting them. They can get feedback via updates on issues.
Use pre-commit and post-commit hooks to catch as many mistakes as possible, and clean up team formatting standards for your code.
Hire developers who are super familiar with whatever technology (language, platform, techniques) that you need them to work on. But NO ONE SHOULD BE A HERO, everyone’s code should be easily understandable, use only the simplest language features to get the job done (but no simpler), and be documented. Accrue no code code debt.
Each developer’s work should be documented and tested, preferably by someone other than themselves.
Each developer should be replaceable. That extra 30% cost spent on fully documenting and testing their code means months saved onboarding someone to take over.
Working remotely is actually GOOD. Working asynchronously 90% of the time is even BETTER. Everything in your system should assume people don’t share time or space.
People live lives. Companies build products. That is our motto. It means exactly this... ask yourself whether you are building a product, and if so, do not give responsibility to PEOPLE, but to the system. If they take a day off to spend with their kids, or work 3 hours a day, it shouldn’t have a major effect on the product.
And our compensation model reflects this, too. Instead of full-time employees, feel free to take anything from this:
qbix.com/blog/2016/11/17/properly-...
After reading the tweet thread, I love this list so much more! One note, a dark themed code editor does help me work better. Brighter, lighter themed displays, hurt my eyes more.
I'm a dark theme user too and while I prefer it, the vibe I got from the original thread is that the "10x engineers" use it exclusively. I'm sure many people better than me use a different theme.
I like dark themes because I am old, and it makes me nostalgic about the old days developing in vi in an xterm on a monochrome monitor.
You're right to react to that tweet. I guess most of us read it.
I read it twice before understanding its meaning. I conclude that, either its author has a limited perception of the world of engineering out there, either I still do not understand.
It sounds like an excerpt from Alice's Adventures in Wonderland. None of us has any superpower. For sure, we always are somebody else's smart. The opposite works correct, too.
No one in this world has succeeded thanks to one engineer who compiles manually in assembly, faster than my i9 8th generation. Success lies on a set of soft skills; a vision; and an appealing adventure.
The 10x engineer levels up others. Otherwise, he just an engineer doing his job.
Brilliant post!
Great article! Professional software development is definitely a team sport and I don't know why that's a revelation to some people who have been working in the field.