Margaret Hamilton
You may have seen this photograph before, perhaps in a book, or while doomscrolling through those science-fact YouTube Shorts.
The woman in it is Margaret Hamilton. Beside her is a stack of printed software listings from the Apollo program. She led the team that developed the onboard flight software used to take astronauts to the Moon.
The photograph is neat because it makes software look physical. Today, code sits invisibly inside our phones, cars, hospitals, toasters, and almost everything else. Seeing code piled from the floor to nearly the top of Hamilton’s head is fascinating. The story behind the photograph is even better.
Hamilton and her team built software that could recognize when something was going wrong, decide which tasks mattered most, and keep working under pressure. During Apollo 11’s descent to the Moon, those ideas helped prevent a computer overload from forcing the mission to abort.
That alone would make her worth writing about. What inspires me most, though, is the way she approached problems. Hamilton did not build for a perfect plan. She built for what might happen when the plan met reality.
Before Apollo
Hamilton studied mathematics at Earlham College in Indiana. After graduating, she briefly taught high-school mathematics before taking a job at MIT. The job was meant to be temporary while her husband attended Harvard Law School.
Instead, it became the start of her career in software.
At MIT, Hamilton wrote programs used for weather prediction. She later worked on SAGE, an early air-defence system designed to detect and track aircraft.
Computer-science degrees barely existed at the time. Programming was not yet seen as the established profession it is today, so people with strong mathematical backgrounds often found their way into it.
Hamilton’s work eventually brought her to MIT’s Instrumentation Laboratory, which had been contracted to develop the Apollo Guidance Computer. She joined the Apollo effort and focused on some of the least glamorous problems in software: detecting errors, recovering from failures, and deciding which tasks a computer should prioritise when it could not do everything at once.
These problems may sound ordinary now, but at the time, they were not.
Software was often treated as less important than hardware. Hamilton pushed for better testing, stronger error handling, and systems that could continue operating when something unexpected happened. She also helped popularise the term software engineering, partly because she wanted software to be treated with the same seriousness as other engineering disciplines.
Margaret and the Machine
Hamilton understood something that seems obvious but is often ignored: people make mistakes.
According to Hamilton, her young daughter once visited the lab and began playing with a simulator. During the simulation, she selected a program that was meant to run before launch. The system crashed.
Hamilton immediately saw the problem. She asked for safeguards to be added but was reportedly told that astronauts were too well trained to make such a mistake. Then, during Apollo 8, astronaut Jim Lovell did essentially that.
The mistake wiped navigation data from the computer while the spacecraft was in flight. Hamilton’s team had to work out what had happened and send instructions that allowed the astronauts to recover. The point is not that Lovell was careless. He was an expert operating an extraordinarily complicated machine in space. The point is that expertise does not make someone incapable of making a mistake.
A safe system should not depend on perfect people.
This way of thinking became even more important during Apollo 11.
As the lunar module descended towards the Moon, the guidance computer began producing 1201 and 1202 program alarms. Its radar system was feeding it more work than it could handle. Buzz Aldrin and Neil Armstrong were already attempting one of the most dangerous maneuvers in history, and now their computer appeared to be failing. It would have been easy for the system to freeze or crash.
Instead, the software dropped lower-priority work and continued running the tasks needed for the landing. Mission Control understood what the alarms meant and told the astronauts to continue.
The landing went ahead.
This was not the work of Hamilton alone. It depended on the engineers who designed the computer, the programmers who wrote its software, the people in Mission Control who interpreted the alarms, and the astronauts who flew the spacecraft. Hamilton’s role was to lead the software team and push for the kind of thinking that made recovery possible.
Hamilton also treated the astronauts as part of the system, as opposed to passive passengers. The software was not supposed to replace human judgement, but to give people useful information and enough control to act on it.
If you, like me, sat through hours of lectures related to human-computer interaction, this idea probably sounds familiar. That is partly because ideas like Hamilton’s helped make it familiar.
Her approach can be summed up simply:
Assume something will go wrong. Build the system to handle it. Give people the information they need to make the final call.
I see Hamilton as neither an optimist nor a pessimist. She simply designed around reality. She refused to build a system that worked only when everything went right.
I feel that this idea reaches far beyond space travel. The alternative to graceful failure is not always success. Often, it is catastrophic failure. Software, plans, organizations, and even relationships need room for small things to go wrong. Without that room, one mistake can bring down the whole system.
In 2016, Hamilton received the Presidential Medal of Freedom. The citation praised her contributions to “asynchronous software, priority scheduling and priority displays, and human-in-the-loop decision capability,” describing them as foundations of modern, highly reliable software engineering.
Try saying that quickly.
Why She Inspires Me
She held her ground against people who outranked her. She was doing work she believed was necessary while being told repeatedly that it wasn't. That takes a specific kind of nerve. Often, people cave under "the experts say it's not needed."
She was doing something genuinely new, with no template. There was no "software engineering" career path yet, which meant there were no senior mentors in the field to model herself after. This meant she was inventing the discipline while practicing it. That's different from being excellent within an established field, as she had to decide what "good" even looked like.
The stakes were about as real as it gets. If the software had failed, people might not have come home. There's something incredible about someone who treated "boring" defensive engineering with the seriousness of a life-or-death problem, because it was one.
Her work did not receive the recognition it deserved at the time. The Medal of Freedom came in 2016, almost 50 years after Apollo 11. For decades, Hamilton worked in relative obscurity while the astronauts became household names.
Or maybe it's simpler than all that
Maybe it is just the photograph itself: a person dwarfed by the physical weight of what she and her team built, calmly adjusting the stack like it is Tuesday.
Thank you for inspiring me, Margaret.
