5 ms·

Your weekly reminder that the 10x engineer theory is that the best engineers are 10x better than the worst engineers. Which means they are 2 to 3x your average

Your weekly reminder that the 10x engineer theory is that the best engineers are 10x better than the worst engineers. Which means they are 2 to 3x your average engineer. They aren't going to make your team 10x better unless your team is really bad.

IggleSniggle 6y ago
Your yearly reminder that the original use of 10x engineer referred to an engineer who took 10 times longer to the same task as the typical engineer, and has also been variously subverted since in a variety of ways including the “team multiplier that isn’t especially more productive, but is the secret sauce that makes the team 10x more productive.”
partyboat1586 6y ago
This is good to know. I always thought it meant 10x average which seemed absurd. I can certainly attest to having worked on teams where there are one or two developers 10x better than the worst developers on the team. Tbh I think the worst developers are actually negative value because they take so much time from other developers.
- qznc 6y ago
  One source for the 10x number is the book Peopleware. They did Coding War Games where developer got an exercise. The 10x is the time it took them to code an application which fulfills the requirements. The best is 2.5x compared to average. Since it is a single person task, they cannot impact anyone negatively. However, the most interesting fact in my opinion is that within the same organization the difference is only 0.3x. Either the organizational environment determines your productivity or the organization determines which kind of developers get there. The experiment does not tell us anything how the productivity of a developer changes when he changes organizations.
  - kqr 6y ago
    "A bad system will beat a good person every time" as Deming said.
randallsquared 6y ago
The worst engineers destroy value instead of creating it. Less bad than that are engineers who create arbitrarily small amounts of value for the product and team. The 10x engineer concept only really makes sense as "10x typical".
- ipsocannibal 6y ago
  I've come to call this value destruction process "negative work". Typical negative work activities include injecting that new shiny tool into everything because its new and shiny, refactors that require refactors for a single line change that never happens, writing buggy tests and pushing then writing a follow up task to fix your buggy tests that are blocking the pipeline then not doing that task, only doing 'manual' testing, telling the team a tool doesn't work only to realise the dev didn't know how to use it, endless wiki page re-writes, using stand-up meetings as a bitchfest etc. Fortunately, I've become better at recognizing negative work patterns and removing those dev's from my team. Your team will die from attrition if you don't.
IshKebab 6y ago
I dunno, I've met one person who is 10x better than me and I'd consider myself average. I think they must just be very very rare. It's difficult to measure "better" in some cases anyway - you could have 1000 average engineers and they'd never come up with a bloom filter or arithmetic coding or whatever.
- nullsense 6y ago
  Engineering talent likely falls on some sort of distribution like most everything else in the universe. Whether it's normally distributed or not I don't know. Some of the variables that underpin engineering skill are independent, but software careers have a tonne of path dependence where the types of software and problems you work on feed into the types of software and problems that you get to work on in future and that has a big impact on your skills and that particular variable isn't independent. I still work with the assumption that the distribution is normal just cos it's easy to conceptualize. So maybe it makes more sense to think about the 2, 3 and 4 sigma engineers than the "10x" engineer.
jbverschoor 6y ago
No it's not. The "10x" is 10x average. And yes, they will make your team 10x better, as can will decisions which will help the whole team be more productive, or allow you to hire juniors, simply because good code and architecture is simple to understand and work with.
- nullsense 6y ago
  Taking it literally seems kind of silly. It's directionally correct and that's all. It's not precise, but it's accurate. Probably varies depending on the organization too.

IggleSniggle 6y ago

Your yearly reminder that the original use of 10x engineer referred to an engineer who took 10 times longer to the same task as the typical engineer, and has also been variously subverted since in a variety of ways including the “team multiplier that isn’t especially more productive, but is the secret sauce that makes the team 10x more productive.”

partyboat1586 6y ago

This is good to know. I always thought it meant 10x average which seemed absurd. I can certainly attest to having worked on teams where there are one or two developers 10x better than the worst developers on the team. Tbh I think the worst developers are actually negative value because they take so much time from other developers.

qznc 6y ago
One source for the 10x number is the book Peopleware. They did Coding War Games where developer got an exercise. The 10x is the time it took them to code an application which fulfills the requirements. The best is 2.5x compared to average. Since it is a single person task, they cannot impact anyone negatively. However, the most interesting fact in my opinion is that within the same organization the difference is only 0.3x. Either the organizational environment determines your productivity or the organization determines which kind of developers get there. The experiment does not tell us anything how the productivity of a developer changes when he changes organizations.
- kqr 6y ago
  "A bad system will beat a good person every time" as Deming said.

randallsquared 6y ago

The worst engineers destroy value instead of creating it. Less bad than that are engineers who create arbitrarily small amounts of value for the product and team. The 10x engineer concept only really makes sense as "10x typical".

ipsocannibal 6y ago
I've come to call this value destruction process "negative work". Typical negative work activities include injecting that new shiny tool into everything because its new and shiny, refactors that require refactors for a single line change that never happens, writing buggy tests and pushing then writing a follow up task to fix your buggy tests that are blocking the pipeline then not doing that task, only doing 'manual' testing, telling the team a tool doesn't work only to realise the dev didn't know how to use it, endless wiki page re-writes, using stand-up meetings as a bitchfest etc. Fortunately, I've become better at recognizing negative work patterns and removing those dev's from my team. Your team will die from attrition if you don't.

IshKebab 6y ago

I dunno, I've met one person who is 10x better than me and I'd consider myself average. I think they must just be very very rare. It's difficult to measure "better" in some cases anyway - you could have 1000 average engineers and they'd never come up with a bloom filter or arithmetic coding or whatever.

nullsense 6y ago
Engineering talent likely falls on some sort of distribution like most everything else in the universe. Whether it's normally distributed or not I don't know. Some of the variables that underpin engineering skill are independent, but software careers have a tonne of path dependence where the types of software and problems you work on feed into the types of software and problems that you get to work on in future and that has a big impact on your skills and that particular variable isn't independent. I still work with the assumption that the distribution is normal just cos it's easy to conceptualize. So maybe it makes more sense to think about the 2, 3 and 4 sigma engineers than the "10x" engineer.

jbverschoor 6y ago

No it's not. The "10x" is 10x average. And yes, they will make your team 10x better, as can will decisions which will help the whole team be more productive, or allow you to hire juniors, simply because good code and architecture is simple to understand and work with.

nullsense 6y ago
Taking it literally seems kind of silly. It's directionally correct and that's all. It's not precise, but it's accurate. Probably varies depending on the organization too.