[T_Potato]

I have a tangent question: How do you deal with a team that spends days nitpicking implementation, double-speak and saying. I didn't actually expect you to implement this the way I said, I was just saying it would be nice if it was like this, can you undo it. I spend 3 weeks on a code review because of the constant back and forth; and I wish oh I wish they would allow PR to be small but the rule is that the PR has to implement the full deliverable feature. And that can mean 20 files to constantly change and change and change and change. Oh and then the why did you use Lombok question that occurs even though the project uses lombok and so you are stuck defending the use of a library that's is used in the project for no random reason than to flatter the egos of the gatekeepers who say, yes this is good but I want you to name this abc instead of ab before we merge. When in context it doesn't add or remove any value, not even clarity.

[tjansen]

Generally, my stance is that I add more value by doing whatever ridiculous thing people ask me to change than waste my time arguing about it. There are some obvious exceptions, like when the suggestions don't work or make the codebase significantly worse. But other than that, I do whatever people suggest, to save my time, their time, and deliver faster. And often, once you're done with their initial suggestions, people just approve.

This doesn't help all the time. There are those people who still keep finding things they want you to change a week after they first reviewed the code. I try to avoid including them in the code review. The alternative is to talk to your manager about making some rules, like giving reviewers only a day or two to review new code. It's easy to argue for that because those late comments really hinder productivity.

[dbetteridge]

Doesn't help you much I imagine, but the one time we had a dev like this he was fired after multiple complaints to the team lead.