Students often ask, “What is a typical day when working as a mathematician in industry?” Typical days vary across different companies, positions, years of experience, and interests. Following are insights from our careers in industry that allow us to be curious and creative while providing value to our companies. In Part I, the focus is on how a day varies as we develop a mathematical solution. Part II is focused on how typical days change over the years of one’s career.
To appreciate the daily mix of activities you should understand the six general steps taken when developing a solution to a business problem:
- Defining requirements
- Developing a mathematical problem formulation
- Defining an algorithm
- Implementing an algorithm
- Transitioning the solution
- Analyzing results
Each of these steps can take hours to months depending on the type of project. Also, the process is rarely a linear one as we describe below and frequently bounces back and forth as more is learned about the problem.
When a project starts, there typically will be several meetings with the end user, often called the customer, to determine the solution requirements. These meetings could be in a conference room or, as in our cases, they could be on an airplane production line, at an analyst’s desk, or at an overseas military installation. The number of meetings and time frame needed to develop an initial set of requirements depends on the difficulty of the problem and the experience of the customer organization in teaming with mathematicians. During these meetings, the composition of the technical team needed will be considered. Mathematicians are always working in teams with collaborators from various departments and with varied backgrounds, which leads to a higher quality solution and exciting learning in new areas.
Once you have gathered the initial requirements, a fun part of the solution development is creating a mathematical problem formulation (i.e., mathematical equations that define the problem and will be used for algorithm development). Experienced mathematicians will leverage their insights into what approach and tools can be targeted for the business requirement (e.g., estimates on problem characteristics and sizes that can be solved within the run time requirements) to have a likelier first-time quality solution. The step of defining a problem formulation often uncovers additional requirements, another benefit of the problem formulation step.
With the initial problem formulation defined, another engaging and innovative part of the solution development is the creation of the algorithm. While the development of new algorithms might be a dream task for a mathematician, the goal is to determine an algorithm approach that is the most efficient in terms of development time while still meeting all the requirements. As a result, utilizing prior algorithms developed in the company, and open source or commercial software when possible, are always considered first.
Once an algorithm plan is in place, implementation begins. A phased plan typically is developed not only as good practice, but also to be able to get input from and show progress to the customer. During the early steps, development languages are considered, where the decision depends on many factors including run and development time requirements, how the algorithm will be called including any system integration plans, and developer skills. Insights gathered when testing the algorithm frequently lead to changes, including additional requirements.
Because sharing phased results with the customer has often taken place, the solution at the end is ready to be transitioned. Although training often takes place so the customer will know how to run the tool and interpret, analyze and use the results, there is typically additional interaction with the customer to analyze results and work on requirements for the next extension. Analyzing results with the customer and seeing the value the solution provides can often be the most exciting and rewarding part of the entire process.
Typically, mathematicians will work on multiple projects at a time, and the state of each project will dictate the day. If one is involved with requirements and/or solution transition and analysis, there will be more meetings than if one is involved with implementation.
This overview has been just a glimpse into what the typical day of an industrial mathematician might include based on the steps for creating a mathematical solution to a business problem. In Part II of this article, we will give an overview of how typical days in the life of industrial mathematician change over the years.