I love to program and am convinced that programming has been beneficial to my career. Other actuaries proudly proclaim their reluctance or inability to program, and a recent Wall Street Journal article even suggested Excel experts should keep their skills secret and “run the other way.”1 An actuary’s unwillingness to program is always a question of attitude not aptitude: Programming is easier than passing actuarial exams.
“Programming Your Career” makes the case for becoming a programming actuary. It will explain why practical programming skills can enhance your career prospects. Some types of programming have a greater career impact than others, and this article will offer guidelines for which types of projects to undertake and which to avoid. Finally, it will explain why you can be more efficient as an actuary-programmer today than ever before and suggest some ways to get started.
Deliver a Meal, Not a Recipe
You program to answer business problems. Actuarial models are invariably implemented in a program and so programming allows you to deliver a meal — the answer — not a recipe. The answer is much more satisfying!
I’m not saying you have to be a good programmer to be a good actuary; I am saying that given two actuaries with similar actuarial skills, the one with better programming skills will be more useful, that is, better able to get to an answer in a more efficient and timely manner. And in the long run, the more useful actuary will have a more successful career. Companies are not run on the basis of theory of what should be analyzed, but on the results of actually applying relevant theory and models. Today, application means programming.
Programming for Greater Understanding
A model is a simplified representation of relationships among real world variables using statistical, financial, economic, mathematical, or scientific concepts and equations. Models are used to help explain a system, to study the effects of different parts of a system, to predict the behavior of a system, or to derive estimates and guide decisions.2
Modeling and programming have a symbiotic relationship: A model is generally implemented in a program and the rigors of programming help you better understand the process you are modeling. Being forced to work the details of a model through to implemented code is a good discipline and almost always reveals aspects of the model that are not obvious from a cursory review. Once the model is in hand, it becomes easier to perform what-if analyses in order to “study the effects of different parts of a system” and more fully understand systemic drivers. If it is hard to generate examples or test hypotheses, then few are generated and tested. Special cases and boundary conditions are missed, resulting in an incomplete understanding.
Statistics is not a spectator sport. Learning statistics by reading and applying each method in a statistical package is not a bad approach, though beware the “solution-in-search-of-a-problem” syndrome. I learned a lot from the SAS/STAT manual as a student, and I know other actuaries who found this approach productive. Being hands-on will teach you how to use each method so you can quickly move from textbook examples to your own applications. That said, everyone who uses GLMs should be able to set up and solve a GLM model in Excel, explicitly creating the deviance function and using solver (or even better, iteratively re-weighted least squares) to find the maximum likelihood solution. Do this once by hand, thereafter, use GLM in your favorite package. The winners in the analytics battle understand the theory and its implementation.
Programming as a Career Booster
Not all programming exercises will enhance your career. As the WSJ article suggests, being the local Excel-help desk may well be detrimental to your career. However, being unhelpful will also be detrimental to your career. It can be a fine line.
You are adding value to your actuarial career when your programming supports your actuarial work. Remember Chris Dixon’s famous quote about data scientists:
A data scientist is someone who is better at statistics than any software engineer and better at software engineering than any statistician.3
If a data scientist interpolates between a statistician and a computer scientist then I believe an actuary attempts a three-way interpolation among a statistician, a computer scientist and a business person — typically an underwriter. Actuaries understand both the models and the business processes they abstract; they know what is possible and can use that knowledge to envision and enable better solutions. Through programming they can better understand each model and, most importantly, can deliver solutions based on these models in a timely and efficient manner.
Here are some practical guidelines to help guide your understanding of when you can add value, both professionally and personally, as a programming actuary:
- You are actively involved in selecting, designing and parameterizing the algorithms used to solve each business problem. Simply coding to implement actuarial design choices made by someone else is a red flag.
- You leverage existing routines and you do not spend too much time (re-)coding fundamental algorithms — do not roll your own.
- You sell (pitch, explain, propose) your model results and are key to getting buy-in and adoption. You are the voice of your work. You don’t waste time polishing a graphical user interface (GUI) and the user interface to your tool; you sell the result and outcome! To quote Kimberly Holmes, Global Head of Strategic Analytics at AXA XL, “Be outcome-focused, not output-focused.” You are programming to enable a better outcome, not to write cool code.
- You can explain the strengths and weaknesses of your models and their implementations as well as particular data reliances and sensitivities. But beware: Actuaries are often better at presenting the weaknesses of their models than the strengths. Avoid this trap.
- Name your system or tool. There is surprising power in a name, and it will be associated with you.
- If you see that your solution needs to be in production, you lobby for investment to do that rather than try to become a one person IT shop. Work with IT to have your tools integrated into production workflows.
- Your programming enables superior productivity. At several points during my career, I programmed because I didn’t have time not to program. Getting work done required an automated solution and the programming time more than paid for itself. The trick to a good return is understanding which types of program you will reuse. That I learned the hard way ….
Conversely, you are probably not adding value in the following situations:
- If you are an order taker you are not career-programming. If other people are making the algorithmic and modeling decisions and you are just implementing them, you are not being valued as an actuary. You are in danger of being pigeonholed as the programmer. Fear of the pigeonhole is a reason why many actuaries don’t want to program, but it is a symptom of other failings and not a legitimate excuse.
- You waste time tinkering with a GUI. However much you love your GUI it is almost certainly terrible. Use a professional UI/UX designer if you need a user interface.
- You try to put half-baked solutions into production, worry about deployment or start being the help desk. These are important problems, but they can be handled by other professionals who are typically not paid on actuarial salary scales.
- You build an app — this is a special case of my “don’t program GUIs” comment above. No one will use it. They don’t want yet another system, they want to get to a better outcome.
Beware: Programming is fun and addictive. Make conscious decisions about how you program your career.
Remember that you have an IT department for a reason. It is a surprisingly long road from “It works on my machine” to “It works everywhere. It is secure, documented and upgradeable.” If you respect that road, you will win the hearts of your IT colleagues and work more productively with them. Your manager will appreciate your efforts more if you document your methods to ensure a reproducible process. Train others — your replacements. Fear of key-person risk traps entire departments in spreadsheets. As much as I used to love Excel spreadsheets, they are rarely the best answer.
Programming Today is More Productive Than Ever
Programming today is orders of magnitude more efficient than it was 20 or 30 years ago. The advice to program your career was not as clear cut then. But, times have changed and we need to change too. The evolution of programming is an education in itself.
The first computer I programmed on had 4K of memory. You loaded the DOS on a 5 1/4″ (genuinely) floppy disc and then typed in your very basic BASIC program.
Less than 10 years later I learned to program in C on a machine with 1MB of memory and a spacious 40MB hard drive. The computer and software cost over $6,000 in 1988 dollars. It was an expensive, slow and painful process. I had one textbook4 and when it was unclear I just had to figure it out.
Ten years later I learned to program C++ and Windows. The manual had expanded to five massive tomes and I spent several thousand dollars on text books and guide books, in addition to a considerable outlay for Visual Studio. It was still a slow and painful process.
In 2016 I started to learn Python. My inception to date financial investment: zero. The software is free. The documentation is free. If I encounter a problem, I can find a solution on Google or Stackoverflow.com in minutes. Python has an enormous user base and, as a result, packages are available for almost all the boring stuff. Packages are easy to install from central repositories, generally with the source code available for inspection. I can focus on adding actuarial value in my programming efforts. Although I chose to learn Python, the same comments apply to R, except the R online help is not quite as comprehensive since it has a smaller user base.
Programming has exposed me to fintech, insurtech, crypto, open-source and other worlds and has greatly expanded the intellectual community I learn from. If you are interacting in these spaces you need to be able to converse on a level playing field. They are creating data lakes and standing up technology stacks.5 To be taken seriously you need to be fluent in their jargon and have an understanding of their concepts and tools. You gain that understanding by interacting and experimenting with their tool sets, i.e., by programming. Many startups are a website, a white paper and a Github repo. They are building tools and they want developers and users to interact with them. The cutting edge is easy to access, educational and exhilarating. To broaden our actuarial reach beyond insurance requires that we extend our outlook beyond traditional tools and partners, and work with a wider and more diverse community of professionals. Get started today!
Getting started …
There is one downside to all of these new capabilities: They can overwhelm the beginner. I had two failed attempts to learn Python before I achieved escape velocity. Here are a few suggestions for getting started.
First, remember that if you’ve written an =IF(…) statement in Excel then you have already programmed. It is not hard! Have confidence you will succeed but expect it will take time and effort.
Second, be prepared for a steep learning curve. But know the learning curve offers increasing returns for your effort for a surprisingly long time: You will fly higher than you have ever imagined. The biggest hurdle to getting started is learning enough to understand the help! At that point, the training wheels come off and you will learn more quickly. You will develop a sense of what should be possible and what to Google to discover it. And you will find most programming languages are similar. Whatever you learn for one will help with the others.
Third, and this is critical, start with a particular problem in mind. If you just read a book on Language X you will quickly be overwhelmed. Concepts will blur and seem irrelevant. But if you have a particular problem — ideally driven by a business problem — you will be better able to dedicate the concentrated time you need to make progress. And at the end, you will have created something useful.
Fourth, choose your language. A Reddit thread on r/actuary6 recently asked, “What programming languages should I learn to be a good actuary?” The collected wisdom: English, SQL, R (and R over Python), VBA, COBOL (honestly) and SAS (“but I haven’t seen it at my company”). You must know SQL as a data description language. It is foundational but different to most other languages. Pick between R and Python and know you will then be well set to pick up Python or R, VBA, COBOL, etc., as needed.
Here are some good starter projects — mostly things where Excel, well, fails to excel.
- Data munging: Become the data scientist!
– String manipulation. Python has the best out-of-the-box text manipulation I have seen, but most serious languages are far more powerful than Excel. Look at regular expressions.
– Automated data collection and aggregation, e.g., pull information from a variety of websites into a summary dataset and analyze it.
– Use the R tidyverse package.7
– Use Python pandas (panel data sets).8
- Try web scraping and data collection, e.g., FRED9 time series downloads and analysis or interact with the Twitter API.10
- Create more complex data visualizations and graphics, e.g., create plots by-line, by-state, using ggplot in R or seaborn and matplotlib in Python.11
If you are still in college, take a basic computer science course; the underlying concepts in computer science help you learn all languages. The CAS has R seminars and is considering a Python introduction at the CAS Ratemaking, Product and Modeling Seminar. There are numerous great online resources.
Conclusion
To be clear, being a good programmer does not make you a good actuary and being a good actuary does not require that you program. Interpretation, communication and contextual understanding are all important, but times are changing. The insurance industry was an early adopter of big data techniques and actuaries led the work to include behavioral data into ratemaking in the 1990s. Since those auspicious beginnings, we have lost ground to statisticians and data scientists applying predictive analytics in our own space.
For those aspiring to be actuarial leaders of tomorrow, I believe programming experience today is critical. Programming is not an either/or choice for an actuarial student, nor something to learn “if you have the time.” It is a necessity. Your ability to interpret results is honed by producing results, seeing how different methods work and when and why they don’t. Without actually coding it is hard to really understand and appreciate what technology can do. And remember that our competition, the data scientists, can and will program (and better than statisticians).
A strategy of trying to out-interpret data scientists will fail the profession. Problems requiring nuanced interpretation today will be built into an expert system tomorrow. However, the ability to solve a new problem through ingenious application of a model or method will endure. Only experience built through practice offers a route to permanent, productive employment. And practice requires programming. Start programming your career today!
1 https://www.wsj.com/articles/the-first-rule-of-microsoft-exceldont-tell-anyone-youre-good-at-it-1538754380
2 ASOP Modeling Standard, draft.
3 https://twitter.com/cdixon/status/428914681911070720?lang=en
4 The C Programming Language by Brian Kernighan and Dennis Ritchie, Second Edition Prentice Hall, NJ (1988). It is by far the most useful computing book I’ve ever read. It teaches not only C but how to program, all in less than 280 pages. You can find a PDF online.
5 We, of course, are just building databases with computers!
6 https://www.reddit.com/r/actuary/comments/9lol3g/what_programming_languages_should_i_learn_to_be_a
7 http://r4ds.had.co.nz/introduction.html
8 https://pandas.pydata.org/
9 https://fred.stlouisfed.org/
10 https://developer.twitter.com/en/docs.html
11 https://ggplot2.tidyverse.org/, https://seaborn.pydata.org/, https://matplotlib.org/
