I haven't hit that point yet. It can get pretty close to overwhelming how quickly people are building new things and it's often not clear to me what problems the new things are solving (which likely means that I don't have those problems and shouldn't even worry about those new things).
Do you remember how it felt when you had that insight that tech is not mutating as quickly as it may seem?
I've described it as the "disappointment of knowledge" in the past.
It's like hearing all the microservices hype, sitting down to read it and thinking that it's "just" SOA slimmed down with some of the more complex vendor offering replaces. And that both are "just" Smalltalk-style message passing that happens to occur on multiple machines. Or that Kubernetes is just a bunch of nodes running processes with Docker as a process manager (reading the paper on its predecessor, Borg, was very enlightening). That C# is "just" Java that has been cleaned up.
The disappointment is that there is all this hype that would imply the world has changed and you realize that it may be a serviceable tool, but it is "just" something you've seen before remixed a little.
It's one of the reasons that I have a hard time getting excited about learning another web framework or another C++/Java-ish programming language. I can learn by diff'ing pretty quickly, so I tend to read broadly, looking for stuff that looks like it might be highly differentiated. I tend to burrow deep onto things of either immediate use or that will provide a different world-view (for example, learning Prolog will probably teach you a different way to look at problems whereas learning, say, VUE.js after having done Angular might teach you a useful tool, but the world view is more or less the same).
What I got from it, is that there's a solid "baseline" of technology/technique that tends to remain fairly constant and relevant.
It will often be "discovered" anew, and repackaged with jargon, but the basics are still the same.
My experience is that the mutations are more of an "accretion," rather than a change. New stuff is added. An old technique might be formalized (like SOLID isn't actually anything new, but the definition is relatively new), which is really a way of "adding" to the older technique. We find ways to combine "classic" techniques, or specialize/derive from them, to provide a different service.
It's hard to find teachers that will keep up with the times. As someone who has done training, I can tell you that creating a course is a fraught process. It has to be correct. That means a lot of testing/review, and often "after the fact" fixes and refactoring, as students (invariably) find problems.
Keeping it updated is a pain. Also, it's entirely possible that the entire class may need to be binned, as the tech becomes irrelevant (I have a whole bunch of DU -Apple Developer University- certificates that are pretty much worthless).
Also, scope and scale. Projects are much bigger, nowadays, than they used to be, and we have found ways to apply classic techniques in new ways. Instead of learning how to write a device driver, we learn a device interface SDK. That's not a bad thing (as long as we choose a good SDK), as it frees us to do a better job on the higher levels.
One example I give, is that I started Apple programming with MPW[0]/Pascal (not Object Pascal)/ASM. It could take a week or two to produce a relatively simple GUI app.
Nowadays, with Xcode and Cocoa, I can spin up a fairly full-featured app in just a couple of hours.
Very little of what I learned with MPW will help me today, but the discipline that I earned is quite valid, and much of what I had to do by hand, is now done in the framework, so I do have a bit of an understanding of what is going on "beneath the sheets."
I see - strong fundamentals are always worth cultivating because they are invariant under shifting fads and trends.
The thing that I find difficult is how quickly trends and fads shift in this industry. I came out of mathematics, which moves much more slowly than tech in terms of what's fashionable. I think it's a function of the sheer number of people working on tech compared to math.
