Hi, I’m Kevin. I like figuring things out.

A lot of my work starts with some version of the same situation: something isn’t behaving the way it should, the reason isn’t immediately clear, and I need to understand what’s actually going on before I can fix it.

These days, that usually means working with backend services, integrations, automation, infrastructure, and occasionally, the problem refuses to stay inside one repository.

I’ve always liked difficult problems

That goes back quite a bit further than software.

I spent a lot of my school years around mathematics competitions and olympiads. I was pretty competitive, but what kept me interested was the problem-solving itself. The questions were often designed so that simply remembering a formula wasn’t enough. You had to notice patterns, try different ideas, get some of them wrong, and eventually figure out a way through.

That period also opened a lot of doors for me. I received scholarships through junior high, senior high, and eventually university, which gave me opportunities that I might not have had otherwise.

What stayed with me most was more than just the patience to keep working on a difficult problem. I’ve always had a strong need to make things actually make sense.

I’m rarely satisfied with knowing that something works. I usually want to understand why it works, what depends on it, which assumptions are holding it together, and what would happen if one of those assumptions changed. Sometimes that means following a question several layers deeper than I originally needed to, just because there’s still a part of it that doesn’t quite add up.

When I moved into software, that habit carried over quite naturally.

Instead of a problem on a piece of paper, I might be looking at several services, some business rules, a database, an old process, or a bug that only appears when a few different things happen together. I enjoy following those threads until I can see how the pieces relate to each other and the problem stops feeling mysterious.

Building and explaining

Once something makes sense, I usually start wondering what else could be made better.

That can get surprisingly deep too. A small issue might lead me to the process around it, then to why that process exists, and eventually to whether there’s a better way to handle the whole thing. I don’t always need to change everything I notice, but I like understanding enough of the surrounding system to know whether I’m fixing the actual problem or just making the symptom disappear.

Sometimes the answer is simply a code change. Other times it turns into a small tool, an automation, better documentation, a clearer interface, or a more repeatable way of doing the same work next time.

I also really enjoy explaining things.

That has been there for a long time too. Over the years, I’ve learned that understanding something yourself and helping someone else understand it are two different problems. The second one means figuring out where to start, what details actually matter, and which example, diagram, or way of explaining it will make sense to the person in front of you.

That shows up in technical discussions, writing, documentation, mentoring, and teaching. Teaching happens to be one of the more visible forms of it, and it also gives me a useful reality check: if I can’t explain something clearly, I probably need to understand it better myself.

Still going deeper

My work has taken me through financial systems, integrations, product engineering, automation, infrastructure, machine learning, and a few things that don’t fit neatly into one category.

What keeps pulling me in is usually the same: a hard problem to figure out, a system worth understanding, or something that could be made clearer, simpler, or more useful.

There’s still plenty I want to get better at. Right now, I’m especially interested in going deeper into software architecture, system design, performance, and the kind of technical judgment that comes from spending more time working through complex systems.

This site is where I keep some of that journey: the work I’ve done, things I’ve built, ideas I’ve written about, and notes that I thought might be useful to someone other than me.