Hacker News new | ask | show | jobs
by dmix 2641 days ago
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.

1 comments

    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.

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.