I'm a software engineer, and I'm a strong believer that the things you do outside of work shape how you work. The interests, the obsessions, the uncomfortable situations you put yourself in. They bring a kind of taste and instinct to your craft that you can't get any other way. This is a bit of that story.

How I got here

I did a CS degree knowing I wanted to build things, not study them. During university I also part-timed at a design agency. I wasn't there long, but it gave me something I didn't expect: taste. Being around people who cared deeply about craft, who'd argue for thirty minutes about spacing and mean it, trained my eye in ways that still show up in how I think about interfaces and systems today.

Interlay was my first real startup. Small team, no playbook, a lot of surface area. You either picked things up or they didn't get picked up. I built their design system and component library, set up wallet and transaction UIs from scratch, and learned what it means to own a problem end to end.

Womp is where I learned to deliver responsibly. The product had real users and decisions had real consequences. I started talking to users directly, watching how they actually moved through the product, and making decisions based on what I observed rather than what I assumed. Speed still mattered. It always does at a startup. But I started pairing it with intentionality.

Snaptrude is where scale became real. More users, more engineers, more moving parts, and more ways for things to break quietly. That's where I got serious about contingencies: monitoring, alerting, rollback strategies. The goal stopped being "build it and see" and became "build it, instrument it, and know exactly when it's struggling."

Outside of work

I spend a lot of time thinking about engineering, just not the software kind. I'm obsessive about planes and cars. Not what they do, but how they actually work. How a turbocharger spools, how a fly-by-wire system handles pilot input across multiple redundant channels, how a suspension geometry trades compliance for cornering stiffness. That kind of thinking carries directly into how I build software: understanding how a system of systems holds together under stress, where the single points of failure hide, and what happens when one thing goes wrong. Physical machines make the abstractions concrete.

I make a point of doing things that scare me. The logic is simple: the more you put yourself in uncomfortable situations, the more resilience you build, until at some point the discomfort stops registering the same way it used to. I'm a swimmer, surfer, and advanced diver. Being 30 metres underwater or getting held down by a heavy set doesn't scare me anymore. It used to.

I carry that into work. Breaking things doesn't scare me. Shipping without a plan does. By the time I'm ready to push, I've already walked through the failure modes. What's the rollback? What does a partial failure look like? What's the blast radius? The contingency is already loaded. And if something does go wrong, I've learned to stay calm and read the situation before reacting.