By looking at the Reputation by Age graph it looks more like there are just a few really good older developers. The rest probably are so out of touch they do not participate in developer communities such as Stack Overflow.
In my experience it has been that older developers hold on to old coding habits that are today considered dangerous and are reluctant to change that.
The rest probably are so out of touch they do not participate in developer communities such as Stack Overflow.
If you're curious about the down-votes, it may be because the above quote is an example of the particular kind of bigotry commonly referred to as "ageism". For future reference, if you are ever in a management position, that kind of thing is actionable in a work environment. You could get your backside sued off, is what I mean, if you are found to have used that in a hiring decision, for example.
I'm old enough to feel like employers may sometimes find younger and cheaper people to do dumb stuff faster.
What you say about the HR liability potential agrees with what I've heard from HR people, but never seen it be a factor in reality. In practice I can't imagine suing over a development gig. I can think of a million bad reasons people might not hire/let go a good developer (e.g. questions about manhole covers) but the "he's a curmudgeon who's reluctant to slap stuff together quickly" argument seems halfway legitimate.
So I say, bring it on, let's have an open discussion about who's smart, who's fast, who's wise, and when it even matters.
I agree with you. Experienced developers with skills are key for higher level functions such as architecture and system planning due simply to the "been-there" factor. My statement above was geared toward the "curmudgen".
Functions that return multiple types. Relying on private variables declared many level up with no intention of checking their existance or value, or sitting on perticular record numbers in tables from some other process blindly. 5 different versions of code doing the same relative process in slightly different ways depending on whichever developer's habit all live in a system. I've worked with a lot of old code from self taught engineers. You all may not like it or non-PC statement but it exists and its not pretty.
"I've worked with a lot of old code from self taught engineers."
Wait until you deal with code by university educated engineers who follow the rules of software development to the T. Design is emergent. If you see 5 different functions doing the same thing it sounds like you should go refactor it. Private variables that are unchecked? OMG, you might want to add a few asserts and a couple tests. These problems sound insurmountable.
It sounds like you're dealing with production code that makes money, probably so much that they can afford to pay you to improve it.
Thats what I'm doing. Refactoring and redesigning to be safer, more modular, and more optimized. Its one part engineering and one part CSI sometimes. It makes things like code contracts really exciting.
In my experience it has been that older developers hold on to old coding habits that are today considered dangerous and are reluctant to change that.