The fables of 10x engineers never include:
- updating the docs
- pair programming
- adding meaningful test coverage
- listening to burned-out coworkers
- improving on-call runbooks

The engineers that do these do not seek glory. They plant trees they don't expect to sit under.

@raiderrobert

Silently just gets the work done while avoiding meetings.

@raiderrobert

Also never
-mentoring junior or intermediate engineers

@raiderrobert Add to that

- fixing non-working corner cases that you co-worker have to deal with

- partner (if you are lucky enough to have one supporting your character) being left alone with home cleaning/children/day to day organization

-unmaintainable code that nobody (even you 2 weeks later) can fix

@raiderrobert

But planting trees is boring, I wanna be a rockstar unicorn jedi and just push my poorly tested, completely undocumented, AI generated code directly to prod! This is fine because I’m awesome and AI AI AI AI AI AI!

@raiderrobert What you are describing is mostly management failure. Give me an engineer who can truly bang out good working code at that speed but sucks at docs and I'll assign them a trainee and a docs person and still be 3x ahead.
If you have someone with a very spiky skill profile as is common in #autistic leaning engineers you work to enable their skills. We don't bitch at great violinists because they are terrible at writing out music, it's if they can't work as a team it's trouble
@raiderrobert The reality is that the "real" 10× programmer is the one who makes 10 peers (especially juniors) better by doing all those things.
@raiderrobert
And they only wear white tennis socks!

@raiderrobert they don't scale.

Also: a 10x engineer who is sick or on holiday is a 0x engineer during that time.

@raiderrobert
This sounds like a 3rd parallel promotion ladder to me ...

@raiderrobert

#3 is meaningless. The 10x engineers I know all obsess about the other 4.

One could not devise a better illustration that the "10x developer" was a problem of measuring the wrong thing all along.

(@tastapod & @raiderrobert I know you both know all this far more than I ever will)

@raiderrobert I like the take from peopleware: at least according to one study, 10x engineers are just engineers that work in an interruption free environment.
@raiderrobert These are all things that require a mindset that you will be at this company a couple years from now when all signs point to no.
@raiderrobert Nothing on the list means "delivers new features" which is why they are the ones who have to leave first.
@raiderrobert @JosephLeedy
- Automating & standardizing procedures.
- Sticking around during new version launches to make sure nothing goes wrong.
- Caring about the quality and readability of their code
It also helps our future selves in addition to lifting up new people. Test coverage, documentation, runbooks, those help our future selves avoid making the same mistakes, so we can make exciting new ones instead.

@raiderrobert The sad story about the 10x engineer is the moral we could have taken and the one we did take. The original study was in the 60s using very low level programming languages, and basically no real professional rigour in the field. You could very well read that as "we have people who intuitively know how to program, and the rest, we aren't training them very well". You could read that as "there are some people who can cope with the additional complexity from low level programming languages, but we can improve language design to minimise that".

But no, we collectively just did a Goodhart's law to it, something so idiotic that only one other field of "study" readily does this: Economics.

So now instead of looking at the spread and thinking about it, we went "let's just find *the guy*". But even that was more reasonable to start with: It was, let's find the guy and put a good team around them, which is almost what this post and the replies are arguing towards.

But then people got even more stupid. They said: What if everyone was 10x and the way we measured it is by saying "if you write a for loop you're clearly an inferior programmer than someone who just writes the same line 10 times". Awesome.

And now there's a dichotomy, we're just pushing *for* or *against* this myth. This is "electrolytes that plants crave" level bad.

No. The parable of the 10x engineer is a story about how we as a field need to take ourselves seriously, and we need *standards* and *values*. The fact that "some guy" can just declare "move fast and break things" and we eagerly follow the mantra is the folly at the end of this parable, not some pelvic thrusting mouth breather getting promoted beyond their skillset.

@raiderrobert Those are the attributes of a good 10x engineer, because they'll magnify their positive impact over time ten fold.