How to Code Review

Introduction

As a front-end engineer, you are often the one submitting pull requests most frequently across the team. To make your PRs easier to test and more straightforward for reviewers to review, I’ve summarized a few best practices.

Pull Request Descriptions

• State the purpose of the pull request (e.g., fixing a layout bug, adding a new feature, styling a specific screen, etc.).
• Remember that anyone in the company can view the pull request, so ensure the description provides sufficient and complete context.
• Clearly state what kind of feedback you are looking for.
• Use prefixes to indicate the status of your pull request (e.g., [WIP], [RFC]).
• Add the team members who need to review the code (you can use GitHub’s Assignee or Reviewer features).

Giving Feedback

• If you disagree with an approach in the pull request, pause and think about why you disagree before leaving a comment.
• Ask questions instead of giving commands. “Why didn’t you go with this approach?” is better than “Don’t write it this way!” Ask for their thoughts or rationale first; there might be a valid reason behind their choice, opening the door for constructive discussion.
• Explain why you think the code needs changes (Doesn’t follow the style guide? Violates company naming conventions? Missing test cases?).
• Suggest better alternatives to improve the current code.
• Avoid aggressive or dismissive comments (e.g., “Writing it like this is stupid.”).
• Stay humble.
• Avoid dogmatic assertions (e.g., “Never write code like that!”).
• Misunderstandings can easily arise in written communication. When that happens, consider talking face-to-face (or hopping on a quick call).
• Use emojis to soften or clarify your tone, like “good job 👋 👍” or “Needs a quick fix 👻” (well, maybe that ghost feels a bit sarcastic?).

Responding to Feedback

• Thank the people who take the time to review your code.
• If anything is unclear, don’t hesitate to ask questions.
• If the feedback has been addressed in a specific commit, link to it in your reply.
• If the discussion becomes overly complex or reaches an impasse, try talking it through in person.

For Everyone

• Understand that everyone has different coding styles, and there are often multiple valid ways to solve a problem. Weigh trade-offs pragmatically during discussions, and clearly explain why you believe one approach might be better.
• Ask questions instead of issuing orders.
• Avoid deflecting responsibility or creating silos (e.g., “You wrote this, not my problem” or “That part is yours to deal with”).
• Strive to understand the author’s perspective and reasoning.

Conclusion

While there are many points listed above, I believe it all boils down to being considerate of others. Approaching it from the perspective of “What kind of pull request would I want to review?” can make a huge difference.

After all, if a bug slips through—especially due to negligence—and makes it to production, it ends up wasting the entire team’s time tracking it down and redeploying.