One easy trick to keep your skills relevant: Just try to predict ahead of time how long-lived a technology will remain prior to learning it. If you do this throughout your career and are moderately successful, you will end up knowing a bunch of skills that will rust very slowly.
The question then is how to successfully predict the future lifespan of a technology? Obviously you'll get some right and some wrong, but with a little thought you can at least get a good batting average. The easiest trick, which actually works, is to estimate the future remaining lifespan of a technology as being equal to its lifespan so far.[1] If it's been around for a long time, it's likely to keep staying around. By contrast, most new languages, databases, etc invented in the last couple years probably won't last more than another couple years.
Some concrete recommendations this simple heuristic would have made in the recent past, just by way of example:
* If you're working in front end, just get good enough at React to get by. Instead focus your extra efforts on mastering CSS.
* If you're working in back end, just get good enough at novel NoSQL databases to get by. Instead focus your extra efforts on mastering SQL and the relational model.
* If you're in "devops" just get good enough at Ansible, Salt, Puppet, or whatever the flavor of the week is to get by. Instead focus your extra efforts on mastering fundamental UNIX/Linux systems concepts and the basics of internet protocols, etc
* If you have to get stuck on either a ruby or perl legacy project, pick the perl one.
* Learning the basics of C will likely turn out to remain useful forever (even if C itself becomes obsolete)
* Git has been around for a while and will be around for a while longer, so investing in knowing it well is probably worthwhile considering how intimately you work with version control. But the really important and long-lived skill you should master, that was applicable (if more challenging) before git and will remain applicable under whatever replaces git, is being good at resolving merge conflicts.
Etc.
Obviously use your own judgment in concert with this heuristic. Your judgment about this can get better if you practice it a lot, thinking about why some technologies live long and others live short, and what factors allow a new technology to outcompete an old one. But even if you don't get very good at it, the "It will live as long as it already has" heuristic will work pretty well.
[1] This works because it follows from the assumptions that in the absence of any other information, a technology must be estimated as currently being 50% through its total lifespan. It works for estimating the lifetime of anything else that does not decay with time, ie it is just as likely to die early as late other things being equal. So it works great for things like organizations, fashions, human languages and cultures, technologies. (Obviously it would not work for an animal, which gets closer to death as it gets older)
The question then is how to successfully predict the future lifespan of a technology? Obviously you'll get some right and some wrong, but with a little thought you can at least get a good batting average. The easiest trick, which actually works, is to estimate the future remaining lifespan of a technology as being equal to its lifespan so far.[1] If it's been around for a long time, it's likely to keep staying around. By contrast, most new languages, databases, etc invented in the last couple years probably won't last more than another couple years.
Some concrete recommendations this simple heuristic would have made in the recent past, just by way of example:
* If you're working in front end, just get good enough at React to get by. Instead focus your extra efforts on mastering CSS.
* If you're working in back end, just get good enough at novel NoSQL databases to get by. Instead focus your extra efforts on mastering SQL and the relational model.
* If you're in "devops" just get good enough at Ansible, Salt, Puppet, or whatever the flavor of the week is to get by. Instead focus your extra efforts on mastering fundamental UNIX/Linux systems concepts and the basics of internet protocols, etc
* If you have to get stuck on either a ruby or perl legacy project, pick the perl one.
* Learning the basics of C will likely turn out to remain useful forever (even if C itself becomes obsolete)
* Git has been around for a while and will be around for a while longer, so investing in knowing it well is probably worthwhile considering how intimately you work with version control. But the really important and long-lived skill you should master, that was applicable (if more challenging) before git and will remain applicable under whatever replaces git, is being good at resolving merge conflicts.
Etc.
Obviously use your own judgment in concert with this heuristic. Your judgment about this can get better if you practice it a lot, thinking about why some technologies live long and others live short, and what factors allow a new technology to outcompete an old one. But even if you don't get very good at it, the "It will live as long as it already has" heuristic will work pretty well.
[1] This works because it follows from the assumptions that in the absence of any other information, a technology must be estimated as currently being 50% through its total lifespan. It works for estimating the lifetime of anything else that does not decay with time, ie it is just as likely to die early as late other things being equal. So it works great for things like organizations, fashions, human languages and cultures, technologies. (Obviously it would not work for an animal, which gets closer to death as it gets older)