Week 76 (7/15/2026 - 7/21/2026)

       Hi everyone, welcome to my 76th blog! This is the Week 4 post for CST 438 Software Engineering.

  • What is the most interesting thing you have learned in your reading of "Software Engineering at Google"?
    • As a software engineer myself, I would say the most interesting thing covered so far is the discussion of code reviews. It was also interesting to see where the code review flow between my employer and Google compare and contrast.
    • The book describes the flow for Google code reviews as follows, word for word:
      1. A user writes a change to the codebase in their workspace. This author then creates a snapshot of the change: a patch and corresponding description that are uploaded to the code review tool. This change produces a diff against the codebase, which is used to evaluate what code has changed. 
      2. The author can use this initial patch to apply automated review comments or do self-review. When the author is satisfied with the diff of the change, they mail the change to one or more reviewers. This process notifies those reviewers, asking them to view and comment on the snapshot.
      3. Reviewers open the change in the code review tool and post comments on the diff. Some comments request explicit resolution. Some are merely informational.
      4. The author modifies the change and uploads new snapshots based on the feedback and then replies back to the reviewers. Steps 3 and 4 may be repeated multiple times.
      5. After the reviewers are happy with the latest state of the change, they agree to the change and accept it by marking it as “looks good to me” (LGTM). Only one LGTM is required by default, although convention might request that all reviewers agree to the change.
      6. After a change is marked LGTM, the author is allowed to commit the change to the codebase, provided they resolve all comments and that the change is approved.
    • For comparison, here is my organization's code review flow:
      1. This step is similar to Google. The description here is more broad, but in practice, this would be equivalent to me creating a branch, pushing changes (commits) to it, and potentially opening a pull request (PR) as a Draft.
      2. This step sounds like when a pull request (PR) is moved from Draft to Open status. In the Open status, we have a GitHub Action that automatically triggers Cursor Bugbot on every subsequent commit in order to discover issues that may have been missed in the earlier Draft phase. Especially in the age of agentic development, this is an important step. We specifically chose Cursor for this purpose because it offers a different agentic-centered perspective from the code author, especially if Cursor uses a different AI model than the author. An example of this is Cursor using a GPT model to judge code generated by Claude. Here is an article of what this workflow looks like in practice, I use it every day in my software engineering job: https://workos.com/blog/cursor-bugbot-autoreview-claude-code-prs
      3. This is the (mostly) manual human review step. In our organization, we are currently experimenting with a tiered approach that would allow the lowest risk changes to be automatically approved by a custom AI-powered GitHub Action, with medium and high risk changes still requiring a human review. Currently, this has only been rolled out to select repositories and is still in the very early testing stages. Effectively, I would say about 90% of low risk pull requests in our organization still need another engineer's approval.
      4. This step pans out identically if changes are requested during the human review process (or even the AI review process). "Uploading new snapshots" in our context would mean pushing a new commit to the remote branch. 
      5. This step is similar in our org. A reviewer with write access approves the changes, which acts as a "LGTM". Sometimes a reviewer will right "LGTM" as a comment in addition to the approval itself. Our convention is typically that one approval is enough to merge into main, although sometimes multiple people will approve the same pull request (PR) on occasion. This is not a requirement nor the norm, though.
      6. This step is the same as Google. Once at least one reviewer with write access approves the changes, the original pull request (PR) author can merge into main. Depending on the repo, sometimes it is standard practice for approvers to merge the change into main.
    • Overall, our code review flow is very similar to that of Google's, with perhaps some minor differences overall. The largest difference might be of the fact we are experimenting with custom AI approver bots that has custom business context regarding architecture decisions, understanding common gotchas and things to watch out for, etc.
    • Finally, here is a graphic from the above article showing how Cursor Bugbot can work in a Claude Code CLI workflow. Replace "You Review" with "Another engineer reviews" and it is very accurate to how this workflow functions at my company.

    That is all for this week, see you in my Week 77 post!

Comments

Post a Comment

Popular posts from this blog

Weeks 65 - 72 (4/27/2026 - 6/21/2026)

          (Click on READ MORE for better formatting)      Hi everyone, welcome to my 65th-72nd  blog!  This is the Week 1-8 post for a bit of an awkward time in my CSUMB CS Online journey, and one that quite frankly happened by chance. It was discovered that I was not required to take CST383 Introduction to Data Science in order to graduate from the program. As a result, I decided to drop the course and instead take the Summer 2026 A term to recharge after a little over a year of near-nonstop grinding in this program.     That being said, the idea of considering an online program for a M.S. in Computer Science has been in the back of my head basically since the beginning of my B.S. in Computer Science here at CSUMB. Since I now have this newfound eight weeks of free time, I believe now is the perfect opportunity to begin preparing my graduate school applications. To be completely honest, there is really only one school I a...
Read more

Week 73 (6/22/2026 - 6/30/2026)

       Hi everyone, welcome to my 73rd  blog!  This is the Week 1 post for CST 438 Software Engineering. What did you expect a course in Software Engineering would cover? After completing week 1, how has your opinion changed? This question actually brings up an interesting nuance. If you had asked me this prior to entering the industry as a software engineer (December 2025), my answer to this question could have been completely different. Since I have already entered the industry, I was genuinely impressed how much the orientation of this class sounded like a pretty accurate rendition of the current status quo in the industry. For example, I appreciated that Prof. Wisneski understands the relevancy of agentic development via tools such as Claude Code, which is something I use at work every single day. To be more specific, I run most of my prompts on Claude Opus 4.8 1M context. Thankfully, my work has me on a Premium seat of Anthropic's Team plan. This is so...
Read more

Weeks 41 - 48 (10/26/2025 - 12/19/2025)

     (Click on READ MORE for better formatting)      Hi everyone, welcome to my 41st-48th  blogs!  This is the Week 1-8 post for CST 336 Internet Programming. Similarly to CST 311 Introduction to Computer Networks, while journal entries were not required  for this particular course, I wanted to document the concepts and assignments from each week of class. If you would like to see some of these projects for yourself, this link acts as a homepage to visiting all of the projects described below! https://bevans34.github.io Week 1: HTML and CSS This week's primary focus was on learning/practicing creating a website using H yper T ext M arkup L anguage (HTML) and C ascading S tyle S heets (CSS). Highlights from this week included centering a <div>, which is probably one of the biggest memes to ever come out of web development. Labs: 1 - ePortfolio Site In this lab, I created a site hosted on GitHub Pages that features a homepage, about page,...
Read more