Live data from Hacker News

A study of Google's code review tooling (Critique)

engineercodex.substack.com

121–130 of 302 posts

Re: A study of Google's code review tooling (Critique)

#121

I’m always surprised to see the totality of support for this workflow. My biggest gripes were: - Owners - Readability review (or really the 18month queue to get Java/python readability) Although seemingly innocuous, this made maintaining internal libraries very challenging. There was no way to update every call site of your library in an efficient way. Tools like Rosie were added on top so that you could shard your P…

Owners and readability are constraints of the version control system, not the code review system.

Now, finding somebody with authority to approve is a constraint of code review. But that would be true of any code review tool. So it's not really fair to complain about.

Re: A study of Google's code review tooling (Critique)

#122

Earlier quoted context omitted.

This kind of greedy optimization approach is fine if all you’re just trying to maximize velocity, but it starts showing cracks on a long enough timeline in sufficiently large or complex projects. Speed without alignment on direction leads to ugly, tangled messes. As with most quality issues, the key is to try and surface quality problems as early as possible. Finding a bug in prod is worse than finding it in PR is wo…

Long-term project health rests on bigger things like API design, database choices, or service layout.

Hopefully these are in-scope when it comes to accepting or rejecting PRs and are not just considered incidental to whatever the stated purpose of the PR is. What you listed appears to be more fundamental system design concerns so hopefully they are candidates for further review.

Re: A study of Google's code review tooling (Critique)

#123

I’m always surprised to see the totality of support for this workflow. My biggest gripes were: - Owners - Readability review (or really the 18month queue to get Java/python readability) Although seemingly innocuous, this made maintaining internal libraries very challenging. There was no way to update every call site of your library in an efficient way. Tools like Rosie were added on top so that you could shard your P…

OWNERS always made sense to me, but the readability stuff at Google I found just... pointless productivity destroyer. I can't understand why they've kept it. In fact they made it far far worse with the incremental process.

With the crazy interview process, the copious static analysis and formatting tools and style guides + style enforcement tools, and with OWNERS and team members reviewing things... what is even the point? What are they actually checking for?

Back when I started there, I got my C++ readability quite easily with just a month wait or so. Then I briefly worked with a bit of Go, and encountered my first taste of the incremental process, and it.. sucked. When they rolled out incremental readability, I never bothered with any other languages.

Luckily, later, I ended up working in the Chromium tree which required no such readability status.

Re: A study of Google's code review tooling (Critique)

#124
post #9

Satisfaction with Critique among Xooglers is undoubtedly driven by dissatisfaction with GitHub PR reviews. GitHub reviews are astonishingly bad. The tool is utterly useless for actual reviews. After the first round of comments it becomes total chaos. Nobody can tell what's been said, done, changed, or resolved. It is impossible to believe that the people who write and maintain the GitHub PR tools have themselves ever…

Agree with this. GitHub was good at some point, then Gitlab caught up and now Gitlab has been superior in code review experience for few years at least.

Comparing between MR/PR versions, meta commands in MR templates, and so on.

Re: A study of Google's code review tooling (Critique)

#125

Earlier quoted context omitted.

I like your thought process here, but let me propose an alternative. I’m going to assume that we’re talking about Senior->Senior level reviews here. Junior engineers should obviously always get more guidance. But for Seniors, the alternative is: Be extremely picky for PRs from new hires, so that they do things the way that your company does them. Make sure they put files in the right places, and adhere to the “flow”…

> Be extremely picky for PRs from new hires, so that they do things the way that your company does them. I think the word you are looking for is "hazing": > haze (v): force (a new or potential recruit to the military or a university fraternity) to perform strenuous, humiliating, or dangerous tasks. I had this at my current job. I almost quit because it was downright humiliating to get called an "idiot" in so many nic…

They are not suggesting hazing. I don't doubt that you experienced hazing. Being vigilant with new hires to assure assignment on code quality and design is not hazing though.

If someone has legitimate concerns about the design decisions made, then they should voice them. However if they are refusing to adhere to guidelines, simply because they dislike the approach then that's being overly problematic.

Re: A study of Google's code review tooling (Critique)

#126
post #98

Earlier quoted context omitted.

> A PR is waaaaay too late to bring up No. That’s literally the point of a review.

No, it's not and there is a ton of literature (even entire books) written on why it isn't the time to bring this up during a review. For starters, it results in a waste of time for literally everyone involved: 1. The person writing has to rewrite it (probably). 2. The reviewer could have sat down with the person before a single line of code was written. 3. Anyone else reviewing just wasted their time because it will…

The alternative is a big design upfront?

Re: A study of Google's code review tooling (Critique)

#127
post #5

Critique is nice but the ML suggested edits are a waste of attention and cant be disabled.

What's the current miss-rate on them? In principle, it seems brilliant, but I can see that value dropping off a cliff if more than half of them are worthless.

Pretty low it seems. Occasionally I get obviously bad suggestions that are easy to ignore.

Re: A study of Google's code review tooling (Critique)

#128
The biggest part of a smooth code review process are the human behaviors and best practices. There are a half dozen code review tools that work just fine. Both the submitter and reviewers have important roles which make the process work smoothly: small reviews, 80% of reviews should just be "LGTM", avoid nitpicking, code reviews have higher priority than your own development, etc.. Really, if you have good code development guidelines, and good developers, that solves most of the review issues. The high order bit is knowing that every piece of code will be reviewed. Any good programmer who knows their code will be reviewed avoids doing bad stuff.

Re: A study of Google's code review tooling (Critique)

#129
Yes, Critique (and Gerritt) is a good tool. Yes, Googlers tend to behave well in code reviews and conduct them decently, but..

The reality is that this kind of survey is a) self-selecting for the people who adapted well to Google's process, and b) not really measuring for productivity, just satisfaction with tools and some aspects of the (assumed given) process.

What I personally found is that Google is the kind of place where you can only truly be productive if you have the kind of brain that can fork off N work tasks at once and then fork/join on all of them.

If you're the kind of person that does better when going down the whole mineshaft on one problem at a time, you'll be screwed. Because you'll be constantly spending the bulk of your time sitting waiting for review approvals, or getting your account added into some ACL somewhere, or getting sign-off on a PRD or design doc, launch / security approval, or some other form of coworker approval. The only way to make progress is to do a bunch of those kinds of things at once and juggle between them.

After 10 years of battling it, I realized it's not for me, no matter the $$.

(There are some other things that Google does exceptionally smartly, though. The monorepo and the way they handle third party deps [check them in and only allow 1 version for whole company]) I think is one. Both of these things seem crazy at first, but they are amazing at minimizing whole classes of complexity around versioning and dependencies that add mostly needless overhead to the job of engineers)

Re: A study of Google's code review tooling (Critique)

#130

> Developers need to make progress; overly difficult reviews can discourage future improvements. This, to me, is the most important aspect of code review: get out of the way . If you are putting in nit picks, asking for changes that aren't related to a bug or bad architecture choice, etc, then get out of the way. If you are holding up the approval because you want someone to rewrite the code the way you would have wr…

The other side of this coin is without QA, there is no app.

Sure, technically, it can be thrown out the door, and often is, in just this form, but it's a shit-tastic mess without QA time and the users are getting real tired of half-assed garbage that cost twice what the prior package cost.

Post reply on HN