Review your own pull requests
You are probably stupid. No, I'm kidding. But every developer working on large changes makes mistakes. You lose focus, you forget things, you make typos. Reviewing your own pull requests can help you catch bugs and improve your code quality, leaving more time for your peers to focus on the bigger picture of your changes.
How many times have you created a pull request, only to have a colleague point out a console log you forgot to remove, or a typo in a comment? It happens to the best of us.
I have a simple trick that can help you catch these mistakes before you even create a pull request: review your own code. If you commit small and commit often, you may add some comments or console logs to version control that you don't want to be there. If you want more information on creating commits, check out my article on commit style.
What to look for
When reviewing your own code, you should look for the following:
- Syntax errors: Make sure your code is free of syntax errors. This includes typos, missing semicolons, and other common mistakes.
- Code quality: Check that your code follows best practices and is easy to read and understand. This includes using meaningful variable names, writing clear comments, and following any coding standards your team has in place.
- Testing: Make sure your code is thoroughly tested and that all tests and acceptance criteria pass.
- Documentation: Ensure that your code is self-descriptive and that any necessary comments or documentation are present and accurate.
This simple checklist can help you catch many common mistakes before they make to your peers. In my experience, it helps pull requests get merged faster and with fewer comments from reviewers.
If you receive a lot of comments on your pull requests, it can be frustrating and time-consuming to address them all. By reviewing your own code first, you can catch many of these issues early and save yourself and your team time in the long run.
Reiterate on your code
If you work at a fast moving startup you might not have the time to refactor the code you just wrote. Many times I have looked at my own code and thought: "What in the world was I thinking? I can delete this and this and this and it will be so much cleaner". If you have the time, do it.
You write the best code when you are writing it for the second time. You have the context, you know what you are trying to achieve and you can do it in a more efficient way.
TLDR: Take a few minutes to review your own code before assigning it to a colleague. You'll be surprised at how many mistakes you can catch and how much time you can save in the long run.
