It’s ok that computers are (sometimes) better than us

Speaker A: Hello, and welcome to the Stack Overflow Podcast, a place to talk all things software and technology. I'm your host, Ryan Donovan, and today we are on the floor at the LDX3 conference. We're talking about cattle, not pets, but for code. And my guest for that today is Charity Majors, co founder and CTO at Honeycomb. So welcome to the show, Charity.

Speaker B: Thanks for having me.

Speaker A: My pleasure. So, top of the show, we like to get a little familiar with our guests. Can you give us a little TL doctor on how you got into software and technology?

Speaker B: It was an accident. I went to school for piano when I was 15, 16. I grew up in rural Idaho, and the only thing there was to do was read books and play piano. And I went to college and pretty quickly realized that all the music majors who had graduated were still poor, in their 30s and 40s, still hanging around the music department. And I was like, no. And that's about the time that they were wiring the dorms for Ethernet, and I started playing around with computers, and now I'm here.

Speaker A: Well, you're still in orchestration, right?

Speaker B: I'm still doing orchestration. And you could argue just swapping one keyboard for another. There

Speaker A: you

Speaker B: go.

Speaker A: You give a talk yesterday that was really interesting, and it was sort of an idea that I haven't heard. We're taking the idea from infrastructure, where we went from individual servers as pets, to moving to disposable infrastructure as cattle. But you said we should do this for code.

Speaker B: Yeah. And I have to give, like, so much credit to Chad Fowler here. Chad is the one who actually coined the term immutable infrastructure back in 2013, and he's written a lot about this on, um, blog posts on the Phoenix Architecture site, and he's writing a book for O'Reilly on it right now. But it was one of those things that as soon as I saw him make the case, it just. It clicked in my head and I was like, oh, yeah, I am just barely old enough that my first job title was sysadmin. I barely remember this stuff. But I do remember the sense of crisis that everyone was in. I was 17 years old and on call for the first time. I was surrounded by these people who are just wizards. They knew everything About Linux internals, FreeBSD, HPUX, sun, like, the operating system and the networking stack. And they knew everything. And every server was, like, handcrafted. Like, you would SSH in and be like, which type of memory do I need to fix the hardware? Like, they knew so much, and it seemed unfathomable to me that we could just destroy those. And yet BY around early 2000s, it became very clear to everyone that this was better. It was better because one of Chad's great lines is, uh, mutability is the sworn enemy of understanding. Anytime you're going just changing, you lose the provenance, you lose the history of what's come before and it's not repeatable. And the whole way to make technology boring in a good way is to make it so that you don't have to understand it all the way down to the device drivers, so that you could work at a slightly higher level because you know how to revert to something that's known to be good. And so Chad started laying out this argument and it made so much sense to me. And a lot of this does hinge on what is the definition of the word spec, because it's a catchy phrase. But I think the definition of spec is changing a lot. And I just feel in my bones that there's a better way. The cost of software is defined by maintenance.

Speaker A: Yes. So I want to tap on the immutability because I think for a lot of people would look at the server and that being like, that's the immutable infrastructure. Right. Once you start defining infrastructure with a YAML file, you never know exactly how many nodes are up. That seems like that's kind of mutable, that's kind of like I know less about what's going on. Is that mistaken or is uh, that just like, like you said, another layer of abstraction?

Speaker B: I think there are parallels here that history isn't going to exactly repeat itself. That's just moving up the stack, you know, like going from assembly language to C to JavaScript. And I think it's notable that there have been many movements in the past who have low code or no code and they've all kind of failed. Which is why I think it was very reasonable for us to be very skeptical of ChatGPT's claims right up until about last November.

Speaker A: Right. And you were a skeptic for a while.

Speaker B: I was a skeptic for a long time and last year it's here. And at its root this is almost more of an economic argument than a technical argument because code has always been hard and time consuming and expensive to produce and we've always been rate limited by some human has to understand this before we can move forward and iterate on it. And if you think like I do that in the past year AI got to the point where it can generate snippets of code that are roughly at the same level of quality as the median software engineer. Which means that while one software engineer can output a piece of work that works, AI can generate a thousand of them, 10,000, we can see which one is the best. You know, it just, it makes you think very differently about code itself.

Speaker A: It's interesting where we spin up all these nodes. Now you can spin up all these versions of that feature and compete them against each other.

Speaker B: Right. That's one of the building blocks, I think, because it's pretty clear to me that in the same way we don't expect every software engineer to understand how to debug, uh, types of RAM or how many CPUs, or if there's a device where we just don't expect them to understand that we used to, we don't anymore. And I don't think it's an exact analogy, but I do think that when we talk about cost of software as defined by its maintenance, we're talking about the cost of having to understand everything. And I think that if we re architect our software so that we can understand it at the level of functions instead of lines, if you re architect it so that there are bounded parts that can be cut. And, and of course, the most durable part of this system would be the evals, not the code itself. The evals describe what must be true for this to be defined as good. And then, yeah, we can generate 10,000 diffs and see which one is the best.

Speaker A: Yeah, yeah. And for those evals, are you thinking like the LLM is a judge sort of evals, or do you have a deterministic eval?

Speaker B: Well, both. And I mean, a lot of these tools actually already exist. Conformance testing. They're all in the realm of OPS and qa, which are historically like the cost centers. You're not quite as cool as software engineers, but like, they're aimed at describing the world as it is instead of the world as it should be.

Speaker A: Right.

Speaker B: And there are some types of code that will never be replaced by this because they're too sensitive. But there's a lot of code that's very high in the stack and it's a feature. You should be able to say, these are the contracts that our code has made, these are the systems that depend upon it. And right now, the fact that we don't know those things we don't know, like the way that we replace old code is through Strangler FIG architecture, where we just intentionally break one thing at a time. This is terrible. That's why it's so hard. Just

Speaker A: regenerate the architecture.

Speaker B: Yeah.

Speaker A: Jez Humble had a talk yesterday, sort of specifically targeting the Strangler fig architecture.

Speaker B: I'm going to have to catch that.

Speaker A: Yeah. It was interesting because it's like that's a really inefficient way to do it.

Speaker B: Yeah.

Speaker A: It's just scream tests all the way down.

Speaker B: It's no fun. The worst engineering times of my life have all been rewrites. Mhm.

Speaker A: But I talked to a QA engineer that had built a sort of proof of concept agentic sdlc and it was all based on evals and QA mindset. I was like, oh, engineers are going to need to be a QA person.

Speaker B: Yes. And ops. Uh, one of the things that I'm excited about in this era is software engineers have historically lived so much in the land of how things should be. If the tests pass, my job is done. As much as we say the lob it over the wall doesn't exist, it's still exists. Right. They're used to living in this world of well, it is correct on paper, but that's not reality. The code has never been the actual source of truth. The source of truth is the system. What matters is the system and its ability to keep on running in all situations.

Speaker A: You mentioned that the nature of specs has to change. Talk to folks who are thinking about spec driven development and what that spec actually is, whether it's a sort of functional spec languages or plain English.

Speaker B: This is not really my area of expertise and I think it's just a really exciting time to be thinking about those problems if you're someone who likes those problems. One of Chad's recent posts said something like, don't assume that spec is a document. Like there are probably gonna be bits of code in it. There are probably going to be like depends on the type of system you're trying to describe. There might be benchmarks, there might be a lot of different things and the tools don't really exist to do this type of development today. But. But they're starting to be built.

Speaker A: Yeah.

Speaker B: And it is very exciting.

Speaker A: I briefly ran into somebody and mentioned this sort of regenerative code and it's like, well it works for infrastructure because you have that deterministic thing, that YAML file that generates the same thing every time. Do we need the thing that generates the same thing every time?

Speaker B: Oh,

Speaker A: you're sort of talking about like this code. Thunderdome.

Speaker B: We need our AI to generate deterministic system that meets the specifications.

Speaker A: Yeah,

Speaker B: but I think that it can change. This is part of the challenge and the promises. Right. What can change and what can't? If you've got a web app and the latency on, uh, the payments endpoint goes from 2 seconds to 3 seconds, probably fine. It should be fine. We don't know until we try it. But that kind of variance happens all the time for a lot of different reasons. And you need systems that are flexible enough to absorb some variance, something that is much lower on the stack. Like if you had a router that went from taking 0.1 seconds to taking 3 seconds to take a hop, that'd be catastrophic. That'd be terrible.

Speaker A: Right, right,

Speaker B: right. But like, part of architecture and part of building resilient systems is trying to make them flexible so that things can flex.

Speaker A: Right.

Speaker B: You know,

Speaker A: I'm sure a lot of devs listening to this will be like, oh, the spec is never a deterministic thing. The requirements shift over time.

Speaker B: Exactly.

Speaker A: Yeah. So at what point do we need to, uh, get the final, final. Right. Like, how do we stop product managers from changing things along the line?

Speaker B: You know, I think it will be great if we can get to a world where we trust our spec and our evals enough that anyone can just chip code. That is not the world we live in now. And it's not one or two hops away from the world we live in now.

Speaker A: Right.

Speaker B: But for some types of systems, you can see how it might be three or four hops. One of my favorite blog posts of all time was the one about boring software.

Speaker A: Yeah,

Speaker B: you know, boring doesn't mean bad. Boring software runs the world. It means that its failure conditions are well understood. It may fail, but we know what to do. In the same post, he talked about innovation tokens. You know, how you need to limit the number of. Every startup gets two innovation tokens, spend them wisely, and none of this stuff is boring right now. But a lot of the technology that we would use it for is boring. And I think that's where we would start.

Speaker A: How do we make AI boring?

Speaker B: Ooh. That is a topic that really starts to come down to governance really quickly. And I was thinking the other day, five, six years ago, there were plenty of large language model research companies out there that were doing research on their models and following the law when it came to copyright and fair use and everything. And they were making progress. Not as fast. And then OpenAI came along, just like, just go. And how different would the world have been if the changes since 2022, 23, 26 had happened over 10 or 15 years. And what kind of precedent does it set for all of the presumably law following companies out there?

Speaker A: Sure.

Speaker B: So something that I've been thinking about a lot lately. This is not necessarily technical, but just like how do we catch up from a governance perspective? How do we catch up? There's this upsurge of rage at data centers in the company throughout the country right now. But how do we channel some of that into organizing to, I don't know, compensate the people, have funds for the people who want to move because they can't sleep at night or. It feels like this is the question of our generation right now in so many ways.

Speaker A: I mean it does sort of feel like AI is just feeding society into a wood chipper to get this, this amazing sawdust. Right?

Speaker B: Yeah. There's a Cal, uh, Newport just like, why are we letting these folks act like, oh, it might kill everything, but we're going to build it anyway.

Speaker A: Right.

Speaker B: Like this is a product that's broken. Like if your product was out there, like putting people out of work and would you feel okay building it?

Speaker A: Developers have a different view on AI because they can engineer solutions to their problems, society can't.

Speaker B: Well, and this is the thing, I am very much of two very strong minds on AI because as an engineer I'm like, oh my God, it's Christmas morning, this is so cool. And I really do think that software will turn out to be the killer app for large language models because it's logic and language. It's what it is. The LLMs are getting so good at. If you give it a task, it does the task. They're not getting any better at the higher level systems thinking.

Speaker A: Mhm.

Speaker B: And I don't think they will because of the nature of the thing. It's still just sort of predictive text. It's trying so hard to be helpful.

Speaker A: We had an article from Chelsea Wolf that was like, data driven thinking is not innovative thinking. And this is LLMs are data driven thinking.

Speaker B: Uh,

Speaker A: right.

Speaker B: A lot of the rhetoric about how we're all going to be out of jobs and everything I think is, I wish people would calm down. I don't think it's going to be true. But on an individual level, if you don't embrace new technology. Yeah. You will be out of a job.

Speaker A: Yeah.

Speaker B: So like both of these things are true. And back to your question about how do we make AI boring. There are individual levels, there are company levels, there are societal levels. And I think none of us can afford to lean out on all Three. You know, sometimes when I lay awake at night thinking about climate change and the, uh, government and everything, I do find myself thinking, well, when it comes to AI, I can have more of an impact than on anything else.

Speaker A: Yeah.

Speaker B: And it's small, but I'm in it and you're in it. And we have voices and the game is not over. So there are things we can do

Speaker A: and

Speaker B: we should be super actively leaning into that opportunity

Speaker A: for folks who want to lean into it. What is the thing that the IC listening, what they can, they do

Speaker B: the first thing I know this, not everyone thinks this is. Become an expert, become someone worth listening to. You know, it's so much harder for people to, like, discount your voice if they need you. Become indispensable. Master the tools, develop your opinion. Become indispensable is a great way of summing it up, because not only will you be needed and you'll be listened to more. For all we're social animals, you know, but also you're more likely to come up with interesting ideas. You'll know the weaknesses, you'll know where it shouldn't be used. You can make the case. It's credibility.

Speaker A: Yeah. The other things I've heard that will make you indispensable are things like taste. And there was a talk yesterday that said it's wisdom and charisma. Intelligence is a commodity.

Speaker B: I've been thinking about that a lot. I just finished reading this book by Benjamin Labetut. I read it, I got to the end and I turned around and started over from the beginning.

Speaker A: Wow. I've been thinking about the move 37, where it is this entirely unpredictable move. It looks innovative, but it's from the simulations and the data, like, the computer can do all of the moves forever.

Speaker B: For those who are listening, it's sort of about von Neumann's life. I was watching an interview with the author and he was asked about his process, and he says it's very research heavy. He starts with research he tries. It's shelved under fiction, but very little of it is fiction. Most of it is taken from the data taken from history books. And it's sort of like a dark origin story of artificial intelligence.

Speaker A: Yeah, yeah, yeah. It's interesting, you know, the personality, like, von Neumann was very good at solving problems. He would just have these people come by and just like, chat with him and he'd be like, solved their problem. And he worked on the Manhattan Project. He worked on computers. He

Speaker B: worked on the hydrogen bomb, the nuclear bomb. He built one of the very first compute yeah. Like anything that happened, like the first few decades of the 20th century. Like, his figures were probably in it somewhere.

Speaker A: What about that book struck you for this moment?

Speaker B: Uh, so many things, but it's written as sort of a triptych. And the last section is about Alpha Go, basically, and to Go players. And the guy, I don't remember his name, the Go champion who played. And he quit the game after a couple years after losing and just being like, ah, uh, there's no point. And I kept thinking about that and I'm like, yet if your entire life is oriented around being the best and the smartest, this is very threatening.

Speaker A: Right.

Speaker B: But most of us are not the best and the smartest. Most people are, uh, we're all average in some way. And I feel like.

Speaker A: Embrace your mediocrity.

Speaker B: Intelligence is overweighted on. It has been dramatically overweighted on for the past few decades, at least, if not longer. There are so many things about being a person are, ah, not about how smart you are. And the more obsessed we get with our intelligence and with being the best, the more we really lose out on the journey and the joy. Like, there's so much more to life than smarts.

Speaker A: Yeah. We all have become knowledge workers. Right. Our power in the labor market is our knowledge.

Speaker B: And with AI, I mean, with computers. One of the other things I liked about this book was that it showed how much it scared people. The advent of quantum physics.

Speaker A: Yeah. When we ceased to understand the world.

Speaker B: Yeah. And he was just like, they really lost their, like these mathematicians and physicists who were like, we could no longer model how the world works and it's math instead of intuition. And some of them actually went insane.

Speaker A: Yeah. It was kind of a mystical experience for a lot of

Speaker B: them.

Speaker A: Yeah. Yeah.

Speaker B: And now we're all just like, well, yeah, quantum theory exists.

Speaker A: That's fine.

Speaker B: And there are so many other types of AI that are so much better than humans at so many things driving. It doesn't have to threaten us. I think we need to have the time to adjust. The speed of this is so just destabilizing to everyone. Uh, the speed of it and the fact that people seem to be gunning for terrible things with big grins, just like, with glee. They're just like, we're going to put you all out of work. Isn't that great? It's just like, do you trust these people? No, I don't trust anyone who says that it's a terrible thing, but I don't think it needs to or should be intrinsically Terrifying or threatening to our sense of self. The computers are better than us, any more than it should threaten me that someone else is a better CTO than me. I can want to be like them, I can potter myself after them, but it doesn't threaten me because I am who I am. I can still love my family and cuddle my cats. And there are so many things that are not,

Speaker A: uh,

Speaker B: intelligent based. And I wonder if that's kind of been the point all along.

Speaker A: I mean, maybe, like, I

Speaker B: don't

Speaker A: know. It's an interesting take to say that if I'm understanding, AI will sort of rehumanize us.

Speaker B: I hope so.

Speaker A: I hope so, too. So I have a sort of spicy, provocative question that I think you're the right person to ask.

Speaker B: Oh, no.

Speaker A: Yeah. What is the line between observability and monitoring and surveillance?

Speaker B: Off the cuff, I would say observability and monitoring are pointed at machines and surveillance is pointed at humans.

Speaker A: Well, like you said in your talk yesterday, the software is a system and that system includes users,

Speaker B: which is why we have things like PII and types of data that we're supposed to scrub so that any old person off the street can't come in and just like, see where I was at a given time of day.

Speaker A: Right. But in theory, I think we've seen. Don't want to name names, but some data gathering operations have

Speaker B: the NSA leaks all the way back to what's his name is now in Russia. Ah. Edward Snowden and Facebook. Uh, in the early days, the way anyone could just log in as anyone and look at their stuff. There's carelessness and there's maliciousness and then there's governance and. Yeah. I don't know what to say about it, man.

Speaker A: Yeah. I think it's a hard line and it's something I'm sort of freshly thinking about.

Speaker B: It's very hard to build and run these systems without feedback loops that let us see what's happening with some precision.

Speaker A: Yeah. You need to understand the system, but how far does the system extend?

Speaker B: I would love to be like, well, that's why the government makes laws and we can't, blah, blah, blah. But I'm not going to try and do that with a straight face.

Speaker A: Yeah.

Speaker B: I don't know. Where is your head?

Speaker A: I think the engineering mindset has the sort of data gathering and observability built into it. I think what becomes dangerous is when you take the engineering mindset into society outside of machines, outside of rocks and metal.

Speaker B: Yep.

Speaker A: But, you know, engineers are smart people. And they think that they can solve things that are outside the domains. A lot of smart people do that.

Speaker B: Oh yeah. The smarter you are, the more you're like, well, this is just like that other thing I did. Dunning Kruger effect, which AI is making worse than ever. I mean law really can do good here. And I've been thinking recently about the effect of hipaa. Uh,

Speaker A: m

Speaker B: before that, doctors regularly just told someone's parents or their partner or they just told them things. Sometimes M instead of the person. That was incredible. Having laws and then making sure that you have access to your own stuff. With genius, we needed that. But

Speaker A: you had consequences, right?

Speaker B: We had consequences. What do you think we should do? Ryan,

Speaker A: don't turn the mic on me. Come on. I think laws will be great. You know, we're finding the faults in the legal system right now, so maybe an engineering mindset on the legal system would be.

Speaker B: I've been seeing all these news reports recently about lawyers using ChatGPT and having, uh, filing briefs with errors in them and getting down. So I do think that the limitations in large language models are numerous and kind of baked in. And I think the future of software is determinism and non determinism and we use them both, but it's not magic. And I think that, I mean, I really wouldn't want to be a teacher right now, but I think the education system is some of the. Where we're finding a lot of the edges on this stuff

Speaker A: and I think everybody is figuring out like, oh, we have to change kind of everything. I had a conversation yesterday about sas and it's like a lot of this you can just write in house now.

Speaker B: Yeah, Yep.

Speaker A: But I think what's going to shift is that, you know, the SaaS that is indispensable, the stuff that's like, you know, a glorified database.

Speaker B: Yeah. Ah. There's a lot of types of software where you get a lot more value in having it be the same everywhere. Mhm. Or in being able to share data or SaaS is going to change, but not everyone wants to. Again, maintenance is, is what makes software cost what it costs.

Speaker A: Right.

Speaker B: I'll briefly mention PACE Layers, which is the Stewart brand, which is the idea that there are. So like this applies to all complex systems, whether it's society or technical systems or whatever. But there are some layers where innovation is great, things can move very fast, and there are some layers where you need it to move more slowly for stability. I think we run into a lot of trouble when we forget those and when we try to mingle them because it stifles innovation. If you're at a slow pace layer, it creates a lot of instability if you introduce a lot of change into a lower level.

Speaker A: Like you said, uh, earlier in this conversation about boring software innovation tokens. Right.

Speaker B: Yeah.

Speaker A: Don't change too much

Speaker B: and be conscious of where you're changing it. Somewhere where it's easy to revert. Usually persistence is a lower pace layer. Non persistent stuff is much easier to like try and revert and move fast and break things because it doesn't. It's wherever bits meet the world of atoms that things need to slow down a bit because whether it's humans and their interface or it's storing bits on disk, it just, it becomes a lot harder to revert from.

Speaker A: Yeah. Speaking of move fast and break things, I know you spent a lot of time at Meta.

Speaker B: I did.

Speaker A: What would you say your biggest takeaway on moving fast and breaking things there was?

Speaker B: Well, by the time I got there, we were all told that era had ended.

Speaker A: Had it?

Speaker B: And I think it had it had. I learned a lot of things at Facebook, none of them are technical, none of them were things that I think I would have said I wanted to learn. But they were all good lessons. A lot of good people worked there. But it was a one man show. It was the Zuck show.

Speaker A: Yeah.

Speaker B: What he said went to this day. No one can eject him written right in.

Speaker A: He

Speaker B: has total control of that company and for a long time I think that that was a huge asset advantage because it allowed them to have some single minded float. Zuck has great product sense, he's smart man. And now I think we're really starting to see several years of compounding what the weaknesses is with the single player. The sort of monarchic, um, no one can check him.

Speaker A: Yeah. I mean you're a CTO and a founder of a company. I wonder, like how do you think about running the company differently?

Speaker B: I probably am the opposite type of leader where I am not willing enough to be like this is the way it goes. If it was easy, if there was a clear path to winning, uh, you know, uh, it's hard.

Speaker A: Well, thank you for listening everyone. I, I've been Ryan Donovan. I edit the blog host the podcast at StackOverflow. If you want, uh, to reach out with comments, questions, topics to cover, email me@podcastackoverflow.com and if you want to reach out to me directly, you can find me on LinkedIn.

Speaker B: I am Charity Majors, Co Founder, CTO of Honeycomb IO. I write at Charity. WTF? I just put up a blog post called Confessions of an Unrepentant Slop Hater or something like that. We just finished posting a bunch of stuff about AI norms and values, which is on the Honeycomb blog. You're welcome to look up either. If you email me, I will probably not respond.

Speaker A: Thank you for listening everyone, and we'll talk to you next time. It.