
Constraints instead of reviewers
A reviewer catches a mistake once. A constraint catches it forever, including from people who never met you. Which layer should enforce an invariant, and where the approach stops working.
Design Engineer
Post-mortems and technical writeups from building production systems, mostly about what the artifacts recorded rather than what anyone remembers.

A reviewer catches a mistake once. A constraint catches it forever, including from people who never met you. Which layer should enforce an invariant, and where the approach stops working.

Between the people doing the work and the people funding it sits someone who has to produce confidence without being able to verify anything. That is where uncertainty gets laundered into fact.

A manager who cannot evaluate the work has to evaluate the appearance of it. Micromanagement, reorganisations, and the pattern where the strongest engineer gets the hardest treatment all follow from that one substitution.

An animation is a recording of a decision. A simulation is the decision, still running. Three browser experiments that took the second route, and what each one cost.

The September 2026 deadline is not a PDF problem. The seams that survive a vendor change, and the gates that stop a bad deploy transmitting.

Twenty-one months of my own messages, two detectors, and a hand-labelled sample to measure them. The tool found what I expected. Then measuring the tool took part of it back.

Eighteen months, eleven applications, one committer, and what the git history recorded.

What "already largely done" turned out to mean, measured in the files I was handed.

Proving to a French auditor that your records were never altered, and what that does to your release process.