|
To continue the olympic metaphor, those medals are handed out for very specific subsets of skills, not even just runner vs swimmer, but specific distances, specific techniques or variants. While 'olympic-level athlete' contains some level of meaning to me, I feel it is similarly vague enough that you wouldn't know whether a random athlete would be better than average at a random olympic sport. There's probably some correlation, but e.g. a googled list of 10 weirdest olympic events ever claims to include 'poodle shearing', 'solo synchronized swimming', 'horse long jump' as well as the more 'normal' sports that were recently introduced such as 'skateboarding', 'surfing', 'sports climbing'. Would a 10x poodleshearer be a 10x surfer? I'm not even sure that would hold true between skateboarding and surfing which are vaguely related in my mind (as someone who can do neither). I feel 'programming' is a similarly wide field, and so it's obvious that e.g. a really good COBOL mainframe banking programmer, might struggle with generative audio-visual art and vice versa. So I guess for me, the difficulty with this 10x programmer concept, is how do you differentiate the experience and the training from the 'raw genius' which is what i feel people are getting at when they use this concept. And that's without even getting into motivation and interest and impact on others (e.g. mentoring teams, supporting others) and business impact. In general the whole concept seems so undefined that people are all projecting their own things onto it. Which is great for clickbaity blog headlines, but what is the actual take -away knowledge I am supposed to gain from this concept? That my potential is limited by my genes, my industriousness, my time invested, my focus on one niche? That I should hire people that have iq or focus or domain knowledge or ..? That I should construct teams or businesses around a small number of people that specialize, or i should hire two different ranks of programmers, the 10x and the 1x and use them differently? |
One thing that I've observed is that productive programmers seem to more often "just do things". For example, when impelmenting a feature, instead of thinking about the feature and a potential refactor at the same time, experimenting a bit about how it could look, they'll just implement the feature, so they are done with their task, and then see from here if the refactor is needed.