Review your own pull requests

In software development, the cost of reviewing pull requests (PRs) is normally underestimated. Once a new PR is created, the development team has to review it before it can be merged. This can be time consuming for big PRs. In this post, I would like to share my story about reviewing my own PRs making this process less painful.

As a software developer, I write code, I fix annoying bugs, I add new cool features. Once the coding is done, I submit a PR and nicely ask my peers to review it. They point out things that I could have done better. I fix them. My code is merged. I move on to work on the next thing. That was my daily cycle. Until I worked with a team that changed my perspective about doing PR.

One day I saw a developer in my team opened a PR. He immediately jumped in and reviewed his own work. I was very curious about it. During the lunch break, the developer told me that he did so to improve his coding quality. He also thinks that a well written PR is faster and easier for the team to review as well.

That conversation struck me hard. During school, I was taught to review my assignments before submitting. But for some reason, reviewing my code just didn’t cross my mind.

During the last year I found that this technique has helped me a lot. I picked up errors that normally I would have missed. For example:

• Commented out code.
• Undone TODO tasks.
• Code that is unrelated to the pull request’s context.
• Features that could have been implemented better.

Additionally, because I am the first person to review my PRs, I feel the pain if I create a bad one. I find myself consciously trying to make my PRs easier to review. Now my PRs are smaller. They target one aspect of the code base. Therefore, my teammates don’t have to spend too much time figuring out what is going on.

How do I do it?

During the last year I found some techniques to help myself with reviewing my own PRs.

One of the main purposes of reviewing my code is to avoid efforts from other people to review my unfinished work if they don’t have to. When a PR hasn’t been reviewed by myself, I add a “work in progress” (WIP) tag prefix to its name. That way, I tell my team that there is a feature coming but the work is unfinished.

Reviewing code right after working on it doesn’t work well for me. I find that I am still mentally attached to it. Normally, I take a break after the coding phase. It can be a short walk around the office, or it can be a coffee break. When I come back, I can review my code with fresh eyes.

Above is my story about “reviewing your own pull requests” technique. I find that it helps to improve my PRs’ quality. I really hope you find it useful too. Happy coding!