Marc's Blog

About Me

My name is Marc Brooker. I've been writing code, reading code, and living vicariously through computers for as long as I can remember. I like to build things that work. I also dabble in machining, welding, cooking and skiing.

I'm currently an engineer at Amazon Web Services (AWS) in Seattle, where I work on databases, serverless, and serverless databases. Before that, I worked on EC2 and EBS.
All opinions are my own.


My Publications and Videos
@marcbrooker on Mastodon @MarcJBrooker on Twitter

The Builder’s Guide to Better Mousetraps

A little rubric for making a tough decision.

Some people who ask me for advice at work get very long responses. Sometimes, those responses aren’t specific to my particular workplace, and so I share them here. In the past, I’ve written about writing, writing for an audience, heuristics, getting big things done, and how to spend your time. This is another of those emails.

So, you’re thinking of building a new thing. It’s going to be a lot like that other thing that already exists. In fact, it seems so similar that lots of folks are asking you why you’re building a new thing rather than using that existing thing, or maybe adapting that existing thing to your needs. Those people have the right general instincts—rebuilding a thing that already exists and works is seldom a good bet—and you have other important things to do. On the other hand, you seem convinced that your thing will be better in important ways. You also point to a long history of innovation where folks had similar doubts. That, too, is correct. After all, Newcomen and Savery’s steam engines weren’t much better than what they replaced (and ended up being a pretty big deal).

I tend to be biased towards innovation. Towards building. I think most advice for technical leaders over-emphasizes the short-term risks of innovating too much, and under-emphasizes the long-term risks of innovating too little. However, both sides have good points, and we owe it to ourselves and our businesses to think carefully about the decision. Because of my bias, I force myself to deeply question my motivations when making decisions like this.

Its worth mentioning that this thinking is related to, but distinct from, the classic build vs buy decision. The thing you want, the thing you really need, doesn’t seem available to buy.

Here are some questions that are worth asking yourself as you make this decision (then write down your answers):

The decision you’re trying to make here isn’t really a one way door. But the decision to build here is expensive, risky, and comes with a significant chance it’ll distract you and your team from more important things. On the other hand, it could mean that you get much better performance or cost or flexibility. This is the kind of decision its easy to be wrong about. So I’d suggest you answer my questions, and write down your answers. Then sit down with some smart people you trust and see if they believe your conclusions.


  1. Couldn’t solve at the time. One of the really satisfying things for me about Firecracker is how much it’s turned out to be a catalyst for innovation in this space.
  2. If your answer is we’re smarter or we’ll work harder or variants of that, then you need to deeply examine your assumptions. Maybe you are, maybe you will. Or maybe you’re not, or won’t, or can’t sustainably.
  3. There are also some interesting, thought-provoking counter-examples. For example, I would have expected the rise of SSDs (and the 1000x step change in random IO latency that came with it) to lead to a new generation of database engines dominating, built from the ground up to take advantage of the hardware. Seemingly against the odds, PostgreSQL (and MySQL and others to a lesser extent) is as dominant as ever, despite being built for the steampunk age of spinning media.