Two Years Later: Perspectives on Software Engineering from a Former Actuary

“The longer you wait to take that chance, the shorter the Future will be when you arrive.” -Daniel Arsham

Recently, a colleague of mine asked during a project meeting:

You must think software engineering is so much easier than being an actuary, right?

After kicking it around in my brain for a second or two, I realized the question was surprisingly thought-provoking. How much do they know about being an actuary? What gave them the impression that actuarial is a more difficult career path? Does this mean they think their own job is easy?

It was a fun challenge to boil such a large question down into a one-minute answer that wouldn’t derail our meeting and get us both fired. But even after giving an on-the-spot answer, the thought has lingered to the point where it’s more than worthy of a blog post (and a timely one at that: it’s now been nearly two years since I left my last actuarial role, which is hard to believe). Naturally as a career-changer, I’ve put plenty of thought into roles on both sides…so let’s do some introspection, analyze different aspects of both paths, and see if we can put together a coherent answer to my colleague’s question. What’s the easier career, actuary or software engineer?

Breaking In

One of the great selling points of the actuarial profession for me as a high school junior taking a bunch of AP classes was the guarantee of career progression via actuarial exams. For better or worse, I’m a natural-born exam-taker. While I acknowledge that I enjoyed this grind for some time, any prospective actuary should know that we’re talking about dedicating at least every other season on the calendar solely to living and breathing formula sheets and flash cards. Actuarial exams are notoriously difficult: the pass rates speak for themselves. I failed almost as many as I passed, and almost every pass was a score of 7 (10 is max, but 6 is all you need). If you decide to go down this road, make sure you find colleagues that want to study together — you might just make some lifelong friends, and it can even help with retention for the exam.

The conventional wisdom when I was in undergrad was that two or more exams under the belt would get you hired for your first gig, but anecdotally (thanks to friends who are still actuaries) I know that more and more entry-level prospects are showcasing three or more preliminary exams on their resumes. This seems to track with the exam pathway getting longer over time, and with a longer road comes a greater risk of stagnation. Guaranteed progression is a double-edged sword: when you encounter an exam with material that just doesn’t really click with you (totally normal — this happened to me multiple times), you might get stuck…and you will probably have to expend extra energy to get unstuck.

After switching careers, I feel that studying for actuarial exams is most comparable to the interview phase in software engineering, which is already thoroughly documented on this site and across the Internet. At the core of it, there’s a lot of overlap between grinding out problem sets on Coaching Actuaries or LeetCode: you’re still drawing on retained knowledge to solve a puzzle. The only big difference is the business domain! So it’s fair to say that I had a major benefit from past experience here, and as a result studying for engineering interviews felt pretty natural. It would be interesting to transition careers in reverse and see if the opposite was true, but I’ll have to leave that experiment to someone else.

Leveling Up

Despite having spent many hundreds of hours studying for actuarial exams, there’s a reason I felt like I hit a wall in my career as an actuary, and career change became the only real way to knock it down. Increasingly I felt like I was being asked to do things like build highly technical solutions to support my team’s analysis, or improve a data-gathering process for financial projections. As a pure health actuary, I felt totally stuck in these situations (and way too often, we would turn to building something fully in a spreadsheet as the definitive answer). Now as an actuary-turned-engineer, I think back to some of the workbook models and tools I built, or even some of the earliest Python code I wrote while still in the insurance industry, and I laugh…because I would never do it that way again. I continually describe my career switch as having granted me superpowers; as an actuary, I eventually felt limited in both technical capabilities and choice of industry. (Of course, the lack of industry choice is mostly nature of the beast — actuaries were conceived for insurance after all!) Dedicating more and more time to learning software engineering removed these limiters.

But I don’t deny that my career as an actuary gave me essential skills that I still lean on as an engineer. The greatest boost to my professional skillset came from my time as a consulting actuary. Operating in an environment where you’re on 10+ different client teams and each one sees themselves as your #1 priority will stretch you to your limits, but you will come out of the other side as a much stronger project manager and communicator.

There’s one concept in particular from consulting that I still leverage regularly, and that’s thinking “backwards” from the project finish line. What story are we trying to communicate to the client about their health plan so they can make informed decisions? Now given that story, what analysis do we need to perform to tell it? So far during these two years as a full-time software engineer, the Product Owners I’ve most enjoyed working with had this exact same mindset, doing whatever they could to bring insights from app users into our planning meetings so the engineers could understand why we were doing what we were doing. Maybe this is an “old habits die hard” situation, but I find it tough to get going on a project without this kind of context serving as motivation, unless I’m working for myself. (Note to self: might be fun to try that long-term one day…)

Org Dynamics

A fun realization I’ve had recently is that actuarial and engineering roles are more similar than I ever considered them to be:

• Both can be highly technical
• Both have a management-focused career track, where the goal is to bring out the best from their team of individual contributors and future managers
• Both have avenues for career specialization

Perhaps more importantly, the team members we interact with day-to-day fall into a lot of similar paradigms. The stereotypical quiet genius, the poor communicator, and the “person on the team that knows everything” are all tropes that exist in both worlds. Both even have the concept of a legendary employee that has 10x output, give or take. (My actuarial analogue for this: it took me six years to finish just the preliminary actuarial exams, but it has been done in less than one year…)

So what’s the differentiator here? Maybe there isn’t one. I think there’s a larger story to tell here about team dynamics in a corporate environment. I’m lucky enough to have worked in both near-perfect chemistry orgs and “does anyone turn on their webcam here?” orgs, where I joined and left the company without even seeing some team member’s faces. I would run through a wall for some of the mentors and mentees I’ve had in both careers…but I’ve also been one degree of separation from layoffs, a witness to the heartless side of corporate America that most of us deal with on a daily basis. I thank career change for unlocking other industries of work for me, but also for revealing that [career change =/= culture change], and that engineering teams can certainly have much of the same friction that actuarial teams do. There’s no easy answers here, other than finding a leader who will unflinchingly advocate for you and the work you do, even when it comes at their own expense; and finding team solidarity, full of individuals that want to bring out the best in each other and support one another.

So which is easier?

Well, maybe my colleague was right about software engineering being easier…but it’s hard to say for sure. It definitely takes a lot of time, money, and effort to earn those sweet actuarial credentials, but a question I failed to ask myself while barreling down the exam path is where my fulfillment would come from after finishing exams and earning my credentials. I couldn’t find it in insurance, and of all the business models in our world, I would wager that insurance has to be near the bottom of the “Things Can Change Overnight!” list. (For better or worse, we know that things are regularly changing overnight elsewhere, even for the current titans of tech.) It’s vital to stay on your toes in tech to keep up with the pack; if you enjoy this constant challenge, then software engineering seems like a nice place to be.

There’s also reason to believe that the tide is gradually shifting away from actuaries, as data scientists and engineers begin to explore new ways to replicate and perhaps even outperform traditional actuarial methods, both in accuracy and cost. To me, this is mostly an advertising problem: with their deep statistical background, actuaries are already well-positioned to be the data scientists of the insurance world, with a little more cross-education and collaboration. Having witnessed firsthand some of the actuarial pushback to this non-actuarial encroachment, I guess my ultimate takeaway is this: whatever comes next, it’s nice to at least feel like I’m the one with superpowers.