# Better Code Review: Part Two

DevFeed: [Better Code Review: Part Two](<https://devfeed.tech/articles/better-code-review-part-two-20359.md>)

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

Author: Molly King

Published: 2018-12-13T03:03:08Z

Content type: tutorial

Language: en

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

Topics: [Code review](<https://devfeed.tech/topics/code-review.md>), [Pull Request](<https://devfeed.tech/topics/pull-request.md>)

Tags: [code-review](<https://devfeed.tech/tags/code-review.md>), [code-reviews](<https://devfeed.tech/tags/code-reviews.md>), [pull-request](<https://devfeed.tech/tags/pull-request.md>), [skills](<https://devfeed.tech/tags/skills.md>), [software-development](<https://devfeed.tech/tags/software-development.md>)

## AI overview

Part two of a code review series offers advice for developers whose pull requests are being reviewed, including separating personal identity from code and responding constructively to criticism.

## Source excerpt

Being Reviewed Putting your code up for peer review can be a scary proposition. You've artfully crafted this code over multiple hours and cups of coffee. Your precious, perfect baby is about to be exposed to the big, dark, scary world and torn to pieces by your coworkers. Okay, maybe I'm overstating things a bit. But code reviews can be scary, especially if you're new to them. Few people truly relish in the idea of being criticized, but that's what we do in code review: invite criticism. So what can we do to come out of this process unscathed? If you've read part one of this series then hopefully you're already engaging in self-review before opening your pull request (PR). This will help you screen out obvious errors and save your reviewers' time for more nuanced issues. Once the self-review is over and the PR is open, I've got a few more tips for you to survive being reviewed. The first thing to keep in mind is that you are not your code. It's easy to get your ego tied up in your work, but to survive critique you have to take your ego out of the equation. Great code can be written by inexperienced developers and buggy code can be written by highly regarded, experienced developers. Reviewers will find issues with the code you write, and that has no effect on how good you are at your job. When you conflate your ego and your code you get defensive in response to criticism, and that's just not productive. If you can remind yourself to focus on the critique as it pertains to the code and not as a criticism of your skills as a developer, you'll free yourself up to use the skills you know you have to fix the issues your reviewers have found. If I know someone's going to be picky about my code, I'll go to them directly when I open the PR and talk through their criticisms to avoid an avalanche of comments. -- Jazmine, Software Engineer, RMN A common issue people bring up with code reviews is that they can take too long when the reviewer and reviewee go back and forth in a lo