2/19/26
I think that a lot of the reasons that people cite PRs as a great practice fall apart in reality. They are true SOMETIMES. I have had them be true with good teams.
I think a lot of teams I’ve work with are just not “good” teams. In the sense that they’re normal ass people who have day jobs and then go do stuff in their free time they actually care about. Pretty reasonably effective people!
I think the “value” of PRs are hard to get. They take work and trying to reach. The default status quo for PR review I think is more about wasting time.
I think processes that require discipline and effort to maintain are usually brittle and not so great to rely on. Your systems should optimize for failure recovery.
2/17/26
i want to write about hating pull request review
- Computational kindness is often missing
- I want a PR to be as easily reviewable as possible
- Separate types of changes
- Don’t mix tidyings with functional changes
- Stacked PRs
- Comments
- Review my own PR first and add explaining comments
- When I’m being good, make those changes in the PR instead of making the comment
- Waste of time frequently
- Tidy First? suggests not needing review on tidyings
- Ship Show Ask suggests using your good judgement to decide if you need a review