Code Review Aikido
Giving and Receiving Constructive Feedback
During software code reviews, hurt feelings happen. Sometimes, a software engineer treats team mates rudely, calls their code bad, and makes them feel frustrated. As a team member, how can you accept or receive feedback with grace? As a manager, how can you lead teams to avoid the negativity surrounding feedback?
Let’s look at some aspects of Aikido practice and apply them to code reviews.
In Japanese martial arts, the uke is the person receiving the technique (the one on the left in the photo below, being thrown).
One of the things you learn in a martial arts class is that being the uke isn’t just about taking a punch in the face or being thrown around like a rag doll. It’s a legitimate skill to be the uke and it takes practice to receive a technique gracefully, without hurting yourself or feeling resentment about being the “loser.” You have to realize that you can’t practice without a partner, so both people are necessary to practice. With practice, both people should improve their skills.
The other person, the nage (thrower), also has a responsibility to be respectful of their partner. During practice, don’t be cruel and don’t try to catch your partner off guard to actually hurt them. It’s not a real fight, it’s practice. Go as slowly and gently as necessary, given the skill level of your partner. Everybody needs to start as a beginner, and if you throw an uke who isn’t as skilled at rolling, you could hurt them. You can get more fluid and skip the gentleness later, after both of your skills get better.
The dojocho is the leader, the person who runs the dōjō (the martial arts training hall). In the case of code review, the manager’s role is to support the team members and ensure they have the training and resources to succeed — which includes soft skills.
If you are the nage or code review, be patient and respectful, especially when reviewing developers who are junior to you. Everyone starts out not knowing all the code tricks and techniques. That’s part of what the code review is for, to allow people to share knowledge of those techniques while they’re working on a concrete sample of code. But take care — avoid using the meeting as an opportunity to demonstrate your wisdom and experience, which can come across as dominance and superiority.
Justify feedback. Suggest specific changes; don’t just disparage the code. Explain practical benefits to justify why suggested code changes are better. Avoid eye-rolling, deep sighing, speaking in a condescending tone, or going on rants about how many things junior engineers don’t know yet. All of those behaviors are rude and hurtful. Check in with yourself. If you wouldn’t want to be on the receiving end of your behavior, don’t do or say what you are thinking.
If you are the person getting the review, the uke, be graceful about receiving feedback and criticism, as long as it’s constructive and respectful. Take it as an opportunity to learn new code techniques you haven’t experienced — it’s a chance to expand your toolbox. Don’t take constructive criticism as a personal attack. All code can be improved. There’s always more than one way to implement a given function.
Manage emotional reactions and have confidence in your job security. People generally don’t get fired just because they don’t know a particular code technique yet. As an uke, you have the right to reject any criticism that can’t be justified. But you should also avoid becoming defensive or proprietary about your code. It’s not entirely your code anyway — treat code as a team effort.
As the dojocho (development manager), your job is to make your team aware of how to give constructive feedback and how to take constructive feedback. Both of these are professional skills, and any professional skill takes practice and conscious effort. It might even be worthwhile to bring an expert code review consultant in, to coach your team in good communication habits.
No matter what your role, the key to successful teamwork is to treat others with respect in both your actions and words.
🖊 Editor’s note: The line drawings are by Likman Uladzimir, used under license via Shutterstock.
If you enjoyed this article, you might also like the first volume of Bill Karwin’s new SQL Antipatterns book, now in beta with The Pragmatic Bookshelf. You can save 35 percent with promo code bksap1_medium_2022 now through August 31, 2022. Promo codes are not valid on prior purchases.
