Why Companies Should Hire Older Developers
Nerval's Lobster writes: Despite legislation making it overtly illegal, ageism persists in the IT industry. If you're 40 or older, you've probably seen cases where younger developers were picked over older ones. At times we're told there's a staffing crisis, that companies need to import more developers via H-1B, but the truth is that outsourcing and downsizing eliminated a subset of viable developers from the market. Those developers, in turn, had to figure out if they wanted to land another job, freelance, or leave the technology industry entirely. But older developers still have a lot to offer, developer David Bolton writes in a new column: They have decades of experience (and specialist knowledge), they have a healthy disregard for office politics (but can still manage, when necessary), they're available, and they're (generally) stable.
I've been in the technology business for almost 20 years now. In my personal experience, older engineers are much more productive than younger engineers. Younger engineers are much more likely to partake of the "free" dinner offered by the company and work 80 hour weeks. They are also significantly cheaper.
To HR we (engineers) are a fungible commodity anyway. Of course they go for the younger people. Given that they command lower wages AND work more hours their effective hourly rate is much lower. So it's a no brainer.
Of course, I would guess from experience (although I have no specific evidence) that older engineers are cheaper in a productivity/dollar sense, but that doesn't even enter the argument in a modern corporation.
Unless we get into management, we older folks (Lord, is pushing 40 really older now?) are better off in .gov/defense jobs or working for small companies where individual people (may) value our contributions.
That's a pretty ridiculous statement. My actual experience intuitively says just the opposite. I work at a security company that is largely made of guys who just got out of Israeli SIGINT (their mandatory service). The older guys write kernel code know what C compiles to, and see the vulnerabilities intuitively. The new ones have quite a bit more experience in high level languages, while being almost oblivious to abstraction breakage that leads to security holes. At best, I'd say that the older developers get stuck dealing with older code bases (that are making the money) and tools (because the newer ones can't deal with it anyway). But on security.... Prior to the mid 1990s, everybody in the world seemed to be working on a compiler of some kind. This deep compiler knowledge is the most important part of designing and implementing security against hostile input; ie: LANGSEC.