Today I learned how Google facilitates (developer) knowledge sharing across their teams. Internally, Google calls this the readability process, a form of standardized mentorship through code review.
“Code-review?”, you may ask, “What’s so special about that? Don’t all successful technology companies practice code-reviews?” You are right, and Google also has these regular code-reviews. But the readability process, is different in some key ways. Here is how I understand it:
- readability reviews are mandatory for all code commits (not on the commit-level, of source, but for a set of commits)
- readability reviews are performed by qualified individuals, who are well versed in the companies’ software development guidelines and best practices
- anyone can become a qualified readability reviewer, ensuring that knowledge is shared across teams, essentially across the whole company
Anyone can become a qualified readability reviewer
To qualify, you simply need repeatedly submit your pull requests to a central group of qualified reviewers for your specific programming language. These reviewers give feedback on your code. You repeat this process, submitting your code for review, and getting feedback. At some point your submissions will have a high enough level of quality that you will formally receive a “readability reviewer certificate”. Because the reviewers from whom you have received feedback are not from a single team, but from many teams across the company, the knowledge sharing is not limited to team boundaries.
Google writes that around 1 to 2% of their engineers are qualified readability reviewers.
If you want to learn more about this process, and also read about an internal study that Google has conducted how this increases developer productivity, it is described in Chapter 3 “Knowledge Sharing” of the book Software Engineering at Google (O’Reilly 2020).