Ask HN: Where to Work After 40?

When I was 40, I was a few years into my consulting gig, and that went very well for a long time (I'm a cybersecurity guy with a strong ICAM and PKI background, located in the Ottawa area, so there was plenty of work with government clients.)

But I was starting to tire of the consulting grind and found I was doing a lot of the same-old-same-old in most contracts (TRAs, PIAs, audits, etc., and, after incidents, explaining to senior management how recommendations made 6-12 months previously might have prevented or at least greatly mitigated said incident).

I was fortunate: 6ish years ago, I was winding down a couple of contracts through a friend's company and he needed someone to fill a gap and knew I had downtime, so I started a contract with him, 90+% WFH. Every few months we'd chat about where he was taking his company and about what the future product teams would need (he'd bid successfully on a pair of unrelated PoC-to-product contracts, one hardware, one software, and was looking to take things to the next level).

Long story short, 5.5 years ago I retired my shingle and returned to full time "wage slavery" (tongue firmly in cheek), almost 100% WFH. My initial role was to work with customers, fill gaps, learn fast, build fast, and move on, and our plan was to move me into a business-development-slash-product-management role, which appealed to me because of two previous contracts that had a lot of that (he'd worked on one of those and knew what I brought to the table).

You know that old saw about life being what happens when you are making other plans? Yeah, that happened :->

My title now is Director, Special Projects, but what that really means is "our customers think this is critical, no one has any idea how to do it, make it happen". It's more a senior/staff engineering position in some ways, mostly systems programming, the levels getting progressively lower (my Christmas holiday reading has been the excellent Mara Bos book on Rust Atomics).

I'm far more technical now than ever before, entirely hands-on, and it's fantastic. It helps tremendously that I work with a great team, people I've known for years, but hadn't worked directly with until now, and that our boss, my friend, understands how complex is what we are doing and how we need regular breaks and downtime; at the same time, the entire team knows how important are revenue and deadlines.

My advice, if I have any, and it all comes with a strong dose of YMMV, is two-fold:

One, it will be OK. You will be OK.

40 isn't the end, nor is 50, and I doubt 60 will be either. I'm pretty sure I'm going to spend the time around my 65th year working on ABE and data filtering in FPGAs, but that's just a guess. :->

Two, work your network.

Talk to your friends and colleagues, ask who's doing what, what the gaps are, where they think they are going, and what they might need. You have skills, others need them, do NOT under any circumstances undervalue or dismiss them.

I won't advise or even suggest consulting, because it isn't for everyone, and the kinds of contracts that, IMHO, at least, best allow you to explore the space and build a better network, are, by their nature, stressful: short term, possibly requiring travel, and sometimes spread out such that when one ends you don't know when the next will begin. But if you are OK with a certain degree of churn, uncertainty, and repetition, then it might be something to consider.

Regardless of how and where you go, remember Advice One: It will be OK, you will be OK, 40 isn't the end.

If your pager response SLO is not that strict and is not impacted by such routines, then you probably can't justify staffing a team of 20, either.

And I can imagine why - there were quite simply too few people born in countries with a 95%+ literacy rate over the past 20 years for the usual generational turnover to occur.

And "experience" is what allows one software architect to select the right stack, and the other to select something that turned out to be abandonware half a year later. It is what allows one developer to introduce abstractions in exactly the right place, and another to either overabstract or turn stuff into a tangled mess. It's what allows one team lead to estimate the right time and resources for a project, while the other keeps missing deadlines or burning out team-members.

I'm going towards my fifties now. And I have made, or been part of, so many mistakes, failures, errors and stupid decisions. Much more than the average 20-something colleague. I've seen software projects survive 10+ years of continuous change just fine, and others to grind to a screetching halt after even 8 months already.

I'm selling this experience now. As freelancer. I still like to write code. But the experience allows me to often not write it in the first place. Or to write very little of it. Or to map out a path that allows us to write it fast today and continue to do so in the next 15 years.