Engineering
Engineering
Writing on how calculations are made, checked, and reviewed. Methodology, not product — each piece is something you can apply with a spreadsheet and a pencil.
-
Merged is not deployed, and deployed is not served
A change merged, a change deployed, and a change served are three separate observations, not one. A green pipeline proves the pipeline ran; a resolving hostname proves DNS answered; an HTTP 200 proves a server responded — and none of them proves your content is in front of a user. The only verification is fetching the served page as a user would: following a bounded number of redirects so a loop fails loudly instead of hiding, asserting a marker string from the actual body, and keeping a negative control so you know the check can fail. A worked shape where every dashboard stays green while every path loops, and the one fetch that would have caught it in thirty seconds.
-
The cheapest decisive experiment: how we pick the next test
Facing two explanations that both fit a defect, the instinct is to run the test that would confirm the one you favour. The better discipline ranks candidate experiments by cost-to-decisiveness — a decisive experiment splits the hypothesis space no matter which way it lands, and confidence in a hypothesis never enters the ranking. The confirmation run that only ever agrees with you, the question to ask before touching anything, and a worked shape: a request that fails identically for two different reasons, and the one log line that splits them.
-
Two accounts, or it didn’t happen: proving isolation with two-subject tests
A single-account test shows a subject sees its own data — never that another cannot see it. Isolation is a claim about the boundary between two subjects, so proving it takes two: open two independent subjects, act as one, and assert it can reach none of the other’s data by list or by direct reference. Why “the query filters by tenant” is a claim about code rather than a proof about behaviour, and where the pattern applies — multi-tenant data, session scoping, per-customer stores.
-
A gate that has never failed proves nothing: the negative-control principle
A check that has always passed may be catching a rare problem — or may be structurally unable to fail, staying green no matter what walks through it. The two produce identical records. The negative-control principle: a passing gate carries no information until it has been seen to fail on a deliberately broken input, the console-listener blind spot where a check is deaf to the very thing it asserts, and why fixtures should assert sentinels rather than real prohibited values.
-
Fail-closed by default: designing a sign-in door that refuses politely
A sign-in door has two ways to be wrong: it can let in someone it should have stopped, or stop someone it should have let in. Those mistakes are not symmetric, so the door should fall toward the survivable one whenever it is unsure. The engineering case for deny-if-absent config, empty allowlists that refuse everyone, separating “signed in” from “entitled,” and error pages that stay quiet while the logs stay loud.
-
Opaque session handles versus JWTs for a product family
When a family of products shares one sign-in, the choice between a self-contained token and a server-side opaque handle decides whether a logout is real. A walk through the trade-off — revocation as the property that settles it, RFC 7662 introspection as the resolution, parent-domain cookies and why the
__Host-prefix will not share, and what a product should and should not learn about a customer. -
Choosing storage on the edge: strong vs eventual consistency
Edge platforms offer two shapes of storage, and the difference is not speed or size — it is the guarantee about what a read returns after a write. Sorting state by what a stale read would cost: identity wants strong consistency, ephemeral sessions tolerate eventual, and the single-use transaction state of an authentication handshake is the trap case that may never live in an eventually consistent store.
-
What a calculation has to show before it can be checked
A reviewer either checks your work or trusts it, and those are different transactions. The difference is a property of the document, not the reviewer’s diligence. Here is the test for which one you have written, with worked examples of a calculation that can only be trusted and the same calculation rewritten so it can be checked.