We have an open code review process at Alley. There is a review queue in Slack. We submit our Pull Requests (PRs) into the slack channel when ready for review and anyone can claim them.
We also have a culture of feedback and have discussed in length the importance of feedback for adult growth.
One of the struggles for any adult who wants to grow, is the lack of feedback. In general, feedback is not given often enough. When it is given, it is often given too late, or not communicated in the best way.
Fortunately, for software developers, feedback is available in a structured format known as code review. I was extremely lucky to find a job at a company that had a code review system in place. In my early days at Alley, I received immensely valuable feedback that made a lasting impact.
I am still learning. I love doing code review because I learn so much from it. It fulfills my curiosity, builds my vocabulary, and challenges me — because giving feedback well is difficult!
Code review is a huge opportunity for both the requester and reviewer. It is feedback.
The best feedback is timely, specific, and context aware.
How Feedback is Received
Feedback is received differently based on who is giving the feedback and how it is said, as well as the receiver’s mindset when they are receiving it.
In code review, there is also an additional element to feedback: The “Approve” and “Reject” options. We use Github to perform code review and while just commenting is an option, selecting approve is necessary for merging the code. Without an approval they can’t complete the task.
Comments received along with an “approval” will be perceived in a different mindset than comments that accompany a “rejection.” Sometimes the hardest part of performing a code review is making the best decision as to whether to just comment, approve, or reject the code.
The value in feedback is the learning opportunity. However, code review also serves a business function. It allows people to complete their work. Sometimes I approve code because I don’t want to block them, but yet I still deliver important feedback.
When to Reject
This is something I’ve struggled with, but generally I click “Reject” if I feel that the code could do damage. If it’s going to cause errors or cause a security issue, those are obvious things that do damage and should be fixed.
There are less obvious ways code can do damage. For example, code that is confusing could do damage, but sometimes “clever” code solves the issue. It may be that the code itself isn’t really doing damage (it has business value), but that it should have comments added to help our future selves understand the context.
The Value of Only Commenting
Not explicitly selecting “Accept” or “Reject” allows the feedback to be received without a green or red light. It can feel better to get feedback without receiving an outright rejection. I think this allows the feedback to be received in a better mindset.
The Value of Questions
The person writing the code has more context than the person reviewing the code, so asking questions can help you give better feedback.
Questions also can help the developer improve their code. Because they have more context, they may think of improvements that would not occur to you.
Ask more questions.
Positive Feedback is Feedback too
Feedback isn’t just about what should be improved. If you see an opportunity for praise, take the moment to provide it. “Do more of this” is valuable feedback too.
The “Who” Matters A Lot
Who is requesting the code and who is reviewing the code? Is there a power hierarchy?
Feedback received from someone in authority is different from peer feedback. It will be received differently. Be mindful of how your position may impact how the feedback is received. A small suggestion from someone in authority could cause someone to do a complete rewrite. If you truly are giving a suggestion for “next time”, make your expectations super clear.
When someone in authority asks for code review, their code may get approved more easily than someone not in a leadership role.
Feedback is not received in isolation. People dynamics are always at play.
Feedback Beyond Code Review
While code review is a great feedback opportunity, there are limitations and pitfalls to relying too heavily on code review. Code review shines when a developer familiar with a system can give valuable advice like “do this, not that, and here’s why”, but sometimes it’s not so straight forward.
It’s awesome when developers can give domain expertise, but sometimes the work is cutting edge or unique or new and there isn’t a developer who has been there before. While only reviewing code in languages/contexts that you’re familiar with is good advice, to move forward there will be times when it’s all new.
- Pull down the code and run it. Does it work? Does it fulfill the requirements? Any errors or warnings?
- Add unit tests. If you find yourself trying to reason through the logic of some code to determine if it’s correct, that’s a good sign that writing a test would be a better way of determining if the code is doing what you think it’s doing. Tests are also a form of feedback!
- Have conversations about the code. Learning more about the code’s intention will help to give better feedback. There are certainly limitations to looking at code diffs without understanding the bigger picture. Talk it over and turn code review into a pairing session!