Busting the 10x software engineer myth

i.e. Having more knowledge or banging out shonky code might let you appear more productive than your peers, and you should probably adopt more metrics than simply coding tasks getting completed.

Within a team, I think 'greatness' comes in all manner of different forms, all of which are needed. The person who holds the whole software model in their head, and can rattle off the precise changes required to implement a new feature. The person who has an encyclopedic knowledge of all the technologies, and often spotted sat next to another engineer helping them through an issue. The person who mid-way through implementation spots a flaw or an improvement that can be make to the process and comes back offering options for improvement. Of course it's great to have the person who comes back after 2 weeks having written more code than the rest put together - but.. well monoculture is always bad. Wouldn't want a team of them.

First, this is neither an exact science nor a multiplier (in this case, 10-times). I like to believe I have worked with a few of these "10x Engineers". I'm lucky to be technical enough not to be bullshitted by engineers and OK enough to sell to CTOs.

Here is my understanding.

They are not the ones who would produce XX times over a given period. It is not like normal/average engineers create X in 10 months; then they will do the same 10X in that same ten months or take 1-month to do it.

The pattern I see is that the work of these engineers lasts a very long time and stays relevant for quite a long time. Everyone who works with them is happy because they learn a lot from the actions or are predictable.

For instance, the QA team does not find apparent bugs or rare, most use cases, and the usual flow of actions and results happens.

I believe the 10X comes at a much later stage, over time, when the work is a rock-solid framework and foundation that everyone else can pick it up and work upon it.

I know I'm not very concrete, and I have to work harder to describe them in better ways. For now, it is more of a feeling I have after working with them. My only role was to understand them (not the technology) and shield them or cushion them from the BS-es that flow around anything that happens in a project/company.

We used to nod and agree on these lines -- So, what are our BS-es that we need to tell the management/client to cross this hurdle. But remember, we still need to make that BS happen.

Let me extrapolate the last part. So, I will huddle up the CxO of top Companies over a room, with concierge services waiting around to serve snacks, water, etc., but they won't be allowed to leave for a long time. Their phones are out of reach. When the other CxOs or executives are doing it, everyone else follows. I will throw around words like empathy; the design is subjective, iterative design, human framework, and all the jazz that pops up in my head. "The customer has to be able to find the shortest, simplest route to checkout."

Then I will meet up with the team, explain what I promised, and we will, kinda, laugh and wink. However, we will now convert those "Design is Subjective" to Objective Deliverable Goals and Binary answers -- YES or NO -- does this work or not - when that checkout happens, what steps, fallbacks, errors, and everything.

Companies eventually save a lot of money, as there aren't multiple iterations or griding other engineers 10-times.

* Build difficulties.

* Hidden dependencies.

* Multiple and conflicting sources of configuration information.

* Lack of documentation

* Incorrect/outdated/stone-cold lyin' documentation

* Mis-named executables, configuration files, variables, constants etc.

* Lots of global state

* Inconsistent and surprising design choices.

* Console noise inundation.

So, the supposed "10x engineer" simply knows a few paths through this mine, while the rest of you just keep triggering them with almost anything you do.