The Computer That Knew What to Drop

On 20 July 1969, the lunar module Eagle was falling towards the Sea of Tranquility, and a yellow light came on.

Neil Armstrong’s voice, calm but tighter than usual, reached Houston: program alarm. On the little keypad display in front of Buzz Aldrin, a number: 1202. Nobody in the cabin knew what it meant. They were still miles above an unknown surface, descending fast, the fuel was going, and the computer that was flying them down had just said, in its own way, I’m in trouble.

In Mission Control, a young guidance officer named Steve Bales had seconds to decide whether to abort the landing. Beside him, Jack Garman had a hand-written list of every alarm the computer could raise. Bales looked, listened, and answered: we’re go on that alarm. It came again, and a different one, 1201. Go. A few minutes later, Armstrong said that the Eagle had landed.

What happened inside that computer in those minutes is, I think, one of the most beautiful pieces of engineering ever done, and one of the most useful ideas for living that I know.

A machine woven by hand

The Apollo Guidance Computer weighed about 32 kilograms and had less memory than a single photo on your phone.

It had 2,048 words of working memory, the whiteboard: roughly four kilobytes. Its program lived in 36,864 words of permanent memory, the notebook: around seventy-two kilobytes. That’s all. Every calculation needed to fly to the Moon, find the landing site and come home had to fit.

And the permanent memory was not printed or burned. It was woven. It was called core rope memory: thousands of tiny magnetic rings, with copper wires threaded through them by hand. A wire passing through a ring meant a 1. A wire passing around it meant a 0. The software was, quite literally, sewn.

The people who did the sewing at Raytheon’s factory near Boston were mostly women, many hired from the local textile mills and the Waltham watch works for the steadiness of their hands. A single memory module took around eight weeks to weave. Which meant the software had to be finished, frozen and correct months before launch. There was no update over the air. No patch. Whatever went up was what you had.

It’s hard to imagine a more low-tech way of making a high-tech thing. And it shaped how the software was written: with extraordinary care, and with no room for anything that didn’t need to be there.

If you’ve read the first Foundations brick, you’ll recognise the shape. The woven rope remembered the program. The erasable cores remembered the moment-to-moment state. The processor changed numbers into steering commands. Wires sent them to the engine and the display. Remember, change, send, at the edge of space.

What went wrong

The alarms weren’t a bug in the program, and they weren’t the astronauts’ fault.

A radar meant for meeting the command module later in the mission had been left switched on. Because of a small mismatch in how two pieces of hardware had been specified, it kept interrupting the computer with meaningless work: tiny requests to update an antenna that wasn’t really moving. That stole about an eighth of the computer’s time. Then Aldrin asked for a display of how far they were from the surface, and that took another slice.

The computer now had more work to do than time to do it in. Its list of jobs grew faster than it could finish them, until there was no room left on the list. 1202: executive overflow. The kitchen had more orders than cooks.

Most systems, in that situation, do one of two things. They freeze. Or they keep trying to do everything, slower and slower, until nothing gets done in time. Either would have meant an abort, or worse.

What it did instead

The computer’s operating system, its executive, had been designed by Hal Laning at MIT, and the software around it by a team led by Margaret Hamilton, who was in her early thirties and is widely credited with popularising the term software engineering.

They had built something unusual for the time. Every job had a priority. And when the computer ran out of room, it didn’t panic and it didn’t freeze. It restarted itself, in a fraction of a second, and rebuilt its list of jobs, keeping only the ones that mattered most. Steering the craft: kept. Firing the engine correctly: kept. Navigating to the surface: kept. The display of distance on Aldrin’s keypad, nice to have but not essential: dropped.

Then it carried on flying.

The astronauts barely noticed anything but a warning light. The essential work never stopped. The computer had been designed, from the start, with the knowledge that one day it would be asked to do more than it could, and with a clear, calm answer prepared in advance for what to let go of.

The computer didn’t survive by doing everything. It survived because it knew, before the trouble came, what it was willing not to do.

The aha

When I first put this story next to Four Thousand Weeks, something clicked.

Oliver Burkeman’s argument was that we’ll never get it all done; that the list always grows faster than the time; that the question isn’t how do I fit it all in? but what will I let go of? Most of us know this in theory. Very few of us have decided, in advance, what our 1202 answer is.

So when a hard week comes — a child ill, a deadline, a parent needing help, the radar of a hundred small demands stealing our cycles — we do what bad software does. We freeze, or we try to keep every plate spinning, slower and more anxiously, until the essential things start to slip along with the trivial ones.

The Apollo engineers’ quiet genius was to make that decision when they were calm, months before the crisis, and write it into the machine. That’s what essentialism actually is: not a tidy calendar, but a priority table you’ve already agreed with yourself, so that when overload comes, you shed gracefully instead of crashing.

Writing your own priority table

You can do this on one sheet of paper, on an ordinary Sunday, when nothing is on fire.

Priority one: keep the craft flying. What, if dropped, causes real harm? For most of us: sleep, the health of the people we love, the core of our work, a few minutes outside. These never get shed.
Priority two: the landing. The work that moves your life forward in this season: the project, the learning, the building. Protected, but it can slow down for a few days.
The displays. Things that are pleasant and useful but not essential: the tidy inbox, the extra meeting, the perfect dinner. First to go in a hard week, without guilt.
The rendezvous radar. Things stealing cycles that shouldn’t be running at all right now: notifications, background worries, commitments you said yes to out of politeness. Find these and switch them off before the descent.

Put the sheet somewhere you’ll see it. When the yellow light comes on, you won’t have to think. You’ll already know.

The gift of constraint

There’s one more thing the Apollo computer teaches, and it ties back to every piece in this journal.

The engineers did extraordinary work because they had so little. With four kilobytes, every word had to justify itself. There was no room for features nobody needed, for vague code, for a second way of doing the same thing. Scarcity forced clarity.

Today the apps on our phones are often thousands of times larger than the whole program that landed on the Moon, and many of them do far less. Our homes, our calendars and our heads are the same: abundant, and therefore cluttered. Constraint is uncomfortable. But it’s also the thing that made people write the most careful software in history, and it’s the thing that makes a small house, a short list and a simple plate so clarifying.

Back in Houston, nobody shouted. Bales listened, checked, and said a single word. In the cabin, Armstrong kept flying. In the woven memory, the computer kept steering, quietly dropping what didn’t matter. Calm at every level: the headland, standing in the waves, letting the water break and fall.

Sources

Apollo Guidance Computer, Wikipedia — memory sizes, the 1201/1202 alarms and their cause, the executive’s design
Ken Shirriff, Software woven into wire: Core rope and the Apollo Guidance Computer (2019)
Oliver Burkeman, Four Thousand Weeks (2021)