> Pair programming for integrations or maintenance might be ok, but for new projects that is like having multiple people write a novel. Not only will it be pulled in many directions, it may eliminate some great innovations. Usually one person in the pair also has more influence politically in the company so they get their way.
This feels pretty relatable and sometimes also extends to code review, when another developer essentially goes: "Hmm, i don't like this for subjective reasons, you should rewrite it to be different." even in situations where doing so would have no tangible benefits and the only thing that ends up happening is the development velocity being ruined.
I think that sort of problem would manifest itself both in pair/mob programming, architecture discussions, sprint planning as well as code review, it's not like you can easily avoid it altogether, unless you avoid the people in question entirely or provide pushback against nitpicking and bikeshedding, which may or may not be viable.
> 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.
This feels pretty relatable and sometimes also extends to code review, when another developer essentially goes: "Hmm, i don't like this for subjective reasons, you should rewrite it to be different." even in situations where doing so would have no tangible benefits and the only thing that ends up happening is the development velocity being ruined.
I think that sort of problem would manifest itself both in pair/mob programming, architecture discussions, sprint planning as well as code review, it's not like you can easily avoid it altogether, unless you avoid the people in question entirely or provide pushback against nitpicking and bikeshedding, which may or may not be viable.