If I told my manager it was his problem to get my code reviewed, he would tell me to do my job.
Offloading responsibility for getting code through review to a manager or scrum master sounds at least as dysfunctional as people avoiding doing the reviews.
> If I told my manager it was his problem to get my code reviewed, he would tell me to do my job.
If that's how you interact with your team members, no wonder they refuse working with you.
What any competent developer does is a) update ticket to move it to review, b) call out the PR in whatever system you guys use, c) after a reasonable amount or time inform your scrum master/manager that your task is code-complete and is blocked by the review, d) update ticket with a notice that PR is still pending review. Go back to step b) and repeat until the PR is merged.
Done.
Updating the ticket and making a best effort to get the ticket moving is all that's expected from you. By design. That's how things are supposed to work. If your manager doesn't care, it's nothing they want to push anyway, as proven by the ticket history.
> Updating the ticket and making a best effort to get the ticket moving is all that's expected from you.
I have never worked somewhere that ran things as you describe. But then everywhere I’ve ever worked has expected a high level of personal responsibility, not “best effort” that consists of a one time Slack
message and tagging work as blocked.
This may be small nuclear team vs sprawling org difference.
This process works so well in a team that are all pushing together.
Moving the ticket along and a slack to the effect of "this one is quick and easy" Vs "this one's a bit gnarly, happy to jump on it with someone" generally sees PRs reviewed very quickly.
A pleading cat gif is usually enough as a reminder.
A well oiled team is working to deliver customer value (internal or external). I've been lucky enough to have had a few teams of incredibly good engineers over the years. So much gets done.
I can see it not working so well in a team of "individuals" focused on their own performance and "personal responsibility" solely for their bit.
The kind of teams that throw everything over the wall to an individual making a build gate go/no-go decision perhaps.
> This may be small nuclear team vs sprawling org difference.
This is very likely a big part of the difference. Most of my career has been spent at very large companies. Smaller teams that can manage to be more inwardly focused with fewer cross, team dependencies, can doubtless operate differently.
> The kind of teams that throw everything over the wall to an individual making a build gate go/no-go decision perhaps.
That’s not really what I described. I ran the process, not the fundamental go/no go decision, which was a distributed responsibility. That was the exact friction, and it’s very similar to the code review friction in large organizations. A PR author has a responsibility for their PR but it may require sign off from numerous other teams.
Some of this is necessary complexity that arises from large teams building large products. Some of it is certainly dysfunction.
When a small team sits close to each other, you can simply say: "hey guys, anyone got time to check my PR?".
In a gigantic org, you can message them on Teams, but everyone keeps getting messages on Teams constantly so they are probably going to ignore you for an hour.
Dude, you're the one talking about talking down to people telling them they are not doing their job. Relax.
> I have never worked somewhere that ran things as you describe.
What do you think a PR reviews process is? It is literally "I will be prevented from merging my work so that all of you may have a say on what I'm doing".
This is precisely how and why it is designed to work.
In basic scrum, you know that part where the scrum master asks in daily meeting whether people are blocked? What do you think it is used for?
Pray tell, what do you think a PR is used for, and how does the process work?
> The place I currently work at operates quite differently.
If your place of work had no one responsible for setting work priorities of managing task delivery and then find yourself blocked by mundane things like a PR then it seems you are developing novel ways of being dysfunctional. Perhaps you PR process is indeed not the problem but a symptom.
It's pretty rare that I get blocked on something mundane like a PR, but if I do I just tend to message a colleague something along the lines of, "hey, can you please take a look at X when you next have a moment? blocking me for Y" and that resolves the issue promptly.
TBH I think micromanaging inter-team communication by turning it into a process that requires a responsible individual to run is far more dysfunctional.
It is managers responsibility to set priorities including those of other team members. Including priorities of code review. That is not offloading. It is also considerably less toxic then "I demand people to be fired because my code review was not done in 12 hours".
Your PR is not the importantest thing being worked on.
What I said is it’s not my manager’s job to wrangle people to do code reviews for me. It’s absurd that the immediate response to friction is to offload it to someone else. Certainly if there is a cultural problem, or misaligned priorities, discuss the general issue with your manager. But “I set the ticket to blocked so I’m done” is not an acceptable process anywhere I’ve ever worked.
Much of the time the person I’m waiting on doesn’t report to my manager anyway. My manager can’t change their priorities any more than I can.
This doesn’t change much though. If there is a general problem, it’s likely appropriate to pull in management to figure out the issue. But it’s probably not a management problem that my specific PR needs a review.
It's literally the most management problem imaginable.
Management decides the process, management decides who to hire, management assigns the roles and management decides how urgent the work is.
If the constellation is so that reviews are required, but the reviewer is not under the control by the manager and reviews do not happen, then some manager somewhere made a mistake.
Why? Because PRs are expected to be reviewed. Any process in which that does not work automatically is dysfunctional and needs to be fixed until PRs are being reviewed properly again.
If everything is working as intended, but it's the manager who created a false sense of urgency and pushed all of the responsibility onto the person who cannot do anything about that, then the only person who can fix the problem is the manager and the thing he has to do is something very easy: be more patient.
Edit: It might not be obvious, but all the things you claim that strengthen your position are already table stakes and assumed to happen regardless. The question is, who is responsible for making the invisible and automatic happen? And you're saying the manager can shirk his responsibility onto the blocked employee, which is hilarious because it means your entire operational strategy for fixing a broken process relies purely on being lucky.
Another thing that might not be obvious but if you write a bad pull request and the reviewer tells you it is bad and can't be merged that's on you as well, no shit Sherlock.
> What I said is it’s not my manager’s job to wrangle people to do code reviews for me.
I'm sorry to say, but it is. Is your manager responsible for managing workloads, task assignments, and priorities?
> It’s absurd that the immediate response to friction is to offload it to someone else.
That doesn't sound right. A PR review literally requires you to dump your workload onto someone else. Often times a PR requires significant amounts of time to review. Your team members need to set aside significant amounts of time out of their schedule to look at your work.
You cannot frame a problem that fundamentally revolves around dumping work onto someone else as being absurd to dump your work onto someone else. I mean, what do you think happens when you ask someone to review your work? Do you expect your team members to blindly sign off?
It's obviously about offloading work. And it's the Manager's job ro set those priorities.
It sounds way more dysfunctional to start doing the managers job to me.
If you think it is your responsibility to get a reviewer on the other side to prioritise reviewing your work then you basically made yourself responsible for hiring and firing people or reassigning their project responsibilities.
By the time you managed to have your review get through you might not even be a developer anymore.
This is absolutely not true. If I can’t check in a fix or a feature because someone else isn’t doing the review, it’s definitely still my problem.