> Very young employees can sometimes be too aggressive about "what is this legacy garbage?
The flipside: I'm old now, but can remember when I was young in the early 2000s.
At the time I was in the Unix space. Older engineers were adamantly pushing Solaris 6 and 8 on incredibly overpriced, poorly performing UltraSPARC over Red Hat on Xeon, for the blindingly obvious reason than they didn't really like learning anything new.
Of course, that was private: to anyone unfamiliar with the platform, they'd simply say that 'you couldn't get support for Linux'. They knew this was false - IBM and Red Hat were banging down their door to sell support contracts (still far cheaper than Sun's rubbish hardware + good support contracts), and Red Hat had hired a lot of Sun's staff - but if they made enough noise, they thought they could slow things down.
It worked, for a couple of years.
(Later on I realised that enterprise architecture purchasing choices are frequently based on dinners, golf tournaments, and straight up dropping cash into your account, but that's a separate story. )
Short version: older engineers can be overly change averse, much like younger engineers can be overly enthusiastic about change.
Maybe we should stop putting all older engineers in the same basket, and same thing goes for the younger ones.
I've known some older engineers (older than me, heh) make crap decisions because they didn't like change.
Then I've seen younger engineers completely mess up good, maintainable code because they think that knowing one language makes them masters of software development.
I try not to hire any of those two persons.
BUT, I've also seen young programmers completely fail because they couldn't adapt to a newer (or older...) technology.
And I know some very much older programmers who are constantly reading up about new stuff, and loving it.
Bottom line, look at who you're hiring, not only how old they are.
The flipside: I'm old now, but can remember when I was young in the early 2000s.
At the time I was in the Unix space. Older engineers were adamantly pushing Solaris 6 and 8 on incredibly overpriced, poorly performing UltraSPARC over Red Hat on Xeon, for the blindingly obvious reason than they didn't really like learning anything new.
Of course, that was private: to anyone unfamiliar with the platform, they'd simply say that 'you couldn't get support for Linux'. They knew this was false - IBM and Red Hat were banging down their door to sell support contracts (still far cheaper than Sun's rubbish hardware + good support contracts), and Red Hat had hired a lot of Sun's staff - but if they made enough noise, they thought they could slow things down.
It worked, for a couple of years.
(Later on I realised that enterprise architecture purchasing choices are frequently based on dinners, golf tournaments, and straight up dropping cash into your account, but that's a separate story. )
Short version: older engineers can be overly change averse, much like younger engineers can be overly enthusiastic about change.