3 ms·
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 reas
by 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 agoThere 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]