Same Shape, Different Stack

For a while now, I've wanted to get better at shipping features accurately, especially on the kind of feature work where a bad release has real consequences. I kept turning the question over. Was I catching the right things in design review? Was I writing unit tests that actually covered the risky paths? Was the regression suite deep enough to catch what slipped through? I knew the development-to-testing cycle was too long, but the path to shortening it while still exercising enough code paths was genuinely unclear.

Around that time, I came across a talk on TestContainers, a library for integration testing that spins up real services like databases and message brokers inside Docker containers, controlled directly from test code. It got me thinking about whether something like this could shorten the cycle I'd been stuck on.

As I dug in, it became clear that the problem I'd been stuck on wasn't specific to my team's infra or workflows. Other teams had hit the same wall years earlier, worked through it, and written up what they learned. The talk I'd stumbled on was itself a version of that. Someone decided to document a problem-shape and a way through it. It made me wonder how many other problems I was quietly working around had already been solved elsewhere.

Strip away the stack, and a lot of problems start to look like each other. Long test cycles aren't a backend problem or a frontend problem. The same feedback-loop problem shows up in data pipelines, API development, and ML training. While the specifics differ, the shape doesn't. Once you can see the shape, you can start recognizing it in places that look nothing alike.

The hard part is that these patterns aren't obvious when working inside any one team. Each codebase has its own vocabulary and its own constraints, and a problem framed in local terms can look novel even when it isn't. You only start to see the shape after you've seen enough variations across examples. It's a little like the secretary problem; you can't judge what you're looking at until you've seen enough of the set.

Most engineers build up this pattern-recognition over time. You see enough variations in your own industry and the shapes start to come into focus. What this blog is trying to do is take some of those patterns, the ones I've seen enough of to feel confident naming, and write them down with examples.

Much of what I know about this work came from other engineers who wrote things down. Someone wrote a talk, a post, a paper, and I found it when I needed it. That's how knowledge travels. This blog is me adding to the pile.