The Empathetic Code Review
The mention of ‘code review’ channels mixed feelings amongst progessional developers. Writing code is a creative endeavor, and like other creative fields, our identity can become wrapped up in our work. However I think it’s time software developers had an honest look at how we take and receive constructive criticism. An art school graduate will tell you that the ability to seek out and flourish through criticism is a key step in growing as an artist. Effective criticism, when it comes to code, is sadly not taught within Computer Science curriculums. Because of this, professional code reviews are sometimes experienced as a soul-crushing gauntlet of sadness. It’s time we toughen up, stop taking things personally and embrace a process which will make us all better developers.
If your team already does code reviews, or you are a manager hoping to introduce code reviews in the process, here are some tips to make code review a positive experience.
Don’t take it personal, it’s code
When offering criticism on someone else’s work, keep them out of it. Use words like ‘THE code’ instead of ‘YOUR code.’ Treat the interaction as if you are both talking about code created by a third party. Hyperbolic statements, hot takes, and gifs don’t help anyone. Effective criticism must be backed up with evidence and technical examples.
Let it Slide
Save recommendations for the large stuff. Small things like style which do not impact program functionality are not worth the damage to team cohesion. Needling someone with many tiny changes because we disagree with their style is a waste of time. If style is a sticking point on your team, run a script within the CI or add a linter step to Xcode. Style enforcement is best left to the machines.
Flip the thinking
I think a large part of what makes code reviews unpleasant, is the de-facto adversarial role between submitter and reviewer. The reviewer commonly assumes to stance of “all of this code is suspect” instead of a stance of collaboration. Flip the thinking, and instead think of the review as an invitation to add value instead of acting as heavy-handed gatekeeper. This method of thinking requires a great deal of trust within a team, but I think is an achievable situation to strive for.
Be prepared
Submit your best work and prepare for questions about design decisions and the reasoning behind chosen tradeoffs. Before submitting code, give yourself a mock code review. Pretend you’ve never seen the code before, and go through it line by line checking for the same types of things you might make note of when reviewing someone else’s code.
