Notes from building things that hold up
Notes on revenue-critical code, plugin modernization, founder engineering, and products that last.
Almost everything here comes out of the same kind of work: the parts of a product where being wrong is expensive and the failure is quiet. Billing that has to survive a retry, a plugin you cannot take offline because thousands of sites are running it, a decision a founder cannot fully delegate. I write these to think properly about a problem rather than to publish on a schedule, so each one is opinionated, tries to name the trade-off honestly, and says where I would do the opposite. Start with a topic below if you want the argument as a body of work rather than a list of posts.
Shift left assumes there is someone on your left
Rachel Laycock says shift code review left. Brian Houck says fix it first. Both assume a team. Here is review by exception when you are the only reviewer.
Cognitive debt is cheap until the code takes money
Cognitive debt costs you a slow refactor in most code and a wrong payment in billing code. How to scale AI review to what breaks when you are wrong.
Rubber duck debugging in PHP: narrate the sequence, not the lines
Narrate the execution, not the file: what fires, in what order, in whose process. The four questions that find hook, observer and queue bugs in WordPress and Laravel.
Building something where this kind of work matters?
I'm in GMT+6 and work async-first, so your timezone is never a reason not to reach out.
Get in touch