How to cope with technology FOMO

Eight years ago Ray Bango wrote:

…many web developers who have been able to hang their hat on a specific technology for “x” years are incredibly concerned by the rate of churn in the JavaScript (and web development) world. They can’t just pick a specific framework and feel that they’ll be in a good spot for the next 5 years. And when you factor in the rate of churn on tooling and workflow technologies, you increase the anxiety of feeling “left behind”.

I would say that the situation hasn’t changed substantially since then.

I can relate. A lot of developer angst grows from anxiety over technical churn. It shows itself in different ways for different people:

• Personal projects caught in perpetual cycles of framework upgrades; never gaining features, just ported from one shiny tech to the next; or
• …vocal disdain for the “kids and their need for shiny new objects”; or
• …vocal disdain for old fogeys who refuse to keep up; or
• …”We need standardization!”; or
• “…Look at how community X handles this better!”

Here are some things I’d say to a younger version of myself, struggling with technology-churn angst and FOMO:

Focus on learning how to learn. Where did you get stuck on the last technology you mastered? How did you finally get un-stuck? How can you avoid that in the future?

Do you learn best from direct transmission from other developers? Personal exploration? Reading books? Watching videos? Learn yourself and be kind to your learning style.

‘ware the Hacker News bias. You vastly overestimate industry trends toward new technologies. If “everyone is talking about it” that means there are like 15 people who are actually using it to do something nontrivial. And there are a lot of quesions they haven’t answered yet.

Identify keyframe technologies, and start with them. In video compression, a “keyframe” is a frame that includes a complete image information. Frames after it may contain only diffs to that image; in order to play back the video, you have to apply the intermediate frame information to the keyframe.

Certain technologies are epochal: they set a new standard for how to think about a problem. These are the keyframes. Examples: React is a keyframe. Ruby On Rails is a keyframe.

Once a keyframe tech is established, a steady stream of follow-on technologies appear which are billed as “like X, only with Y!”. If you don’t already understand X, stop. Go learn X. Understand the keyframe. Otherwise, none of the why of what you’re learning will make sense. Also, 90% of like-X-but-with-Y technologies will fail to catch on, as X continues to be relevant. Because…

The Lindy Effect is Real. The longer a technology has been relevant, the longer it is likely to stay relevant.

80% of real-world developer work is maintenance. You are more likely to be asked to bone up on an obsolete tech than on a bleeding-edge one. Give up trying to predict the tech you need.

You don’t need to know how to do things, you do need to know what’s possible. Every tech has a shocking amount of fluff around it that you don’t need to memorize now, or ever. There will be at most one or two new, tricky concepts to master. The rest of the information can be left to Google, Stack Overflow, and small stack of reference books. Focus on staying abreast of what’s available and what problems each piece is solving so that when the time comes, you don’ t reinvent the wheel.

Pull information, don’t cram it. Yes, to fully master the Thneed stack you need to know XYZML, Flarp, Jinglebells, Booof, and CaptainPacket. Try not to get mad. Believe it or not, everyone who assembled this stack was solving a problem. It wasn’t done arbitrarily, or with malice aforethought.

The good news is, you don’t have to learn it all at once. Start at one end, and follow the pain: do enough XYZML to discover why Flarp was created. Then work on Flarp until you start wishing that it would bodge the wozits automatically, and presto: now you understand where Jinglebells fits in. And so on.

You’re probably thinking you could massively simplify all this. Now you have N+1 problems.

There is nothing new under the sun. This observation is true, infuriating, and useless. Sure, modern “frontend” MVC is basically NeWS only with Postscript replaced by JavaScript/HTML. Except for the million ways in which it is different from NeWS, and the ways in which it occupies a very different world than the world of Sun mainframes in the 1980s. There is nothing new under the Sun (heh), but most human progress comes of fiddling with combinations.

Stay humble. Before you start feeling all superior to anyone who is stuck in the past, reflect on how your coding practice of today looks like from the perspective of you-in-five-years.

This article was extracted from a SIGAVDI newsletter originally published in October of 2016.