Exactly. Also, things keep getting reinvented, often with something beneficial added but usually also something worse than what we used to have. So the perspective of past knowledge can often help you understand some aspect of the new stuff, if you’re also correspondingly open-minded enough to learn the new thing on its own in advance.
And recent experience has shown me that you can both be working with the worst legacy code and CGI has to throw at you and also having to learn pre-release ECMAScript and TypeScript, to use on the same project. Some skills transfer — I’ve never had to fully relearn how to loop through something in a new language once I managed to master both for loops and map/each functional approaches, for example.
Other things are maddeningly poorly developed — tools to help you understand and refactor code are still very much language-specific at the moment and it’s always a one-off to port out-of-fashion languages and syntax to newer ones. Let’s not start on how testing guidelines and TDD haven’t significantly changed since 2003 unless you maybe include SRE work and better “testing in production” techniques... Some knowledge seems evergreen... or stale.
But it’s amazing how when you do keep an open mind, and focus on how something really works at a lower level, it still pays off over time. I still haven’t deployed anything in production with Docker and K8S but that doesn’t mean it wasn’t worth learning, it helped clarify that there’s more to production reliability than simple deployment scripts or imperative commands vs declarative repos — simply knowing it helped me better understand related topics, including additional reasons why immutable, fully-reproducible build systems are a good thing, or how deployment can be seen as a complete system instead of simply “what version of the code is on the servers now?” It also provides a promise of a cloud-agnostic future, and an alternative look at why 12-factor was good, but incomplete.
And there, again, one might say, why did you bother learning 12-factor when most places let you store log files on local EC2 drives, for example? Well, because if you can get over the information overload, having multiple ways of doing things means you’re more likely to be flexible in your approach, or ask “why” when someone says “just do it this way”. It of course has to be balanced with healthy pragmatism, to both ignore the “best option” when it’s too much work, or to recognize that there’s always a chance to continue improving things later on, or as a team.
What’s key is trying to think strategically about your code rather than tactically. A tactician would say “learning nothing new outside of what I need at this moment gets the job done faster” or “this fixes the bug” while a strategist recognizes that there’s always a future opportunity cost, or asks, “but what caused the misunderstanding that allowed it to occur in the first place?”
Also, it’s inevitable that things will change, so you should always either keep up with your specialty or keep expanding your generalist skill sets. And even your knowledge isn’t constant — there’s always something to re-learn if you haven’t used a thing in awhile or in some new way...