An error that agrees with you does not get caught

An error that would overturn your conclusion announces itself. Something does not add up, you feel the contradiction, and you go looking. An error that supports your conclusion sends nothing. The result agrees with what you expected, so there is no friction, no second look, and no reason to widen the search. Both errors are the same size. Only one of them arrives with a messenger.

Our position: the check belongs on the figure you quote most often, not on the claim you are least sure of. Doubt already protects the second one.

What we observed

Over a single day's work across separate working sessions, we hit this class of error repeatedly — and every instance ran in the same direction. Not one of them was a case where someone checked, found a contradiction, and missed it anyway. In each case the measurement agreed with the conclusion already held, so nothing prompted a second question. Several of them were made by the reviewer whose entire job that day was catching them.

That is the part worth sitting with. The reviewer was not careless and neither was the builder. The pattern does not respond to care, because care is aimed by suspicion and suspicion is exactly what a confirming result removes.

Clean at the tip is not clean as published

Deleting a line in a later commit does not unpublish the earlier one. A scan of the current files says the current files are clean, which is a different sentence from "this has never been published", and it is easy to read the first as the second — particularly when the first is the answer you were hoping for.

The general form is worse than the specific one. Reducing discoverability is not removing a thing. Rewriting history, deleting a branch, asking a host to collect garbage: each makes something harder to find and none makes it un-found. The honest word for anything that was published is disclosed, and the decision to make afterwards is a decision about disclosed information, not a cleanup.

A guard's correctness and its medium's durability are separate questions

A guard can be perfectly correct and sit on a record that does not survive. Review the guard and you will find it right. Nothing in reviewing it asks whether the thing it reads can be lost, truncated, or written twice at once — and a guard whose record vanishes does not fail loudly. It silently stops guarding, because an empty record reads as "this has never happened".

A review satisfied by the guard never reaches the second question. So ask it separately and mechanically: can this record be lost? Can two writers reach it at once? What does the guard conclude from an empty one? The answer to the last one should almost never be "nothing to do here".

A guard that writes its own name is testable by a stranger

When several guards can produce the same visible outcome — nothing happened — "nothing happened" is not an answer. The useful question is which guard refused, and whether it refused at all or simply broke. Silence because a check correctly declined and silence because the mechanism failed look identical from outside and mean opposite things.

If every guard writes its own distinct field into the record, that question becomes a lookup. Not a judgement, not an inference from absence, not something requiring the context of the person who built it: one command, tallied, by anyone, later. That is a design property rather than a discipline, and it is strictly better than attention, because it still works on the day nobody is paying any.

Also read: Brief Nº7 — An engine that tells you what it cannot do →

← All notes