Opening a pull request for code review can be a vulnerable thing. A lot of care and energy goes into writing code, but we often lose sight of this when reviewing, thinking that if we communicate the information we need to, it doesn’t matter how it’s communicated. But humans write code and receive feedback, and if humans are made to feel stupid or inferior for making a mistake or doing something differently than the reviewer, that can impact how feedback is received, and how the author will approach writing code in the future.
This is a small sample and of course only anecdotal, but I don’t think I’m alone in having felt intimidated to open a pull request:
So if we accept that this intimidation is something people do feel, what can we do about it? I’d like to focus primarily on the reviewer, but there also things an we can do as authors to increase the odds that we’ll get the kind of feedback we’re looking for, so I’ll talk about some things that have worked for me there too. I’d love to hear any other ideas you have!
As a Reviewer
Reviewing code is a big responsibility — it’s through this collaboration that we ensure our codebases are functional, secure, maintainable, and more. It’s absolutely important to provide constructive feedback about these things, but I often see people lose sight of the fact the way feedback is given can impact the way it’s received and how the person receiving it is made to feel about their work and themselves.
Prioritize — consider the cost of the changes you request
There’s a lot to think about when reviewing code:
- Whether it does what it’s supposed to
- Data model
- Architecture/design — maintainability & readability
- Whether it’s sufficiently tested
Reviewing each of these things requires looking at the code through different lenses, and how important each one is can vary a lot based on the product you’re building, the timeline you’re on, etc. And…