There's a lot of discussion in this thread around "junior" vs. "senior". This misses the point, which is to hire good programmers and avoid bad ones. It's as if

There's a lot of discussion in this thread around "junior" vs. "senior". This misses the point, which is to hire good programmers and avoid bad ones. It's as if the industry has finally burned itself out of the "programmers as replaceable cogs" model and has replaced it with the next-laziest model, "hire senior, not junior". That is an improvement, but it's still so off-base that the words "junior" and "senior" applied to programming make me cringe. Here are two factors the junior/senior model does not take into account. First, a good but inexperienced programmer will learn so quickly that they will run rings around mediocre experienced programmers in no time. Second, experience isn't only a good thing. Once people have repeated something a certain way enough times (and surprisingly few repetitions are required), they become locked-in and unable to see alternatives. This loss of flexibility is toxic to effective programming. Of course that happens less to good programmers than bad ones, but that only puts us back at the real question - how do you tell a good one apart from a bad one? - something we have no satisfactory way of answering that is compatible with current hiring practices. What we need is a healthy culture of interaction between "junior" and "senior". Our industry lacks this. What is our path to learning? We have the sink-or-swim model in which people once hired are installed in a silo and told to work on their tasks. Everyone recapitulates all the classic mistakes and has to figure everything out for themselves. I know I did. It cost me at least 5 years developmentally, and I'm only putting the number that low to save face. This way is so inefficient that it must eventually yield to something better. Hopefully when that happens there will also be less of the prickly auto-didact about most of us - but that's another story.