What do I mean by “reviewing your own pull requests”? Obviously, it means going through the code you’ve pushed with the tool your team would use to review. I would guess that it is obvious in one way while obscure in another. Indeed, we all skim through our code in the IDE prior to opening a PR. However, do we really see what we need to see? Do we really pay attention to everything or overly rely on our team and tools to catch potential issues? Can you improve your code review experience by reviewing your own pull requests?
If you paid attention to my LinkedIn history, you might have noticed that I changed jobs a few months ago. Upon doing so, I joined a team where I spotted a practice I had not seen before. I could see signs that the other devs reviewed their own code before submitting it for review. By signs I mean comments within the pull request. I spotted several kind of comments and I will share three of these with you since these were valuable to me and you might find value in knowing about them.
1. The moved file
Sometimes, you can have a file moved from one package to another and the tool you use for reviewing code may show it as two entries. A deleted file on one hand and a new file on another. Adding a comment to highlight this will save valuable time for both yourself and your reviewer. While you might not need this one for tiny PRs with a couple of file updates, this becomes a lifesaver for those with dozens of files and hundreds of changes.
2. The design choice
Unless you work in on a project where all architectural decisions are already made to the line of code, you may have multiple options to solve a problem. While the big ones may get discussed upon kicking off a story/task, some will be down to you.
This tends to happen when options appear to you as you implement a solution for something that is trickier than first thought. In these situations, it may be faster to implement one or two different solutions and weigh them against one another than going to the drawing board.
You will want to reflect that in your pull request possibly by listing the options you looked into and why you chose the one you picked. This way you can save both yourself and your reviewer time they might spend asking about the options you didn’t pick. Heck, maybe they will come up with a third option between the rejects and the chosen one which will lead to better software. Everyone wins.
3. Dead code
Sometimes, you maintain a piece of software older than Tiktok. Something that someone, maybe yourself, implemented dozens of news cycles ago. But now, you realise that all the services which used that code previously aren’t anymore. Maybe your IDE let you know this is a piece of dead code. So you delete it. But your reviewer might ask why you deleted it.
Now, unless you keep refreshing your pull request tool to see the latest reviews, you will wait until you get a notification about the question. Then you will answer, and the reviewer will get an email notification that you replied. If you’re lucky, this will take an hour only from the moment the question is asked to the moment it is answered. Do you see the problem here?
The solution is to just say it outright in your pull request. You’re deleting that class or method because there are no more dependencies on it. Simple as that. And the bonus is that your code gets reviewed faster by a happier person.
Closing thoughts
Reviewing your own pull requests is not something I ever thought of before and it’s definitely an improvement in my experience of code reviews. Both as a reviewer and a reviewee, I found that this massively speeds up productivity.
This is all new to me and I am still discovering and improving upon this newfound tool. Still, I am looking forward to finding out how much better it can help me become. I hope you found this useful and will start reviewing your own pull requests today.
