I love to program, and I am convinced 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 more straightforward than passing actuarial exams.
“Programming Your Career” makes a case for being a programming actuary. Some types of programming have a more significant career impact than others, and the article will offer guidelines for which types of project to undertake and which to avoid. It will explain why practical programming skills will enhance your career prospects. 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.
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. But I am saying that given two actuaries with similar actuarial skills, the one with better programming skills will be more useful: more able to get to an answer efficiently and quickly. And in the long run, the more useful actuary (or data scientist) will have the more successful career. Companies are not run based on what should be analyzed; they are run on by applying relevant theory and models. And today, application means programming.
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 decisions2.
Programming and modeling 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, “study the effects of different parts of a system,” and understand systemic drivers more fully. If it is hard to generate examples or test hypotheses, few are generated and tested. Special cases and boundary conditions are missed, resulting in an incomplete understanding.
Statistics is not a spectator sport. The winners in the analytics battle understand the theory and the implementation. Learning statistics by reading and applying each method in a statistical package is not a bad approach—though beware of “solution in search of a problem” syndrome. As a student, I learned a lot from the SAS/Stat manual, and I know other actuaries who have found this approach productive—being hands-on will teach you how to use each method to move from textbook examples to your applications quickly. 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. Only once: after that, use
glm in your favorite package, but once by hand.
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 harm your career: it can be a fine line.
You add 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 better at statistics than any software engineer and better at software engineering than any statistician3.
If a Data Scientist interpolates between a statistician and a computer scientist, then I believe an Actuary attempts a three-way interpolation between statistician and computer scientist, and a business person—typically an underwriter. The actuary understands 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, critically, deliver solutions based on those models in a timely and efficient manner.
Here are some practical guidelines to help you know you will add value personally and professionally as a programming actuary.
Conversely, you are probably not adding value in the following situations.
Beware: programming is fun and addictive. Make conscious decisions about how you program your career.
Remember 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, 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. Much as I loved Excel spreadsheets, they are rarely the best answer.
Programming today is orders of magnitude more efficient than it was twenty or thirty 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 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 ten 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 $6000, in 1988 dollars. It was an expensive, slow and painful process. I had one textbook4, and when something was unclear, I just had to figure it out.
Another 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 textbooks, 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—any problem I can Google on Stackoverflow.com where I almost always find the exact solution in minutes. Python has an enormous user base, and as a result, packages are available for virtually 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 through 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 dramatically expanded the intellectual community I learn from. If you are interacting in these spaces, you need to converse with them on a level playing field. They are creating data lakes and standing up technology stacks5; to be taken seriously, you need to be fluent in their jargon and have interiority into their concepts and tools. You gain that understanding by interacting and experimenting with their toolsets, i.e., programming. Many start-ups are a website, a white paper, and a Github repo. They are building tools and 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 expanding our outlook beyond traditional tools and partners and working with a broader and more diverse community of professionals. Get started today!
One downside to all of these new capabilities is that 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, 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 to effort for a surprisingly long time: you will fly higher than you ever imagined. The highest hurdle the beginner faces 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 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 in the end, you will have built something worthwhile.
Fourth, 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 from 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 excellent starter projects, mostly where Excel fails to excel.
pandaspanel data sets8.
ggplotin R or
If you are still at college, take an introductory computer science course: the underlying concepts in CS help you learn all languages. The CAS has R seminars and is considering a Python introduction at RPM. There are numerous helpful online resources.
To be clear: being a good programmer does not make you a good actuary, and being a good actuary does not require you can 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 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 an actuarial leader of tomorrow, I believe programming experience today is critical. Programming is not an either/or choice for an actuarial student, not something to learn “if you have the time.” It is a necessity. It is hard to understand and appreciate what technology can do without coding. Your ability to interpret results is honed by producing results, seeing how different methods work when and why they don’t. And remember the 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 that today require nuanced interpretation will be solved by the expert system of tomorrow. However, the ability to solve a problem through the ingenious application of a model or method will endure. Only experience built through practice offers a route to permanent, productive employment. And to practice means to program. Start programming your career today!
ASOP Modeling Standard, draft↩︎
The C Programming Language by Brian Kernighan and Dennis Ritchie, Second Edition Prentice Hall, NJ (1988). It is by far the most helpful computing book I’ve ever read. It teaches C and how to program, all in less than 280 pages. You can find a PDF online.↩︎
We, of course, are just building databases with computers!↩︎
https://ggplot2.tidyverse.org/, https://seaborn.pydata.org/, https://matplotlib.org/↩︎