I'm a 40+ engineer in the NYC metro area and I've never felt more in-demand in my life! I think it boils down to a simple idea: computer-science is a dynamic field and THE FUN PART is that you need to always be learning.
There are still some colleagues my age who still wax about the days of writing JCL for their mainframe jobs and never evolved past the 80's and perhaps they gave a bad name for others who built on their of years of experience with evolving knowledge.
I decided in 2009 to specialize in mobile, when I realized how impossible it was for the startup I was working for to find any high throughput engineers, let alone high throughput engineers with niche expertise in mobile. I think it is an advantage in some ways during interviews that I can talk about decades of awesome projects I worked on while also being among the first to ship an iPhone app or a top ranking iPad app.
As they say, luck is when preparation meets opportunity. It's my job to make myself lucky.
That's reassuring, but... What's the average retirement age in the US? 60? And here we are consoling ourselves about still being in-demand at the ripe old age of 40.
Keep in mind that most of us aren't earning pensions and our 401Ks are earning peanuts so retirement at 60 effectively means "living on social security and whatever you managed to scrape together". Retirement will mean poverty for a great many people, I fear.
61 and climbing, but that number doesn't tell you much by itself. If you spend your career in SV as a reasonably in-demand developer and have no major life catastrophes, you might easily retire 5-10 years earlier with good money management. Partly depends on what kind of lifestyle you want in retirement, and where you plan to spend that retirement.
Come talk to me when you hit 50 :-) The "retire to Latin America" trope seems to be extremely popular amongst thirtysomethings who haven't necessarily considered what it would be like to suddenly put thousands of miles between yourself and aging parents, family, children, whatever friends you still have, etc. It just ain't that simple.
I'm sure its different for everyone, but I'm 31 and live in a 1100 sq ft condo with my wife; I could give away all our Ikea furniture in 24 hours on Craigslist and be on the other side of the world in 48-72 hours. That's just me though and how I like to live.
A decision to specialize in mobile in 2009 would probably have even worked out for a 60+ engineer if they were good at it. The best way to combat ageism is to stay technically relevant. Good decision.
> The best way to combat ageism is to stay technically relevant.
As I get older, I find that is easier said than done. I still spend quite a lot of time learning new things, but I've become less interested in learning things that are immediately marketable. Learning yet another framework that is marginally different than the one I used on the last project is not the interesting pursuit it once was. At this point I would rather invest that time in something that might fundamentally change my outlook and understanding of the world, which is beneficial in a meta way, but isn't really something that you can specifically write down on a resume.
I think just showing that you are still learning makes you relevant. Displaying some level of intellectual curiosity will get attention, even if it isn't the exact framework or new shiny thing that is the latest flavor. Also shows that you can pick up new things.
I'm curious about the "high throughput" part of your comment. Does that mean rapid development? Lots of lines written? or what?
I find the older I get, the slower I produce code. I spend more time thinking about the solution than coding the solution. This tends to frustrate my employers, who follow the "move fast and break things" philosophy. They think I shouldn't have to think about it, just do it.
So, I guess what I'm asking is, in your opinion, is my slowing down a problem? Or an advantage?
If your code ends up coming out the other end with fewer defects and ends up costing the company less overall than when similar tasks are done by your peers, then document that and present it to your bosses.
If it's incurring a similar bug load and just gets done slower, that's a problem and they're right to be upset.
I've seen both cases before, even from very experienced people, so it's very specific to the situation.
" team, especially one that does rapid development-"
sorry, what? any team that thinks "rapid development" actually means writing code more quickly is a team composed of idiots - I think I must be misunderstanding you?
It's never easier to blitz through interviews and ramp on new tech than if you've seen most/all of it before.
We're just figuring out where the old abstractions land and the syntactic sugar has made life easier.
There is a massive personality issue at play. If you love this stuff, you don't let new stuff pass you by and end up being a specialist on the dead end. You're constantly sharpening the sword... because you love sharpening swords. Staying relevant and employable is a side-effect.
Depends on the interview. I would not do well in algorithmic questions these days, because I know better than to write my own. I was good a that stuff at University, but I have never had the need to implement a linked list or hash table since.
What was the job market like when you graduated from university? Do you think it's easier for you to get a job now than it is 10, 20 years ago? Just curious to hear your thoughts.
When I graduated from college, it was 1994. Most people who were making good money at the time were Unix C programmers so that's what I did out of school. Honestly, I felt more ageism because I was young at the time (contrary to this article) than than I ever do now as a 40+. I was getting paid a relatively low salary and was expected to work insane hours. My accountant friends were probably making more money out of school. So, I wouldn't say it was harder to find a job then, but it was harder to find something cool or interesting than it is now.
I also think I wrote kind of silly code then. I always laugh when I think about a persistent hash table I had to write and how I went out of my way to find prime numbers for M slots using Fermat's Simple Theorem (not his last theorem) and testing for Carmichael numbers. Of course, there aren't that many prime numbers in the first place and a static table would have worked just fine! I always remember this as part of my evolution from an inexperienced academic kid solving a problem that doesn't need solving vs. experience to know where to comprimise and just get it done.
Even then, I knew it was important to start specializing where the needs were evolving, which was win32 programming at the time and eventually Windows MFC programming. This all dove-tailed nicely years later when I started working on the Playstation 3, where you develop in MS DevStudio but the PS3 was essentially a Unix box. It's funny how things work out.
The only thing that sucks about being a 40+ engineer is when I say "whachoo talkin' bout Willis" or "it's tricky to rock a rhyme", half the people don't know what I'm talking about.
> Honestly, I felt more ageism because I was young at the time (contrary to this article) than than I ever do now as a 40+. I was getting paid a relatively low salary and was expected to work insane hours.
Interesting! Was it ageism or was it because you were inexperienced? This is tricky because I feel like even if younger developers are discriminated against based on their age, they might be less likely to attribute it to ageism. If this is true then I wonder if older developers are for some reason more likely to blame ageism for their career ills instead of skill obsolescence, hence making ageism seem like something that mostly affects the older devs...
There are still some colleagues my age who still wax about the days of writing JCL for their mainframe jobs and never evolved past the 80's and perhaps they gave a bad name for others who built on their of years of experience with evolving knowledge.
I decided in 2009 to specialize in mobile, when I realized how impossible it was for the startup I was working for to find any high throughput engineers, let alone high throughput engineers with niche expertise in mobile. I think it is an advantage in some ways during interviews that I can talk about decades of awesome projects I worked on while also being among the first to ship an iPhone app or a top ranking iPad app.
As they say, luck is when preparation meets opportunity. It's my job to make myself lucky.