In technology education, or what passes for it in today’s world of blog-tweets and youtube sync’d slide decks, signal-to-noise ratio is only part of the problem. The larger problem is signal degradation. Today’s hot technology, the one that’s doubling productivities around the world, is tomorrow’s dead dog rotting in a gutter, and the pace seems to be quickening. And whither the legacy codebase?
Every dead technology started the same way: somebody had a problem and they fixed it. Pleased with themselves, they told somebody else. Eventually, an evangelist heard about it, and they told everybody who would listen. Developers heard; most ignored it but the truly curious ones tried it out. Some of them agreed — this is the hot new thing. They applied it to a project, the project worked, and suddenly the hot new thing is making IPO millionaires out of guys writing LinkedIn articles about their cuture wearing sketchier beards than mine.
Then out of nowhere, our new technology isn’t new anymore. It’s missing X or too full of Y, doesn’t scale, isn’t elegant. Suddenly this once great technology is a doorstop, and anybody gauche enough to program with it is an industry pariah, delegated to cleaning up messes in the machines that made other people rich.
I wonder how many technologies have their reputations built on what I call the Dumbo’s Feather effect. You remember the story of Dumbo — baby elephant discovers, by virtue of waking up on a telephone wire, that he might be able to fly. But he has no faith in himself; after all, the idea is preposterous. Until, that is, he acquires a “magic” feather — a placebo totem that gives him the confidence to grow from doubter to pachyderm Icarus.
Developers, like all skilled professionals, naturally mature. As their skills increase, their productivity improves. But this doesn’t protect them from failure. It’s inevitable — you can’t program without making assumptions, and some of them are going to be wrong. Not to mention the other inevitabilities of software, like flip-flopping customers, pushy bosses, shoddy analyses, short schedules. And in the digital space, where only the developers know what’s going on, obviously it’s their fault.
A developer can’t help blaming themselves for software failures, even if nobody else does, and even if it’s not their fault. A sensitive dev remembers every great idea scrapped, every beautiful implementation sullied by haste and hack and every production failure in a class with their @author tag. If only they’d been precognitive, clairvoyant and had infinite productivity!
And for many, this feeling of failure compounds; it begins to weigh heavy. It makes the developer risk averse, sometimes to the point of being afraid to do anything bold. And that’s a problem. A developer without confidence is supremely unproductive, refusing to make any assumptions, and turning every decision point into a meeting.
Then new technology comes around. And hey — says in this one blog post that it’s specifically designed to fix the problem the developer’s been dwelling on all this time. So he checks the documentation — say, hello world looks easy! He types it up, compiles after only a few tries! He stays up all night trying different permutations. He posts in the forums, reads everything he can, visits a conference, and is most careful not to repeat the mistakes he made on that OLD technology.
And when that first big project on the new technology hits production — a rocky release, to be sure, but who cares about that, it actually worked — it becomes the star. The elephant flew, and it was the feather what done it.
Confidence. It’s essential to every stack. Even a battle hardened skeptic like me needs it, sometimes, and the allure of a new technology brings with it an awful lot of confidence building. Sometimes, it’s even enough to overcome the interruptions, the missteps and other inherent risks in adopting it. The rest of the time — hack it, patch it, decay sets in, and it’s on to the next new tech.