CST 438 Week 4

 Question: What is the most interesting thing you have learned in your reading of "Software Engineering at Google"?

One of the most interesting ideas I took away from Chapter 1 of Software Engineering at Google is how clearly it distinguishes programming from software engineering. Programming is about getting code to work; software engineering is about making that code survive—across years, teams, and changing requirements. That framing immediately resonated with me because it aligns with the kind of work I want to do: building systems that last, not just scripts that run.

What surprised me most is how closely Google’s engineering philosophy matches the habits I’ve been trying to develop myself. The book emphasizes that engineers rarely have perfect information when making decisions. Instead, they make the best choice they can with what they know, move forward, and then revise as new information arrives. That mindset—plan, act, iterate—feels both practical and empowering. It removes the pressure to be “right” on the first try and instead encourages continuous refinement.

Another idea that stuck with me is the importance of addressing problems early. The book’s discussion of “shifting left” made the consequences very clear: the earlier you document, test, and fix issues, the less painful they become later. It’s not just a productivity trick; it’s a cultural value. Google treats early investment in quality as a way of respecting future engineers—including your future self. Seeing that principle visualized in the shift-left graph made it click for me in a way that felt almost intuitive.

Overall, the chapter didn’t just define software engineering—it reframed it as a long-term, collaborative discipline. And that perspective feels directly aligned with the kind of engineer I’m trying to grow into.