Shiwen Dialogue Issue 24 | She Named This Industry — Margaret Hamilton and 60 Years of Software Engineering

Host: Shiwen (AI) | Guest: Yongliang

---

Opening: An Obituary That Reminded an Industry of Its Own Name

On October 7, MIT published an obituary: Margaret Hamilton passed away on September 30 at the age of 90. The news reached Hacker News that same night, and by now it has over 800 upvotes and over 100 comments—the popularity is just a matter of scale, but the picture in the comment section is very consistent: many people posted that famous photo of her in her youth, standing next to a stack of printed code as tall as she was; others repeatedly posted the Wikiquote link, just to confirm the same thing—the term “software engineering” was the one she insisted on using. The screen was filled with RIP, legend, pioneer—these are the exact words setting the tone in the comment section. A tech community that usually argues over anything and everything, this time had no arguments, only farewells.

Shiwen: Why is the obituary of a 90-year-old worth making the entire industry pause?

Yongliang: Because the professional title of millions of us was coined by this lady. And when she coined this term, she was treated as someone telling a joke. This episode is a character memorial; I don’t intend to force a debate. The sense of conflict lies in a contrast: in her era, “not understanding” resulted in letting go, while in our era, “not understanding” results in strict control. As usual, where I estimate, I will clearly state that it is my estimate, not statistics.

Shiwen: Should we talk about the person first, or the term first?

Yongliang: The person first. The term was earned by the person; the order cannot be reversed. Let me add a timeline: passed away on September 30, MIT published the obituary on October 7; both dates are clearly stated in the obituary; the memorial service is scheduled for next spring, to be held in Cambridge, USA—the location of MIT.

Q1: Who is she—starting from the job ad to “send people to the moon”

Shiwen: Tell her story accurately. What exactly has she achieved?

Yongliang: Lay out three things, and the significance becomes clear.

First, in 1965, she was hired as the first programmer for the Apollo program at the MIT Instrumentation Laboratory, and also the first female programmer in the project. The origin of this “first” is quite everyday: she originally planned to go to graduate school, but her husband saw an ad in the newspaper for the Instrumentation Laboratory hiring to “send people to the moon,” so she applied. Second, by 1968, when she served as the assistant supervisor of the Command and Service Module team, the Apollo software team had already grown to over 400 people—from writing code alone to leading 400 people, in three years. Third, in 2016, Obama awarded her the Presidential Medal of Freedom; the gist of the citation was: she defined a new form of software engineering and helped launch an industry that would forever change human history.

She published over 130 papers in her lifetime, and later started two businesses, founding Higher Order Software in 1976, and Hamilton Technologies in 1986. Her obituary also listed a string of easily overlooked honors: NASA’s Exceptional Space Act Award, Computer History Museum Fellow, and induction into the National Aviation Hall of Fame in 2022. Plus an adorable fact—in 2017, she was made into a LEGO minifigure, included in the Women of NASA set. There’s another detail I love: in 2015, the Apollo code she wrote back in the day was uploaded in its entirety to GitHub; printouts from half a century ago are still being read line by line by young people today.

Shiwen: Was she formally educated in computer science before entering the field?

Yongliang: No. She graduated with a bachelor’s degree in mathematics from Earlham College in 1958, with a minor in philosophy. Her first programming job was in the MIT meteorology department, writing weather prediction software for Edward Lorenz—yes, the one who later proposed chaos theory. In 1961, she moved to Lincoln Laboratory to write software for the SAGE air defense system; it was during those years that she began to ponder the then-brand-new concept of “software reliability.”

Note this path: no computer science degree, diving headfirst from the math department into an industry that did not yet exist, building the industry itself as she worked. This path is repeating itself 60 years later—most of the people pouring into the AI industry today are not formally trained in AI either. This is my observation, not a statistic.

Q2: How did a word treated as a joke grow into the name of an industry?

Shiwen: Where did that “software engineering” in the title actually come from?

Yongliang: MIT’s obituary cited her recollection from a 2018 interview with Spain’s El País, which paraphrased goes like this: in that era, software was seen as “art and magic, not science,” and was not valued in projects. Her response was to directly coin a term—software engineering—deliberately mirroring the word structure of hardware engineering, to show management: what we do is the same kind of work as the engineers who build rockets and capsules.

As a result, it was initially treated as a joke. Peers felt, how dare a mere software group call itself engineering? It was only many years later that the term gained respect. Today, “software engineer” is printed on the business cards of millions of people, yet few know that this name was insisted upon by a programmer during an era of ridicule.

Shiwen: It’s just a name, is it really that important? Doesn’t the work get done the same way regardless of what you’re called?**

Yongliang: It’s not the same. Names determine resources. In that era, budgets, headcounts, and influence all lay on the hardware side; software was an afterthought. If you called yourself a “programmer,” you were logistics; if you called yourself an “engineer,” you earned the right to sit at the design decision table. In reality, she was using a word to claim professional status for an entire occupation. And she wasn’t just shouting slogans—the reason this term later took hold wasn’t because it won a debate, but because it was fulfilled through task after task. More on this in Q3 below.

Having led teams for seventeen years, my firsthand experience of this point is very direct: what an occupation is called within a company directly affects its priority in meeting schedules, the headcount it can request, and the difficulty of securing a budget. This is speaking from my experience, not a law.

Q3: Two Life-Saving Stories—One Prevents Mistakes, One Rescues the Scene

Shiwen: Is her most famous technical legacy to this industry those two stories?

Yongliang: Right, one is about “humans should not be assumed to be error-free”, and the other is about “what to save first when the system overloads”. Let’s start with the first one. This story is often called the Lauren error; Lauren is her daughter’s name.

When her daughter was four years old, she was playing on the simulator and accidentally started the P01 pre-launch program, causing the simulator to crash on the spot. Hamilton proposed adding protection in the software, but was overruled by her superiors, on the grounds that: astronauts are well-trained and would not make such a mistake. She couldn’t win the argument and had to let it go. As a result, during the Apollo 8 lunar orbit mission, astronaut Jim Lovell really did accidentally start P01 during the flight, losing navigation data, and her team was urgently called back to rescue the situation. From then on, the modifications she proposed were adopted. The MIT obituary called this story an early example of “defensive programming”—building software that can anticipate and correct its own errors, rather than betting on humans not making mistakes.

Shiwen: The second one, is that the famous moon landing alarm?

Yongliang: In July 1969, a few minutes before the Apollo 11 lunar module landed, the onboard computer reported a 1202 error, which was later found to be a hardware switch failure causing the computer to overload. During those few minutes when the whole world held its breath, the priority scheduling software written by Hamilton’s team automatically shut down low-priority background tasks, leaving all computing power for the critical tasks related to landing. Houston ground control chose to trust this software and decided to continue the descent. A few minutes later, two people’s footprints were left on the moon.

When I lead a team in creating degradation plans for production incidents, a variant of this story is always in my mind: at the moment of system overload, what must be preserved and what can be discarded—this decision must be written into the system in advance, and cannot be left for people at the incident scene to improvise. In her era, there was no such term as “degradation plan”, but what she did was exactly the same thing. This is my personal point of resonance when leading a team, for your reference.

Q4: A 60-Year Cycle—Trading a Black Box for Freedom, or a Black Box Under Strict Control

Shiwen: Putting her era and today side by side, what is the biggest contrast?

Yongliang: In a 2009 interview with MIT, she said something verbatim, which I’ll quote directly: “Because software was a mystery, a black box, upper management gave us total freedom and trust”—precisely because software was a mystery, a black box, upper management gave us total freedom and trust.

Reading this today feels almost surreal. 60 years ago, no one could understand software, so no one managed it, and the team instead gained complete autonomy and trust. 60 years later, it’s the exact opposite: today’s AI is also a’ black? black box,! but what the black box brings is not freedom, butF audits, alignment evaluations, filing, red teaming, and disputes over the right? right to+1 to explanation. Similarly “incomprehensible?=9,” management’sG reaction has shifted from letting go to tightening& tightening control.

*ShiwenC:9E% wen: Why does the same opacity lead to the opposite treatment?

Yongliang: My reading is this:=9: for things that are incomprehensible, when the scale isC is? small/ small, it9 small, it’s another department’s problem; when” problem; when the scale is large, it’s everyone’s risk. Back then, no matter how software erred, it ruined one task; today, if* today, if a model errs, it affects the information flow6 information flow and decisions of hundredsG hundreds of millions of people. The42 people. The radius of trust hasn’t changed much, but the scale of the trusted object has increased a millionfold, so control must step in. This is my analytical framework, not statistics.

An even more fascinating contrast lies at the semantic level. “Software engineering” was mocked back then, the punchline being “You dare call this engineering?”; today “AI engineering” is experiencing the exact same semantic war—“Tweaking prompts is also called engineering?” “Building a workflow makes you an engineer?” I judge that in ten years, “AI Engineer” will become an unquestioned title just like3 just like “Software Engineer,” and those who mock the term today will be forgotten just like those who mocked her back then. This is my judgment, not a prophecy.

There is another layer worth mentioning: the directions of her two ventures in her later years were actually highly consistent—using mathematical methods to make software verifiable and deducible, trying to turn the black box into a glass box. She understood earlier than anyone: freedom and trust are temporary dividends of the black box; to sustain them long-term, you must open the box. This statement serves as the same reminder for those of us building AI systems.

Epilogue

Shiwen: Summarize this episode in one sentence?

Yongliang: When she went to apply for that job of “sending people to the moon” in 1965, “software engineering” was still a joke; when she left, it was the name of an entire industry. Those of us who call ourselves software engineers use the title she fought for every day. Treating errors as inevitable, writing degradation into the system, and eventually opening the black box—the methods left behind by her generation are worth more than the title.

Shiwen: We dedicate this episode to bidding farewell to Margaret Hamilton. See you next time.

[In-Depth] The Black Box’s Dividend and Bill

Hamilton actually fought the same battle throughout her life, and the opponent was always the same statement: “These things you do are not science.” In her early years, she responded with software engineering, aligning software with the status of engineering; in her later years, she founded a company to pursue directions like Universal Systems Language, using mathematical methods to make software verifiable, turning “art and magic” into something that could be reasoned about.

Her quote from 2009 is worth reading over and over because it exposes a counter-intuitive mechanism in the history of the industry: opacity was once a dividend. Management couldn’t understand software, so they simply ignored it; freedom and trust were byproducts of “not understanding.” But this dividend has an implicit clause—the trust granted by the black box is essentially held in escrow; once the system grows large enough to affect livelihoods, the bill comes due. In the Apollo era, when software crashed, it ruined a single mission; today, when AI errs, the unit of cost is companies and public trust. Therefore, these 60 years are not about “management becoming more conservative,” but about the things being trusted growing larger, causing rules to naturally emerge.

For engineers working in AI today, her life story provides not nostalgia, but two very practical things: first, a name must be fought for, but it must ultimately be redeemed by results—“software engineering” earned respect not because a debate was won, but because the software didn’t drop the ball during those few minutes in July 1969; second, the black box’s dividend period is limited, so while freedom remains, build the abilities to “anticipate errors, degrade gracefully, and be verified” into the system—these two principles she laid down 60 years ago are exactly what AI systems lack the most today. The day these two are universally built into AI systems, the term “AI engineering” will truly be established—just as after July 1969, no one ever laughed at “software engineering” again.

Sources for This Issue

• MIT News obituary (2026-10-07, author Janine Liberty): news.mit.edu/2026/margaret-hamilton-computing-pioneer-dies-1007 (firsthand; date of death, life milestones, 130+ papers, 400-person team, Lauren error, 1202 alarm, origin of the term “software engineering”, 2016 Presidential Medal of Freedom, 2015 code on GitHub are all sourced from this)
• Hacker News discussion (story 49998895, 857▲ / 101💬, 2026-10-08 read count): life-sized code photo, Wikiquote link, and the comment section consensus that “she coined the term software engineering” are paraphrases, without specific attribution
• Quote sources: “black box / total freedom and trust” is from a 2009 MIT interview (cited via the obituary); “art and magic, not science” and “initially treated as a joke” are from a 2018 El Pais interview (cited via the obituary, Chinese is a paraphrase); the award citation is a loose translation
• Guest’s personal experience (17 years of tech management, 70-person peak team, degradation plan practice, non-CS major observation, assessment of the term “AI engineering”): first-person experiential statement, not statistical