This is my core complaint. All software development is (eventually) rate-limited somewhere other than developer brilliance. Most business software hits this limit fast.
A huge portion of business software is stuff you can't solve with brilliance - tasks from integrating with other companies to building out simple new features happen at the speed of spec development, email responses, or other non-development limits.
If the 10x myth makes employers expect 10x productivity from certain devs, or even 5x, it's badly misleading them. Not always, there are compiler companies and ML firms and whatever else that need brilliance, but I think most companies that advertiser for 10x developers are usually limited by forces 10x development can't help with.
I've worked on plenty of projects where two smart developers would have massively outperformed the 10-12 mediocre and highly risk-averse developers working on the shitty (gradually getting shittier) code base over a period of 6 months.
For greenfield I don't think 10x productivity is likely though. If you're testing an idea you might throw away, cheap and cheerful will do.
If a business hires me thinking I am a 10x-er they have high hopes that I can't satisfy for their dimension of X.
There are good programmers, great programmers and dangerous programmers. But that's all relative to what work needs to be done.
If so how do we address such a problem?
I consider myself to be a 10x developer, but I'm not 10x all of the time for all tasks. Things that set me apart are the quality of my code vs other developer's code for a given amount of development time, the higher probability of my code being bug-free or nearly so before I've even run it, my skill at tackling extensive refactoring tasks with zero change in code behavior without needing to write and constantly run tests, etc. These skills all come from long-term experience, wide variety, and a fearlessness and belief that no development task is beyond my capability.
If you look at athletes, you'll see some that are really good at one particular sport, some that are naturals at pretty much anything they try, some that enjoy sports but aren't particularly good at it, and some (like me) that are so non-athletic that it's embarrassing. I think development skills are like that too. We can't really identify what '10x' means, because it depends on context and isn't tied to specific skills or behaviors.
This is a valuable point; many of the most productive people I know are breadth first not depth first. Being able to glue disparate systems together without having to stop and iterate with someone else saves a ton of time.
> Things that set me apart are... the higher probability of my code being bug-free or nearly so before I've even run it
I totally applaud your self confidence, and kudos if you're writing big chunks of nearly bug-free software before ever running it. My personal experience has been that even when I've been at my most productive, is that the probability of code of any nontrivial size being anywhere near bug free before running it is exactly zero. I'm scared of people who believe otherwise (I've never met someone who could prove it), and much of the success and productivity I've enjoyed in my code and management career have rested on the strategies to avoid assuming that code is nearly bug free.
The very best programmers and the very smartest people I know are people that came to the same conclusion - that every line of code is another bug - and then used that information to decide and inform how they're going to write software. They consciously avoid using fancy language features or playing code golf, they refactor often when architecture gets crusty, they spend a lot of time making sure other people can read their code, and they test and test and test.
I'll admit that's sort of a technicality, though. I've been programming for a long time, most of my career without anything more sophisticated than a text editor. I've taught myself to be pretty good at running code in my head, even fairly complex code. So what I'm really doing while I'm writing code is running it in my head as I write it, and finding the unhandled edge cases and other bugs while I'm doing it. I'm also compiling the code (if applicable) which finds other bugs. So, by the time I run the code for real, most of the bugs are gone. This is all a natural part of the act of coding for me, so I see it as coding rather than running/debugging. (I often debug in my head too; handy when you know roughly where a problem is but can't reproduce it.)
I agree completely with your last paragraph; that all helps to be able to hold the execution state in your mind while you're reading through the code.
In the past six years, I only worked on one project that justified an extensive test suite. It was a scheduling system for a large machine shop, which allocated multi-step manufacturing tasks across a suite of metal-working machines for dozens of concurrent jobs, while taking into account available machinists, working hours, breaks, vacations, and scheduled maintenance downtimes for each machine. Testing the algorithms for that required setting up a variety of consistent starting conditions, running the scheduler, injecting changes to existing jobs and inserting new jobs at certain times, and making sure that the resulting scheduling decisions were acceptable to the experts who'd been doing the schedules manually and to the machinists.
All of the negatives are: You get significant Lake Wobegon, and a ton of people think they are 10x that aren't (including a significant portion of people on this very website). People attempt to measure their 10xness in comparison to the worst engineer they know or work with (which is really likely comparing a 2x engineer to a 0.2 engineer). We have no way of evaluating it. No good way of hiring for it. The majority of actual 10x engineers don't get paid like it (they're just known as that really good engineer on the team / company). People spend time writing about it, and reading about it to no real benefit.
It really is the ultimate programmer insecurity. If Cosmo made a magazine for programmers it would likely be their splashy headline every other week.
The reason I mention it, is that it's wasted effort even thinking about it. If you're an engineer, figure out what you can do to improve your skills. Some things are flashy, some things are mundane. If you're hiring engineers, figure out what you can do to improve your hiring accuracy.
I posit (with no proof) that nothing useful has come from the 10x programmer discussions beyond the 6 months following its introduction.
The 10x developer existing means that the field is not really competitive yet and/or there is mismatch between who is trying to work there and what the actual needed aptitude is. Well managed company should facilitter knowledge transfer between people and competitive field should have large enough supply of people (unless the hiring process sux for some reason).
What a wonderful observation. This is true in fields other than software development, too.
Especially if you're working in a small company, you're going to hit a point when there is a massive wall of work to be done, bigger than you would ever be able to handle alone, and your organization will fail if you don't do it. The skills you need to actually handle that situation are going to be more in the vein of basic professionalism than technical talent. Better programmers might need a bigger wall before things get rough, but they will still hit it.
The reason for criticizing the 10x idea isn't that it doesn't exist, the reason is because feeds into myths that might end up being harmful far beyond the actionable decisions it lets you make.