Are you tired of waiting for your colleagues to review your pull requests? Here are some quick tips to help your PRs filter to the top of the proverbial review queue. Short and sweet — Nobody likes reviewing long PRs. It might not be fair, but ten 10-line pull requests will generally get reviewed faster than a single 100-line pull request. Limit scope — One of the surest ways to confuse someone reading your change set is to mix concerns.

Yesterday Kief Morris published a thought-proviking article, Why your team doesn’t need to use pull requests. The central thesis is that pull requests introduce a harmful human delay into the software delivery process, and that there are better alternatives. This promise excited me, as I read the introduction to the piece. But I found that the proposed solutions left me with more questions than answers. The post generated a lot of knee-jerk reactions on Twitter, my own among them:

I have a funny habit. Well, I guess it’s a funny habit. I never thought of it as funny. Then people started pointing it out to me, and asking why I did such a funny thing. A little over a hear ago, this funny habit came up during a job interview: “It’s funny how you make pull requests for your own projects on GitHub.” Yes. That’s right. My funny habit is that, even on solo projects (and yes, even the private ones I never publish), I create pull requests.

In my programming practice, peer code review has become such second nature to me that it’s sometimes a challenge to articulate why I think it is important. I was recently asked this question, which forced me to think about it, and so now I want to put it into writing, lest I forget my answers. It’s just to reduce bugs, right? Before I jump into the list proper, let me address what I believe is a common misconception about code review.