Where I work: We encourage people to mark their comments on diffs as to whether it should be regarded as a blocker to being merged, or not a blocker. (Perhaps

Where I work: We encourage people to mark their comments on diffs as to whether it should be regarded as a blocker to being merged, or not a blocker. (Perhaps poster could ask the Senior to do this) Blockers should be comments to correct: - code which goes against either the spirit of the spec or the spec itself, in other words, wrong behaviour. - something which could really harm performance in a meaningful way (back this up with benchmarks) - code which could break something else (probably a sign of a missing test elsewhere) Non blockers should be the subjective things that are the topic of OPs post, but it's the responsibility of the reviewer to make that clear. The committer can then decide whether to implement or not. We couple this with quarterly patterns and practices meetings where we can discuss any of the subjective things which come up over and over again as points of friction. If we can come to an agreement, great, if we can come up with a linter rule to enforce the decision automatically, even better. Then it's removed as a point of interpersonal friction. There's a culture I push for in the company I work for and in the teams within. It's to try and best as possible, to check your ego at the door and regard the code as 'the companies code' rather than 'your code'. This is important to strive for in your Seniors just as much as less-senior developers. (Rank shouldn't be blindly used as barometer of the decision whether to hear out feedback or not). When you keep focus on the culture, working practices start to emerge rather than trying to dictate them from the top down.