Programming Your Career

actuarial review
publications
programming
Author

Stephen J. Mildenhall

Published

2019-01-07

Programming Your Career

Confession

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.

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. 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.

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 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.

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 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.

  • You are actively involved in selecting, designing, and parameterizing the algorithms used to solve each business problem. Just 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 crucial to buy-in and adoption. You are the voice of your work. You don’t waste time polishing a GUI and user interface to your tool; you sell the result and outcome! As Kimberly Holmes, Global Head of Strategic Analytics at AXA XL says “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 shortcomings in 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 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 if you re-use code!* The trick to a good return is understanding which types of programs you will reuse—something I learned the hard way. 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.

Conversely, you are probably not adding value in the following situations.

  • If you are an order taker you are not career-programming. If you implement other people’s algorithmic and modeling decisions, you are not valued as an actuary. You are in danger of being pigeonholed as the programmer. Fear of the pigeonhole is 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 UI.
  • You try to put half-baked solutions into production, you worry about deployment, or you start being the help desk. These are essential, but they are handled by other professionals typically not paid on actuarial salary scales.
  • You build an app—see “don’t program GUIs.” 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 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 More Productive Than Ever

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!

Getting started

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.

  • Data munging: become the Data Scientist!
    • String manipulation. Python has the best out-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 various websites into a summary dataset and analyze it.
    • Use the R tidyverse package7.
    • Or use Python pandas panel data sets8.
  • Try web scraping and data collection, e.g., FRED9 time series downloads and analysis or interact with the Twitter API10.
  • Create more complex data visualization and graphics, e.g. create plots by-line, by-state, using ggplot in R or seaborn and matplotlib in Python11.

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.

Conclusion

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!

Footnotes

  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 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.↩︎

  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/↩︎