High/Low Zeitgeist, Cargo Cult, PR Stampers

A lot of the things we do as part of making software in venture-funded tech are both deeply embedded and considered heretical to question. Two-week sprints, story points, daily standup, OKRs. Pull requests and thorough code review of every change have always had a waft of the cargo cult to me. For a generation of engineers, pull or merge requests are just what you do, as part of the environment as breathing air or drinking water: you write or change code, then you submit your changeset to a teammate for them to review, then after they get around to it, you respond to your teammate's sometimes valuable, sometimes arbitrary comments, resubmit for review, and finally once they get around to re-reviewing (while you explain to your teammates and an anxious EM that your change is "stuck in code review"), you update your PR, deal with merge conflicts, and finally finally merge your change.

I remember the early days of my career when "code review" was when - maybe once a month, maybe less frequently - a peer or supervisor would ask you to print out(!) code you'd written recently so they could review it and give you their thoughts. It was useful as a point of reflection, an opportunity for coaching in a private space with the pressure off, the feature already long in production, the guidance mostly aimed at the next change and how we wanted code to look going forward.

My primary problem with pull requests and code review isn't about doing them, it's about doing them on every change. Changes are always different. Some are very risky, and those are the changes that deserve the thorough review treatment - often by more eyes than the get one approval and merge system requires. Other changes are low risk, and should be made as quickly as possible with as little ceremony as possible. But the cargo cult requires the check.

I've always dreamed of a triage step, whereby a PR was assessed as risky - worthy of a thorough review, often more thorough than it would get otherwise - or non-risky, in which case it would be allowed to be merged without review. The two problems with this were (a) someone had to look over the change to determine the risk, and once you've done that, you might as well just do the review (b) there is no b, that's the whole problem right there: you have to do most of the thing in order to know if you need to do the thing.

It's 2026 though, and now we have agents capable of discernment. So I've been working on a PR stamper, a way of deciding that a change is low risk and providing an auto-approval that lets the author choose whether they want human eyes on their change or not. Iterating on it, thinking about it in the shower, taking notes on it, and also working on a post about it.

Then I looked at Will Larson's blog the other day, and I saw he's written my post: Speeding up code review with small-change. Which I know is going to be better than what I would write, because Larson is a fantastic writer.

I don't think this is an accident. Much as I try to restrict my exposure to social media, I'm sadly very online, and being very online plugs you into the zeitgeist in the niches you're involved in. Larson and I aren't plugged into some telepathic connection, and he hasn't hacked my drafts folder. He's also just very online, very plugged into and in his case part of the zeitgeist, which in software development is what roughly 50 or so people - including Larson - are thinking and talking about.

It made me think about my peers at work, and how some of them are also very plugged in to what's happening in tech and making software, whereas others are not in the least. Being plugged in has a lot of advantages. A lot of community practices are battle-tested, the sorts of things where you can eliminate hundreds of downstream decisions by defaulting to one easy choice. Also, teams tend to build trust fastest when they share values, and while those of us in the management set might hope those are company values, often it's community values that more readily bought into and transferable.

There's also disadvantages to being High Zeitgeist. The obvious one, at least to me: Social media is literally trying to make everyone's problem into your problem. Another disadvantage: when there's a whole community out there bearing ideas, it's much easier to just source your ideas from that group without questioning them. Complacency is the nature of the beast, and the game remains a battle between our desire to win and our desire not to think.

Some of my all-time favorite peers have been Low Zeitgeist: perpetually unplugged, smart people who see and listen well, notice things that work / don't work without the bias of community group think, then act when they see they can effect change.

It got me thinking that the best teams weave the two together. The current community defaults form a sort of starter pack of practices. And then if you have enough people who aren't plugged in, they can discern which of those have real value, and which are cargo cult. And if you have enough people who are plugged in, new practices that arise will naturally flow into the shop and be tested.

And as for code reviews? Maybe it's time to swing the pendulum a bit back towards the old days, and think of them as a once a month / once a quarter review of what's been done, how it's performed in production, and what we can take away from it.