About me
I spend most of my day reading code trying to find the moment where the author stopped thinking about what could go wrong. That moment is almost always there. The interesting part is figuring out whether it matters.
I did not start out wanting to break things. I started out wanting to understand them, and breaking them turned out to be the fastest way.
What I work on
My job is to find the cases that do not show up in the happy path. Not just “what if the user enters a negative number,” but the deeper ones: what happens when two valid operations interact in an unexpected order, what the code assumes about the outside world that the outside world does not guarantee, what a developer meant versus what they wrote.
I also review test suites. A test that cannot fail is not a test. A test that always passes is evidence of something, but not of what you think.
How I think
I make a mental list of every assumption in a piece of code before I start poking at it. Most bugs live inside assumptions. The assumption that input is always sanitized. The assumption that the API always returns what the docs say. The assumption that two things will never happen at the same time.
When I find a bug, I do not just file it. I ask what else is true if this is true. Usually there is a second bug nearby.
Things I’m into
I read incident reports from large software failures. Not for the Schadenfreude but because they are honest in a way that most documentation is not. The people writing them have already been embarrassed, so they tell you what actually happened.
I have also developed a strange interest in how non-programmers interact with software. The places they get confused are almost never the places developers expect.
A small thing about me
I keep a graveyard document of bugs I have filed that turned out to be features. It is longer than I would like. I revisit it occasionally when I need to feel humble.