Her Code Got Humans on the Moon
I really enjoyed this reading, learning about Margaret Hamilton and her impressive contributions to the field of software engineering, especially at such a young age is truly inspirational. As someone who semi-aspires to be a software engineer, but sometimes feel that it’s not a welcoming environment for women, this reading really changed my perspective and gave me some hope and motivation. A few things stood out to me in this reading. First, Margaret felt a lot of pressure to avoid any mistakes. Mistakes are normal, but obviously, in such a high stakes environment, any mistake can be catastrophic. More than that, if she made a mistake, it would only worsen the image about women in “male-dominated fields,” and it would set a bad impression for future women scientists. For instance, the reading mentions a time where she suddenly remembered a bug in the code one late night, and immediately went to fix it, out of fear that any mistakes in the code would be blamed on her is a sad, but plausible scenario. Despite it being a team effort working on the Apollo software, any mistakes would’ve most likely pointed back to her. Luckily, that didn’t happen!
Another thing I found interesting is her attention to detail, implementing back-up plans for any scenario. Even when others on her team claimed that no astronaut would make such mistake, she still insisted on planning for every worst-case scenario. And it paid off. This reminds me of whenever I if-else statements, sometimes even though there are only two possibilities (true or false, for example), I still feel the need to write the second statement as an else if, JUST IN CASE. Obviously, this isn’t the same thing, but this two situations kind of related in mind.
Norman,“Emotion & Design: Attractive things work better”
This reading made me reflect on a lot of everyday things that we use. While I cannot think of any examples of the top off my head, I’m sure there are so many times where I’ve chosen the more aesthetic item, even when it is not functionally better. I think social media trends also contribute to these phenomena nowadays. Overall, I think Norman brings up some great points about how there sometimes always a trade-off between functionality and aesthetics, even though that is not necessary. His example about tools used during hazardous and stressful situations make sense, I guess that’s probably why emergency exits and fire extinguishers all look the same and work the same. Most emergency exit doors are “push” doors because that’s the fastest way to get everyone OUT, and it’s important that any tools needed to facilitate this escape are standardized and straightforward to use (fire extinguishers, ‘hammers’ in buses to break the window, etc.).
However, the balance between functionality and aesthetics still stands in calmer situations. Let’s say someone wants to pick up a new hobby and they buy a pottery kit. The packaging is aesthetic, the brand is well-known and trendy, and everything LOOKS good. Then, they go home and try to start working on their new pottery and nothing makes sense. The instructions are so short because they were trying to keep a minimalist aesthetic, and everything is organized really well but the user does not understand how to use anything. Now, this calm situation has become a frustrating one because what was supposed to be a relaxing, unwinding evening is now a confused, annoyed evening. This might not be what Norman meant by his explanations, but this is kind of what I understood. And this continues to apply in so many aspects of life, when an app developer makes a new app, the interactions should be built on user standards and shouldn’t require the user to think twice, or else the user will just delete the app and go back to what they know. The learning curve to adapt to something new shouldn’t be so high that the user abandons the experience.