I am in the middle of these two groups. Often "Stay current", "It's different with modern ideas/methods", etc... Expressions commonly used by people who want to ignore the lessons that other people had to learn the hard way. Ironically claiming they claim the old person is out of touch. When in reality they are trying to prevent newbies from repeating the past.

When I'm interviewing a developer, I'm less concerned with what they've been learning and more concerned with if they've been learning. As long as you've accepted that being a developer means constant change and constantly learning, you'll be able to make up your own mind about whether new fad X is worthwhile or whether your organization should skip it. But if you get to the point where you stop learning, you'll be stuck with a certain set of tools/skills that eventually stop becoming adaptable.

I like to think of it like evolution. Most mutations are not advantageous and die off quickly. The ones that are allow you to outcompete competitors. I've learned 3 new languages this year, toyed with 2 new data stores, and played with/read about countless frameworks and libraries. Most of these technologies took up less than an hour of my time. Some I devoted a half day of hacking with. Others I stuck with for longer. From all of this, I've filtered it down to a handful of tools that I'd consider using in specific situations. This is what I consider staying current. I consider this to be between 10% and 20% of my job as a leader in my engineering org. And it's what I feel that I need to do so that when it's decided that we need to use something other than what we're using now, I feel that I can come up to speed on that new technology quickly.

It gets frustrating interviewing developers who, for the past 20 years, have programmed nothing but Java. Sure, they know a few libraries within the Java ecosystem but, for the most part, all their learning from the past decade was domain-specific knowledge from their last job. And then they want to be rewarded for that "experience" at a new employer. Sorry, that's not going to happen. I can hire a newly-graduated university hire who's more willing and able to put in the time to learn for half what I'd have to pay you. That's not ageism, that's common sense. On the other hand, when I encounter a developer with 20 years experience under their belt that has used that time wisely and has enough tools in their utility belt to make Batman jealous, I'm more than willing to bring them on and pay them accordingly. They'll be a great mentor to all the younger hires I'm forced to make.

The key point of contention that I have with you is that I don't consider time spent learning to be wasted. Ever. Learning itself is a skill that needs to be practiced, even if that means learning something that you'll never use.

One could also argue that it's better to interpret "stay current" as being about "learn new frameworks", but rather "learn important concepts and their applications."

One can write object oriented code (with clear modules and interfaces) in plain-old-C (see "C Interfaces and Implementations"), just as one can write Fortran in Ruby (and I don't mean by creating a DSL sensitive to positions of characters in a line).

If we look at the market adoption curve (Marketing 101) most of the money and most of the demand is in "old" technology. But extremely old tech, extremely new tech, either way there's going to be demand across the spectrum relative to the supply of developers.

Unfortunately for non-fad followers, the people with money want to use the fads.

Shouldn't having the knowledge of what you could do in 1994 make you that much better suited to doing it in 2015 even if you have to spend a few days learning the faddish way of expressing the concepts?

The point isn't that you can insulate yourself from the fads; the point is that you should spend your career-building time on fundamental skills acquisition, and pick up faddish frameworks and languages on a JIT basis. People who can write compilers generally aren't too intimidated by compile-to-JS languages.