January 26, 2019
Readability is a system internal at Google that I brought over to Jet for great effect. It’s a system for ensuring that code quality stays high and consistent with standards, while simultaneously maintaining effective business decisions and encouraging tech excellence.
Readability is a badge that a developer earns for excellence in code quality, attention to detail, and attention to code review. In the system, all pull requests must have at least one approval by a developer with Readability, in effect making Readability a bottleneck on code approval.
You may be thinking: why would I ever want a bottleneck on code approval? There are a few reasons why this has historically worked:
Those with readability have the responsibility to block pull requests if it doesn’t abide by guidelines or if it isn’t written correctly, with no exceptions.
It’s important to note that Readability is not a measure of who the “best” developers are. Engineers with readability are those who have proven themselves to be thoughtful and thorough, and to have a great grasp of your code standards. In an ideal world, everyone on the team will have Readability, though realistically that is unlikely.
The requirements for Readability that make sense for you will differ from team to team. For example, at Google it’s based on language proficiency. Below are the qualifications I use at Jet:
Likewise to requirements, the process for achieving Readability will differ from team to team. For example, at Google it’s a written test. Below are the qualifications I use at Jet:
I also recommend that you have a required “check in” with a mentor about intended applications and a discussion about code sense. This helps prevent people going for Readability on a whim, and it removes the potential for a failed Readability presentation (for example, scope is too small, developer doesn’t really have the skills in place yet, etc) — if it’s already approved by the right people, the rest is just a presentation to spread the information through the team.