No Continuous Delivery? Then Walk Out. w/ Charity Majors of Honeycomb

**LinearB** (0:02)
The data is irrefutable. Continuous delivery, the action of having a short feedback loop when shipping software to production is the best way for engineering teams to operate. The benefits are enormous, and almost every engineer you ask would agree. But almost no organizations are shipping software in under 15 minutes.
In this incredible episode, I bring in Charity Majors, CTO of honeycomb.io, to explain how to implement continuous delivery and why you should walk out if your organization doesn't support the practice.

**SPEAKER_2** (0:40)
This episode is sponsored by Linear B. Give your dev team the power to improve with team-based metrics, high-risk code alerts, and the world's first project board based on real-time Git activity.
Sign up free at linearb.io.

**LinearB** (0:55)
Charity, thanks so much for joining us today.

**Charity Majors** (0:57)
Thanks for having me. Delighted to be here.

**LinearB** (1:00)
Yeah, yeah. Awesome to have you on the pod. You've wrote some really cool blogs and I've seen you on some YouTube stuff.
And the things that you're, at least I saw that you're talking about around continuous delivery are really cool and amazing. So just thank you for helping the community.

**Charity Majors** (1:20)
Thank you for receiving my rants. Yes, I've been very ranty about CD lately.

**LinearB** (1:25)
Yeah, that's actually the first topic that I kind of wanted to dig in with you here. I think you're a known advocate of CD. That's the CD part of CI CD.
And also kind of how in general it relates to shortening feedback loops. I hear you talk about maybe some smaller PRs that are more easily able to be reviewed and making sure we're automated to get good work shipped out into prod. And the quicker you can get the code out, then you can shorten the feedback cycle. So kind of just wanted to start by asking you, why is a short feedback loop so important?
And how long should it take?

**Charity Majors** (2:13)
Well, there are two reasons that it's important. And the one that we always talk about is for our customers. Like it's better for our customers. If we're able to find bugs quickly and find bugs ourselves, instead of letting them find our bugs like months later, we can get our features out faster and all this stuff. But the other one is just like, it's important for like the life of the engineer. Like for the joy, if you want to find joy in your work, you need to be able to experience its impact on the world. And like shortening the feedback loop is just a way of making it feel more natural. It's a way of like plugging into your body's like natural reward systems, like dopamine and like adrenaline and all that stuff.
And training yourself to have a good gut feel for like what you're about to do. I feel like if someone's a senior engineer, to me that says that I can trust their gut instincts.
Sometimes it takes you a while to like unpack why you have an intuition that this thing you're doing is about to be terrible.
But you have an intuition. And the only way to train that gut feeling to be intuitively like correct is to train like your internal data corpus, so to speak, on production. If all you ever interact with is your code and staging, like your intuitive gut feeling is not going to be worth much.
So I feel like shortening those feedback loops is important because it's, you know, and how short should it be? As short as possible. I think that 15 minutes is a good upper bound, right? Like if you can rely on, you know, anytime you merge your code back to main or master, within 15 minutes, your code will be live in production. You can kind of build it in as muscle memory, that, you know, while you're writing the code, you instrument, because you know what you're trying to do. You will never know it better than you know it right now, right? You know what you're trying to do. You write some instrumentation that will help you, you know, tell, is it doing what I expected it to do? And then, you know, you flip over and you watch. Is it doing what I meant to do? And does anything else look weird, right? And that anything else looks weird is kind of an irreducible amount of complexity because it's about those unknown unknowns, right? The things that just strike you as off.
And if you can, if it's like 15 minutes or less, you can pretty much, you can build that muscle memory in. You can expect engineers to always look at their code after it's been shipped. And that creates a feedback loop where, I feel like 80% of bugs are usually found in that moment when the person who just wrote the code is looking at it through the lens of the instrumentation they just wrote in production, users using it right now. And if you don't look at it, those bugs go unfound, uncut. They become part of the background noise or someone else has to debug them days, weeks, months later. And it's just, the longer it's been, the harder it will be.