It's hard to review code. You'd often much rather keep focusing on your own work. Code reviews break your focus. They also force you to interpret changes without seeing them in action, and without the assistance of an IDE. The result is a high cognitive load (it takes a lot of focus and thought) and a seemingly low payoff (it's someone else's work you're helping push forward, not your own).
I've found that with code reviews as with many things, a willfully stubborn attitude is key to doing it properly.
Next time you review someone’s code, try this. Pretend you submitted a PR yesterday and woke up today with no memory of having made that change. The code is already approved and ready to merge, but you don’t remember writing it!
So, would you merge it into production? Of course not! You'd need to be sure to understand what that code says because it’s got your name on it. You'd go through every line of that change and visualize how it works in real time. You’d think about the design implications. You might even test it out yourself.
So it is with reviewing the work of your teammates. Even if it’s not your change, you’re accountable for its quality. As a leader and a good teammate, it’s important to go further than eyeballing the change. You have to take it seriously.
It might take more of your time than you want to spend. So be it! Be stubborn in your insistence for deep understanding. The resulting software will be less buggy and easier to maintain. And your teammates will appreciate your commitment to making their work better.
Top comments (0)