Ask HN: With such fast changes in technology, how do you update your skillset?

Depends. I'm shepherding http://www.airwindows.com/ through a switch to Patreon, by expressing new DSP ideas in a context of very, very old audio plugin frameworks. The dev tools I'm using won't even work on current computers. I code on a time capsule laptop and depend on the very simplified plugin formats I've chosen (generic interface AU and VST) to remain functional. They'd have to break the most fundamental interfaces to kill my stuff (which doesn't make it impossible to do, just very user-hostile)

Don't confuse advances in technology with intentional churn generated by vendors and platforms. The latter is a plague, and it doesn't only cost people money, it costs them productivity. You may be getting confused and mistaking skillset for toolset. Large companies will always be able to replace your toolset and demand you learn a whole new one, because the more you do, the more you'll be locked in to their toolset. If you can abstract out the functions being implemented and express them in different ways, you can take your skillset different places.

Whether you do that, depends on how good you are at finding niche markets. As someone who's stayed in business for ten years selling GUI-less audio plugins with no advertising and no DRM of any sort, I can tell you (1) niche markets exist and they're loyal, and (2) they're small, which is what makes them niche. :)

A lot of the technology on the bleeding edge will be gone in a couple of years. AngularJS v1 used to be the next big thing, now it's obsolete. Who knows if v2 will stick around.

So following the latest technology in detail is unnecessary. Far more useful is just having a broad sense of what tools are available out there; it takes less time, and it's more useful since it gives you access to a broader set of tools on-demand.

Beyond technology, the things that persist are much more fundamental skills:

1. Ability to read a new code base, and ability to quickly learn a new technology.

If you can do this you don't need to worry about new technologies since you can always learn them as needed. E.g I just wrote a patch for a Ruby project (Sinatra) at work even though I don't really know Ruby and never saw the codebase before. It got accepted, too.

2. Ability to figure out what the real problem is, what the real business goal is. This makes you a really valuable employee.

Technology is just a tool. More fundamental skills are your real value.

More detailed write-up on how to keep up without giving up your life: https://codewithoutrules.com/2017/01/11/your-job-is-not-your...

I learned the hard way about 10 years ago what happens when your current skill set becomes obsolete, since then I've become very focused (and lucky) and only take on really enjoyable and unique projects. That way it's easy to be exited and do a good job during a project, communicate your passion in future interviews and transfer that enthusiasm in your previous projects to potential future employers.

The exact tech choices doesn't matter that much it's more of the overall direction (in my case analytics, in a bunch of varied sub-fields).

Although the top comment has some merit I'd argue c/c++ is an outlier here rather than the norm.

I completely agree with you.

I started in this field in 1992. I've seen the coming and goings of many flash-in-the-pan technologies.

If you are a dev and are selling yourself on your skillset, ask yourself, "is this sustainable?" The answer is "no." A fifty-year-old brain simply does not absorb new technologies as fast as a 25-year-old-brain. If your plan is to continually adopt new cutting edge technologies in order to stay marketable, I politely submit you need to rethink your long term plan.

As an almost 50-year-old, I promise you that the world is not a gentle place for older devs. Plan your exit into management, a related field, or some other job altogether. If you expect to be a coder at age 50 you're going to be disappointed.

As for me, I jettisoned the "technical skill set" war decades ago. I do not sell myself on my technical skill set. I sell myself as the ultimate generalist. This comes with its own set of problems. However, it has allowed me to age more gracefully in my field, because I do not create the expectation that my primary value-added is code generation.

I developed a checklist to spot technologies that are in an early stage of the hype cycle and avoid them.

The following are signals that a technology is in and early part of the hype cycle:

* It has the backing of a major corporation or a startup with a marketing budget.

* There are a lot of rave articles/blog posts about building relatively simple or small self contained applications using this technology.

* There is a small but vocal contingent of users who are passionately against the new technology. Their arguments often link to bugs on the bug tracker, cite edge cases that occur under heavy usage and indicate fundamental oversights in the design as well as assumptions (and often arrogance) on the part of the architects.

* The benefits cited are either A) vague or B) explicitly aimed at beginners.

* Arguments in favor often appeal to authority (e.g. "Google uses it" or "XYZ company use it in production"), popularity ("everybody's containerizing these days") or cite benefits which were already possible.

* A high ratio of talk to action: the technology is talked about on Hacker News a lot but there appears to be very little real life stuff developed with it and a lot of the talk involves jamming it in where it's not really necessary.

* Sometimes I experiment with a technology for an hour or two and I see if there's anything obviously wrong with it or if the criticisms are valid.