4 ms·

The reason why we have the 10x developer myth is that by the definition the author uses "good" developers are rare and "bad" developers are extremely common. E

The reason why we have the 10x developer myth is that by the definition the author uses "good" developers are rare and "bad" developers are extremely common. Entire development teams consist of such bad developers. Many of us worked in such teams at one time or another, and it's part what makes us so obsessed with quality and good development practices. We're dealing with the unprecedented reality that software is already everywhere, but the process of identifying and training good developers has barely started. Most companies that develop software don't even supply their programmers with the proper tools and work environment. It's like living in a world where everyone has a car, but only 90% of all mechanics aren't capable of doing more than just applying some duct-tape, and most garages are ill-equipped barns. Most software is appallingly badly made, and has a very short lifespan. And no, this is not just because technology moves so fast. Most of the languages we code in are almost 20 years old, and the techniques and conventions for coding in them even older. Core architectures are based on design conventions that existed before most of us started programming. The fast innovation mostly happens around the edges. Software development is a ridiculously immature profession compared to it's social and economic importance, and the majority of programmers are as incompetent as a neanderthal with a chemistry set.

jmorton 14y ago
most garages are ill-equipped barns To abstract and paraphrase (wildly): there are 10x work environments, and 1/10x work environments. It seems to me that the least productive environments let "now" trump "great" – so attracting (and retaining) the top 0.1% of talent becomes necessary for a company to survive. I wonder which costs more in the long run. When I make technical decisions, I think hard about how to keep things simple so that a reasonably smart and attentive person can use or extend whatever system down the road.
HNLogInShit 14y ago
"We" don't have this myth. "10x developer" is just the made-up term of the week. Real people aren't talking about this, because it's bullshit. People love to pretend they're somehow in the know by making shit up. Go out and do something useful instead.
agentultra 14y ago
Most of the languages we code in are almost 20 years old, and the techniques and conventions for coding in them even older. Core architectures are based on design conventions that existed before most of us started programming. The fast innovation mostly happens around the edges. We have more cores and memory caches and our address spaces have gotten larger but the most popular computer design, if I am not mistaken, is still the register-based machine. In that case despite advances in hardware, C and it's derivatives have scaled rather well to the problems at hand. Given a sufficient proficiency for abstraction an evaluator should be capable of emulating any machine required to run a given process. Which is what has allowed Lisp based languages to scale and continue to be relevant over the last 50 years. Some developers talk about "age," like it's a bad thing.

jmorton 14y ago

most garages are ill-equipped barns To abstract and paraphrase (wildly): there are 10x work environments, and 1/10x work environments. It seems to me that the least productive environments let "now" trump "great" – so attracting (and retaining) the top 0.1% of talent becomes necessary for a company to survive. I wonder which costs more in the long run. When I make technical decisions, I think hard about how to keep things simple so that a reasonably smart and attentive person can use or extend whatever system down the road.

HNLogInShit 14y ago

"We" don't have this myth. "10x developer" is just the made-up term of the week. Real people aren't talking about this, because it's bullshit. People love to pretend they're somehow in the know by making shit up. Go out and do something useful instead.

agentultra 14y ago

Most of the languages we code in are almost 20 years old, and the techniques and conventions for coding in them even older. Core architectures are based on design conventions that existed before most of us started programming. The fast innovation mostly happens around the edges. We have more cores and memory caches and our address spaces have gotten larger but the most popular computer design, if I am not mistaken, is still the register-based machine. In that case despite advances in hardware, C and it's derivatives have scaled rather well to the problems at hand. Given a sufficient proficiency for abstraction an evaluator should be capable of emulating any machine required to run a given process. Which is what has allowed Lisp based languages to scale and continue to be relevant over the last 50 years. Some developers talk about "age," like it's a bad thing.