Looking back on my two-year journey as a software engineer, one of the areas where I experienced most growth is code review 🔍. I knew next to nothing about code reviews when I started my current job in 2022. Thanks to my supportive team members and online resources, I’ve adopted a personal mantra on code review: I Choose the Intent to Learn 🌻
One of the biggest challenges I faced during my early days is my own insecurity. When I was assigned as a reviewer, I would think to myself I don’t really think I have anything useful to add because I am still new to everything! I’d have the urge to automatically approve when the pull request creator is a senior engineer, since I believed that I had nothing to comment on a PR of a senior developer.
During a one-on-one meeting with my manager, I shared my feelings about code reviews and he kindly pointed out that I don’t need to provide constructive feedback for every pull request, and it is absolutely okay for me to ask clarifying questions if I don’t understand a particular line of the code 💛
It was then that I realized that my intention was a bit off when code reviewing. I had the intention of trying my best to spot any potential flaw and therefore providing a useful review. However, code reviewing is not limited to a one-directional activity where one side purely gives and the other side purely receives. It can be a two-directional activity if you set the intention to learn while you review others’ code.
This mindset shift drastically reduced my anxiety around code reviews and also taught me the power of our mindset and intention ✨. When I choose the intent to learn, I also find it easier to give constructive feedback since my mind is open and calm.
What is the code doing?
- do you have the right background info?
- do you fully understand why this code is needed?
- do you understand how this code fits into the project?
Frame your mind
- how experienced are you with the codebase/language?
- are you going to be using this code in the future?
- have you written code similar to this?
- what is the experience level of the author?
- what is your relationship with the author?
Test the code
- does the code generate warnings/errors?
- does the code take longer than normal to build/run?
- do the changes require any additional setup steps?
Inspect the code
- are correct naming conventions followed?
- does the code follow DRY principles?
- are new files/folders named appropriately?
- does the code have error handling?
- is the code written in a similar style to other code in the project?
Compile your review
- beware of bikeshedding
- be respectful
- be specific and descriptive
- be open to follow-ups
I’ll keep updating this post as I move along in my career 😊
Resources for Code Reviews:
Top comments (0)