[jgrahamc]

"Unlike Engelbart, I have re-tooled. I now work in JavaScript in the browser and on the server. I had to walk away from the codebase that I loved. I understood that the price of relevance is to give up fighting at some point and settle for a partial victory. I think I was right in the development environment I created. But right doesn't mean the world uses what you created."

Yep. That's the key to staying relevant: change with the times.

[ams6110]

For me, the thing that gets a bit discouraging at times is the feeling of riding a slow-motion merry-go-round. Every 10 years or so you see the same ideas start to come around again, only with some new paint and landscaping.

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."

[derefr]

I see the same thing, but feel much more optimistic about it: it's not, in my mind, that tech is effectively fashion, but rather that there are "futurist" ideas that tech keeps trying and which keep not getting adoption, because it's not their time yet—the state of the art isn't there to make the experience for the average consumer (or the average developer) justify the costs.

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.

[smitherfield]

Not to be that guy, but

Apple Newton: 1993

Palm Pilot: 1997

Smartphones: ~2002

iPhone: 2007

Android: 2008

iPad: 2010

[scarmig]

His numbers were in base 5.

[timmy-turner]

And you hopefully have learnt from the mistakes Powerbuilder did back in '95, not making them again. So in theory you're ahead of the crowd of today.

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.

[tjradcliffe]

I don't see that at all. I started out when "structured programming" and "recursion" were both exciting concepts. OO came along and over a ten year period went from "useful for UI" to "the One Ring To Rule Them All" and while the shine wore off a bit, it really did help.

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.

[silverlake]

Most companies aren't using the trendy new languages and tools. The bulk of jobs today are for C++ ('83), Java ('95), Javascript ('95), Python ('91), and maybe C# (2000).

[sjolsen]

It's a shame, too, since C++14 is a far cry from 1983's C++ (or whatever version the majority of the segment of the industry which uses C++ is actually using), and the others are similar stories.

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.

[Retra]

C++ dumping ten pages of unreadable error messages on you because you forgot a semicolon or misspelled an import? If that is C++14, I'd hate to see 1983's version.

[mcguire]

1983's C++ didn't have templates.

[tomjen3]

As a young person my biggest concern with hiring old people is that exact attitude: this is just like $IRRELEVANT_OLD_TECH.

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.

[wedowhatwedo]

Powerbuilder failed? I made a ton of money programming with Powerbuilder back in the 90's. How is that a failure?

Some day a person younger than you will say "this is just like Javascript that failed back in the day".

[vezzy-fnord]

...this is just like $IRRELEVANT_OLD_TECH.

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

[walshemj]

Amen when I was looking at hadoop it suddenly dawned on me that I had been doing map reduce back in the early 80's for British Telecom.

[wwweston]

> As a young person my biggest concern with hiring old people is that exact attitude: this is just like $IRRELEVANT_OLD_TECH.

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?

[mcguire]

"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."

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.

[wwweston]

Something I've found as I've gotten older, though, is that I have a stronger and stronger sense of wasted time every time I have to learn a new way of doing the same thing. Particularly if the new way involves a bleeding edge leaky abstraction.

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.

[fsk]

That is one of my biggest concerns. A lot of the new tools are just different, not better. But you're expected to know all of them.

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.

[georgemcbay]

" I thought that using Javascript on the server was pants-on-head retarded, but it's very popular"

Well, there's no law against things being both terrible and popular. It is quite common.

[fsk]

What does it say about software as a serious career, if tools that are awful are popular and widely used?

[vezzy-fnord]

Generally sound, but there does seem to be a certain breed of vanguard who lives off being heterodox with regards to the computing mainstream, yet functions just fine and likely harbors plenty of insights. Much of the Go team lived full time on Plan 9 at one point or another, and it's not like all of them were Rob Pike or Ken Thompson.

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".

[bentcorner]

I think I'm coming to grasps with this too. I'm over 30 and have spent most of my life building large desktop applications in C/C++. I want to eventually work remote, and looking at what's out there, there are very few opportunities with someone with my skillset. It's all modern frameworks and languages. So, I'm spending some of my own time learning some of this stuff.

[_yosefk]

Embedded programming is much more stable wrt languages and (often non-existent) frameworks. Nice for C/C++ devs.

[housel]

Embedded programming is also harder to do remotely due to needing hands-on access to development hardware, frequent access to hardware engineers, expensive test equipment, and so forth.

[sgt101]

I worked as a C and then C++ dev for a few years and then I started a Ph.D writing a C++ code base.

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.

[tosseraccount]

How many java programs are running your desktop now?

How many C/C++ programs?

[vonmoltke]

It's also a silo that can be hard to get out of and is very hard to get into, because all you do is C or C++ work and everyone wants C or C++ experts for their jobs.

[curun1r]

This. I see too many older developers who complain about ageism, but what's really going on is that they're essentially the same developer they were 2-3 years into their career. If you've been working in the industry for over 20 years, employers can and should expect that you've made the most of it. Those developers have very few problems with ageism. It's the ones that have become comfortable and stagnated that have trouble.

[rayiner]

I'm not a programmer anymore, so I don't have a horse in this race, but I cringe when people exhort older programmers to "stay current."

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."

[johngalt]

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.

[curun1r]

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.

[strlen]

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).

[pjbrunet]

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.

[DannoHung]

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?

[tptacek]

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.

[scrozier]

I am 57 and quite current. I have launched several startups and kept fresh constantly. My current client has me doing lots of leading edge stuff that some of their younger devs couldn't do.

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.

[31reasons]

What kind of ageism have you experienced ? Can you describe some experiences ?

[hoprocker]

Who was it that said, "It's not 10 years worth of experience, it's the same year repeated 10 times"?

[spacemanmatt]

Someone with 10 years of experience, unable to recognize the nuances one picks up by repeating those 10 years of experience with 10 years of context to make better sense of it.

[hoprocker]

Excellent point; that 10 years can make you a specialist.