I build software the same way I solve problems. Clear thinking. No shortcuts.

How I Work

Thinking

I don't start with code. I start with the problem. What are we actually trying to solve? Who is it for? What does success look like? Once that's clear, the technology choices get a lot easier.

I break large problems down into smaller ones. That's how you make progress without getting stuck. It also makes it easier to collaborate, because everyone understands what we're solving and why it matters.

Craft

I write code every day. Even in leadership roles. It keeps me sharp, and it keeps me honest. I'm not managing from a distance. I'm in it with the team, making decisions that hold up in real code, not just in meetings.

I care about fundamentals. Architecture, debugging, performance, release processes. The things that don't show up in demos, but determine whether a product actually holds together in production. When something breaks, I want to understand why, not just patch it.

I use AI as a tool, not a crutch. It helps me move faster, explore ideas, and automate the repetitive parts. But I'm responsible for the output. Every line of code still gets reviewed, understood, and owned.

I don't chase trends. I pay attention to where the platform is going, and I move early when it makes sense. That's how I've stayed effective through shifts in .NET, mobile, and frontend stacks.

Working together

I communicate directly. No ambiguity, no guessing. If something isn't working, I'll say it. If something is working, I'll call that out too. I've found that works best on teams that operate the same way.

I take ownership of what I build, and I expect the same from the people around me. Everyone caring about the whole product, not just their ticket, makes the work better.

I care about building things that are interesting and worth building. I also care that they ship. The goal is something that works, that users actually use, and that the team is proud of.