LPT: Make friends & influence people through code reviews…🙀

Written by kyleboss | Published 2018/03/10
Tech Story Tags: code-review | software-development | productivity | coding | engineering

TLDRvia the TL;DR App

I am at Starbucks. I promise I try not to eavesdrop, but sometimes I can’t help it — especially when it seems like the two folks next to me are having a code review. It was great! I love seeing these practices that we preach materialize in the real world…then the words “Your code has a bug in it” wizzed through the air 🤦🏼.

Code reviews like the one I overheard can be soul-crushing, especially for newer engineers. This reviewer had the best of intentions. With a few tweaks to the verbiage, this review can be empowering, thought-provoking, and educational 🌈

Try replacing “your” with “the”

“Your code has a bug in it.”

…is what the reviewer said, but all the coder read is…

“You fucked up.”😈

(Side note: if you ever pondered what an emoji looks like when it is italicized…ponder no more!)

A simple solution to making code reviews more productive is to remove all instances of “you” and your”. For example, instead of “What does your function do?”, try out “What does the function do? 😯”. This demonstrates to the coder that the reviewer isn’t judging the coder, but the code itself.

Point out the good code too! 🎊

Code reviews aren’t just useful for critiques, they are also great mediums for positive reinforcement of good coding practices. Attempt to maintain a 1:1 ratio for suggestions & re-enforcements. Remind the coder you “💜 that this spec stubbed out this function. #LoveIt.” Reinforcements will stick in the coders mind & guide her to what good code looks like when coding in the future.

Effects of positive reinforcement.

Reference principles 👩🏽‍🏫 not opinions

When a reviewer writes

I don’t like how the Square class inherits from the Rectangle class…

the coder probably just thinks

Well…fuck you too, Jim…

Obviously this is not the desired response. Opinions make reviews personal. Furthermore, it’s impossible to dissect why code is bad from an opinion. This means that nothing is learned from this review. Sure, the coder can fix the code, but they are prone to making the mistake again. A better review might be

Due to Liskov’s Substitution Principle, it might not be best to have Square inherit from Rectangle.

Keeping the coder in a state of open-mindedness 🌈 not defensiveness

No matter how valid a review may be, it will be 100% ineffective if the coder is put on the defensive. Keeping the coder in a state of open-mindedness & not defensiveness is an art that should be practiced & cultivated. The software engineering world can be soul-crushing as it is, let’s work together to make it soul-enriching, one code review at a time.

Peace, love, & vinyl 🥑


Published by HackerNoon on 2018/03/10