While I do not know your exact situation, I find such attitude a bit selfish. Yes, you've got other shit to do, but guess what, writing good code is part of the

While I do not know your exact situation, I find such attitude a bit selfish. Yes, you've got other shit to do, but guess what, writing good code is part of the shit to be done. I consider working code being a minimum standard. Code can be working but can still be bad. On top of correctness it should be easy to read and modify. And by telling your team go modify if themselves if they don't like it, you're kind of saying "if you expect me to do more than minimum, do it yourself". Again, it varies from team to team and you might have colleagues who focus on meaningless details instead of the essence. What I try to do in my teams is to encourage people to go together through changes suggested by the reviewer. If the sides agree that one version is objectively better than the other, go with that version. If there's no agreement or if the difference is too marginal, the author of the code makes the call. Also for me the review has easy "done" definition. It ends either in "code approved" or "changes requested" state. The first one leads to merge, the other one to further work or discussion on the code.