I’ve been pondering good code reviews and the amount of time spent on such reviews and adjusting the code. While no reviews are definitely an anti-pattern, an overemphasis on having perfect code is as bad of an antipattern.
When making review comments for optional, nice to maybe do in my opinion things consider the following:
Is this really worth doing? An example of this is some new ruby syntax versus the standard syntax. Just making what’s easy to read in 3 lines as 1 line.
How much would a change to some code improve readability for the new developer (and, not the developer familiar with 1,000 obscure gems)?
Will changing this code really work toward our critical company objective of shipping software more quickly?
When making a review, if you feel compelled to offer opinions, please prefix them with IMHO: or FYI:.
Also, based on many years of experience with many commercial projects, code that is obsessively too perfect is as much of an anti-pattern for commercial success as code that is a little messy.
In fact, code that’s messy is often, though not always, correlated with a fast growing business that needs to respond to customer needs quickly.
Our most important goal is to be a learning machine and that means shipping effective code more efficiently and learning how our users respond to what we ship.