The Programming Steamroller Waits For No One (2013)

If you're smart about it, you hire programmers because of their ability to solve problems. If she used Ruby for 10 years and did great things, and you use Clojure, no matter. People can learn new things. The core ideas and competencies haven't changed much. The tools and APIs seem to have a half-life of 5 years, except for the proven winners (C, Unix, Lisp as a concept if not a specific dialect yet).

If you're a dumbass, however, you hire based on trivia. You ask for minuscule details of C++ templates or Python metaclasses or JVM internals. You let your HR write hiring specifications like "must have PhD and 5+ years in ". The trivia questions are fine interview material if the person is claiming to be an expert in that technology. They're useless at determining whether a person is generally capable.

The problem is that companies tend to fuck up one of two opposing ways. The more common failing is the HR fuckuppery I described above, of hiring for specific easy-to-learn skills rather than actual capability. This tends to hurt older people, who (after a decade or so, when all the half-hearted programmers have dropped out) want to develop genuine competence rather than chasing every crappy new thing that pops up. That seems to be why every good programmer above 35 either wants to be an architect or data scientist or something other than a "regular ol'" programmer, i.e. an "X who programs"; because the way programmers are evaluated is completely borked.

The (much less common, but still irritating) opposite end of the spectrum is the "hire ALL the talentz" attitude you see at certain very large tech companies, where they "hire generalists" but that's an excuse for a one-size-fits-all, CommodityDeveloper, internal attitude. If you're running a closed allocation shop, you really can't hire people "just because" they're talented. You have to hire to the specific role or you'll have a morale problem and possibly an HR disaster inside of 12 months.

So, really, the only way to avoid falling into one of these vicious patterns or the other is to implement open allocation. But we all knew that already.

The problem isn't that there's a steamroller. It's that it's driven by idiots who don't understand the first thing about any creative process-- closed allocation is a laughably terrible idea-- much less a constantly changing one like technology.

For those who were paying attention in language classes it's a game of waiting for industry to catch up. A long one at that.

As much as I love learning new things, and would love a day job working with Clojure/cljs or contemporary js on regular basis, in terms of my career I potentially would have benefitted more from consolidating skills in the aforementioned ecosystems. In the valley these things may be perceived as legacy and completely outmoded, but in the rest of the world that's hardly the case.