Another Theory to Explain 10X Programmers

Here are some observations that may or may not help you:

Average programmers tend to: * like new projects * want to build "new things" * not like fixing bugs * not like reading code * not like to redo their designs/code * think their code is as good as it gets

Good programmers on the other hand * tries to find joy in thr task at hand * thinks their old code is bad * aren't invested in their own designs * don't fear trying solutions * reads code rather than docs about the code * don't mind fixing bugs * happy when the code quality goes up, hates it when it goes down.

In other words - good coders CARE, average coders just want to have fun and build stuff. This means the latter group doesn't build the understanding of how to build good, bug free code. They prefer to build themselves into a corner rather than throwing out their designs. Thus they get less practice.

There's an old knowledge management idea called the "knowledge nugget," a definable chunk of knowledge, skill, and/or ability that can be captured, learned, stored, found, and shared. This chunking plays a big role in disciplines where the body of knowledge is vast, changes rapidly, and where just-in-time skill acquisition is likely. Aircraft maintenance calls for more info about more parts about different aircraft than any one technician could know; so they wind up doing lots of look-ups and following procedures and limiting studying to the most commonly encountered problems and to understanding classes of problems/solutions.

The first books on algorithms, like Knuth's, tried to chunk computer science. Software patterns tried this with newer ideas later. We've seen similar projects in functional programming, cloud architecture, and machine learning. The catalog of ideas/hacks is vast and, unlike with aircraft documentation/training, isn't centralized or organized.

Aircraft techs have a deterministic advantage over programmers: they have well-defined triggers and search parameters to find the relevant nuggets. The light that's blinking red has a part code and a serial number and docs can explain the the light's various states. Systems guide techs through decision trees to identify the right procedures for this problem. Programmers experience miserably vague and inconclusive cues.

Aircraft techs benefit from large but finite and known problem sets: just so many parts and so many interactions among them. Programming keeps coming back to ways to simplify and constrain the number of things that interact in ways that produce unexpected results. How much of OOP and FP aspires to help coders avoid complexity?

Aircraft systems are evolving rapidly, from one aircraft model to the next generation. But these have, for the most part, been incremental changes. Contrast that to the six-months to a year it takes to mature in your switch to function programming. Or new architectures, programming languages, and operating systems that require rethinking everything you know. The cognitive burden is high and the duty to relearn is weighty.

So your theory about nugget/task fitness producing moments of 10Xness and sum(nuggets)/sum(projects) producing days/weeks/months/years of 10Xness maps well to the knowledge management world.

In this particular case, isn't "10x" just a factor of IQ then? Smarter programmers get complicated things done faster. That seems like a no-brainer. Problem is, how many of those people actually exist in programming? A much smaller subset than exist in the world, which is already a small subset of the general population. Hinging your company on hiring nothing but 10x programmers is like trying to hire a unicorn.