> That's why code review process must have a guidebook with a rule "it's on the reviewer to show why the suggested change has a tangible benefit".
Agreed, yet you're implying that:
- there must be a guidebook in the first place
- that it must actively be followed
Sadly, that is not the case in many environments, where disagreeing with another developer might actually make you waste more time discussing (or rather) arguing things back and forth, rather than just doing the changes that they want.
It's unfortunate people are mostly conditioned to not oppose: whether to get branches landed faster, or simply because of the imposter syndrome, but some of us who are good at opposing and saying no sometimes struggle to find the right balance.
My goal when reviewing is to help others learn something new, which is why I'll sometimes share a personal, subjective preference for an approach (with "subjective" meaning that there are pros and cons to either approach with neither being better in every circumstance, especially in a legacy codebase like they all are).
I am trying to walk the fine line between teaching someone something potentially new, and not dumping on their velocity or self-confidence. I love it when people acknowledge the idea and say "nope", yet I understand that many won't do that, so most of the time, I stop myself from even sharing my subjective preference.
Outside of character, it requires building trust between people and not being out there to "prove your mettle", but to build stuff together. And with so much churn in jobs and remote work (I haven't met my new coworkers of 6 months yet, and I haven't met half the previous team either), that's sometimes hard.
That's why code review process must have a guidebook with a rule "it's on the reviewer to show why the suggested change has a tangible benefit".