Swizec Teller - a geek with a hatswizec.com

Senior Mindset Book

Get promoted, earn a bigger salary, work for top companies

Senior Engineer Mindset cover
Learn more

    Why trunk-based development is best

    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 main.

    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.

    Cheers,
    ~Swizec

    Did you enjoy this article?

    Published on January 24th, 2023 in Teams, Productivity, Mindset, Velocity,

    Senior Mindset Book

    Get promoted, earn a bigger salary, work for top companies

    Learn 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

    Want to get my best emails on JavaScript, React, Serverless, Fullstack Web, or Indie Hacking? Check out swizec.com/collections

    Want to brush up on modern JavaScript syntax? Check out my interactive cheatsheet: es6cheatsheet.com

    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

    Want to brush up on your modern JavaScript syntax? Check out my interactive cheatsheet: es6cheatsheet.com

    By the way, just in case no one has told you it yet today: I love and appreciate you for who you are ❤️

    Created by Swizec with ❤️