Steph- Keep pull requests small
Try to keep the pull requests as small as possible. When a pull request requires more than three comments— and especially once it reaches five — it is usually a sign that the pull request should have been broken up into smaller pull requests.
- Be open to feedback
Remember, it can be just as stressful to give feedback as it is to receive it. Coding is a craft and it is hard to point out ways that someone else's hard work could be improved.
If you feel frustrated by the feedback you received, pause before responding – perhaps put it aside and go for a walk/sleep on it and come back to it the next day. Is there some truth to the feedback that was shared?
The more open and appreciative you can be with feedback, the more ideas you will get from others, and the more you will grow.
- Respond quickly – if you can
If you have a negative emotional reaction to the review, best to step away. As Oasis so eloquently sang, Don’t Write Back to a Code Review in Anger… or at least that’s how we remember it.
If you don’t have a negative reaction, deal with the review as fast as possible– answer the questions, make the changes, and ask follow-up questions.
Context switching is a killer for coding flow. The goal is to minimize the time spent for you and the Reviewer thinking about this review vs. other coding work. If you can reply to the review just after the Reviewer completes it, you avoid the mental effort later for both of you to get back up to speed.
- Switch to synchronous communication for any follow-up
Code reviews are usually asynchronous and can be completed thousands of miles apart.
In the Olden Days, when Dinosaurs kept using up the copier toner with jokes that really weren’t all that funny, a Coder could ask a question or a colleague by walking over to their desk.
Now we have many other tools, which are helpful up to a point.
Now it’s time for the sixth and final Golden Rule of Code Reviews (you didn’t think we’d forget, did you? If the code Author has a follow-up question to a code review, do it synchronously in real-time, not asynchronously. Pick up the phone, start a huddle, and walk over.
The reason is context switching. At this point, there will be three moments of focused attention on the code:
1- Author writing
2- Reviewer reviewing
3- Author internalizing the review
Asking clarifying questions about the review automatically means there will be a fourth moment:
4-Reviewer responding.
The goal of synchronous communication here is to avoid requiring a fifth, sixth, seventh, etc. moment of attention.
