Getting Started With Code Reviews
Published on .
I’ve had a consistent question from most of the junior developer I’ve worked with — it centres around code reviews.
When you’re relatively new to software development, commenting on someone else’s work, especially when they’re more senior than you, is intimidating. How can you be helpful in code reviews when you’re just starting your development career?
I wanted to share some things I, and the various people I’ve worked with, have found helpful. If you’re reading this as someone struggling to review other people’s code, I hope they can help you in some way.
Know what code reviews aren’t
It helps to clarify what code reviews are not (and conversely — what they are).
Remember that code reviews are not one developer taking responsibility for another’s work. This thought gets in the way of people reviewing work because “what if I miss a glaring security hole or a bug”?
Firstly, I hope you’re learning to write code at a place that uses mistakes as a learning opportunity. Being in a supportive environment can help build comfort with this one. Learning is what being a junior is all about, and mistakes are a great way to learn — seniors make them all the time too. Trust me.
But let me ask you a question — when you approve a piece of code do you expect to take credit for its positive outcomes? If not, should you anticipate taking responsibility if something goes wrong?
Reviews are also not tests, and you aren’t getting judged on whether or not you know something. It’s OK to admit you don’t understand something and ask for clarification. It’s easy to overthink and not question or make a suggestion because you think your peers will judge you for not knowing something. Admittedly this behaviour can be challenging to overcome, but try to be mindful of it and get into the habit of asking or commenting anyway. One practical way of helping with this is to start by talking privately with another trusted developer on your team — their reaction will help build confidence that it’s OK to ask.
Know what code reviews are
Code reviews invite discussion from everyone on your team, no matter geographical location, timezone or accessibility requirement. They are an effective way to discuss approaches, spot edge cases and squash bugs before they make it to production.
Reviews allow contextual discussion and provide specialized tools to explain thoughts (GitHub’s code suggestions are a great example of this).
They’re a second brain giving code extra consideration. They provide an opportunity for quality assurance, to spot issues to address, clarify any unclear code and discuss the approach taken.
They help businesses meet security requirements. For example, ISO 27001 is “the world’s best-known standard for information security management systems”. ISO 27001 describes having “secure system engineering principles”, and whilst it’s not a specific requirement, code reviews can be considered a contributory factor.
Code reviews are not only for providing constructive criticism — comments can praise clever solutions too. They’re a way of letting someone know that you like what they’ve done, perhaps that it’s helped you or taught you something.
Most importantly, code reviews are a huge chance to learn. Some of the most valuable improvements to how I approach and write code have come from the feedback I’ve received in reviews, and they were invaluable when I changed the programming language I was using.
Give the correct feedback at the proper time
The 30/60/90 feedback framework helps guide the kind of feedback an author seeks, and it’s a tool for both those seeking and giving feedback. As a brief overview of what these different stages are:
- 30% is for feedback on the approach itself. At this point, you have a good idea of how you’d like to solve the problem, but you’d like other thoughts to avoid any later course corrections.
- 60% is for when you’ve finalized the approach, and a draft of the implementation is ready. You’re looking for things you’ve missed, potential improvements or alternative methods.
- 90% is for final tweaks and seeking final approval. It’s the last feedback step, and at this stage, all of the feedback you received at the 60% stage will have been addressed.
When doing a code review, use this kind of language to understand the feedback you should be giving. Ideally, this will come from the code’s author (perhaps using labels) — if it doesn’t, then there’s no harm in asking.
Giving the right kind of feedback at the right time is essential. Imagine you’re at the 90% stage, and it’s decided the approach needs to change. You could have to re-work everything you’ve done. It’s hard to receive that feedback as the author; it’s difficult to give it too. That doesn’t mean you shouldn’t — it can be unavoidable — but always try to avoid it by feeding back (and asking for feedback) early and often.
Ask for clarity
Code reviews are not just for enabling more experienced developers to provide feedback on more junior developers’ software. Juniors can and should give feedback in the other direction, which can significantly improve the code.
We’ve already said this, but — when reviewing code, you should ask if you need clarification about what a piece of it does or how it works. There are many reasons why asking questions about things you don’t understand is a good thing to do; for code reviews, I want to pick out two key reasons:
- It’s an opportunity to cement some understanding.
- It could result in more readable code.
Occasionally we all need help understanding a piece of code. We pick up ways of writing software that we know but may still be unclear to others. Asking for clarification will, at worst, teach you something new. Still, it may prompt a rewrite to more self-documenting code, improving it for everyone.
Encourage discussion
Asking for an explanation of code you need help understanding will invite discussion, which will (sometimes) act as a prompt to make changes. That’s what a code review fundamentally is — a discussion. As a junior, you can encourage discussion because of your fresh viewpoint. You don’t have years of habits subconsciously biasing the work software you write, and you can use that to help all of your colleagues. The perceived reasons for not being able to contribute to code reviews are the best reasons to do so.
In Summary
Getting into the habit of doing code reviews and building confidence in your ability to do them takes a lot of work. Still, I’d encourage you to keep trying. Start small if it helps, lean on the developers around you to build that confidence and make sure, as much as possible, to give the proper feedback at the right time. It will get more accessible, and you, and the people you work with, will be much stronger developers because of it.