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:
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.
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. 🙂
Latest comments (46)
I don't think you actually described a 10x engineer but rather a 10x team engineer see why with Russell Ackoff ;) youtube.com/watch?v=EbLh7rZ3rhU
Let me share a secret with You there aren't any 10x engineers :). They are the same mythical creatures as unicorns.
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-...
”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.
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.
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.
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"
Wait, that's the same thing.
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! 🙂
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.
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.