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
February 2024
Can I get your opinion
Books start with a detailed outline that's easy to change. That's when they're easy to change and where you can help.
January 2024
Ask me a question
Swizec is writing "Scaling Fast", a book about his journey in a 20x hyper-growth startup. Questions?
Be action oriented
Unearth the surprising connection between the CIA's Simple Sabotage Manual and your productivity, and learn how to transform tiny actions into big wins. Dive into Swizec's engaging exploration of how small actions can make a huge impact on your progress.
November 2023
Let juniors speak first
Want an engaged engineering team? Let juniors speak first.
The efficacy of TypeScript
TypeScript may streamline code navigation and catch semantic errors, but it doesn't guarantee fewer bugs or faster fixes.
October 2023
Solve the problem, not a different more difficult problem
Solve the problem at hand, not the one you imagine might come next. A simple fix now often beats a complex one later.
August 2023
Finding modules in a Big Ball of Mud with ChatGPT
Detangling a Big Ball of Mud is hard. You have to find domain boundaries where none exist. Looks like AI can help π€©
Followup answers to Forget complicated code, focus on the system
Why are utility files bad? How do you recognize architectural complexity? What the hell is a transitive dependency?
Forget complicated code, focus on the system
Clean code matters, but it's the architectural complexity that truly impacts your productivity and bug count. Focus on simplifying the system, not just the code.
July 2023
What I learned from Team Topologies
You can't escape Conway's Law. Might as well use it for good.
Working with product
A strong partnership with product is key to an enjoyable engineering life
June 2023
Why taming architectural complexity is paramount
Unravel the hidden costs of architectural complexity in software engineering and learn practical strategies to tackle it. Boost productivity, reduce defects, and improve staff retention with insights from an MIT PhD thesis.
Effective standups
The secret to effective standups that don't suck
May 2023
Two types of complexity and their impact
Complicated code slows down junior devs, while complex systems impact senior devs more. Focus on managing system complexity & dependencies, not just simplifying code.
You can't fix the wrong abstraction
Unlock the secrets to combating architectural complexity in software development and learn to identify and fix the wrong abstraction. Boost productivity, reduce bugs, and retain more staff.
April 2023
DRY vs SoC, a difficult choice
What is the essential difference between DRY and SoC principles in software engineering and how do you balance the two
January 2023
Squash merge? Really!?
Learn why squash merging is your friend - from hating it to loving it! Squash merging helps you keep moving and focus on the work instead of recording the work.
Why trunk-based development is best
Merging finished work straight to main and deploying to production right away, scales to teams of thousands. This approach is counterintuitive to many engineers who may be used to working on their own
November 2022
Scaling teams is a technical challenge
A founder friend asked me about growing pains on his team. How do you avoid stepping on each other's toes?
September 2022
The art of the cowboy merge π€
how do you catch a critical deadline that cannot be missed? We're talking external stakeholders, millions on the line, and it all hinges on *your* team getting it done on time. No overtime
August 2022
Reader Question: What do collaborative teams look like?
New members on our team invariably say 2 things: 1. Wow I've never seen a team move this fast 2. This approach feels weird. I'm uncomfortable Teams like this are not common.
Reader question: So about that perfect burndown chart ...
If your approach works so well, why isn't every team doing this?
July 2022
Write abstractions, not just code
Wherein I use a silly example to show why you need more than small reusable single purpose functions to write good software.
June 2022
Coding forces you to understand the problem
Programming translates fuzzy understanding into exacting specifications. Thatβs why itβs hard. The Illusion of Explanatory Depth reigns supreme
May 2022
Writing software is like kicking a can
Writing software is a playful process of exploration and discovery. Like a game of kick the can on a Sunday walk.
The Italian foods theory of bad software design π
Spaghetti code β unstructured Ravioli code β too structured Lasagna code β layered wrong Minestrone software β unclear domains
April 2022
How we made the best burndown chart you've ever seen
My entire career I've never seen a sprint finished on time. The new manager said "Oh I think we can fix that" ... 18 months later he proved me wrong
October 2021
What's more productive, a team or a talented soloist?
Engineers *hate it* when you say it doesn't matter how good they are because a team will outcode them any day. But it's true, you can't build something big on your own.
August 2021
WorkInProgress kills your progress
If it takes 6 engineers 10 days to complete 6 projects in parallel, why does it take 8 days when you work together π€¨
Tech debt is a tool
If your house was on fire, would you mow the lawn first?