A recent blog post from the folks at Code Climate (a highly recommended hosted static analysis tool for Rubyists) highlighted a study that found what the researchers deemed “The Unexpected Outcomes Of Code Review”. When I read these “unexpected” outcomes—code improvements, understanding, and communication among colleagues—my initial reaction was “Unexpected? Those are precisely the reason I push hard for an integrated code review process in the first place!”
Then I remembered that I’m apparently a weirdo and have only a rainbows-and-unicorns outlook when forming and wrangling software development teams. Also, that collaborative pedagogy was most certainly beat into me at some point in another life, it takes many forms outside the academy, and the workplace is a pedagogical space. Or at least it should be. It’s more fun that way.
In that bland, flowcharty way (it’s my own flowchart, so I know it’s bland), it may look like the emphasis is on “finding issues”—and of course it is, to an extent, much like the author of the “Unexpected Outcomes” post summarizes that “a large portion of developers, managers, and testers are motivated to perform code review because they hope to find bugs”. But in the era of an increased focus on automated testing, be it through TDD, BDD, or any test automation, code review is an opportunity for so much more.
That’s right: unicorns, rainbows, and talking. “Talking” can be entirely through GitHub comments or Jira tickets, or in person, or whatever, as long as it happens. The “unexpected” findings of the study referenced in the blog post are “knowledge transfer, team awareness, and improved solutions to problems [as well as] educating new developers about code writing”. I say that if we (software development managers, team leads, and whomever is making sure the processes are working for your teams and not against them) are not looking for opportunities for holistic improvement, we’re missing out on a great opportunity.
Think back to when your
horrible composition instructors in college made you do some in-class peer review. If you were like any student I ever had in class, you probably read a peer’s essay, saw some wonky things, didn’t want to say anything out loud, certainly didn’t want others to find the same issues with your work, and generally thought the whole process was a waste of time. Until—until!—some brave soul piped up and said she was having a hard time understanding your argument, and couldn’t you work together to make it more clear? Or a fellow turned to you and said, “you know, I totally get your point, but you sure do use a lot of extra words to make it!” And with a little teacherly coaching and maybe a worksheet, the flood gates opened, everyone saw they were in this together, and everyone’s work improved. Sure, grammar improved, because it’s easy peasy to fix a sentence fragment, comma splice, or misused semicolon, but so did argumentation, clarity, concision, trust, and the ability to communicate all of that.
It’s easy to find something legitimately wrong with code (it won’t run, won’t compile, tests will fail, etc). It’s more difficult to find and address issues of style, convention, future-proofing, DRY-ing things up, and so on. But those are the real issues that human brains and human eyes should focus on catching, discussing, fixing, and learning about (especially for juniors, but plenty of seniors need help, too). All of those things make our code better, communicating in a positive way makes our teams better (and closer, and more trusting of each other), and it should be a goal, not just an unexpected bonus.