4 ms·

Ask HN: What do you dislike about code reviews?

fosterfriends 3y ago
eg: * 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.
simulosius 3y ago
> Reviews can slow down development. 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?
potamic 3y ago
When probing questions are answered literally.
alex_lav 3y ago
So much. I think most engineers aren't really equipped with the behavioral skills to conduct code review in a healthy way, and I think the industry just turns a blind eye to terrible/unproductive behavior being a core part of the development process. The prevalence of comments starting with "Nit" is a good example. Never leave a nit. 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.
- fosterfriends 3y ago
  I feel you. If you want to hear my write-up against nits... https://graphite.dev/blog/what-are-nits https://graphite.dev/blog/what-are-nits > 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.

eg: * 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.

simulosius 3y ago

> Reviews can slow down development. 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?

potamic 3y ago

When probing questions are answered literally.

alex_lav 3y ago

So much. I think most engineers aren't really equipped with the behavioral skills to conduct code review in a healthy way, and I think the industry just turns a blind eye to terrible/unproductive behavior being a core part of the development process. The prevalence of comments starting with "Nit" is a good example. Never leave a nit. 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.

fosterfriends 3y ago
I feel you. If you want to hear my write-up against nits... https://graphite.dev/blog/what-are-nits https://graphite.dev/blog/what-are-nits > 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.