Yep. That's the key to staying relevant: change with the times.
I have found myself more than once thinking that learning about some new trendy buzzword is just ultimately a waste of time, since I will barely have mastered it before it's been replaced by the next new/old thing.
On the other hand, it gets easier since none of the concepts are new anymore, and I tell myself, "hey, if you want to pay me to build a client-server app in the browser like it was 1995 (substitute Powerbuilder for Firefox/Chrome), great, happy to take your money."
An example of what I mean: the Apple Newton, and then 10 years later the Palm Pilot, and then 10 years later Windows CE and flip-phones supporting J2ME, and then 10 years later touchscreen phones and tablets. There have been four generations of "mobile app developers", but only the latest generation has seen any traction for their apps. This time the idea stuck; it will stay around, rather than coming around again.
If something like Paypal's prototype service (beaming money from one Palm Pilot to another) were set in this "revolution" of mobile instead of that one, it would be much more successful.
Apple Newton: 1993
Palm Pilot: 1997
Smartphones: ~2002
iPhone: 2007
Android: 2008
iPad: 2010
Though that means that you have acknowledge that things were not all that great back then as you remember - which seems to get harder as one grows older.
Today Functional Programming is introducing all kinds of new ideas and approaches, and while I often find FP people over-earnest and irritating, I'm still able to recognize that they offer something new, even if it isn't all they think it is.
Impure functional languages like Haskell have shown that it's possible to get many of the advantages of a purely functional language while still being able to implement side-effects, which is an amazingly cool trick despite Haskeller's annoying insistance that their side-effect-ful "language" is "purely functional" even if they have to redefine "language" to make it true.
This is true of all the supposedly "pure" functional languages, which universally come with caveats that amount to "disregarding all the sex I've had, I am a virgin", but that's just a somewhat off-putting quirk of the community. The languages themselves are full of interesting ideas that are being adopted by less purity-obsessed languages, and this is a good thing in the same way that the OO-purism of SmallTalk drove other more mainstream languages to adopt OO ideas and bring them in adulterated form to the unwashed masses (which had the nice side-effect of driving the purists nuts, and who doesn't want to see that?)
So I personally get the feeling that it's a great time to be alive and active as a software developer. We're barely out of the "bash rocks together to make hammer-like-thing" era of programming, and we get to be part of the most explosive growth phase of the most important technological growth curve in human history: the algorithmization of work.
One the one hand, I suspect ams6110 was referring more to those things we give names like "pattern," "architecture," and "paradigm," maybe even "stack," "platform," or "library" than to languages. On the other, my suspicion may be wrong, and I'd agree with him about it if it were anyway; so little that's been developed in the world of programming languages recently is anything new, and what isn't is as often as not a poor reimagining of something Lisp or ML had figured out pretty damn well ages ago, thank you very much.
Still, though, progress has been made even on the mainstays, even if the industry hasn't quite caught on yet.
Yeah on the surface. $IRRELEVANT_OLD_TECH didn't catch on or it wouldn't be irrelevant but _why_ didn't it catch on? Powerbuilder failed, but was it because you couldn't write a good enough program that way on 1995s hardware? Or because it was ultimately a stupid idea?
Somebody like me who has never heard of Powerbuilder would have to look into the technology, which would take longer but it would prevent me from just dismissing it because "this has been done before".
Remember it isn't what you don't know that gets you, it is what you know for damn sure that just isn't so.
I am not saying this is the case for all old developers, but it would be my concern.
Some day a person younger than you will say "this is just like Javascript that failed back in the day".
Yeah on the surface. $IRRELEVANT_OLD_TECH didn't catch on or it wouldn't be irrelevant but _why_ didn't it catch on?...
I'm a young person, too. Lipstick on a pig doesn't make a cow, you know.
Arguments like "It's only similar on the surface" I've found tend to give too much credence to incidental properties - this runs on X, it's widespread unlike previous solutions, it's better at specific Y use case, etc. Yet regardless of underlying platform, the concepts do not tend to evolve quickly, and it is all too often the case that their limitations have been discovered either in academia or engineering practice. These limitations will eventually be uncovered again, and no one learns from their failures or successes. Where languages and platforms shift, architecture will always bite you.
As for the reasons why, that's another fallacy. It assumes the status quo always maintains an equilibrium of what is inherently technical superior, and that popularity implies great technical qualities. The reasons can be plentiful, often it's unfortunate historical circumstances.
It's comforting to think we're on to something truly new, but this is rarely the case: http://www.dwheeler.com/innovation/innovation.html
Leaving aside the (substantial) ageism issues here, it looks to me like your reading of the GP's complaint is incorrect.
It's not a judgment that $NEW_TECH is going to not catch on or otherwise fail because it's just like $NOW_IRRELEVANT_OLD_TECH.
It's the observation that much of the $NEW_TECH that catches on and succeeds for a time often turns out to offer approximately the same utility as $NOW_IRRELEVANT_OLD_TECH... and similar adoption costs, which we pay over and over again. We rent rather than buy.
There are counterexamples I can think of -- new tools/abstractions/practices I've adopted that have resulted in near order-of-magnitude gains. But the ratio of these to other $NEW_TECH that just sort of shuffles the dirt around... well, that probably approaches another order-of-magnitude relationship.
And there's also the argument about the aggregation of marginal gains (see Brailsford and the British cycling team); approximately the same utility isn't quite the same thing as exactly the same utility and I don't think that should be overlooked. In fact, I think one could put together a specific case that the GP is arguably not correct in making an even comparison between Powerbuilder and webapps on precisely such a basis.
Still, an aggregation of marginal gains approach only ends up helpful if the marginal and opportunity costs are low.
How often do you find that's true for $NEW_TECH over $NOW_IRRELEVANT_OLD_TECH?
And since we're being free with judgments about age here (generalizations, naturally -- not that you or I would ever let such general thinking affect our judgment when it comes to individuals)... do most young developers really have enough knowledge and experience to answer that question effectively?
Further, most people seem to have little appreciation of the difference between order-of-magnitude gains and shuffling the dirt around. Certainly, there are those who are wrong in assuming anything new is just dirt-shuffling, but for anyone without experience, everything offers an order of magnitude. And this really is an engineering discipline---$NEW_TECH is never as good as its proponents say, but it the best trade off in some circumstances, while $OLD_TECH is never as bad (or good) as the "general consensus" would have you believe, while it is almost certainly inappropriate under some scenarios.
Because every hour I spend investing in a new stack and its details is an hour I can't spend thinking about product-level details, can't spend learning more learning about organizational-level matters, can't spend on improving more timeless investments like statistics, math, and soft/interpersonal skills. Not to mention fun things like music and travel and enjoying the company of people you like.
It wouldn't be so bad if most of the new shiny things in the software world were an order of magnitude better. But saying that 1/4 new frameworks or even languages present tha kind of power/productivity jump would be optimistic.
It's also hard to predict what will be popular five years from now. I thought that using Javascript on the server was pants-on-head retarded, but it's very popular, with no signs of passing on.
Well, there's no law against things being both terrible and popular. It is quite common.
There is value in keeping up with trends, but on the flip side there is value in sticking with sound ideas, even if they are not necessarily attractive in the labor market, and learn enough to be employable or self-sustainable in some regard.
I would say server-side JS might not necessarily be a great long-term prospect, at least in part due to limitations with SMP and unwieldy concurrency models. Even if it persists, the value of knowing might be more of a labor necessity than any inherent utility.
Because programming operates on lots of trends and conjecture, knowing which ones not to waste time on is a much more valuable skill than jumping to stay "relevant".
I remember the day that I got java 0.7 running on my spark 20. I would never touch the STL again, never have to worry about malloc and #def overwrites. No more gdb.
There's not much nice for c/c++ devs, pity them.
How many C/C++ programs?
If you're spending your free time learning about distributed databases, machine learning, cryptography--fields that existed in the 1990's but are more relevant and developed today because of the web--you're becoming a better programmer. If you're figuring out the latest "compile to JS" language or framework, you're wasting your time. You could do all that stuff in C++ or Lisp or ML. In 1994.
Maybe there are lots of programmers who don't stay current. But I also think there are lots of employers who can't distinguish between "staying current" and "keeping up with fashion."
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 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).
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?
And yet I do feel the ageism. I understand it and I'm not angry about it, but it's real, nonetheless. It's not a good feeling.