davidpoll.com
Building systems, writing about engineering, and learning in public.
Posts
-
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.
-
The Difficulty Cliff: Why Building Software Has Never Been Smooth (Until Maybe Now)
Continue reading →How every abstraction in software creates walls, and why AI might finally demolish them
The learning curve for building software is a lie. It’s not a curve at all—it’s a jagged mountain range with sheer cliffs where the trail suddenly ends.
You’re cruising along with your no-code tool, dragging and dropping your way to success. Everything’s great until you need that one custom calculation, that one specific integration, that one behavior the platform didn’t anticipate. Suddenly you’re not climbing anymore—you’re standing at the base of a cliff, staring up at “real” programming.
Welcome to the difficulty cliff. After so many years building developer platforms, I’ve come to believe these cliffs aren’t bugs—they’re the fundamental challenge of software abstraction. Every tool that makes development easier eventually hits a wall where its abstraction breaks down.
But what if AI could finally smooth this curve? Not by building better walls, but by eliminating them entirely?
-
The Art of Letting Go: Why Your Platform Needs Less Control Than You Think
Continue reading →After nearly two decades building developer platforms, I’ve learned that the moment you truly succeed is when developers find magic in places you didn’t mean to put it.
This is terrifying. It’s also the point.
I’ve been thinking about this a lot lately as I watch the next generation of platforms struggling with how much control to maintain. The instinct is always to constrain, to guide, to protect developers from themselves. We add guardrails, validation, prescribed patterns. We tell ourselves we’re preventing footguns. Really, we’re preventing discovery.
-
The Only Way to Build Trust Is to Give Trust
Continue reading →A former report reached out recently. It was one of those unexpected messages that stops you mid-scroll, the kind that makes you put your phone down and actually think.
They wanted me to know I’d been a good manager. More specifically, they remembered how I’d believed in their technical leadership ability early on—perhaps before they believed in it themselves.
I sat with that for a while. Not because of the compliment, but because it crystallized something I’ve been practicing and preaching in one-on-ones since becoming an engineering manager: The only way to build trust is to give trust.
It sounds almost tautological when you write it out. Of course trust requires trust. But here’s what I’ve learned in my decade as an engineering manager, across multiple companies, one failed startup, and three kids: most of us do it backwards. We wait for trust to be earned. We require proof before we extend belief. We manage risk instead of enabling growth.
And in doing so, we become the limiting factor in our own organizations, relationships, and lives.
-
The 4p Developer: The Missing Layer in Platform Thinking
Continue reading →Every successful platform has them. They’re worth billions. Yet we don’t even have a name for them.
I’m talking about developers who build tools for OTHER developers on your platform. Not your internal team. Not external app developers. The fourth party that makes platforms explode.
I’ve been calling them “4p developers” throughout my career building developer platforms at Microsoft, Parse, Firebase, and Google Cloud. I wanted to share this framework because if you’re building a platform without thinking about them, you’re leaving massive ecosystem value on the table.
subscribe via RSS