Get to Know Each Others’ code Better with Code Review

There are lots of reasons why Developers don’t know each others’ code.

Sometimes it’s because the Developers just have different levels of expertise. Other times, there’s a general lack of transparency.

But, to build efficiently, all of the Developers need a shared understanding of the code and how it’s progressing. This transparency is at the foundation of an Agile work environment.

Plus, it’s never a bad idea to get a fresh perspective on your work.

So, how do some Agile teams bring transparency to their work? One of the easiest ways to get to know each others’ code is to do a code review. This is a pretty common practice that boils down to one Developer explaining the code they’ve worked on to another, and vice versa. 

It’s a pretty simple practice that can seem daunting when it’s first suggested. But, it’s also been used by experienced programmers and Agilists for years to help teams avoid waste and technical debt.

Here are my top tips for peer code review:

• You don’t have to include non-Developers (unless it makes sense). This is only for those who code.
• Add code review to the Done criteria so that every piece of work is reviewed by another set of eyes before deployment.
• Maintain transparent, easily-accessible documentation of all versions, releases, and changes. Be sure to include Backlog item numbers whenever possible.

Of course, the last thing you need for a successful code review is an open mind. Be willing to hear another perspective on your work, and give your own insights and knowledge generously. 

Your code (and end-users) will thank you.