In my experience if an older engineer/programmer is more expensive than a younger one --- but the older one is better --- the older one will be hired. You get what you pay for. As long as your skill set isn't basically a "commodity" (generic web design for example) you will be ok. Put another way---if your decades of experience _don't_ give you some appreciable advantage over a 20-something new guy, then yes maybe you are in the wrong business.
One of the most entertaining conferences I ever attended was Usenix, several years ago. The paper sessions typically went like this: a grad student would stand up and present his and his advisor's research. In the sbsequent question-and-answer period, one of a small number of grey-beards (you'd recognize their names, but I can't remember who exactly it was; I'm old, too) would come to the mic and ask some variant of, "when we tried that back in the '80s, it didn't work because of.... How are you dealing with the problems?" There was never any real answer. (To be truthful, there were also a number of responses along the lines of "Why didn't you cite our earlier work?" which were more annoying since the typical true answer would have been "Because you only published it in a single post in rec.arts.no-one-reads-this." Bah.)
Since then, I've learned one thing: experience in this field doesn't give you any advantage. Or, more precisely, Cassandra, it doesn't give you any advantage that anyone will pay attention to.
I've had many similar conversations since that conference, usually along the lines of:
Them: "We should do X."
We: "That didn't work the last time; A, B, and C happen and only super-genius levels of D will get you out of the mess, which we don't have."
Them: "But X is the hot newness and everything's different this time, anyway."
Or sometimes:
We: "We're doing Y."
Them: "That's stupid, everyone is doing Z now." (Them almost never has more than 2-3 years of experience, by the way.)
We: "No one we've hired in the last ten years knows how to do Z, Z offers no actual advantage over Y, and I'd personally prefer not to have to deal with 27 different ways of doing the same thing."
Them: "I'm doing Z."
We: "Great. You'll be solely responsible for that project until you quit, then we'll throw it away and rewrite it. Just like last time."
Sure, you can keep up with the technology fashion; that's fairly easy. But it's a bit dispiriting to see the same problems in the new tech from the last time the dharma wheel rolled around. And to be unable to convince the new kids not to try to cross the railroad bridge because the 12:15 really does have a good on-time record. The entertainment value of watching projects hit the same shoals eventually loses its charm.
Indeed. I've worked for more than one company that died because it didn't listen when I said, e.g., this won't work because math. In that case, simple multiplication and comparing the result to currently available IOPS.
A lot of people just don't care until they actually crash into the brick wall, but in a start up that's frequently too late, and never fun. Our host pg has commented that more than a few dot.com failures were in part inevitable due to technical failure. I'm sure that's still the case.
Frequently, it's not technical. I have in mind one individual who still maintains a project management position at a former employer, who has repeatedly made every last project management mistake possible, right down to "adding people to a late project makes it later." It got to the point where I was uninterested in his latest fiasco because it was like 1980s sitcoms---a minor variation on something that wasn't all that funny the first time around.
Hired a new guy who had a few years of experience, but less than most of the existing folks (most of whom, admittedly, had the same one year, over and over). He immediately starts telling us how we should be doing things. Case in question: Maven.
Now, Maven is a nice enough tool and he's probably right in that it is the new "industry standard", but it doesn't do anything that we need to do better than Ant. (Making it easy to add new dependencies to a project, in particular, is something that I anti-want to do.) The only advantage, as far as I can see, would be to allow the new guy to use an IDE other than Eclipse. The costs are pretty large, though. It was an uphill struggle to get the cowboys to use any build system instead of Eclipse's export. This would be a new build system, a new project layout, and either we could convert everything, which exactly no one had time to do (and did I mention the one year of experience thing?) or just add Maven to the already gigantic ball of mud.
Carefully explaining all of that, plus the point that futzing around with build systems did nothing to help us get stuff out the door, which is what we were having problems with and what we hired him to do, led only to blank looks and his decision to "demonstrate the advantages" in the project he was working on---exactly the reason we have a ball-of-mud problem.
It's not age, it's what you know (what value you deliver!). Some older people around me are pushing themselves as hard as when they were undergrads, attending online seminars, trying out new software platforms and tools. They're doing fine and still leading the conversation ahead of other people. The people getting replaced are the ones who aren't developing their skills.
There's also a wage ceiling for software developers, even with the newest skills. This shouldn't be surprising though, all employment has a wage ceiling.
Would anyone mind elucidating why I was downvoted for this comment with no response? I feel it's truthful and respectfully stated. Several other comments agree with it.
I don't know what the HN perspective is on linking to your own old comments, but I can't write this any better today than I did last year: https://news.ycombinator.com/item?id=7374123
Ageism is a brutal reality.