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).

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.

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.

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.