Something of a mixed week. I was the oncall person, so got to deal with a bunch of interesting failing things. Most interesting was an alert that one of our databases was approaching 70% of its disk quota. We weren’t in a position to get more, so I ended up designing a solution which would migrate the blobs out of the database. We don’t have time to implement this right now. But we have a reviewed design, and enough time to implement it before it’s a crisis.

The main thing I was supposed to be working on was designing a migration for the metrics system I work on. As happens so often, I ended up going down a rabbit hole trying to understand the source data. Bugs were filed … but not a lot of progress was made.

I filed my first bug against Chrome! The right click menu on a mac has grown a “Exit Full Screen” menu item right where “Back” used to sit. This led to me being frustrated two-to-three times per hour as I spend of my time in full screen mode.

Stats: 14 changes submitted, 39 reviewed.


Code Review

One of the things I enjoy most at Google is code review. I don’t think anything else has improved me so much as an engineer. What I really value is that it’s an open discussion about how to make the system better, without personal prejudice. Being exposed to other people’s ideas is one of the clearest benefits of diversity: it forces you to think about another’s views and opinions.

Google’s setup for code review works well. All code must be reviewed before before it’s submitted to the codebase. You must have at least one other person read through the code. If there’s something that makes them go “huh?” it’ll come out. This is not (usually) a rubber stamping exercise. This really matters, as it means that knowledge is distributed instead of siloed.

One thing which I think is peculiar to Google is the notion of readability. This is the idea that our code should look fairly similar, no matter which project you’re on. It makes it much easier to move between teams, or jump into another teams codebase. This is enforced through the use of readability approvals, which is an incremental process where each code review must have approval from an expert in that language in addition to the regular review from your colleague.

I participate in the Go readability approvers, and it’s been a great experience. I see code from all over Google, and I help mentor folks not only in Go, but how we write Go inside Google. Sometimes it’s really trivial stuff: use a common library for creating a time.Time from microseconds. Other times it’s more structural: if you’ve designed a public API around channels, I might discuss to see if there’s a less error prone way. Often I learn quite a lot through these discussions!

Another benefit of code review is that it provides a common point for tooling. When a review is started, many tools have already triggered, starting all kinds of analyses. When I get to a review, I can immediately see that there’s an API being misused, or some configuration is incorrect. It’s far cheaper to correct these issues before the code is submitted.

Statistics: I’ve reviewed over 15,000 changes at Google.

Anyway, reviews are one of the most enjoyable parts of my job. I get to learn, as do the people I’m working with. And it’s over of the quickest ways to help unblock my colleagues.