Busting the 10x software engineer myth

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.

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.

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.

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.