Developers July 3, 2020

Is this even a problem for devs?

Vladyslav @vladyslav

Hello, indie hackers!

I wonder if someone had a problem working with a big amount of pull requests in a big team. At my current project, I have to review from 10 to 15 PRs per day and sometimes it's hard to track the status of PR, who is author, what is the target branch, etc. My assumption that it's more like a UI/UX issue of GitHub/Bitbucket IMHO. Also in the future, I need some kind of pull request analytics based on different categories, timelines, and more.

  1. Have you encountered such a problem?
  2. Would you use an app/service which solves this problem?
  1. 2

    That sounds like a management problem. Either you're a bottleneck and should be empowered to delegate or you need better guidance on which code reviews are actually part of your job.

    I was in a similar situation a few years back. The problem was that something like thirty of us were all on the distribution. When I pointed out how much of my day this was taking up, I was told that the policy was that only two people needed to review any given commit and, really, a manager's review was both required and carried the weight of both reviewers. So, that took the pressure off of me, but pointed out the bigger problem that they had, in that we needed to wait for one of the team leads to do the work.

    So, if the "app" is a giant cartoon mallet for hitting the people that come up with these policies, I'd probably use it, but...

  2. 1

    I don't know if you can do this, but I would suggest you try out pair programming at this point.

    If everyone can review PRs, you'll always have two people going over the same code. So instead of waiting for a feature to be done and then review it, you can have people pair and build something together. This tends to lead to better code, and the review is already done since two people did the code.

    Of course, this only works if everyone can pair with everyone. If only one or two people in the organization are trusted enough to review code, pair programming doesn't make sense.

    Hope this helps :)

  3. 1

    This is something that is provided by your vcs provider. GitHub and Bitcuket has third party extensions to address these issues. gitlab has a great dashboard to begin with so I don’t think you need anything there.

  4. 1

    10 to 15 PRs per day? How many people are in your team? How many people do they make per day? Are you the sole reviewer? Most of the time I've seen about 1or 2 PRs per person per day and 1 or 2 required reviewer per PR. As an active member of a product team, that leads to about 5PRs per day per person, and yes you could speed the review up, but then static code analysis is probably more useful, than improving the UI IMO.

    On another point though, as a previous Head of Eng who had to oversee over 10 product teams (so about 50 engineers), it sometimes become difficult to have a good oversight of what people are doing. Some of the use-cases might be:

    • You want to review one person's contributions, so you will check this person's PR
    • You spend some time on one particular product, so you're having to review all their PRs for a limited time duration (lots of context switching...)

    Looking at some improvements, I think GH's usage has been democratised, there are many more roles involved around it. MS having purchased GH also brings in more enterprise customers, so you keep having larger clients hosting their products on top of GH. There might be an underserved user-base there: Engineering managers, security consultants, department leads. Thinking about it now, 15 PRs to review per day sounds like principal engineer role, where your approval is needed across a wide range or products. Could also be some agency work with lots of external contributors I guess.

Recommended Posts