About ten years ago, I started my career as a backend intern at a small company. Back then, the main product our team was working on was a multilingual hotel management software. After spending some time watching tutorials and practicing, the tech lead decided I was ready to contribute to the main project, so I officially joined the team.

When I completed my first task, I nervously sent my pull request to my manager. Before even opening it, he asked, “Did you review it yourself?” I was a bit surprised and said no. He told me to go review my own code first, fix any issues that you found, and then send it back to me. He also suggested that I do these reviews before committing my code and introduced me to git diff for the first time.

This simple habit has stuck with me ever since. Over the years, it has saved me from committing sensitive passwords, unnecessary logs, and even stupid code mistakes. It has also made life easier for my reviewers. Interestingly, every time I’ve skipped this step due to a lack of time, my pull requests have taken longer to get merged, with more back-and-forth comments. Eventually, I realized that doing the first review myself actually saves time for the whole team by reducing unnecessary iterations.

That’s why, from that moment on, I’ve always been the first person to review my own pull requests.


If you liked this post and want to see more, follow me at X/Twitter .