If you are not doing code reviews, start now!

I was introduced to code reviews few years back in my first startup job and as a junior developer I immediately felt their impact. Having my code reviewed by seniors and reviewing code myself taught me a ton. After that job, I switched to another startup and we had a great code review process in place as well. I thought world was a good place.

Today a friend of mine complained about a project she inherited. It was thousands of lines of unintended code with whole functions commented out. Another friend told his horror stories from work and I felt baffled: “How is it possible that code like this goes through to production?”.

Apparently many of my friends work as software developers in companies that have no code reviews set up. Everyone does what they wish and push it to production. And that’s really scary.

Code reviews help ensure quality

Code reviews combined with automated tests and style checks helps a lot when battling with the code quality. Having a second pair of eyes look at every piece of code that goes to production helps find out brain farts and weird choices: we all make silly, easy-to-spot mistakes when we are too deep in our own code.

Many people complain that code reviews become fights over small issues: code styling, variable naming etc but big part of that can be avoided by using automatic linters as part of the CI process. Something like ESLint for Javascript and PEP8 for Python are easy to set up and they help you guarantee that the code remains consistent.

I don’t personally give a damn if we use 2 spaces, 4 spaces or tabs or if we put the opening curly brackets after if or on the next line. What I do care about, is consistency. With small adjustments in automated processes (f. ex. break a build if the style guide is violated) you can help the team in the future. New people can easily grasp the code and architecture when everything looks the same and is named logically.

Code review doesn’t have to slow down the development. It doesn’t have to be a rigorous all-hands meeting for every pull request but having one other team member go through your code, give feedback and ask questions. The small extra time used will be saved in the future with less bugs, less maintenance and faster on-boarding with new employees or people changing projects.

It’s about the shared code, not you

Giving and receiving feedback is difficult. I absolutely hate when someone criticizes my work but we all need to learn how to deal with that. Every piece of code you contribute to your team is a shared responsibility, it’s not your code. That’s why it’s important that the code that goes in and stays in for months and years, isn’t just any random quirks that someone came up with.

Even with code reviews, automated tests and style checking, you cannot completely avoid bugs and problems. But it will reduce the amount of them and it will give your team better view on what could be the cause for a bug: when more people have seen the code beforehand, more people have an opportunity to recognize the issues.

Code buddies for freelancers

If you work alone, it can be difficult to do code reviews. Consider finding a trusted fellow freelancer with whom you can do quid pro quo code reviewing. Reviewing an unknown code base is much more difficult but at least if you work on the same technology (say, both of you do Django), you can find some pitfalls from each other’s code.