On building software

I think clearly about problems before reaching for solutions. Most of my best work has come from asking better questions — about what users actually need, what the system already provides, and where the real complexity lives.

I care about the details that compound over time. Consistent naming, clear data flow, honest component boundaries. These aren't exciting on day one, but they're the reason a codebase still feels workable two years later.

I work best in small teams where trust is high and context is shared. I prefer direct conversations over process, and I'd rather ship something small and correct than something large and approximate.

Most days, I'm just trying to leave things a little better than I found them.