3 ms·

> I think people take code reviews way too personally. Like, my priority is to ensure I don’t have headaches down the line I feel this, and have personally exp

> I think people take code reviews way too personally. Like, my priority is to ensure I don’t have headaches down the line I feel this, and have personally experienced submitters taking feedback far too personally, to the point of even using sunken cost as justification of their design, completely overlooking valid points of feedback. I’m looking for basics. Will it work? is the code clear? is it commented/documented? is the approach simple and maintainable? Some submitters really need coaching on how to receive feedback, and how to plan their timelines to incorporate revisions.

Aeolun 4y ago
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.
- cramjabsyn 4y ago
  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”
  - Aeolun 4y ago
    There’s limits and degrees to anything. I guess I never get PR’s that are quite that boneheaded.
- interactivecode 4y ago
  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
pjmorris 4y ago
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

Aeolun 4y ago

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.

cramjabsyn 4y ago
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”
- Aeolun 4y ago
  There’s limits and degrees to anything. I guess I never get PR’s that are quite that boneheaded.
interactivecode 4y ago
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

pjmorris 4y ago

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