Introducing Field Notes: The Best Ideas in Software Were Never Invented There

I keep noticing something. For nearly every hard problem I run into while building software, somebody already solved it: a long time ago, in a field that has never written a line of code.

Air traffic controllers figured out what to do when the data in front of them can no longer be trusted. Tailors figured out that a fit that's only "good enough" ends up costing more than it ever saves. Restaurant kitchens figured out that calm in the middle of a dinner rush is bought hours earlier, never improvised in the moment. None of them would call what they did a methodology. They'd call it the job, done right, the way it's been done for a long time. Strip away the vocabulary, though, and the shape of the problem is the same one we keep hitting in software, usually without noticing we're not the first.

So, I bring you Field Notes: short pieces where I borrow a hard-won idea from somewhere outside software and follow it back into how custom systems actually get built.

Part of the reason is practical, maybe even a little selfish. A field that's had a hundred years, or a thousand, to refine an idea has already paid down the cost of getting it wrong. Stealing that mental model and adapting it is cheaper, and usually better, than reinventing it badly from first principles inside a sprint. The graceful-degradation practices behind modern air traffic control didn't emerge from a brainstorming session. They were built through decades of accidents, near misses, investigation, and disciplined refinement. We get to inherit those lessons without paying their original price.

The other reason is less practical and more personal. Some of the best conversations I have about software are with the people who run the businesses software gets built for: the ones who understand their own industry at a depth no outside developer ever will, and who are usually sitting on an insight about resilience, or trust, or risk, that would make the system better if anyone thought to ask. This series is partly an excuse to keep having those conversations, and to write down what comes out of them.

What to expect

Each piece pairs one idea from another field with one real lesson about building software, anchored where I can in an actual project (with names and identifying details changed, but the substance left intact). One idea per piece, not a survey: a hook, the other field treated with enough care that someone who knows it will recognize it, the place where the parallel actually holds, and what it means for the way we build.

Some pieces will come from crafts and professions well beyond software: tailoring, farming, the orchestra pit. Others will come straight from the industries we work in: defense, banking, telecom, healthcare, music, manufacturing, air traffic control itself. A few will come from nowhere professional at all, just something true about how people handle difficulty.

Written for two audiences at once, deliberately: the people making decisions about the software their business depends on, and the people building it. Neither gets the lesser version.

No fixed schedule here. Just the parallels I find genuinely useful, written down as I find them.

The first real note is next: what air traffic controllers know about a dashboard that keeps looking confident even after the data behind it has gone stale, what it cost aviation to learn that lesson, and how the lesson changed a system where the stakes were real.

If your field has a hard-won lesson you think software keeps relearning the hard way, tell me. That might be the next one.