4 ms·

Code review is useful to a point but it can become insanely frustrating to have your work delayed due to lack of resources or comments that are more about prefe

Code review is useful to a point but it can become insanely frustrating to have your work delayed due to lack of resources or comments that are more about preference(or, worse cargo culture) than function. It takes a team commitment on what matters and a managerial commitment that fast reviews are a priority. As for feature suggestions- it's really good to get into the habit of stating the criticality of a comment. Like a 1-5 score of nitpick to strong objection. Code review tools never have this but it's a huge time/frustration saver.

simonbarker87 3y ago
That’s why everywhere that I work I introduce Must, Could, Should. It gives people the ability to express their opinion with coulds, improve for objective reasons with shoulds, and enforce in house conventions with musts. The rule for a must is that to apply one you have to say yes to the question “would I apply this to code written by the CTO/Head of Engineering?” and to argue a must you have to answer yes to the question “would I query this from the CTO/HoE?” It’s not perfect but it always makes code review a faster, less contentious process in my experience. To be clear, I didn’t come up with this - I picked it up at my first real dev job and have carried it on.
- surajrmal 3y ago
  There are only 4 cases where I have a non optional comment: * code has a bug * code is not compliant with a style guide, API rubric, or similar * architecture is flawed (usually due to skipping a design doc or review) it is introducing tech debt that wasn't agreed to take on * missing test cases Everything else is a suggestion I start with the word nit or consider. I leave it up to the author to decide what action to take. Most often they take the suggestion, but not always. It's never been a problem imo either way.
  - deleted 3y ago
    [deleted]

simonbarker87 3y ago

That’s why everywhere that I work I introduce Must, Could, Should. It gives people the ability to express their opinion with coulds, improve for objective reasons with shoulds, and enforce in house conventions with musts. The rule for a must is that to apply one you have to say yes to the question “would I apply this to code written by the CTO/Head of Engineering?” and to argue a must you have to answer yes to the question “would I query this from the CTO/HoE?” It’s not perfect but it always makes code review a faster, less contentious process in my experience. To be clear, I didn’t come up with this - I picked it up at my first real dev job and have carried it on.

surajrmal 3y ago
There are only 4 cases where I have a non optional comment: * code has a bug * code is not compliant with a style guide, API rubric, or similar * architecture is flawed (usually due to skipping a design doc or review) it is introducing tech debt that wasn't agreed to take on * missing test cases Everything else is a suggestion I start with the word nit or consider. I leave it up to the author to decide what action to take. Most often they take the suggestion, but not always. It's never been a problem imo either way.
- deleted 3y ago
  [deleted]