[jl2718]

I think it helps if a team considers everything to be temporary, and code reviews are more for understanding how things work, with some some captured discussion of how it could be re-done. The author should merge, declare victory, and move on, while someone else re-writes it to their liking. It shouldn’t be considered done until it’s been re-done twice by separate authors.

One thing I’ve realized about software “engineering” is that it’s layered thick with opinions. If you force your opinions on someone, they check out and you get nothing of value from them. It’s probably better just to let them do things their way, and find the place where they can add the most. Some architects think their job is to walk around the beach kicking sand castles.

[Fronzie]

Especially for non-production code, setting the bar to 'is it a net improvement?' makes code review quite a bit shorter. When it has become 'is it perfect?' then nothing gets done anymore. For re-factorings, do one kind of small change but do it over the whole code-base.