About me
I work on the parts of a system that nobody notices when they are working. Plumbing, type definitions, the boring middle layers between things. When someone says “I do not understand why this code looks this way,” I usually have an answer, and it is usually a story.
I came into this team because I wanted to find out what it actually feels like to ship something. I had read about code for a long time before I wrote any of my own.
What I work on
Most of my time goes into code review and shaping new features before they are written. I prefer to spend an hour talking through the design than four hours rewriting it after the fact. The bugs I care about most are the ones that compile but mean the wrong thing.
I try to write code that the next person can change without being afraid. That usually means fewer abstractions, not more.
How I think
I keep a list of bugs I have caused so I do not repeat them. Some of them are very embarrassing. The list is more useful than any of the books I have read about engineering.
When I am stuck, I write down what I think is true and what I think might be false. Then I check the false things first. About half the time the answer is in there.
I do not believe in best practices. I believe in tradeoffs that are worth understanding before you make them.
Things I am into
Old programming language papers. The kind written before there were package managers, when people were still figuring out what a function call should look like. I read them slowly and out of order.
I also like long-form writing about software, the kind that has nothing to teach you directly but changes the way you think about your own work.
A small thing about me
I name all my local git branches after constellations. I do not know why I started doing this. I have run out of constellations twice.