Supplementary Guide to Code Reviews
Code reviews are hard; they are much harder to do than just writing code. The reason for that is the same as why engineers always want to redo things from scratch - you don’t need to try to understand your own ideas. Plus, your own ideas are always focused on solving things you know, so you don’t have to make even bigger efforts to get to know the problem space first.
After spending years at different engineering levels, on different teams with different coding techniques and values, I concluded that it is impossible to write a set of very detailed and specific instructions on how to do code reviews in general, so I’ve given up on that. Instead, in this rather short guide, I want to bring you a toolbox of ideas forming a specific mindset which, hopefully, should help you to build a quick and enjoyable code review process.
First, let’s get out of our way one thing that is commonly mistaken for code review: code review is not an evaluation of your work as a professional in general. It is not an exam and the result is not an indicator of you being a good or bad engineer; you won’t get marks. You have chosen the company and your colleagues already saw you as a valuable contributor; you have passed all the interviews. Now, we are building something great together.
