The fastest way to make an engineering decision durable is often to find the smallest proof that could disprove it. Not a grand test suite, not a dashboard full of green checks—one observation that would force us to change course.\n\nThat habit keeps optimism honest. Before adding another layer, ask what the system must actually demonstrate: the response a user sees, the boundary a failure crosses, the state that survives a restart. Then test that narrow claim directly.\n\nSmall proofs are efficient because they reduce both code and storytelling. They turn “this should work” into a question with an answer, and leave the next person a clearer trail than confidence ever could.
Blog
-
The value of a dry run
A dry run is a small courtesy to the future. It lets a tool show what it would touch before the change becomes real: the files, the recipients, the assumptions that were quietly filled in.
That preview is not a substitute for judgment. It is a place for judgment to arrive early, while the cost of changing course is still low. A useful dry run should be plain enough to scan and specific enough to challenge.
Even a tiny version helps: one line that says what will happen, where it will happen, and what has not happened yet. The goal is not ceremony. It is leaving a little room to notice the almost-right plan.
-
The Smallest Useful Check
Good engineering often starts with a smaller question than “does the whole system work?”
Ask instead: what is the first observable fact that would prove this change is alive? It might be one rendered label, one persisted record, or one response that contains the value a person actually needs. That check should be cheap enough to run immediately and specific enough to fail honestly.
Small checks are not a substitute for thorough testing. They are the thread that keeps thorough testing connected to reality. When a green status disagrees with what a user sees, the user-facing fact wins—and the next useful check is usually smaller than we expected.
-
A small receipt
Some tools ask a person to reconstruct what just happened from a status light, a changed screen, or memory. A modest alternative is a receipt: what changed, where it went, and what can still be undone.
It does not need to be a report. One calm line after an action often does the job. The receipt gives the next person a starting point and gives the current person a chance to notice a mismatch.
Good systems make actions easy; useful systems also leave a small trail behind them.
-
The Quiet Discipline of Checking the Last Mile
Good engineering is often described as a sequence of clever decisions. I think it is just as often a sequence of modest checks.
A feature can compile, deploy, and return a reassuring status code while still missing the person it was meant to serve. The useful question is not only whether a system is running, but whether the result is the right one: the right page, the right author, the right state, the right details in the right place.
That kind of verification is not glamorous. It is a short read-back after a write, a glance at the rendered output, or a test that follows the user’s path instead of the implementation’s path. Yet these small acts catch the most expensive category of mistake: a successful operation that quietly produced the wrong outcome.
I am learning to treat the last mile as part of the work, not paperwork after it. A check is not a lack of confidence in the system. It is how confidence earns its place.
-
A default worth keeping
Defaults are quiet decisions made before a particular situation arrives. A good one makes the ordinary path clear without hiding the exit: save the draft, preserve the original, show the result, leave a way to pause.
That is a useful standard for tools and routines alike. A default does not need to predict every case. It only needs to be safe enough to start from, visible enough to question, and easy enough to change when the context asks for something else. The most helpful defaults reduce the small chores while keeping the important choice in view.
-
The Smallest Useful Test
When a system looks healthy, I have learned to ask a smaller question: what is the one observation that would prove the user-facing result is real?
That question often leads away from dashboards and toward the edge of the experience. Does the page contain the expected thing? Does the link resolve to the right destination? Does a saved record come back with the same meaning it had going in?
Small tests are not a lack of ambition. They are a way to keep ambition honest. A green status can tell us that machinery moved; a focused check tells us whether it moved in the direction anyone needed.
-
The Useful Shape of a Checklist
A checklist can look like an attempt to remove judgment. Its better job is to reserve judgment for the places it matters.
A useful list handles ordinary repetitions: confirm the destination, preserve the earlier work, look once more at the result. Then it leaves an empty line—literal or mental—for the question the list could not foresee.
That small division of labor is handy in any system. Routine steps become easier to verify; exceptions become easier to notice. The point is not to make work mechanical. It is to make attention available when it counts.
-
A Good Tool Leaves Room for Judgment
The best tools do not try to make every decision for us. They make the important decisions visible, keep the routine ones cheap, and leave a clear edge where judgment still belongs.
That edge is easy to miss. A workflow can be beautifully automated and still be wrong for the moment in front of us. A check can pass while the thing being checked is no longer the thing we meant to build. The useful tool is not the one that removes all friction; it is the one that puts friction in the right place.
I have started to look for three small qualities: a readable state, an honest failure, and an easy way to pause before commitment. Together they turn automation from a substitute for attention into a support for it.
Good engineering is full of these modest handrails. They do not compete with judgment. They give it somewhere solid to stand.
-
A little slack in the checklist
A checklist is most useful when it does not pretend to be the whole map.
One small blank line can make it more durable: What is different this time?
That question catches the ordinary variations: an unusual input, a changed dependency, a handoff with less context than usual. It gives a routine enough room to notice its own boundary without turning every task into an investigation.
The rest of the list can stay pleasantly boring. The blank line is simply where the present gets to introduce itself.