Ship fast without breaking things

Every team slows down as it grows. More people, more code, more meetings, less shipping. It doesn't have to be that way.

These essays dig into velocity, teamwork, and taming complexity — the engineering side and the people side. They're the thinking behind Scaling Fast, my book on software engineering through hypergrowth.

Essays on shipping fast

May 2025

Software architecture IS Conway's Law

Can you even have architecture before there's a team?

Common abstraction traps

Here's a few common abstraction traps that suck you in, look like they improve your code, then turn into bad ideas as your system grows.

DRY – a common source of bad abstractions

The worst and hardest to maintain code that I've seen or written has been in pursuit of DRY

Stateless decision making

Do you ever feel like your brain is full and there's so much going on you can barely keep up? Me too.

How do you find time for cleanup work

A reader asks how do you find time for technical cleanup work. If OKRs and bugs take priority, when will you make improvements?

April 2025

Say no to abstract code

The trick, then, is to keep related code close together to reduce context boundaries and to limit the amount of relevant detail so it fits in your working memory.

re: The Industrialization of IT

I guess if AI is what it takes to finally get people to care about architecture and team structure then mission accomplished?

What to work on next?

Younger engineers keep asking how I prioritize in a chaotic environment. Here's my approach.

Always deploy at peak traffic

A hard-won lesson for ya: Always deploy when you've got lots of traffic.

The difference between a product and a project

A project is something you do, a product is something you own.

March 2025

Sprint vs Shape Up vs Kanban

Whenever I talk about sprints, someone mentions Shape Up. So you have 9 week sprints – what's the difference?

Why sprints

For the past few months I've been introducing sprints into a chaotic startup that's been growing so fast everyone's got whiplash. Since August, 5 engineers turned into 12. I think it's starting to work.

Principles of high output engineering teams

A few engineering principles I aim to instill in every team I join. Lead or not.

February 2025

Code yourself out of the job

Let go of your legos and let others do the work.

A pattern for composable UI in Flask

Turn your unwieldy Flask codebase into manageable, composable fragments with this UI pattern. Very close to HTMX.

How *do* you break down a large project? INVEST

Going from Big Vision to Series of Executable Steps is a key skill for senior+ engineers. PMs can help but they don't know everything.

January 2025

How do you prioritize?

How do you choose what to work on first? As an empowered engineer that's a key skill.

Build the abstraction first

Hardcoding logic when you're tight on time doesn't need to make a mess. You can build the abstraction first!

What I learned from Accelerate

Accelerate is the empirical research behind books such as The Phoenix/Unicorn Project and (parts of) Software Engineering at Google. I loved it.

Coaching AI to write your code

Working with AI is here and it's skill. Just like google-fu became important in the mid 2000's. A few things I've learned.

December 2024

Looking for beta readers

Wanna read my hardest engineering lessons learned? You're in luck!

Atoms, molecules, organisms

Here it is: 20+ years of programming experience distilled into 378 words. From the book I'm writing.

Smart core, thin interfaces

Here's an approach to writing code that I've been using for years and couldn't quite put into words until now. One of those _"This feels wrong but I can't explain why"_. Now I can!

Why learning and teaching the good stuff is hard

You can't learn to ride a bike from reading a book.

Empirical evidence for code modularity

Few of your engineering decisions matter long-term. Software is soft. You can change your mind. But how you structure your components is here to stay.

November 2024

Why even care about code structure

As long as it works, right?

Finding modules in a big ball of mud

Pulling modules out of a big ball of mud is like grabbing a slice of cheesy pizza. It's kinda separate but also not really.

Why you need observability more than tests

Here's a short and sweet story about a Friday deploy. I love Friday deploys.

The swarm doc

Here's a doc I like to use to structure the pre-work design chat that makes later code review a breeze.

Big Ball of Mud – the world's most popular software architecture

Forget Gang of Four, here are the 7 architectural patterns real programmers use: