[jacobsenscott]

Successful companies don't have this sort of framework churn. You see it in the startup world because companies are always starting up right when some new framework came out. But anything out of the MVP stage doesn't churn on frameworks, unless something went horribly wrong - like passing on experienced engineers.

[gambler]

>Successful companies don't have this sort of framework churn.

Sure they do. They're just slower at it. I've seen plenty of established companies jump on React bandwagon right after jumping off Angular, for example. One year and the "new" framework is thrown out of the window. (But all the software written in it remains and creates maintenance liability.)

Funny thing is, more often than not they don't even need SPAs in the first place.

[hrktb]

It happens, but usually for some decent reason.

Some companies for instance have a very stable business and keep a stable stack, but then hit a wall when trying to hire. They'll see average people coming to them, but those are not as efficient as their current staff who is now super experienced and want people who can match them.

Or they'll try to find graduate level people to train forward, but newcomers have no interest in the old stack, as it won't pimp their resume that much to their eyes.

Solution: keep using trendy frameworks.

Veterans will be happy to see shiny things, recruiting becomes that much easier, buzzword capacity increases all other the map. And all of these have a real benefit, in people retention, hiring cost, marketing opportunities that can cover the man/hour cost of moving frameworks.

[dmix]

True not everything is like the crazy front-end JS world but when it comes to age we're talking about a very long timescale. Say ~40yrs in the business (20+40=60).

How many companies maintain a framework/stack from 20-30yrs ago? The average new company will die after ~7yrs from start date. Only a few major monopoly-style companies survive like IBM and Microsoft. Which is basically the only software that runs forever on that type of scale. That's only a percentage of available jobs.

And even within IBM and Microsoft there are countless sub-projects within the company...beyond say the classic Windows OS, Word, etc from the 90s there are tons of other programming work going on (for ex: VSCode is JS or IBM's cloud + consulting work). Very few of those newer projects are going to look much like the 20yr old one you cut your teeth on early in your careerr.

I don't think no one is saying age discrimination doesn't exist. But this is a unique problem in our industry rarely found in other fields.

[ido]

    Very few of those newer projects are going to 
    look much like the 20yr old one you cut your 
    teeth on early in your careerr.

Maybe I'm too young to comment, but my first job as a developer was almost 18 years ago now & even tho I'm no longer using the same language & tools a lot of the challenges of software engineering are the same now as it was then (and you learn using new stuff incrementally anyway).

Overall the experience of developing a comparable-scale project in java on tomcat in 2001 is not that different from a modern one in ES6 on node.js in 2019.

[jacobsenscott]

I've been doing this about the same amount of time, and yes, everything is the same as it was 20 years ago. Frameworks come and go, but they aren't that different. And you are hopefully mostly writing application code not framework glue. So the framework doesn't matter.

All the popular languages are sadly still descendants of C, just with variations on the strongly/weakly typed spectrum, and if functions are first or second class.

The hard stuff is still identifying requirements, managing expectations, and writing code that can adapt to changing requirements overtime. None of the hard stuff has anything to do with the language or framework you are using.

[Traubenfuchs]

That's even worse then: You are honing obsolete skills and will have a hard time finding a new job if you want or have to.

So you are an expert in Java service oriented architecture? Sorry, but we are now looking for developers with Spring Boot 2.x Microservice experience.

[k_sze]

Well, software folklore seems to say that COBOL graybeards get paid A LOT.

[Traubenfuchs]

Does this hold for everything? Do we have any other examples besides the fabled COBOL developer?

Are application server / Java XML SOA graybeards also paid a lot?

My current technological focus are Spring Boot applications, seasoned with everything that comes with that: SQL, devops basics, etc. If Spring Boot is still a thing in 10 - 20 years I'd be extremely surprised.