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

▲

8note 14 minutes ago | parent | next [-]

you are describing a work cultural issue - putting merges on the person that is writing, as a personal failing of people focusing on getting their own code merged, and probably having similar difficulty with that.

why are you working on teams where you are always touching somebody else's code without also making friends with them?

▲

locknitpicker 3 hours ago | parent | prev [-]

> 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 4 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 4 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 3 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 2 hours 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 an hour 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 an hour 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 an hour 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.

	▲	dpark 10 minutes ago \| parent [-]
		Sometimes that’s the CEO, but sure. 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.