I Hate Your Code

Promoting a Culture of Great Feedback

Feedback is a necessary (though, not sufficient) component of building and maintaining great software in a collaborative setting. Not just any sort of feedback will due. We need constructive feedback which not only improves the quality of software but also makes engineers better and promotes a culture of respect. Insensitive feedback does not benefit anyone. The software in question may get fixed, but the engineer responsible for said software may feel his or her work is not valued. If your engineers aren’t confident in their work, they’ll hold back. If they hold back, they’ll never reach their true potential. If individual engineers aren’t striving to reach their full potential, your team may become stagnant.

Here’s the deal: software engineers and designers are creators. When someone creates something original (or something they perceive to be original), the idea starts in their mind — which means it comes from them. Because of how humans have evolved, this gives the impression that the idea in question — and the creation that stems from the idea — is actually apart of them. As a result, creators tend to have a very personal attachment to the things they create. Those of us who have been around for a while have learned to deal with this feeling. It’s not that we no longer feel it, we recognize it for what it is and have experience mitigating its effect over our judgment (mostly).

Not everyone has this ability (yet). For those of us who are in a position to lead a team of creators, it’s important that we try to help people draw distinction between creators and their creations. We need to help them understand that they are not the thing they’ve created. This is where great feedback becomes very important. When conducting code reviews or design reviews, team members should always provide feedback on the creation not the creator.

Bad feedback:

Ugh, why did you do it this way? Here’s what you should have done. Just…

Good feedback:

Hmm, this can be refactored a bit to make it more performant. Let’s try this…

See the difference? The good feedback keeps the criticism on the creation hence, words like “this” which draw attention to the code/design itself. Also, notice the word “Let’s” — which helps to create a sense of team ownership over the code rather than dropping sole blame onto one person’s lap. This is particularly important for code that has already made it into production because if it got there, either someone else signed off on it, or there were no good measures in place to catch it and that’s a team issue. In addition, the word “try”, in the context of offering an alternative solution, does not carry the weight of presumption. The author of the good feedback is acknowledging that the originator of the code probably has legitimate reasons for not getting it right the first time around (zombie coding, bad day, lack of experience, difficult problem etc). Finally, the good feedback points out the actual problem with the code — the performance — as opposed to essentially dismissing all of code as worthless.

Now, look at the bad feedback. Words like “Ugh”, which convey a sense of disgust (even if done so jokingly) should be avoided — you never know how someone might interpret that. Also, words like “you” should be avoided. When it comes to criticism, words that merge identity of the creator and creation closer together may be detrimental to an engineer’s self-esteem and ego. Remember, we’re fighting instinctual cognitive processes.

Another thing to point out in the bad feedback is how questioning can carry a negative tone if not done correctly. If you must pose a question to the creator (which is perfectly fine) try something along the lines of:

Interesting solution, is there a specific reason why you went with this implementation? If it were me, I might have…

Again, this question lacks presumption on the part of the feedback author and doesn’t call into question the competency of the creator like the word “just” does in the bad feedback. The question also provides some degree of validation to the solution (with the use of the word “interesting”) without actually signing off on it. The feedback author then provides an alternative solution but does not do so from a place of authority (as if there is one absolute way to solve the problem). The feedback author makes the alternative solution very personal. They are acknowledging that there are many ways to solve this problem and that their solution — while not necessarily better — might help spark a discussion that will eventually lead to the right solution.

Delivering good feedback can be an easy way to create a huge impact not only on the quality of software but on how teams interact. Good feedback also demonstrates respect amongst colleagues. Creators will feel free to experiment and know that, should they stray, someone will be there to help them get back on track, as opposed to scolding them for doing something “wrong”. When you have a culture that promotes respect and experimentation you’re on your way to greatness.