Many PullRequest code reviewers have experience at big tech companies, like Facebook, Amazon, or Netflix. The following Q&A with one of our reviewers describes their path to getting their certification to review code at Google called "code readability."
Our team didn't have a reviewer with readability, so we always needed to ask other teams to review the code on our behalf. As a hard requirement, this blocked us from pushing changes and hurt overall velocity.
To solve the bottleneck, our tech lead and I started the process to get JS readability, which is like going through a sort of "code review code review."
In order to apply for JS readability, engineers submit CLs to a team of readability reviewers who go through the code with fine-tooth combs. An assigned reviewer makes comments and approves the code only after you've proven you understand Google's style guide and best practices.
I submitted an Angular component to make a calendar for an internal tool. It came back with red ink all over the place. Every little thing from how many spaces need to be above constants, to removing extra spaces in these function declarations.
Unlike a traditional code review, the readability process is the one time where the assigned readability reviewer holds nothing back. Every single minor thing that could possibly be pointed out, will be. But in the end, going through the readability process made me a better programmer and code reviewer.
What's right for Google doesn't necessarily mean it's right for every team. I learned a great deal about the code review process and why readable code is so critical through my path to JS readability. I keep the spirit of these lessons learned in mind when I review code for other teams, and focus on being positive and as constructive as possible.