The use of a scientific method is one of the chief differences between a software engineer and a software developer. Observing, hypothesizing, coding small experiments to test the hypothesis, collecting and analyzing results are all steps good software engineers take in the normal course of their work. Adam McQuistan knows this all too well after making a career hop from science to software engineering.
“After I finished my bachelor’s degree in biochemistry, I worked in a genomics lab as a scientist. Some of the work was mundane and repetitive. I felt like a cook. I would follow set instructions (like a recipe), then wait for the timer to ring,” said McQuistan.
Having taken college courses in software development, McQuistan started automating things in the lab.
“Eventually my employer saw that I enjoyed it and asked if I wanted to get a master’s degree in computer science and switch roles,” McQuistan said. He worked full time, attended graduate school in the evening and went on to hold several software engineering jobs before coming to Mutual of Omaha in late 2021.
Now McQuistan works in Information Services as an engineer III and solution lead supporting Mutual’s Workplace Solutions business unit. He and his team are involved in a multi-year, phased technology modernization effort moving group insurance applications to the AWS (Amazon Web Services) cloud.
“Our team helps provision a cloud-based architecture that is modern, robust, resilient and leverages all the benefits of a cloud environment,” McQuistan said. “We are using DevOps practices to automate cloud deployments and monitoring and alerting to keep things operational.”
Modernization efforts are also making use of event-driven microservices architecture to replace the more monolithic applications developed in the past.
“Microservices make it possible for many teams to work on small API services that can be combined to create larger business processes,” McQuistan explained.
In his current role, McQuistan is responsible for ensuring the work aligns with the enterprise architecture, both long-term vision and short-term goals as well as working in the trenches to figure out ways to make it happen. For that reason, his typical day differs from the traditional engineer role — although it begins in much the same way.
“First thing in the morning I log on to see if there are any notifications from the previous day that need immediate attention. Then I have about an hour of development time followed by a daily standup meeting with the rest of the team,” McQuistan said.
Rather than spending the rest of the day writing software or configuring cloud components, McQuistan usually attends more meetings with product owners and architects.
“I also interface with other teams in our area. As they raise impediments to completing their work, it often falls on my team to prioritize and resolve those issues,” he said. His biggest challenge in recent memory involved a full day of troubleshooting a piece of infrastructure code that stopped working even though the team made no changes to it.
“It seemed like our parsing algorithm was truncating characters in a very small number of cases. That had never happened before,” McQuistan stressed. “We were thinking, ‘It can’t be, nothing has changed!’ But it turned out to be a really weird edge case and we had to resolve it.”
McQuistan said his most rewarding days involve helping other engineers solve challenging problems.
“It’s one of the best things about my role — to find ways to help them without just giving them the answer. Sometimes it’s a matter of honing a set of skills to craft the perfect Google search,” he said. “Helping an engineer work through a really hard problem and seeing how excited they get when they figure it out — that’s the best part of my job. That’s what I love.”