On this day, one of the most monumental events in human history occurred—we made it to the Moon.

On July 20, 1969 the Apollo 11 astronauts succeeded in their goal, landing with near-flawless precision. Shortly after, Neil Armstrong and Buzz Aldrin took humanity's first historic steps on another world. And if you aren't aware, Margaret Hamilton is the engineer who got us there. She took humanity to the Moon.

Hamilton wrote the code for Apollo 11's on-board flight software, and as a result of her work, she received NASA’s Exceptional Space Act Award. If that's not enough, she is also credited with coining the term “software engineering.”

In a recent interview, she discussed her experience with the Apollo program and what it was like to be a woman in the earliest days of NASA.

Futurism: So before Apollo, how did you first get involved at MIT, what was your earliest work like?

MHH: Prior to Apollo, beginning in 1959, I worked on my first software projects, and they were for a professor at MIT.  During this time I learned several software languages on my own, but, I learned a great deal about systems and software from Professor Edward N. Lorenz.

The very first languages I programmed in were hexadecimal and binary. With Lorenz's guidance, I learned how to build software (in hexadecimal) and how to take advantage of the LGP30 computer hardware to most benefit the software's performance.  Lorenz encouraged me to design and build what would today be called a 'mini operating system' for my applications.

I also worked during this time on the SAGE system at Lincoln Labs and wrote software for the XD-1, the first AN/FSQ-7 computer, whose job was to search for 'unfriendly' aircraft—a very early form of 'homeland security.'

Hamilton at MIT Lincoln Laboratory in 1962, when she was developing software for the SAGE system. Credit: Margaret Hamilton

The size of the computers I and others worked on before Apollo varied from being huge, taking up rooms of warehouse like space, to being quite large.

SAGE was one of the first jumping off points where I became interested in the subject of software reliability.  When the computer crashed during the execution of your program, there was no hiding. Lights would be flashing, bells would be ringing and everyone, the developers and computer operators, would come running to find out whose program was doing something bad to the system.

The only information the computer provided to the developer for debugging his program was to light up a very large register on the console of the computer, showing the address where the program halted.

When my program was running, it always sounded like the sound of waves on a beautiful seashore, so we all referred to it as the 'seashore program.' Until one night at 4 am in the morning when I got a call from one of the computer operators who said something terribly wrong has happened with your program. When I asked him how he knew, he said 'it no longer sounds like a seashore!' Now, we had a new way to debug, using sound!

Futurism:  And what was the relationship between women and men and programming like when you started working? 

MHH: When I began as a programmer in 1959, and continuing until now, in every software organization and in every software project I have been involved in, there were always many more men than women programmers.

Women were always in the minority and men were always in the majority.

There were many more men than women in our profession ,and this is still the case. Regarding my own experiences, women were always in the minority and men were always in the majority. Before and during Apollo, my colleagues, including those on the software engineering team, for which I was responsible, were mostly male.

But more than anything, we were dedicated to the missions and worked side by side to solve the challenging problems and to meet the critical deadlines. I was so involved in what we were doing, technically, that I was oblivious to the fact that I was outnumbered by men.  We concentrated on our work much more than whether one was male or female. We were more likely to notice if someone was a first floor or second floor person, a hardware or software guy, or what area someone was specializing in, e.g., man-machine interface, operating system, error detection and recovery, or in an application specific area.

Futurism: What, or who, led you to this field? What would you say was your biggest inspiration as a young programmer?

MHH: Even though I was more often than not the only woman in my math and physics classes at both the University of Michigan and Earlham College, one of the math professors at Earlham College was a woman, named Florence Long; and she was a favorite of all of the students studying math. She was also a great human being.

As a result, I had originally wanted to major in abstract math along with mathematical linguistics, and then become a professor in math.

When I attended high school and college, software engineering was not yet a field.

There were other heroes outside of the technical world—my father who was a philosopher and a poet, and my grandfather who was a writer, a head schoolmaster and a Quaker minister. All were instrumental in my minoring in philosophy in college. All of these influences from those related to the fields of mathematics and philosophy helped to decide and integrate what was important for the path that I would take in the fields of computer science and systems design and software engineering.

When I attended high school and college, software engineering was not yet a field and there were therefore no classes in programming, i.e., 'software engineering,' to attend.

Futurism: So then when did you make the transition to the Apollo team? Can you explain how all of this happened?

MHH: It happened during the 1963 and 1964 time frame. I had been planning to resume studies in graduate school at Brandeis to major in abstract math, when I heard that MIT had received a contract from NASA to develop the software for 'sending man' to the moon. And that MIT was looking for people to work on this project.

I immediately called MIT to see if I could be involved in what sounded like the opportunity of a life time; and within hours I set up interviews with the two project managers at MIT. Both of them offered me a position on the same day as the interviews.  I did not want to hurt anyone's feelings, so I told them to flip a coin as to which group was going to hire me; hoping for the project manager to win the coin toss, who, in the end, did win and therefore ended up hiring me for his area. Fortunately, that is what happened, and I was on my way.

Futurism: And of course, we're all probably dying to know what a typical day on the Apollo project was really like.

MHH: The working environment was very much like the rest of MIT. Informal, but serious. Because software was a mystery, a black box, to upper management, we were given total freedom and trust. Mutual respect was across the board. We were very lucky to be in the right place at the right time.

There was no choice but to be pioneers.

There was no school to attend or field to learn what today is known as 'software engineering' or 'systems engineering.' When answers could not be found, we had to invent them; we were designing things that had to work the first time, and our systems had to be 'man-rated.' Many on the team began as fearless 20-something-year-olds. The greater the challenge, the more fun we had. And, yet, dedication and commitment were a given. There was no time to be a beginner. Learning was by being and doing, and a dramatic event would often dictate change.

In the beginning, those of us who were software developers lived in our own world. We had our own culture. Non-software types were often reminded, sometimes in subtle ways, of that fact by the software people. We lived by and made up our own rules, not only because we wanted to, but because we had to.

To management and non-software subject matter experts, software seemed to magically appear within the on-board flight computer, integrated and ready to go.

Futurism: How did you balance your non-professional life and the Apollo project? Was it difficult?

MHH: Being young helped! Also, I made sure to spend as much time as possible with my daughter by taking her to work with me during nights and weekends.

Futurism: Tell me about the infamous photo with you and a stack of books taller than yourself. What were the books? There are a lot of different captions and explanations going around!

Margaret Hamilton with the code that she wrote for Apollo 11

MHH: This photo was taken of me by the MIT photographer. The photos were to become part of the information that MIT was providing to the news media, both at the time of the landing on the Moon and at the time of the landing on Earth after returning home from the moon.

The following was excerpted from a description of the photo in an MIT document: 'Taken by the MIT Instrumentation Lab [Draper Lab] photographer in 1969 (during the time of Apollo 11). Here, Margaret is shown standing beside listings of the software developed by her and the team she was in charge of, the LM and CM on-board flight software team.'

The task at hand included that of being able to successfully develop and integrate all of the on-board flight software for the Command Module (CM), the Lunar Module (LM), and the systems software shared between and residing within the CM and the LM.

We also had to make sure that there were no interface/integration/communication conflicts where updates and changes were continuously being submitted from hundreds of people, and continuously changing over time and over the many releases for every mission—when software for one mission was often being worked on concurrently with software for other missions.

A tiny part of the printout of the AGC source code for the on board flight software for the Apollo Guidance Computer. Credit: Margaret Hamilton

We had to make sure everything would all play together as well as making sure that the software would successfully interface to, and work together with, all the other systems including the hardware, peopleware and missionware for each mission.

Each of the books, we called them 'listings,' in the stack of listings was made up of only Apollo Guidance Computer source code and nothing else.

All the listings in the stack contained the source code for the Apollo 11 mission and future 'to be' missions that we were working on concurrently.

For every mission there were two listings, one for the CM and one for the LM. Within this stack, two of the listings were for Apollo 11, one for the Apollo 11 CM and one for the Apollo 11 LM.

Futurism: Finally, what piece of advice would you give you young girls who are interested in pursuing a STEM career?

MHH: Regarding one's education related to any field, I think it is important to bring together what I would call the necessary experiences for both a 'streetwise and a formal education.  From a streetwise perspective, the more jobs a kid has, and the more varied they are, during his or her youth, the better prepared one is for going out into the world. When considering the formal part of a kid's education, learning subjects like English and other languages, history and STEM [science, technology, engineering and math including logic], including how to use computers...this is important in preparing for all parts of our modern society.

Software engineering related courses are important for all aspects of STEM including that of helping one to become more creative, a better problem solver—including being a good detective and how to understand the world in terms of a system of systems—to learn how to be analytical and objective, about abstraction, and how to think outside of the box. How to learn from your mistakes and turn that into a positive result can also be learned from software engineering related courses. I believe it is also important to learn (or be around) things like music, art, philosophy, linguistics, and math including logic; any of which could help improve one's being an excellent programmer/problem solver/thinker and to have a more global perspective on things. The ultimate goal would be that of teaching one how to think (design).

I would add that what seems to work best for me when I want to learn about anything new or to do anything new is not to let fear get in the way.

One should not be afraid to say 'I don't know' or  'I don't understand,' or to ask 'dumb' questions, since no question is a dumb question. To continue even when things appear to be impossible, even when the so called experts say it is impossible; to stand alone or to be different; and not to be afraid to be wrong or to make and admit mistakes, for only those who dare to fail greatly can ever achieve greatly.

This interview had been slightly edited for brevity and clarity.

Share This Article