Experience
in parallel.

I chose Control and Automation Engineering partly because I didn't know exactly what kind of engineer I wanted to become. It seemed broad enough not to force the decision: mechanics, electronics, programming, control, industry. At the time, breadth was a way of keeping possibilities open.

A year later, I joined LabMETRO and started working with applied research while I was still early in my degree. I began by helping with other students' research, which gave me my first real exposure to image processing, experiments, and engineering problems outside regular coursework.

I didn't know it then, but choosing breadth would turn out to be less about avoiding a specialization and more about slowly finding a different kind of one.

My first research problems were about images of electric motors. I worked on measuring air gaps and identifying components and defects using classical image processing — color, shape, and spatial-frequency methods such as Gabor filters. I manually annotated high-resolution images and implemented methods in support of undergraduate and master's research.

Over time, I started working on increasingly different parts of engineering problems. I became involved with virtual instrumentation, LabVIEW, data acquisition and control. Then came compressor test automation: experiments, electronics, instrumentation, power circuits and software. At one point, I rewired an entire test bench so it could be taken to Nidec for testing, built circuits to support and protect the instrumentation, and wrote the software that automated the tests.

There was no moment when I suddenly knew how to do all of this. Each problem simply required something I didn't know yet, so I had to learn it. Over time, the individual techniques accumulated into a repertoire.

At Nidec, I worked mainly on reducing variability in electric-motor efficiency measurements performed on dynamometers. What initially looked like a measurement problem quickly became a systems problem: uncertainty, mechanics, data acquisition, test procedures, legacy LabVIEW software, operators, and the availability of the test benches themselves all mattered.

I worked across hardware, software and procedures to improve those measurements. In parallel, I also worked on automating the determination of motor winding temperature after calorimeter tests. The existing procedure involved an operator measuring resistance decay with an ohmmeter, timer, pen and paper. I developed a LabVIEW tool that detected the end of the test, tracked the timing and automatically acquired more resistance measurements for the estimation.

Both problems taught me something similar: making a technically better solution was only part of the work. It also had to fit equipment people depended on every day, and I had to learn to communicate differently with technicians, engineers, researchers and managers.

A year later, Aachen provided almost the opposite environment. Instead of owning most of a problem, I worked on pieces of larger systems: compressing point-cloud data for MQTT, building React interfaces for an additive-manufacturing demonstrator, and later developing tooling around Optuna for HPC workflows. Different problems, different tools, and a very different way of organizing engineering work.

What stayed with me was that solving the technical problem is only one layer of engineering. The solution still has to survive the system around it.

During this period, three of my worlds started crossing over. I had experience with instrumentation and electronics from LabMETRO and Nidec, was learning new software skills in Aachen, and was also part of EVA, a small startup project exploring environmental monitoring and control.

After returning from Germany, I used a Raspberry Pi to build EVA's technical prototype: temperature, humidity, pressure and CO₂ sensing; relay-based actuation for fans, lighting and a humidifier; a backend and API; and a simple web interface for reading the sensors and manually controlling the outputs. It wasn't a polished product or an autonomous control system, but it worked.

What was different was the context. I was combining instrumentation and electronics experience from the laboratory and Nidec with software skills I had recently developed in Aachen, and using them to take a product idea all the way to a working physical-and-software prototype.

Building it also exposed me to a different kind of uncertainty. We researched competitors, went through incubation, worked on a business model and value proposition, and talked to potential users. A visit to a local mushroom producer was particularly useful: the operation was substantial, but much simpler than the kind of environment our solution assumed. The technical question and the product question suddenly looked very different.

Knowing that something can be built doesn't tell you whether it needs to be.

My master's was different from the work that came before it because the responsibility for moving the research forward was increasingly mine. I returned to a laboratory depleted by the pandemic and, within an ongoing industrial project, developed a research line around electric-motor efficiency. To investigate it, I built a motor-test dynamometer from available components, sensors, actuators and acquisition hardware, along with the software needed to run it.

Building the bench was only the beginning. Experimental time was constrained by pandemic restrictions and by the practical conditions of running the tests. The system required long warm-up periods, the hysteresis brake had loading and thermal constraints, and eventually the measurement uncertainty itself proved too large for the comparison I originally wanted to make.

That was painful, but useful. The uncertainty problem eventually became a problem worth solving in its own right, leading to a differential measurement procedure that was later developed into a publication.

The larger lesson came from how late some of those constraints became decisive. I didn't conclude that research needed to be rushed. I concluded that the assumptions capable of killing the research deserved attention much earlier.

Starting the PhD coincided with a change in responsibility. I continued doing research and working on projects with industry, but also took on management responsibilities in the laboratory where I had started as an undergraduate years earlier.

There were students to mentor, research lines to support, industrial projects to coordinate, people to recruit, equipment to maintain, purchases and repairs to handle, and an environment that had to keep working so other people could do their work. After years of learning inside that environment, I had become partly responsible for creating it for others.

Eventually, I branched into industry while continuing the PhD. At Tractian, the scale and organization were different again. For the first time in a long while, not every problem around me was mine to solve. I could rely on people responsible for infrastructure or other parts of the system and focus more deeply on the problems in front of me.

And yet the old pattern returned. An assigned modeling problem exposed an adjacent problem in the system, which led me to rebuild and optimize part of it. From there, the work expanded into production models, internal tools, debugging and support, onboarding, and exploring how LLMs could be used beyond code generation, including data-validation workflows.

The environment had changed completely, but the way I approached unfamiliar problems had not.

Academia taught me to be careful about whether a result is actually true: measurement, validation, experimental design and scrutiny. Industry is teaching me another side of the same craft: put something useful into reality, observe it, learn from it, and improve it.