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.
Top comments (8)
I also find doing my own code reviews useful.
Looking back on code I wrote perhaps even a year ago I sometimes think: "Why the hell did I do that, that's stupid?".
I also sometimes catch unused variables and unnecessary ones that can be refactored and/or pruned. The brain has a way of blocking things out when you're working on something that looking back a year becomes obvious as your brain thinks it's fresh code.
And as you're always learning, perhaps there was a function in an API you wasn't aware of so you wrote it or sculpted a workaround for it using other functions.
"When I wrote this, only God and I knew what I was thinking. Now only God knows."
Haha, I look back on code I wrote last week and think it's stupid. :P
Code reviews are a great way to learn by example, and another good way of skillbuilding for the author by teaching. I like to think that, suppose someone more senior wrote something overly complex. You could either ask about it to which they try to clearly explain, or maybe you interpret it as 'better' code, and you mimic the style which they later critique. You could then both go back to the original and distil it and wind up improving both pieces. Really nice post.
Yup! That's exactly how my experience went. I think It's important for senior devs to instil this (and other mindsets) into junior devs as they come aboard in an organization. It's often the most obvious things that are the most essential for doing good work, but since they're so seemingly obvious they are rarely ever taught. For onboarding junior devs, sometimes stating the obvious is just what's needed.
I found that good code reviews work both ways. Even seniors can learn a lot by reviewing code of (and getting their code reviewed by) junior developers. In fact, at my workplace we found so much value in reviews between juniors and seniors as a means of learning that we built a whole randomized code review process around it.
Amazing point of view :D
Guys, suggest me please code review tool. Preferably free solution.