I agree that sometimes people can be too focused on perfection in code reviews but consistency, modularity, and other seemingly unimportant things are crucial in maintaining hygiene for your project
Does it merely sound like non-engineer talk, or is it actually non-engineer talk? I just want to make sure you aren't making the wrong assumption or implying the wrong thing. I've been saying what I've been saying as a result of my 5+ years experience doing full-time software engineering.
> I agree that sometimes people can be too focused on perfection in code reviews but consistency, modularity, and other seemingly unimportant things are crucial in maintaining hygiene for your project
It's interesting to me how easily people here are assuming that I'm implying the absence of standards merely because I'm suggesting people opt not to chase perfection in favor of providing a non-blocking pathway for engineers to make changes or improvements. Maybe my phrasing is poor.
I don't think you and I disagree that consistency, modularity, etc., are important and should have some amount of enforcement. The point I'm trying to make is that, in my experience, people sometimes go too far with this, so there should be some set expectations as to the limits of an individual code review. Limiting the amount of review iterations in a unit of work and splitting feedback-related work into other tickets can help address the issue of perfection zealotry.
>Limiting the amount of review iterations in a unit of work
Fully agree. I think there should only be two iterations max, preferably just one.
>splitting feedback-related work into other tickets
Would never work at places I've worked. The backlog of "important tasks" is never-ending so code cleanups, optimizations, etc. never get done because there is always higher priority work. This isn't really in control of the team because even if the PM agrees to let you lose a week of productivity making the code better without adding features there's a good chance their manager, the engineering director, etc. won't like to see that. So at least in my experience you only have one shot at getting that code in a good state, with the alternative being the code slowly getting worse and worse until it gets so bad you opt for a rewrite or lengthy refactor