Ah code reviews… That dreadful, tedious task that interrupts your focus and takes time away from meaningful work. I can’t count how many times my code has sat in PR (pull request, if you’re unfamiliar with git lingo), lonely and waiting for approval by my fellow developers. It’s understandable that people put off code review for the reasons I mentioned above and many more.
As a junior developer (which I still am), I felt similarly towards code reviews. I didn’t like doing them. I thought, Why am I reviewing code written by senior developers? It’s not like I’m going to catch any of their errors. However what I didn’t understand at the time was that the code review was more for me than it was for them.
This became clear to me while I was reviewing a PR from a senior developer one day. While looking through their code I thought to myself, Wow! This code is really well-written — it’s readable, modular, and well structured…
I was learning React and Redux at the time, and if you know React, you’ll know that everything you do seems a bit weird at first. It’s hard to pick up on best practices on your own (at least I thought so), so being able to see how more experienced developers write components is a great way to learn how to write better code.
Once I was able to see code reviews as a learning opportunity rather than a check on my coworkers’ code, I was able to gain a lot of value from them. I began challenging my own way of writing code with the approaches of my more experienced coworkers and modifying my our approach along the way. I also began asking questions about why something was done a certain way if I didn’t understand it.
This change in mindset around code reviews meant I was able to pick up React and Redux much more quickly than I expected. Within just a couple weeks I was fully up to speed, completing similar amounts of work as the rest of my team and it was mostly because of the things I learned while reviewing the PRs of my coworkers.