Software development as a chemical engineer
Toni Heinilä / 24 Aug 2020
About the author:
Toni Heinilä is a summer trainee at NAPCON. He works in the Software Engineering team as a Software Engineer Trainee. Toni is studying Chemical and Process Engineering at Aalto University. Outside of work and studies, Toni spends his time as a student volunteer or with general nerd-stuff, such as tabletop games and literature.
It is often said that chemical engineers are jack of all trades and have the skills and resources to be pretty much anything they want in pretty much any industry. Except that they can’t code. Well, I have studied chemical engineering in Aalto University, and while I have a computer science minor and a fair amount of experience, in practice, this summer has been a real crash course to software development.
The lessons I’ve learned on something other than actual programming are at least equally valuable.
I have been working as a software engineer summer trainee for NAPCON, and my work has mainly been development of NAPCON’s in-house dynamic process simulator ProsDS. In my work, I’ve learned a lot about functional programming, implementing chemical and thermodynamic equations, object oriented programming et cetera. However, the lessons I’ve learned on something other than actual programming are at least equally valuable: UI design, good workflow practices, and general project and teamwork skills.
Having different ways of thinking, different tools in your toolbox, is a valuable thing indeed.
However, the most important thing I’ve picked up during the summer is a new, different mindset. During their studies, chemical engineers learn, or are indoctrinated into, this certain way of thinking. The way we see the world may be a bit hard to describe, but it can be (over)simplified into a simple balance: in = out. This somewhat differs from other engineers, and certainly is different from the mindset of people with IT-background. It may be unconscious, but chemical engineers tend to look at every problem from that perspective. While it is a good approach to many issues, and it can be even applied into programming, it’s not necessarily the most optimal way to do things. Having different ways of thinking, different tools in your toolbox, is a valuable thing indeed.
The projects I have been working on are quite multidisciplinary, so I have found it really helpful, that I can easily put myself into others positions e.g. at meetings, and translate my thoughts into words that the other participants can understand. It is not unheard of people talking of the same topic or the exact same thing, but not understanding each other. The utilization of Scrum also supports this multidisciplinary way of working, as it “forces” people to communicate often about their wants and needs, which makes work easier for everyone, as the targets are clear and concise.
One could argue that NAPCON is a startup inside a multi-billion-dollar company.
When I first started, I was a bit surprised. Scrum and concepts like agile and light organization structure are not necessarily the first things that come to mind when thinking about Neste and other large and traditional companies in the process industry. However, I have really enjoyed working at NAPCON, and the ability to affect your work via Scrum is one big part of that. I have never before thought that Scrum could work anywhere else than in twenty-person software startups, but my experiences during the summer have proved otherwise. One could argue that NAPCON is a startup inside a multi-billion-dollar company, but I see no reason why these practices from software business could not work in traditional chemical engineering like process and plant design.