The subject of 10x engineers & their existence is back. Again. It's just the nicknames that change:

  • rockstar programmers
  • cowboy programmers
  • 10x engineers

Personally I thought that's not much to be said beyond what Scott Hanselman did here almost 1.5 yr ago, but the fire is still burning & sometimes the discussion drifts in very surprising directions:

  • 10x engineering is just about having resources (especially money) & support (especially credit of trust) (yikes!)
  • 10x engineering is a myth to promote the idea of stereoptypical white male nerdish misoginist programmer (yikes!!)
  • 10x engineering is about genetic sort-of superpowers (yikes!!!)

Geez. I won't even link any discussions, majority of them is real garbage. But I want to give my 3 cents about that as well, because actually I think that 10x is about something A BIT different.

10x engineer - who is (s)he?

10x engineer (in short - 10xe) is not someone with the unique ability to code more complex stuff. It's not someone who writes code (creates classes, objects, modules) 10x faster or makes 10x less bugs because (s)he types 10x faster or spots the bugs by their looks in IDE.

10x engineer is someone who has fully mastered the basic software craftsmanship practices & knows how to use them in practice.

Examples of these practices?

  1. debugging (YES!)
  2. reading other people code (YES!)
  3. troubleshooting problems in code (YES!)
  4. applying SOLID principles (YES!)
  5. knowing their tools
  6. basic engineering common-sense

First four items are quite straightforward, nevertheless the majority of devs HAVE SERIOUS PROBLEMS with them. The problem is more psychological than intellectual - an average programmer is quite good in mapping the written requirements into abstract model made of IFs & FORs, but CREATING code is something very different from MAINTAINING code.

Everything goes smoothly until first problems start to occur:

  • performance issues
  • errors that do not appear each time (harder to replicate)
  • errors in integrated pipeline (can't be replicated immediately via UI)
  • functionality works in a context that requires a lot of effort (massive DBs, external services)
  • something doesn't work as intended & there's not straight answer at Stack Overflow

And then shit hits the fan ...

Many programmers are just paralyzed in such situations - they can't think straight, decompose / separate the problem, iterate with small steps to find the root cause. Instead they almost randomly float around, waste time on recompiling / redeploying / re-doing everything, because they hope that the problem will magically disappear just like that.

I think that EVERY developer starts at this level, facing this mental bareer of infirmity. Some break it faster (the doers, the icebreakers, the rockstars, the 10xes), but some never ascend to this level.

I think that surpassing this threshold counts as 6x of 10x for 10xes.

The missing 4x

2.5x is from something I call "engineers' common-sense" - the gut-feeling (developed through the everyday's practice & learning) - based on what you learned / tried / read about, you have the feeling of ...:

  • ... what will work and what will not
  • ... what can be automated & what shouldn't be
  • ... what kind of indirect effect may a particular action have
  • etc.

A person with an instinct thinks with solutions, because (s)he can re-assemble parts of something (s)he has already "touched" in the past: and it doesn't matter that it was Pascal & now it is C# -> some low-level, common-sense rules are universal.

Another 1x is from knowing your tools. Yes, productivity in software development relies mainly on your brain power, but tools are important as well - not just because they can speed things up directly (sometimes they can), but they can also make things less annoying or tedious -> which is a great way to boost your morale & energy level.

And the final 0.5x is "a gift": natural talent for programming - well, some have it & some do not. Not everyone is the same -> it's exactly the same story as for any other industry.


Obviously these numbers are a simplification to illustrate the idea, but my point is that ANYONE can be a 10x engineer (well, at least 9.5x one ...). It's not for the chosen ones only.

But is it really 10x? 10 times more efficient? 10 times more reliable?

I've never measured that, but several times I've seen people ...:

  • ... completely stalling at every non-trivial obstacle, while some other (regularly) went through like a knife through butter
  • ... redoing their work, because they were not able to find out what was wrong with their code
  • ... falling in long periods of firefighting (ofc they had to put their regular tasks away for that time) because of fundamentally f#$%ed up application architecture
  • ... working with 10% efficiency because they had to work with legacy code they have never grokked
  • etc.

Yes, I believe that in this situations the efficiency of those people dropped at least few times if you compare it with what it could have been.


Even with you agree with me on what I've written above, it doesn't mean that if you identify 10xe in your team / project, you should cherish, worship & keep her/him in a golden cage. Remember:

Having 10x team is far better than having 10x engineer.

The best what you can do is push such a person towards being what I call an "inspiring technical leader":

  • (s)he doesn't have to be a formal leader of some sort
  • her/his authority shouldn't come from being assigned by superiors
  • her/his role is to spread the knowledge, guide with his experience, help others become 10xe ...
  • ... but not doing the work for someone / all alone (even if it's just the most demanding stuff)