I also think reviewers shouldn't have a freeform textbox to leave comments in. I think feedback items should be something like a dropdown. The goal is to remove opinion and bias as much as possible. Style, linting, etc should all be automated.
> When folks defend nits, I suspect they are actually defending “non-blocking” comments - including educational remarks, context sharing, suggestions, aspirations, and more. Poor definitions from Google’s otherwise excellent style guide muddles two orthogonal ideas: non-blocking comments, and trivial preference-based requests. The former is a healthy means of communication between engineers writing code. The latter is an inconsistent inefficiency.
* Time Consumption: Reviews can slow down development.
* Inconsistent Standards: Varying coding standards among team members.
* Nitpicking: Overemphasis on minor details.
* Lack of Constructive Feedback: Comments may lack guidance for improvement.
* Knowledge Gaps: Reviewers might not fully understand the context or technology.
* Ego Clashes: Personal biases or ego can affect the review process.
* Blocking Progress: Waiting for reviews can delay other tasks. Lack of Recognition: Feeling that efforts in code quality are undervalued.
* Tool Limitations: Frustration with the limitations or inefficiencies of review tools.
* Overwhelming Backlog: Large volumes of code to review can be daunting.
I don't get this. Yes, the development seems faster _without_ a code review. But the issues that you miss, the quality that could be increased will bite you back tenfolds later on. So why is that "slow down" such a big issue?