About Me

I'm a senior software engineer based in Oslo, Norway. I build and understand complex systems, from distributed infrastructure and financial platforms to Linux environments and the interfaces people use to operate them.

Previously, I was a senior engineer at AWS working on MediaLive, where I built control planes and interfaces for large-scale media infrastructure. Today, I work at Vipps MobilePay on financial infrastructure, including accounting, reconciliation, safeguarding, payouts, and reporting. I also helped establish Linux as an officially supported developer platform.

My engineering interests sit at the intersection of systems, infrastructure, and human-computer interaction. I care about how systems behave internally, but equally about how people understand and interact with them. UX and the neuroscience of HCI have been long-standing interests.

I'm interested in almost every programming language. Right now I particularly enjoy SQL, Python, and Go. Rust is a great choice when working around the Linux kernel, but C is my love language.

I studied computer science in college and continue to study independently, including through MIT OpenCourseWare. I learn best by combining fundamentals with experimentation: taking systems apart, building prototypes, testing assumptions, and refining my understanding from what happens.

I'm most at home with difficult, open-ended engineering problems: problems without an established solution, where understanding the system is part of figuring out what to build.

What I'm learning

AI, ML, and inference systems are relatively new areas of serious study for me. I'm working from first principles: mathematics, model architectures, inference, accelerators, memory and compute constraints, and the systems required to run models efficiently.

Local inference gives me a practical way to explore those ideas. One of my personal projects involves repurposing unconventional or older hardware for inference and understanding what useful compute can be extracted from it. At work, I'm exploring whether and how local inference could fit into our engineering environment, including the infrastructure and economics of running large models.

I'm also going deeper into Linux and low-level systems engineering. I've spent much of my career building distributed systems and infrastructure, but I want to understand more of what happens below them: kernels, memory, scheduling, networking, hardware, and performance.

HCI, cognitive science, and neuroscience are areas I want to study more rigorously and apply to my engineering work. I'm particularly interested in how people form mental models of complex systems and how we can build interfaces and tools that work with, rather than against, human cognition.

Outside software, I have a hands-on engineering background and interests that include machining, welding, carpentry, farming, soil health, and agricultural technology.

How I work

My natural engineering style is independent and exploratory. Give me a difficult problem, the context and constraints, and enough trust to investigate it deeply. Some of my best working environments have essentially been: own this area, figure out what needs to exist, and keep me informed.

I tend to move quickly from an idea to investigation to something concrete. To me, a prototype is often another way of asking a question. Building something gives me an artifact I can inspect, challenge, and learn from.

That style has tradeoffs. A prototype I see as an experiment can reasonably look to someone else like a direction has already been chosen. I'm working on adapting to teams and cultures that need more visibility: sharing intent earlier, making the exploratory status of work explicit, and creating opportunities for people to participate without losing the autonomy and experimentation that make this way of working effective.

I'm comfortable with technical ambiguity. Human and organizational ambiguity can be harder. I value precise communication and can over-explain when I feel misunderstood. I'm learning that sometimes clarity comes from saying less, asking a question, or accepting that two people can understand something differently.

More broadly, I'm learning to distinguish being wrong from being a problem. Engineering has made me comfortable with being wrong: build a model, test it, discover where it fails, and update it. I'm trying to bring more of that mindset into communication and collaboration.

I'm not trying to engineer away the way I naturally work. I'm trying to understand its strengths, recognize its tradeoffs, and become more adaptable about when and how I use it.