If you’ve ever had to go through the process of a code review then I’m sure you’d be familiar with the time-honored tradition of raising a pull request and having your hand-written code critiqued. This is something that I’ve traditionally disliked. It’s slow, can be distracting, and if I’m being completely honest, I don’t like hearing that I’m wrong. Who does? However, as a new member of my team, I thought it best to do things the right way and I found myself relying heavily on the code review process. For me, what I had once considered a mere a rubber stamp on my work became a process that helped me identify inconsistencies in my code style and validated that I was still capable of writing Java. The code review became such a positive experience for me as a JIRA Software engineer that I started thinking I’d been unfairly harsh on the whole code review process and that I needed to change my perspective.
Better than yesterday, not as good as tomorrow There’s a UK hiphop artist called Scroobius Pip and you’d be forgiven for not being familiar with him, but in the context of code reviews he’s important for penning the following lyrics: If your only goal’s to be as good as Scroobius Pip Then as soon as you achieve that your standards have slipped If your goal is always to improve on yourself Then the quest is never over no matter how big your wealth You see, it’s important that we all strive to be better at everything that we do. That doesn’t mean comparing ourselves to others, but rather taking the time to look at ourselves to compare the way we do things now against the way we did things yesterday and the way we want to do things tomorrow. Improving our own skills and techniques is a good practice and makes every day a challenge.
Check your code review technique
Code reviews are an integral part of development culture at Atlassian and many other companies, but it can be easy to treat them with a certain amount of disdain. Us devs often find ourselves on the receiving end of a code review feeling tempted to give it only a cursory glance before clicking the approve button, or maybe waiting until someone else completes it before submitting our own approval without checking the changes. And when a code review is created, we may not always provide the necessary context around our changes or set up an instance to allow our reviewers to validate our
changes easily. Lastly, we often fall into the trap of taking feedback on our code as a criticism of our abilities rather than an opportunity to hone our skills.
The thing is, different people will identify with the role a code review plays, well, differently. Some may view it as a method of identifying errors in code, a form of testing, a rubber stamping process, or even human linting. To make the most out of each code review it’s worth considering the benefits it offers to your own development, and ask yourself: How does this review to help me grow as a developer?
Keep coding, keep growing
The crux of the matter is that the code review process is a great opportunity to take stock of your work. You might find better, more effective ways of implementing solutions, or practice the valuable art of providing concise and easy-to-understand feedback. Code reviews could also help you improve your depth of knowledge in a specific product, library, or language; or even just increase your ability
to read, understand, and reason about other team members’ code. There’s always something new to learn in even the most mundane of code reviews. Next time you’re starting a code review — whether it
be as a reviewer or as someone creating a review — start by asking yourself how it can help you and your team grow. Hopefully it will lead to a more fruitful experience for you and everyone else involved and, as we all grow, the quality of what we produce will grow too.