[malaporte]

I don't think age as a numerical thing is the issue here. The problem is probably more related to people that stopped learning / being interested in new stuff when they landed a stable job. So they've been using the same skill base for a long time, and suddenly they realize they are obsolete.

Sure they may have grown their skills inside that particular silo, and that is worth something, but maybe outside the whole world has taken a different direction.

Never forget that the cool tech you're learning now will be out of fashion in a few years, and completely obsolete a few years more down the road (replace years by months for any JS framework out here :p).

[dvirsky]

This also creates a bias against older engineers. People assume that since they meet a lot of "dinosaurs" (in terms of technology) out there, 40+ engineers will probably be dinosaurs as well.

Also, there's some unspoken assumption, that if you're 40 or even 50 and "still" an engineer, something is wrong with you - you should have been a CTO or something years ago, so you either have bad personal skills or are untalented, kept for some Job-Security-Tech you know.

The sad thing BTW is that this attitude is a self fulfilling prophecy, causing talented engineers to push up the ladder and become bad managers, or go into marketing/sales/etc. Even if they're not bad at it, we are losing great engineers due to that, who were just scared to remain engineers.

BTW to me personally tech is a second career, although I've been programming since I was a child, my first career was in journalism, and later web content and product management. I've only started working professionally as an engineer at 29.

[conistonwater]

Your line of thought relies very strongly on the assumption that the skills of software engineers are tied to the particular language or framework they are using. Surely that's just complete nonsense?

[klibertp]

> the skills of software engineers are tied to the particular language or framework they are using

Well, not all of them of course, but yes, knowledge of a particular language matters.

For example:

a) idiomatic code in a given language is easier to maintain, a programmer who doesn't know this language won't write idiomatic code for awhile

b) lack of knowledge of available libraries may result in reinventing them poorly, leading to NIH syndrome, which is bad for maintainability... and just bad in general

c) std lib of a language is a special case here: without having memorized what it has to offer you're going to work many times slower due to having to google all the time

and so on.

You can either know a lot of languages and technologies and bet your career on ability to learn new things very quickly, or you can be content with one language and become a master in using it. In the latter case much of your skills do become tied to the language and particular technology, so just be sure to pick one which is not going to stop being popular in a year.

[malaporte]

Well, I wasn't thinking of specific skills for a given language/framework, but maybe more how those frameworks help you evolve along with the tech landscape.

I started my career around 15 years ago, working on a complex server system written in C++. The important skills back then were all about managing concurrency using mutexes, RW locks, events, and so forth.

Fast forward to now (with lots going on in between), and I find myself working again on server software, but this time the approach is much different: now for dealing with concurrency I'm relying on immutable state, and using Futures or actor systems to coordinate parallel work. It's been years since I've had problems with a deadlock.

Bottom line, it's true that a good programmer doesn't care about language or framework, since he can pick those up pretty fast anyway. But it's a skill that needs practising, and I've seen people neglect this and then regret it later.

[minthd]

Whether it's true or not, that's how employers choose employees.