Preflight checks for tasks, not just planes

A field note from Chad Mathews, drafted with Claude. Chad directs the work and lived these decisions; Claude does the writing; Chad edits every line and approves it before it publishes. Where an idea or a reference came from Claude, the note says so.

A pilot who has flown the same plane a thousand times still runs the preflight checklist. Not because they might have forgotten how to fly, but because the checklist catches the one item that memory skips on the day it matters. I started running the same thing before coding tasks, and it fixed a category of waste I had been eating without noticing.

The two ways a task goes wrong before it starts

Most of my thrown-away work does not come from writing bad code. It comes from starting the wrong task, or restarting a solved one.

The first is beginning work before I have loaded the context that defines the problem. I would jump into a change, build something reasonable, and only later find out I had solved a problem next to the real one, because the answer was sitting in a doc I did not open. The second is quieter and more annoying: re-hitting a mistake I had already made and already written down. The lesson existed, the fix existed, and I walked into the same hole anyway because nothing forced me to check for it first.

Both have the same root. The moment of starting a task is exactly when I have the least context loaded and the most momentum to just go. A preflight puts a small fixed gate at that moment.

What the checklist actually does

It is short and it is boring, which is the point. Before any change, it makes me do four things.

Read the small set of files that hold the current state and the standing rules, every time, in the same order. Check what has actually changed in the working files, so I do not clobber something I forgot I left in progress. Classify the task honestly: is this cosmetic, does it change how the thing behaves, or does it touch saved state? That one answer decides how much I need to verify at the end. And load the specific lesson file for this kind of work, so if I have already solved this shape of problem, I reuse the solution instead of writing a worse new one.

None of that is clever. It is a list that guarantees the context is loaded and the known traps are named before the momentum takes over. The checklist is different per kind of task, because a checklist that covers everything covers nothing. Art work, movement changes, and saved-state changes each get their own short list of the traps specific to them.

The old name for this

I built this from getting tired of starting the wrong task. I did not know it had a name.

It came up while Claude and I were writing this note: the checklist idea is the core argument of Atul Gawande’s The Checklist Manifesto, drawn from aviation and surgery. In complex work, experts fail not from lack of skill but from skipping a known step under load, and a short checklist for the highest-stakes moments catches those misses better than more expertise does. I have not read the book. But that one-line version is my checklist wearing a name, and arriving at it from the other direction is a decent sign the instinct was sound.

Where it does not help, and the failure to avoid

A preflight cannot tell you your plan is right. It can only confirm you loaded the things you already know matter. If the whole approach is wrong in a way I have never seen before, the checklist waves me straight through, because there is no item for a mistake I have not learned yet. It is a floor against known failure, not a ceiling on judgment.

And it is separate from checking the work afterward. Preflight is the before: load the context, name the traps. Verifying the behavior once the change is done is the after, and it answers a different question. Confusing the two, or trying to fold them into one list, is how both get skipped.

The real risk with any checklist is length. A preflight that grows until it is a chore is a preflight that gets skipped, and a skipped checklist is worse than none, because it lets you believe you were careful. So the discipline is to keep it short enough that running it is never the expensive part of the task. The day it feels like overhead is the day it stops getting used.