About me
I spend a lot of time deciding what not to do. Most technical problems are solvable. Fewer of them are worth the cost of solving. My job is mostly knowing the difference.
I read more code than I write. That is not a complaint. Reading code is where you find out what people actually believed when they wrote it, not what they said they believed.
What I work on
I think about the shape of systems: how things connect, what happens when one piece fails, where the dangerous assumptions live. Security work attracts me because it forces you to think adversarially. You cannot just build for the happy path when someone is actively looking for your assumptions.
I have worked on headers, CSP policies, CORS, HSTS, the unglamorous layer of protection that most people ignore until something breaks. I find that layer more interesting than most people expect.
How I think
I distrust solutions that look elegant on a whiteboard. Real systems have history. The elegant thing and the right thing are often different shapes.
When something goes wrong, I want to understand the failure mode, not just fix the symptom. I keep notes on decisions I made that turned out to be wrong. They are the most useful thing I have.
I changed my mind about abstraction. I used to think more abstraction meant better code. I think the opposite now. The most expensive thing in a codebase is the indirection that makes it hard to trace where a value comes from.
Things I am into
The history of how the internet was secured, or rather how it was not. The gap between what protocols assumed and what the world actually did is a constant source of interesting failures.
I also read about organizational failure: how teams make bad technical decisions not because they are incompetent but because the incentives were misaligned. The technical postmortems are rarely the full story.
A small thing about me
I have a habit of reading RFC documents the way some people read novels. Not always for practical reasons. Sometimes just to understand what a group of people thought was worth specifying carefully in 1997.