Code review is one of the best practices for sharing knowledge between colleagues, leveling up skills, and knowing each other’s limitations, including your own.
Why?
When you’re doing a code review for a co-worker’s code or for an open source project, you’re probably in at least three positions:
- You already know most of the code and can contribute to a better arrangement or point out the impacts of the new code;
- You don’t know anything about the project, but you know the syntax and can contribute to better code style (yeah, I know the lint tools can do this automatically);
- Or you’re an apprentice learning new things, and others can guide you through the code.
But as we’re learning something new every day, we can move between these positions depending on the area of the code being reviewed. For example, I’m a full stack software developer and can contribute to each layer of an application. However, a more specialized colleague can deliver more useful input about, let’s say, frontend code.
For example, one day a frontend co-worker asked me to review a pull request with a code change that looked like this:
this.setState({
- id,
+ id: +id,
})
Since I didn’t recognize why he made this change, I asked him, and he said it was
to convert an id variable from a string into an integer.
I’ve always learned something through code reviews, because they force you to understand the reasons behind proposed changes, and sometimes I didn’t know or couldn’t think about it before.
Another example happened to me about 7 years ago, when I got my second remote position as a software developer working with Ruby on Rails. I was highly motivated because I had just gotten that position, and I wanted to deliver my first pull request there. I made the proposed fix with good test coverage, submitted the pull request, and received my first rejection from my team leader, who questioned the tests I had written. The unit tests I wrote used some metaprogramming (common in Ruby), and the feedback was: “The tests should be as explicit as possible, and you should avoid this kind of approach, because it adds complexity and reduces readability.”
After that, I knew I needed to get better at reviewing others’ code and wanted others to do the same for me.