Yes. How many people have you observed in BigCo's whose value lies mostly in knowing some internal, proprietary process/technology/etc.? They might make $100K and be worth that amount for awhile to the BigCo compared to someone from off the street who doesn't know how to help out CustomerX who has been stuck on a customized version of the company's flagship product from 12 years ago. Maybe this person is compliant, polite, and completes near-menial work as asked. So, whenever a round of layoffs happens, he or she never gets cut.There are a bunch of reasons why those with scant technical skills end-up sticking around. However, the divide between this person's salary and that which he could get at another company grows ever wider.

Whenever I read stories about out-of-work "older" engineers, I presume them members of the categories I described above. What never seems to be said is that their plights usually are the results of decisions they made over a decade before. Stick with the current company doing crappy technology X? Yeah, it's boring, but the benefits are good and the work is low-stress. Go out on job interviews? I know deep down inside that I'm a mediocre developer, but my current company seems to put up with my crappy code and low productivity. SO, I 'd better stay right where I am. In this latter case, it could be argued that the "older" person's previous employ-ability was an accident or aberration.

There probably are few on HN who can imagine being like these people, so it's hard to relate. I just turned 37 and think that I'm a better dev than at 27. I've been thinking a bit about how my thought processes have changed. One thing I do now is mull through a lot of ideas before bothering to write code. If there are 50 ways to do something, it's worth taking a way to get a cup of coffee and think through a few possibilities. Along with that, I am less likely to believe that my current view into a problem or situation is accurate. What's the probability that the design I mulled over in the shower this morning will actually work out? As I've aged, I've assigned lower probabilities to positive outcomes, and I don't think my thoughts are of worse quality. So, I experiment more, and my experiments (iterations, or whatever else you want to call them) are faster, dirtier, and prove me right or wrong faster than the paths I embarked on before. My ability to hold a large, "working" model of a system in my head an perform experiments on it has improved over time. This is really what debugging is all about. I now ask better questions about how a system ought to function based on experience. What should happen if the async remoting process fails? How will humans know that a failure has happened? I think of these things because I've endured the pain in the past of finding out three days later that some background process has gone haywire.

So, what are the negatives? I'm less likely to run off and push a new technology into an important system. Around 2001, I wrote a macro-processor-y thing in Python (1.5x timeframe). The company I worked for was a Java shop. I was intrigued with Python, so I decided to learn something. The thing I built worked really well, but it was later converted into Java so that any one of N competent developers could hack on it when issues arose. Today, I'd suck it up from the beginning, look at the realities of the organization, and end-up writing the thing in Java from the beginning. Maybe I'd use some alternate JVM language, but I'd have to think hard about doing so. I'm still regarded as a loose cannon when it comes to dragging additional open source dependencies into codebases, so maybe I've never grown up. Who knows. I really can't think of any downsides to having gotten older other than feeling agitated when "kids" don't know how a hashtable works. Back in my day....