Hacker News Reader

Comment by tmhedberg | Hacker News Reader

It's common at Google to have a few projects cooking that you move between. One reason for this (though I doubt it's the sole reason) probably has to do with the mandatory peer review process for all code, which can cause delays in getting your code submitted if your reviewer's schedule doesn't line up well with your own. Instead of introducing a bubble into your pipeline when that happens, it's nice to have a side project you can hack on for a little while until you get your code review feedback.

View on HN

How are deadlines managed in that environment? Sprint ends or release dates or just "we will do it by Tuesday" all conspire against peer review delays.

Is the frustration level a constant problem if reviews can take ... X longer than thought?

Well, you can always assign a different reviewer if your initial choice is taking too long. I usually try to check with my teammates to see who has time for a review before sending them my code, at least if it's something that I want to get submitted quickly. That ensures that I pick someone who will look at it sooner rather than later. Sometimes the specifics of the process require someone who is not on your immediate team to give their approval, in which case delays are more likely.

I'm an SRE, which means most of the code I write isn't directly user-facing, and thus isn't normally subject to hard external launch deadlines. That means I'm rarely rushing to push my changes through on a tight schedule. If there's a production emergency and I need to make an urgent change to avoid or mitigate an outage, there are escape hatches at our disposal to temporarily circumvent the code review system when no one is immediately available to do a review, but the need for that is pretty infrequent.

I rarely find it frustrating. On the contrary, I really appreciate Google's emphasis on code quality, even though it does come at the cost of some agility. I used to work at a company where the implementation of code reviews was generally resisted, and though we did get new code out the door faster, we ended up with some real maintenance nightmares as a result.

Artificial deadlines are not compatible with quality assurance, so the solution is... drop the artificial deadlines.

Yes :-) agreed!

You can self-review. That's how people solve the problem.

You mean TBR? It's never been more than an emergency thing where I used to work. I'd be curious to know which part of Google you are/were in.

No, not TBR. I was referring to the fact that you can +2 your own CL, which allows it to be merged. Officially this is an "emergency" feature, as you say, but a dirty secret is that it's used routinely. I encountered it in both Android and Chrome.

I've seen lots of self-+2s under the following circumstances:

1. You are the only engineer on your team, or all other engineers on your team are out for an extended period of time.

2. All other engineers have very different skillsets, and are not capable of doing effective review. Think Rails engineer attempting to review a touchpad firmware fix.

3. You have a hard deadline (e.g. product demo or factory build) and you're desperately trying to get as much working as you can. You may even be in a location where coordination is difficult and Internet access is poor.

For SWEs working on, say, web services, you probably have at least a medium-sized team (4+ engineers) and a week's slip is no big deal. But not all software is like that at Google.

I'm not actually sure this works in... well, not Android and Chrome. I can TBR, but as far as I know I can't self-LGTM (and certainly not self-Approve).

Why not start working on the next feature while the previous one is in review?

Reply on news.ycombinator.com