I've worked with some older folks with a ton of experience (think: programmed in the 80s or earlier) before, and I have huge respect for those folks who can see a disaster coming miles away, or have been around the block enough times to have formed solid opinions on many subjects.
---
Although, while more often than not true (perhaps partly due to survivor bias), I do think that it's not a given that old programmers are wonderful. Some older folks do seem very set in their ways and unwilling to experiment in a way newer programmers aren't.
The natural example is that you hear a lot of "ah it's like <blah> all over again" where blah is something like winforms or activeX or CORBA or lisp or OSGI or what have you, but it's frustrating to come into everything with that baggage.
Yes it might be the same idea, but it might be executed quite a bit better! Perhaps much wider platform support, perhaps lower total cost of ownership, perhaps increased viability under current conditions, perhaps much larger community of people and tools!
The cycle turns much quicker than it used to, and using older, more mature but inferior technology sometimes does have a big effect on the bottom line or provides a disadvantage over competitors in a way that I don't think it did as much earlier on. Granted, this isn't always the case and knowing when it is also matters.
I think "strong opinions loosely held" is a great motto, and a lot of these folks follow that motto to wonderful effect.
---
It is also entirely possible do essentially the same project over and over in a multi-decade long career, and learn nothing material from it all, and I've seen that happen too.
---
In conclusion, I think older programmers can be a great asset to your team, and are often overlooked for no good reason. But they're also people like everyone else.
> The natural example is that you hear a lot of "ah it's like <blah> all over again" where blah is something like winforms or activeX or CORBA or lisp or OSGI or what have you, but it's frustrating to come into everything with that baggage.
This is why I have changed my thinking on this. I have used technology, I have seen technology fall apart at certain points. So I just poke at pain points. If I can't poke holes, that's good. Less worries on my mind. But otherwise...
"Ok when we used this we had problems with X when doing Y, your're using X and you're doing something that's very similar to Y, but you're not pushing it as hard as we did. Have you tested this?" Aww, your stuff fell apart. 10 minutes well spent, hah.
"It is also entirely possible do essentially the same project over and over in a multi-decade long career, and learn nothing material from it all, and I've seen that happen too."
I remember interviewing someone like that. He came to the interview with 11 years exclusive experience in a language that's 11 years old; yet he struggled with the basic patterns and terminology that should be wrote memorization for anyone who's worked in it since the beginning.
As I struggled through the interview, I wondered if the guy just outright lied on his resume, and if I should end the interview early.
Then, at the end, I got to my question that's basically writing boilerplate data access code, and he zoomed through it. I realized that this guy spent 11 years writing mindless data access code and never really learned how to program!
An historical perspective, which older programmers at their best bring to a project, is important in my view. When you look at the history of software systems you see that the better technology rarely wins in the marketplace. A lot of things contribute to the success of one system over another--technical excellence is not one of them.
Also, the significance of fad and novelty cannot be underestimated. When I see yet another new language or framework that is only trivially different from the existing ones, yet touted as the next big thing I can only grumpily roll my eyes.
We all have hopes that new things like languages will make things better or easier. Mostly it does. Today's hardware beats the 4004 CPU I started with.
Technology will move forward but building tech on back tech is a bad idea.
---
Although, while more often than not true (perhaps partly due to survivor bias), I do think that it's not a given that old programmers are wonderful. Some older folks do seem very set in their ways and unwilling to experiment in a way newer programmers aren't.
The natural example is that you hear a lot of "ah it's like <blah> all over again" where blah is something like winforms or activeX or CORBA or lisp or OSGI or what have you, but it's frustrating to come into everything with that baggage.
Yes it might be the same idea, but it might be executed quite a bit better! Perhaps much wider platform support, perhaps lower total cost of ownership, perhaps increased viability under current conditions, perhaps much larger community of people and tools!
The cycle turns much quicker than it used to, and using older, more mature but inferior technology sometimes does have a big effect on the bottom line or provides a disadvantage over competitors in a way that I don't think it did as much earlier on. Granted, this isn't always the case and knowing when it is also matters.
I think "strong opinions loosely held" is a great motto, and a lot of these folks follow that motto to wonderful effect.
---
It is also entirely possible do essentially the same project over and over in a multi-decade long career, and learn nothing material from it all, and I've seen that happen too.
---
In conclusion, I think older programmers can be a great asset to your team, and are often overlooked for no good reason. But they're also people like everyone else.