In my experience 10X is more to do with the environment than it is to do with the programmer. I have been 10X and more in the past over maybe a 10 year stretch when I was doing lots of greenfield development and I also had control over the design, architecture and system configs. But now, in an environment with messy legacy code, and no control over architecture or systems, I seem to be more like .02X. At some point I will have mastered refactoring a big ball of mud and I will be able to get to 10X again.

And in case you were thinking, rewriting from scratch is not sufficient to transform a big ball of mud into a greenfield.

In any case, the opportunities for refactoring big balls of mud are growing exponentially so it is a worthwhile skill to master.

I'm not really sure if I'm qualified to comment on the selectivity idea, since nothing I've written has ever been scrapped (if you don't count my personal projects, that is). Mind you, I've never shied away from or maneuvered away from a project; I've just said up front that X and Y is how it should be implemented.

What I do know is that I have been the 10x guy up until my latest thing, where finally, thankfully, I'm surrounded by people who are on average better than me.

10x, though it sounds objective, is a very fluid term. What I've noticed is that everyone who plays at this level cares deeply about code quality. It's about art meeting functionality, and all of that being shipped on time. It's about avoiding technical debt, except in rare cases of grudging agreement in the face of cold hard facts.

10x is discipline and drive. It's not that they choose to, it's that they're DRIVEN to.

The article used his own example of programming fixed-point arithmetic, plus Ken Thompson and Linus Torvalds. In everyday use, "10x programmers" describe those who produce work much quicker in everyday IT shops using Cobol or Java. Many programmers in these places are typically low on aptitude, and are only as productive as the number of years they've worked on the systems for their particular employer. Occasionally someone with some more aptitude ends up in one of these places and soon works a lot quicker, and gain the title "10x programmer", though may only do stuff 3 or 5 times quicker than average. Most of them get transferred out to some more meaningful project in the company, but management usually keep one or two of them stuck in that maintenance team, generally whoever agrees to do after-hours standby work.

I believe in the 10x programmer... because my own productivity (as measured by some random objective metric) can change by that much over short and long terms.

I agree that this is a challenge for management. Writing good computer programs for 40+ hours a week is an unusual thing for a human being to do. Doing it at 10x over the long term is just plain unnatural.

Individuals seem to require their own (evolving) set of motivations and circumstances, making successes very challenging to replicate.

I'm going to comment. I really hope this doesn't get buried. That's absolutely true.

I call myself a 121 programmer, which is the MacLeod Sociopath of the programmer world. (911 are MacLeod Clueless because they're willing to throw down in an emergency that management created; 501 developers, who leave at 5:01, are MacLeod Losers.) I want to improve the value of my skill set by 1% every 21 days.

There is 10x of selectivity (choosing good projects) and also 10x of productivity (making good calls) with the latter especially prominent in powerful languages (e.g. Lisp). But "10x" doesn't happen overnight. It happens over a long time. Taking the 1%/21-days estimate (which is a wild guess, but the right binary order of magnitude) that means we go from 1x to 10x in 13.3 years (although I've actually seen people grow faster than that.)

The 10x programmers got that way by mandating that they learn, and ignoring career-incoherent work.