From Student to Lab Assistant

In my second year of the Game Development program at Malmö University, I was asked by one of my lecturers to work as a lab assistant for Data Structures and Algorithms. I was one of several students selected based on our performance in the course.

The role was roughly ten hours a week, but it involved much more than answering programming questions. I helped first-year students understand assignments, explained programming concepts, helped them debug their code, graded their work, and ran through problems with them when they were stuck. Sometimes the problem wasn't technical at all — these were students who had only been programming for a few weeks, so part of the job was simply helping someone regain confidence when they'd reached the point of thinking, "I have no idea what I'm supposed to do."

I found that I naturally approached teaching by breaking problems down into very small pieces. Rather than giving someone the solution, I would work backwards from what they already understood, using examples, drawings, metaphors, and simple questions to guide them toward the answer. If someone didn't understand the fundamentals, there was little value in jumping ahead to the complicated part.

That approach has stayed with me.

Today, when I work with less experienced developers, I see my role as more than simply providing answers based on experience. A senior engineer or technical lead should make the people around them better — understanding where someone is stuck, identifying the missing piece in their understanding, and helping them build the mental model that lets them solve the problem themselves.

The experience also gave me an early appreciation for the relationship between theory and implementation. The Game Development program was heavily practical — we learned programming by building games. That environment forced us to think about performance, optimization, clear patterns, and maintainable code, because inefficiencies were immediately visible. A game that drops frames makes a technical problem tangible in a way a slightly slower business application often doesn't.

Looking back, the most important thing I gained from the experience wasn't a particular data structure or algorithm. It was the opportunity to practice something that has remained a significant part of how I work: understand the fundamentals, meet people where they are, and help them find their way to the solution rather than simply handing them the answer.