# Better Code Review: Part One

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

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

Author: Molly King

Published: 2018-11-26T17:15:14Z

Content type: tutorial

Language: en

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

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

Tags: [bugs](<https://devfeed.tech/tags/bugs.md>), [code-comments](<https://devfeed.tech/tags/code-comments.md>), [code-review](<https://devfeed.tech/tags/code-review.md>), [pull-request](<https://devfeed.tech/tags/pull-request.md>), [review](<https://devfeed.tech/tags/review.md>), [software-development](<https://devfeed.tech/tags/software-development.md>), [software-engineering](<https://devfeed.tech/tags/software-engineering.md>), [tips](<https://devfeed.tech/tags/tips.md>)

## AI overview

This first article in a three-part series presents self-review as preparation for code review. It recommends running, reading, and documenting code before opening a pull request, arguing that this can catch bugs earlier and support more productive technical discussions.

## Source excerpt

Self-Review Code reviews are an integral part of software engineering, and unless you work alone, are likely to be a regular part of your work life in building software products. Code reviews can occasionally be contentious, and about as fun as a root canal, but they don't have to be! Over the course of this three-part blog series, I will present some tips from my experience to help you review code and for your code to be reviewed in a more productive and less onerous way. First, by putting your code through a form of self-review before having it reviewed by others, you can catch bugs earlier and set yourself up for more successful technical discussions. Microsoft conducted an internal study on code review in 2013. Their aim was to find out why we do code reviews, what the most frequent outcomes are, and how we can conduct reviews more effectively. While most of those surveyed listed finding bugs as their main motivation for code review, in practice only 14% of code comments centered around code defects. The main outcomes found in the study were knowledge transfer, increased team awareness, and finding alternative solutions to problems. Given this information, how can we as reviewers and reviewees change our approach to help bolster those outcomes? The code review process does not begin when you open a pull request (PR). It begins when you start writing code that you intend to merge to a shared codebase. There is a level of due diligence that we are obligated to perform before opening that PR to ensure the best process for everyone involved. I believe by engaging in a few steps of self-review before opening a PR, we can all produce better, more robust code. I propose that there are three steps to self-review: Run it Read it Document it Run it This may sound obvious, but run your code. Even in the case of a simple String change, always run your code. Crashing code that goes to code review creates unnecessary churn and wastes developer and QE time. Very well-written c