This article from explores why coding, although crucial for actuaries, is seen as a secondary skill, and writing software a different career. Time to change all that.
The actuarial profession is undergoing a process of modernization that is driven by technology. Despite this, many actuaries are unsure how to improve their technology and programming skills, lacking experienced mentors and any knowledge of best practices. There is a valuable opportunity here for actuaries to draw insights from software engineering.
Actuaries and their stakeholders increasingly understand that the innovative use of technology is one way to gain a competitive advantage. Tools and systems built with code can improve efficiency and reduce costs, among many other benefits. This means that the demand for actuaries who can code is higher than ever, and will continue to rise.
However, most actuaries have only basic coding skills, if any. This is not surprising – the journey to qualification leaves little space for learning a programming language to an advanced level, and actuaries who do code are largely self-taught or have learned it as a minor part of an undergraduate degree. In these environments and in most actuarial teams, the focus is rarely to develop production-grade software. Instead, code is typically used to carry out activities such as statistical analysis and data visualisation – and as quickly as possible.
These factors have led to a shortage of actuaries who are highly skilled, experienced coders, something revealed by the abundance of inefficient legacy systems and bloated spreadsheets found throughout the profession. To borrow the software engineering term, many businesses are rife with ‘tech debt’ – the implied accumulated cost of taking shortcuts.
So, who should actuaries look to for guidance? The answer is clear: software engineers, who use code every day to design, develop, test and maintain applications. In practice, this view does not appear widely accepted by the actuarial community – actuarial teams seem reluctant to recognize their work as software, even when it consists of scalable and reusable tools that are written in code. Actuarial and software work are incorrectly considered separate disciplines.
To an extent, this is simply a labelling problem – but labels are important. When they choose not to describe their code as ‘software’, actuaries distance themselves from the technology world. This is not the case with data science. It is well understood that there is significant overlap between actuarial and data work. They both add business value by finding insights in data, and actuaries are all the richer for this collaboration.
Fortunately, actuaries don’t need a computer science degree to improve their coding skills. Progress and innovation in the technology industry has exploded during the past few decades, marked by a wealth of information on how to write better code. Actuaries can select from the available resources to suit them. There has never been a better time to do it.
All this points to a clear conclusion – actuaries interested in coding should lean into this speciality. And look to the broader technology world for guidance, not just data science.
It is not feasible to try to cover all the areas on which actuaries should focus in terms of writing software – it is a broad skillset that takes years of sustained effort to develop. However, there are a few areas in which beginners can make considerable progress with relatively little difficulty.
Beginners tend to write code in the form of one long script, consisting of a series of commands to be executed in sequence. This works for simple exploratory exercises but is not sustainable when the task becomes more complex, and does not lend itself well to integration with other processes or systems. You wouldn’t build a spreadsheet using only one worksheet – so don’t try to do everything in a single script, particularly when there are thousands of lines of code.
Look to well-established software design principles, which are not necessarily difficult to implement. A start would be to take duplicated sections of code and move them into functions, or take larger sections and create modules in separate files. Modularization has many benefits – each file, module and function can be independent, making them easier to understand, test, review and re-use in other tools.
This relates to the styling and formatting of the code. It might seem superficial but code that is difficult to read and understand is more prone to errors, harder to update and collaborate on, and more likely to become obsolete over time. Actuaries understand this clearly when it comes to spreadsheets – a messy spreadsheet with hardcoded parameters in the wrong places is not likely to pass the actuarial review process. Equally, code that has no comments and inconsistent naming, for example, should not be accepted.
Code style is one of the easiest things to improve – simply select a published style guide and align your code with its principles. There are many style guides available online, such as PEP8 for Python and tidyverse for R.
Actuaries tend to have a narrow conception of what ‘good’ looks like when creating a tool using code. They often implement the first (and perhaps only) solution they can think of, check it works on their use case, and move on. This approach tends to work only in the short term.
Testing for correctness is necessary but not sufficient for long-term solutions. There are many factors to consider, including portability, usability, simplicity, scalability, runtime, memory usage, and consistency with precedent. Good software is written by first considering the task’s requirements and constraints, then creating a solution that is optimized for the most relevant factors. This takes time, effort and empathy. It is always tempting to write a quick-and-dirty solution, but this just passes the burden onto those who will have to use the code in the future.
Learning to write better code does not necessarily mean understanding difficult algorithms or complex data structures.
Many best practices are easy to implement – invaluable and well understood by software engineers, but often ignored by actuaries.
There is one key factor necessary for an actuary to become an expert coder: a genuine interest in learning. In terms of concrete steps, there are four areas that actuaries can work on.
Take courses, attend conferences (outside the actuarial profession), read books, blogs and online documentation, and watch tutorial videos. This can give you the confidence to get started. However, learning new material or programming languages is not just for beginners – we are all on a continuous learning journey, and experts are more likely to know exactly what to Google (or ask ChatGPT) than to have memorized all the syntax.
Passive learning is a good and necessary start but will only get you so far; everything not put into practice will be forgotten. Actively implementing what is learned in a real-life situation is the best way to improve your judgment and problem-solving skills. Actuaries can also tackle coding exercises, try a machine learning project or even contribute to open-source software.
Without getting feedback on their code, an actuary can go their whole career without realizing that the ‘== TRUE’ in ‘if (condition == TRUE)’ is obsolete. This is a trivial example but it highlights the fact that those who do not seek comprehensive feedback on their code are limiting their potential. And thinking through feedback should not be a perfunctory exercise – it is a crucial step required for an actuary to improve.
It is helpful to recognize that the first solution written is almost never the best, so it is good practice to rewrite and refactor. This is a skill to be cultivated, and a good way to develop it is to write as many solutions to a single problem as possible.
For example, the factorial function can be implemented in code using iteration, recursion and vectorization. Each method has its advantages and disadvantages, and these can only be fully appreciated when they have been used.
There are still barriers that the profession needs to overcome. Few computer science graduates choose an actuarial career, meaning the profession is failing to recruit from a pool of candidates who have valuable technology skills. Moreover, many still consider programming a niche speciality, rather than a core element of the future actuarial skillset. Until these attitudes change, actuaries will not realize the full potential that technology can bring.
