When our development team pushes up new code to be reviewed, I like to review it quickly. Why?

Personal reasons

Generally reviewing code has little cost of delay for me, especially if I am already interrupted or have not started new work. Reviewing code is a good mental shift after I push up my own features.

I like being able to give feedback on code. I think that it improves the quality and consistency of our project.

I also like seeing what everyone is working on. It gives me better context for when I am working on new features or fixing bugs. I get a really good sense of what everyone likes to do and how they like to do it. Sometimes I realize that a teammate is working in a similar (or the same!) area, and I need to communicate more to not squash what they are working on.

If I’m deep in focus of developing or otherwise occupied, I might wait to review. But generally if I see that there is an open pull request I will take a look and comment on what I see.

Github pull requests of feature branches are our current method of pushing code up for review. A typical review takes me maybe a couple of minutes. Some are longer, and some one-line fixes are very quick.

Reviewing just about every pull request is currently feasible. Our development team size is four full-time developers and one half-time developer. At some point it possibly doesn’t scale, but I am willing to at least look at the pull requests that roll through at a high level to get a better understanding of what is happening.

Code review is a skill that improves with practice. It is also a really good way to learn from what your teammates are doing. What takes hours to do, a reviewer might be able to learn from in a short time.

Team reasons

It excites me to get feedback soon after I release something, and I can only assume it is the same for others on my team. If I want to boost someone’s morale, one thing that I can do is take a look at the work that they labored over and give it an honest view. Not letting pull requests to stagnate gives us momentum.

There is a relatively high cost of delay for the reviewee. Every hour that we delay reviewing code is one more hour that the code might be getting out of sync with the master branch.

The very best time to respond to review comments and make any desired changes would be right after the code is released. Every hour we delay, the person who did the work loses some degree of context, focus, or energy. So the quicker I can review something, the better work we can do as a team.

One important side-effect is that we get the code that is closest to being released totally finished, so we can pull new items forward. In Lean terminology, we lower our WIP. If I can choose reviewing something that is finished over starting something new, the team can deliver value more quickly.