Notes on "Review your own PRs"

Notes on Review your own PRs

The main point of the article is in the title: when you are done, open a PR and review it yourself before asking others to review it.

The people I work with are usually on top of things and can point out my mistakes, but the development loop is far tighter when you can proactively address such issues yourself.

A hack I’ve been using is to review my own PR inside the GitHub1 UI, as though it were someone else’s. My brain seems to switch to a completely different mode of operation when I do this. Problems that were previously invisible to me while looking at the code in my editor will all of a sudden become far more obvious. I’ve caught a lot of my own silly bugs by doing this, which frees up my team to do more useful and interesting work.

This is something I experienced myself: writing is a very different mindset than reviewing.

There is a useful hack I learned early in my career. When I'm finished with a feature, I sit down and play with it a bit. Whenever I encounter something that looks wrong, I write it down but I don't fix it right away. When I'm happy that I caught all the problems, only then I go through the list and fix the items.

What I found is that separating the coding from the QA helps finding all the defects instead of just the first few. A lot of time when I needed to review someone else's work it was trivially easy to find a way to break it.

Later I expanded on this by writing down just the names of the tests in a notebook. This allowed me to have a "specification mindset", one that allows me to think about edge cases without burdening with the implementation itself. Later, when I do the implementation I can focus on the specifics knowing that the big picture is already taken care of.

Separating work into different mental states is a powerful trick.

One other thing I like to do when self-reviewing is to attach discussion points about my PR inline where they are relevant. I’ll use this to flesh out local design choices and discuss alternatives I considered.

I'm not sure I agree with this one: a PR comment is short-lived and when somebody goes back to that piece of code a year later won't know where to look for the information. Commit messages or comments in the code feels like a better place for implementation reasoning.