Jeff Atwood writes about the “The Years of Experience Myth” in his usual, dead-on style:
Imagine how many brilliant software engineers companies are missing out on because they are completely obsessed with finding people who match– exactly and to the letter– some highly specific laundry list of skills.
Somehow, they’ve forgetten that what software developers do best is learn. Employers should be loooking for passionate, driven, flexible self-educators who have a proven ability to code in whatever language — and serving them up interesting projects they can engage with.
Jeff goes on to make the point that you can use job requirements like “3-5 years of experience in such-and-such” as a baseline for determining the quality of the hiring company. If they hire based on irrelevant (or counterproductive) measures of skill, chances are good that “the rest of the team will be stooges picked for the wrong reasons.”
Let’s take this a few steps further.
Consider the impact of this situation on emergent technologies, and I think a case can be made for why new, “special” technologies have the lifecycle they do.
I’ve often wondered why new technologies get the hoopla that they do. Is C# really such a huge improvement over C++? Is Ruby on Rails really such an extraordinary step up from PHP? Sure, these technologies usually represent improvements – sometimes significant ones. But by now we all should know that the real cost – and opportunity – of technologies lies in the human capital involved. I for one will take an A+ PHP developer over a B- Ruby developer any day.
So why do new technologies get the buzz?
If the best programmers are learners, then it stands to reason that when a new technology is introduced, it will be the curious learners – the best programmers, in other words – who early-adopt it. It therefore follows that the first wave of solutions based on the new technologies are often the outstanding solutions – not because the technologies are so great, but because by virtue of their newness, only the very best programmers are using them.
Once the technology has matured somewhat (and the requisite training curricula, certifications, and dead-meat programmers take their places in the market), productivity understandably falls off. The quality and novelty of the solutions drop. The buzz and hype fade. And the best programmers, having been a part of this technology shift for several years at this point, start looking for something new to learn, and move on.
This offers some interesting lessons to learn.
- If you’re a software badass, then it really pays to stay on the leading edge of new technologies, even ones that don’t seem to offer a real benefit. By doing so, you not only differentiate yourself from your peers, but you also will probably end up in the company of other badasses doing badass work.
- If you’re a company looking to start some new development, consider implementing using new technology as a way of discerning and attracting talent. Your risk – that of implementing an untried technology – may be lower than the risk of implementing an established technology with tired, unproductive, uncreative developers.
- If you’re a software toolset provider, your marketing strategy should be based on finding the software badasses and convincing them to early-adopt your technology. This may even dictate that you do not offer training or certification, and keep your documentation sketchy and terse – just the way badasses like it.