Busting the 10x software engineer myth

I can cite many examples of a 10x engineer having an insight that greatly shortened the development time.

It's not that they write code faster. It's that they select a path to the solution that is a lot shorter.

Writing code is the simplest thing in our job, once the problem and goal are clear the solution presents itself.

Knowing what to write, what not, how to solve users problems and how to understand users problems in the first place so you know you're solving the right one up to users expectation, that is the hard part.

A testing methodology that moves from programming kohans only tests the writing code part. Of course you find low variation there!

> Wrote hard-to-understand procedural code to 5000-line files. Did not actively share knowledge with his peers.

The author seems to mean prima donna, not a 10x engineer and then goes on to destroy that strawman.

Actively sharing knowledge, mentoring etc... and code and architectural simplicity are a given for someone who's 10x productive. Most of the costs are in maintenance not the initial delivery and a 10xer's output would deliver over the life of the software use. Hard to decipher code doesn't sound like it would fit that bill.

This is a silly framing of the 10x engineer issue. That label originally designated someone who had written an unusual amount of excellent software.

Recently in the discussions here, people take it to mean someone who cobbles together broken apps at a rapid pace and gets credit from management for being a hero. This is not what 10x engineer means. Please find another label for that phenomenon, for example 10x faker.

There are some good points in this article. At the same time, "10x engineers" are not a myth. Anecdotally, I have seen plenty of situations where the most skilled engineers in a group were many times more productive than the least skilled. If anything, "10x" greatly understates how big the difference can be.