Hi, I'm Johnathan Sewell

Software Engineer & JavaScript Developer

Code Reviews: a Cornerstone Practice

Since moving to Copenhagen earlier this year I've been working for a (large and successful) digital agency. I was very surprised to find they didn't do regular code reviews. I truly (naively) believed that every development team had to be doing some form of peer code review.

The lack of process didn't seem like a concious decision either, some of the answers to my questions on the lack of reviews were telling:

The developers on this team are very experienced, they don't need their work to be checked
We do code reviews, but only for junior developers during their first 2 weeks
We each have our own areas of the project code, we know our areas best, so code reviews don't make sense for us

Agency Time-Centric Culture

Having to track time is completely understandable, since agencies sell time to their clients. And I think SaaS companies should also be very aware of where time is being spent. But I've seen projects that put a heavy burden of time tracking on engineers, and I suspect this makes it difficult for practices like code reviews to survive. When you have to log every hour of your day to a client invoice, it's difficult to justify spending an hour looking at code that someone else has already written!

But Code Reviews are a Cornerstone of Great Teams

There are so many benefits to a good code review process, they are a cornerstone practice for great teams. In my experience the exact code review process should be one the whole team agrees on, and one which requires everybody to put their code through a review before it gets deployed.

Code reviews improve code quality AND the performance of the team. I'll explain why.

Code Reviews improve Code Quality

Reduce Bugs. Code reviews help catch bugs early. Bugs are cheaper to fix at this early stage. You will also catch bugs that get through your QA process, like subtle memory leaks that slow down your app after an arbitrary time.

Add a Quality Incentive. Knowing that your code will be reviewed by someone on your team gives you some extra incentive to do things right and not cut corners.

Stamp out Bad Practices. Reviews help keep bad practices out of the code. Bad practices spread, engineers love to reuse code and techniques. And the broken window effect means that engineers lose respect for poorly maintained code and start to write poor code in response. Code reviews can also reduce existing bad code by encouraging refactoring as part of related work. The opposite is true for good practices and smart solutions, these are more visible to the rest of the team and more likely to be reused.

Increase Development Speed. Why care about code quality, especially in an agency where you just need to get something that works out the door? Well, one of the ways teams can move faster is by having well-engineered and well-maintained code, it makes it quicker to refactor to fit in new features, and it reduces bug counts and fix time. So the project could be delivered faster, with less bugs, and be in great shape for another phase of work.

Code Reviews improve Developer Engagement

To me this is the most important factor. Any company that build software as a business needs good engineers, code reviews can help to keep your great engineers happy, and help to improve the rest of the team.

Learn More. When someone suggests a better way to do something we're learning, when we look at how other engineers have approached something, we're learning. Code reviews naturally involve knowledge sharing. We're also helping new engineers align with the team, and giving them a platform to share and discuss fresh perspectives. Constant learning is a big part of the appeal of being a developer, without it work becomes boring and bored people quit.

Rely Less on Individuals. We're reducing dependency on individuals, because exposure to each others' work means it's easier to pick up where others left off. So people can move around, do different things, take time off, without a major impact on projects.

Make the Team more Cohesive. Discussions on code reviews get people talking and finding concensus (hopefully).

Make Engineers Happy. Lastly and most importantly, developer engagement is affected by the projects we work on. Good engineers care about working on a well-maintained project that provides a sense of achievement, having other engineers cutting corners and adding poor quality code is only going to make your best engineers unhappy. For a software company, having unhappy engineers is a gigantic problem.

Needless to say I've introduced code reviews to my current team, and everyone is on board with it! Having a flexible process has helped, and the code review tools provided by Github are invaluable!