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.