You can open a tab right now and read the flight code that landed on the moon. It has been on GitHub since 2016. A former NASA intern named Chris Garry uploaded the files for the lunar module, Luminary099, and for the command module, Comanche055. These are not reconstructions, not transcripts; they are the actual assembly files, complete with the comments written by the people who were, at the time, trying to keep three astronauts alive.
The first thing you notice isn't the math. It's that the comments are better than yours.
Go look
The ignition routine lives in a file named BURN_BABY_BURN--MASTER_IGNITION_ROUTINE.agc. The Los Angeles DJ Magnificent Montague had been shouting "burn baby burn" on the radio during the 1965 Watts uprising; three years later, the MIT Instrumentation Lab programmers put his slogan on the subroutine that fired the engine that landed on the Sea of Tranquility. Inside the codebase, a section is labelled TRASHY LITTLE SUBROUTINES, which is exactly what it sounds like. Elsewhere, the programmers left an epigraph from Henry VI, Part 2 — the scene where Shakespeare's characters mock people who "talk of a noun and a verb" — a joke aimed squarely at the AGC's Verb-Noun interface. Margaret Hamilton's team — the team that shipped flight software for Apollo — wrote code you could grep for in good humor.
Scroll through any of the files and the pattern is the same. Tight subroutines. Names that describe what the thing does. Comments written in plain English that a non-programmer could read aloud and roughly follow. Smithsonian did a tour of the jokes a few years ago and found plenty more.
It is the kind of code a senior engineer writes when they expect someone smart but cold to come in at 2 a.m. and have to understand it fast.
The 1201/1202 story
Every few years a new generation of engineers learns this story. It's worth telling again because it gets used wrong.
In the final minutes of the lunar descent, the Apollo Guidance Computer started shouting 1201 and 1202 at the astronauts. Those codes meant the executive program had run out of room — NO VAC AREAS and NO CORE SETS, respectively. The cause, diagnosed later, was a switch configuration that left the rendezvous radar pumping spurious interrupts into a CPU already pushed to the edge. Roughly 15% of the machine's cycles were being stolen by a subsystem that was not supposed to be running.
The computer did not crash. It rebooted, shed the lowest-priority work, and kept the navigation loop alive. It did this five separate times on the way down, and every time it did, the critical tasks came back still running. Mission control called "Go for landing." The priority scheduler that made this possible had been designed years earlier by J. Halcombe Laning, a mathematician at MIT who understood that a real-time computer is eventually going to run out of room and that the interesting question is what it does when that happens. Don Eyles, the 25-year-old programmer who wrote the descent code, had built on top of a scheduler already designed to absorb exactly this kind of overload.
The contemporary version of this story is usually told as "look how reliable old code was." That isn't quite right. The AGC was reliable because it was designed, all the way down, to fail in a useful direction. Not never to fail. To fail without killing anyone.
Yes, the comparison is unfair
The objections are reasonable, and I can hear them already.
The AGC had 2,048 words of RAM and roughly 70 kilobytes of read-only memory that was woven, literally, by hand at Raytheon. There was no user interface to speak of; there was a keypad with verbs and nouns. There was no network, no login, no package manager, no npm typosquatting. There were a small number of engineers reading every line. The hardware clock was deterministic enough that they could predict execution time to the cycle. The budget was a fraction of the Cold War's defense line item. Nobody was going to ship a feature to the moon in a week.
Everything you have now, they did not have. Everything you fight with — vendor churn, dependencies you never chose, an authentication provider that went down last Tuesday, a UI framework that replaced itself twice while you were writing your app, an LLM filling in a test file you will never read — they did not fight with.
So the comparison is not fair, and it is still fair. The tooling is not the same story as the discipline. Margaret Hamilton wasn't writing readable subroutines because she had slack in the schedule. She was writing them because Buzz Aldrin was a real person. The comments in BURN_BABY_BURN aren't the craft. The craft is the implicit assumption in every file that another human being is going to need to read this code in a crisis, and that the code should make their job possible.
Most of us are not flying to the moon. Some of us are flying payments, medical records, power grids, whole municipal services. The people who depend on our software are also real people. The thing Apollo's engineers had that we mostly don't is a culture that took the cost of our own incomprehensibility seriously.
What's still portable
Not a prescription. A short list of habits that predate the tools and don't need to go with them.
Name a file what it does. BURN_BABY_BURN--MASTER_IGNITION_ROUTINE.agc is, in modern terms, a fine filename. It tells you the mood, the subsystem, and the purpose in one line.
Write the comment for the reader who comes in cold. Not for the you of today. For the person who lands on this file in six years, having never seen it before, with an alarm going off.
Fail in a direction the rest of the system can survive. Shed low-priority work instead of crashing. Return a slow answer before you return no answer. Decide in advance which requests matter more than others, because your scheduler will not decide well at 3 a.m. and neither will you.
And — the hardest — expect someone to read what you wrote. Treat every file as evidence in a future post-mortem. Apollo's programmers did this reflexively because the post-mortem had a specific form: a televised press conference at which the mission ended in silence. Your post-mortem will be less dramatic. It will still cost somebody something.
The moon is still there
The tab is still open. The code has been public for a decade. Anyone with an internet connection can scroll through it in an afternoon. None of the craft in it requires 1969's hardware to reproduce.
The only thing standing between us and code that reads like Luminary099 is the belief that we don't have to write it that way anymore. We can stop believing that whenever we want.
Top comments (0)