

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

I&#x27;m working with a team that has around 20 engineers and we&#x27;re running into a problem getting engineers to look at pull requests. We&#x27;ve got 24 open right now and it&#x27;s been like that for a week.
What kind of things do you do to encourage people to look at pull requests?
======
skylark
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
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
+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
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!

