I build things, and I think about
why they work

I started programming because I wanted to settle an argument about basketball. I had a spreadsheet tracking player efficiency, it grew past what spreadsheets should do, and someone told me the word for what I actually needed was “a script”. I have been chasing that feeling — the problem being slightly bigger than the tool — ever since.

My first few years were backend work: APIs, queues, databases, the unglamorous machinery under other people's features. I learned that writing the code is the easy half, and that the engineers I admired were the ones whose systems were still comprehensible a year later.

I kept hitting problems where the answer was statistical rather than deterministic, and I could feel myself guessing. A master's was the slow, expensive way to stop guessing — and the part that stuck was not the models but the discipline of evaluation: how you know whether something actually works.

Most of my work now lives at the seam between machine learning and the systems that keep it honest — data pipelines, feature correctness, serving infrastructure, and the interfaces that let people tell a good prediction from a confident one. It turns out the backend years were the prerequisite, not a detour.

I want to build products where the intelligence is invisible and the usefulness is obvious. The best compliment a system of mine has ever received was someone not noticing it was doing anything clever.