I agree. The problem starts when this sort of friction continues after all the decision-making is done and starts manifesting as contrarian positions towards how the project is being conducted, always insisting that their idea was better, and even assuming aspects of sabotage.
It's one thing to determine a path forward, but an entirely different thing to assume a "my way or no way" stance.
me: "ok."
(even though this will cost hundreds of productivity hours - explaining it to new devs and wondering why all your history disappeared again, sigh you shouldn't rebase on a public branch! , gah fuck it)
Yeah, sure, sounds like a great idea.
Not a problem.
Rebase is a tradeoff of handling merge conflicts with achieving a commit history that is far cleaner and audit-friendly.
The point being that some technical choices are not black and white, and people mistake baseless personal opinions with technical truths. There's an awful lot of workable grey areas with tradeoffs.
If a team member insists on pushing his personal opinions as the truth, challenges and opposes each and every proposal that does not match his personal opinion, and drags on personal vendettas in decisions that didn't went their way... I'd say that no matter where their tech skills are, that person is still incompetent and a liability in any team.
- Great idea
- Makes total sense
- That's how I would do it
- I agree
And this is not a joke.