Somewhere between a simulator session and a hangar argument last month, a student asked me whether the software world has anything like a checklists-and-callouts culture. It does. The nearest thing I know to it is GitOps: you write the plan down, you brief and approve every change in company, and a tireless copilot holds the aeroplane on the numbers you filed. If you have ever flown a proper pattern or preflighted a rented 172, you already carry more of this practice in your head than the average programmer does. So here are the seven flight-deck habits you already own, mapped one by one onto the way GitOps runs a modern platform.
Seven Flight-Deck Habits That Map Straight onto GitOps
1. The checklist is the configuration
Before the engine starts, the before-start checklist tells you what the aeroplane should look like: mixture rich, fuel selector on the proper tank, flight instruments checking against the AI. Nobody relies on memory for those items, because memory drifts. GitOps works from the same instinct. Everything the system ought to be — which parts run where, at what size, under which settings — gets written out as ordinary files kept in a Git repository, and that document is treated as the single truth. If it isn’t written, it isn’t the plan.
2. The logbook never forgets
Your airframe and engine logbooks are append-only by law and by common sense. You don’t erase last month’s oil change; you add this month’s. A GitOps repository behaves the same way. Every edit is dated, attributed, and kept forever, and you can flip back through history to see precisely what the system looked like on any past day. When something starts misbehaving, you compare today’s entry against the one before it instead of reconstructing events from recollection — the difference between an investigation and a séance.
3. The autopilot holds the heading, minute after minute
Set a heading bug and the autopilot doesn’t correct once and go to sleep. It reads the situation continuously and nudges, forever. That loop is the heart of GitOps, and practitioners call it reconciliation: a software agent repeatedly compares the live system against the written state and brings the two back together whenever they part ways. Someone hand-edits a setting at midnight? The agent notices on its next pass and quietly puts the numbers back. The plan is enforced continuously, not inspected occasionally — the difference between an autopilot and a once-a-year check ride.
4. Brief the flight, then fly the brief
Good crews brief the approach before they fly it: who shoots the approach, what the missed goes like, where the decision height sits. Changes in a GitOps world get the same treatment through pull requests. You propose the new configuration as a written change, a second set of eyes reviews it, and only after that brief is accepted does it become the plan of record. Nothing reaches production on one person’s say-so — which, if you have ever flown with a stranger, you’ll recognise as crew resource management applied to servers.
5. Standard callouts beat shouting
When the autopilot departs a captured altitude, it announces it. When a crew member sees something off, they say so in words everyone recognises. A reconciliation agent does its callouts the same understated way: it reports drift, flags failed syncs, and logs what it fixed, so the humans see a standard stream of “minor deviation corrected” rather than an occasional scream. If you have read a proper cockpit layout, you know why instrument placement matters — predictable information in predictable places. The agent’s reports are that philosophy continued into operations.
6. Abnormal procedures are written before anything goes abnormal
Nobody drafts the engine-out checklist during the engine failure. Aviation writes its abnormal procedures on a calm day and rehearshes them. Mature GitOps teams do the same for the day the automation and the humans disagree — say, during an incident when a responder needs to make an emergency change and the agent will, helpfully, try to revert it. The recognised answer is a rehearsed break-glass procedure: suspend the agent for the affected part, make the emergency fix, bring the automation back under control afterwards. Teams that skip this discover, at the worst hour, that a helpful enforcer can become a stubborn opponent.
7. Trust the instruments — after you inspect the pitot
A static port blocked by a mud wasp will lie to you all day with total confidence. Automation deserves the same respect: the reconciliation loop is trustworthy exactly as far as what it observes is trustworthy. So sensible teams keep an eye on the agent itself — the time an approved change needs before it is serving happily, how often the platform wanders off plan, and whether each correction holds. Instrument confidence comes from cross-checks, and this is one more place where a clean beginner’s guide to the aircraft cockpit makes a fine mental model: know what each instrument reads, and never let one gauge be the whole truth.
Where GitOps and Aviation Part Ways
The analogy holds impressively far, then breaks in one honest place: aeroplanes punish experimentation, while software thrives on it. Aviation solves this with certification and regulation — you don’t get to try a new fuel pump on a revenue flight. GitOps solves it with smallness and reversibility. Because every change is a reviewed written entry, trying something is cheap: merge it, watch the agent apply it, and if it misbehaves, revert the entry and watch the agent walk it back. The rollback is as boring as the rollout, which is the property aviation folks spend entire careers trying to buy with procedures.
The second difference is scope. A cockpit’s automation manages one aeroplane; a reconciliation agent can hold dozens of environments to their written plans at once, and the same pattern even extends beyond servers to cloud accounts and networks. Students who want to see where this career path crosses their own — infrastructure roles that reward people who think in checklists — will enjoy this piece on cloud and DevOps consulting work. And if you’re the sort of reader who likes knowing how things are put together before trusting them, the same instinct that makes you read about how an aircraft cabin is structured will make you enjoy reading the full write-up of this practice in the Ops Atlas’s GitOps reference, which is where I send engineers who want the formal version of everything above.
Fly the brief, then fly the aeroplane. GitOps is that sentence wearing a hard hat: write the plan, approve the plan in company, and put a tireless crew member on watch so the aeroplane stays where the brief says it should.
For readers who like the summary-card version, the whole practice fits on a kneeboard:
- Write the plan down before the engine starts.
- Keep the plan’s history intact, append-only.
- Let the automation hold the numbers, continuously.
- Brief every change in company before you fly it.
- Make deviations speak in standard callouts.
- Rehearse the abnormal procedure on a calm day.
- Cross-check whatever the automation reads.
None of this makes software people pilots, and it doesn’t make pilots programmers. But the habits transfer because they were never really aviation habits — they are discipline habits, invented wherever mistakes are expensive and memory is unreliable. Checklists, logbooks, briefings, callouts, rehearsed emergencies, and instrument cross-checks: seven habits, one culture, and now you know their names in a second trade. Next time a software friend mentions GitOps at a hangar flying, you can nod and tell them their favourite practice was invented at 3,000 feet long before it reached a data centre.
