The Theatre of Pull Requests and Code Review
Meks McClure · September 23, 2025
I recently attended the Goatmire Elixir Conf and one of the standout talks for me was Saša Jurić's "Tell Me a Story". It was an incredible presentation that combined theatrical storytelling with practical technical advice. Saša performed parts of his talk in character, turning technical topics into a compelling narrative that was part comedy, part tragedy, and fully packed with useful insights I've started implementing myself. The recording will eventually be released online for viewing. I highly recommend that people watch it, and I'll endeavor to add a link to it here when it becomes available.
The Code Review Challenge
The talk focused on Code Review and Pull Requests (PRs). Saša laid out common problems most software engineers face. Too often, engineers dread code reviews even though they're a significant part of team collaboration. We avoid them because PRs tend to be too large, too complex, too difficult to comprehend, and too painful to test. So we end up commenting "Looks Good To Me" and suggesting a few minor styling improvements to give the appearance of a thorough review.
This is how security leaks happen and codebases become progressively unmaintainable. Since git blame only points to the original author, it's easy to think "if something goes wrong, it's not on me". But we're all responsible for the whole system, regardless of who wrote the individual lines of code.
What Makes a PR Reviewable?
So how do we review something that feels unreviewable? Saša advocates for normalizing the practice of returning difficult-to-understand PRs to the author. This makes logical sense, but it's challenging to implement because it can feel like admitting we're not smart enough to understand the code. However, saying "I don't understand this enough to approve it" is far more valuable than pretending with an empty "LGTM".
If we commit to only reviewing truly reviewable PRs, what does that look like? According to Saša, it should take the average reviewer 5-10 minutes. By 'average reviewer,' he means mid-to-senior developers who understand the domain, business, and tech stack well—not newcomers still learning the system or mythical 10x engineers.
How do you create a PR that can be reviewed in 5-10 minutes? By reducing the scope. A full feature should often be multiple PRs. A good rule of thumb is 300 lines of code changes - once you get above 500 lines, you're entering unreviewable territory.
... continue reading