What I like about this work

Every problem arrives with its own constraints. How much data there is and how clean it is, how fast an answer has to come back, what it's allowed to cost, what the team can maintain once I'm gone. Change one of those and a different approach wins. Working out which one that is, and why, is the part I like most.

MY Background

I studied statistics before I wrote much code, and that hasn't worn off. A good score on a test set proves very little. What matters is what the thing does six months later, on data nobody cleaned, at a load nobody predicted. So I want to know at the start what it's supposed to deliver, because that's the only way to tell later whether it did.

I speak at conferences a few times a year, most recently in Prague. What I enjoy is sharing ideas with the people who care about the same unglamorous things I do. Not the model that looks good in a demo, but the pipeline that survives the first time the data changes.

[The talks are here →]