* code review is expected responsibility, so everyone participates in every part of it regularly, so they are also incentivized to keep the process sane
* we have an auto linter and we recommend saving on fix specifically so no one argues about useless style nits
* CR back and forth is measured in minutes or hours so you are not waiting days to resolve someone’s drive by comment
* CR feedback always has a specific action item that is easy to address
* reviewees submit smaller CRs which are quick and easy to review for reviewers
Then CRs are pretty much pointless. The feedback I want as a senior developer is the complex stuff and that is half of the time not easy to address. The trivial stuff I usually, but not always, spot myself when checking the code before sending it for a review.
This is an essential component of a productive code review culture.
* This code should be changed looks bad - not a good comment
* This code should be chabged because ten nested ternaries gets hard to read - better
* This code is hard to read because there are ten nested ternaries. Can we replace it with a helper method that returns one value using if blocks? - best, in terms of actionability
If you are doing system/algorithm design in the code review, it’s not meant for that.
The action item can also be “can we create a issue to track and discuss this further”