# Code Review Communication Tips for Reviewing Others' Code

DevFeed: [Code Review Communication Tips for Reviewing Others' Code](<https://devfeed.tech/articles/better-code-review-part-3-20357.md>)

Original publisher: [Read original article](<https://engineering.ziffmedia.com/better-code-review-part-3-4efb568885?source=rss----d6bb34696ef5---4>)

Author: Molly King

Published: 2019-01-18T22:35:25Z

Content type: opinion

Language: en

Sources: [RetailMeNot](<https://devfeed.tech/sources/retailmenot.md>)

Topics: [Code review](<https://devfeed.tech/topics/code-review.md>)

Tags: [code-review](<https://devfeed.tech/tags/code-review.md>)

## AI overview

The article offers advice for communicating constructively when reviewing other developers' code. It recommends using inclusive language, asking "what" rather than "why," avoiding minimizing words such as "just" and "simply," and reconsidering emoji used to defuse tense comments.

## Source excerpt

Reviewing code Happy new year! The beginning of the year is a great time to reflect on our strengths, our accomplishments, and our areas of opportunity. Perhaps you've decided that code reviews are one of your areas of opportunity. Wonderful! I'm so glad you're here. I highly recommend checking out parts 1 and 2 of this series, as code review is a two-way street. Now that you're caught up, let's move onto part 3: reviewing others' code. What follows are a few tips and tricks that I've learned and (tried to) put into practice myself. Language mattersBeing condescending makes you look like a jerk and teaches the developer nothing What you say in code review matters, and so does how you say it. It's important to be clear and conscientious when giving feedback, positive or negative. One of the first tips I've learned when it comes to language is to use "we", not "you". "You need to do it this way" comes across like a demand, "we need to do it this way" is a reinforcement of team standards. It's a small thing really, but can yield positive results. Ask what, not why. People are more open to negative feedback in the form of a "what" than that of a "why". Rephrasing questions to ask "what are the benefits of x over y" instead of "why did you choose x?" forces you as the asker to clarify what you really want to know, and gives the responder a straightforward, non-judgmental question to answer. Avoid using "just" or "simply". What seems simple to you might be less intuitive to others -- there's no reason to imply that there's something wrong if a solution isn't obvious to them. The reality is that "just" and "simply" are filler words that don't add value to your comment, so you can leave them out without losing anything. Lastly, emoji. This may be a hot take but I don't think emoji belong in code reviews. If you're adding a smiley face to a comment to try and defuse tension it might cause, you should probably reword your comment. Or better yet, deliver it in person! As I ment