If your codebase makes you feel like this, you need to do more code reviews.

Code reviews make better software. I’ve worked on teams that do code reviews, and I highly recommend the practice. But why do they work so well?

The magic behind code reviews is that 1 + 1 is more than 2.

A code review happens after a programmer uploads a chunk of code to the team’s repository. Someone other than the author must read and review the author’s code, suggest any changes, and once those changes are implemented, approve the chunk.

A second (or third) set of eyes works wonders for development. Each engineer knows a different part of the system and can offer different comments. Bugs get fixed (or prevented) before they go into production, saving time in the long run. And programmers make better design decisions, curbing technical debt.

The problem with code reviews is that they take time. The author has to wait for approval, slowing down his or her process. While the individual author may be blocked on a certain day, the team moves faster throughout the year. It’s like writing tests: spend an hour today to avoid losing three hours tomorrow.

In the long run, if you want to make great software, do code reviews.

What challenges do you face surrounding code reviews?