However, in recent times, I’ve found myself making similar mistakes in my pull requests, or doing things I’ve already been asked to do differently. While learning something new, there’s a lot to remember and try do properly, and it turns out I couldn’t remember it all in my head. I found this embarrassing and it lead to a fair bit of frustration within me, not to mention the understandable disappointment from the domain expert trying to help me. After a bit of thought, I thought enough was enough and it was time for a solution.
I settled on what I call a “Self-Review Checklist”. It’s a list of things I’ll check as I’m doing my self-review of my code before sending it to the reviewer. It often finds a bunch of things to fix that occurred during the development process.
I created this list by spending about an hour and going through all the previous code reviews I’d received. I made a list of every comment I’d ever got that was generic enough to apply to other codebases or in future reviews. Here are some from my list:
Make sure you’ve got eslint on and working
Can you use .map instead of .forEach?
Put utilities in well-named files in the right directory
Check logging to the error reporting service sufficiently masks any sensitive data
Have you used “any” in TypeScript only when you cant type it thoroughly?
At the moment, these things are listed just to prompt my memory and don’t have examples or further explanation than required. I think this is okay because this list is meant for my personal use. I don’t intend to share it, nor do I think it should be some sort of checklist all developers on my team follow. These are things that I found non-obvious , or that I need to work on to make code that fits my team’s expectations.
I’ve been using this list for about two months now and I’m proud to say that I think my code reviews have gone much better. I feel more general satisfaction from my reviewers, and they’re able to point out even more detailed things I can work on, or point out even new things I can learn from – and I really love that. I’ve even used this list with my reviews of other’s work too – and has made me a more effective reviewer.
I intend to remove some items when I become more confident that I’m in the habit, but for now I’m keeping the complete list. Am I making the same mistakes now though? Often not, which is great and signs that I’m proceeding through theConscious Competence Learning Model.
While the checklist has helped enormously with my code reviews. I have no doubt I’ll still make mistakes. And I think that is a completely reasonable thing to happen. If I didn’t, then code review would be pretty pointless wouldn't it? However, taking the time and having the discipline to thoroughly self-review eliminates a lot of high-level silly mistakes and lets the reviewer focus on the important parts of the review. As a reviewer, I am careful not to be quick to rage or abuse when a team member makes mistakes like this, it is just that - a mistake. They’re not out to annoy me or have any malice at all. I’ll leave a simple comment such as “left some commented out code here” or “oops, looks like this is still hardcoded?”.
However, my new expectation is that if I’m pointing out something for the second or third time for the same team member, then I will experience disappointment and frustration - and I’ll likely voice that. Similar to what I’ve done for myself, I’ll put the responsibility back onto the team member to correct. I love the code review process, and I’m passionate about making it better in every team I join. However, individuals also need to take ownership of their code reviews and make sure its a positive experience for them and the reviewer and make sure it’s effective as possible.
In conclusion, I thoroughly recommend self-review checklists as a tool if you’re experiencing similar issues at your work. Even if not, I think the act of reflecting thoroughly on code review feedback as I do now will further cement and accelerate your learning.