Busting the 10x software engineer myth(swarmia.com)
swarmia.com
Busting the 10x software engineer myth
https://www.swarmia.com/blog/busting-the-10x-software-engineer-myth/
356 comments
I totally agree, but I think you can use examples closer to home.
Carmack could build a video games which is 100x across a number of metrics (quality, cost, time to deliver) than I could. Still too far? Pick your field, there'll be experts.
You can get even closer to home. After 20 year, I really feel like I'm at least 10x developer across a number of metrics (e.g., value to my employer, amount of complexity I can manage) than I was when I started.
Also, some developers do more harm than good. An employer would literally be better paying them not to do work.
Carmack could build a video games which is 100x across a number of metrics (quality, cost, time to deliver) than I could. Still too far? Pick your field, there'll be experts.
You can get even closer to home. After 20 year, I really feel like I'm at least 10x developer across a number of metrics (e.g., value to my employer, amount of complexity I can manage) than I was when I started.
Also, some developers do more harm than good. An employer would literally be better paying them not to do work.
> Carmack could build a video games which is 100x across a number of metrics
But even Carmack couldn't crack Steve Jobs stubbornness.
Sometimes being 10x is only a matter of being free to help the best you can.
EDIT: where Carmack shows that he is well above average is not in coding, but in being extremely pragmatic and thous being able to extract good, almost unbiased, information out of every discussion, even the more unpleseant ones.
---
Part of his method, at least with me, was to deride contemporary options and dare me to tell him differently. They might be pragmatic, but couldn't actually be good.
"I have Pixar. We will make something [an API] that is actually good." It was often frustrating, because he could talk, with complete confidence, about things he was just plain wrong about, like the price of memory for video cards and the amount of system bandwidth exploitable by the AltiVec extensions.
People were backing away from us. If Steve was mad, Apple employees didn't want him to associate the sight of them with the experience. Afterwards, one of the execs assured me that "Steve appreciates vigorous conversation".
Still deeply disappointed about it, I made some comments that got picked up by the press. Steve didn't appreciate that. The Steve Jobs "hero / sh*head" rollercoaster was real, and after riding high for a long time, I was now on the down side. Someone told me that Steve explicitly instructed them to not give me access to the early iPhone SDK when it finally was ready.
But even Carmack couldn't crack Steve Jobs stubbornness.
Sometimes being 10x is only a matter of being free to help the best you can.
EDIT: where Carmack shows that he is well above average is not in coding, but in being extremely pragmatic and thous being able to extract good, almost unbiased, information out of every discussion, even the more unpleseant ones.
---
Part of his method, at least with me, was to deride contemporary options and dare me to tell him differently. They might be pragmatic, but couldn't actually be good.
"I have Pixar. We will make something [an API] that is actually good." It was often frustrating, because he could talk, with complete confidence, about things he was just plain wrong about, like the price of memory for video cards and the amount of system bandwidth exploitable by the AltiVec extensions.
People were backing away from us. If Steve was mad, Apple employees didn't want him to associate the sight of them with the experience. Afterwards, one of the execs assured me that "Steve appreciates vigorous conversation".
Still deeply disappointed about it, I made some comments that got picked up by the press. Steve didn't appreciate that. The Steve Jobs "hero / sh*head" rollercoaster was real, and after riding high for a long time, I was now on the down side. Someone told me that Steve explicitly instructed them to not give me access to the early iPhone SDK when it finally was ready.
> But even Carmack couldn't crack Steve Jobs stubbornness.
I honestly don't understand how this is relevant.
Carmack is 10x in coding and designing software. Jobs was 10x in PR and persuasion.
I honestly don't understand how this is relevant.
Carmack is 10x in coding and designing software. Jobs was 10x in PR and persuasion.
The point is he wasn't when he worked with Jobs.
Carmack is exceptional, not just 10x, but how many above average people work with a Steve Jobs and can't prove it and do not even realize it?
Carmack is not an actual good benchmark here, but even as good as he is, he met his kryptonite
Don't assume that great workers will perform great in every condition, because that's not a realistic assumption and only puts pressure on younger people for no reason.
We must not support the idea that if you're not Carmack you can't be worth (at doing your job. *only *) more than the others or the company's average.
Carmack is exceptional, not just 10x, but how many above average people work with a Steve Jobs and can't prove it and do not even realize it?
Carmack is not an actual good benchmark here, but even as good as he is, he met his kryptonite
Don't assume that great workers will perform great in every condition, because that's not a realistic assumption and only puts pressure on younger people for no reason.
We must not support the idea that if you're not Carmack you can't be worth (at doing your job. *only *) more than the others or the company's average.
"worked with Jobs"
What are you talking about, John Carmack never worked directly with Steve Jobs? He had his own company and he sometimes had to talk with Apple as a platform vendor, but they never worked together on a title. He didn't like Jobs as a person but that is another story.
What are you talking about, John Carmack never worked directly with Steve Jobs? He had his own company and he sometimes had to talk with Apple as a platform vendor, but they never worked together on a title. He didn't like Jobs as a person but that is another story.
Carmack literally talks about working WITH Jobs, but random HN user says he didn't.
OK!
OK!
John Carmack ran a video game company. Steve Jobs ran a platform, the Apple. Therefore John Carmack sometimes talked to Steve Jobs about things he needed from the Apple platform. John Carmack had a very negative experience in those interactions, yes. But John Carmack never worked with Steve Jobs on any project. Steve Jobs was never the boss of John Carmack.
If you disagree please link an article where it says that they did work together on anything and that during that project John Carmack's performance was significantly reduced. I haven't found such an article, and it would be strange since they never worked at the same company.
That he did a few keynotes at Apple isn't really working together. And him refusing to take a keynote that would force him to reschedule his wedding is just him being healthy and Steve Jobs being an ass, I'd say that is evidence that Steve Jobs didn't really have any power over him.
If you disagree please link an article where it says that they did work together on anything and that during that project John Carmack's performance was significantly reduced. I haven't found such an article, and it would be strange since they never worked at the same company.
That he did a few keynotes at Apple isn't really working together. And him refusing to take a keynote that would force him to reschedule his wedding is just him being healthy and Steve Jobs being an ass, I'd say that is evidence that Steve Jobs didn't really have any power over him.
> If you disagree please link an article where it says that they did work together
It would have sufficed to read the Carmack post.
Seriously, random internet guy, he literally *said it himself*
> When NeXT managed to sort of reverse-acquire Apple and Steve was back in charge, I was excited by the possibilities of a resurgent Apple with the virtues of NeXT in a mainstream platform. *I was brought in* to talk about the needs of games in general, but I made it my mission to get Apple to adopt OpenGL as their 3D graphics API. I had a lot of arguments with Steve.
> I wound up doing *several keynotes with Steve* (see the word WITH?), and it was always a crazy fire drill with not enough time to do things right, and generally requiring heroic effort from many people to make it happen at all. I tend to think this was also a calculated part of his method.
-- John Carmack
I've specifically said WITH not FOR.
Please random guy, read before speaking.
It would have sufficed to read the Carmack post.
Seriously, random internet guy, he literally *said it himself*
> When NeXT managed to sort of reverse-acquire Apple and Steve was back in charge, I was excited by the possibilities of a resurgent Apple with the virtues of NeXT in a mainstream platform. *I was brought in* to talk about the needs of games in general, but I made it my mission to get Apple to adopt OpenGL as their 3D graphics API. I had a lot of arguments with Steve.
> I wound up doing *several keynotes with Steve* (see the word WITH?), and it was always a crazy fire drill with not enough time to do things right, and generally requiring heroic effort from many people to make it happen at all. I tend to think this was also a calculated part of his method.
-- John Carmack
I've specifically said WITH not FOR.
Please random guy, read before speaking.
> But even Carmack couldn't crack Steve Jobs stubbornness.
Not sure that's a bug.
Seems no matter what Jobs thought, Carmack kept bringing value and shipping great software.
Not sure that's a bug.
Seems no matter what Jobs thought, Carmack kept bringing value and shipping great software.
I always use competitive coding as an example. There are children in Ukraine / India / Russia / wherever who I'm sure will always be able to whoop my ass in these competitive coding things. I try really hard and get nowhere, and when I look at their submissions it's some inscrutable / clever thing that solves the problem orders of magnitude faster than I could ever do.
The only way through this all is to recognize that it's okay to feel stupid, even if it's pretty much all the time. I'd rather feel stupid and challenge myself than sit around bored (e.g. with Monolith Maintenance).
The only way through this all is to recognize that it's okay to feel stupid, even if it's pretty much all the time. I'd rather feel stupid and challenge myself than sit around bored (e.g. with Monolith Maintenance).
Your case of Carmack is illustrative.
To achieve 100x, consider what he was doing:
- writing a first person shooter (Castle Wolfenstein 3d)
- writing a first person shooter (Doom)
- writing a first person shooter (Quake)
... you get the idea.
Now, there was enormous leaps in maximal utilitilization of hardware, but do you notice a pattern? The requirements are basically fixed.
Most 10x I've achieved in a short fashion or observed was due to some similar parameters:
- the requirements were stable
- the basic problem was done before and practiced, and implementaiton was a variation/improvement of the previous
- solo or very small development team where greenfield imposed little barriers
To achieve 100x, consider what he was doing:
- writing a first person shooter (Castle Wolfenstein 3d)
- writing a first person shooter (Doom)
- writing a first person shooter (Quake)
... you get the idea.
Now, there was enormous leaps in maximal utilitilization of hardware, but do you notice a pattern? The requirements are basically fixed.
Most 10x I've achieved in a short fashion or observed was due to some similar parameters:
- the requirements were stable
- the basic problem was done before and practiced, and implementaiton was a variation/improvement of the previous
- solo or very small development team where greenfield imposed little barriers
Commander Keen was the first side scrolling platformer for PC (side scrolling was hardware accelerated on consoles, so PC games didn't have it before this) and released 1991. Wolfenstein 3d was the first fps and released 1992. Both of those were revolutionary and combined is more than enough to put him way above most other game programmers at the time.
And you know, at the time he didn't have any experience! That was his first few years as a professional programmer! So your hypothesis that he was only effective since he worked in a domain he had tons of experience in is wrong! He had less experience than most other programmers but was way more effective in many different areas.
And you know, at the time he didn't have any experience! That was his first few years as a professional programmer! So your hypothesis that he was only effective since he worked in a domain he had tons of experience in is wrong! He had less experience than most other programmers but was way more effective in many different areas.
Side scrollers have existed since the Apple II on "PCs". I highly doubt that 1991 was the first side scroller on ibm pc.
Wolfenstein was not the first 3d fps on ibmpc, and certainly not in "PC" land. Skyfox existed on the Apple II, and battlezone likely was ported at some point.
Carmack was fantastic, but again his "requirements" are static and he is a dev team of one.
Wolfenstein was not the first 3d fps on ibmpc, and certainly not in "PC" land. Skyfox existed on the Apple II, and battlezone likely was ported at some point.
Carmack was fantastic, but again his "requirements" are static and he is a dev team of one.
A lot of early jump & run games worked on a screen-by-screen basis (Prince of Persia, Lode Runner, etc) rather than actually having smooth, NES-style scrolling.
In any case, this Wikipedia article [1] backs up that the only real predecessors of Keen on PC were early-80s console ports that were extremely limited in other ways, like having boxy, low color count graphics.
[1]: https://en.wikipedia.org/wiki/Side-scrolling_video_game#IBM_...
In any case, this Wikipedia article [1] backs up that the only real predecessors of Keen on PC were early-80s console ports that were extremely limited in other ways, like having boxy, low color count graphics.
[1]: https://en.wikipedia.org/wiki/Side-scrolling_video_game#IBM_...
seadragon on the apple II did scrolling, as did a lot of shmup and shmup ports.
I've never written a side scroller so I don't know how much of the gravity/platform mechanic complicates the scrolling, but I imagine it's about the same thing as shmups with hitboxes, sprites, etc.
I've never written a side scroller so I don't know how much of the gravity/platform mechanic complicates the scrolling, but I imagine it's about the same thing as shmups with hitboxes, sprites, etc.
Mazewar was the first FPS, but Wolf3D was a totally different class of game, and every FPS since then has been an imitation of Wolf3D. Agreed about CKeen.
I guess this all depends on your definition of 10x. It sounds like you are saying 10x the average person rather than 10x the average person who works in that field.
I'm a 10x developer if we count non developers. I am not if we could people who work as developers. Likewise there are expert marathon runners who are 10X, or more, than the average human. But there are not marathon runners who run 10x faster than other professional marathon runners.
I'm a 10x developer if we count non developers. I am not if we could people who work as developers. Likewise there are expert marathon runners who are 10X, or more, than the average human. But there are not marathon runners who run 10x faster than other professional marathon runners.
> But there are not marathon runners who run 10x faster than other professional marathon runners.
It’s true that they don’t run 10 times as fast, but the marathon runner that is 1% faster will finish 10x more races before the slower one (YMMV depending on stdev).
Similar in software development, picking a 1% better local solution often enough can make the global result 10x better due to the complexity of the systems.
It’s true that they don’t run 10 times as fast, but the marathon runner that is 1% faster will finish 10x more races before the slower one (YMMV depending on stdev).
Similar in software development, picking a 1% better local solution often enough can make the global result 10x better due to the complexity of the systems.
This example holds true imo. There is a world of difference between a 2:10 marathoner and a 2:30 marathoner. Same as a 4 min miler and a 4:30 miler, etc.
Because of diminishing returns, improvement can still be seen as potentially some kind of multiple in many skillsets.
Because of diminishing returns, improvement can still be seen as potentially some kind of multiple in many skillsets.
So 1x devs exist? I agree.
Claude Shannon, Dennis Ritchie, Vitalik Buterin, Jeff Dean are all 10x programmers. Let's not pretend they dont exist
Perhaps. But is it meaningful to talk about these incredible outlier cases when considering how you structure an engineering organization?
I think there are two kinds of companies that make tech:
1. Companies where all of the technical problems they need to solve can be solved by typical engineers.
2. Companies where some of the technical problems they need to solve are too difficult to be solved by typical engineers.
In the latter case you do need "special" engineers and you need to point them at these problems. But what percentage of companies fall into category #2?
I think there are two kinds of companies that make tech:
1. Companies where all of the technical problems they need to solve can be solved by typical engineers.
2. Companies where some of the technical problems they need to solve are too difficult to be solved by typical engineers.
In the latter case you do need "special" engineers and you need to point them at these problems. But what percentage of companies fall into category #2?
3. Companies that have technical problems that can easily be solved by typical engineers but not noticed and articulated by typical engineers.
Which is most of them. The main value of "special" engineers come from them pointing you to the right problems. Notice how all of Ritchie, Shannon, Dean and Buterin certainly fall into this category. They were all technically proficient enough, but that's not the point. A seasoned veteran would have coded circles around Buterin at age 20, which is when he invented Ethereum. The point is that the seasoned veteran didn't invent Ethereum. Similarly, Shannon's most influential work (that paper that basically invented information theory) is fairly elementary, and basically any geezer with a relevant PhD had had the technical chops for the paper. But they never would have written that paper in a million years.
Which is most of them. The main value of "special" engineers come from them pointing you to the right problems. Notice how all of Ritchie, Shannon, Dean and Buterin certainly fall into this category. They were all technically proficient enough, but that's not the point. A seasoned veteran would have coded circles around Buterin at age 20, which is when he invented Ethereum. The point is that the seasoned veteran didn't invent Ethereum. Similarly, Shannon's most influential work (that paper that basically invented information theory) is fairly elementary, and basically any geezer with a relevant PhD had had the technical chops for the paper. But they never would have written that paper in a million years.
10x what?
As far as I'm aware, Shannon wasn't even a programmer.
I'm sure Ritchie was pretty good at coding in the language he invented; AIUI, that language is pretty similar to the assembly language of the machine he designed it for.
I don't know anything about Buterin and Dean.
I'm sure these people all had brilliant ideas and insights, that I couldn't begin to match. But given an arbitrary dev task, I doubt they'd come close to 10x the performance of a reasonably competent dev.
As far as I'm aware, Shannon wasn't even a programmer.
I'm sure Ritchie was pretty good at coding in the language he invented; AIUI, that language is pretty similar to the assembly language of the machine he designed it for.
I don't know anything about Buterin and Dean.
I'm sure these people all had brilliant ideas and insights, that I couldn't begin to match. But given an arbitrary dev task, I doubt they'd come close to 10x the performance of a reasonably competent dev.
'dev task', 'shannon wasn't a programmer', 'don't know about buterin, dean' -- There in lies your problem, seriously
Shannon was a mathematician, famous for his work on information theory. Wikipedia says he presented a paper on the subject of programming a computer to play chess. In 1949. It doesn't mention any other programming accomplishments. And as far as I know, there were no programming languages at that time.
And if my "problem" is not having heard of Buterin and Dean, I reckon myself a fortunate fellow - I can think of worse problems.
And if my "problem" is not having heard of Buterin and Dean, I reckon myself a fortunate fellow - I can think of worse problems.
> Marathon runners run 42 km in like two hours but it would take me days to finish the same distance...
Not really. If you walk at an easy pace of 2 miles per hour, and start at 6am, you'll be done in time for an evening meal. At 3 mph, you might even make afternoon tea.
The world record marathon times are, in fact, only about 4-6x what you can do as a walking human being.
Not really. If you walk at an easy pace of 2 miles per hour, and start at 6am, you'll be done in time for an evening meal. At 3 mph, you might even make afternoon tea.
The world record marathon times are, in fact, only about 4-6x what you can do as a walking human being.
Correct - and if you compare world record marathon runners with average (but seasoned) marathon runners, the difference is even smaller.
Specifically, RunningWorld.com took data from 107.9M runners over 70,000 events over 209 countries over 32 years and found the "average" finish time was about 4:32hrs. The men's world record is ~2 hours.
https://www.runnersworld.com/uk/training/marathon/a27787958/...
(That link has a video of people on a giant treadmill, moving at Kipchogi's world record pace, trying to keep up).
https://www.runnersworld.com/uk/training/marathon/a27787958/...
(That link has a video of people on a giant treadmill, moving at Kipchogi's world record pace, trying to keep up).
Time wise, absolutely true, but as someone who is a reasonably seasoned runner I can say my 3:30 marathon feels lightyears away from 2:00. It doesn't sound 10x harder, it sounds impossibly harder.
so in the context of TFA, what really needs to be asked is not "are some people massively better coders than others?", but rather "how difficult is it to progress from the equivalent of a 3:30 marathoner to a 2:00, as a coder?"
I don't know the answer, TBH. I've been a programmer for nearly 35 years now, and at times along that journey I've been the 10x coder. But I'm not anymore (just like I can't go sub-3h for a marathon at this point), despite knowing a lot more and being better by some metrics than I was during my 10x periods.
I don't know the answer, TBH. I've been a programmer for nearly 35 years now, and at times along that journey I've been the 10x coder. But I'm not anymore (just like I can't go sub-3h for a marathon at this point), despite knowing a lot more and being better by some metrics than I was during my 10x periods.
Maybe what needs to be asked is
"If you're okay with the message getting there in 3 and a half hours instead of 2 hours, do we really need to fetishize 10x performance?"
YAGNI is a way stronger principle to base your success on than finding or training unicorns.
"If you're okay with the message getting there in 3 and a half hours instead of 2 hours, do we really need to fetishize 10x performance?"
YAGNI is a way stronger principle to base your success on than finding or training unicorns.
> It may take a world-class musician a week to write a masterful symphony but it would take me way longer.
But are you a world-class musician yourself?
Yeah it would probably take me a week to run a marathon, but I've never run anything so it's not a meaningul comparison.
In all your examples you're comparing amateurs or even non-participants vs. the top professionals. Of course there is a huge multiplier, up to sometimes infinity.
That's not the typical usage of "10x developer" though. The baseline comparison isn't random person on the street who is not a developer. The comparison is other professional developers who are gainfully employed in the field.
But are you a world-class musician yourself?
Yeah it would probably take me a week to run a marathon, but I've never run anything so it's not a meaningul comparison.
In all your examples you're comparing amateurs or even non-participants vs. the top professionals. Of course there is a huge multiplier, up to sometimes infinity.
That's not the typical usage of "10x developer" though. The baseline comparison isn't random person on the street who is not a developer. The comparison is other professional developers who are gainfully employed in the field.
I've worked with hundreds of average (professional) developers over the years, and I've only met 1 person who was a 3x developer. I've met several 2x developers and lots of 1.5x developers. I assume a 5x developer exists, but I doubt a 10x does.
I think the point of x10 devs is this doesn't occur in other fields. It's like a HR Moore's Law.
I've always understood it as: if you step back and see the easy way, it's easy to be x10.
But most jobs are dominated by actual unavoidable straightforward work. Another exception is mathematics. You can certainly have a x10 mathematician! But it's not a mainstream job.
I've always understood it as: if you step back and see the easy way, it's easy to be x10.
But most jobs are dominated by actual unavoidable straightforward work. Another exception is mathematics. You can certainly have a x10 mathematician! But it's not a mainstream job.
> this doesn't occur in other fields
It absolutely does, just look at surgeons.
It absolutely does, just look at surgeons.
The reality is you DO have 10x devs, hell you have infinity-x devs, because there are zero value devs - epitomized by the bullshit promoted by stupid start-ups like Swarmia, and next to that, by basic mathematics, anything positive represents a infinity-x improvement.
10x (or more) engineers in both hardware and SW exist. I've personally known more than a few, they are humbling, and I was pretty good myself at the time.
SW is too time consuming, I think, for it to really show, and tools help even things out, but I think math shows that even 100x people exist - the von Neumanns of the world. Maybe they don't exist any more, but we had a bunch of them in the 1900s and it's inarguable that they were at least 1-2 orders of magnitude above the rest.
That said, there's a ton of people in the field who now focus on image management so heavily that the numbers of _apparent_ 10x are really skewed. If you're willing to engage in engineering fraud, overselling, etc. you can seem to be one of them pretty easily in most contexts even pushing the most outrageous crap/fraud as something it's not. I feel like ML particularly enables this. I am dealing with two of these guys now, and honestly, it's so tiring dealing with the low-cost-to-produce/high-cost-to-analyze asymmetric warfare that frauds in engineering create.
SW is too time consuming, I think, for it to really show, and tools help even things out, but I think math shows that even 100x people exist - the von Neumanns of the world. Maybe they don't exist any more, but we had a bunch of them in the 1900s and it's inarguable that they were at least 1-2 orders of magnitude above the rest.
That said, there's a ton of people in the field who now focus on image management so heavily that the numbers of _apparent_ 10x are really skewed. If you're willing to engage in engineering fraud, overselling, etc. you can seem to be one of them pretty easily in most contexts even pushing the most outrageous crap/fraud as something it's not. I feel like ML particularly enables this. I am dealing with two of these guys now, and honestly, it's so tiring dealing with the low-cost-to-produce/high-cost-to-analyze asymmetric warfare that frauds in engineering create.
What do the two guys produce that's hard to analyze?
It's a volumetric warfare. Demonstrating that their output is just a rudimentary assembly of stuff that doesn't do what they claim after the fanfare and announcement emails is much more work than it costs them to produce this stuff.
10x is often used to suggest that one only seeds a single 10x developer. This makes as much sense as the army being okay with squad made up of one 10x solider.
Yes there are 10x solders but their impact is measured by their impact on the unit. IMO this is the only sensible meaning of 10x in large scale software development.
Yes there are 10x solders but their impact is measured by their impact on the unit. IMO this is the only sensible meaning of 10x in large scale software development.
"myth" is just another ruined word.
Hard agree.
For many, I wonder if the denial stems from imposter syndrome and a lack of self-confidence in their own performance at work.
I suppose in that scenario, the idea of 10x-ers would be quite uncomfortable if I felt like everyone was referring to my output as the baseline?
For many, I wonder if the denial stems from imposter syndrome and a lack of self-confidence in their own performance at work.
I suppose in that scenario, the idea of 10x-ers would be quite uncomfortable if I felt like everyone was referring to my output as the baseline?
This is so obviously true that I laugh whenever I read the “10x software developers doesn’t exist” articles. Typically written by average developers with an axe to grind.
> Great chess players beat amateurs at least 99 times out of 100 so must also be 10x in comparison.
Absolutely. Chess is very hierarchical. I would say true amateurs will literally never beat a grandmaster, and high school champion-level (not prodigies though) can only beat a grandmaster if the grandmaster plays very weakly (vastly underestimating them, not truly playing their best, or having their guard really, really down).
Absolutely. Chess is very hierarchical. I would say true amateurs will literally never beat a grandmaster, and high school champion-level (not prodigies though) can only beat a grandmaster if the grandmaster plays very weakly (vastly underestimating them, not truly playing their best, or having their guard really, really down).
In Go, for example, for the professional ranks (1 dan through 9 dan) each rank should win 70% of their games against players from the next rank below.
> Marathon runners run 42 km in like two hours but it would take me days to finish the same distance...
This doesn't take away the core message of your post. Most marathon races are time limited for logistics reasons - to open streets to traffic. Give or take 6 hours.
This doesn't take away the core message of your post. Most marathon races are time limited for logistics reasons - to open streets to traffic. Give or take 6 hours.
10x is real but I think the more compelling question is how low a bar of competency is allowed to work in the profession - and what is the average level of competency in the programmer market.
"Certifications" doesn't get there - too easy to just game a multiple choice test. I would like to see a formal education + testing requirement (ala Doctors, just not 10 years!) Essentially, a barrier of entry for serious programmers. That would ultimately come with a high minimum salary without having to get hired at faang.
College accreditation doesn't cut it either. I work w programmers with an MS in CS. Programmers are kinda impressed. Managers could care less.
The insanely high demand for labor and (always present) priority to reduce labor costs however encourages the entry of boot-camp you're hired on the low end of experience/competence.
"Certifications" doesn't get there - too easy to just game a multiple choice test. I would like to see a formal education + testing requirement (ala Doctors, just not 10 years!) Essentially, a barrier of entry for serious programmers. That would ultimately come with a high minimum salary without having to get hired at faang.
College accreditation doesn't cut it either. I work w programmers with an MS in CS. Programmers are kinda impressed. Managers could care less.
The insanely high demand for labor and (always present) priority to reduce labor costs however encourages the entry of boot-camp you're hired on the low end of experience/competence.
I love it! Artificially constrain the labor supply with licensing. It would be incredibly lucrative for programmers. As a bonus, it would increase the prestige of our profession. Of course it would be a terrible deal for companies and quite bad for the economy.
The fact is that there are many types of applications where a high level of expertise is not needed. Eg. websites for small businesses. The client/end user doesn't care how cleanly architected or efficient or even bug-free the codebase is, and it's a better deal for management to pay some freshly-minted bootcamp grad 50k/yr to hack away than drop 6 times that on a 10xer.
The fact is that there are many types of applications where a high level of expertise is not needed. Eg. websites for small businesses. The client/end user doesn't care how cleanly architected or efficient or even bug-free the codebase is, and it's a better deal for management to pay some freshly-minted bootcamp grad 50k/yr to hack away than drop 6 times that on a 10xer.
[deleted]
Wouldn't winning 99/100 be a 100x chess player?
Depends on how much the 1x wins, and that depends on who they play, where, when, in what state of mind, with what extra resources…
They play the same games in the same time.
https://en.chessbase.com/post/carlsen-s-70-board-simul-in-ha...
Here we can see Carlsen being more than 70x as efficient as his opponents. He won 67 of them and lost 1 which is why we can't say that the 70 he faced together was as efficient as him.
https://en.chessbase.com/post/carlsen-s-70-board-simul-in-ha...
Here we can see Carlsen being more than 70x as efficient as his opponents. He won 67 of them and lost 1 which is why we can't say that the 70 he faced together was as efficient as him.
The problem is that you can't measure a developer. So you can't say someone is 10x faster or better. If you add a bench-mark like how many LOC is written per day, most will exceed at that benchmark, but the overall quality will go down.
Schrodinger's project management: developers are measurable as long as they don't know they are being measured.
You might be joking but it actually has a name:
https://en.wikipedia.org/wiki/Goodhart%27s_law
Well, your idea is probably closer to the Marilyn Strathern definition.
Well, your idea is probably closer to the Marilyn Strathern definition.
Better play it safe and commit more often.
I used to 'craft' commits but more frequent WIPs is what the people (who write the checks) want to see.
Cue the link to the story of Bill Atkinson‘s “-2000 Lines of Code”:
https://www.folklore.org/StoryView.py?story=Negative_2000_Li...
https://www.folklore.org/StoryView.py?story=Negative_2000_Li...
> So you can't say someone is 10x faster or better
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".
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".
That sounds like a senior engineer vs junior engineer experience level.
The term 10x engineer is generally used differently.
Though I guess the reason for terms like that might just be related to how many inexperienced people get senior level jobs.
The term 10x engineer is generally used differently.
Though I guess the reason for terms like that might just be related to how many inexperienced people get senior level jobs.
The comment I was replying to was "The problem is that you can't measure a developer."
You can measure. One way you measure is years of experience. Another can be time to deliver against a spec. Another can be number/size of defects. Another can be time to remedy defects.
Yes, it's "junior vs senior", but their management is explicitly stating "everyone's experience is relevant, and everyone has an equal voice" and so on. No, the person who has literally never contributed to a production codebase should not have an equal say in the technology stack choice. Their voice is not 'equal' to someone who has delivered consistently for 2 decades.
And... yes, it's largely bad management. He's looking to move. They had rocky mgt for... a year before, but it was tolerable. Leadership changed and my colleague stuck around the last few months to see if things would get better, but they're getting worse.
You can measure. One way you measure is years of experience. Another can be time to deliver against a spec. Another can be number/size of defects. Another can be time to remedy defects.
Yes, it's "junior vs senior", but their management is explicitly stating "everyone's experience is relevant, and everyone has an equal voice" and so on. No, the person who has literally never contributed to a production codebase should not have an equal say in the technology stack choice. Their voice is not 'equal' to someone who has delivered consistently for 2 decades.
And... yes, it's largely bad management. He's looking to move. They had rocky mgt for... a year before, but it was tolerable. Leadership changed and my colleague stuck around the last few months to see if things would get better, but they're getting worse.
> That sounds like a senior engineer vs junior engineer experience level.
I've actually met junior 10x engineers, I could tell pretty quickly that they were better than me. I've also met senior 1/10x engineers!
Working with a junior 10x engineer is humbling.
I remember starting out at my first job, realizing I was working with people way better than me (my first office mate had 2 PhDs, IIRC Chemistry and Physics!), but slowly I climbed up the ladder of competence and became that software engineer who was doing the Really Cool Stuff.
Then, new grad joins, and he is quite obviously a full standard deviation to the right of me.
Like, shit. Sure some architect whose name is in Wikipedia, yeah they are better than me, and I've been honored to work with multiple people of that caliber, and when you work with someone whose career is regularly described as "ground breaking", you don't even try to measure up, ya know? But, when someone fresh out of college starts pumping out better code, faster, than anything I can do, just, takes a bit of mental adjustment.
Intellectually, it shouldn't be surprising, after all if there are smarter people who are older, than there are smarter people who are younger!
The one guy I am thinking of (who might be reading this, you know who you are!) is also humble, and eager to learn from everyone around him. It was a delight working with him almost a decade ago, and his career has been great since then.
Thinking about it, I don't even know where I am on the 1-100x scale. I know people who are obvious 100x developers who are the literal one of only a few dozen people in the world who can do the things that they did. During my career I have been responsible for the success of multiple projects that would've fallen to pieces w/o me, and while I was a blatant bus factor of 1. But even then, in all those projects I worked with a group of amazing developers, we all kind of brought different 10x skills to the table, if that makes sense.
Actually, when I was the Bus Factor of 1, it wasn't for my code. The handful of 10x people on the projects were turning out much better code than I ever could. My 10x contribution? I organized, lead, and figured out what code needed to be written, designed systems, and saw the interconnections between the work the various 10x+ devs were doing. My real contribution was spotting patterns, good and bad, and using that recognition to get ahead of future problems, or to organize efforts to put code in place ahead of time in anticipation of future needs.
Heck the project I'm leading right now, it started because I saw a pattern in existing work flows and I started thinking if there was a way to optimize those workflow through better usage of data structures and automation.
Maybe I'm a 10x pattern recognizer.
I've actually met junior 10x engineers, I could tell pretty quickly that they were better than me. I've also met senior 1/10x engineers!
Working with a junior 10x engineer is humbling.
I remember starting out at my first job, realizing I was working with people way better than me (my first office mate had 2 PhDs, IIRC Chemistry and Physics!), but slowly I climbed up the ladder of competence and became that software engineer who was doing the Really Cool Stuff.
Then, new grad joins, and he is quite obviously a full standard deviation to the right of me.
Like, shit. Sure some architect whose name is in Wikipedia, yeah they are better than me, and I've been honored to work with multiple people of that caliber, and when you work with someone whose career is regularly described as "ground breaking", you don't even try to measure up, ya know? But, when someone fresh out of college starts pumping out better code, faster, than anything I can do, just, takes a bit of mental adjustment.
Intellectually, it shouldn't be surprising, after all if there are smarter people who are older, than there are smarter people who are younger!
The one guy I am thinking of (who might be reading this, you know who you are!) is also humble, and eager to learn from everyone around him. It was a delight working with him almost a decade ago, and his career has been great since then.
Thinking about it, I don't even know where I am on the 1-100x scale. I know people who are obvious 100x developers who are the literal one of only a few dozen people in the world who can do the things that they did. During my career I have been responsible for the success of multiple projects that would've fallen to pieces w/o me, and while I was a blatant bus factor of 1. But even then, in all those projects I worked with a group of amazing developers, we all kind of brought different 10x skills to the table, if that makes sense.
Actually, when I was the Bus Factor of 1, it wasn't for my code. The handful of 10x people on the projects were turning out much better code than I ever could. My 10x contribution? I organized, lead, and figured out what code needed to be written, designed systems, and saw the interconnections between the work the various 10x+ devs were doing. My real contribution was spotting patterns, good and bad, and using that recognition to get ahead of future problems, or to organize efforts to put code in place ahead of time in anticipation of future needs.
Heck the project I'm leading right now, it started because I saw a pattern in existing work flows and I started thinking if there was a way to optimize those workflow through better usage of data structures and automation.
Maybe I'm a 10x pattern recognizer.
I recommended a graduate hire once with "he failed all my questions, but he's clearly very smart". Fortunately I was right and he was great to work with, and I'd recognized that my questions had been expecting a particular curriculum.
> Thinking about it, I don't even know where I am on the 1-100x scale.
Where you are is dependent on the rest of the team, and the structure of the process. The notion of "X" times as a measurement implies a comparison to others. Posted elsewhere... I've been the slowest/least-productive on some teams, and I've been the 'rockstar/ninja/10x' on others - in one case, during the same time frame, just different teams.
Where you are is dependent on the rest of the team, and the structure of the process. The notion of "X" times as a measurement implies a comparison to others. Posted elsewhere... I've been the slowest/least-productive on some teams, and I've been the 'rockstar/ninja/10x' on others - in one case, during the same time frame, just different teams.
You can't "measure" a session musician either. And yet some of them take hundreds of dollars an hour to be there for a recording, so clearly there is a way to know
We are exposed to music so much that even someone who don't know how to play an instrument can tell the difference. So the average Joe can tell the difference in for example talent shows. Now imagine a talent show with programmers/developers, we kinda have that already with hackatons, but then it becomes more about the presentation, the actual code - if any code exist at all - is an absolute "hack".
When a measure becomes a target, it ceases to be a good measure.
Sometimes you can. At some point I worked as a consultant assisting a team that actually picked the next item from the backlog as their next task. All tasks were estimated before they were put in the backlog and assigned to someone. I would usually finish tasks in less than 30% of the esimated time, while some would use 3x+ the estimated time, and then only because they were receiving assistance a couple of hours per week.
The guy doing the estimages was evaluated based on his ability to estimate accurately, so he had to inflate the estimates beyond what would be reasonable.
This was in a country with really good job protection laws....
The guy doing the estimages was evaluated based on his ability to estimate accurately, so he had to inflate the estimates beyond what would be reasonable.
This was in a country with really good job protection laws....
Can a 10x marathon runner finish 26 miles in less than 1 hour? How about 10 minutes? There _are_ gaps between skill levels, but from personal experience, no one is substantially worse or better. We are after all just flesh and bone...
The average marathon run time is about 4.5 hours. The world record marathon run time is 2 hours.
Most people who run cannot even complete a marathon. Then there are ultramarathons.
Most people who run cannot even complete a marathon. Then there are ultramarathons.
> Then there are ultramarathons
and then there's Mauro Prosperi
and then there's Mauro Prosperi
> Can a 10x marathon runner finish 26 miles in less than 1 hour?
That’s the wrong analogy because marathon runners are already the 10x-ers of movement.
The average person could cover the distance of a marathon, but it would take them many days of walking and resting.
A marathon runner can finish a marathon in around 5 hours. That’s an order of magnitude faster than an average person, so yes, they are 10X-ers.
Most people can walk, but few people can cover so much ground so quickly. That’s the essence of the 10X designator.
The average programmer is not like the average marathon runner.
That’s the wrong analogy because marathon runners are already the 10x-ers of movement.
The average person could cover the distance of a marathon, but it would take them many days of walking and resting.
A marathon runner can finish a marathon in around 5 hours. That’s an order of magnitude faster than an average person, so yes, they are 10X-ers.
Most people can walk, but few people can cover so much ground so quickly. That’s the essence of the 10X designator.
The average programmer is not like the average marathon runner.
I think your comment inadvertently illustrates how much of this comes down to how you define the baseline. I think the comparison for a world-leading marathon runner shouldn't be someone who _never_ exercises but someone who's actually put some effort into fitness (say, an amateur runner) — yes, they're faster but it's nowhere near 10x[1] — just as our baseline for a 10x developer shouldn't be someone who's never written a line of code before but the median professional developer. It's easy to get an order of magnitude win over someone who's completely inept but once you get into more realistic territory you're chasing diminishing returns pretty hard.
The other big problem here is that you're talking about a complex skill but trying to reduce it to a single number. Tellingly, most of the 10x developer examples cited are cases where they know exactly what they want to do and have near-complete control over it, which isn't exactly how most developers work. It's really hard to quantify things like teamwork or the ability to distill what people need from what they say they need, and those are core skills for most of us in a way that optimizing a 3D engine is not.
1. I've done marathon length _hikes_ in far less than a single day, and I'm far from a hard-core athlete.
The other big problem here is that you're talking about a complex skill but trying to reduce it to a single number. Tellingly, most of the 10x developer examples cited are cases where they know exactly what they want to do and have near-complete control over it, which isn't exactly how most developers work. It's really hard to quantify things like teamwork or the ability to distill what people need from what they say they need, and those are core skills for most of us in a way that optimizing a 3D engine is not.
1. I've done marathon length _hikes_ in far less than a single day, and I'm far from a hard-core athlete.
I think it is probably much, much less harder (as a young, healthy person) to get from relatively unfit to running a marathon in 4:20 compared to getting from that 4:20 to the 2:10 that the elite marathon runners do. It's probably a lot more than 10x harder to go from 4h to 2h, I think. I gained a lot of respect for them when I realized that my gym treadmills' maximum speed (20Kph, which I have never managed to hit for any significant length of time) is less than the average speed to hit the current world record times.
That was my experience as a cyclist, too — when I was in my 20s it was relatively straightforward to get my average for a 100mph ride with modest hills into the low 20mph range, while the people in the Tour de France are sustaining greater speeds over mountains. Going from that dedicated amateur level to even the lowest pro tiers requires both significantly more effort and a fair amount of luck in terms of genetics, being able to afford that time, etc.
> The average person could cover the distance of a marathon, but it would take them many days of walking and resting.
26 miles at 3 miles an hour is a bit under 9 hours. Throw in another hour for resting and the average person should be able to walk a marathon in 10 hours. Sure they might be sore afterwards but from what I heard marathon runners also need to recover after their run.
26 miles at 3 miles an hour is a bit under 9 hours. Throw in another hour for resting and the average person should be able to walk a marathon in 10 hours. Sure they might be sore afterwards but from what I heard marathon runners also need to recover after their run.
There’s a much bigger difference in ability going from a 2:30 marathon to a 2:00 marathon than going from a 3:00 to a 2:30 marathon. It’s not linear. But it’s also not relevant to the point the OP is making.
A 10x marathoner can achieve a qualifying time for their marathon far 10x faster than the average person who might not ever be able to qualify.
When you talk about a 10x programmer, you don't expect their program to run 10x as fast. You expect 10x the results.
A 10x marathoner could post the regular marathoners best times 10x as frequently throughout the year easily. His training runs would destroy regular runners PR's. No amount of work by the regular guy would allow him to produce a single instance of comparable performance.
When you talk about a 10x programmer, you don't expect their program to run 10x as fast. You expect 10x the results.
A 10x marathoner could post the regular marathoners best times 10x as frequently throughout the year easily. His training runs would destroy regular runners PR's. No amount of work by the regular guy would allow him to produce a single instance of comparable performance.
This is annoying semantics, but sport is just as often about being very fractionally better and making a time fractionally smaller .. at the expense of huge amounts of effort. The same can apply in software too. I don't think it invalidates the metaphor as long as you can stop people interpreting "10x" to mean "there is some precise metric on which we can determine the average is a number X and this person is at least 10X".
The only reason DOOM was finished in 1997 was because John Carmack recognized himself as the 10x developer and started living in-office until the game was finished. Obviously it's important to not let silly titles distract you, but stepping up to the plate like this is how organizations get stuff done.
And while there’s nothing wrong with people choosing to do that, there’s absolutely everything wrong with organisations that expect it.
Yes!
This is how bad organisations get stuff done. Good organisations don't run into these problems in the first place because they listen to their staff and don't set arbitrary deadlines*
* I have no idea how arbitrary the deadline for Doom was. But I've seen so many devs burn themselves out meeting deadlines that were pulled out of a hat by managers because it gave them the illusion of control
This is how bad organisations get stuff done. Good organisations don't run into these problems in the first place because they listen to their staff and don't set arbitrary deadlines*
* I have no idea how arbitrary the deadline for Doom was. But I've seen so many devs burn themselves out meeting deadlines that were pulled out of a hat by managers because it gave them the illusion of control
Most real 10x's work precisely when they decide to. If they are mistreated by their employer, other stand in line to hire them.
The crunch problem mostly applies to the average-and-below developers (possibly with the exception of some devs that give up leverage vs their employer somehow, by depending on them for a visa, only consider work in a given industry, etc)
The crunch problem mostly applies to the average-and-below developers (possibly with the exception of some devs that give up leverage vs their employer somehow, by depending on them for a visa, only consider work in a given industry, etc)
I know "10x engineers" exist; some people are fakes and put forward things that look like they have high impact but are actually a bit shoddy.
Some people like to be present and suck up.
But some people really do just work hard, smart and have deep passion for what they're doing- and importantly: pride, which makes the quality of the content great too.
Some of the best engineers I know "visit" bits of code or infrastructure and afterwards it's a pleasure to use and rarely if ever has weird bugs, and if they do have bugs they're easy to root out.
What I'm trying to say is: high performers exist. But your organisation shouldn't be resting on the shoulders of those people.
People leave. If your 10x (or 3x or 5x) engineer quits: are you really going to hire 3,5 or 10 people to replace them? Unlikely. And even if you do, institutional knowledge is lost.
It's not a myth they exist, but you shouldn't depend on them.
Some people like to be present and suck up.
But some people really do just work hard, smart and have deep passion for what they're doing- and importantly: pride, which makes the quality of the content great too.
Some of the best engineers I know "visit" bits of code or infrastructure and afterwards it's a pleasure to use and rarely if ever has weird bugs, and if they do have bugs they're easy to root out.
What I'm trying to say is: high performers exist. But your organisation shouldn't be resting on the shoulders of those people.
People leave. If your 10x (or 3x or 5x) engineer quits: are you really going to hire 3,5 or 10 people to replace them? Unlikely. And even if you do, institutional knowledge is lost.
It's not a myth they exist, but you shouldn't depend on them.
If we're taking about is just output on a larger macro scale, then yes, hiring enough people will replace 10x engineers.
But some things i think you won't be able to replace --
You won't be able to replace speed on short-term projects. Lots of people means lots of communication overhead, which really kills fast responsive speed. If you value time to answer, you'd prefer a small team of really smart people instead of a large team of average people.
You won't be able to replace the insights. Tasks and knowledge are distributed amongst many individuals in bite-size chunks, so you miss out on insights you only get when someone holds everything in their head at once.
You won't be able to have a small team / small company culture anymore. You have to be large, standardized, bureaucratic, catering to the least common denominator. And then make up for it with volume.
But some things i think you won't be able to replace --
You won't be able to replace speed on short-term projects. Lots of people means lots of communication overhead, which really kills fast responsive speed. If you value time to answer, you'd prefer a small team of really smart people instead of a large team of average people.
You won't be able to replace the insights. Tasks and knowledge are distributed amongst many individuals in bite-size chunks, so you miss out on insights you only get when someone holds everything in their head at once.
You won't be able to have a small team / small company culture anymore. You have to be large, standardized, bureaucratic, catering to the least common denominator. And then make up for it with volume.
Just to give a concrete example: no amount of software engineers can be hired to produce comparable work of an expert cartoonist except by dumb luck. Throwing 1000 engineers won’t solve the problem.
I imagine within the tech world there are tasks that are ill defined and a small subset of engineers can solve, but a typical engineer may not have the background to solve it.
I imagine within the tech world there are tasks that are ill defined and a small subset of engineers can solve, but a typical engineer may not have the background to solve it.
>no amount of software engineers can be hired to produce comparable work of an expert cartoonist except by dumb luck.
You actually hit this nail quite on the head with the example. The "10x engineers" get a lot of their "10x"-ness from creativity - most I've met are cartoonists, painters, musicians, writers, cooks - artists in general that love software as a way of expressing themselves and earning good money. The beautiful bits of code you get after are usually there because the starting point is "create it" not "implement existing solution/pattern".
You actually hit this nail quite on the head with the example. The "10x engineers" get a lot of their "10x"-ness from creativity - most I've met are cartoonists, painters, musicians, writers, cooks - artists in general that love software as a way of expressing themselves and earning good money. The beautiful bits of code you get after are usually there because the starting point is "create it" not "implement existing solution/pattern".
I generally consider myself a 5x coder... I usually spend about 1/3 the day reading/learning and another 1/3 experimenting... only about 1/3 of a typical day will I be on-task, and usually still outpace my peers. This last 2-week cycle, I literally did all the assigned work, and refactored a few things that annoyed me in one caffeine fueled night.
I used to do design/graphix/ux work... that always interested me. Programming pays better, and I have a talent for it. I have spent time learning patterns, etc, but not through a formal education. I tend to just see a good way forward... creating discoverable code along the way. I find a lot of the time, the formal patterns tend to just make things more complicated than they need to be.
Just my own take on things. I'm kind of lazy in a good way. I have spurts where I will do a crazy amount in a short time, and those where I'm closer to coasting. Like many/most creative types, it varies.
I used to do design/graphix/ux work... that always interested me. Programming pays better, and I have a talent for it. I have spent time learning patterns, etc, but not through a formal education. I tend to just see a good way forward... creating discoverable code along the way. I find a lot of the time, the formal patterns tend to just make things more complicated than they need to be.
Just my own take on things. I'm kind of lazy in a good way. I have spurts where I will do a crazy amount in a short time, and those where I'm closer to coasting. Like many/most creative types, it varies.
This has helped me to understand this very problem (which I didn’t really know had a name)
Uh, you left out passionate lego builders (AFOL). I’m adding it for you.
> hiring enough people will replace 10x engineers
The math is not that simple. The output of a Junior engineer is much different from that of a Senior engineer. You can hire any number of Junior engineers you want, and they won't have the vision and seasoned experience of a Senior engineer for producing higher quality code with less technical debt.
Even among Senior engineers there are different grades of experience/competence/capability.
The math is not that simple. The output of a Junior engineer is much different from that of a Senior engineer. You can hire any number of Junior engineers you want, and they won't have the vision and seasoned experience of a Senior engineer for producing higher quality code with less technical debt.
Even among Senior engineers there are different grades of experience/competence/capability.
I think its important to understand there are also relatively high floors to getting certain things done well. If the engineer is too junior or simply not good enough, its not that you will get there slower, its that you may not get there at all. Or you get there slowly and with a very buggy or unmaintainable mess. Some engineers can even go backwards in that sense, attempting to optimize the wrong solution and spending months on something that in honesty can't actually be completed.
Cue the link to Mythical Man Month:
central theme is that "adding manpower to a late software project makes it later."
https://en.wikipedia.org/wiki/The_Mythical_Man-Month
central theme is that "adding manpower to a late software project makes it later."
https://en.wikipedia.org/wiki/The_Mythical_Man-Month
I've had junior engineers outperforming senior engineers, even counting the hours I had to spend correcting and guiding.
Some engineers are just slow. I don't think it's much correlated with experience. If your goal was never to be a super productive programmer, I don't think you'll ever become one.
This might also be why there is this spectre of agism in the industry. Everyone knows there's greybeards out there that would eat your lunch and get paid the big bucks, but at the same time older programmers have hard times interviewing. At that age most of the really great programmers have probably already been fished out of the pond.
Some engineers are just slow. I don't think it's much correlated with experience. If your goal was never to be a super productive programmer, I don't think you'll ever become one.
This might also be why there is this spectre of agism in the industry. Everyone knows there's greybeards out there that would eat your lunch and get paid the big bucks, but at the same time older programmers have hard times interviewing. At that age most of the really great programmers have probably already been fished out of the pond.
I think it depends... where I am now (third from last day), I'm one of the younger devs at 46yo. which is wild to me... about 2/4 of those here older than me have little interest in taking on new approaches or techniques. The other 1/4 absolutely work to stay current. Some are coasting to retirement, others of us don't ever plan to stop.
I will say, my recent stint of interviews over the past 6 weeks or so has been pretty painful. Everyone seems to be going through 6+ interview stages. The reality, even then, I'm not sure they're getting a great signal:noise outcome. Some of the tests are for things that will never be used for those jobs on any given day.
I do miss my 20's when an interview was maybe an hour and a half on an afternoon, and an offer shortly after.
I will say, my recent stint of interviews over the past 6 weeks or so has been pretty painful. Everyone seems to be going through 6+ interview stages. The reality, even then, I'm not sure they're getting a great signal:noise outcome. Some of the tests are for things that will never be used for those jobs on any given day.
I do miss my 20's when an interview was maybe an hour and a half on an afternoon, and an offer shortly after.
It's crazy, I wonder if it actually works and they actually get a higher percentage of good coders. I just do a face to face, then a take home assignment, then another face to face where we discuss the take home, and then I immediately make the decision. I skip the take home if they've got impressive GitHub accounts or other clear public displays of skill.
The issue I seem to often see, for some reason, is that people who have a say in hiring often don't realize themselves that the great engineer did something quickly thanks to an insight, or, more generally speaking, thanks to being very good, or being able to turn the problem on its head, as opposed to pure brute force.
They often seem to have the idea that it's more or less grunt work. Yeah, if a truck will haul 10 tonnes in one go, you'll get the same time if you hire an army of people, each carrying 10 kg on their backs, give or take economies of scale.
They often seem to have the idea that it's more or less grunt work. Yeah, if a truck will haul 10 tonnes in one go, you'll get the same time if you hire an army of people, each carrying 10 kg on their backs, give or take economies of scale.
There is a flip side to that as well I think. One 10x developer can be more productive than 10 developers, but often 10 10x developers cannot be as productive as 100 developers. Certain things just don't "scale out" with the sort of creative advantages that highly productive engineers use.
Overly complex code is more difficult to modify than elegant simple code. A 10x developer will produce simple elegant code. That is one reason why they are a 10x developer. Ten 10x developers will create a much more simple solution than 100 standard developers. Standard developers usually create a mess. That is what always happens, we have all seen it. So 10 10x will be much more productive than 100 standard developers.
Speed an accuracy are on different dimensions that are somewhat independent.
Another consideration is how much time we can afford for the solution to be wrong and need to be tweaked. For anything that has to work the first time, you want one (two, really) of your more sober and likely expensive engineers on the case, even if they aren't your fastest.
You may or may be able to replace your 10x engineer for this kind of work, but you're likely to be hamstrung by your interview processes.
Another consideration is how much time we can afford for the solution to be wrong and need to be tweaked. For anything that has to work the first time, you want one (two, really) of your more sober and likely expensive engineers on the case, even if they aren't your fastest.
You may or may be able to replace your 10x engineer for this kind of work, but you're likely to be hamstrung by your interview processes.
I've worked with a few developers who are great - people who get bored of waiting so just build it themselves one evening whilst everybody's arguing over funding/recruiting the team we thought was needed.
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.
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.
Oof, sadly this sounds like me... It's hard to delegate, and even harder to trust that it's done correctly. I know this will be my undoing someday, it also drives me insane because it puts extra pressure on myself...
Any suggestions? (Short of let people do it).
Any suggestions? (Short of let people do it).
Start small and practice. Evaluate how people react to the task size and experiment from there. E.g. don't make someone annoyed by tasks way under their stature grow at the same rate as someone who struggles to deliver.
This goes for clarity, difficulty and size of the task. Don't make someone bad at filling the details do an unclear task. Don't make someone unskilled do a clear yet difficult task. Don't make someone with no track record work on a task for too many days without supervision. Etc.
Unfortunately, people not meeting standards you would will always be a thing unless you're leading people more skilled in the area of expertise. Which brings it's own set of issues.
This goes for clarity, difficulty and size of the task. Don't make someone bad at filling the details do an unclear task. Don't make someone unskilled do a clear yet difficult task. Don't make someone with no track record work on a task for too many days without supervision. Etc.
Unfortunately, people not meeting standards you would will always be a thing unless you're leading people more skilled in the area of expertise. Which brings it's own set of issues.
Realize that others are at other points in their lives. That just because the code does not look the exact way you would write it does not mean it is not bad/wrong. There is always one more refactor to do. There is always more bug. Worry about what you can do. Help others when they need it (not when you want to, this is tricky to not become the knowitall guy).
Delegating is knowing that you need to let go and ingest the fact that they are there to help. Mistakes happen and will happen. But that is part of learning for you and them. If they are not learning that is a different issue. Do not worry about it. You will learn what you can put them on better. But once they learn something they can turn around and help you learn. They can take care of it and you do not have to worry. Delegation is trust. Learning to trust is learning to 'let go' and being open to being 'hurt'. But also being willing to forgive and forget.
Delegating is knowing that you need to let go and ingest the fact that they are there to help. Mistakes happen and will happen. But that is part of learning for you and them. If they are not learning that is a different issue. Do not worry about it. You will learn what you can put them on better. But once they learn something they can turn around and help you learn. They can take care of it and you do not have to worry. Delegation is trust. Learning to trust is learning to 'let go' and being open to being 'hurt'. But also being willing to forgive and forget.
I'm not a developer, so maybe not the best person to ask.
What seems to work is where areas of the product are assigned to specific teams - the overly-attached dev can at least see what's happening, provide guidance, without having to do the work, point to wiki that needs updating etc. Over time they'll build trust and can back away a bit.
What doesn't work is if work is given to a different team who just do their own thing and the 'parent dev' only finds what's happened to their baby on the commit/demo. Even if they've done a great job, it ruffles feathers.
What seems to work is where areas of the product are assigned to specific teams - the overly-attached dev can at least see what's happening, provide guidance, without having to do the work, point to wiki that needs updating etc. Over time they'll build trust and can back away a bit.
What doesn't work is if work is given to a different team who just do their own thing and the 'parent dev' only finds what's happened to their baby on the commit/demo. Even if they've done a great job, it ruffles feathers.
Try another career. You'll never be successful in this one. Sorry its harsh but that's the way it is.
Unless you can change that trait, it's going to be a hell of a bumpy road with no payoff.
Unless you can change that trait, it's going to be a hell of a bumpy road with no payoff.
[deleted]
On the flipside, I've met "10x engineers" who always prioritized working on highly visible and strategic new features, and excelled at shipping them as fast as possible, even if it meant racking up massive technical debt. By doing this, they effectively did produce 10x as much in the eyes of management, and got promoted and rewarded in kind. The technical debt they racked up then got paid by everyone else that had to go in and make their prototype maintainable while they were already off to the next high-profile project. Not only did they not have to stay and cover the cheques they wrote, they also managed to lower the effectiveness of everyone else, lowering the baseline they got compared against, so they could be 10x instead of just 5x.
> On the flipside, I've met "10x engineers" who always prioritized working on highly visible and strategic new features, and excelled at shipping them as fast as possible, even if it meant racking up massive technical debt.
I start my comment with an intent to indicate that these people are not what is meant when people say 10x. (maybe it's what some people think of when lambasting "10x" developers).
If you think you're a 10x engineer: you're not, you wouldn't see yourself as better, you'd see yourself as passionate.
I start my comment with an intent to indicate that these people are not what is meant when people say 10x. (maybe it's what some people think of when lambasting "10x" developers).
If you think you're a 10x engineer: you're not, you wouldn't see yourself as better, you'd see yourself as passionate.
[deleted]
I have the opposite issue here. I have an engineer still writing VB6 code and we have 20 man years of his technical debt we have to live with. He never learned anything new and he has a hammer and everything is a nail.
As a >5x engineer I generally build out the initial design/development of a project and then hand it off to a team member to maintain. I get involved only when there is a new significant feature that needs to be added.
As a >5x engineer I generally build out the initial design/development of a project and then hand it off to a team member to maintain. I get involved only when there is a new significant feature that needs to be added.
That’s right, the mythical 10x-er who does greenfield work, uses the latest tech, who not only never maintains their masterpieces but moves on to other pastures causing other devs loss of productivity and captive to their mazes..
On the plus side, the company shipped something. In a startup time to market is important. Especially in a startup.
Though, the order of events might be backwards there sometimes.
The director has a highly visible and strategic new feature they need executed, so they'll handpick the best engineers to work on the project. The engineers complete the project as fast as possible because that was the point of the project, to get the team that could produce a MVP fastest. And the technical debt and productionizing of the project is something that can be done by a less specialized pool of developers, who also are given way less tight time constraints.
Their value is in shipping fast.
If competitors are working on the same feature and manage to roll it out of the door first, that spells trouble.
First version of Twitter was an almost complete re-write because of performance issues. But since their concept was dead simple, they had to get market shares fast else someone else was going to be there first.
If competitors are working on the same feature and manage to roll it out of the door first, that spells trouble.
First version of Twitter was an almost complete re-write because of performance issues. But since their concept was dead simple, they had to get market shares fast else someone else was going to be there first.
> It's not a myth they exist, but you shouldn't depend on them.
It's hard to tell if it's arrogance or reluctance to admit some people are more valuable than others and just allow them to get to a point they prefer to leave than stay.
Domain knowledge, institutional knowledge, whatever you wanna call it, takes time to acquire and these kinds of companies are equally reluctant/arrogant to spend enough to hire properly. That's not enough to kill them mind you, not right away anyway, so they are destined to be mediocre at best I suppose.
It's hard to tell if it's arrogance or reluctance to admit some people are more valuable than others and just allow them to get to a point they prefer to leave than stay.
Domain knowledge, institutional knowledge, whatever you wanna call it, takes time to acquire and these kinds of companies are equally reluctant/arrogant to spend enough to hire properly. That's not enough to kill them mind you, not right away anyway, so they are destined to be mediocre at best I suppose.
> It's hard to tell if it's arrogance or reluctance to admit some people are more valuable than others and just allow them to get to a point they prefer to leave than stay.
Stating that a developer is worth 10 times what other developers are worth goes way beyond saying that some people are more valuable than others.
We're not talking about junior/medior/senior distinctions. We're talking about 10x. The myths. The lone gunman who is supposedly so good that is able to replace entire teams and still outproduce them.
Stating that a developer is worth 10 times what other developers are worth goes way beyond saying that some people are more valuable than others.
We're not talking about junior/medior/senior distinctions. We're talking about 10x. The myths. The lone gunman who is supposedly so good that is able to replace entire teams and still outproduce them.
A really good developer can and will absolutely outpace a couple small teams of developers. The shortcomings is the domain knowledge is locked in one head. You gain and lose a lot depending on how many people are involved and how much you have to communicate.
Not having a backup solution is probably the single biggest shortcoming of the lone gunman in practice. The second is that the code is often not laid out or structured so that a team can work on it.
Not having a backup solution is probably the single biggest shortcoming of the lone gunman in practice. The second is that the code is often not laid out or structured so that a team can work on it.
As the MapReduce example shows, the domain knowledge is not necessarily locked in one head in cases like this. I haven't heard complaints from Googlers about how Jeff and Sanjay write unmaintainable code, either. My own non-Google experience is that extremely productive programmers tend to write code that's more readable, not less readable.
MapReduce. Leveraging lower level abstractions incipient in the early Google datacenter (distributed FS, distributed process executor) and providing a simple but expressive programming model for distributed large scale batch computations. A significant amount of effort went into documenting and exemplifying the usage of the programming model for a large number of use-cases. Chosen to serve thousands of use-cases all across a fast growing company. Developed by 2 people. A fantastic example of '10[00]x engineering', and yet I can't imagine something more antithetic to the 'lone gunman' strawman.
I think Jeff + Sanjay is arguably a better example of 100x developers. Goes way beyond just MapReduce.
Edit: I just noticed that you said the same yourself. Great minds...
Edit: I just noticed that you said the same yourself. Great minds...
One of the hard lessons I've learned in software is that force of will can make any development or management process work for a little over 12 months before the cracks really start to show. By then people (and by people I mean folks who don't think the way I do) have cemented that process in their heads as working and they want to ignore the data that says it doesn't.
If you are up or out as a manager, then any changes you didn't make right at the beginning of your tenure are going to unravel under the watch of your replacement. You not only don't have to reflect on them, but lots of people nominate someone else as the person who needs to fix it/take the blame. If there's a better recipe for willful ignorance, I don't know what it is, and I'm pretty sure I wouldn't want to.
If you are up or out as a manager, then any changes you didn't make right at the beginning of your tenure are going to unravel under the watch of your replacement. You not only don't have to reflect on them, but lots of people nominate someone else as the person who needs to fix it/take the blame. If there's a better recipe for willful ignorance, I don't know what it is, and I'm pretty sure I wouldn't want to.
“Adding people to a late project makes it later”. Equally, replacing high performers with multiple people wouldn't work most of the time.
Yea funnily enough I just added a comment along these lines about restaurants in a different story. Just because an engineer is 10x better in some sense that another one, it doesn't meant that 10 of the lower quality engineers will make up for it, just as eating 10 times at McDonald's isn't going to be as much fun as eating once at a great restaurant (for most people)
I'm a good cook, but compared to Wolfgang Puck, I make shit on a shingle look brilliant. You could hire 100's of me and not get a decent restaurant. After so many decades as a programmer, there are enormous gaps between programmers in their ability to deliver quality. Calling something 10x is not a measurable quantity, but watching quality delivery over and over gives you the impression; the number is arbitrary.
But, I think, you should consider that it's 10x at McDonald's vs 1x at a good restaurant and 9 days eating nothing at all.
Yes, this is obviously just considering utility at a higher level of the hierarchy of needs, not pure subsistence. Otherwise everyone should just be slurping Soylent all the time I guess.
only if you think that any organization that hires a 10X engineer doesn't hire any 1X engineers.
Are we sure they're not actually the exact same problem?
Hypothesis: the "10x" developer does not actually have 10x the output of a single average developer, but rather the same output as 10 average developers working together (and having much of their productivity eaten up by coordination overhead).
Hypothesis: the "10x" developer does not actually have 10x the output of a single average developer, but rather the same output as 10 average developers working together (and having much of their productivity eaten up by coordination overhead).
That is a good point... and gets back to the chief programmer of the MMM surgical team.
One of the aspects of having a chief programmer (and there's another HN article making the rounds on heroes for projects) is that they're able to conceptualize/structure/design an entire application or module.
A chief programmer, doing a "this is how we're doing it" and with all the parts in their head and working to that end will have better overall "idea to deploy" performance than someone who is given the task of "do X" and may have to come back to it again to reconcile their implementation of X with the design of the system and its goals.
The way to resolve that is to get everyone who is working on it on the same page for the design... and that takes meetings leading to the issues with adding more people to a project will make it later.
One of the aspects of having a chief programmer (and there's another HN article making the rounds on heroes for projects) is that they're able to conceptualize/structure/design an entire application or module.
A chief programmer, doing a "this is how we're doing it" and with all the parts in their head and working to that end will have better overall "idea to deploy" performance than someone who is given the task of "do X" and may have to come back to it again to reconcile their implementation of X with the design of the system and its goals.
The way to resolve that is to get everyone who is working on it on the same page for the design... and that takes meetings leading to the issues with adding more people to a project will make it later.
More people means more human error, which means that not only do you have to invest more in communication overhead, but you have to invest more in sanity checks to keep your state machine in bounds.
The original author always knows not to push buttons in this order. Two people who are communicating badly will find a way to do so sooner or later, and if the system doesn't slap you on the wrist for doing so, it's gonna be a bad day.
On the plus side, systems with these sorts of guard rails are better opportunities for self-directed mid-level developers to pull themselves up to a senior role. One man bands are notoriously awful at affordances for discoverability.
I think I do better than most but any time I want to shed a responsibility I always have to first add more docs and a handful of extra exceptions and/or exception handlers to the code to make sure the new person doesn't immediately have a bad experience and toss it back to me. I call it sweetening the pot but others might use a different description.
The original author always knows not to push buttons in this order. Two people who are communicating badly will find a way to do so sooner or later, and if the system doesn't slap you on the wrist for doing so, it's gonna be a bad day.
On the plus side, systems with these sorts of guard rails are better opportunities for self-directed mid-level developers to pull themselves up to a senior role. One man bands are notoriously awful at affordances for discoverability.
I think I do better than most but any time I want to shed a responsibility I always have to first add more docs and a handful of extra exceptions and/or exception handlers to the code to make sure the new person doesn't immediately have a bad experience and toss it back to me. I call it sweetening the pot but others might use a different description.
Author here. There definitely are people, who perform better than others, even when the environment is not built to favor them and hinder others from performing well.
If we believe that the talent within a field follows the power law, as suggested by this study (http://www.hermanaguinis.com/PPsych2012.pdf) it means that only 20% people in the field are high-perfomers, and something like less than 5% exceptionally high performers. When you look it from the perspective of scaling an organization it means that getting these people to your company will be very hard. 80% of companies are hiring within the "average or below average" section. The truly high-performing people, who are passionate about their craft are very likely to move to companies that are at the at the top of XYZ, where XYZ is the topic within software engineering that they're especially passionate about, pay well, etc.
There was originally a section the article that tried to highlight "statistics", but I eventually left it out, because I did not find a good place for it:
"Statistically speaking, it is much easier to create a "10x engineer" by creating an organization, where most people perform poorly than actually hire and retain someone, who really is 10x better at software engineering than an average person."
In hindsight, I think there are a few things that could have been emphasized more, so the thrust of the blog post would have been clearer:
- The title could have been better frased around the topic.
- The context is companies that are growing fast and need to scale.
- You likely have a company full of close-to-average people.
If we believe that the talent within a field follows the power law, as suggested by this study (http://www.hermanaguinis.com/PPsych2012.pdf) it means that only 20% people in the field are high-perfomers, and something like less than 5% exceptionally high performers. When you look it from the perspective of scaling an organization it means that getting these people to your company will be very hard. 80% of companies are hiring within the "average or below average" section. The truly high-performing people, who are passionate about their craft are very likely to move to companies that are at the at the top of XYZ, where XYZ is the topic within software engineering that they're especially passionate about, pay well, etc.
There was originally a section the article that tried to highlight "statistics", but I eventually left it out, because I did not find a good place for it:
"Statistically speaking, it is much easier to create a "10x engineer" by creating an organization, where most people perform poorly than actually hire and retain someone, who really is 10x better at software engineering than an average person."
In hindsight, I think there are a few things that could have been emphasized more, so the thrust of the blog post would have been clearer:
- The title could have been better frased around the topic.
- The context is companies that are growing fast and need to scale.
- You likely have a company full of close-to-average people.
”The truly high-performing people, who are passionate about their craft are very likely to move to companies that are at the at the top of XYZ, where XYZ is the topic within software engineering that they're especially passionate about, pay well, etc.”
Is there a source for this claim?
How likely are they to move exactly, and what motivates the non-movers to stay?
Is there a source for this claim?
How likely are they to move exactly, and what motivates the non-movers to stay?
This is based on my limited personal experience observing the careers of people I know, whom I could consider somehow exceptionally good at their craft. I co-led the CTO team of software consultancy with 350+ devs. In that role it was pretty clear that it was really hard to compete on salary and how interesting projects experts could be offered.
Motivations differ based on what the person values. The top motivations I've experienced are:
- Money
- Following intrinsic motivation and being able to grow professionally
- Friendships and the feeling of belonging
- Stability and not taking any risks
The people in the last two categories tend to change jobs more slowly in my experience, but most still do it at some point.
I'm not aware of any reliable studies on the subject from the field of software engineering. If someone knows one, I would be more than interested in reading one.
Motivations differ based on what the person values. The top motivations I've experienced are:
- Money
- Following intrinsic motivation and being able to grow professionally
- Friendships and the feeling of belonging
- Stability and not taking any risks
The people in the last two categories tend to change jobs more slowly in my experience, but most still do it at some point.
I'm not aware of any reliable studies on the subject from the field of software engineering. If someone knows one, I would be more than interested in reading one.
I would probably consider consultancies very differently from product companies.
Since the company charges a per-person rate on hours worked, all it needs is to charge more than you pay them (plus utilization). So it's a very viable business model for the company to hire the cheapest (so either least skilled or least experienced) developers, as long as you have enough projects where you can charge for them. Maximizing engineering skill is not profitable, maximizing the diff in pay * the number of hours worked is what is most profitable.
I would argue that consultancies are probably the worst type of company for attracting talent. If we consider the idea that an engineer becomes skilled enough that they now have to power to choose which projects best interest them, then choosing the company is analogous to choosing that next project. If they join a consultancy, they specifically lose that power. Since, you're not signing up for a single company and single project, you're signing up for every single client in that company's portfolio.
Personally speaking, if I was to run a consultancy and cared about the quality of the developers, the only choice is to hire exclusively new grads out of college. That's when there is the greatest diff between the pay they can command and the potential skill level they have, since that skill level is unknown. You can then exploit that gap for a number of years, until they realize how good they are and can command a high enough salary from a different company (most likely a product company) that has the margins to be able to pay ridiculous salaries and not blink an eye.
Since the company charges a per-person rate on hours worked, all it needs is to charge more than you pay them (plus utilization). So it's a very viable business model for the company to hire the cheapest (so either least skilled or least experienced) developers, as long as you have enough projects where you can charge for them. Maximizing engineering skill is not profitable, maximizing the diff in pay * the number of hours worked is what is most profitable.
I would argue that consultancies are probably the worst type of company for attracting talent. If we consider the idea that an engineer becomes skilled enough that they now have to power to choose which projects best interest them, then choosing the company is analogous to choosing that next project. If they join a consultancy, they specifically lose that power. Since, you're not signing up for a single company and single project, you're signing up for every single client in that company's portfolio.
Personally speaking, if I was to run a consultancy and cared about the quality of the developers, the only choice is to hire exclusively new grads out of college. That's when there is the greatest diff between the pay they can command and the potential skill level they have, since that skill level is unknown. You can then exploit that gap for a number of years, until they realize how good they are and can command a high enough salary from a different company (most likely a product company) that has the margins to be able to pay ridiculous salaries and not blink an eye.
In my experience the difference between good consultancies and average product companies is not very big. On average I've seen consultancies being able to attract more technically curious and product-minded engineers. The exception are the product companies that are somehow special in the market (e.g. can offer a significantly better pay, or do something very interesting in terms of scale or technologies).
The dynamic you describe tends to get stronger, when consultancies grow. The voices & competence of the technical people becomes less important when it comes to the business and efficiencies in utilization and the company brand start to matter more. The consultancy I worked at was not an incumbent, but an underdog competing with the big players, so the actual execution mattered more, when trying to win bigger customers. Even in consultancies, there are operational effiencies you get from having competent people. Mainly from having less middle management & account managers.
However, there things are useful for the consultancy's business only to a limited extend. You only need to be slightly better than the average consultancy and you're OK. So there is a point, when you either need to be great at sales or thought-leadering, or a consultancy can no longer increase your salary or provide your with work you find interesting.
The dynamic you describe tends to get stronger, when consultancies grow. The voices & competence of the technical people becomes less important when it comes to the business and efficiencies in utilization and the company brand start to matter more. The consultancy I worked at was not an incumbent, but an underdog competing with the big players, so the actual execution mattered more, when trying to win bigger customers. Even in consultancies, there are operational effiencies you get from having competent people. Mainly from having less middle management & account managers.
However, there things are useful for the consultancy's business only to a limited extend. You only need to be slightly better than the average consultancy and you're OK. So there is a point, when you either need to be great at sales or thought-leadering, or a consultancy can no longer increase your salary or provide your with work you find interesting.
Interesting on that first point, that's not what i would have expected. So what are you seeing from these product-minded engineers that leads them to choose a consultancy over a product company?
For "underdog" consultancies, i've always felt that they win by
1) sending their A team where an incumbent would be sending in their C team. That would make sense, as the incumbent's A team is on a more important client, whereas this small client "is" the underdog's important client.
2) carving out niches and specialties. So you serve less clients and projects, but also build up a reputation. You kind of become an incumbent of sorts, just for that niche.
For "underdog" consultancies, i've always felt that they win by
1) sending their A team where an incumbent would be sending in their C team. That would make sense, as the incumbent's A team is on a more important client, whereas this small client "is" the underdog's important client.
2) carving out niches and specialties. So you serve less clients and projects, but also build up a reputation. You kind of become an incumbent of sorts, just for that niche.
Both 1 & 2 are valid strategies for underdog consultancies. Consultancies that are very good at #2 may also have better ability to keep people, who are exceptionally good at some specific tech or domain, because they usually have higher rates and peers that are good at the same thing.
As for product-minded engineers, there is often more freedom at a smaller a consultancy than in (many) product companies. You can switch projects every 3-18 months, select a new technology you want to learn, have big ownership on the helping the customer building the product, etc. To some people this is ofc a downside and a lot depends on the kind of client/project you're working in. Much of this also is lost, when the consultancy starts taking on bigger projects with bigger clients that already have much of these things set in stone.
As for product-minded engineers, there is often more freedom at a smaller a consultancy than in (many) product companies. You can switch projects every 3-18 months, select a new technology you want to learn, have big ownership on the helping the customer building the product, etc. To some people this is ofc a downside and a lot depends on the kind of client/project you're working in. Much of this also is lost, when the consultancy starts taking on bigger projects with bigger clients that already have much of these things set in stone.
If a brittle piece of JS (with high support cost due to runtime errors) is replaced with a piece of Elm, the runtime errors are gone.
The one that made the decision to change it, and actually ported the code, easily wins the 10x badge when we consider the high support cost of that brittle piece of JS code in production.
> institutional knowledge is lost.
Exactly! Say a dev rewrote the brittle piece of JS to resilient JS, and did this REALLY fast. Great, you may have a 10x'er on your team! But in this case the knowledge is merely with one guy, he has the experience and discipline to write resilient JS: something rarely found in human beings. In this case the 10x'er may be a 10x coder, but not a 10x architect/techlead/CTO.
Hence I dont like to depend on human's experience and discipline, but prefer to fix it with Real Good Tech and Tooling(TM).
The one that made the decision to change it, and actually ported the code, easily wins the 10x badge when we consider the high support cost of that brittle piece of JS code in production.
> institutional knowledge is lost.
Exactly! Say a dev rewrote the brittle piece of JS to resilient JS, and did this REALLY fast. Great, you may have a 10x'er on your team! But in this case the knowledge is merely with one guy, he has the experience and discipline to write resilient JS: something rarely found in human beings. In this case the 10x'er may be a 10x coder, but not a 10x architect/techlead/CTO.
Hence I dont like to depend on human's experience and discipline, but prefer to fix it with Real Good Tech and Tooling(TM).
Someone who thinks all bugs will go away if the code is just rewritten in the hipster niche language de-jour, is probably a 0.1x developer. They may work hard but don't solve any real problems for the business and leave a mess to future maintainers who have to spend time debugging the forgotten hipster languages of yesteryear.
Do you think the developers who rewrote everything in Dart or CoffeeScript a few years ago were actual 10x productive for the business in the long run?
Do you think the developers who rewrote everything in Dart or CoffeeScript a few years ago were actual 10x productive for the business in the long run?
They specifically said runtime errors. Elm is designed in such a way that runtime errors do not occur. Obviously logic errors etc. are still possible.
So what happens if you divide by 0 in Elm?
For integer division, you get 0 as a result. For floats, it is the Infinity value used by standard implementations.
The integer solution is not great, but is mathematically consistent despite what many believe (it’s true in most proof assistants, for example).
The integer solution is not great, but is mathematically consistent despite what many believe (it’s true in most proof assistants, for example).
You claim something is "hipster" without having any clue whats it about. May I say the word hipster means nothing. It could mean popular: but Elm is not popular.
Maybe time to study some of that "hipster stuff".
I'd say Elm was very interesting to learn. I gained some programming wisdom from writing stuff in Elm (and in a previous experiment, Haskell).
Maybe time to study some of that "hipster stuff".
I'd say Elm was very interesting to learn. I gained some programming wisdom from writing stuff in Elm (and in a previous experiment, Haskell).
I'm not knocking Elm at all, I think it is a very interesting language.
I'm saying it is not very productive to rewrite a buggy and brittle JavaScript app in another language because you think that will make the errors go away.
A productive developer would figure out why the code is buggy and brittle and fix the root cause. If you don't understand the root cause, the same or similar bugs will surely show up in a rewrite.
If you do the rewrite as a learning exercise or CV building, great for you! But probably not for the business.
I'm saying it is not very productive to rewrite a buggy and brittle JavaScript app in another language because you think that will make the errors go away.
A productive developer would figure out why the code is buggy and brittle and fix the root cause. If you don't understand the root cause, the same or similar bugs will surely show up in a rewrite.
If you do the rewrite as a learning exercise or CV building, great for you! But probably not for the business.
It’s just an objective fact that an Elm rewrite eliminates all runtime errors. Turing complete languages aren’t required to have ways of panicking at runtime, it’s a choice language designers make.
No. Exceptions and errors are different things. An error is when something goes wrong due to a bug or unexpected condition. An exception is a signal in the runtime when an error condition have been detected. If an error does not generate a signal (like an exception or panic) then we call it an logical error. Logical errors are generally worse than errors which cause exceptions, since they may go undiscovered longer and are harder to debug.
Take divide by zero. Dividing by zero is an error so there must be a bug or insufficient validation in the code if it happens. Some languages throw an exception if you divide by zero. You immediately know where something went wrong, and the program does not continue with invalid data.
JavaScript does not throw an error but returns Infinity. So you don't discover the bug immediately, but at least the final output will be clearly invalid since arithmetic operations on Infinity will yield Infinity or NaN.
Apparently in Elm, dividing an integer by zero results in zero. So not only will the program continue with invalid data, it will not even be clear that the result is invalid. The error is still there, but instead of a runtime exception you have an extremely insidious logical error which you might never know is there.
Lets say you have a banking app and the user can take out a loan. The user select the size of loan and the number of months for paying back, and the app calculate the monthly installments by division. But you forgot to validate the input to disallow 0! So the user selects 0 months. A Python app would throw an exception here. Unfortunate, but no harm done. The JavaScript app will state installments of Infinity size. Unfortunate, but most likely the error will be discovered soon. It is unlikely to pass through the backed without causing a crash or validation error somewhere before the database (for example JSON will not allow Infinity).
But Elm will happily give the user 0 installments of $0, in other words a free loan. Nobody notices anything is wrong until you realize you are bankrupt.
Bottom line: Converting runtime exceptions to logical errors is a very bad trade.
I'm a great fan of static typing by the way. But it is important to understand that it does not prevent logical errors, only pretty trivial typos and type-mismatch errors which you will discover in unit testing anyway.
I'm not knocking Elm in particular here, just pointing out that believing Elm (or any language really) can eliminate all runtime errors is very dangerous thinking.
Take divide by zero. Dividing by zero is an error so there must be a bug or insufficient validation in the code if it happens. Some languages throw an exception if you divide by zero. You immediately know where something went wrong, and the program does not continue with invalid data.
JavaScript does not throw an error but returns Infinity. So you don't discover the bug immediately, but at least the final output will be clearly invalid since arithmetic operations on Infinity will yield Infinity or NaN.
Apparently in Elm, dividing an integer by zero results in zero. So not only will the program continue with invalid data, it will not even be clear that the result is invalid. The error is still there, but instead of a runtime exception you have an extremely insidious logical error which you might never know is there.
Lets say you have a banking app and the user can take out a loan. The user select the size of loan and the number of months for paying back, and the app calculate the monthly installments by division. But you forgot to validate the input to disallow 0! So the user selects 0 months. A Python app would throw an exception here. Unfortunate, but no harm done. The JavaScript app will state installments of Infinity size. Unfortunate, but most likely the error will be discovered soon. It is unlikely to pass through the backed without causing a crash or validation error somewhere before the database (for example JSON will not allow Infinity).
But Elm will happily give the user 0 installments of $0, in other words a free loan. Nobody notices anything is wrong until you realize you are bankrupt.
Bottom line: Converting runtime exceptions to logical errors is a very bad trade.
I'm a great fan of static typing by the way. But it is important to understand that it does not prevent logical errors, only pretty trivial typos and type-mismatch errors which you will discover in unit testing anyway.
I'm not knocking Elm in particular here, just pointing out that believing Elm (or any language really) can eliminate all runtime errors is very dangerous thinking.
Mistreating division by zero is a logical error as you say, not a runtime error. No one has made any claims in this thread about logical errors, other than my earlier statement that Elm does not preclude them. The things which have been referred to as runtime errors for decades are not present in Elm, that’s really the only point here. In order to make that guarantee, there’s a couple of potholes where logical errors may crop up, it’s a worthwhile trade to many people.
Runtime errors means errors which occurs at runtime as opposed to compile time. Logical errors are a subset of runtime errors. Se for example https://en.wikipedia.org/wiki/Runtime_(program_lifecycle_pha...
This is the common definition.
Defining runtime errors as just being exceptions is clearly absurd - that would mean languages like C or assembler cannot have runtime errors!
This is the common definition.
Defining runtime errors as just being exceptions is clearly absurd - that would mean languages like C or assembler cannot have runtime errors!
To be fair, the grandparent said 'runtime errors', not 'bugs'. And it is a stated goal of the Elm language that runtime exceptions thrown from the compiled Javascript should be impossible. As far as I know, they have succeeded in that goal.
How this relates to 10x or not I don't know - I'm not sure the discussion is a productive one without further context.
It might be that for some tasks, Elm really does provide a huge benefit in productivity. In that case, it's probably fair to call a developer that selects and uses the tool correctly a 10x developer - provided they are able to evolve the culture of their company so that others can take advantage of it.
For other tasks, or in other contexts, Elm might be a hinderance. If it's lacking an indispensable library, or if the company culture is not ready to accept it as a core language, it won't help anyone to rewrite in Elm.
As always, one of the key things that makes a good (even 10x) developer is the ability to select the right tool, and to wield it gracefully.
How this relates to 10x or not I don't know - I'm not sure the discussion is a productive one without further context.
It might be that for some tasks, Elm really does provide a huge benefit in productivity. In that case, it's probably fair to call a developer that selects and uses the tool correctly a 10x developer - provided they are able to evolve the culture of their company so that others can take advantage of it.
For other tasks, or in other contexts, Elm might be a hinderance. If it's lacking an indispensable library, or if the company culture is not ready to accept it as a core language, it won't help anyone to rewrite in Elm.
As always, one of the key things that makes a good (even 10x) developer is the ability to select the right tool, and to wield it gracefully.
I'm sure Elm is a great language, but thinking it eliminates runtime errors is ridiculous. Of course it might eliminate exceptions, but exceptions are not errors, rather they are (sometimes) signals than an error have happened.
Yes, this only holds for some definition of errors. Run time program errors due to type mismatch, nulls and exceptions are non-existant.
Pretty cool!
Pretty cool!
The question is, why was these run time error not caught by unit tests? Probably because there wasn't any tests - which means the code likely have numerous logical errors. Static typing is great, but it will not prevent against logical errors. So without testing you will have bugs in any language you rewrite in.
[deleted]
This is wrong. Rewriting your code in Elm (or other niche language) doesn't make you a 10x developer.
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.
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.
You did not get my comment. I wanted to say that in choosing lang+tooling is a great place to make the 10x difference.
Is it really that 10x performers exist, or that 0.4x performers are abundant so 2x performers look like 10x performers?
I guess what I'm asking is if there is any actual data on this so we can look at actual statistics or if it is all just a meaningless blogspam topic.
I guess what I'm asking is if there is any actual data on this so we can look at actual statistics or if it is all just a meaningless blogspam topic.
>Is it really that 10x performers exist, or that 0.4x performers are abundant so 2x performers look like 10x performers?
Performance is relative, so if the norm is 0.4x, that's the actual "1x" base to just 10x programmers by, even if it's below what a 0.4x programmer could potentially achieve if they really tried.
In other words, if most devs are underperforming due to complacency, lack of motivation, etc., that should also factor in in the 10x programmer calculation.
So, 10x doesn't have to be "10x as good when both are 100% motivated" just "10x as effective" is enough (even if it's because they are more motivated and not actually more intelligent, knowlegeable etc).
Performance is relative, so if the norm is 0.4x, that's the actual "1x" base to just 10x programmers by, even if it's below what a 0.4x programmer could potentially achieve if they really tried.
In other words, if most devs are underperforming due to complacency, lack of motivation, etc., that should also factor in in the 10x programmer calculation.
So, 10x doesn't have to be "10x as good when both are 100% motivated" just "10x as effective" is enough (even if it's because they are more motivated and not actually more intelligent, knowlegeable etc).
The norm can still be 1x and the number of 0.4x can apparently also be too abundant for comfort.
>There is also a significant variation in how the same person performs across multiple tasks.
Not only that, sometimes one individual can engineer things 10X better than at other times.
>Do these two engineers have the same experience with the technology at hand?
No, one has 10x the experience.
>How familiar are they with the system they're working on?
Very, one is just 10X more familiar.
>Do they have the same ability to make decisions on the go?
No, one is a 10X better decision maker.
>How easily can they get help?
Both easily, but one of the two only needs help 10X less often.
>There is also a significant variation in how the same person performs across multiple tasks.
Not only that, sometimes one individual can engineer things 10X better than at other times.
>Do these two engineers have the same experience with the technology at hand?
No, one has 10x the experience.
>How familiar are they with the system they're working on?
Very, one is just 10X more familiar.
>Do they have the same ability to make decisions on the go?
No, one is a 10X better decision maker.
>How easily can they get help?
Both easily, but one of the two only needs help 10X less often.
What I'm getting at is if our 1x is defined by average or median, essentially. Of course without actual data it is impossible to say.
Abstractly it's nice to know.
But practically does it really matter?
Even if we knew the case, one can't just e.g. whip 0.4x into 1x, so a 2x remains a very valuable 2/0.4 jump.
But practically does it really matter?
Even if we knew the case, one can't just e.g. whip 0.4x into 1x, so a 2x remains a very valuable 2/0.4 jump.
> Even if we knew the case, one can't just e.g. whip 0.4x into 1x, so a 2x remains a very valuable 2/0.4 jump.
This is pure speculation, which is why actual data would be useful. Is a measured 0.4x performer that way for innate reasons or is that something which some combination of training and mentoring, better tools, streamlined environments, etc. can help with? — or is the way that's measured even valid? I've seen a few cases where someone got flack for being slow until wider perspective showed that they were the only one solving the customer's real problem because it turned out that what they were doing was more complicated than it looked and/or the other guys were “solving” it in ways that required lots of ongoing maintenance.
This is pure speculation, which is why actual data would be useful. Is a measured 0.4x performer that way for innate reasons or is that something which some combination of training and mentoring, better tools, streamlined environments, etc. can help with? — or is the way that's measured even valid? I've seen a few cases where someone got flack for being slow until wider perspective showed that they were the only one solving the customer's real problem because it turned out that what they were doing was more complicated than it looked and/or the other guys were “solving” it in ways that required lots of ongoing maintenance.
>Is a measured 0.4x performer that way for innate reasons or is that something which some combination of training and mentoring, better tools, streamlined environments, etc. can help with?
For this or that individual (as per your example of "a few cases"), maybe.
For the majority do you think there will be something that hasn't been tried until now, what with all 2000 methodologies of management, team structure, company culture, development methodologies, tooling, agile, waterfall, and what have you, that will suddenly make a difference?
For this or that individual (as per your example of "a few cases"), maybe.
For the majority do you think there will be something that hasn't been tried until now, what with all 2000 methodologies of management, team structure, company culture, development methodologies, tooling, agile, waterfall, and what have you, that will suddenly make a difference?
I think there are plenty of things which make a difference — for example the training and mentoring I mentioned — but the methodology point touches on the problem that they're neither cheap nor easy and most places are unwilling to invest in them. Very few companies which “adopt” something like Agile manage to substantially transform their culture because that's hard and it's a lot easier to make an announcement, do Agilefall, and avoid hard conversations.
Don’t forget that we have -x performers.
There are some programmers who are worse than nothing happening. So a 10x looks better by working accords the averages of all the 1x, -1x, etc.
There are some programmers who are worse than nothing happening. So a 10x looks better by working accords the averages of all the 1x, -1x, etc.
On the Net Negative Producing Programmer - https://wiki.c2.com/?NetNegativeProducingProgrammer and the referenced article from there http://pyxisinc.com/NNPP_Article.pdf
That article starts out with...
> We've known since the early sixties, but have never come to grips with the implications that there are net negative producing programmers (NNPPs) on almost all projects, who insert enough spoilage to exceed the value of their production. So, it is important to make the bold statement: Taking a poor performer off the team can often be more productive than adding a good one. [6, p. 208] Although important, it is difficult to deal with the NNPP. Most development managers do not handle negative aspects of their programming staff well. This paper discusses how to recognize NNPPs, and remedial actions necessary for project success.
> Researchers have found between a low of 5 to 1 to a high of 100 to 1 ratios in programmer performance. This means that programmers at the same level, with similar backgrounds and comparable salaries, might take 1 to 100 weeks to complete the same tasks. [21, p. 8]
Source 21 is: Shneiderman, Ben Software Psychology: Human Factors in Computer and Information Systems (Cambridge, MA: Winthrop, 1980)
https://www.amazon.com/Software-psychology-computer-informat...
That article starts out with...
> We've known since the early sixties, but have never come to grips with the implications that there are net negative producing programmers (NNPPs) on almost all projects, who insert enough spoilage to exceed the value of their production. So, it is important to make the bold statement: Taking a poor performer off the team can often be more productive than adding a good one. [6, p. 208] Although important, it is difficult to deal with the NNPP. Most development managers do not handle negative aspects of their programming staff well. This paper discusses how to recognize NNPPs, and remedial actions necessary for project success.
> Researchers have found between a low of 5 to 1 to a high of 100 to 1 ratios in programmer performance. This means that programmers at the same level, with similar backgrounds and comparable salaries, might take 1 to 100 weeks to complete the same tasks. [21, p. 8]
Source 21 is: Shneiderman, Ben Software Psychology: Human Factors in Computer and Information Systems (Cambridge, MA: Winthrop, 1980)
https://www.amazon.com/Software-psychology-computer-informat...
The Survey cited in Peopleware says that it is a 10x difference between the best and the worst performers. The best performers were something like 2.5x the average performer, as measured by time to complete a specific coding task in the 70s.
Office environment was a factor in performance.
Office environment was a factor in performance.
Peopleware is 30 years old though. Back then very few decided to become programmers. Today when everyone flocks to the field chasing money and you have several orders of magnitude more programmers the ratio could be very different.
Having worked at really high quality startups, and low-quality companies, this is a real thing.
0.1x developer might be a 10x developer that has given up because the build or management is fundamentally broken. Working more will just lead to burnout.
a 0.1x developer might be someone who at some point was very talented but now has no clue, but enough savvy to stay on as a lead/architect/senior
a 0.1x developer might not be qualified, but was hired because the company paid well below market rate.
Many reasons... A 10x is motivated, intelligent, and in the right place at the right time.
0.1x developer might be a 10x developer that has given up because the build or management is fundamentally broken. Working more will just lead to burnout.
a 0.1x developer might be someone who at some point was very talented but now has no clue, but enough savvy to stay on as a lead/architect/senior
a 0.1x developer might not be qualified, but was hired because the company paid well below market rate.
Many reasons... A 10x is motivated, intelligent, and in the right place at the right time.
Yeah, this is an important point when thinking about it from an organization perspective. I've been at places where they "only wanted to hire rockstars" which was beyond stupid. By definition 10x developers are rare and are going to have a lot of options when it comes to where they work. So if you depend on some member of the team carrying a hugely disproportionate
amount of the work, then you are in for a rude awakening when they jump ship.
The problem I have is they always want me to train someone as insurance for if I leave. It becomes a self fulfilling prophecy when you make me work and train mediocre people. I just want to build great things and be left alone.
This blog post has some really interesting thoughts on that point: https://applieddivinitystudies.com/2020/10/15/bus-factor/
Yup. this is my life. I have a dev title but im really directing people. I don't enjoy doing both. May as well get paid accordingly.
This is something our industry needs to fix. I've turned down promotions so many times because they amounted to moving from coding to pastoral care. Which is bizarre - it's like a surgeon being offered a promotion to work in HR.
Many companies do have an individual contributor track, and that's a big factor in where I choose to work, but way too many companies seem to think it's all kinda the same thing.
(To be clear: none of this is neglecting the importance of, or talent involved in, managing people. Bringing out people's potential requires tremendous skill, which I don't have, and that's why I won't do it.)
Many companies do have an individual contributor track, and that's a big factor in where I choose to work, but way too many companies seem to think it's all kinda the same thing.
(To be clear: none of this is neglecting the importance of, or talent involved in, managing people. Bringing out people's potential requires tremendous skill, which I don't have, and that's why I won't do it.)
If you trained one or more operators who have already left for alternative employment, you could point out that there may now be other orgs making more money from your technology than your own employer is.
>you depend on some member of the team carrying a hugely disproportionate amount of the work
This can be a problem when there is only one high-performer.
You hire all high-performers so this is not what happens.
This can be a problem when there is only one high-performer.
You hire all high-performers so this is not what happens.
I still haven't met any 10x engineers.
What I have met are 3x engineers who protect their own job security so severely that they make everyone else a third as effective.
3 * (1 / 1/3) = 9
Meanwhile I'm a 3x engineer who makes everyone else twice as effective. Management sees me as a 1.5x engineer, when my actual factor depends on how many coworkers I have.
What I have met are 3x engineers who protect their own job security so severely that they make everyone else a third as effective.
3 * (1 / 1/3) = 9
Meanwhile I'm a 3x engineer who makes everyone else twice as effective. Management sees me as a 1.5x engineer, when my actual factor depends on how many coworkers I have.
You don't always have a choice: you cannot replace a person that can read with 10 people that cannot read. All of the very few "10x people" that I met had expertise far beyond their team mates had and they used it well.
People don't always leave, although they do die. Peter Norvig has been at Google since 02000. Jeff Dean has been at Google since 01999. Ken Thompson was at Bell Labs from 01966 to 02000, when he "retired" (but, really, Bell Labs no longer existed). Mick Jagger has been in the Rolling Stones since 01962. Marvin Minsky was at the AI Lab from its founding as Project MAC in 01963 until his death in 02016.
What would the Rolling Stones look like if someone had said, "Our organization shouldn't be resting on the shoulders of Mick Jagger"? What would Google look like if someone had said "Our organization shouldn't be resting on the shoulders of Jeff and Sanjay"? What would CSAIL look like if someone had said "Our organization shouldn't be resting on the shoulders of Minsky"? They'd look like mediocre failures.
"How are you going to replace Jagger if he quits the Stones?" is not really the right question. You have to accept that the Stones without Jagger, or Bell Labs without Thompson, just would not be the same. To a very great extent the productivity of a creative organization depends on its ability to attract and retain high performers, because it's inevitable that it rests on their shoulders. Denial won't change that.
If you want your organization to succeed in a creative field, the right question to ask is, "How can we hire people like Ken Thompson, and how can we keep them from wanting to leave?"
What would the Rolling Stones look like if someone had said, "Our organization shouldn't be resting on the shoulders of Mick Jagger"? What would Google look like if someone had said "Our organization shouldn't be resting on the shoulders of Jeff and Sanjay"? What would CSAIL look like if someone had said "Our organization shouldn't be resting on the shoulders of Minsky"? They'd look like mediocre failures.
"How are you going to replace Jagger if he quits the Stones?" is not really the right question. You have to accept that the Stones without Jagger, or Bell Labs without Thompson, just would not be the same. To a very great extent the productivity of a creative organization depends on its ability to attract and retain high performers, because it's inevitable that it rests on their shoulders. Denial won't change that.
If you want your organization to succeed in a creative field, the right question to ask is, "How can we hire people like Ken Thompson, and how can we keep them from wanting to leave?"
> People leave. If your 10x (or 3x or 5x) engineer quits: are you really going to hire 3,5 or 10 people to replace them? Unlikely. And even if you do, institutional knowledge is lost.
When I left my last job, part of what I was doing was replaced by a team that built up to 5 engineers last I checked. They're doing it more intensely (although, I don't think with better results), and they've got to have a lot more communication than when I did it (I was trusted to do cowboy deploys to an isolated system, they've got to deal with code reviews and just making each other aware of what they're doing because 5 people in a small system means overlapping work). And, I did a bunch of other stuff too which AFAIK didn't really get picked up, but hopefully they've been lucky and not had weird TLS problems or other 'select is broken' experiences lately.
When I left my last job, part of what I was doing was replaced by a team that built up to 5 engineers last I checked. They're doing it more intensely (although, I don't think with better results), and they've got to have a lot more communication than when I did it (I was trusted to do cowboy deploys to an isolated system, they've got to deal with code reviews and just making each other aware of what they're doing because 5 people in a small system means overlapping work). And, I did a bunch of other stuff too which AFAIK didn't really get picked up, but hopefully they've been lucky and not had weird TLS problems or other 'select is broken' experiences lately.
My employer considers me a 10x developer. It's not a title I'd choose for myself. I'm the only software engineer to be on a bonus scheme, which is great.
But it means I'm expected to be available constantly. I'm not a one-man team but I tend to be the first point of contact for people outside our Eng team. It gets a bit much sometimes.
But it means I'm expected to be available constantly. I'm not a one-man team but I tend to be the first point of contact for people outside our Eng team. It gets a bit much sometimes.
Make sure your enployer isn’t just stroking your ego to make you work long hours and take on more responsibility. Make sure you get the compensation you think you deserve not future promises..
> 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.
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.
I'd agree. I don't think the article is refutes that "10x engineers exist" - more that some engineers who are able to work fast are incorrectly labelled "10x"
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.
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.
Indeed! Did he get time to "share knowledge with his peers". Would he have been credited for it? Would his position in the corporation have gotten more secure?
In a U.S. corporation, the answer to all these questions is "no".
In a U.S. corporation, the answer to all these questions is "no".
I strongly suspect those conditions are not confined to the US.
This here. I think the author is confusing what a 10x developer is.
I took the 10x dev to mean somebody who may work efficiently but also improves all of the devs around them. Improving yourself by 2x is one thing but improving the team around you by 2x is where you get the 10x.
I took the 10x dev to mean somebody who may work efficiently but also improves all of the devs around them. Improving yourself by 2x is one thing but improving the team around you by 2x is where you get the 10x.
> the author is confusing what a 10x developer is.
Its a subjective definition. You have a different one to the author. sneak has a different definition to you.
That's a part of the problem: there's no clear definition and the label "10x developer" means different things to different things.
Some of these definitions definitely are a myth. Some are not. But the conversations about it tend to not be that meaningful, because everyone argues their own definition, which may or may not match up with other people who are also arguing theirs. The best we can do is define our definition and then state our reasoning about it and then others can agree or disagree or say yes but if you define it this way that I do, then its different because whatever.
Right now, everyone has a different definition and the discussion isn't that useful.
Its a subjective definition. You have a different one to the author. sneak has a different definition to you.
That's a part of the problem: there's no clear definition and the label "10x developer" means different things to different things.
Some of these definitions definitely are a myth. Some are not. But the conversations about it tend to not be that meaningful, because everyone argues their own definition, which may or may not match up with other people who are also arguing theirs. The best we can do is define our definition and then state our reasoning about it and then others can agree or disagree or say yes but if you define it this way that I do, then its different because whatever.
Right now, everyone has a different definition and the discussion isn't that useful.
My coworker is a beast at churning out working code, but mine is often better abstracted and requires less refactoring to use in the future.
There are features where I spent 5-10x the time he'd do, but my code could then be used to later implement several dozen feature requests in mere minutes rather than hours and days.
Who's better? I'd say we've got different strengths, so depends on what you need to get done.
There are features where I spent 5-10x the time he'd do, but my code could then be used to later implement several dozen feature requests in mere minutes rather than hours and days.
Who's better? I'd say we've got different strengths, so depends on what you need to get done.
Your coworker is better, sounds like you spend a lot of time on premature generalisation.
Technically premature yes.
But I do have experience guiding me. It's not like I'm abstracting everything I do. So my efforts tend to pay off.
But I do have experience guiding me. It's not like I'm abstracting everything I do. So my efforts tend to pay off.
No, the 10x developer is someone who, alone in a room, can ship in y period of time the same thing it would take 10 median developers y units of time to ship, or one median developer 10y units of time
to ship.
Because of the mythical man month, the 10 will actually take >y time to do it, due to coordination overhead. The 10xer will still ship the item in 1y. A big part of the leap from 5x to 10x is being able to dodge communication overhead.
Some are also good at boosting their team. Some only work well alone.
Because of the mythical man month, the 10 will actually take >y time to do it, due to coordination overhead. The 10xer will still ship the item in 1y. A big part of the leap from 5x to 10x is being able to dodge communication overhead.
Some are also good at boosting their team. Some only work well alone.
Yeah, this reads like a straw man attack on a particular and not widely accepted view of what a 10x engineer is.
Yeah, great programmers are also great documenters and also process-oriented and detailed
Dennis Ritchie, Vitalik Buterin, Jeff Dean exist
Dennis Ritchie, Vitalik Buterin, Jeff Dean exist
The author is talking about people who are perceived by management to be 10x developers and why that perception can sometimes be flawed.
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.
It's not that they write code faster. It's that they select a path to the solution that is a lot shorter.
Perhaps best is when they make other people more productive by pointing them in the right direction early on. Everybody has been stuck on a problem for days or more. Someone who can get you moving again by asking the right questions or pointing to an alternative approach can make you a lot more productive.
> they select a path to the solution that is a lot shorter.
Yeah, I've also seen this. A lot. And selecting a shorter path often includes redefining the problem to be solved.
In fact, as far as I can tell these kinds of differences are the norm, not the exception.
From the article:
> In a controlled environment, the variation between most software engineers is much more modest.
This is almost certainly true, but completely misses the point. The point of 10x engineers is that they change the environment. They don't type in code 10x faster. If you don't allow them to change the environment, they won't be 10x more effective.
Yeah, I've also seen this. A lot. And selecting a shorter path often includes redefining the problem to be solved.
In fact, as far as I can tell these kinds of differences are the norm, not the exception.
From the article:
> In a controlled environment, the variation between most software engineers is much more modest.
This is almost certainly true, but completely misses the point. The point of 10x engineers is that they change the environment. They don't type in code 10x faster. If you don't allow them to change the environment, they won't be 10x more effective.
I'd add that its also in the design of things and deciding what to work on.
I've seen small design decisions lead to a lot more (or less) work for the whole team. I've also seen teams work for months on things that didn't need to be done.
I've seen small design decisions lead to a lot more (or less) work for the whole team. I've also seen teams work for months on things that didn't need to be done.
I'm mid-career, I guess, and these days I kinda feel like I've fucked up if I'm writing any serious amount of code, under most circumstances. The best solution is often a small script in the right place, leveraging existing software (when the best solution isn't "FFS, just pay a SaaS to take care of this, it's not even worth the time we've spent talking about it"). When I'm writing an actual project, I've got this nagging feeling like I just didn't know enough to avoid writing it. Like maybe I need to go RTFMs of the many battle-hardened daemons and OS components I have available and could be using.
Any time I do achieve "10x" versus anyone else (and I think I sometimes do, though the broad "anyone else" makes that less impressive) it's usually because of what I didn't write.
Any time I do achieve "10x" versus anyone else (and I think I sometimes do, though the broad "anyone else" makes that less impressive) it's usually because of what I didn't write.
The smaller a Pull Request I submit, the prouder I am of it.
> It's not that they write code faster. It's that they select a path to the solution that is a lot shorter.
I know a developer who likes portraying himself as a kind of 10x.
He does not code faster, better, or smarter. His talent is managing his supervisor's expectations. He massages management to revise goals and shave off requirements, he is able to leverage even the smallest bump on the project management road to remove requirements and justify delays, and in the process he is able to put together a MVP that meets a fraction of the initial requirements and in spite of barely working does meet his manager's acceptance bar.
In the end all that is left is the story where he single-handedly delivered a working product, he moves onward to greener pastures, and an unwitting team is left with the architectural problems, myriads of bugs, missing features, and the blame for stuff failing to work in production.
I know a developer who likes portraying himself as a kind of 10x.
He does not code faster, better, or smarter. His talent is managing his supervisor's expectations. He massages management to revise goals and shave off requirements, he is able to leverage even the smallest bump on the project management road to remove requirements and justify delays, and in the process he is able to put together a MVP that meets a fraction of the initial requirements and in spite of barely working does meet his manager's acceptance bar.
In the end all that is left is the story where he single-handedly delivered a working product, he moves onward to greener pastures, and an unwitting team is left with the architectural problems, myriads of bugs, missing features, and the blame for stuff failing to work in production.
I think you are just salty.
Communication is really important and seems like that dev was really capable at it
> I think you are just salty. Communication is really important and seems like that dev was really capable at it
I'm not sure you got the point. The whole point is that, exactly like OP stated, some of these self-described 10x developers do not code faster/better/stronger at all. They might even suck at it. However, they do excel at all the salesmanship required to descope critical features out of a project until all it's left is a fraction of the original project, and also excel at managing the expectations of all stakeholders so that the 1/10th of the project they deliver is passed off as the desired outcome.
Once they succeed at turning a production project that requires a team to write into what amounts to a proof of concept that's doable by a one-man team, they find themselves in a position where a person alone can put it together.
To put it differently, it's easy to run a whole marathon at 1/10th of the time when you succeed at moving the finishing line to 1/10th of the marathon's length. That requires skills, but they are soft skills and not hard skills, and you do not need to run faster than anyone else to do it.
I'm not sure you got the point. The whole point is that, exactly like OP stated, some of these self-described 10x developers do not code faster/better/stronger at all. They might even suck at it. However, they do excel at all the salesmanship required to descope critical features out of a project until all it's left is a fraction of the original project, and also excel at managing the expectations of all stakeholders so that the 1/10th of the project they deliver is passed off as the desired outcome.
Once they succeed at turning a production project that requires a team to write into what amounts to a proof of concept that's doable by a one-man team, they find themselves in a position where a person alone can put it together.
To put it differently, it's easy to run a whole marathon at 1/10th of the time when you succeed at moving the finishing line to 1/10th of the marathon's length. That requires skills, but they are soft skills and not hard skills, and you do not need to run faster than anyone else to do it.
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!
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!
Why not both? There's at least a factor of 3x difference between the volume of the most prolific programmers I know and the least. If John Carmack ships the product in 1/10th the time of Average Joe, I would call him a 10x engineer regardless of whether he picked a smarter design or if he simply implemented the dumb design 10x faster (or anything in between, obviously).
This is finally what allowed me to overcome my own self-doubt.
I'm not the fastest programmer and I don't have the most intellectual horsepower either. What I do have is an enormous body of knowledge built up over many many years that allows me to select the shortest path or atleast guide people smarter than me into the right area of the solution space where it should exist.
I'm not the fastest programmer and I don't have the most intellectual horsepower either. What I do have is an enormous body of knowledge built up over many many years that allows me to select the shortest path or atleast guide people smarter than me into the right area of the solution space where it should exist.
Unfortunately in big companies, pointing in the right direction isn't good enough: then you have to fight inertia, inter-team, inter-site disputes to finally do the right things :-(
The original study (if I remember correctly) showed a 10x productivity difference between the most and least productive students on a given task. I find that very plausible. In real world settings the difference might be much larger, since some developers effectively have zero or negative productivity.
This article talks about a developer with consistently 10x productivity compared to the average developers in an organization. I think this is pretty rare. And I would consider it a warning signal. It means that either the average is really low or the hero is really a one-of-kind genius which will likely move on to a different job quickly (or get hit by a bus, per Murphys Law).
It could also indicate (as per the article) that the 10x developer is actually keeping the other developers down, e.g. by insufficient knowledge sharing or writing unmaintainable code. You often see this if the 10x developers is "the old guy" who develops at night and hates meetings of any kind. Removing this guy will cause an immediate hit, but over time increase the productivity of the remaining developers.
This article talks about a developer with consistently 10x productivity compared to the average developers in an organization. I think this is pretty rare. And I would consider it a warning signal. It means that either the average is really low or the hero is really a one-of-kind genius which will likely move on to a different job quickly (or get hit by a bus, per Murphys Law).
It could also indicate (as per the article) that the 10x developer is actually keeping the other developers down, e.g. by insufficient knowledge sharing or writing unmaintainable code. You often see this if the 10x developers is "the old guy" who develops at night and hates meetings of any kind. Removing this guy will cause an immediate hit, but over time increase the productivity of the remaining developers.
I see a variation on this article, several times a year.
I can't speak for other cultures, but the US has a fundamental mindset that all but worships "exceptionalism." We like mavericks, rule-benders, and exceptionally talented individuals. Being attractive, and having a winning [public] persona is also very helpful. Sometimes, good actors can use attractiveness and persona to cover up for a lack of accomplishment and substance, and often, people of great substance, are ignored, because they are not attractive, have "problematic" personalities, or are not particularly good at self-promotion.
I remember watching a documentary that compared the k-12 educational systems of the US, Germany and Japan. They looked at how high-performing students were treated, and how that affected their peers.
The US would concentrate on high performers, often to the detriment of their peers.
Japan would make high performers coach their peers.
They seemed to decide that Germany had the best approach. I don't remember exactly how that went (I remember extremes).
I'm a damn good engineer. Am I "10X"? I don't know, and don't care. I'm not in competition with anyone else. I get done what needs getting done, and I always have a ton of stuff I don't know, and still need to learn.
Another thing about the US culture (I was not raised in the US), is that it is highly competitive. We can't just be good at something; we need to be better than someone else.
That seems exhausting, to me.
I'm not competitive at all. I have worked on high-functioning teams, my entire career, and was never interested in competing with my teammates. The team competed against other teams, but that wasn't really anything that concerned me.
I can't speak for other cultures, but the US has a fundamental mindset that all but worships "exceptionalism." We like mavericks, rule-benders, and exceptionally talented individuals. Being attractive, and having a winning [public] persona is also very helpful. Sometimes, good actors can use attractiveness and persona to cover up for a lack of accomplishment and substance, and often, people of great substance, are ignored, because they are not attractive, have "problematic" personalities, or are not particularly good at self-promotion.
I remember watching a documentary that compared the k-12 educational systems of the US, Germany and Japan. They looked at how high-performing students were treated, and how that affected their peers.
The US would concentrate on high performers, often to the detriment of their peers.
Japan would make high performers coach their peers.
They seemed to decide that Germany had the best approach. I don't remember exactly how that went (I remember extremes).
I'm a damn good engineer. Am I "10X"? I don't know, and don't care. I'm not in competition with anyone else. I get done what needs getting done, and I always have a ton of stuff I don't know, and still need to learn.
Another thing about the US culture (I was not raised in the US), is that it is highly competitive. We can't just be good at something; we need to be better than someone else.
That seems exhausting, to me.
I'm not competitive at all. I have worked on high-functioning teams, my entire career, and was never interested in competing with my teammates. The team competed against other teams, but that wasn't really anything that concerned me.
> The US would concentrate on high performers, often to the detriment of their peers.
This is, at best, half true. The high performers might get the most attention from certain teachers (esp. in middle class and upper middle class schools), but systemically they are ignored.
1. The general idea in education circles is that the higher performers “will do fine” without any additional attention, so they don’t need much help. As such, very little research attention is focused on them.
2. Gifted education is a joke in the US. Almost completely ignored.
3. Most honors classes are also a joke in that they are often regular classes with more busy work.
4. AP classes are sometimes good, but it’s often easier just to take an actual college course if your school allows it. Same or less classroom time and much less busy work.
5. School administrators are evaluated based on performance metrics. In almost all cases it is more beneficial and often easier to improve the low performers than it is to improve the high performers. This is largely due to the metrics that have been chosen for evaluation.
As for Japan, that observation is very true. That said, most of the talent mismatches disappear starting at high school and sometimes junior high school due to tracking (of which I am a fan).
This is, at best, half true. The high performers might get the most attention from certain teachers (esp. in middle class and upper middle class schools), but systemically they are ignored.
1. The general idea in education circles is that the higher performers “will do fine” without any additional attention, so they don’t need much help. As such, very little research attention is focused on them.
2. Gifted education is a joke in the US. Almost completely ignored.
3. Most honors classes are also a joke in that they are often regular classes with more busy work.
4. AP classes are sometimes good, but it’s often easier just to take an actual college course if your school allows it. Same or less classroom time and much less busy work.
5. School administrators are evaluated based on performance metrics. In almost all cases it is more beneficial and often easier to improve the low performers than it is to improve the high performers. This is largely due to the metrics that have been chosen for evaluation.
As for Japan, that observation is very true. That said, most of the talent mismatches disappear starting at high school and sometimes junior high school due to tracking (of which I am a fan).
> The US would concentrate on high performers, often to the detriment of their peers.
That's very interesting. This is anecdotally very contrary to my experience in middle-class public school, and my sister's experience as a teacher in a lower-income school.
Was the doc shot pre-NCLB? Is it simply a matter of variance across a large country, and my viewpoint is biased?
That's very interesting. This is anecdotally very contrary to my experience in middle-class public school, and my sister's experience as a teacher in a lower-income school.
Was the doc shot pre-NCLB? Is it simply a matter of variance across a large country, and my viewpoint is biased?
I don't remember. It was a long time ago. In my experience, this is exactly what happened, in my schools (I attended US public and private schools, after 5th grade).
I saw it from both perspectives. I was very smart, and did well, when I applied myself. I could also be a nightmare slacker.
I saw it from both perspectives. I was very smart, and did well, when I applied myself. I could also be a nightmare slacker.
Anyone who doubts 10x devs exist either never met a real one or is merely protecting their ego. Software development is complex enough that I'd go so far as to say there's even 100x range even among those considered competent. We accept this range in sports and art, what's the hangup? It seems like someone who just learned deductive reasoning and feels like they could now understand the universe then someone says there are 10x'ers and they instinctively go Noooooo!
Sus are those who write to debunk it.
Sus are those who write to debunk it.
I don't think anyone really doubts that some engineers will work an order of magnitude or more faster than others on a given task. They just think it's a misleading way to think about performance, which likely falls on a unimodal curve within your organisation, and likely differs by task.
How do you know you're looking at a 10x developer instead of a 2x, a 9x, an 11x, a 500x, a 0.2x, or a 0.5x? The premise gives the impression that you can neatly split engineers into two groups, which is wrong. Your 500x engineers are only going to perform that way on tasks they've done before, your 0.2x engineer might just have the flu or might be an intern on his first day, your 2x engineer who wrote a parser for that weird proprietary format last week could be 0.5x this week because she's working on ansible scripts, and in general it's impossible to settle on a constant integer factor of engineering ability that does any better than IQ.
How do you know you're looking at a 10x developer instead of a 2x, a 9x, an 11x, a 500x, a 0.2x, or a 0.5x? The premise gives the impression that you can neatly split engineers into two groups, which is wrong. Your 500x engineers are only going to perform that way on tasks they've done before, your 0.2x engineer might just have the flu or might be an intern on his first day, your 2x engineer who wrote a parser for that weird proprietary format last week could be 0.5x this week because she's working on ansible scripts, and in general it's impossible to settle on a constant integer factor of engineering ability that does any better than IQ.
You're looking at a very different kind of Nx engineer. The kind I'm talking about is where they approach a brand new problem that no one has an idea how to decompose using any tech that they have a clue how to operate, then a concise solution somehow appears using mostly what is already in service with careful splitting of tasks that appear clear and obvious only in retrospect. It's not about volume of output, precisely the opposite.
The original studies that gave us the concept of a 10x engineer tracked defect rate and speed on programming tasks. You're using your own definition of an Nx engineer that:
- does not relate to speed or defect rate
- does not provide any way to quantify what N is
- does not explain how an Nx engineer differs from a normal competent engineer
There's no problem with saying "engineers who can solve novel open-ended problems exist", the problem is that there's no reason to call those engineers 10x, no reason to suggest ability to solve those problems is a yes/no question, and no link to the original studies that we got the concept of a 10x engineer from. I remain unconvinced that the concept of 10x engineers is very useful.
- does not relate to speed or defect rate
- does not provide any way to quantify what N is
- does not explain how an Nx engineer differs from a normal competent engineer
There's no problem with saying "engineers who can solve novel open-ended problems exist", the problem is that there's no reason to call those engineers 10x, no reason to suggest ability to solve those problems is a yes/no question, and no link to the original studies that we got the concept of a 10x engineer from. I remain unconvinced that the concept of 10x engineers is very useful.
The difference isn't only in how fast/well tasks get done, but a very good engineer will make many such tasks unnecessary altogether with better design and implementations that forego their need. Without including this aspect, the metric is a low-level one and not indicative of overall impact.
That's the point. If you don't have a metric that says "Alice is 10x better than Bob" and you don't specify a task she's better at, then what you really mean is "Alice is on average and by some unknown factor much better than Bob on the tasks she performs".
Framing it as though you have a rigorous comparison between them will mislead you into thinking about engineers as if they were fungible, like diesel generators, which is a very silly way to think about a divide-and-conquer field like software engineering where engineers develop different levels of expertise in different things.
If you're suggesting there is some underlying factor, like generalised intelligence, I'm not arguing with that! I strongly disagree that factor has anything to do with the number 10, or that engineers fall into discrete 1x and 10x camps, though. I think the phrase "10x engineer" leads to logical fallacies about performance.
Framing it as though you have a rigorous comparison between them will mislead you into thinking about engineers as if they were fungible, like diesel generators, which is a very silly way to think about a divide-and-conquer field like software engineering where engineers develop different levels of expertise in different things.
If you're suggesting there is some underlying factor, like generalised intelligence, I'm not arguing with that! I strongly disagree that factor has anything to do with the number 10, or that engineers fall into discrete 1x and 10x camps, though. I think the phrase "10x engineer" leads to logical fallacies about performance.
I don't see where we disagree at all. I suggested 100x and at the same time didn't try to measure or spec it in any concrete way, which seems meaningless but have had enough interactions to say it has merit. I have no interest in why, unless it's something I can use to hire or train.
> How do you know you're looking at a 10x developer instead of a 2x, a 9x, an 11x, a 500x, a 0.2x, or a 0.5x?
This is the hard part, isn’t it. It’s hard to tell beforehand, but if you’re skilled enough you can look at someone’s contribution history and see what they’ve done over the past years. It’s not perfect, but it helps.
Similar to how you review a 10x artist, just look at their work.
I don’t think asking people if they are great is very useful.
This is the hard part, isn’t it. It’s hard to tell beforehand, but if you’re skilled enough you can look at someone’s contribution history and see what they’ve done over the past years. It’s not perfect, but it helps.
Similar to how you review a 10x artist, just look at their work.
I don’t think asking people if they are great is very useful.
Agreed. They absolutely exist and I think 10x is too small of a multiplier for what they can do for a project and team. In particular, starting a significant project from zero often requires them.
We’re fooling ourselves that they don’t exist and, if they do exist, are universally toxic.
We’re fooling ourselves that they don’t exist and, if they do exist, are universally toxic.
I work in ML engineering, and I’ve seen people work on a problem for the better part of a year with little to show for it. The non-progress gets on leadership’s radar, so even more resources get directed to crack what should be a solvable but non-trivial problem.
An engineer who could have solved this problem without a fuss within a month or two is easily a 10x engineer. Not because they work 10x faster, but through better ideas and thought process, efficiency with their tools, and exercising leverage. This is even without considering their additional impact on the work of others.
I think this could be applicable in any software or tech field, as long as the best solution to a problem isn’t trivial or immediately obvious.
An engineer who could have solved this problem without a fuss within a month or two is easily a 10x engineer. Not because they work 10x faster, but through better ideas and thought process, efficiency with their tools, and exercising leverage. This is even without considering their additional impact on the work of others.
I think this could be applicable in any software or tech field, as long as the best solution to a problem isn’t trivial or immediately obvious.
==An engineer who could have solved this problem without a fuss within a month or two is easily a 10x engineer.==
They also need the trust of their superiors to be listened to in the first place. A 10x engineer isn’t helpful if management doesn’t take their advice.
They also need the trust of their superiors to be listened to in the first place. A 10x engineer isn’t helpful if management doesn’t take their advice.
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.
I think this is true for any group of engineers - some will be much more productive than others. That isn't because those engineers are better, or "10x" though, it's simply because they're working on a problem they find interesting in an environment where they're thriving. The less productive people aren't enjoying the problem they're solving, or there's something about the company or team that isn't right for them.
Most capable engineers have the potential to be "10x engineers" compared to their peers if they find a problem they're passionate about in a company that works well for them.
The real unicorn engineers are the ones who are able to drop in to any team and be like that.
Most capable engineers have the potential to be "10x engineers" compared to their peers if they find a problem they're passionate about in a company that works well for them.
The real unicorn engineers are the ones who are able to drop in to any team and be like that.
There are two things here:
- What is a 10x programmer (what do they do better?)
- What is the impact of their presence (or absence) on a company
A 10x programmer is not someone who completes a narrowly defined task at 10x the speed of another engineer.
> In a controlled environment, the variation between most software engineers is much more modest.
Of course!
If you ask people to implement a small component as part of a large architecture that was already decided .. you won't find much of a difference in performance (unless you have people who are truly and utterly incompetent).
The excellent engineers would come up with a different design to begin with, but you can't measure that in a controlled study.
Now, knowing that 10x engineers exist, how can you use that to your advantage if you're a manager of a company?
If you yourself are not an excellent programmer, you can't just hire excellent programmers and hope they improve your business.
You will be fighting with them over control.
The key is to have excellent programmers in powerful position where they can call the shots about how to hire and manage and reward people.
If you are willing to give them that kind of power, then you have no business reading articles like this on the internet.
If you are not yourself an excellent engineer and are not willing to share power with excellent engineers, then no amount of reading of such articles on the internet will help you make the right decisions.
- What is a 10x programmer (what do they do better?)
- What is the impact of their presence (or absence) on a company
A 10x programmer is not someone who completes a narrowly defined task at 10x the speed of another engineer.
> In a controlled environment, the variation between most software engineers is much more modest.
Of course!
If you ask people to implement a small component as part of a large architecture that was already decided .. you won't find much of a difference in performance (unless you have people who are truly and utterly incompetent).
The excellent engineers would come up with a different design to begin with, but you can't measure that in a controlled study.
Now, knowing that 10x engineers exist, how can you use that to your advantage if you're a manager of a company?
If you yourself are not an excellent programmer, you can't just hire excellent programmers and hope they improve your business.
You will be fighting with them over control.
The key is to have excellent programmers in powerful position where they can call the shots about how to hire and manage and reward people.
If you are willing to give them that kind of power, then you have no business reading articles like this on the internet.
If you are not yourself an excellent engineer and are not willing to share power with excellent engineers, then no amount of reading of such articles on the internet will help you make the right decisions.
So… 10x engineers exist, but they don’t count because their productivity comes from superior knowledge or other factors? This is sort of silly. Just because you can ‘control for a factor’ doesn’t mean that said developer isn’t 10x more productive than everyone else. And providing one example of how this can go wrong says nothing about the general case.
I know an objectively measured 500x engineer.
In the '90s, Siemens AG and Ericsson made a joint venture called Ellemtel for a classic six-month death-march project: if it completed on time, the customer paid. Otherwise, discarded. Each company sent 250 engineers.
At the end of the six months, they delivered a working system. Fully half the code in it was by this one engineer.
In the '90s, Siemens AG and Ericsson made a joint venture called Ellemtel for a classic six-month death-march project: if it completed on time, the customer paid. Otherwise, discarded. Each company sent 250 engineers.
At the end of the six months, they delivered a working system. Fully half the code in it was by this one engineer.
Out of the 50 ish devs I've worked with closely, I've seen two I would say are in the '10x' camp. They were relentless in writing solid, simple, bug-free code, and doing so faster than everyone else. They were also effective in communicating their work. i.e. They weren't head-down in the corner savants.
Their productivity was also significantly more consistent across a range of areas and task complexity, compared with other devs who would slow if working in an unfamiliar area or on a more complex task.
Finally, good (and bad) decision making compounds with software. The right high level approach can pay easily pay of 10x over time just as a bad approach will result in buggy, bad performing software, and multiple rewrites.
In short, this article does not match my experience.
Their productivity was also significantly more consistent across a range of areas and task complexity, compared with other devs who would slow if working in an unfamiliar area or on a more complex task.
Finally, good (and bad) decision making compounds with software. The right high level approach can pay easily pay of 10x over time just as a bad approach will result in buggy, bad performing software, and multiple rewrites.
In short, this article does not match my experience.
People often forget that 10X does not (only) mean quantity, but most of all quality.
Also thinking in factors may not be the right approach here. We should look at it in a more binary way: Can a developer achieve the requirements or not? In most cases the magnitude of skill shows in what a developer can solve at all, not how fast he/she can solve it.
Also thinking in factors may not be the right approach here. We should look at it in a more binary way: Can a developer achieve the requirements or not? In most cases the magnitude of skill shows in what a developer can solve at all, not how fast he/she can solve it.
I churn this out every so often:
A 2nd edition of Peopleware summarises it; the 10x programmer is not a myth, but it's comparing the best to the worst; NOT best to median. It's also not about programming specifically; it's simply a common distribution in many metrics of performance.
The rule of thumb Peopleware states is that you can rely on the best outperforming the worst by a factor of 10, and you can rely on the best outperforming the median by a factor of 2.5. This of course indicates that a median developer, middle of the pack, is a 4x developer. Obviously, this is a statistical rule, and if you've got a tiny sample size or some kind of singular outlier or other such; well, we're all adults and we understand how statistics and distributions work.
Peopleware uses Boehn (1981), Sackman (1968), Augustine (1979) and Lawrence (1981) as its sources. [ "Peopleware", DeMarco and Lister, 1987, p45 ]
A 2nd edition of Peopleware summarises it; the 10x programmer is not a myth, but it's comparing the best to the worst; NOT best to median. It's also not about programming specifically; it's simply a common distribution in many metrics of performance.
The rule of thumb Peopleware states is that you can rely on the best outperforming the worst by a factor of 10, and you can rely on the best outperforming the median by a factor of 2.5. This of course indicates that a median developer, middle of the pack, is a 4x developer. Obviously, this is a statistical rule, and if you've got a tiny sample size or some kind of singular outlier or other such; well, we're all adults and we understand how statistics and distributions work.
Peopleware uses Boehn (1981), Sackman (1968), Augustine (1979) and Lawrence (1981) as its sources. [ "Peopleware", DeMarco and Lister, 1987, p45 ]
As much as I admire Peopleware, I think on this it misses the fact that there are "negative"-X programmers. Adding them to a team means the team gets _less_ work done, either through endless questions, dodging responsibility, demotivating others etc. In this kind of best/worst metric you end up with above-infinite-X programmers, because the worst you could give a working system to and they will break it.
Once you filter out the worst, I've still seen 10x-vs-median programmers. They have some insight which collapses a buggy, never-complete 50kloc library into a 50 line function plus a call to a SAT solver, or have some deep understanding of the underlying system that lets the whole team avoid spinning its wheels on an impossible-to-diagnose bug. These people are worth 10 ticket-closers any day of the week.
Once you filter out the worst, I've still seen 10x-vs-median programmers. They have some insight which collapses a buggy, never-complete 50kloc library into a 50 line function plus a call to a SAT solver, or have some deep understanding of the underlying system that lets the whole team avoid spinning its wheels on an impossible-to-diagnose bug. These people are worth 10 ticket-closers any day of the week.
There's a twisted version of this "myth" that I encoutered: The demand for software developers grows much faster than the supply, so there is a temptation to hire wildly incompetent people, hoping that they still be able to deliver good enough product. As a result we have "1x" engineers, which are competent but rare, and "0.1x" code monkeys trying to get by.
Or to put it in a different way: "In the land of blind, the one-eyed is a king".
Or to put it in a different way: "In the land of blind, the one-eyed is a king".
As I get older, and maybe because I worked at a company whose product is “talent optimization”, I think a lot of the “10x” thing is just a function engagement and passion. That is to say it’s not entirely skill or “intelligence”. You could take the best programmer but if you point them at a project they don’t give a crap about they’ll phone it in. Point them at something they’re passionate about and they’ll have absurd impact. They’ll think of more novel solutions, test and refine those solutions, and crank out the whole thing in record time.
If you want a 10x engineer, give them work they love.
If you want a 10x engineer, give them work they love.
I'd also qualify it by saying that a 10x engineer is not a 10x engineer for long if you burn them out or even if life just happens.
I've met a lot of spunky young college grads/drop-outs who felt like 10x engineers but had no family, no hobbies outside programming and no social life outside meetups, conferences and work.
I've also met people I'd confidently describe as 10x engineers who had all of that but in turn spent far fewer "productive" hours at work than the former.
There's a common misconception that you need to find "young talent" and make them work maximum productive hours (who needs to do chores when you have a work-provided luxury cafeteria and laundry service?) to get the most value out of them like they're top athletes. Well, most top athletes retire before they hit 40. If that's your plan, you're not looking for 10x developers, you're just looking for more meat for the grinder.
I've met a lot of spunky young college grads/drop-outs who felt like 10x engineers but had no family, no hobbies outside programming and no social life outside meetups, conferences and work.
I've also met people I'd confidently describe as 10x engineers who had all of that but in turn spent far fewer "productive" hours at work than the former.
There's a common misconception that you need to find "young talent" and make them work maximum productive hours (who needs to do chores when you have a work-provided luxury cafeteria and laundry service?) to get the most value out of them like they're top athletes. Well, most top athletes retire before they hit 40. If that's your plan, you're not looking for 10x developers, you're just looking for more meat for the grinder.
This. Very much this.
I've probably fallen into the "10x" camp myself at certain points in my career, and it was absolutely due to these factors. I should also add that having a general expertise of the problem domain and environment are enormous boosters as well.
Of course the moment I'm considered "fungible" and moved to a project I'm not passionate about at all, I'm pretty sure this evaporates entirely.
I've probably fallen into the "10x" camp myself at certain points in my career, and it was absolutely due to these factors. I should also add that having a general expertise of the problem domain and environment are enormous boosters as well.
Of course the moment I'm considered "fungible" and moved to a project I'm not passionate about at all, I'm pretty sure this evaporates entirely.
Yep. I've seen 10x engineers become -1x when shoved into projects they hated. Their contribution became net negative to the project.
And then return to 10x when transferred back to projects they enjoyed.
And then return to 10x when transferred back to projects they enjoyed.
But there's so much work that just has to be done, whether anyone loves it or not. For that, I think reliable mediocrity is a fine objective.
There may be 10x engineers. But what I know for sure is, that there are engineers (or engineering teams) which make you perform at 1/10x of what you might have, by mis-carefully laying a minefield of:
* 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.
* 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.
More broadly, the 10x engineer makes sure there are no such minefields.
They make sure there are nearly zero hurdles to getting in the zone.
They make sure there are nearly zero hurdles to getting in the zone.
Ah, no, quite the contrary.
The person who makes sure there are no such minefields makes a lot less great advances him/herself - they're busy working in a careful, orderly and considerate manner. And then the other engineers perform close to his/her level. That's not the 10x engineer.
However, the person who lays the minefield may only be a 1x person talent-wise, but since he puts his colleagues on 0.1x, s/he is effectively the 10x engineer of that team.
The person who makes sure there are no such minefields makes a lot less great advances him/herself - they're busy working in a careful, orderly and considerate manner. And then the other engineers perform close to his/her level. That's not the 10x engineer.
However, the person who lays the minefield may only be a 1x person talent-wise, but since he puts his colleagues on 0.1x, s/he is effectively the 10x engineer of that team.
If people can perform so much despite the minefields, then these are not minefields.
If we agree that they are minefields that impede programmer's performance, then by definition someone who does not make sure these mines are never introduced in the first place will outperform those who just leave them all over the place.
> they're busy working in a careful, orderly and considerate manner.
Actually no. It only takes very little initial effort. He spends most of his time producing actual work.
Meanwhile, other people spend a considerable amount of their time fighting against bad tools and bad development environments.
Worse, they might not spend a whole lot of "total" time fighting against the minefields, but their presence ensures they can never get in the zone (flow) and thus they always perform worse than their potential.
If we agree that they are minefields that impede programmer's performance, then by definition someone who does not make sure these mines are never introduced in the first place will outperform those who just leave them all over the place.
> they're busy working in a careful, orderly and considerate manner.
Actually no. It only takes very little initial effort. He spends most of his time producing actual work.
Meanwhile, other people spend a considerable amount of their time fighting against bad tools and bad development environments.
Worse, they might not spend a whole lot of "total" time fighting against the minefields, but their presence ensures they can never get in the zone (flow) and thus they always perform worse than their potential.
Almost by definition, the 10x engineer is the one who is in a position to reuse and work within his own code, almost exclusively, rather than navigate the minefields laid by others.
The 1x engineer is a normal one who builds upon the work of other 1x people.
The 0.1x engineer is the one who builds upon the 10x engineer's work.
The 1x engineer is a normal one who builds upon the work of other 1x people.
The 0.1x engineer is the one who builds upon the 10x engineer's work.
Seems more like time pressure than incompetence to me.
Anyone who has working in software for any length of time will have come across people who deliver orders of magnitude more high quality work than their peers: high output, high quality -- the 10xer. This post confuses that archetype with the similar-but-different high output, low quality archetype -- AKA the "cowboy", "hero", "prima donna".
It's a completely context-dependent assessment.
I was part of a team a few years back where I was certainly not a 10x dev. It was a team of... around 8-9 folks. 5-6 devs, PM, testers. There were jr/sr divides, but it was relatively smooth. My 20+ years of experience were helpful, but I wasn't 10x more productive than some of the lesser experienced folks on the team, and given the constraints and role I was in, there really wasn't a way to achieve that.
I've been on other projects where the experience level and other factors really exacerbate differences, and I've absolutely been "10x" in comparison to the others on the project.
The larger problems may come in with how you're treated, how you're viewed by management, etc.
"In a controlled environment, the variation between most software engineers is much more modest."
Well yes, but we don't usually work in controlled environments. With similar backgrounds/experiences, and strict project management controls in place, there's going to be far less variance possible.
I was part of a team a few years back where I was certainly not a 10x dev. It was a team of... around 8-9 folks. 5-6 devs, PM, testers. There were jr/sr divides, but it was relatively smooth. My 20+ years of experience were helpful, but I wasn't 10x more productive than some of the lesser experienced folks on the team, and given the constraints and role I was in, there really wasn't a way to achieve that.
I've been on other projects where the experience level and other factors really exacerbate differences, and I've absolutely been "10x" in comparison to the others on the project.
The larger problems may come in with how you're treated, how you're viewed by management, etc.
"In a controlled environment, the variation between most software engineers is much more modest."
Well yes, but we don't usually work in controlled environments. With similar backgrounds/experiences, and strict project management controls in place, there's going to be far less variance possible.
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.
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.
I don’t think that’s a fair labeling; from my experience ”cobbled-together, broken apps” are the result of taking the MVP approach to continuous development due to time constraints imposed by management due to contracts sold too cheap by sales directors.
The failure of a software project begins at the contract stage. This gives salespeople a measure of control over the developers, and it is in their interests to increase developer stress by selling more things cheaper.
The worst part is that salespeople are prone to corruption: if they can make a client company pay less for a service, the company may hand over a part of their savings. This is difficult to control, as the kickbacks may come in material or immaterial forms.
The effects of the corruption are very real to the organisation, which now puts undue stress on developers with projects that are designed to fail just enough to trigger contractual clauses in benefit of the buyer.
The failure of a software project begins at the contract stage. This gives salespeople a measure of control over the developers, and it is in their interests to increase developer stress by selling more things cheaper.
The worst part is that salespeople are prone to corruption: if they can make a client company pay less for a service, the company may hand over a part of their savings. This is difficult to control, as the kickbacks may come in material or immaterial forms.
The effects of the corruption are very real to the organisation, which now puts undue stress on developers with projects that are designed to fail just enough to trigger contractual clauses in benefit of the buyer.
> people take it to mean someone who cobbles together broken apps at a rapid pace and gets credit from management for being a hero
I agree, but as you say, this is more often than not the definition used (unconsciously) by management. Management considers this person the 10x and others consider them the -1x.
And yet.. these developers are also great though, in their niche. It's awesome to have someone on the team who can whip up the demoware in an evening for investors and customers! Even when I'd rather they never commit anything to the product source.
Which is why this discussion of finding who is the 10x is misguided. Turns out people excel at different things. Good management will identify what everyone is best at and have them focused on that. Bad management will shoehorn people into the wrong roles and set them up for failure.
I agree, but as you say, this is more often than not the definition used (unconsciously) by management. Management considers this person the 10x and others consider them the -1x.
And yet.. these developers are also great though, in their niche. It's awesome to have someone on the team who can whip up the demoware in an evening for investors and customers! Even when I'd rather they never commit anything to the product source.
Which is why this discussion of finding who is the 10x is misguided. Turns out people excel at different things. Good management will identify what everyone is best at and have them focused on that. Bad management will shoehorn people into the wrong roles and set them up for failure.
Like some football players, some software engineers are a LOT better than others.
The measurement is value in $, which easily can be translated to 10x-1000x better.
The measurement is value in $, which easily can be translated to 10x-1000x better.
I think this is a nice strawman. The difference between an engineer that writes truly good code and pushes the team forward, and one that is simply the only one left that understands their own mess should be obvious to anyone, except maybe the most stereotypically clueless manager.
"10x" is obviously a buzzword and not a literal measurement, but is there any real doubt that productivity differences exist? Or is is just fashionable to not admit this anymore?
"10x" is obviously a buzzword and not a literal measurement, but is there any real doubt that productivity differences exist? Or is is just fashionable to not admit this anymore?
I don't even consider myself a very good developer but I work hard, I have discipline and commitment, and I focus on getting the work done. This made me 10x engineer in most of the teams I worked.
And for a few years I had it well measured because I was working with the same app and I was estimating all the tasks for me and the others with high precision to my own performance. The manager understood that other team members wouldn't follow my pace since they were less familiar with the app, and it was OK for him to estimate 2x or 3x the time when planning. But at the end it showed that I was average 8x faster (and with better quality) which was not justified since they were also senior even they knew the app a bit less.
The worst part is that I was earning much less than them due to location... but at least I could justify a request for a 15% raise which was given with no hesitation.
And for a few years I had it well measured because I was working with the same app and I was estimating all the tasks for me and the others with high precision to my own performance. The manager understood that other team members wouldn't follow my pace since they were less familiar with the app, and it was OK for him to estimate 2x or 3x the time when planning. But at the end it showed that I was average 8x faster (and with better quality) which was not justified since they were also senior even they knew the app a bit less.
The worst part is that I was earning much less than them due to location... but at least I could justify a request for a 15% raise which was given with no hesitation.
The fact that this is constantly debated is sad. I've run numerous tests across various organisations. When measured it becomes evident that 10x is nothing strange.
Set some real world useful target. Give the task to individuals or small teams and let them go at it, with regular followup. Measure time, defects, maintainability, whatnot. Perhaps add some real world change of requirements mid stream? I've seen solutions ranging from hours to never.
What I see, and find very sad, is that most organisations have obstinately obtuse attitudes and handling of such simple analysis.
It doesn't matter if the variance stems from intelligence, creativity, work pattern, experience, clever tricks, tools, processes, etc, etc. If it's faster/better then find out why, and learn from it. Can it be taught to others? Change work processes? Hire differently? ???
Whatever works. But ffs: measure, analyse, learn, embrace.
Set some real world useful target. Give the task to individuals or small teams and let them go at it, with regular followup. Measure time, defects, maintainability, whatnot. Perhaps add some real world change of requirements mid stream? I've seen solutions ranging from hours to never.
What I see, and find very sad, is that most organisations have obstinately obtuse attitudes and handling of such simple analysis.
It doesn't matter if the variance stems from intelligence, creativity, work pattern, experience, clever tricks, tools, processes, etc, etc. If it's faster/better then find out why, and learn from it. Can it be taught to others? Change work processes? Hire differently? ???
Whatever works. But ffs: measure, analyse, learn, embrace.
I have a different take on 10x Engineers.
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.
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.
> One of the most interesting recent studies comes to a very different conclusion. In a controlled environment, the variation between most software engineers is much more modest.
This is a silly comparison. The engineers I've worked with in my career that stand out don't stand out because they can write for-loops faster than others or public-class-Foo-public-static-void-main-string-args-System.out.println-hello faster than others. They are much more productive because they are better at ensuring they understand the problems they're trying to solve, and solving the problem with the least amount of superfluous work.
> No one talked about the fact that this particular developer had been developing the same system for the past 15 years, the first five almost alone. He relished being “the best." Wrote hard-to-understand procedural code to 5000-line files. Did not actively share knowledge with his peers. Over the years, some capable developers had joined the company. Most of them decided to move on. The ones left were happy to coast along and leave all the heroics to the “10x engineer.” As a result, the company had great difficulties in trying to scale its development efforts.
This example seems like a counter-example to me. It's important to separate out one's (potentially flawed) judgement vs the actual value an engineer brings. This engineer made everyone else less productive. Simply calling someone a "10x engineer" does not make it so.
> The best strategy for most companies is not a relentless focus on trying to hire “the best” in hopes of finding 10x unicorn engineers.
The rest of the article is a distraction from this generally good piece of advice. For many things, finding a competent programmer familiar with your tools and stack who can write the CRUD operations you need should be acceptable. A lot of software engineering interviewing distracts from this, with gotcha trivia questions about whether one can recite from memory algorithms from a text book that are not relevant to the work.
This is a silly comparison. The engineers I've worked with in my career that stand out don't stand out because they can write for-loops faster than others or public-class-Foo-public-static-void-main-string-args-System.out.println-hello faster than others. They are much more productive because they are better at ensuring they understand the problems they're trying to solve, and solving the problem with the least amount of superfluous work.
> No one talked about the fact that this particular developer had been developing the same system for the past 15 years, the first five almost alone. He relished being “the best." Wrote hard-to-understand procedural code to 5000-line files. Did not actively share knowledge with his peers. Over the years, some capable developers had joined the company. Most of them decided to move on. The ones left were happy to coast along and leave all the heroics to the “10x engineer.” As a result, the company had great difficulties in trying to scale its development efforts.
This example seems like a counter-example to me. It's important to separate out one's (potentially flawed) judgement vs the actual value an engineer brings. This engineer made everyone else less productive. Simply calling someone a "10x engineer" does not make it so.
> The best strategy for most companies is not a relentless focus on trying to hire “the best” in hopes of finding 10x unicorn engineers.
The rest of the article is a distraction from this generally good piece of advice. For many things, finding a competent programmer familiar with your tools and stack who can write the CRUD operations you need should be acceptable. A lot of software engineering interviewing distracts from this, with gotcha trivia questions about whether one can recite from memory algorithms from a text book that are not relevant to the work.
The point of the article is not whether 10x factors have been observed, the point is that (in all cases the author has seen) they are dependent on circumstances/environment and not the individual.
Implicitly, he invites readers to re-evaluate their experiences.
To me, this rings true for most mundane organizations (not id software).
Implicitly, he invites readers to re-evaluate their experiences.
To me, this rings true for most mundane organizations (not id software).
Doesn't really bust the myth, though does it? Just says that the 10x engineer is a sign that the company may be in trouble, depending too heavily in such engineers.
From 25 years in electronic engineering, I guarantee that there are some engineers that are 5x or 10x others.
A fact I notice in a lot of teams and orgs, valid for both this and the 'heroes' discussion:
Every organisational silo has,in the long term, exactly one 10x engineer, a.k.a hero.
If there is no hero, the organisational silo will fail unless someone cares enough to take the role. If there is a hero, the need for a second one disappears. If a hero falls away, you'll have a few months of chaos after which a new hero appears.
People will naturally give problems and hard projects to the best available person, and generally people agree who that us. So one person with a slight edge gets all the training and quickly gets much better.
Heros are a consequence of organizational barriers.
Update: That last part is inexact. Heros are a consequence of knowledge barriers.
Every organisational silo has,in the long term, exactly one 10x engineer, a.k.a hero.
If there is no hero, the organisational silo will fail unless someone cares enough to take the role. If there is a hero, the need for a second one disappears. If a hero falls away, you'll have a few months of chaos after which a new hero appears.
People will naturally give problems and hard projects to the best available person, and generally people agree who that us. So one person with a slight edge gets all the training and quickly gets much better.
Heros are a consequence of organizational barriers.
Update: That last part is inexact. Heros are a consequence of knowledge barriers.
> Heros are a consequence of organizational barriers.
Or organizational barriers are a consequence of heros?
Or organizational barriers are a consequence of heros?
The article seems to argue that you shouldn't focus specifically on hiring 10x engineers, not that they don't exist at all.
Bad/clickbait title?
Some people seem really uncomfortable with the idea that individual performance can vary massively from person to person.
Bad/clickbait title?
Some people seem really uncomfortable with the idea that individual performance can vary massively from person to person.
The article seems to make and fight a strawman argument, making a supposed 10x engineer a problem for information sharing, teamwork, etc.
In my experience, it is quite the opposite: while very few of the 10x engineer are indeed "leave me alone to solve hard problems; figure out yourself how to maintain my solutions within the enterprise", the majority makes simple, robust designs that are easier, not harder for the team to understand and maintain. And when they leave, they generally leave behind a system that is stable and does not need day-to-day meddling from a senior engineer, which gives enough time to find a replacement. My 2c.
In my experience, it is quite the opposite: while very few of the 10x engineer are indeed "leave me alone to solve hard problems; figure out yourself how to maintain my solutions within the enterprise", the majority makes simple, robust designs that are easier, not harder for the team to understand and maintain. And when they leave, they generally leave behind a system that is stable and does not need day-to-day meddling from a senior engineer, which gives enough time to find a replacement. My 2c.
It's not like there are 10x engineers, it's so many 0.1x ones that a 1x one is nowadays seen as something of a miracle.
If you have a team of decent developers then I think the article has a point. But imagine you're in a situation where 90% of the developers on your team are outsource contractors with below junior level of aptitude who have been up-marketed by talent agencies as "senior architects" and "technical leads." Now 10x makes a bit more sense.
Organizations with poor technical leadership fail to quality control hires and accumulate imposters. In this setting the lucky hire of a merely average developer creates the appearance of a 10x (or 100x) unicorn.
Organizations with poor technical leadership fail to quality control hires and accumulate imposters. In this setting the lucky hire of a merely average developer creates the appearance of a 10x (or 100x) unicorn.
> In a controlled environment, the variation between most software engineers is much more modest.
I have a feeling the writing has never worked with 10x developers. You know, everyone knows, that there's a galactic difference between the average team member vs that 10x in the corner crafting code like an artist chiseling into a block of marble.
... and then there's that awe inspiring, humbling privilege when you score getting onto a team where everyone are 10x-er.
The variation between most software engineers isn't modest, it's a Mariana Trench of a difference.
I have a feeling the writing has never worked with 10x developers. You know, everyone knows, that there's a galactic difference between the average team member vs that 10x in the corner crafting code like an artist chiseling into a block of marble.
... and then there's that awe inspiring, humbling privilege when you score getting onto a team where everyone are 10x-er.
The variation between most software engineers isn't modest, it's a Mariana Trench of a difference.
10x software engineers are mostly 10x problem solvers who happen to be programmers. The driving attitude is refusing to work hard to accomplish something of low significance, which is mostly done thanks to: finding clever solutions, reducing feedback loops when debugging or testing, gaining proper understanding of systems to avoid empirical tweaking, asking around quickly when getting stuck, and also cleverly navigating company politics in order to ship something in environments where it is hard.
> 10x software engineers are mostly 10x problem solvers who happen to be programmers
I don't think it's just about problem solving, as in "solving a math problem". The 10x is, I believe, the combination of different factors:
- Knowing you language and its ecosystem by heart: 2X
- Knowing your codebase by heart: 2X
- Mastering your tools (IDE/editor, Git,...), perhaps making your own tools: 2X
- Using good development methodology (e.g. limit trial-and-error or do it thoughtfully): 2X
- Being unsocial so people think twice before interrupting you: 1.5X
So in my opinion, on the contrary being a 10X engineer has a lot to do with being a good programmer.
I don't think it's just about problem solving, as in "solving a math problem". The 10x is, I believe, the combination of different factors:
- Knowing you language and its ecosystem by heart: 2X
- Knowing your codebase by heart: 2X
- Mastering your tools (IDE/editor, Git,...), perhaps making your own tools: 2X
- Using good development methodology (e.g. limit trial-and-error or do it thoughtfully): 2X
- Being unsocial so people think twice before interrupting you: 1.5X
So in my opinion, on the contrary being a 10X engineer has a lot to do with being a good programmer.
> cleverly navigating company politics in order to ship something in environments
conversely, company politics can be a reason why someone could be 10x in one setup and a complete dud in another.
conversely, company politics can be a reason why someone could be 10x in one setup and a complete dud in another.
Ari-Pekka makes various plausible-sounding declarations, but he doesn't even try to make a case.
I know that I've had many colleagues that were next to useless - even, possibly, exhibiting negative utility. Let's just give that kind a zero. Then there are novices - smart people with little experience. They can get stuff done, but they need watching. Suppose we give those a 1. And suppose we give an "average" dev, fairly smart, with a lot of experience, a 2. Such a person doesn't need watching, and gets stuff done.
I'd say a zero needs to find more suitable work.
A 1 is worth investing in.
A 2 is most good professional devs.
So what's this x10 fellow? Well, I rate myself as a 2. I'm a journeyman, and I'll never be a master. But the people I've met that I'd rate as "masters" were no more than twice as productive as I was.
I can't imagine a dev that was 10x as productive as a journeyman. I've certainly never met one. Software development is a process of discovering and remedying bugs - from the requirements, through the design, to the implementation. These things take roughly the same amount of time, whether you are a journeyman or a "master". And once you have identified the problem, the solution is usually fairly obvious.
If this notion of a 10x dev is a real thing, then I suspect it arises in people who regard technology as some kind of woo. If you're recruiting a magician, then he'd better be better than any other magician, because you don't know magic.
I know that I've had many colleagues that were next to useless - even, possibly, exhibiting negative utility. Let's just give that kind a zero. Then there are novices - smart people with little experience. They can get stuff done, but they need watching. Suppose we give those a 1. And suppose we give an "average" dev, fairly smart, with a lot of experience, a 2. Such a person doesn't need watching, and gets stuff done.
I'd say a zero needs to find more suitable work.
A 1 is worth investing in.
A 2 is most good professional devs.
So what's this x10 fellow? Well, I rate myself as a 2. I'm a journeyman, and I'll never be a master. But the people I've met that I'd rate as "masters" were no more than twice as productive as I was.
I can't imagine a dev that was 10x as productive as a journeyman. I've certainly never met one. Software development is a process of discovering and remedying bugs - from the requirements, through the design, to the implementation. These things take roughly the same amount of time, whether you are a journeyman or a "master". And once you have identified the problem, the solution is usually fairly obvious.
If this notion of a 10x dev is a real thing, then I suspect it arises in people who regard technology as some kind of woo. If you're recruiting a magician, then he'd better be better than any other magician, because you don't know magic.
The best developers don't add utility just by their own direct productivity, they add utility by increasing the productivity of the team (pointing people in directions that avoid dead ends, helping quickly bust impediments, etc., contributing in design discussions in a way which reduces the amount of unnecessary code that ever gets written, etc.) This is a much bigger effect (IME) than the delta in personal direct coding output.
> Software development is a process of discovering and remedying bugs - from the requirements, through the design, to the implementation
The fastest developers are those who barely put in bugs in the first place not those who are good at finding the bugs they themselves put in.
Example: Two developers writes half of a project. Developer A's code has 10 bugs, developer B's code has 1 bug. They both work together to fix the bugs, developer A fixed 4 of A's bugs while B fixed 6 of A's bug and his own bug. In total A fixed 4 and B fixed 7. In this case it looks like B was almost twice as effective, but if B didn't have to fix A's bugs he would have been way faster, especially since fixing others bugs is way harder than fixing your own.
The fastest developers are those who barely put in bugs in the first place not those who are good at finding the bugs they themselves put in.
Example: Two developers writes half of a project. Developer A's code has 10 bugs, developer B's code has 1 bug. They both work together to fix the bugs, developer A fixed 4 of A's bugs while B fixed 6 of A's bug and his own bug. In total A fixed 4 and B fixed 7. In this case it looks like B was almost twice as effective, but if B didn't have to fix A's bugs he would have been way faster, especially since fixing others bugs is way harder than fixing your own.
I don't like your example.
Dev B had a much richer target-environment than A.
And I don't agree that fixing other people's bugs is harder than fixing your own. It's human nature to be blind to your own mistakes.
Dev B had a much richer target-environment than A.
And I don't agree that fixing other people's bugs is harder than fixing your own. It's human nature to be blind to your own mistakes.
The 10x is in comparison to the least productive engineer. In your model they get a zero so you actually have infinity x.
Score your zero up slightly to 0.2 and a 10x is now a 2.
It’s not so drastic a claim really. The common misinterpretation is that it’s 10x the average.
Score your zero up slightly to 0.2 and a 10x is now a 2.
It’s not so drastic a claim really. The common misinterpretation is that it’s 10x the average.
Well, yes, I was thinking the same way.
But I'm aware that many of those I've rated zero are actually something negative, as in "Please stop writing code" (I was trying to be generous). I'm thinking of people with personality defects, who are also novice coders, who also think they're God's gift, and therefore won't take advice.
So the score is a continuum, and there are negative (and zero) values. If that conflicts with the "x10" concept, then I'm not unhappy.
I'm also conscious of the notion that some super-clever people can unexpectedly wreck an organisation or team, instead of sparking it off. It's not insane to think of a -x4 dev. Very smart, but anyone picking up his work has a mountain to climb.
But I'm aware that many of those I've rated zero are actually something negative, as in "Please stop writing code" (I was trying to be generous). I'm thinking of people with personality defects, who are also novice coders, who also think they're God's gift, and therefore won't take advice.
So the score is a continuum, and there are negative (and zero) values. If that conflicts with the "x10" concept, then I'm not unhappy.
I'm also conscious of the notion that some super-clever people can unexpectedly wreck an organisation or team, instead of sparking it off. It's not insane to think of a -x4 dev. Very smart, but anyone picking up his work has a mountain to climb.
I just wish employers would stop focusing on hiring 10x engineers, and instead focus on how to create an environment in which the overall standard can improve. What I mean is - you can take a superior engineer and put them in a crappy environment, and they will fail. Likewise, you can take an average engineer and surround them with support and they will produce a multiple of their raw talent. Focus on the things that make it possible to produce at a high level. For that matter, it strikes me that often those people that companies believe are producing at a high level, aren't. I saw this a lot in consulting - companies think Jimmy is just the bees knees, but in fact the reason he looks like a hero is that his junk is broken and he's constantly having to firefight to fix it. Often too, the loudest engineer in the room shouts down everyone else and "looks" like a leader when they are really the villain.
I saw for myself - there were places in my career where I was super productive, and places where I hardly produced anything. It had everything to do with the environment: politics, communication style, teammates, technology, and problem domain.
I saw for myself - there were places in my career where I was super productive, and places where I hardly produced anything. It had everything to do with the environment: politics, communication style, teammates, technology, and problem domain.
I am currently becoming so sick of WFH and boring to-dos that I am making the 10x software engineer myth true for all of you. You can thank me later.
This is a colossal strawman of an article, suggesting that a 10x engineer is someone who simply churns out features faster with a high degree of technical debt. It also talks about the "science of 10x engineers" being shoddy, and tends to regress to the mean under "controlled environments".
This entire discussion is deep in pointy-haired boss territory. First of all, creation and derivation of value from software is not "a controlled environment". Attempting to define things such that you can measure them means that whatever individual strengths and abilities people have will be washed out along with whatever advantages they could confer to the organization. As much as management wants to commodify programmers and treat it as an assembly line, programming remains a craft. It's not construction to a blueprint, but rather architect, engineer and builder all rolled into one—and the output is data and UI interactions with abstract purposes and mental models, not physical buildings with very straightforward goals and constraints.
The truth of the 10x engineer (or 100x or 1000x) is not that they code the same thing faster, it's that they find a better path. There are many different archetypes of this, you can't measure it, and you certainly can't hire for it, but with experience you can definitely see the impact of the smarter abstraction, the better anticipation of future requirements, the judicious application of YAGNI.
As an engineering manager the size of what you can accomplish is limited primarily by how you structure the team and give everyone the opportunity to play to their strengths. It's not about adding process and bureaucracy to ensure everyone feels equal, it's about setting up shared goals and fostering a sense of camaradarie so that natural leadership can emerge and everyone can do their best work.
This entire discussion is deep in pointy-haired boss territory. First of all, creation and derivation of value from software is not "a controlled environment". Attempting to define things such that you can measure them means that whatever individual strengths and abilities people have will be washed out along with whatever advantages they could confer to the organization. As much as management wants to commodify programmers and treat it as an assembly line, programming remains a craft. It's not construction to a blueprint, but rather architect, engineer and builder all rolled into one—and the output is data and UI interactions with abstract purposes and mental models, not physical buildings with very straightforward goals and constraints.
The truth of the 10x engineer (or 100x or 1000x) is not that they code the same thing faster, it's that they find a better path. There are many different archetypes of this, you can't measure it, and you certainly can't hire for it, but with experience you can definitely see the impact of the smarter abstraction, the better anticipation of future requirements, the judicious application of YAGNI.
As an engineering manager the size of what you can accomplish is limited primarily by how you structure the team and give everyone the opportunity to play to their strengths. It's not about adding process and bureaucracy to ensure everyone feels equal, it's about setting up shared goals and fostering a sense of camaradarie so that natural leadership can emerge and everyone can do their best work.
Well, my experience is that to increase productivity the most important thing is not doing things. If you can filter out the meaningless features and shut down products that are a product of politics (giving someone a product to keep them happy even though everyone thinks it useless) you can increase productivity much more than focusing on the technical aspects of development.
Very sf-type of term, is it still in use? From an eu perspective the idea to rely on some members of your team to be 10 times more productive than others seems like a terrible idea for anything longer than a 1 month sprint. That's not to say people's raw smartness, competence and experiences are the same just that a better focus would be growing the team as a whole.
> From an eu perspective the idea to rely on some members of your team to be 10 times more productive than others seems like a terrible idea
It's just less socially acceptable to say it out loud, doesn't make it any less true. If anything, 10 is a conservative estimation: the spectrum spans orders of magnitude.
> a better focus would be growing the team as a whole
Not mutually exclusive. Prima donna behavior is always inexcusable. If you can't work with others you're not 10x, you're 0x.
It's just less socially acceptable to say it out loud, doesn't make it any less true. If anything, 10 is a conservative estimation: the spectrum spans orders of magnitude.
> a better focus would be growing the team as a whole
Not mutually exclusive. Prima donna behavior is always inexcusable. If you can't work with others you're not 10x, you're 0x.
Strange that always the 10x is blamed for communication issues. The passive aggressive 1x, who try to undermine him, are a group and as such always right.
I haven't seen a true 10x who was still writing code and growing the team. Time does not permit that, it is a fantasy. There are team growing "10x" engineers who shamelessly take the credit for everything.
I haven't seen a true 10x who was still writing code and growing the team. Time does not permit that, it is a fantasy. There are team growing "10x" engineers who shamelessly take the credit for everything.
> Very sf-type of term, is it still in use?
Yeah, I've never seen it outside the SF bubble.
Where everyone seems to think they are the 10x, and everyone around them is a dolt.
Yeah, I've never seen it outside the SF bubble.
Where everyone seems to think they are the 10x, and everyone around them is a dolt.
Whether or not "10x" exists depend on what "x" is. Some companies have very high hiring standards, so there the "1x" may be high enough that "10x" becomes really unlikely. But some companies hire almost anyone who can walk, and then "x"<=0, making 10x pretty achievable.
I even expect that some consulting firms to this on purpose, at least if they sell services to customers that are put off by paying according to the value generated by the best developers, they bundle the best developers with teams of low-paid underachievers, where the lead is 10x as productive as those, and where the total output still matches customer expectations. Instead of paying $1000/h for one person they pay $1500/h for a team of 10 people, even if that one person could have more or less done everything on his own.
I even expect that some consulting firms to this on purpose, at least if they sell services to customers that are put off by paying according to the value generated by the best developers, they bundle the best developers with teams of low-paid underachievers, where the lead is 10x as productive as those, and where the total output still matches customer expectations. Instead of paying $1000/h for one person they pay $1500/h for a team of 10 people, even if that one person could have more or less done everything on his own.
If you haven't worked with one, you might believe it's a myth. Some folks, in the right place at the right time, are just better. Probably way more than 10x better, but dragged down by the same meetings overhead, at more than 10x the cost for no benefit, as everyone else. No I'm not one of them.
Pssh. As something of an outsider, its far worse than "10x." There's just a fundamental mismatch here, which I think is the elephant in the room. Where there are people like Linus Torvalds and Kovid Goyal, you just don't need that many software makers in the way we do it now, unlike the way you need at least X amount of construction workers or dentists.
Which, I believe, is not to say you can't have that many people working in IT, but a major shift of thinking is required. Software shouldn't be a product, and I'd go even further to say that it shouldn't even be a deeply centralized service. Rather, a lot of IT pros helping smaller individuals solve problems (and just happen to use software while doing it, in the way that e.g. astronomers happen to use math) would be best.
Which, I believe, is not to say you can't have that many people working in IT, but a major shift of thinking is required. Software shouldn't be a product, and I'd go even further to say that it shouldn't even be a deeply centralized service. Rather, a lot of IT pros helping smaller individuals solve problems (and just happen to use software while doing it, in the way that e.g. astronomers happen to use math) would be best.
Why do you think Ari-Pekka believes it’s the organization of engineers that creates long-term sustainable productivity?
Hint: What does Ari-Pekka do for a living?
Most people want to believe that what they do is the unique secret sauce of value creation, and they want others to believe it too. This is basically what you call politics.
Hint: What does Ari-Pekka do for a living?
Most people want to believe that what they do is the unique secret sauce of value creation, and they want others to believe it too. This is basically what you call politics.
[deleted]
[deleted]
IMO the 10x engineer is not someone who is 10x more productive than their peers. It's the person who will identify and solve critical engineering design questions far in advance, such that if you took them out of the team, the team would be 10x less valuable.
A 10x Software Engineer is not somebody that can write programs 10 times faster. A 10x SE can solve problems that are 10x more complex. Because a 10x SE has a higher understanding and is able make design simplications and create better abstractions that allows her to not get lost on the complexity.
Case in point. I have similar years of experience as Linus Torvalds and feel I am pretty good SE, but I couldn't have written git. Because his understanding is in a different level. I am able to understand how git works, but he was able to come up with the concept. I was happily using subversion but he knew what needed to be different and how to implement it. It is just another level.
Case in point. I have similar years of experience as Linus Torvalds and feel I am pretty good SE, but I couldn't have written git. Because his understanding is in a different level. I am able to understand how git works, but he was able to come up with the concept. I was happily using subversion but he knew what needed to be different and how to implement it. It is just another level.
Assign a work of an enginner to 10 engineers and it will become a work of 10 engineers. My experience is "10x engineers" are ones who work alone in independent manner, removing all dependencies that can potentially pin down their progress.
"10x engineers" definitely do exist. Anyone who doesn't believe in 10x engineers just hasn't met one yet.
I've had the pleasure of working with two 10x engineers. One of them is a problem-solving and execution machine. I could understand what he did, and I think that I could have done the same, only taking 10x longer.
The other one... the other one isn't just a "faster me". His brain works on a qualitatively different way than mine. I probably couldn't have come up with the things he came up with, even with 10x or 100x more time.
These guys are also incredibly humble and nice, and hilariously funny. Fantastic humans all around. Stu, Matt, I miss you guys!
I've had the pleasure of working with two 10x engineers. One of them is a problem-solving and execution machine. I could understand what he did, and I think that I could have done the same, only taking 10x longer.
The other one... the other one isn't just a "faster me". His brain works on a qualitatively different way than mine. I probably couldn't have come up with the things he came up with, even with 10x or 100x more time.
These guys are also incredibly humble and nice, and hilariously funny. Fantastic humans all around. Stu, Matt, I miss you guys!
> Anyone who doesn't believe in 10x engineers just hasn't met one yet.
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.
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.
Fair enough.
I have worked with 10x developers. And I have worked with -1x developers (stopping them from working made everybody else productive). Without the 10x developers things wouldn’t get done. Your demo/prototype wouldn’t be ready in time to secure the contract. Your production problems wouldn’t be solved fast. I suspect that certain (average) developers are jealous of the attention 10x developers (rightly) get. That’s understandable. But pretending that 10x developers doesn’t exist is silly. It’s like pretending that world class musicians/engineers/artists/… doesn’t exist.
There absolutely are different levels of talent between coders. But it is more nuanced than that - I rarely see anyone who is 10X better than everyone else at everything. But I do see someone who rocks one specific type of coding, while they are slow at others. Figuring out what skills you really need on your team, hiring the people who excel at those specific skills, and letting people spend most of their time in the area where they excel is how you get a high performing team. Also a pigeonholed team, though - there is balancing to be done in the long run.
The unit of software delivery agency is a team not an individual any more. That was in the days of Norton Disk Doctor where a single programmer held the whole problem in their head.
The question that is lost in the noise about 10x is “Does a team with a 10x programmer deliver software better faster cheaper than a team without one. More formally is a team with a power law distribution of talent more productive than a team with a normal distribution of talent.”
That is IMHO the question that really matters in terms of modern software delivery. Any thoughts on this question?
The question that is lost in the noise about 10x is “Does a team with a 10x programmer deliver software better faster cheaper than a team without one. More formally is a team with a power law distribution of talent more productive than a team with a normal distribution of talent.”
That is IMHO the question that really matters in terms of modern software delivery. Any thoughts on this question?
The solution proposed is not good because it presents “hire 10x” and “support 1x” as some sort of exclusive options.
Of course, the smart choice for orgs is to do both. If I had to choose a single (and I don’t) I’d go with a few 10x progs over dozens of 1x because small teams work better in general due to coordination overhead.
This is no excuse for letting 10x be jerks and I would probably run away from any hiring notice that talked about 10x. I think this follows my observation that smart people don’t talk about being smart, they be smart.
Of course, the smart choice for orgs is to do both. If I had to choose a single (and I don’t) I’d go with a few 10x progs over dozens of 1x because small teams work better in general due to coordination overhead.
This is no excuse for letting 10x be jerks and I would probably run away from any hiring notice that talked about 10x. I think this follows my observation that smart people don’t talk about being smart, they be smart.
For a lot of basic crud software something is very wrong if there is even a possibility of having a 10x engineer. I worked on a project that was basically just forms. Should have been really basic, anything a junior engineer could build. Nope! The 10x engineer instead built out his own form library. Incredibly difficult to use, obviously undocumented, extremely buggy. To build static forms with a little bit of validation. So yeah he was a 10x engineer because he made everyone else a .1x engineer.
10x engineers most certainly exist, I've had the fortune of being able to work with a few and their true impact isn't in the code they themselves write but in the higher-level strategic/architectural decisions they make that impact the team as a whole. That being said it is also my experience that most self-described 10x engineers are anything but, so if one bases their impression of 10x engineers off those self-promoting cases then I can see how it would appear to be a myth
In many cases, I had to step into an Augean stable of code, i.e. a 10x dev had to deep dive into code produced by 10 1x dev. Coming out the other end, functionality went up by 50% with 40% less code.
Prior to being downsized at a multinational, I was asked to explain my database update scripts to a lady who had never seen SQL. Some of the queries took most of a page. That system slowly sank into the sunset. It's hard to do customer support when the database doesn't know about their new machines.
Prior to being downsized at a multinational, I was asked to explain my database update scripts to a lady who had never seen SQL. Some of the queries took most of a page. That system slowly sank into the sunset. It's hard to do customer support when the database doesn't know about their new machines.
[deleted]
Well, if there are software companies that have 1.5x growth and there are that produce 10x and some produce 100x growth, then by definition developers in the 100x company are 10x more efficient than those in 10x company, assuming the factor a developer plays in company growth is significant.
It feels like these myths busters are a bit left leaning.
Sames as a topic about whether Tim Cook deserves his huge pay/bonus, to which the answer to the left leaning academic is, can you find a replacement for him?
It feels like these myths busters are a bit left leaning.
Sames as a topic about whether Tim Cook deserves his huge pay/bonus, to which the answer to the left leaning academic is, can you find a replacement for him?
Anyone trying to ”bust this myth” are to me suspect of either selling snake oil or just trying to defend their own mediocrity.
If anything the problem is usually understated, as a big problem in larger teams become people who actually add negative net productivity to a team. Also, not to be forgotten (and also covered in books like Waltzing with bears) are people who act as multipliers to the whole team by making the team “gel”.
If anything the problem is usually understated, as a big problem in larger teams become people who actually add negative net productivity to a team. Also, not to be forgotten (and also covered in books like Waltzing with bears) are people who act as multipliers to the whole team by making the team “gel”.
My biggest problem with 10x is that I see it applied prescriptively not descriptively. If it's just describing some fact about someone's output then fine. If you've got the data to backup your 10x trophy then good for you but I don't want to hear some shit about someone being a 10x developer because someone else said they were.
You also don't get to be a 10x developer by kneecapping everyone around you.
You also don't get to be a 10x developer by kneecapping everyone around you.
[deleted]
It's weird to focus on time to solve a problem when the software field is full of examples of challenges where you need a great engineer to be able to create a working solution at all, and an average engineer could never in their lifetime produce a workable solution. What's the multiplier factor on these?
Whether or not some people in a given field are 10x more knowledgeable or productive than others is a question that can be answered.
Whether trying to find 10x programmers is a good HR strategy is a separate question.
This article is just a stream of consciousness brain dump, which I guess proves that 1/10x clickbait authors exist.
Whether trying to find 10x programmers is a good HR strategy is a separate question.
This article is just a stream of consciousness brain dump, which I guess proves that 1/10x clickbait authors exist.
Not sure about the exact number before the X, but remarkably capable people exist in every field of human endeavor including engineering.
I get the sense that some of this constant myth busting comes from HR people who want people to be interchangeable parts and don’t like it when they are not.
I get the sense that some of this constant myth busting comes from HR people who want people to be interchangeable parts and don’t like it when they are not.
In my experience, 100x absolutely exists. It can be sustained in areas where someone has considerable amounts of closely-related experience; however, when innovating, it is only sustainable for up to a few months at a time and with great sacrifice in one’s personal life.
You cannot bust it because most of us have empirical evidence of a 10x engineer (whether it's 10x, 20x, or merely 3x doesn't matter -- there are engineers who can and hold projects all by themselves, with top-notch code and utmost speed and quality design).
> The company's CEO would walk into the space where the developers worked and loudly comment – even to outsiders – “sometimes it feels like X is the only developer who gets anything done.”
Their analysis: 10X developers are a myth.
Alternative explanation: 0.1X managers are a reality.
Their analysis: 10X developers are a myth.
Alternative explanation: 0.1X managers are a reality.
[deleted]
I’m not a huge fan of the 10X thing. I always feel like it panders to one’s vanity. I’m just a normal guy who enjoys what he gets to create.
But I’ve worked with a lot of people over the years who I thought of as 0.1X. They often just don’t seem to care.
But I’ve worked with a lot of people over the years who I thought of as 0.1X. They often just don’t seem to care.
I think 0.1x (or even negative x) software engineers are more common. The ones that introduce bad bugs, don’t accept feedback, don’t communicate well with PM and design, always want to refactor things… they can take a whole team down.
Well in the age of livestreams you don't have to guess you can just watch them work. To me pretty clearly Jon Gjengset Rust streams are what would I call 10X, although it all depends on what you consider 1x to be :)
I've never seen anyone be 10X better than,
say, average consistently over a long
period of time.
But I've been 10X better than apparently average a few times a few weeks at a time. Uh, part of the reason for a few weeks at a time is that as part of the 10X I got the work done very quickly!
My 10X cases were all when the planets happened to line up just right and, to use a baseball analogy, the work to be done was like a slow pitch right in my best strike zone.
(1) I was seeing a girl, and she was an intern and working for someone who wanted her to work on some old Fortran code. She couldn't figure out why the code was giving totally garbage results.
I glanced at her code and saw where she passed the constant 2 as an argument to a subroutine. So, sure, that can be dangerous. I glanced at the subroutine and, yup, it was changing the corresponding parameter so for the rest of the execution of the program the constant 2 had the value given it by the subroutine and was not 2.
She worked a day or two on this, and I solved it in about 180 seconds.
Why? I'd seen that in Fortran usage before.
(2) I was in a software house working as a programmer and fast Fourier transform expert at a US Navy lab. Some engineers at the lab needed an extensive software project done and set up a competitive bidding situation. For one of the engineers, part of the work to be done was some power spectral estimation of ocean wave noise, that is, quite low frequency. Due to some earlier experience at GE, I knew the basics of the Wiener-Khinchin theorem and also got the Blackman-Tukey book on the statistics of power spectral estimation, typed in some code to generate synthetic ocean waves and accumulate and display the power spectra estimates, then called the engineer and we met and reviewed my work.
The main point I had for him was that for the very low frequencies he was interested in, he could need dozens of hours of data and with much less data than that would be looking at small sample statistical fluctuations instead of good estimates of the actual power spectrum. Likely I got these results in 10X. Our software house got "sole source" on the work.
(3) I was at Georgetown University consulting in applied math and teaching computer science courses when a friend from college called. He flew up to Georgetown with several other people, and we met. Everything was inconclusive -- no one had any definite, good ideas. The problem was scheduling the fleet for FedEx. That was important because some Members of the BoD questioned if the fleet could be scheduled at all; crucial funding was being held up; the company was at risk of going out of business.
Finally in the meeting I just blurted out that I would solve the problem. Six weeks later I had the software running which was also the end of the semester for my teaching. I flew to Memphis, ran my program, pleased the BoD, pleased the founder F. Smith ("solved the most important problem facing FedEx"), and saved the company. I suspect that in time, that was a 10X effort.
(4) I was working on a Navy project to support both my wife and myself through our Ph.D. degrees when the Navy wanted an evaluation of the survivability of the US SSBN (ballistic missile submarines) under a scenario of global nuclear war limited to sea. They wanted the results in two weeks. That timing just fit -- my wife had a vacation planned for us at Shenandoah just after the two weeks.
From a WWII paper by Koopman's, I saw a continuous time, discrete state space Markov process subordinated to a Poisson progress and wrote and ran the software, Monte Carlo. The software was fast enough that I could generate and average 1000 sample paths quickly.
During a peer-review, an objection was that there was no way I could "fathom the enormous state space". In response I mentioned that after, say, five days, the number of SSBNs left was a random variable; it was bounded and thus had an expectation; the expectation was finite; the random variable had a finite variance; the law of large numbers applied; and averaging 500 sample paths would give quite accurate estimates.
I explained that intuitively Monte Carlo put the effort where the action was, and the reviewer, a well-known probabilist, responded "That's a good way to look at it." My work passed the review.
A second person, actually two people, had been assigned as an independent effort. At the end of the two weeks, they made no progress at all.
The Navy got their results on time, and my wife got her vacation on time.
(5) When I arrived at Georgetown, a prof had just completed a statistics package. One of the routines was polynomial fitting, but on testing the numerical accuracy was poor. The prof had programmed normal equations, and on that problem the normal equations are close to the notoriously ill-conditioned Hilbert matrix. I wrote a replacement routine using some orthogonal polynomial methods and got accurate results.
(6) I was in an AI (artificial intelligence), expert systems, project at IBM's Watson lab, and we were developing IBM's language YES/L1. We wanted rule subroutines. Our code design was to (A) return one call at a time from the whole stack of dynamic descendancy, (B) execute the RETE algorithm run-time code, (C) rebuild the stack of dynamic descendancy. I saw serious semantic problems with this approach and the coding was to take some weeks. I got some dinner, wrote and ran some illustrative code, in effect to call back into the stack of dynamic descendancy, at dawn wrote email to our team, got some sleep, returned at noon, and our programmer on the work was done later that day. I got an IBM award for the work.
There were a few more 10X examples.
I always put my pants on one leg at a time and have never walked on water in warm weather. None of these examples involved high stress. Instead the keys were context, e.g., I had everything I needed and background so that the work was in my strike zone.
I don't achieve 10X all the time. Heck, I don't achieve 1X all the time; e.g., in my startup recently I've been interrupted and slowed by some unpredictable exogenous obstacles. But now it appears that I've circumvented the obstacles and am making good progress again. Back to it.
Net: I don't think anyone can achieve 10X consistently over long time intervals. And I don't believe that very many people can just decide "next week I'll do 10X work." and be able actually to do it. Instead I suspect that most people can have 10X periods given the luck of the right circumstances.
But I've been 10X better than apparently average a few times a few weeks at a time. Uh, part of the reason for a few weeks at a time is that as part of the 10X I got the work done very quickly!
My 10X cases were all when the planets happened to line up just right and, to use a baseball analogy, the work to be done was like a slow pitch right in my best strike zone.
(1) I was seeing a girl, and she was an intern and working for someone who wanted her to work on some old Fortran code. She couldn't figure out why the code was giving totally garbage results.
I glanced at her code and saw where she passed the constant 2 as an argument to a subroutine. So, sure, that can be dangerous. I glanced at the subroutine and, yup, it was changing the corresponding parameter so for the rest of the execution of the program the constant 2 had the value given it by the subroutine and was not 2.
She worked a day or two on this, and I solved it in about 180 seconds.
Why? I'd seen that in Fortran usage before.
(2) I was in a software house working as a programmer and fast Fourier transform expert at a US Navy lab. Some engineers at the lab needed an extensive software project done and set up a competitive bidding situation. For one of the engineers, part of the work to be done was some power spectral estimation of ocean wave noise, that is, quite low frequency. Due to some earlier experience at GE, I knew the basics of the Wiener-Khinchin theorem and also got the Blackman-Tukey book on the statistics of power spectral estimation, typed in some code to generate synthetic ocean waves and accumulate and display the power spectra estimates, then called the engineer and we met and reviewed my work.
The main point I had for him was that for the very low frequencies he was interested in, he could need dozens of hours of data and with much less data than that would be looking at small sample statistical fluctuations instead of good estimates of the actual power spectrum. Likely I got these results in 10X. Our software house got "sole source" on the work.
(3) I was at Georgetown University consulting in applied math and teaching computer science courses when a friend from college called. He flew up to Georgetown with several other people, and we met. Everything was inconclusive -- no one had any definite, good ideas. The problem was scheduling the fleet for FedEx. That was important because some Members of the BoD questioned if the fleet could be scheduled at all; crucial funding was being held up; the company was at risk of going out of business.
Finally in the meeting I just blurted out that I would solve the problem. Six weeks later I had the software running which was also the end of the semester for my teaching. I flew to Memphis, ran my program, pleased the BoD, pleased the founder F. Smith ("solved the most important problem facing FedEx"), and saved the company. I suspect that in time, that was a 10X effort.
(4) I was working on a Navy project to support both my wife and myself through our Ph.D. degrees when the Navy wanted an evaluation of the survivability of the US SSBN (ballistic missile submarines) under a scenario of global nuclear war limited to sea. They wanted the results in two weeks. That timing just fit -- my wife had a vacation planned for us at Shenandoah just after the two weeks.
From a WWII paper by Koopman's, I saw a continuous time, discrete state space Markov process subordinated to a Poisson progress and wrote and ran the software, Monte Carlo. The software was fast enough that I could generate and average 1000 sample paths quickly.
During a peer-review, an objection was that there was no way I could "fathom the enormous state space". In response I mentioned that after, say, five days, the number of SSBNs left was a random variable; it was bounded and thus had an expectation; the expectation was finite; the random variable had a finite variance; the law of large numbers applied; and averaging 500 sample paths would give quite accurate estimates.
I explained that intuitively Monte Carlo put the effort where the action was, and the reviewer, a well-known probabilist, responded "That's a good way to look at it." My work passed the review.
A second person, actually two people, had been assigned as an independent effort. At the end of the two weeks, they made no progress at all.
The Navy got their results on time, and my wife got her vacation on time.
(5) When I arrived at Georgetown, a prof had just completed a statistics package. One of the routines was polynomial fitting, but on testing the numerical accuracy was poor. The prof had programmed normal equations, and on that problem the normal equations are close to the notoriously ill-conditioned Hilbert matrix. I wrote a replacement routine using some orthogonal polynomial methods and got accurate results.
(6) I was in an AI (artificial intelligence), expert systems, project at IBM's Watson lab, and we were developing IBM's language YES/L1. We wanted rule subroutines. Our code design was to (A) return one call at a time from the whole stack of dynamic descendancy, (B) execute the RETE algorithm run-time code, (C) rebuild the stack of dynamic descendancy. I saw serious semantic problems with this approach and the coding was to take some weeks. I got some dinner, wrote and ran some illustrative code, in effect to call back into the stack of dynamic descendancy, at dawn wrote email to our team, got some sleep, returned at noon, and our programmer on the work was done later that day. I got an IBM award for the work.
There were a few more 10X examples.
I always put my pants on one leg at a time and have never walked on water in warm weather. None of these examples involved high stress. Instead the keys were context, e.g., I had everything I needed and background so that the work was in my strike zone.
I don't achieve 10X all the time. Heck, I don't achieve 1X all the time; e.g., in my startup recently I've been interrupted and slowed by some unpredictable exogenous obstacles. But now it appears that I've circumvented the obstacles and am making good progress again. Back to it.
Net: I don't think anyone can achieve 10X consistently over long time intervals. And I don't believe that very many people can just decide "next week I'll do 10X work." and be able actually to do it. Instead I suspect that most people can have 10X periods given the luck of the right circumstances.
In my experience, it's possible to identify these people early career, set up their environment to help them excel, and help them 10x. Actually hire a 10x off the street? Pretty damn hard
Denying that 10x <anything> exists is usually a shallow defense mechanism for our own egos. We aren't that good at <skill>, so we convince ourselves that no one else is either.
10x developers exist, but often they leave mess for others to clean up.
They cite a study that concluded “while programmers are better and/or faster than others, the importance and scale has been greatly exaggerated.”
Bah. Come on, OP. 10x engineers exist but much rarer than most think. Could you honestly see these people and NOT call them 10x engineer?
* Fabrice Bellard
* Linus Torvald
* Chris Sawyer of Transport Tycoon
* John Carmack
* Ken Thompson
* Jeff Dean
* Fabrice Bellard
* Linus Torvald
* Chris Sawyer of Transport Tycoon
* John Carmack
* Ken Thompson
* Jeff Dean
10x engineers surely exist IMO, but:
- 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.
- 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.
Here we go again.
I don't know why but this idea really seems to rub some people up the wrong way. Yet we all know that on a big team only a handful of people will be doing the majority of the work.
Those who believe in 10x software engineers are just dealing with 0.1x software engineers most of the time.
Why do we even discuss this type of clickbait posts, few times every year?
He's not even busting the myth.
He says 10xers exist, but they are bad for the company.
He says 10xers exist, but they are bad for the company.
No. He puts up a strawman argument, representing ”10x engineers” as producing shoddy work and not sharing information, which he then presents as being bad for the company. That is not a valid argument—obviously people like that are bad for a company, but those people are not ”10x engineers” even if they may sometimes be perceived as such.
Sure, Jeff Dean, Vitalik Buterin, Dennis Ritchie destroyed their companies because they were 10x (or 100x programmers).
[deleted]
Who would you rather have, a single individual who's a "10x person".
Or another individual who can make all of your developers 5x more productive, because that individual created a framework/algorithm/model that is radically more productive than what existed before (e.g. think Jeff Dean at Google, DHH with Ruby on Rails, etc)?
Or another individual who can make all of your developers 5x more productive, because that individual created a framework/algorithm/model that is radically more productive than what existed before (e.g. think Jeff Dean at Google, DHH with Ruby on Rails, etc)?
just like every other domain, the problem is identifying the 10x dev
Is this just the IQ debate, or "nature vs nurture", on another playing field?
It seems very obviously that some people operate on another level than others. If methods exist to boost the "normal" people to the genius level, they have not found their way into the mainstream yet.
Surely you could bog them down so that they don't perform better than the rest. You could simply only have boring software issues to solve in your company. In that sense, maybe you could get rid of the 10 times developer.
Or you could hire only very good people. But looking at the sea of developers, it seems clear that some are better than others.
It seems very obviously that some people operate on another level than others. If methods exist to boost the "normal" people to the genius level, they have not found their way into the mainstream yet.
Surely you could bog them down so that they don't perform better than the rest. You could simply only have boring software issues to solve in your company. In that sense, maybe you could get rid of the 10 times developer.
Or you could hire only very good people. But looking at the sea of developers, it seems clear that some are better than others.
tl;dr
FILL YOUR EMPTY FUNGIBLE DEVELOPER SEATS WITH OUR FRESHLY TRAINED DEVELOPER CATTLE FROM SCHOOL OF PROGRAMMERS #36. CERTIFIED IN AGILE BEST PRACTICES AND ADVANCED JAVA BEANS. 2 YEAR SERVICE LIFE. PRODUCT OF DJIBOUTI.
FILL YOUR EMPTY FUNGIBLE DEVELOPER SEATS WITH OUR FRESHLY TRAINED DEVELOPER CATTLE FROM SCHOOL OF PROGRAMMERS #36. CERTIFIED IN AGILE BEST PRACTICES AND ADVANCED JAVA BEANS. 2 YEAR SERVICE LIFE. PRODUCT OF DJIBOUTI.
A 9x mother will give birth a baby in 1 month.
A 9x mother will benchmark one baby per month.
https://en.wikipedia.org/wiki/List_of_multiple_births#Nonupl...
https://en.wikipedia.org/wiki/List_of_multiple_births#Nonupl...
Wow - an actual intelligent well thought out post on this very crazy subject. I agree with them ! And love the call out to psychological safety, an important and usually under- values area
Satoshi Nakamoto is a great example of a 1000x engineer (or a bunch of 1000x engineers) with an impact measured in trillions of USD, but the article may be right that he wouldn't have been able to have that impact inside a big financial organization, as his engineering is disruptive.
If you measure his impact in turns of extra CO2 emitted you might take a different view.
Isn't that true for any trillion dollar industry? Industries use energy whether you like it or not, and it's unfair to make such a big deal from one just because it's adopted in a different pattern than others.
Agriculture, mining, electricity, transportation, defence...all have CO2 emissions, and it's extremely hard to get rid of it.
Agriculture, mining, electricity, transportation, defence...all have CO2 emissions, and it's extremely hard to get rid of it.
Yes, except all those industries produce something useful.
It's true for almost any human activity that there is a huge gap between the worst, the average, and the best. It is preposterous to believe that the same wouldn't hold true for software development.