Review All of Their Code

via GIPHY

Working in a sandbox is one of the easiest ways to miss a huge part of any feature. Developers may think they are introverts that like to work in dark corners and only need coffee and donuts to function, but applications do not benefit from single perspectives. Simply having someone look at how you did something will find a bug or problem that you never thought of, even if they aren’t a coder.

A great exercise to run is the rubber duck experiment.

• Do a Google search for rubber duck images.
• Click on any rubber duck you like.
• Explain the code to them in a way the rubber duck would understand.

You’ll feel weird at first, but suddenly things will pop into your head like “oh, I completely forgot that” or “I didn’t account for this”. Or do the same thing with a quality assurance person, or a designer, or your friend who is a super successful movie star, or your dad, whoever.

These code reviews should check for things like code standards, unit tests, and adhering to the architecture. This is your team’s backup to make sure they are doing all the other things they said they are doing. Any code that has been reviewed now has at least two stamps of approval.

This accountability will make your quality skyrocket. I make sure any team I join is doing this. However, it is also one for the hardest things to have everyone start doing. Developers tend to just look at something and say “yea, this looks like code”, and say they reviewed it. Every company that begins to use code reviews will have these growing pains. Eventually, developers will learn from the review process and start producing high quality code.

At one of my previous companies, I reviewed someone’s pull request, and I found 4 conditions of satisfaction missing for the story he said he had implemented. Four defects would have emerged had I not taken 5 minutes to just make sure the code was working as it should be. This small change in process can save a day of development across the company.

At another company, I learned a great lesson about who should do your pull request. Simply put, the person who should do your pull request is the person who will be the most critical of it. Pull requests are learning processes; the person who finds the most problems with it is the person a developer will learn the most from. Similarly, this will teach the developer to be better at pull requests so they can do the same for other members of the team.

One time it took me three days to review someone’s code, and I had 280 changes for them to make. The developer made the necessary changes, and their next pull request had only 30 changes. My review of their code improved their development by a factor of ten!