After seeing so much noise and struggle at the past couple places I've worked regarding people having to beg and make noise about getting reviews, I half jokingly think someone should make a "begging for PR reviews as a service" startup.
A few jobs ago I put a PR in a few days into our two-week sprint. Our team of purportedly full-stack developers was actually a team of two front-end and seven back-end developers which meant that the Jira tasks were written such that tasks in the same sprint were all interdependent on one another. This always resulted in long cycle times and a mad rush to get everything merged the day before sprint review. This was a bit painful as our team lead was obsessed with Git commit history and required branches to be rebased onto the main branch, so every PR that got merged ahead of yours meant that you had to immediately jump in and rebase yours to make it eligible for review again.
The PR that I put in before everybody else's was summarily ignored because everybody was busy getting their own stuff in. I spent cram day rebasing my PR at least a half-dozen times as commits flew into the main branch. A few minutes before cut-off I asked in a team call if I could get a review; my team lead told me that there was no time and that it would have to wait.
Needless to say I've since found a team that does the opposite (reviews each others' code in a timely and constructive manner). I really enjoy working with people that care about delivering value and helping others... it's vastly improved my job satisfaction.
Agreed. In my opinion, just goes for show that you need a good team organization/culture more than another tool.
While I'm sure a lot of people will find this tool useful, I believe it will also help disfunctional teams last longer, which just means that the real problems (like, why people don't review code in timely fashion) will take longer to resolve.
As always, just my two cents based on my experience :)
The problem is that in most teams code review is considered an auxiliary task that's off the books (from a ticket tracker perspective) where as in reality it should be a ticket in its own right that someone can assign themselves to and review the associated PR.
This is a team culture thing. Prompt and professional reviews have to be valued. If you're a senior engineer (or at least senior on a code base), you can add at least as much value to the development process by giving others timely and fair feedback as you can writing your own code—it's a force multiplier.
(Edit) For big changes I've seen people schedule 30-minute review meetings. We all hate meetings but I don't think it's a bad idea.
Everyone says they value good reviews, and I think that's actually true to some extent, but 'prompt' comes at a real cost as you have to stop what you're doing to take a look.
The strategy I used for smaller changes was twice-a-day queue review; noonish and end of day. "Prompt" doesn't have to mean instant, it just means not sitting on a change for days.
Not prompt reviewing has a real cost too. If it takes a long time to get a review, the submitter loses context and has to regain it when the review comes in.
The longer the cycle, the more contexts to be juggled and the more effort to juggle them.
Also, if you are building upon the code from the prior review, and you need to shuffle things around based on feedback from the review, then your more recent work also must be redone, resulting in waste.
Exactly - and waiting for that review leaves you in this holding pattern where you'd really like to be moving the ticket along, but you kinda sorta have time to do something else.
There's just a lot going on with them. The way they pop up and you can choose to either wait or interrupt your own work to process one. If everyone waits, then the person needing the PR gets hassled by their manager that they need to "go out and get it", which means more aggressively hassling other people, which is stressful and unpleasant for everyone.
There's some kind of game theory dynamic going on where I don't think the outcome is really ideal, even if most people involved are trying to make it work.
Right, each one of us needs to finish the work before the deadline. I really don't like how we perpetuate assignments to individuals. I suppose it stems from our education system and ticket assignments but I would really like to see more teamwork built into our daily workflow.
Some people assign timeslots for reviews, but when deadline is pressing, all the timeslots go away.
The only solution that I have seen, and am happy to be a part of currently, is to have a close coworking team that's responsive. In short, it's not the tooling, it's the people.
We've actually started doing this, though it's working around the fact that I couldn't figure out how an author can send a PR back to a reviewer for another round of review so that it shows up in a queue nicely.
It's really nice. We have a kanban column 'Needs Review' and I've dumped tasks there for PRs, documents, and all kinds of other stuff.
Hmm it could work like those LinkedIn emails. Automatically send after two days, "Hey I know you're busy, aren't we all? And the last thing I want to do is give you more code to review. But you really should check out..."
