How do you avoid having too many cooks in the kitchen when a bunch of developers try to work together?
Easy! Don't work together.
That's what companies try first. You get a bunch of soloists who think they're a team. But they're not and work in progress kills their progress.
Most companies work this way. It sucks.
Almost every engineer that joins our team says our way of working together feels deeply unnatural. 2 months later, they love it.
What is trunk-based development
Trunk-based development is a philosophy of merging finished work straight to
main. A CI pipeline picks it up and deploys to production. Right away. Every time.
That may be shocking to you but it works. More, it's the only approach that has successfully scaled to teams of thousands as Winters et al. describe in Software Engineering at Google.
Trunk-based development in practice
You don't have to go hardcore and push every commit to
You have to decide, as a team, what a unit of work looks like for you. The definition that survived on my team is ... something I can't put into words 😆 More of a fine-tuned sense of "yeah that looks about right".
Small features (1pt) are a unit of work. Engineers grab those and get them done.
Bigger features, we break down into subtasks as part of our swarm meeting. That's the up-front discussion that reduces later disagreements and helps us avoid re-work.
Each of those subtasks becomes a unit of work. It gets a pull request, a code review, and delivers a tiny little bit of value.
When the code is in a working state, passes tests, and gets approvals ✅, we squash merge to
main and let it deploy. Yes, in an overall unfinished state.
The key that makes it all work
Feature flags. You have to separate deployment from delivery.
The bar for production should be "doesn't break the system" instead of "works perfectly". This takes the pressure off, de-risks deployments, and enables testing in production.
Because only production is like production with all the right data and systems in place to know your code works works.
Feature flags come in different flavors:
- proper feature flags, configurable on-demand through a dashboard
- a new URL that users won't find
- a "quirk" of configuration, like when admins haven't enabled your thing for anyone yet
When you're happy, you flip the switch and deliver your feature. But not before.
The goal is to keep
main always deployable. That way nobody has to wait.
Followup article: Squash merge? Really!?
Become a *true* Senior Engineer
Get promoted, earn a bigger salary, work for top companies
Getting that senior title is easy. Just stick around. Being a true senior takes a new way of thinking. Do you have it?
Leave your email and get the 5 Action Steps to Senior Engineer - a short email course showing you steps you can take right now to become a true senior engineer and go from writing code to being a true collaborative partner that builds products.
5 Action Steps to Senior Engineer
Get a short email series with action steps you can take right now to be true senior engineer. Go from being a pair of hands that write code to a collaborative partner that others rely on.
Here's what a reader had to say:
Hey Swiz, I really enjoyed the series. Quite useful 5-step roadmap, if everybody kept those things in mind we would be in a much better place and our industry would be a more mature and less hype-driven one. Thanks, keep up the great work!
Senior Mindset Book
Get promoted, earn a bigger salary, work for top companiesLearn more
Have a burning question that you think I can answer? Hit me up on twitter and I'll do my best.
Who am I and who do I help? I'm Swizec Teller and I turn coders into engineers with "Raw and honest from the heart!" writing. No bullshit. Real insights into the career and skills of a modern software engineer.
Want to become a true senior engineer? Take ownership, have autonomy, and be a force multiplier on your team. The Senior Engineer Mindset ebook can help 👉 swizec.com/senior-mindset. These are the shifts in mindset that unlocked my career.
Curious about Serverless and the modern backend? Check out Serverless Handbook, for frontend engineers 👉 ServerlessHandbook.dev
Want to Stop copy pasting D3 examples and create data visualizations of your own? Learn how to build scalable dataviz React components your whole team can understand with React for Data Visualization
Did someone amazing share this letter with you? Wonderful! You can sign up for my weekly letters for software engineers on their path to greatness, here: swizec.com/blog
By the way, just in case no one has told you it yet today: I love and appreciate you for who you are ❤️