> 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 6 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 5 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 4 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 3 hours 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 3 hours 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 3 hours 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 2 hours 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.