Hacker News Reader

Comment by locknitpicker | Hacker News Reader

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

View on HN

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

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.

> Weird and abrasive assumption you make.

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?

> Dude, you're the one talking about talking down to people telling them they are not doing their job. Relax.

What are you talking about? Are you confusing different commenters or are you intentionally trying to put words in my mouth?

And don’t tell people to relax when you are being actively rude. Try instead not being rude.

> What do you think a PR reviews process is?

It is not possible that you suddenly think our disagreement is about what a PR is rather who has responsibility to shepherd code through the process.

At this point I doubt your good faith so I’m out. Take care.

You're describing a specific way of working.

I've worked at places that operate the way you're describing.

The place I currently work at operates quite differently. We also ship more software, faster, and it's of higher quality.

Make of that what you will.

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

Reply on news.ycombinator.com