CST438 Learning Journal 4

I think the most interesting thing I learned from Chapter 9 of Software Engineering at Google is that code reviews are not just about finding bugs—they are an essential way of sharing knowledge and maintaining long-term code quality. Before reading this chapter, I thought code reviews were mainly a final step before merging changes. However, I now understand that they are also a learning opportunity for both the author and the reviewer.

One point that stood out to me was Google's emphasis on making code reviews small and manageable. Smaller changes are easier to understand, receive feedback on more quickly, and reduce the chance of introducing errors. This approach encourages continuous improvement rather than waiting until a large feature is completed. I also found it interesting that reviewers are expected to focus on the overall quality, readability, and maintainability of the code instead of only checking whether it works.

Another valuable lesson was the importance of creating a positive review culture. Constructive feedback, respectful communication, and clear explanations help developers improve without making reviews feel personal or discouraging. This reminded me that technical skills alone are not enough in software engineering; effective collaboration and communication are equally important.

This chapter changed the way I think about code reviews. Instead of seeing them as a checkpoint that slows development, I now see them as a collaborative process that helps teams produce better software while helping developers learn from one another. In my future programming projects, I want to write smaller, clearer changes and view feedback as an opportunity to improve rather than as criticism.

Comments

Popular posts from this blog

Computer Science BS Journal (CST334) : Week 3

Computer Science BS Journal (CST334) : Week 5

Computer Science BS Journal (CST334) : Week 8