Rubenerd

There’s been another surge of interest in the concept of so-called 10x Engineers on social media, and I’m delighted to see it being called out for the counterproductive and damaging idea it is.

Defining the term

The canonical Silicon Valley Dictionary defines a 10x Engineer as:

A concept sometimes used in Silicon Valley to describe an engineer that is 10x more productive than an average engineer although the 10x metric is figurative. Sometimes referred to as “Ninjas”, these engineers are highly sought after by all tech companies.

Use of the term ninjas is the perennial cake icing. This recruitment site has some more clichés:

10x Engineer @ Surge. Connecting rockstar tech talent with the most disruptive early-stage startups in India & Southeast Asia.

But my favourite definition comes from this nginx-ish 404 page by @theevocatur:

404 Not Found
10x Engineers aren’t real

Attributes that make a 10x Engineer

So now we know what these mystical beasts are, what are their defininig qualities? Codegiant listed the following, which I’ve condensed into a paragraph for easier skimming and to make a point in a moment. Emphasis added:

Curious and always learning. Not just great engineers themselves, but they elevate the work of everyone around them. Able to dive in and and learn new code bases with faster ramp up times. Great at recognizing patterns and replacing procedural code with simple, beautiful methods. The best at debugging code; they don’t need to waste time, because they ID problems quickly and have a solution faster than your average programmer. Extremely well versed in a broad range of languages, tools, and algorithms. Able to quickly recommend the best technical solution based on risk vs. benefit. Always coding; not just at work, but on their own time. Looking at the whole picture and can anticipate problems, and build to avoid them.

There are some good pointers here that would apply to any modern work. Being self motivated and willing to learn, and honing one’s craft to the point where elegant solutions can easily be developed are all important. I’ve been privileged and honoured to work with developers who possess all those qualities.

But there are two points that concern me. “Always coding” guilts people into a permanent state of work: learning on your time isn’t considered a desirable bonus, it’s mandatory. This is how you exploit people with unreasonable hours and destroy life/work balance, which is counterproductive when your staff burn out or quit.

And the larger point is what the list excludes. Read the sentence I highlighted above in the sea of other words. Only one point out of almost a dozen mention interpersonal skills. I shouldn’t be surprised, but this absolutely floors me, like a nicely finished parquet.

Unless you’re working for yourself, you’ll almost certainly be working in a team; and even sole traders often have contractors. Your ability to work constructively and congenially in a group, either as a member or manager, will have a direct impact on a project’s success or failure.

It’s everybody, stupid

The more time I’ve spent as a systems architect now, rather than a developer or a sysadmin, the more I’ve come to realise that humans are as important to IT as the infrastructure itself; perhaps more so. Even the most selfish of managers must realise that hiring a Ninja Rockstar 10x Engineer who brings toxicity and antagonism will ultimately be a net negative. Which is why I was encouraged to see Atlassian’s recent post about performance reviews:

Another common bias that pops up is when companies over-emphasize delivery of results and ignore behaviors that can take a toll on team health and company culture (some refer to this as rewarding the “brilliant jerk”).

Brilliant jerk is such a great term on so many levels, I’m going to start using it.

And as for those developers I mentioned above that I worked with? All of them were lovely people too.