Not gonna lie, I've had the PR issue before.

The solution? Blast the PR into your shared slack noting that it isn't being reviewed on time because maybe XYZ person is busy.

Watch how fast they are suddenly free to review when their name is attached to something in public.

The real solution is to simply fire these people. There is no good excuse for ignoring requests repeatedly besides laziness or self importance.

▲

starky 4 hours ago | parent | next [-]

>There is no good excuse for ignoring requests repeatedly besides laziness or self importance.

Not necessarily, there are also plenty of cases where a person's KPIs don't match their responsibilities or the actual needs of the team. This is frequently a management problem where resources haven't been properly assigned and the employee will always prioritize what they are evaluated on to minimize friction. Far too often managers collect responsibilities for their team (or are told to take on something), yet have zero plans other than "it will work itself out" and they don't bother to formalize how the requests will be dealt with.

There are certainly a lot of people out there that refuse to do their jobs, but it is common enough that there is something else wrong that a discussion with the manager about where the process is failing is the first step.

▲

dpark 4 hours ago | parent | prev | next [-]

It’s not necessarily laziness. They just don’t care about your request. “This thing you’re asking for is not important compared to the other things I need do.”

I used to run build call and this was the bane of my existence. People who just never engage (but pretend they are to get you to go away).

	▲	radiator 28 minutes ago \| parent [-]
		what is "build call"?

▲

nradov an hour ago | parent | prev | next [-]

Dogbert: "I can only please one person per day. Today is not your day. Tomorrow isn't looking good, either."

▲

locknitpicker 4 hours ago | parent | prev [-]

> The real solution is to simply fire these people.

I don't think that firing people is an intelligent solution to a problem that boils down to your personal inconvenience.

If you posted a PR and it's awaiting review, it is no longer your problem. You are literally blocked by others. Who knows what they are dealing with? Perhaps they have higher priority items than reviewing your work? I mean, would you stop making this complain after they review your 3rd or 30th PR? Everyone around you also has work to do.

If PR reviews are slow, escalate the issue with your manager.

▲

Jcampuzano2 4 hours ago | parent | next [-]

This is why I said "repeatedly" i.e. a pattern has already emerged.

And in most companies I've worked at you are the one being held responsible for a PR/feature not being merged or finished on time - at least in my experience. You're often working on a different team from the people doing reviews, so in a large enough company they are just a faceless/nameless person from the perspective of your PM.

▲

locknitpicker 2 hours ago | parent [-]

> And in most companies I've worked at you are the one being held responsible for a PR/feature not being merged or finished on time - at least in my experience. L

You are responsible for delivering tasks, but if you are blocked by the process then it's not you who is preventing the task from being delivered. Whether it's the scrum master or sdm or project manager, someone else is responsible for keeping the tasks moving. Once you mark a task as pending review, you are blocked. From that point onward all you have to do is raise awareness of reviewers to the task pending review, and raise visibility with stakeholders that your deliverable is being blocked by the review. As long as you don't slack in raising awareness, it's not your problem anymore.

	▲	tdhz77 2 hours ago \| parent [-]
		Crazy solution to fire people. Found a toxic person in waiting.

▲

dpark 4 hours ago | parent | prev [-]

> it is no longer your problem

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.

▲

locknitpicker 3 hours ago | parent [-]

> 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

It isn't. It's your scrum master's/Manager's problem, because the ticket is blocked in review.

In the meantime you moved on to another task. Because the review is not your problem.

▲

dpark 3 hours ago | parent [-]

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.

▲

locknitpicker 2 hours ago | parent | next [-]

> 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.

	▲	dpark an hour ago \| parent [-]
		> no wonder they refuse working with you. Weird and abrasive assumption you make. > 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.

▲

watwut 41 minutes ago | parent | prev [-]

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.

▲

dpark 31 minutes ago | parent [-]

I didn’t say anything about firing people.

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.

	▲	radiator 21 minutes ago \| parent [-]
		> Much of the time the person I’m waiting on doesn’t report to my manager anyway But there exists a manager who is the nearest common ancestor of your and their manager.