I switched jobs recently and tried to adopt a zen-like attitude of beginners mind. It definitely helped...but I'd be lying if I said I never hit frustration points where I'm trying to go from A to C but I have to learn all about B when I don't WANT to care about B, I want to get to C. A good attitude helps, but I think the underlying reason is still true and is part of why experienced devs aren't adopting new tech at the rate of newer devs.
There's an awful lot of cyclical patterns in development, and an awful lot of convergence. HTML5 canvas for example is an awful lot like writing custom 2d graphics back in the day. Docker, Vagrant, etc. are neat but there was chroot, zones, vmware images, cygwin etc. before. A lot of hot new language features as well are just existing patterns from the functional discipline being tacked onto imperative languages and vice versa.
The fact that the constraints and reasons for adding generics to java or lambdas to c/c++ are different from the constraints and reasons for adding templating to c/c++ and lambdas to lisp doesnt mean that you can't go in if you understand one well and identify the pit falls or gotchas of newer implementations.
Is it really meaningful to go all in on learning how feature x from 2000 repurposed to solve solution y is all that fundamentally different? WebSockets are great, so was long polling and comet architecture, restful is great, so was SOAP, and their non web based COM messaging or just cross application communication ancestors.
There are a lot of pitfalls and unique characteristics to knew technologies but there is a lot more of new spins on old ideas, common underlying concepts and reinventing of the wheel.
You had me until that (j/k)(mostly)
> Is it really meaningful to go all in on learning how ....is all that fundamentally different?
That'd be the diminishing returns I mentioned up-thread: each iteration of learning a new way to do an old problem gives you less. I'd argue it's still more than 0, but we aren't comparing to zero, we're comparing to the opportunity cost.
That said, I think, as a generalization, experienced devs tend to be prematurely dismissive. That is, however, a personal opinion.
* stealth edit.
But if you don't do it, you're stuck on the local maximum of Hill X, and as it gradually erodes away, one day you realize that you don't have any lucrative jobs that you're qualified for, and you're so far away from what Tech Z is nowadays that you're effectively starting over from scratch, except that also you need to unlearn a bunch of stuff that's no longer true.
And this happens fast. If you try to coast for even, say, five years, so many of your skills will have turned to dust.
This is why the only real way to have a long-term career as a developer is to genuinely be interested in this stuff for its own sake. You need to want to go learn the latest new tech not just out of a cynical career calculus, but because you think it's genuinely cool and interesting and sounds fun. As long as that's true, I think you'll be able to be a valuable dev even as you get older; as soon as it stops being true, well, time to consider what's next for you.
Now, a lot of companies do over-engineer and cutting edge tools aren't necessary in a lot of cases, but that's a separate problem.