Pesky Pull Request Reviews

My notes on the article by Jessica Kerr, Those pesky pull request reviews

A pull-request review done properly requires the reviewer to load the purpose, code and tests into working memory and participate in finishing the change. Because that competes with the reviewer's nominal priorities, reluctance and delay are properties of the system rather than merely individual irresponsibility.

The usual workflow creates several queues: the author waits for review; the reviewer reconstructs context; requested changes make the author reconstruct context; and approved work may wait again for deployment. Starting another change “while waiting” converts these queues into more WIP.

Jessica advocates for pairing, mobbing, etc. so review and shared understanding happen during development rather than in a later approval queue. A pull request can remain a record or safeguard without being the first piece of communication about a code change.