CST 438 - Week 4 - "Software Engineering at Google"

One of the most interesting things I learned from "Software Engineering at Google" was how much emphasis Google places on the code review process. Before reading this chapter, I thought code reviews were mainly about finding bugs or checking if the code worked correctly. However, I learned that a good code review is much more than that. Reviewers also consider whether the code is easy to understand, maintain, and extend in the future. This changed the way I think about writing code because it showed me that software development is a team effort, not just an individual task.

I was also surprised to learn about the different roles involved in a code review, such as the peer engineer, codebase owner, and language readability approver. Each person has a different responsibility, which helps ensure that the code meets technical standards, follows project conventions, and remains readable for future developers. I had never realized how structured the review process could be in a large software company.

Another idea that stood out to me was the recommendation to keep code reviews small. The book explains that reviewing a few hundred lines of code at a time is much more effective than reviewing very large changes. This makes sense because reviewers can give more thoughtful feedback and are less likely to overlook mistakes.

Overall, this reading helped me understand that software engineering is not only about writing working code but also about creating code that other people can easily understand, maintain, and improve. I think these practices will be valuable to apply in future team projects and throughout my career as a software developer.