davidpoll.com
Building systems, writing about engineering, and learning in public.
Posts
-
Software Is Not A Single-Player Game
Continue reading →When I wrote a few months ago that code review is not about catching bugs, the most common pushback I got was a variation of the same thing:
“If you’re only getting to that decision at the code review stage, you skipped a step. The basic call about whether to build this should have come much, much earlier – at the design doc stage, before code was written.”
I find that argument partly right. The earlier steps it points to – thinking through what to build, why, with what shape, at what cost – are real and important. They don’t disappear in a faster cycle. If anything, they matter more.
Here is something this pushback concedes without quite meaning to. By saying “you skipped a step,” it acknowledges that the SDLC has multiple stages where judgment matters. It doesn’t claim the only judgment left happens in production, or that pull requests are a relic. On that, I agree.
What it gets wrong is the shape of those stages. It treats them as fixed, sequential, and largely complete before code is written. They never were. AI is making the rigidity less tenable by the day.
Underneath all of that is a deeper assumption: that the multiplayer part of software ends before the code exists. People hash things out in documents and meetings, and then development itself is a single-player game. Get the upstream call right and the rest is execution. Code review becomes a checkpoint to verify individual work, and the optimization is to make the checkpoint smaller and earlier.
Much of the current AI development discourse goes further and assumes there was never much of a multiplayer part at all. Either way, the assumption has a ceiling.
What I actually want to argue is that building software that lasts, grows, and that people can depend on is and will remain a multiplayer game. The earlier stages this pushback points to are part of that game, not separate from it. Code review is one of the primary places where the game gets played, and the artifact the game is played on is shifting in a way that makes review more central, not less.
-
Code Review Is Not About Catching Bugs
Continue reading →My former Parse colleague Charity Majors – now CTO of Honeycomb and one of the strongest voices in the observability space – recently posted something that caught my attention. She’s frustrated with the discourse around AI-generated code shifting the bottleneck to code review, and she argues the real burden is validation – production observability. You don’t know if code works until it’s running with enough instrumentation to see what it’s actually doing.
She followed up by endorsing Boris Tane’s piece arguing that the entire SDLC is collapsing, with monitoring as the only stage that survives. Boris goes further than Charity – he argues the pull request flow is a relic, that human code review should become exception-based, and that clinging to it is “an identity crisis.”
She’s right about that. And I’d go further: if your primary strategy for knowing whether code works is having other humans read it, you have bigger problems than AI-generated code.
But I think the “code review is the bottleneck” crowd and the “no, validation is the bottleneck” crowd are both working from the same flawed premise: that code review exists primarily to answer “does this code work?”
To be fair, finding defects has always been listed as a goal of code review – Wikipedia will tell you as much. And sure, reviewers do catch bugs. But I think that framing dramatically overstates the bug-catching role and understates everything else code review does. If your review process is primarily a bug-finding mechanism, you’re leaving most of the value on the table.
-
The Temporary Ignorance Superpower
Continue reading →I’m about to start a new role leading a team I’ve never worked with. After a decade at Google, I’ll be the person who doesn’t know where anything is again.
I’m genuinely excited about that.
There’s a window when you join a new organization – maybe 90 days, give or take – where being new is actually a superpower. You can ask the questions everyone else stopped asking years ago. You can wander into long-standing debates and poke at assumptions without anyone assuming you have an agenda. “Don’t mind me, I’m new here” is a surprisingly effective shield for what would otherwise be career-limiting curiosity.
I’ve come to think of this as the temporary ignorance superpower, and I’ve learned to use it deliberately.
-
The Constraints That Create Autonomy
Continue reading →The conventional wisdom about autonomy is simple: remove constraints. Get out of people’s way. Let them figure it out. Trust them to run.
But this often backfires in a specific, predictable way. Teams think they have autonomy. What they actually have is ambiguity.
-
Orderly API Evolution: How to Break APIs Without Breaking Trust
Continue reading →I spent my baby bonding leave this summer with my newest kid — which was the point. But between feedings and naps, I also found myself trying to deeply understand coding agents and the new developer landscape. I wanted to see where this was all heading.
Building MCP servers was one of the experiments that surfaced something I hadn’t fully appreciated: MCP servers have wildly different audiences with wildly different expectations.
Consider the use cases:
- An end user uses a chatbot hooked up to an MCP server to accomplish some task
- A developer uses their coding agent hooked up to an MCP server to help them build something
- A developer builds an agent that uses an MCP server to accomplish something useful, potentially entirely under the hood
- A developer uses an MCP server’s tools directly as an API, bypassing the agent layer entirely
Not all of these may be good ideas, but Hyrum’s Law applies: with enough users, all observable behaviors will be depended on by somebody. That’s an overloaded interface. And when you start thinking about versioning an overloaded interface, suddenly questions like “what constitutes a breaking change?” get a lot messier.
subscribe via RSS