Busting the 10x software engineer myth

Same way rewriting your code in Rust doesn't make you a 10x developer for removing memory safety issues.

A 10x more productive developer is more productive within an ecosystem against others who are also in that same ecosystem. It's not fair to compare a C developer to a Rust developer in terms of developer skill. But maybe productivity you could. Like how Python is more productive than C++ but you don't call the Python developer a 10x developer.

The integer solution is not great, but is mathematically consistent despite what many believe (it’s true in most proof assistants, for example).

You can absolutely measure something.

I have a colleague going through this right now - he's got... 24 years of experience in software - mostly web - across multiple problem domains/industries. He's now on a web team with someone who's done windows desktop software for 15 years, someone else who graduated from high school 2 years ago and has never worked anywhere before, someone else who has a few years of some web experience but has never actually shipped anything remotely close to what the team is trying to do.

There's more, but... the mgt wants to treat everyone as 'equal' and having an 'equal voice'.

So... they need some new web service. "Let's use React! Let's use Dart! Let's use foo!"

Mgt: "OK - well... let's have a 'shoot out' - everyone research their ideal and we'll present findings!"

My colleague: "Hey - here's this. I got this done in a couple days - there's tests, docs, works with the existing infrastructure, and has some sample data for you to play with".

Weeks later, others: "Hey, that's not fair, you already knew some of that. I'm not an expert in $foo, but heard good things about it, and people at google use it, so we should too! I just need a few more months to get up to speed, then I can show the rest of you how good it is and why we should use it."

Someone being able to accomplish stated goals in a few days, where other people on the team are not even sure what terms to google... Yes, there are people who are "10x developers".

Or they are working in a small and well-funded company that only employs ~10x engineers, and they have never met a (to them) 0.1x engineer.

- There are 10x as many pretenders for every one real one. Management might mistake the fakers for the real ones because they are faking it on being charismatic. These engineers wreak havoc on teams.. everyone else is cleaning up their mess, the fake 10x gets all the credit due to the charisma and ego and too often the rest of the team isn't able to reveal the true situation. Management will often give these guys (never seen a fake 10xer who was a woman) huge accommodations and let them go off on massive projects outside of normal accountability and project management and when they come back a year later they've produced a big mess of garbage but a year was spent and the guy is charismatic so management has to have it in the product.

- Any given engineer might be 10x more productive in one organization than another. This can probably be indirectly correlated to the size of the organization

- Fake 10xers can drag down everyone else's productivity, and make themselves look better in the process.

- Real 10xer will produce an elegant architecture or solution that is easy to maintain and understand. The faker will produce a mountain of code with hidden bugs and put on an air as if no one else is smart enough to understand what they've produced.

- There's an element of "emperor's new clothes" with revealing a faker. Everyone knows they are a faker except management, and yet it feels impossible to stop pretending and pull the curtain back.

- Non-technical management makes it much easier for the faker to get their hooks into an org. Maybe the UI designer got elevated to VP of engineering and doesn't know much about code. Maybe a junior guy got promoted for being one of the first employees. These kinds of managers are juicy targets for fakers.

- Fakers often seem to introduce new tech to the stack so they can show it off on their resume, even if it doesn't fit the product well.

- Fakers make up clever names for everything they write as if they are marketing their code. Put stuff off in a separate library in a separate repo when it could have fit right in the main repo. Give it a clever name. Convince management to allow them to put it on github as open source so they can polish their external cred.

My last two positions the team was essentially sabotaged by a fake 10xer on each project. Reams of buggy code and huge management accolades, when the bad code starts to catch up to them them move on and leave tons of tech debt behind, and they move on to do the same thing at their next position. One of these guys spent 3 years writing a crazy library that used an alternate persistence strategy and when it got put in it destroyed performance to such an extent that when he moved on the whole thing was removed in a month or two and performance went up 100x just by changing everything back to a more standard persistence strategy. Meanwhile alternate persistence strategy went all over the guys's resume/LinkedIn.