by Carolin Dirks
To be honest, most maths students who are just about to finish their studies have no specific plan of what kind of job they want to pursue after graduating. Up to that point, they might have realised what they did not know in their first semester, namely that there are plenty of opportunities in different areas of industry and academia for a mathematician besides the “obvious” choices, like the financial sector and insurance companies. Artificial intelligence, automation technology, big data, deep learning, computer vision – just a few fields of great interest for modern industry, and all of them are very closely related to maths. Most of them seem to promise a much more exciting job opportunity than an insurance company – with so many possibilities, why did I finally decide for a job as a software developer in an insurance company? The short answer: Because it offers a huge lot of fun, exciting tasks, complex mathematical and computational problems, and besides, great colleagues and an outstanding working atmosphere.
Let’s have a look at the long answer. For me, during my last years at the university it became clear that I wanted to be a software developer. Solving specific tasks using logical skills and computational tricks and contributing to something “useful” were the important parts for me, in addition to a strong desire for a preferably stress-free and enjoyable working atmosphere, while I did not really care about the specific application behind my work. The job advertisement at a big and well-known German insurance company sounded exactly like what I was looking for, next to the very good reputation of the employer regarding the labour conditions. So I took the chance, honestly without a specific imagination of how a “typical day” as a software developer would look like.
Now, 1.5 years later, I am still not able to say what a typical day looks like, simply because every day can be very different. Every day can pose different tasks and new challenges, with almost no repetitions, with lots of new things to learn, with lots of new insights – and the more I understand how things work, the more I can participate actively in new areas of responsibility. A developer is not only the aimless “executor”, but also needs to keep an overview of the whole software architecture, stay in touch with the “client” (in my case, the company itself, especially those who are going to work with the new software after its release) and other departments and work together with the rest of the team in order to develop a viable product. Thus, the best way to describe what I am really doing is to divide my tasks into three “areas”: The learning part, the conceptional part and the implementational part.
My first year in my new job was dominated by the learning part. A mathematician is typically not educated in many practical skills, a mathematician is educated in independence, learning receptivity and frustration tolerance – in being able to understand complex problems and find smart solutions by her- or himself. Basically (and hopefully not sounding overbearing) a mathematician is able to understand almost every problem, and this is in my opinion one of the main reasons a mathematician is hired. Consequently, I needed to learn a lot, about programming languages and especially about state-of-the-art tools and technologies in software development. This was a whole new world for me – before, I had literally only implemented “plain code” without a suitable development environment, without fancy testing tools and without connecting to databases. And for me, there are very few places which are more suitable for getting a wide insight into so many different fields connected to development. Learning is not only considered to be necessary, but also promoted – and everyone in my department is encouraged to spend time on learning. Additionally, we have the philosophy that, roughly speaking, every developer in my team should be basically able to do every task – of course everyone has some kind of focus, based on his or her knowledge, but everyone is also encouraged to undertake tasks where he or she is a complete beginner.
Today, learning new things is still a daily business in my job. Another part which becomes more and more important is the conception and discussion of particular features of the new software. The “clients” (in our case, the “specialist department”, those who, in contrast to me and my team, know how an insurance as a product needs to work) decide about new features they want. This can be a very small and simple request like “I want this button to be green instead of blue” or a big new feature like the possibility for the customer to report a damage case. The developers (like me) discuss the technical requirements and details, check if everything is technically possible, roughly figure out which parts of the software are affected and what has to be done and wrap everything up in one or more specific tasks. In addition, the developers can contribute their own ideas or write “IT-only-tasks” (tasks which do not bring a visible new feature, but are necessary for some other reasons).
Consequently, the last part is the implementation part – namely solving the tasks. This (mostly) means implementing new pieces of code, integrating them into the complete software (after a quite strict reviewing process by other developers) and writing automated tests for the new features. One task can take from a few minutes (like the green button) up to several weeks, often accompanied by further discussion rounds with the “insurance experts” or with other developers. Besides, a task can be done completely alone or even in a team of several people – in every case, the whole team discusses everyone’s tasks in a daily meeting together, where problems can be put on the table or opinions can be exchanged. All in all, everything is based on teamwork: If you don’t know the answer to a question, lots of phone calls and sometimes a whole bunch of people staring at the problem later always lead to a solution.
All three parts together make this a perfect job for me. As an applied mathematician, I am still able to make use of the skills I acquired during my studies and still solve complex problems. The job does not only require programming skills, but also the ability to “delve into” specific issues and to analyse all sides and effects of a problem, while always raising new challenges and opportunities to learn new things – but without the pressure of exams and the question of “what should become of me” in the future.