How do you get your engineers to look at pull requests?

https://news.ycombinator.com/item?id=9060740

by ajma • 11 years ago

5 4 11 years ago

news.ycombinator.com

I'm working with a team that has around 20 engineers and we're running into a problem getting engineers to look at pull requests. We've got 24 open right now and it's been like that for a week. What kind of things do you do to encourage people to look at pull requests?

skylark• 11 years ago

I feel like one contributing factor might be your company's culture or process.

I try my best to review every pull request at work, but ultimately any time I spend reviewing code is essentially time I'm spending on Hacker News as far as management is concerned. Time spent on code review can't be logged against any defects or stories, so when the metrics get printed, it looks like I'm pulling less weight than I should be. Sure, I can game the system a bit by logging time against something that I didn't actually work on, but just the fact that I'd have to be dishonest to do something means I'm less inclined to do it.

See if there are any processes in place which would disincentive developers from doing code review. Are the deadlines too tight? Is performance graded against some metric like tickets closed?

And where's your tech lead in all of this? I feel that part of the job of a good tech lead is to be a technical mentor, and that involves reading the code your team is writing.

fdr• 11 years ago

The process that works for my team (Department of Data. Heroku.) is simple:

If one expects a review with any timeliness, "@mention" the person(s) you think are qualified to review. Include the urgency of integrating the patch. The default assumption is urgency is low.

The reviewee is free to punt (if they're especially busy, or it's a case of mistaken identity as to the correct expert), but he or she is expected to fill-or-kill their intent to review in a day or so.

Some advantages:

* Not overbearing nor complicated

* Leaves room for non-urgent work

* Targeted (avoiding tragedy of the commons)

* Dynamic and nuanced (not slavish to a strict taxonomy of assignment and priority)

chrisBob• 11 years ago

+1 for the @mention idea. The biggest obstacle I usually see at work is no one taking ownership of an issue. If my boss says "someone need to do this before Friday" then I know it will never happen because no one is responsible for it.

cauterized• 11 years ago

Give two to get one. That is, if you want your code reviewed (not stuck in limbo) and there are other requests in the queue, you have to review at least two others before submitting. Should clear up your backlog right quick!

How do you get your engineers to look at pull requests?

Related Stories