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
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:
Why software only moves forward
At scale there are no rollbacks and no cut-overs. Your software only moves forward.
October 2024
"Yes caviar is great, here's a ham sandwich"
Why do some projects ship and others seem to drag on forever? You need 3 people to get this right.
Make mistakes easy to fix
You can't prevent bugs. You'll burn out. Instead focus on making them quick to fix.