Hacker News Reader

Comment by teeray | Hacker News Reader

> You should review PRs, you should review them in a timely fashion. You should, you should, you should. That’s all Push. Any wonder that so many teams struggling with PR dwell time?

The problem with this is nobody is performance managed on PR reviews. Features are often what get put on performance reviews, so it becomes beneficial to the PR author to go work on another feature than review someone else’s PR. Reviewing a PR for a feature doesn’t get your name attached to it. More often than not, your review is considered a formality imposed by upper management and impediment to the feature in the eyes of line managers. Those headwinds turn PRs into a classic Volunteer’s Dilemma [0].

[0] https://en.wikipedia.org/wiki/Volunteer's_dilemma

View on HN

I spend a disproportionate amount of time on PRs at $client and recently got dinged for not performing “enough” so I stopped reviewing PRs.

PRs have dwell times of weeks. It’s all broken, but somehow we are all convinced that this is better than a formalised change review process.

Never mind the inability to plan work, or having to have yet another discussion with some corporate random that happens to be reviewing your PR and has a thousand questions as to why this particular functionality needs to be implemented, and why weren’t they consulted - dude, here is all the process documentation, go complain at management, not me.

But in the meantime, management wants to know why x was not delivered on time.

Teamwork takes time. I think a lot of people do not understand that.

As soon as we get above two or three tightly knit people internal communication starts to become the bottleneck. It's inherently serialized. It's the human equivalent of Amdahl's law.

Never has it been more clear than when remote work took over in organization that are not built on it from the start. While we all feel more productive without office chit chat it all has to be compensated somehow if we're going to be aligned with common goals.

Perhaps we need to dedicate 25% work time to PR's. It's just half of what pair programming is and plenty of people are productive doing that.

eng-practices has a page about speedy reviews and says that reviews should happen in a day or less: https://google.github.io/eng-practices/review/reviewer/speed...

It's a pretty established practice within the Goog eng teams I've interacted with. Consistently and noticeably failing to meet the 1 day response would be minor grounds for perf mgmt, I reckon. Never would happen for just that problem by itself, but would be mentioned alongside other problems perhaps. Just providing an anecdotal counterpoint...

My company tracks PR reviews. They aren't tracked in source code (and to my knowledge source isn't used as one of the metrics).

The engineer can put forward that they spend their time on PR reviews and it's had X benefit.

So how do you quantify the difference your review makes? That cost/benefit analysis is hard to do objectively because the counterfactual outcome of deploying without review is not observed. You could model the various probabilities of failure and their expected cost, but it is arduous and hand wavy at best.

don’t companies like amazon track the number of PR comments as a metric?

Reply on news.ycombinator.com