One technique I use regularly when working with a team or even by myself is lots of individual code reviews.

This is not a formal (sit down with someone) code review.

This is a personal practice I found extremely useful.

Granted, I'm not talking about reviewing every commit in a repository the size of Facebooks. Most of the projects I have participated in are on small enough teams (between 1-10 people) that reviewing code changes either as they come in or in some block during the day is completely feasible.

Depending on the project, how many developers, time zones of committers, I shift how often or how thorough I review the changes but I try to review each and every commit (or at least the branch merge). This is one reason why segregating your code commits into tiny topical changes is important.

If you're working with a source control that doesn't have an easy way to do pull requests. Or some other code review functionality, you can still use the source control system to manually review changes or diffs between branches. Way back when I was forced to use TFS source control this was a much more manual process. I would open up Visual Studio, browse our TFS server and begin reviewing. These days, the power of a pull request is generally suffecient for this purpose.

What happens in this review?

One approach I've taken in the past is to block some time, possibly while warming up with a cup of coffee to begin reviewing the previous day's commits. I would use this time to not only review other developer's changes, but I would also re-review my own commits. This helped remind me what I worked on and possibly what I was struggling through the previous day. Reviewing code the next day provided time for my mental perspective to have shifted. I was probably thinking about things a little more clearly after a nights rest. Maybe I'd learned something that could be applied to the problem being worked on and provide better setup for changes needing to be made that day.

Some other benefits the morning review process provided include:

• It was a bit of a meditative process in the early morning that put my brain on a code thinking track for the day.
• I could take notes on changes other's had made that were not clear. (Note: this is generally done in an environment that didn't perscribe peer-reviewing code changes). So I essentially took the job on personally to review other's changes. Provide feedback, or ask question to get more understanding of their changes.
• Easily catch when the project conventions were not being followed, when the convention was not automated.
• Potentially spot bugs being introduced.
• Suggest potentially better approaches.

However, the most important thing I gained by doing this was:

• Gain a better understanding of the entire project.
• Learn from others. I'd like to think I'm a pretty good develoepr, but there is so much to know and learn that reading other's code provides a great way to learn something new (or possibly what not to do).

I once had a fellow developer say to me that they were blown away at how quick I could spin up on a brownfield project and get an architectural understanding that I could apply that knowledge and not only contribute quickly, but spot the places where we could improve general architectural patterns or jump in and become productive on a problem set.

I believe that reviewing the changes going into a code base each day allowed me to keep a strong perspective on what is shifting within the project and be able to talk intelligibly when others start to get stuck on their work.

Formal Code Reviews

If your team practices some form of code review workflow, this is great for those participating in the review process. However, it leaves the rest of the developers out of that specific review.

This should not stop those not in the review room (or pull request) from participating and learning from the changes.

Many of the places I've worked don't have a formal review process in place, so by putting this little ritual in place for myself I can not only come up to speed on a project but can be helpful to all aspects of the project. Reviewing changes every day allows me to more easily understand what people were working on when they announce it during the morning standup.

Just Review Everything

If you project is small enough and you can - spend a moment each day and review everything going on in the project. You and your team will likely be better off.

Happy Reviewing!