To be fair, some people are just pedantic. Just because you are the reviewer doesn’t mean things have to be done exactly the way you say.

If I never accept anything from more junior people because it isn’t perfect, how are they ever going to stay motivated?

I aim for one or at most two rounds of review, because anything else is just depressing.

Ehhh far from perfection, more like “please use the native feature that handles this in 2 LOC instead of shelling out to an external 100 line script”

There’s limits and degrees to anything. I guess I never get PR’s that are quite that boneheaded.

100% agree, code review should be there to check if the code doesn’t contain any obvious security risks or mistakes.

Designing features, architecture and learning should happen before someone even gets to the point of submitting a PR. Plus if it can be improved on in follow PRs then do that instead of blocking juniors with pedantics

Jerry Weinberg pitched the concept of 'egoless programming' [0] with the suggestion that it is possible to not take reviews of your code personally, with examples from his experience. Weinberg is careful to address the problem of feeling attacked by working on the social environment to avoid or limit attacks and the consequent defenses.

Thirty years later, egoless programming is one of Robert Glass's favorite fallacies in 'Facts and Fallacies of Software Engineering.'

IOW, it is a hard problem!

The SE research community has been looking into this for awhile (e.g. Greiler, Bacchelli)

[0] 'The Psychology of Computer Programming' (1971), Gerald Weinberg

[1] 'Facts and Fallacies of Software Engineering', Robert L. Glass