Hacker News Reader

Comment by ridiculous_fish | Hacker News Reader

Xoogler here, circa 2015. My reaction is that this is a very google3 (i.e. web services) centered book. But Google contains multitudes and it feels wrong to ignore them.

For example the book has a section called "How Code Review Works At Google." And it goes on to describe strictly the google3 process. But Chrome, ChromeOS, GoogleX, others have different processes. If Google has a proven model, why do so many of its projects deviate from it?

During my time there, the Android team was recruiting internally, advertising "come work on Android, we don't require Readability." It was seen as an internal competitive advantage to reject these processes! What does that say about how they are perceived internally?

I speculate that Android and Chrome and others have distinct processes for a good reason, and that the book is unknowingly slanted towards web-service style engineering.

View on HN

It was seen as an internal competitive advantage to reject these processes! What does that say about how they are perceived internally?

It certainly says something about how the Android org was perceived internally during most of the time I was there (2011-2018).

> we don't require Readability.

I assume from capitalisation and context that Readability is some very specific and very strict set of rules? I’m curious what would be there that would be so offputting...

The readability process at Google is a way to gain the ability to submit code without a language style reviewer. To submit code into google3 (their main repo for server-side stuff), a changelist requires acceptance by a person or people who collectively own all of the code being changed, and a person or people who collectively "have readability" in all of the languages in the change. The simplest example is there is some C++ code that you own and you have C++ readability. In this case you need the review of anyone. If you don't have C++ readability, you need a reviewer who does have it, and they need to carefully review your change for style.

It used to be that you had to do a "readability review" which was a large change that you developed specifically to gain readability in some language. A style reviewer would approve it after (usually) many rounds of comments, and then thereafter you had C++ readability forever.

More recently some language teams have adopted incremental readability. In this process you add a language reviewer to all of your changes, and after you demonstrate that you know what you are doing, they will grant you readability. I think the Go team was the first group to adopt incremental readability, but it spread to other languages.

This process is off-putting to people who want to join Google but not be acculturated to their language style rules. There's a surprising number of these people. In mainline Google these people simply will not get bonuses, raises, and promotions. In defective organizations like Android they just discard Google code quality standards and it shows.

The way I've described it to people is that you need to get at least one review from someone who...

- is an Owner of the code

- has Readability in the language of the code

- is not you

If you are an owner and have readability, you just need someone who isn't you to sign off on it. If you don't have ownership or readability you need to get someone who has those things to sign off. If you can find someone who has both, great. Otherwise you'll need two people.

Having readability in a language can make you pretty desirable, particularly if it's in a language that your team doesn't often use. It's hard to get, and it takes time. My team is pure Java, but once in a long while we check in Python scripts. Most people have Java readability, but I'm one of two people on the team with Python, which makes me more valuable to the team.

It's really hard to get someone who isn't on your team to give you a readability review.

Definitely. Being an SRE with C++ readability, for example, is like a permanent employment guarantee.

I'd like to acknowledge the brilliance of people who name their code files "foo.javascript" to avoid having to get JS readability.

I'd lump them into the category of people who would make production code depend on things in experimental to get around code reviews.

I’m pretty sure that will trigger reviewed-and-submitted code audits for any role that handles PII. Don’t want the HN-reading public to get the wrong impression.

Reply on news.ycombinator.com