Ep. #10, The System Is More Than the Code with Charity Majors

Adam Zimman: So I guess the first thing we should do before we get too far is, Charity, would love to have you introduce yourself so that anyone who may not be aware of you can know who you are.

Charity Majors: My name is Charity Majors. I'm the co-founder and CTO of Honeycomb.io, and I am and forever will be an ops engineer at heart.

Adam: Excellent. And you are also, just so you know, for this group, probably one of the most quoted individuals in all of tech.

Charity: Ah, I hope so. Have you seen my sticker game of late?

Heidi Waterhouse: It's so good.

Charity: It is. So we can just talk about stickers. "Have a human in the loop." "I don't need your pity invite." "No participation trophies, please." "It's my fucking loop."

Adam: So there are a number of things that, you know, we wanted to kind of talk to you about. So this is a podcast that is intended to be a kind of continuation of the conversation that we started with the Progressive Delivery book.

And so really kind of thinking about how do we think about this notion of the third loop, which is the idea of user adoption, which has become so much more relevant of late, where all of a sudden the barrier to generate code has dropped precipitously. But the barrier of users feeling good about the code that they are using is seemingly getting greater and greater. And I think that this is something that we talk about from a bunch of different angles, but your name keeps coming up.

Charity: Well, not to disappoint you, but I just had to Google the third loop and read up on it real quick while you were talking. But no, I'm up to speed now. Now I understand what we're talking about.

Adam: In all honesty, we maybe are using a slightly different name, but this is the stuff that you have talked about rather significantly, you know, for years. Like, even mention the fact that I was at a talk with you recently and you, you know, talked about the fourth trimester.

Charity: Right, right. So, very similar.

Adam: Pretty much exactly the same thing. It's like, really, how do you even know if what you built is useful until it's actually in production? And that's when you learn.

So I think that this is a similar idea. It's like, how do we start to get more builders to pay closer attention to not just getting things over the line to being deployed or getting things over the line to being released, but how do we have that third loop of like, okay, but are people using it? And are people using it in rage, or are they using it, you know, with contentment or success?

Charity: And how are they using it? Like, we have this idea in our heads we're going to use it, but it's never actually matched by the real world. Like, I feel like we have software engineers, they're so used to living in a world of how things should work. You know, like they think that the code is the source of truth, the tests are how you validate.

And then at the end of the development process, you neatly hand it off and production starts. When production is a stage of development, it is the only stage that ultimately matters. Code that's not in production may as well not exist.

I love the term progressive delivery. I was so excited when you guys started talking about that because it pulls together so many strands that are so much greater than the sum of their parts.

Adam: Yeah, absolutely. I loved your recent blog post, "Make AI Boring Again." I'd love for you to, you know, just give a quick kind of summary of some of the things that you talked about in that post for people that haven't had a chance to read it yet. And then we'll put a link in the show notes as well.

Charity: Yeah, totally. You know, those of us in the tech industry, we're used to new innovations in technology being exciting and fun and new iPhone and, you know, kind of optimistic. I mean, a bit of cynicism, but, like, I don't think we've ever experienced something before where it's like, you're doomed. We're building up for you, but it's going to fuck everything up. You know, just brace yourself.

There's this guy, I blank on his name. He coined the term "doom trolling" for what the big AI CEOs keep doing to us, where they're just like, again and again, this is world ending and you should do something. You know, and it's just a way to raise money.

Make AI a normal, boring product. Don't tell customers that you're building something that's going to destroy their lives. Like, just the level of anxiety in the world right now as a result of this is not healthy. Sorry, that's not what my piece is about. That was just--

Heidi: But also true.

Adam: But also true.

Charity: So in wrestling with this myself, the sticker was actually an interesting entry point for me, because I live in San Francisco, one of the leftiest, notoriously lefty cities in the world, you know, and I'm surrounded by people who are like, anyone who uses AI to generate art is a bad person because this was trained on stolen data. It's all the externalities, the data centers, the water, the electricity, all these things. And so I didn't touch it for a long time.

And there was a moment where I was late and I'm like, ah, fuck it, I need to do this. And so I did it and I got hooked because it was so much fun. And then I'm like, oh no, what have I done?

And I had to really sit and think about it. Like, am I okay with this? Can I cop to this in public?

And what I realized was I grew up as a fundamentalist, right-wing fundamentalist. And my dad thought that purity was the highest thing that a woman could aspire to be, honestly. And my parents believed that the world was corrupt, that it was--

Heidi: Fallen.

Charity: Fallen, yes. Original sin, a fallen world, you know. And the way to be a good person, to protect your purity, was to withdraw from it. And they did.

They revoked their social security numbers. They homeschooled us. They started their own trip. You know, so I definitely have a nose for this.

And I refute the pursuit of purity is behind every single fundamentalism on the left and the right. It's the urge to purify yourself instead of engaging with the world. And it slips so easily into this sort of narcissism and performance where you're not actually centering the problems or the people being harmed by them. You're centering yourself and your quest to be perfect.

And then you start competing with everyone else for clicks. And, you know, the denuncia, just the worst of social media is a lot of performative purity, you know?

And I think, first of all, AI is just technology. Technology can't be evil. Like guns do evil things, but they're not evil, right? Like it is what you do with them that counts.

And AI is incredibly powerful. We don't know exactly what it's best at. We're figuring out what it's incredible.

And I think it's stupid to just, like, in the face of powerful tools, unilaterally disarm and walk away and leave it to the people with the fewest morals to develop governance. Like, no.

I want to stop short of saying we have an obligation, because I do think ethics are deeply personal. No gods, no masters. Which doesn't mean that everything is relative. And I hope that this spurs a lot of people to read and listen and look around and then look deep within themselves and find their convictions and act on them.

There's a great book that I recommend called Catastrophe Ethics, where he just walks through a lot of the traditional ethical traditions and how you can't apply them to a world like this where every act we take is hopelessly compromised. Are you going to use milk or soy milk or almond milk? But what about the water? Like, you just can't.

Heidi: I thought that was one of the most compelling Good Place episodes, was like the best man in the world is still just like super ethically compromised because there are no ethical possible choices.

Charity: And it feels like nothing we do better.

Heidi: And it could either be like an abandonment, like, I can't do anything right, so I might as well just not.

Charity: Nihilism.

Heidi: Or it could be a like, what is the best path to choose? You got to pick your battles and then fight them.

Adam: And, you know, it's one of the things where, like, also every person gets to pick their own battles.

Charity: Yeah. But I want to be clear that just by saying, yes, we have a responsibility, I think, to use the tools, become experts, become people worth listening to, etc.

That's not the end of it, right? We do have an obligation to act, to organize, to give back, to compensate, because we are participating in harm.

Adam: Well, I think also, you know, something else that came up for us on a recent conversation was the fact that we are seeing so much of the kind of anxiety and angst and anger and this kind of like imbalance is the fact that we've hit like this, you know, kind of step function inflection point in terms of the pace of change. And the thing that governments in general and like societal structures in general are really bad at is being able to accommodate change. And you can have some flexibility built into that.

But the reality is that we're at a point right now that we're seeing technology do, you know, kind of one of these. And, you know, governments or societal structures are just kind of like humming along doing this. And they're just like, wait, what's up? How do we get, you know?

And there's a lot of people that are taking advantage of that. And a lot of people that are actually being, you know, physically harmed by it. So it's just hard to kind of reconcile. How do you get things to kind of converge back together again, at least a little bit?

Charity: Start with local government. Like, all these data centers, first of all, they don't pay taxes. Second of all, your tax money is going to lure them there to build next to you so that you can't sleep at night. Like, billions and billions of dollars in subsidies. So vote out the assholes that did that, first of all.

Adam: Or, you know, make it so that the kind of folks that are saying, hey, we want to build these data centers in our town, recognize that it's actually an opportunity to be able to increase the taxes on them and generate tax revenue and be able to actually, you know, put policies or regulations in place with regards to noise ordinance or how you like dissipate noise.

Heidi: Or how you recycle the water. Like, we can recycle the water. If it were required.

Charity: Yeah, closed loop systems are completely technically feasible if they were just incentive by a student. There are so many things we can do.

And one of the things that I said at the end of that piece was, when I lie awake at night and I can't sleep and I'm thinking about the government, the elections, the climate, I remember myself that I can have some small impact on AI and software. And the same is true of you and every person listening to it.

Next to climate change and the government, like, software's not that big and we have voices. So I find that optimistic. But then again, I'm an SRE. We do depressing.

Heidi: I don't know that it's depressing so much as the permanent worst case scenario.

Charity: Reality. We're deeply tuned with reality. You know, they say that the only people who really truly perceive the world clearly are deeply depressed people and SREs.

Adam: So another thing that we wanted to make sure we mentioned, and this goes kind of to your comment of SRE for life. You just had a new revision of your book come out. So congratulations.

Charity: Thank you.

Adam: Your book is Observability Engineering, second edition.

Charity: Yeah, the first edition was 250 pages. It took us three-ish years to write, three and a half, like 2019 to 2022, I think. And when O'Reilly wanted us to do a second edition, I at first was like-- and then I was like, you know what?

No, I'm really grateful for the opportunity to do this again, because I never felt like, great, this is done, ship it, like, I can't wait for people. It was more like enough time passed and I was just like, oh my God, I can't look at this, I can't be reminded about another, I can't just, whatever we have, I don't even want to look. And I look back at it now and I'm like, I wouldn't say I'm not proud of it. Like, I feel like it's like your children, you're not allowed to say that. So now the second edition, though, turned into-- it took nine months to write instead of very long, and it ended up being completely rewritten and over twice as long, and I'm really proud of it. I think it's a really good book.

The book, you can download it now, honeycomb.io/book. The dead tree version will be out in another couple of weeks, and the structure is like this:

Basically, there's a short part one, which is just kind of like being like, all right, this is a crazy time to be in software, like, AI is changing literally everything. And so our hope in this book is to provide you with the first principles that are more important than ever, right? We're not going to try and say-- a bunch of stuff is going to be out of date-- but, like, these are first principles. And then part two and part three are for software engineers who are trying to instrument their code and understand the code that they wrote, both with and without AI. Then we have part four and part five, which are kind of-- we have so many incredible guest contributors who wrote deep--

Like, Hanson Ho does a deep dive into frontend and mobile, and Intercom folks did a case study of how they built Fin with this iterative stuff. And we've got, like, a CI/CD, like, just incredible guest stars. And then the last section of the book kind of mutated. It was supposed to be, like, three little chapters for observability teams, and it turned into a monster. It's 10, 11, 12 chapters. It's a third of the book, but it's for technical decision makers, and it starts with an open letter to CTOs about why all their goals for the next few years with AI are blocked behind their ability to understand what's happening in their organization. And then we talk about things like VPs and directors and principal engineers and staff engineers need to know about socio-technical systems and instrumentation, driving change without influence, and choosing software, build versus fire versus the mentors.

And even my favorite chapter is right at the end, and it's called The Art and Science of Vendor Partnerships.

Heidi: Oh, that sounds amazing. Because, yeah, we're not making software alone.

Charity: We are not.

Adam: I love that you have that as part of your book on observability engineering.

Charity: I know. It's kind of--

Adam: No, I mean, like, I've been in organizations that have, you know, built their own stack. I've been in organizations that have bought everything. I've, you know, kind of seen all varieties over the years.

And, you know, like, helping people to think about how they, you know, kind of work with vendor, I think, especially in that context is so important, especially nowadays, where if your observability stack has external vendors in it, that means that your ability to be able to know what's going on is reliant upon somebody else's ability for uptime.

Charity: Yes. And you probably really care about having influence over their roadmap.

Adam: And this goes back to kind of how we frequently talk about things is that notion of technological jerk. Of like, you probably care an awful lot that they don't push an update to their platform when you're in the middle of an incident.

Charity: Yeah, yeah, little things like that.

No little kid is like, I want to grow up to do enterprise vendor partnerships. But if you are an engineer who's, you know, been writing code and doing stuff for 20-plus years, one of the most durable skills, I think, in a post-AI era is the ability to orchestrate across company lines.

So in the chapter, I talk about how most transformational initiatives fail because they're hard. And the ones that succeed usually have someone on the inside, someone who's an engineer, with deep trust and credibility around the organization. They understand positive outcomes. They can cut through bureaucracy like a hot knife through butter. And that trust just makes the world go round.

And when you're partnering with vendors, trust and credibility is not the game. It's building trust through reciprocity, understanding that you have different-- they need to make a sale, you need to get the best thing for your company, and you shouldn't confuse those two.

But over time, you can build a real-- like, most vendor relationships never build much trust. They're just like, you give me money, and I give you services, and it's fine.

But sometimes it gets to the point-- Like, I feel this way about Intercom. Like, their successes are our successes. Our successes are their successes. And it's just so good.

Adam: Yeah, that's awesome. As someone who has spent time, you know, kind of in that, like, partnership land, as well as on the product side, as well as, you know, running observability teams, I think that that is something that is so frequently overlooked.

Charity: Yeah, I don't know that I've ever heard anyone talk or write about this, but I might not just be listening to the right channels.

Adam: It's interesting because I think it's something that's talked about a lot in the kind of world of partnerships or alliances. But I think that what is oftentimes absent from that conversation is the notion of the kind of vendor-consumer relationship, especially in the context of engineering. Because by and large, you know, there's a stereotype that engineers hate talking to vendors.

Charity: Well, they do hate talking to--

Actually, the piece that I'm working on right now is it is not impossible to sell and market to engineers. You just have to not lie and not be a weasel about it.

Adam: This is the thing is that going back to, like, mid-2000s, like at GitHub, this was something that we talked a lot about was you can absolutely market engineers. You just have to wreck it because you look around, you know, like the engineers that you know, and there's all sorts of things that they will be very adamant that they are committed to and that they like and that they want. And it's like, yes, because there's marketing that's taking place in a way that resonates with them.

Heidi: But the marketing has to be authentic and not transactional. Again, it has to be useful. It has to be meaningful. It has to say, like, I understand your problems and I have talked to my engineers about how to solve them.

Adam: Or I will actually solve them. As opposed to making promises that are, you know, oh, yeah, well, we're working on that.

That's going to be out in, you know, a couple of years. That doesn't fly. Doesn't fly. What can you do for me right now?

Heidi: Even though I'm not going to adopt for a couple of years, which is the thing that makes me crazy. They're like, well, how much Kubernetes do you have? And I'm like, how much Kubernetes are you trying to support right now? And they're like, two Kubernetes?

I'm like, you don't need orchestration yet. I'm sorry. Can we talk about your heterogeneous data center environment?

Charity: If they notice it, it's because it's out of place and it feels off and then they're like, that's marketing and that's sales. People don't notice it and call it marketing and sales when it's relevant and they want it.

Adam: Absolutely. Now, this notion of, like, vendors and the use of external components, how do you see that changing with AI?

Charity: Obviously, SaaS is dead. I mean, we've known that for weeks now.

Heidi: I thought we had cycled out of it again.

Charity: Yeah, probably. I can't--

Heidi: Keep up, Charity.

Charity: Seriously.

Adam: I think that you wrote about this a little bit, and I have had a few conversations, especially I remember with one of the lead AI devs at Facebook a few months back, was talking to him about this concept of what if you don't need to worry about what code says or, you know, what it does, because if something's wrong, you just prompt the AI to completely rebuild it from scratch. And so you don't actually ever care. All you care about is your objective, your outcome. And, you know, like it could write it once in TypeScript. And then the next time it's going to go and write it in Clojure. And the next time it's going to go write in Rust.

And you don't actually care what the code says, right? But at the same time, how does that extend to either the packages you use in open source or the partners or vendors that you choose to use for building out your stack? How are you starting to think about that?

Because I know that Honeycomb has been using a fair amount of AI. I love seeing Liz's updates. What's your thoughts on that?

Charity: I welcome people to the playground of personal application generation development. I think that's wonderful.

I love it. I think people are overly optimistic about, well, most things. Software is the killer app for AI because it's made up of language and logic. And every time you have to reconcile the world of language and logic and bits with the physical world, which operates with very different sort of rules, you have to reconcile those two. And those two points are storage, like physical systems, databases, everything, and people design interactive. And I think no matter how fast the world of it goes, it has to slow down wherever it meets the world of the physical realm because I don't want to wake up every day and have the buttons on my Slack app move around. I deeply do not want that.

I like my change budget to be meted out very intentionally and slowly, you know, and if I'm not looking at it, I don't want it to change. And I think that, I mean, anyone who's ever done a sticky database upgrade has some real humility about our ability to-- I mean, just all the non-deterministic code in the world right now runs on a very deep stack of deeply deterministic primitives. And it's easy to take those for granted, but I think we will run into some pretty alarming and non-workable things if we just make everything--

Clearly, deterministic workloads are great for some things. Non-deterministic workloads are great for others. You know, the prototyping and the fancy bits and experimentation and all this stuff, that's super. But I think that determinism is not going anywhere.

And I don't think that there are many paradigms that will work well for both. But some, right? I don't know. Have you guys read much about the Phoenix architecture stuff that Chad Fowler has been writing about?

Heidi: No.

Adam: I have to look into that one.

Charity: I highly recommend that you do. So Chad is the guy who coined the term in 2013, immutable infrastructure. You remember, Heidi, the handcrafted server pets and cattle and everything. And he has been writing up a storm about the same things happening for code.

And because the economics of generating code dropped to near zero, it's now cheaper, faster, and easier to generate a thousand variants of a bit of code than it is to handcraft one, right? And he's talking about how, because of that, we really need to have different artifacts that we iterate on once that represent the invariants, the architecture, promises that we've made to our users. Like, think about strangler fig architecture. The only way we know to, like, rewrite legacy code is by breaking it, seeing what broke, and then, like, you know, building up architectures around replacing a tiny bit by-- Like, the cost of software has always been defined by cost of its maintenance. And every rewrite I've ever been a part of is so miserable. But if we can make it so that code could be regenerable cache, basically, like, it's not-- there's a spec, there are evals, you know, we have to get better at designing.

Heidi: Right. Like, the thing that's been bothering me about the just-regenerate-it thing is it's so non-deterministic.

Charity: So that's the thing. It's not enough to have just a spec. You also have to have a really robust set of-- even so, like, think about-- and I would never claim that I think this will work for all types of code, like databases and really low-level stuff, I'm still just like-- but I think that we could move a significant bit in this direction. It would be really good for all of us, because if you can validate in it, or if you can define, you know, our users expect this to return within 20 milliseconds to 50 milliseconds. And so if you can generate code to these constraints, you can generate thousands until you get a snippet that, you know, fulfills the constraints, I think that would be a better world.

Kim Harrison: In one of your articles, you said something that I really love, and it gets at this: "What if we could discuss and converge on an architecture diagram and the code could be regenerated from changes to the architecture instead of the architecture being kind of sort of inferred from the code?"

Heidi: Okay, wait -- the architecture or the diagram? I think that's a really key point. Like, I just unplugged my NAS. Okay, does that reflect in my code?

Charity: So I think the declarative flow would have to go from an artifact to components. But I just mapped this right back to the way we learned to generate. Basically, the point is that mutation causes drift, which is what's expensive.

Heidi: Because maintenance depends on predictability.

Charity: Well, yeah -- the history of the code, all of the bugs we fixed, all of the implicit and explicit things. All of that, nobody has; it doesn't exist anymore. We don't know what promises we've made to users, we don't know what expectations they have. And this is where, you know -- to circle back to where we were at the very beginning, when we were talking about how software engineers are used to living in this world of how it thinks should work, right?

But the system is so much more than the code. The code is just a part of it. And all of the most important parts of the system are not really written down or defined anywhere right now.

Adam: Well, not only that, but they are the multitudes of variables that we are expected to account for. Like, I think this is why your kind of notion of, you know, everybody tests in production and some people do it on purpose, right? Like, this is the thing is that until you actually start interacting with that physical world, like you talked about, you don't actually know how your code, that, like, isolated experiment, is going to actually interact.

And not only that, but guess what? The world doesn't sit still. And so, like, all of those things that you are observing and, like, trying to account for, they're continually changing. So there's so much there that you need to be mindful of and paying attention to.

The thing that I'm a little dubious of with regards to AI is how all of these things come down to how large can we allow the context window to become.

Heidi: Okay. That matters because?

Adam: That matters because if you think about it in the context of all of the unwritten stuff, right? We talk about, like, why was this bug fixed? Or, you know, why was this code changed to meet this constraint? All of those things ultimately make up context.

Charity: Yeah, but the context window, I would treat that more like cache. That's not permanent.

Adam: Yes, but how do you make sure that the right things are ending up in that cache at the time that you're doing your exploration rebuild of the code?

Heidi: How is the context window different than the promise?

Charity: The context window is the input and the promise is the output.

Heidi: But in order to be contextual, the promise has to be incorporated.

Charity: So I think we don't have the primitives. We're not used to talking or thinking about software in the way.

I'm going to drop the link because I'm trying to get everyone to read this Phoenix architecture. Chad is actually writing a book and he's working with my O'Reilly editor, and I'm super excited about all this. And so I think everyone should be reading shit because I think it's the next generation of software. But it's like, if you're anything like me, I suspect, Heidi, you will read one or two pieces and you go, oh, I understand what this is about now.

Heidi: Yeah, I felt like that when I read Promise Theory, actually. Like the Burgess book.

And I'm like, oh, okay. I'm skipping all the physics. There's a lot of physics. Skip the physics.

Sorry, Adam. But I see sort of where you're going, where you're like, what matters is the behavior, not the way we get there.

Charity: Not the implementation. And in the past, the generation, you know, the way that we've been like, I know this code works. So I'm never changing it, right? Like, it works. And therefore, like, if we could separate out the workingness of the code and make the implementations generated to fit the spec of the "this is what it means to work" is just kind of the general idea.

Heidi: Yeah, I need to read this. I think y'all on the podcast can't see us, but we're all making this deeply thoughtful face of, like, wait, what does that mean?

Adam: Question for you, Charity. Do you think that there is a distinction of doing software development in that manner for, like, personal applications or, like, tool-based things versus, like, deep infrastructure type?

Charity: So I would actually put it a different way. I was a little depressed about the AI stuff for a long time. I'm just like, yeah, I see where this is going. When I started reading Chad's stuff, I was like, oh, this is engineering. This is still engineering. It's just a different type. And I have never been one who had the attention span to really obsess over code quality, to be perfectly honest. There are other artifacts that I find far more interesting. But I don't feel like I actually fully answered your question earlier about the SaaS versus, like, toy apps and stuff. I think that it's still engineering. If you're trying to do something that is elegant, has a good experience, it has a rich mental model that people can navigate and rely on and depend on, if it's going to scale, if people are willing to trust it with their data and their money, if people are willing to build businesses on top of it, it's still going to take engineering.

I don't see a world where it's not going to take actual engineering. It's going to look different. And in some ways, I think very different. In other ways, I think not that different.

But I really see the big change as being now non-determinism is available to us in some really interesting and creative and unique ways. And I'm excited about that. But I don't really see it changing everything or making engineering obsolete at all.

Adam: Well, it goes back to make AI boring, right? It's just another tool in your tool belt that sometimes is appropriate and sometimes maybe not.

Charity: And we've definitely been through over the past year at Honeycomb. I was telling folks recently, like, a year ago, when people were complaining about AI and not wanting to use it, I didn't trust us to say that. I didn't think we knew enough to say whether or not -- I knew that I didn't. I could be complaining, but I knew that I didn't know the trade-offs well enough to, like, really authentically, credibly say. And now I feel like we do, right?

And I feel like this is the J curve of learning that everyone has to go through is you get worse before you get better. And you've got to go through it. The only way through it is through it.

Kim: I have another quote from another one of your articles. "I might argue that software engineers have always relied far too heavily on the code instead of sensemaking the system through observability."

Heidi: Ding, ding, ding, ding, ding.

Adam: Truth.

Heidi: And not just mechanical observability. Like, the socio part of observability is really a huge part of sensemaking. Like, what are you even trying to do with my software? Why are you using the backside of the hammer that way? I don't understand.

Adam: Yeah, absolutely. All right. We got one last question for you from Kim.

Kim: This has been a great conversation. Who else should we be talking to?

Charity: Oh, boy. I'm actually on podcast hiatus until the fall. You guys are the only folks that I'm talking to.

And instead, I am trying to distribute around. There's so many incredible people at Honeycomb who have all these convictions and this experience. And they're great to talk to. And they don't get enough.

And I'm just like, so you should talk to Allison, the director who's been in charge of all the AI stuff, the sharp left turn we took over the past year. You should talk to Steph Hippo, who's the engineering director who's been on the other end, receiving all the -- her teams do the storage and the on-call and all this stuff.

And you should talk to -- we've got a few engineers, one of them distributed assistant. He's super interested in talking about folks. We've got another engineer who's writing a piece right now on why the rise of agentic development means that you really need to spend more time together, developing together as human beings, like leaning into the non-chatty parts of distributed work. I'm not even going to try and give any names outside Honeycomb because I've got at least half a dozen people to send you there.

Heidi: Do you think Third Loop would be a place for the Phoenix architecture?

Charity: Chad?

Kim: Chad Fowler.

Heidi: Chad Fowler.

Charity: Yeah, absolutely.

Heidi: Yes, I will absolutely introduce you to Chad.

Adam: Excellent. But yes, we would love to have some more conversations with folks from Honeycomb.

Kim: Absolutely.

Adam: Thank you so much for your time this morning, Charity. Really appreciate it. It's always a blast talking with you.

Heidi: Always super fun. And congratulations on the new book.

Charity: Thank you so much.