[mcbrown]

This (partly) explains a major paradox I see: all the best software engineers I know are over 50, and yet the young'uns who dominate the tech zeitgeist assume these same people are incompetent dinosaurs. The young'uns have reached the expert beginner stage, and because they assume they're experts, they refuse to seek out the actual experts to discover what it is they don't know. And if the young'uns ARE the experts, and older developers aren't part of their in-group, then by definition the older developers must not be experts.

This is why I (for one) am strongly biased towards hiring older developers.

[Karunamon]

All the best software engineers I know are over 50, and yet the young'uns who dominate the tech zeitgeist assume these same people are incompetent dinosaurs.

With age comes experience and also comes a strengthening of biases. Older people, so the stereotype goes, are inflexible and set in their ways, if very experienced in those ways.

It's not really paradoxical, it just depends on what tradeoffs you're willing to make as the person responsible for hiring, which depends on your line of business. There are few things more tiresome than someone making mistakes you already made two decades ago and tried to warn about, and the same applies to someone ignoring the new and improved ways to get things done just because they've always done it that way and know it the best.

[mcbrown]

"With age comes experience and also comes a strengthening of biases. Older people, so the stereotype goes, are inflexible and set in their ways, if very experienced in those ways."

Like most stereotypes, it might be true in some cases but far from universal. The literal two best developers I know, both over 50, are FAR from set in their ways. They are both constantly seeking new ways of doing things, exploring new languages and technologies, sometimes playing with low level projects (like making lights blink in interesting ways on breadboards), sometimes playing with high level projects (spawning hundreds or thousands of cloud instances to see how it works), but always looking for new things.

They might SEEM set in their ways when they shoot down bad ideas from expert beginners, but that's only because the expert beginner is confusing wisdom for lack of flexibility.

[maxxxxx]

Actually I find a lot of the young guys pretty inflexible. They jump on the cool thing of the day and then don't look left or right for alternatives.

[nevir]

Even worse, (generalization) they get frustrated and blame the team/project when the tool-of-the-day doesn't work out.

[maxxxxx]

I have given this some more thought and my theory is that probably most of the currently young devs will turn into old developers that will have stooped learning a long time ago. I guess that's the natural progression of things. Most people stop learning at some time. It happened to people who started 30 years ago and it will happen to the currently young hotshots too.

[beat]

As an over-50 programmer who likes to learn, I'm gonna talk about something totally unrelated to programming...

I'm a musician. I've been playing guitar since I was a teenager. As a technician, I've peaked out. I will probably never play faster, cleaner, or more complex than I do now. If anything, I'll start to go downhill as age takes its toll on my hands. But as a musician, I'm always getting better. I'm growing more conscious, more sensitive, more subtle, more sophisticated. I'm a better musician now than I was a year ago, and a far better musician than I was five years ago.

There's a similar thing in software. When you're still learning, still approaching real expertise, it's easy to think that being a great software engineer is about technique. It's not. I know a bunch of over-50 programmers. Sure, many are basically dead in the water, but many are not, and are constantly improving. It's not because they learn a new language, or a new framework. It's because they learn better taste. They learn more and more what is and is not important, how long things will take, best use of resources, translating requirements more effectively... these things will all make you a better engineer than writing glorified Hello Worlds in framework-of-the-month ever will.

[vacri]

We just had a young applicant who apparently had technical chops (I wasn't interviewing), but everything as "boring". This tech is "boring", that tech is "boring".

[Retric]

The best older developers are often really interested in new things. The real separation is more Hubris vs. Expertise. An expert knows how to get something done so they may take risks with a fall back option. Younger developers often have no fall back option other than just blowing deadlines or working at 2AM.

In the end the real 'problem' with older developers is they expose problems with your organization by providing what you ask for. If you keep asking for tight deadlines thinking people are going to ignore them you squeeze out creativity.

[spikej]

Sadly the older developers I've come across still write code the way they were writing 25 years back, without any regard for changes and newer developments in their chosen languages/DBMS. I've had to spend days convincing them to move to using newer language/DB features, feeling like I'm banging my head against the wall

[lazyant]

From what I'm reading (OK, maybe I just watched it in a Brain Games episode) the inflexibility of the old brain is not as set as previously believed (you can teach an old dog new tricks).

[Terr_]

> all the best software engineers I know are over 50

Survivorship bias? Perhaps all the bad 50-year-old programmers transitioned out or became "incompetent dinosaurs" in low-challenge areas where you can't easily see them.

[mcbrown]

If so, it's the cohort I see (the "survivors") that are routinely underestimated by tech bros. Which suggests the problem is even worse: if it visibly affects the best of the best, how bad is it for the average?