Just Use Postgres - Choose Boring Technology by Dan McKinley

Carter (00:00)

But because we now just have more bandwidth, the question is, have we just kind of all bought ourselves more innovation tokens?

Hey there, welcome to Book Overflows, the podcast for software engineers by software engineers, where every week we read one of the best technical books in the world in an effort to improve our craft. I'm Carter Morgan. I'm joined here as always by my co host Nathan Toops. How are you doing, Nathan?

Nathan Toups (00:26)

Doing great. Hey everybody.

Carter (00:27)

We are back. We have been, I think there was only one week we went officially dark. We we inter released our interview with Pramod Satalage, which you should check out. but for those who are maybe discovering us for the first time, the reason we have been a little off schedule is I my wife my wife had the baby. I attended the birth of the baby. But we yes, we have we welcome the new child into our family. Our first daughter, we have four sons, and this is the first girl. Her name is Heidi. and

The boys are just smitten with her. Well, I was saying to Nathan before the podcast started that the the youngest boy is a little upset about being dethroned as the baby. Yeah. We're all dethroned eventually. but yeah, we're we're excited. And I I took a few weeks off of work and am back at it. So back at the podcast, back at work, back at regular life. and yeah, we're super excited. And

Nathan Toups (01:06)

You know, it's a good life lesson. Things happen that you have no control over, right?

Carter (01:27)

we you're saying, Nathan, that some of our listeners requested that we maybe start at the beginning of the episode, give a bit of more of a roadmap of what's to come in the podcast, just so people can stay up to date with us. So we just wanted to give a heads up that we're actually reading another book by Uncle Bob. this one's called We Programmers, a Chronicle of Coders from Ada to AI by Uncle Bob. it's gonna be a little different for us. We've read some books like this before that are more like

Story driven? How would you say that? That those the one we read by Uncle Bob was Clean Coder, which is very like story driven, which I really enjoyed.

Nathan Toups (01:59)

Yeah,

I think he was in the process of wrapping up, or maybe he'd just finished it, when we interviewed him a while back, and it sounded really interesting and it's in the same vein that when we interviewed Brian Kirnahan, we ended up you know, reading Unix A History in a Memoir. And we had so much fun doing that. And I I I liked it helps me understand the context of like how did this compiler emerge? Like what was the indust what did the industry look like at that time? Which is, you know, a leading question we typically ask.

Carter (02:18)

Yeah, right.

Nathan Toups (02:28)

the authors in general. and so it these are fun. It's it's you know, software engineering has a history and I think it would it behooves us not to kind of understand it from various perspectives. And so I don't know, this look kind of like fun and something that we could all share.

Carter (02:43)

Yeah, I was I was reading a quote by like I think it was like a military general and he was saying I don't remember the exact quote, but basically saying like you need to read a lot of books because at a certain like your own experience is not enough. At a certain point, you're gonna need to rely on the experience and wisdom of others. And books are a great way to get that. Obviously, very pertinent to the the theme of our podcast, but I think especially pertinent when we're talking about these kind of historical books. because it's one thing to kind of just learn the nuts and bolts of programming, which we do a lot of here.

But it's another thing to yeah, learn our history and where we came from and how I think there's a lot of pertinent lessons from those early innovators to the innovators of today. So excited to read that. also excited for today. we're taking we're doing an essay today. listen to the podcast know that every now and again we'll do one of those. if we just trying to get back in the swing of things, we need to take a breather. And so obviously, having just had our baby, it was a good time to do an essay. But I'm very excited about this essay. This Nathan, you chose this one. Maybe.

I'll read the author introduction and the essay introduction, so to speak. And then if you want to kind of give your thoughts and maybe explain to the audience what why you resonate with this essay, I'd be I I'd love to hear that. So for the author, this is yeah, choose boring technology by Dan McKinley, who is a freelance raccoin tour, I don't know what that means, an engineer. He was in the first 20 employees at Etsy and worked at Stripe, MailChimp, and his own startups. His talk, Choose Boring Technology, is fairly popular online.

Nathan Toups (03:55)

Yeah, sounds great.

Carter (04:11)

More recently, he was a VP of engineering at Mozilla before circling back to Etsy, where he's now a principal architect working on applied ML and AI. And just to introduce the blog post, back in 2015, when NodeS still felt risky, MongoDB was the height of web scale hype. Listening to the podcast, no, I'm chuckling because we just migrated off MongoDB. And every conference had a talk urging you to try something new. Dan McKinley made the unfashionable case for the opposite instinct.

In choose boring technology, first an essay and then a widely shared talk, he argued that every company gets only a handful of innovation tokens, and that the mature move is to reach for the well-worn tool whose failures you already understand, saving those precious tokens for the problems that actually make your company different. It became one of the most quietly influential pieces of writing in modern software engineering, a permission slip for every engineer who suspected that best tool for the job was wrecking their weekends. Eleven years on, we put it to the test. so yeah, Nathan, you recommended this. I had

I I I think I'd probably heard I I resonate with a lot of this. And I think it's one of those things that just over these last 11 years has been distilled into more or less common wisdom. And but I had never read the origin of this. I really enjoyed reading it. but I guess why why'd you read it? Recommend this and what are your thoughts on it?

Nathan Toups (05:09)

Yeah.

Yeah,

I mean it's funny. I've definitely brought up this idea over the podcast over time. And I think it's often cited by folks who kind of you take a sober step back of how much new technology should you take on in a project, right? You hear about Redis or you hear about some graph database. Is this actually gonna help you solve a business problem? Are you taking on too much risk? And I think we all kind of ha get an aesthetic feel for things, but it's cool to read the blog post about

What an innovation token is, and his reasoning behind, hey, you get this finite resource. and so going back and reading, I think I did read this back when it first came out. some of it I accepted, some of it I rejected. It's also funny, I think it's really important to read contrarian views because he's literally calling out ThoughtWorks in this. He he he posts to a Martin Fowler blog post and talk talks about how.

Carter (06:11)

Right.

Yeah.

Nathan Toups (06:22)

An idea from Neil Ford is insanity about this idea of a polyglot, how it doesn't matter that you can use whatever it developers are comfortable with. And what's funny is I actually agree with both. I mean, I'm I'm definitely like both sides in this, and it's okay. You can both sides things. I understand where Martin Fowler and Neil Ford are coming from. And I think specifically in the type of like reverse conway maneuver, big corporate enterprise, how do you introduce better technologies and get out of dysfunction?

Carter (06:37)

Yeah.

Nathan Toups (06:51)

You sometimes need to spend extra innovation tokens. But I think in from a a sober analysis of cargo culting, of saying, hey, we're gonna make web scale, we're gonna copy Google with some crazy distributed database technology that they're using. And if our startup uses all this new tech, we'll be as innovative as they are, is actually, you know, really a bad idea. And that he it's actually from his own experiences. Like it what what I like about

Carter (06:54)

Right.

Nathan Toups (07:21)

Dan McKinley is that first of all, he's got street cred, right? He's worked at an he's worked through these transition periods and he made all those same mistakes, right? He he like talks about certain functional programming languages and using MongoDB and he made every mistake that he's like calling out here and making this like really good case for like why do we do this to ourselves? And anyway, I'm I'm excited about hopping into it because I think it's the same tingled mess.

Carter (07:27)

Right, right.

Nathan Toups (07:48)

most of us have probably walked into at some point in our careers and and it gives you a good framework to go w what is the benefit of settling on a set of tools or what is the what's when should I use an old boring technology versus something new. and so I don't know it it's a this is a ex it's a short read, but it's a really good catalyst for thinking about the why, right?

Carter (08:11)

Right. no, I and we should say it up front that because this is a blog post, right? Like this this discussion is gonna be a little more free ranging. I it's funny, we're gonna spend an hour talking about a blog post and it reminds me of like I think it's YouTuber Jenny Nicholson and she like did a review of the movie Joker, and then someone did like a review of her review, but the review's like four hours long, and someone's like, You could you could just watch the Joker movie like four times and and that that's about what we're gonna do here today. yeah, this is a really

Nathan Toups (08:31)

Right.

Yeah.

Carter (08:40)

This is really interesting because I there's another layer to all of this too, which is how does AI impact the landscape here? How are people saying AI impacts the landscape? And how do we really think AI is impacting the landscape? Because like the far end of like the AI maximalists are like programming languages don't exist anymore. You're you're programming in English, right?

And and so they would say like they would kind of come back to full polyglot of like, dude, program it in straight assembly if you want. Like I don't care. which I I think is silly. But there is this question of and it's worth talking about the the kind of fundamental concept here of like the innovation tokens. I like this there's a blog post and then there is a transcript of a a talk he did at a conference. Yeah, I

Nathan Toups (09:31)

Of a talk he gave, right? And a little

after it had settled in, because I think he was a bit unsettled about how popular this post got, right? He just had an personal engineering blog. and this one just kind of lit a fire. And I think he even said he had to come to terms with the fact that yeah, I've I've had to largely come to terms with it in reality that I will never escape its popularity. Talking about his blog post, because I'm sure that he, you know, because some of it is clickbaity.

Carter (09:38)

Right, right.

Yeah.

Nathan Toups (10:00)

You know, choose boring technology. there's a lot of ill-defined terms. And I would say that a lot of this is left up to aesthetics. And I think we could probably dig into that because this gets into that deeper conversation here, which is how do you define boring? Is there an objective definition of boring? it's funny, some of the technologies he lists here as the new and exciting and risky technologies are quite boring now, right? NodeS is one of those he talks about.

Carter (10:01)

Right.

Yeah.

Right. No. JS is the big one. And

Nathan Toups (10:29)

Which again, you know, you and you could even argue, hey, if you're gonna take this polyglot idea to its extreme, it behooves you to write anything other than TypeScript, because I can use TypeScript on the server and in the client. And now my team doesn't have to learn two different languages and you know, which again I would say it depends.

Carter (10:42)

Right, right.

No, we we had the exact opposite experience. So I guess first let's cover the the concept like an innovation token, which is just this idea that, like, okay, you're a startup, you're trying to change the world. And in his talk, he he he mentioned his friend, I thought of you, Nathan, because he his friend always he wears a black shirt every day. Yeah, yeah. That you can make the same argument with me, and I'm I'm often in a BYU shirt. And and he basically says, like, his friend thinks that by choosing to wear a black shirt every day, he's eliminated a choice from his life.

Nathan Toups (10:54)

Yes.

Black shirt every day, yeah.

Carter (11:18)

And that frees up the mental power for other choices. I I have to ask Nathan, do you subscribe to this logic?

Nathan Toups (11:25)

So this is why I originally started it. And and now that I'm thinking back on it, I'm it might have even been this talk that would convince me. And there was some blog post, and it is we it it it it makes you strange. Like I will tell you that like psychologically I did not realize that my daughter is just like, my dad wears black shirts. You know, like this is a I've built a norm for her and she's grown up her entire life with like, my my dad, the black shirt guy.

Carter (11:30)

really?

Right, right.

Nathan Toups (11:52)

And it is. I I would not say that I'm necessarily the most fashionable person, but I'm definitely I'm liberated from having to make any decisions. when I go to the store, I'm like, are there black t shirts that I would like? No. Okay, then I'm not gonna buy anything here. but I do think that it that there's this idea that and it maybe some of this is cargo culting on my side, that it w it it's death by a thousand cuts, right? That one little decision is not gonna bother you. And and we've seen this, right? We've seen this it's like,

Carter (11:57)

There you go.

Right. Right.

Nathan Toups (12:20)

What does it take to deploy a new version of your app? well, you have to follow the run book and then go talk to Bob. And then like, you know, we we speak through the like 50 things you have to do of friction that gets in the way. where if you just you don't let the engineers make a decision at all, they do a PR, there's a code review, you sign off, you tag something and it deploys. You've taken all this cognitive load. You don't have to have to think about the deploy process every time.

Carter (12:30)

Right.

Right.

Well, and so with this idea of innovation tokens, he's basically saying, like, he works at Etsy, and Etsy's mission was like to remake global commerce or something like that. And like I thought Etsy's mission was to sell me Tchotchkis, but that to each their own. and he he says, like, okay, that's a pretty big mission. That probably costs you at least one innovation token, right? And he just says, like, by by choosing non-standard, by choosing non-boring technologies.

Nathan Toups (12:57)

Right.

Carter (13:16)

You're using up innovation tokens. You're using up brain power that, especially at a small company and really any company, you should be spending your innovation capabilities on the things that matter. and he also talks about this idea. It's funny because this quote, this idea comes from Donald Rumsfeld, who is the controversial Secretary of Defense during the Bush administration. And every time he mentions him, he he has this big disclaimer of like, I do not like Donald Rumsfeld. And

But he basically, Donald Rumsell has this interesting quote where and we've talked about this on the podcast several times, which is that there are, yeah, there there are known unknowns and there are unknown unknowns, which is he he kind of points out like a known unknown is this idea that like we don't know what happens when the CPU hits a hundred percent utilization. An unknown unknown is an example his friend had, which is that by writing stat statements, they were accidentally pausing garbage collections.

Nathan Toups (13:47)

I I yeah, yeah.

Carter (14:10)

Right. And so you don't even know that's going to happen. And so he says when you choose boring technologies, you are eliminating the unknown unknowns, or at least reducing them. and this frees up space. And another great example he has is this idea of like he had to build an activity feed for Etsy. The best choice for the job would have been Redis to store kind of the materialized view of the feed. But no one at Etsy used Redis, so they use memcached, which is not as good a choice because it's more ephemeral.

But because everyone at Etsy was using memcache, they built the feed, they all moved on to different things. He checked back in on the feed usage later, like a a year later, and it had grown by 20x with no one even monitoring the product. And he said that because they chose memcached, which was a supported by the entire company, that it grew with the company without anyone even checking on it. and so basically by choosing boring technology, you're you're freeing up your surface area to do.

Other more important things. Now, I think the big question here is where do LLMs fit into all of this? Because obviously agentic coding agents are very powerful. And I've I've actually heard I saw someone on Twitter say the other day, and I really agree with this, that like one of the reasons LLMs have made software engineering feel more exhausting is because there used to be this kind of flow in software engineering where it's like, okay, I'm doing my solutioning, I'm finding out the right solution, and now I've found the solution.

And now I'm gonna spend a couple hours implementing the solution, just typing it out, right? And then that, even though there's some cognitive load there, there's much less cognitive load than like coming up with the right solution. But now there's a robot that does the implementing, right? And we supervise the robot and verify its output, but that time spent implementing is drastically reduced. And so now we just move straight on to more solutioning. And so it's kind of like.

The LLM ate all the easy parts of the job, but all of those hard parts are still there. But because we now just have more bandwidth, the question is, have we just kind of all bought ourselves more innovation tokens?

I'm inclined to say to a degree, yes.

Nathan Toups (16:24)

It and yeah, and so this is I think I think to kind of iterate this, because I I actually think the introduction of large language models themselves is a form of innovation token usage. and so to reiterate that point that you're bringing up, and and unfortunately we can't show you one of the nice graphs, boring old tech, right? We have this set of un known unknowns and then this larger set of unknowns.

Carter (16:35)

That's fair. That's fair.

Nathan Toups (16:51)

unknowns, meaning that I, you know, and and I like to think of it this way. There's this stuff where I'm like, I know I'm probably going to run into these problems. That's the known unknowns, right? Like I know that if we get to 100% CPU utilization, the server's gonna start acting weird. Right. then there's the unknown unknowns where I can't even guess what kind of weird stuff's gonna come up. Right. And so he he says, you know, again boring technology, both of those numbers are smaller, even though

Carter (17:11)

Right, right.

Nathan Toups (17:19)

The unknown unknowns is still gonna be larger than your known unknowns because you just again you can't guess all the things that might happen. But a shiny new tech, both of those numbers are larger. Both known unknowns because there's gonna be limitations, there's just not as many people using it. we don't really know how to predict the system properly. And then there's the unknown unknowns, which is like, hey, we've never even there, we're gonna get to a scale using some new technology that the creators of this thing never even thought of, right? And and we saw this, like it.

They they don't really talk about this at the time, but in the late 2010s, Twitter did use Redis for their feed and they ended up having to like reinvent distributed Redis charting like four times. And it was a complete dumpster fire. I actually knew some folks that were working at Twitter and they were just like, What did we do? Like what absolutely insane thing? and and so it is when you see this like memcached thing where you're like, well, memcach D was actually

Carter (18:02)

Mm-hmm.

Ha ha ha.

Nathan Toups (18:17)

was actually designed to horizontally scale from day one. Yes, it's boring. Yes, you have to build it so that it can just blow itself away and you're you messing your things are messing up. But the idea that you're going to add more stuff to it and it'll scale out over time and it'll be predictable is like a core, you know, feature. to me, large language models are like this as well, right? Which is like we have the known unknowns where you're like, hey, if I spin up five agents and I have to go manage them and I there's only so much time in my day. But then there's the unknown unknowns, which is like,

Carter (18:41)

Right, right.

Nathan Toups (18:45)

How do I actually code review 10, you know, 100,000 lines of vibe-coded code and what weird new problems could be introduced? And I I think that there's another side to this, which is like, and he gives us a he actually gives us an a a nice little like algorithm, which I I really enjoyed, which was what's how do you figure out what the total cost of of something is? And this isn't the talk. This is not in his his original paper, which I highly recommend reading these things together. But he says the sum.

Carter (18:51)

Yeah, right.

Nathan Toups (19:14)

Of all maintenance costs minus the sum of all velocity benefits equals the total cost. And what's interesting about that is again, if obviously this is sort of like a back of the envelope calculation, but you can imagine that the maintenance cost, if it's large, but the velocity benefits are small, the total cost of that thing is super high, right? We don't want that. We don't we what we would like is a c close to zero or even negative, right? Negative meaning we've increased velocity and the maintenance costs are negligible.

Carter (19:20)

Right, right.

Nathan Toups (19:44)

If anything, we're getting a net benefit out of it. and so you can make an argument that if you use large language models in a proper way, the velocity benefits outweigh the maintenance costs, right? But that I think that a large a lot of large language models are oversold and that the maintenance cost, whether it's cognitive load, whether it's training, whether it's the the cost of is the foundation model going to get banned by the US government, those maintenance costs can be quite high. And that if you're not getting the velocity benefit out of it.

Carter (19:54)

Right.

Yeah.

Nathan Toups (20:14)

you've now introduced a new thing that's actually like a net drag on your company.

Carter (20:20)

It you know, when he says velocity, what are we talking about? Are we talking about pure development velocity or are we talking about business velocity? Because this is what I think is is interesting, right? Because I'll give you an example and and I actually wanted to circle back to this because a few weeks ago we read Learning Domain Driven Design by Vlad Konanov. And I think the title of like our second episode was This Pattern is Insane or I'm an idiot, right? And we are talking about event sourcing, which if you don't remember.

Nathan Toups (20:25)

Mm.

Yeah.

Right.

Carter (20:50)

is this idea that let's say you have a ticket and a ticket tracking system. And how are you representing that in data? Well, the traditional way is it's a row and a table. And when you move it from in progress to complete, you update the status column. When you move who it's assigned to, you update the assignee column, right? Event sourcing is this idea that you never keep track of like the current state in the table in in one row. Instead what you do is you have an event log of like ticket created, ticket assigned, ticket progress move.

And then to get the current status, you reduce all of the events into the the current state and just serve it like basically out of memory. and it gives you some neat things like the ability to kind of rewind time. And I'm like, this is insane. Like, why why would you ever do something like this? And then at work, we I I I I was exploring something, this is too much preamble, but basically.

for those who aren't familiar, I work at a company called Leland. It's like an online expertise marketplace where you can go and you can connect with someone who, you know, is as an expert, like the goal you're trying to achieve in your life right now. So like we do a lot of business and like you wanna, you're you're preparing to interview for a fang company, you want to pass those interviews, you sign up with someone who used to administer a ton of fang interviews and you do mock interviews and you know, move on from there. people chat a lot over the inbox, you know, they message each other, but we've been really, really limited by.

Our messaging provider. It just doesn't give us all of the features we need. And so we started asking ourselves, like, what would it take to build this in-house? Could we build this in-house? And Cloudflare actually offers this really neat service called Cloudflare Durable Objects. Have you heard of these, Nathan? I just learned about these. They're really neat. They're basically like single instantiation servers per object. And every one of those servers comes back with its own mini SQLite database.

Nathan Toups (22:34)

No.

Carter (22:44)

And so this is really, really great for like a conversation history and because it's all served over WebSockets. So they manage all of the WebSockets that they take the load completely off your server. And then and you have complete control over like how you're adding data. Anyhow, this is really, really great for messaging because it turns out the best way to do messaging is event sourcing. Rather than like if someone likes a message, you don't go find that message and add to the column, you know.

Nathan Toups (23:11)

Yeah.

Carter (23:12)

Instead you just you append an event that says message with ID three one two gets like reaction, right? And then to serve it back to the user, you reduce and you just serve the materialized view of all of those messages. And we're actually being able to do some really neat things with it because like, for example, we wanted to to have like a rich preview in the inbox of like if someone if you send an offer to someone for like a a custom package that you want them to buy, right?

We wanted to make it so that if they buy that package, even if they don't buy it within the inbox, they buy it, you know, through their dashboard or whatever, that that preview still updates in the inbox to like show that it's been purchased. And you can do that because what we do is we have a whole event-driven architecture. So when the package is purchased, we just fire as like a side effect an append, we append to that log of the conversation, like, hey, package purchase, and then it updates the rich preview.

Nathan Toups (24:06)

Right.

Carter (24:11)

Anyhow, we're working on this right now. We're it's feeling really promising. But this is kind of this idea of like innovation tokens where are we talking about velocity? Because in terms of velocity, this is this is more surface area we're adding for us technologically to maintain. But from a business perspective, we have long felt like our inbox is a terrible tool for selling between experts and their clients, right? And we thought if we could own it end to end,

We could do more business there. And we and with some of the other bets we were making, we think that's increasingly important. So, like, yeah, it's more technological surface area, but it I think business-wise, it makes sense.

Nathan Toups (24:48)

Yeah, I mean

no, I I I think so and again, I my interpretation of this is first of all, every one of these assessment tools, and I think that's really where this is really strong is how do we objectively talk about what's the appropriate amount of risk we should take on with a business decision that we're making. And that business decision could be if you think about like we we've talked about this with, you know, Will Larson's type stuff with

Carter (25:08)

Right.

Nathan Toups (25:17)

Worldly maps are an excellent example of this, where you try to represent business value from you know bespoke innovations internally to commodification. We always try to go towards commodification of things that are further from the customer, right? Which again, you would imagine that's boring technology, right? We we see this kind of interpreted in different ways, right? Yes, we really there is no way to do this unless we use this innovative new way because there's no established patterns.

Carter (25:36)

Right, right. Yeah, yeah.

Nathan Toups (25:45)

And then we convince the industry that this is a great pattern, startups start emerging or some open source database, and we will probably migrate to that over time because we don't want to manage this custom implementation in-house, right? You can imagine these like we have to constantly think through, or maybe it's hey, we built this thing in you know, Pearl because the early internet used Pearl. and that was the thing. But now we're having trouble hiring staff. No one wants to program in Perl.

Carter (26:08)

Right, right.

Right, right.

Nathan Toups (26:14)

And you started looking at yes, by one definition, Pearl's a very boring technology. But the other side of it, it might be that like, hey, this actually isn't serving us well. It's not being updated with the expectations of what web servers should have in the future. There's all these security vulnerabilities or whatever decisions are. The new boring technology might be, okay, well, we're not gonna necessarily use, you know, some, you know, zig or something that's like brand new, that's not even version one yet, but we're gonna move to Java.

Right. Which again, everyone would argue is a boring technology. and that's a very safe thing. We have a large pool that we can hire. You know, again, you can think about velocity for the business is that, yeah, sure, some of that's engineering velocity, but some of it's also that like, hey, we can just move faster, there's better established patterns. it's not controversial. And so I think that you kind of use this as like again, a way of measuring things aesthetically. He he also brings this up in the paper, and I think this is really important. And I've seen this in different companies where

Carter (26:47)

Right, right.

Nathan Toups (27:14)

The co the founders and the core engineers at this one company I was in, Impera, had a background in databases. And so we did stuff that we built in-house that I thought were nuts, like absolutely nuts, but was boring to these guys, right? They very much was in their wheelhouse. They we had a C code base that had this like custom queuing stuff because we were doing dynamic AI pipelines.

Carter (27:21)

Mm.

Ha ha ha.

Nathan Toups (27:40)

That were this that was the core innovation. And again, and eventually this is what got acquired by Figma. so but I remember when I joined, I was like, my spidey sense would often be like, this is you this is vanity project and they they shouldn't be doing this. But I was actually completely wrong. And this was a completely straightforward tech. This was not Wonderlust and I would like to do this one day. It'd be if I started writing a C code base, that's exactly what that would be.

Carter (28:01)

Right, right.

Nathan Toups (28:06)

I've been in teams in which we had very mature platform engineering from day one, where a polyglot, which he criticizes, really wasn't that big of a deal because what were boring was you shipped it in a Docker container. And we already solved all the logging and deployment patterns in a very abstract way. and so there but you didn't get to decide that you're gonna use, you know, Firecracker.

Carter (28:20)

Right, right.

Right, right.

Nathan Toups (28:32)

Or or some some other thing, you didn't get to make those decisions. You didn't get to go spin up AWS Lambdas and have a serverless framework. You know, we removed that. So but the boring part for us was, you know, do this, name it this way. And if you have a Python code base or you have a Ruby code base, we actually didn't care. in for that organization, it was appropriate. I've been in another again, I talk about this, and it's the last little story before I punt it back. We

Carter (28:32)

Right.

Totally, totally.

Nathan Toups (28:59)

We're on a team that chose boring technology in the strictest way possible, probably in most alignment with what he had here. It was the best engineering team I ever worked on. It's the one I keep bringing up. It was that FinTech company. We had a ch decision as an org that we picked one programming language. Our data science team had already established using Python. And so we wrote everything in Python, right? All of our API servers were in Python, all of the SDK stuff that we wrote was in Python. And it was no one's favorite. Actually, there was a running joke internally that.

Carter (29:08)

Yeah.

Right. Mm-hmm.

Nathan Toups (29:28)

Python was everyone's second favorite language. and it was fine, right? Like, injure, we would complain about some of the weird, quirky things, or we would talk about the stupid parts of Python and like which subset of Python we would use. But it was a debate around that. And so it wasn't like, well, Python is stupid. We're gonna use Scala because Scala, you know, does this distributed parallelization better? It was completely taken off of the also just use Postgres, right? We were like a Postgres shop.

Carter (29:30)

Right, right.

Nathan Toups (29:57)

you there was one team that got to make a decision on doing colommer data that very well justified, and we made an exception because it really did solve that. We used some innovation tokens on that. because it was a newer Colomer setup at the time, it was early two thousand to early 2020s. I got to use an innovation token on the fact that like I converted us to a service mesh on top of Kubernetes, even though we were a small team, it ended up being a really great decision.

But like I like this this idea that you really need to justify a shine what feels like a shiny new thing. Is it in the core capability? Is this something that your team's willing to own for the next ten years? Right. If you make this decision and you can't switch off of it, are you comfortable with it for the next 10 years? I think that's a, you know.

Carter (30:38)

Right, right.

And and that's the point he makes, which is like there's a there's groups of tech there's technologies and there's business problems. And there's any number of technologies can solve any number of business problems. Right. And but sometimes we work backwards, right? We we say, I would like to use this technology. Therefore, let me see what kind of business problem I might be able to solve with it. and I think that's yeah, like I I I like the way you're phrasing it with kind of like core domains, and that's something we have.

We've just have been debating more and more at work. We're like, look, like we are a we we are a a matching marketplace platform where so much of the the relationship is realized over the platform. Like we think messaging is a core domain for us. We don't think that this is a commodity at this point anymore. It's been a commodity for three years, right? at at this company. but I do think LLMs change the surface area. Like that's where we we had known.

And I think this is interesting, like at businesses. I'm finding, I'm willing to be proven wrong here, but as I've stepped into more of a leadership role at this company, I'm finding that the best way to make decisions or at least to like get buy-in is when your decision is really just the synthesis of what a lot of other people have already said they wanted. Right. Like we had this with our big, we just we we did a big migration. We we kind of we

We killed the old back end and rewrote everything. And I was a big fan of I said, we're gonna choose the most boring technologies. We're gonna do we're I ironically, when he wrote this, he said Node.js was an exciting technology. We chose Node.js because it is the most boring technology, right? We chose TypeScript because we were already using Next.js for the front end. And so we're like, okay, you know, let's just do let's just have it all on the the same language, right? and

Nathan Toups (32:29)

Right.

Carter (32:38)

Yeah, just this idea that like but but when I c when I

Nathan Toups (32:41)

But you get you you

got a credit back for moving to Postgres too, right? Like so yeah.

Carter (32:45)

Well, I I I think so. I think so. Right.

And also, but when I came with that kind of proposal, it was really just the synthesis of what the team had been saying for months. Like, hey, if we were to do something new, what were we to do? And that was the same thing with like, okay, I think we need to redo our messaging. Like one of our other some of our other engineers had already used this kind of Cloudflare durable object for our like live stream chat functionality. Like, okay, so like that seems it works. And I'd known

That this was a big pain point for a while. And so where I think LLM's really changed the picture is I I went to like my my teammate yesterday. Yeah, because we literally started this yesterday as a startup. We're moving really fast. And I kind of said, I'm like, let's see if we could get like a working prototype of this done today. Cause if we could get a working prototype of this done today, and we've already proved out this pattern in a separate domain, and we know that we're very, very familiar with our messaging platform. So we we kind of know a lot of the known.

No or the the known problems, right? Like if we get a working prototype this done today, like I think we could do this. and so and you know, and so we did. And yeah, just like this like I I think that's where LLMs change the calculus is rather than being like, okay, let's spend a week investigating this, let's do this or that. Like, 'cause as a startup, it's like we don't have if this is working, we should be spending our time on like other bigger things. But instead, we're like, hey, I think we could get this done a lot faster.

I don't know. I th I do think LLMs buy you kind of more innovation tokens. Although I do think your point about like LMs themselves being costing innovation tokens make a lot of sense too, right?

Nathan Toups (34:20)

Yeah. And

it and again, this is w that gets into one of those like turtles all the way down thing. Cause I I kept going back and forth where I would read I read this and I was like, you know, I really agree with some of these points, and I think that some of this is obnoxious. And then I slept on it and I thought about it some more and I read some more. And I was like, you know, this is the Jedi IQ thing where, you know, you can do really well with just it just use Postgres, right? And then you can get into that middle curve where you're like, but yeah, but

You know, maybe I need this distributed caching thing, and maybe I need a graph database, and maybe I to do this all these things, other things. And I I I love functional programming, so the business should use functional programming. And then you get back to like the Jedi at the other end where you're like just use Postgres, you know, use the boring tech. Because yeah, the business doesn't care. And I think I think that's the the other part of it. It's like I mean, I've I've not been shied away from this. Go is my personal favorite programming language.

Carter (35:10)

Right.

Nathan Toups (35:19)

I have not advocated for I've been really happy when I've been on a team that uses Go. Like that it's fun, it's a joy for me to use, but I've never asked someone at a company to switch off of their established code base to move to Go. mostly because I'm in a minority. Go is not most programmers' favorite programming language, right? It would the team itself would have to go, you know what? We feel productive, we think we could maintain this long term.

Carter (35:34)

Right, right.

Uh-huh.

Nathan Toups (35:48)

We don't like all of the weird edge cases that come from a you know a Python code base or you know PHP or something. And as an organization, we go, yeah, this is cool. This is the boring tech. Go's been out for a long time. we like the things that are established here. And with l with large language models, it does change the I think it changes the willingness of like, would I feel confident in helping contribute to a a programming language that I was less familiar with? I think.

Carter (36:16)

Right.

Nathan Toups (36:17)

I think we've seen this a lot with establishment of Rust, right? There's a lot of like beginner rust out there now, right? Where,

Carter (36:20)

Yes.

Yeah,

I I because I I worked at Rust at a previous job and I hated it because I there was just so yeah, and cause Rust is like it's like if you can get it to compile and work, then it works, right? But like kind of just getting there, there was so much that I was unfamiliar with that was like, What I don't understand. And like I had to like start doing deep dives and like what is Rust? Like, how does this work? Right. Whereas I think today I I would enjoy working with Rust a lot more because it's a lot of those like little gotchas would

Nathan Toups (36:30)

Right.

Right.

Right.

Well, and if you look, I have several friends who are absolute huge, just they love the type system in Rust. They love the bar checker. They it like they'll read advanced Rust developer blog posts and be like, Hey, look how cool this is. This they they figured out this, like and I'll look at it and kind of nod my head and go, that's that's really neat. Like I I under I think it's cool. I I appreciate the Rust community from a distance. Like I I really do think that the way that they do stuff is cool.

Carter (37:00)

Right.

Right, right.

Yeah.

Nathan Toups (37:21)

It's not how I wanna write programs, right? and so yet while I wouldn't if if if majority of the engineers have really compelling reasons to use Rust, I I feel more confident that I could at least I understand good patterns, I understand things, I understand enough about Rust that I think I could contribute in a non stupid way with the assistance of a large language model. and so I do think that like what's boring and what you're allowed to do as an organization can

shift, you know, if it depending on the skill set. And so I the other thing that he doesn't bring up in here, and again, these were an evolving things at the time. And I will say a swing back towards I'm a fan of Neil Ford, is building your systems so that they're evolvable is another piece to this. which is again, I don't want to excuse away making lots of bad decisions and introducing the polyglot unnecessarily, but this idea that we know that we acknowledge that unknown unknowns exist.

Carter (38:08)

Right.

Nathan Toups (38:20)

We acknowledge that decisions that we make today may not serve us well in three years. it's really a boring decision, I would argue, is to put good fitness functions in place and to make sure that the system is evolvable, that we know that we might need to make changes in the future. so that if we do decide to in introduce some new technology or, you know, break a team out or do whatever, it would be really nice if you set the code up in a way that's, you know, acknowledges that these changes and decisions might happen.

Carter (38:32)

Right.

Yeah, and and I think well, and this is something we harp in the podcast a lot, which is this idea that like you need to understand your business domain. You need to understand what problems you're actually solving. And that has only become more true with LLMs, right? Because this this kind of profitable niche of like I just I get my clear requirements, I write the code. Like, well, you know, that that's not so that that that has become more commoditized these days. And so when you're choosing a new technology, I think there's a lot of like

I like what you're saying about like you need to be evolvable. You need to be flexible. I worked at one of the companies I worked at. they were really, really, really all in on like Ruby and Ruby on Rails. Like they they hired like so many, like the Ruby committee board or whatever. Basically, like half of them worked at this company. and there there came a point in the company's history where they were trying to make a square pig fit into a round.

Particularly when it came to front-end development, because the the market really just moved to React, and React became a more mature ecosystem. And it was certainly easier to hire talent. So they were trying to hire like front-end developers. And none of the it was like this evolution of like first none of the developers wanted to work. It's funny because like it's very like choose boring technology-ish, where it's like first the front-end developers, like, well, I don't want to work in Ruby on Rails. I I want to learn React. Like React is the thing I want to do.

Nathan Toups (39:51)

Yeah.

Right.

Carter (40:18)

But then it evolved over time to where React became the boring technology. And it was like, it's hard for us to hire because everyone knows React. and and they don't want to work in Ruby on Rails or they don't know Ruby on Rails. so I think that there's like that company, I think, went like way too in the other extreme of like, we're going to force, in our opinion, this boring technology to the point where it didn't make sense anymore. but

Nathan Toups (40:23)

Right.

Carter (40:47)

It at the same time, it's like you need compelling business reasons for why you're choosing a new technology. For what it's worth, I think a compelling business reason can be we have a hard time hiring talent who knows this language or this process or this, you know, framework, or wants to know this language or process or framework. yeah.

Nathan Toups (41:11)

Yeah. I I bring up the Pearl

thing because I knew I know a guy, he's a few years older than me, phenomenal programmer, you know, background in C programming, was big in the Pearl community. And he he actually is the maintainer of this like FFI library, which, you know, for for the uninitiated foreign function interface calls are like how do I interface between one language system one language calls into another language, right? With the there's this FFI.

So if I wanted to call across into some into something else. and this was this interface. And so it was not only was he, he was a really well-established Pearl programmer, he worked at one of the big CDNs, and the big CDN still had a huge Pearl code base. So it was like job security, but most people didn't want to work in this. And he happened to be an expert. He was like maintainer of some of the like one of the more popular open source libraries. and he had these cool stories.

But one of the problems though is they had a hard time hiring, right? It was a hard time. And so one of his jobs actually was most of the underlying stuff in Perl ended up getting rewritten in Rust. And this FFI library became super important because they wouldn't you want to use Pearl's cryptography library, which is like not well maintained, I think. I I might be messing up some of this, or maybe didn't have some of the new features, but Rust did, right? Rust's cryptography library is phenomenal.

Carter (42:13)

Right.

Nathan Toups (42:37)

And so they would write more of this core tooling and then they would use these these hooks into Perl so that it would be exposed to the Pearl language. and of course, amazing deep domain expertise, boring technology. You can understand why they're still maintaining it because there's very valuable to the company, but increasingly there's this sort of like, you know, inner council of wizards who knew how to actually run any of that system. And I think at some point you have to realize is it more boring?

To just re-write it in Rust, right? Or is it just is it more boring for for all of those things? One of the things I also wanted to think about with what is boring when it comes to LLMs is also it's not just is it a boring tech, but also is it in the training corpus, right? So and I think exactly. No, you brought this up really well. I'm gonna give you like credit for this. You know, one of the reasons that you were talking about like using React is that just like there's just a tremendous amount of React data out there.

Carter (43:09)

Right, right.

Yes. I mean that's why we chose TypeScripts. It was like there's bajillions of lines of TypeScript.

Nathan Toups (43:37)

To be trained on, right? Where if you pick something, yeah, yeah, right. The entire web is is you know, just like all the you believe everything you have online, all the code that's in GitHub you should trust. but it y you're right though, there's a lot more examples of React than than something that's newer, right? Like what's s what's that other? This is gonna drive me nuts. Svelte, right? Svelte.

Carter (43:39)

All quality.

I don't know any new one. South, Selton, okay.

Yeah.

Nathan Toups (44:06)

Right, Svelte, which is I think actually has a lot of cool learnings. It does some really reactive and fun stuff. I actually really enjoy the sort of contrarian aspects of it. I think in a lot of ways it's probably a better abstraction, more performant. But the Svelte community is way smaller, right? Is it's just in like if you wanted to get a large language model to help you get up and running. I'm working on a project right now where I'm playing with the idea of using auto merge, right? Which is again,

That's the project that spun out of some of the stuff that came in the DDIA book. And auto emerge is this local first C D R T C R D T C D R I'm gonna get it's gonna drive me nuts. Is it C R D T? C R D Yes, conflict free C Yes, C R D T conflict free replication data types, right? Pretty out there stuff.

much smaller set I'm having to do a lot of like research on my own, right? I can't just like dial it in and let the large language model just like do it for me. I'm using some innovation tokens. And I think that that might be the thing is like some of this boring technology in a world of LLMs is how many innovation tokens of cognitive load do I have to take on because I'm choosing something that's not in the training corpus of large language models.

Carter (45:08)

Right, right.

Right, right. Yeah. And and I think yeah, it it's so interesting. Like I I was thinking about with because we're we're all going through a a bit of career crisis of confidence with large language models. But like I was thinking about this today, which is like if you ask me if a dis if if design will be replaced, designers will be replaced by large language models. Like I say, I'm like, no, of course not. I'm like, now designers' roles have changed, right? Like I I noticed that when we're like prototyping features.

We can get it looking pretty good faster than we could with than before. Cause like Claude is just better at design than I am, because I'm not very good at design. But it's just changed what designers do. Instead of now handcrafting every single screen, they're more coming in almost at the end and saying, okay, we should change this. It should look like this, or, you know, or they're exploring kind of higher level visions of like,

What should the whole design language for the site be? Like it's actually freed them up because they don't have to do individual screens to be looking at way more on the website and be like, you know what? This thing has languished for a while and actually isn't very good, but we never had time to get to it. So we should rethink how we're doing this. We should redesign this. and like, and I think it's it's really interesting. And it's just kind of making everything better. And we still have plenty of work for designers. But then when you ask me, like, well, will software engineering be eaten by large language models? Then I get like a lot more nervous.

Nathan Toups (46:32)

Right.

Carter (46:47)

But like I know that the answer has to be the same for designers, right? Like it's just because I'm so familiar with the job.

Nathan Toups (46:51)

I

I saw a really interesting thing the other day, which they were talking about automation and it was about the hand wringing of when the ATM came out. And I'm not gonna say ATM machine, because that's a thing that irks me. Cause you're saying automatic teller machine machine. but yeah, AT it's the it's the AT machine. Yeah. It's the it's yeah. So when the ATM came out, they're like,

Carter (47:04)

Okay. Yeah. I call it the AT machine. Yeah.

Nathan Toups (47:21)

Yeah, bank tellers are cooked, right? Like there's they there's no future. Who's gonna even want to go talk to a bank teller? And if you actually looked at bank teller hiring in the US and ATM distribution in the United States, they both continue to go up. And it wasn't until like I think three years ago that bank tellers leveled out in hiring. is it just so and that was like 25 years or something, right? Maybe more than that. it'd have to be more than 25 years.

Carter (47:35)

Right, right.

Nathan Toups (47:48)

ATMs probably came out 35 years ago, if I had guess. Maybe longer than that. I have no idea. Many years. Many years that the ATM has been out. and so I think that we're in the same boat where like the expectations are changing. And I think with ATMs, the very silly I'd like to get $100 in cash out of the bank. Now real I didn't have to fill out a slip and walk up to the bank teller and like ask for a hundred bucks, right? I could do that automatically. But if I had anything that's slightly more complex.

Carter (47:50)

Right, right.

Yeah.

Right, right.

Nathan Toups (48:19)

I needed to go talk to a teller and I go do and when I ran my when I ran my own business in Austin, I actually would go do deposit. I remember I would get these, you know, five thousand, ten thousand dollar checks sometimes 'cause I'd sign on a new customer. And I'd go do those it by hand because like you can't just I I don't think at the time I could night deposit, you know, or like I it was just like I felt more comfortable making sure that I did that in person. And so I would go to the bank s you know semi regularly with certain things because people still wrote checks.

Carter (48:36)

Right.

Yeah, right,

Nathan Toups (48:48)

It was not all electronic, even you know, fifteen years ago. and and so you know, but I I think that that's actually probably similar where the expectations of our job are changing. I think folks who are the Leadites, right? The ones who have straight up said I will not use large language models, some of them may find sort of a niche, high security job where you you know, like you're not allowed to to have anything leak out to a foundation model or maybe

Carter (49:12)

Right.

Nathan Toups (49:18)

certain types of system programming where they just aren't up to snuff. But I I don't know. I I've I'm actually having more fun than than I thought I would be, right? And so like I've kind of settled into this and I there's I've been able to re I've been I've been very fortunate. I've been able to redefine my job. Right. So I'm I'm working with a company that's really into AI stuff. They're really excited about the potential of it.

Carter (49:29)

Me too.

Yes, yes.

Nathan Toups (49:45)

And we've been really sober about identifying what things it's inappropriate for and which things it's appropriate for. And which areas we're we'd say are active experimentation, right?

Carter (49:49)

Yes.

I say, I say, look, provided my job still exists in 10 years, right? I am in this is the most I've ever enjoyed my job. Right. I I have heard, I asked on the experienced dev subreddit like a few days ago, then it got removed because you're not allowed to ask AI questions, not on Wednesdays, I found out. Anyhow, but I basically said, like, okay, I I I moved to a startup around the same time that coding agents became popular. And so to me, this is the fastest I've ever moved to my career. But I also moved to a startup after only working at

Big old companies, right? So of course it's the fastest I've ever moved. So I asked like people more experienced organizations, like what's it like? How has it changed? And something someone brought up is said, like, bad developers are a lot more dangerous now because previously they were, they were blocked by their own incompetence that you could just couldn't program, right? But now you have the slot machine. But it it's the opposite, which is like a good developer is also much more dangerous, is also much more productive.

Nathan Toups (50:36)

Way more dangerous.

Carter (50:51)

But I I think it there's a little to this that's like, it's like looking at a semi truck carrying tons and tons of goods down the road and saying, man, look at all those horses that got put out of work. Right. Think if we could transport all those goods by horses, how many horses could we employ? When the answer is just like, we never would have transported those goods on horses, right? We just we transport a lot more goods these days than we ever did pre-automobile.

And I think there's a lot to that with LLMs and software engineering, where we see it a ton at work where like we're just constantly opening up new surface areas of like, hey, we could bring this in-house, or hey, we could you know, like we think we could really improve the mobile app, right? Where previously it's like you can kind of like bemoan that and be like, well, previously they would have hired like a dedicated mobile developer, but I'm like, but that wasn't on the table, right? Like.

Nathan Toups (51:49)

Right.

Carter (51:50)

We we just didn't have the resources to do that. But my hope is that by now, because we can make some of these investments, we'll be able to grow the business faster. And like I think it, I think there's a reality where it's like if the ultimate vision of the company I work at in a pre-LLM world of if like Leland at its final form employed 5,000 software engineers, I think it's possible that Leland at its final form today only employs 2,000 software engineers.

But I also think it's not just possible, but probable that Leland never would have gotten the chance to reach its final form because they just were constrained by what they could do with the more limited resources at the beginning. And I think that's gonna hold true across a lot of companies, which doesn't say anything about all of the new businesses that are being invented because they use LLMs, right? Even and like here's like a funny example, right? Pangram. You know about Pangram?

Nathan Toups (52:48)

Yeah.

Carter (52:49)

Have

you seen these guys? It is an LLM detection business, right? Where they use machine learning, right?

Nathan Toups (52:54)

I do know I do know

so my my wife is actually a speculative fiction author. She's had a couple of published short stories, but she's like working on a manuscript. And so like I kinda keep track of like what's going on in literary stuff and the Pangram stuff, I I have s some outside knowledge, yeah.

Carter (53:08)

Yes.

But but so this is a business that now exists because of LLMs to to counteract LLMs, right? And so that's going to employ. And so like, while I think a lot of these micro SAS businesses might go the way of the dinosaur, I I I think like we're just it's just new surface area. It's new surface area across the entire industry, right? and this has kind of gotten off the idea of like choose boring technology. But you know, it's funny to think that one day.

Claude will be a boring technology, right? And there will be some new super duper LLM, you know, harness or whatever. And people say, just use Claude. Cloud's got an ecosystem. Just, you know, deal with the vendor lock-in. It's fine. Right. But it'll be funny. It'll be funny. And yeah, in five years, Claude Code will be a boring technology, I bet. we'll just we'll have to see how it all plays out.

Nathan Toups (53:57)

Well, and I I don't to round this out, and I think this is from a boring standpoint, Marquise Brown Lee just had like a a really fun little talk on did Apple win or lose the AI wars? It's it's so good. And and I think he it it's actually like this a dialogue between himself. It's like him taking two different perspectives, which just watching the video and how he crafted it, you're like, this is very clever. It's like really well put together. And one of the things I the big takeaway that I thought was interesting was that.

Carter (54:09)

I have to watch that.

Nathan Toups (54:27)

Apple typically takes the boring technology route. they're really good about wait and see, wait for the dust to settle and then dominate. And their are and his argument was actually really kind of interesting, which is that like, you know, Apple didn't become a search engine, right? Apple did not the Google went out and made, you know, a money printing machine doing search and Apple didn't, but Apple owns all the like a majority of the devices that people use Google on, right?

Carter (54:32)

Right.

Nathan Toups (54:55)

if you're not an Android user, you're using iOS or using a Mac. And the same thing with large language models is like, yes, they're not competitive when it comes to AI directly, but you're probably accessing it from one of their devices, right? It's just a delightful way of using it. And that when Apple as these models become more powerful, as we make distilled models that can run on locally on device, Apple's like uniquely set up to have a privacy first local AI that doesn't phone home and they're just sitting there.

Carter (55:21)

Right.

Nathan Toups (55:24)

And there's a huge moat that they're just gonna continue to maintain, being absolutely the best hardware that people are shooting for. In that long term, you know, we're probably gonna look back and go, my gosh, like remember the mainframe days of using foundation models where we like literally gave all of our private IP off to some foundation model, and we basically have something that's 99% as good.

Carter (55:39)

Yeah, I know, right, right.

Nathan Toups (55:48)

But runs on my device. And you know, we'll tell stories about the good old days when we had data centers that were taking over small towns and you know, and then you're like, all of that runs in my pocket. And who of the companies are uniquely positioned to succeed there? And I think that this is the this is the thing with like with boring technology, there's a sense of maturity that comes from it and says, I I love that this weird graph database exists. We don't need it to sell widgets online, right?

Carter (55:54)

I know, right.

Totally.

Nathan Toups (56:18)

Like in it from an engineering standpoint. And again, I I to loop this holding back. He was said he was so proud that that memcach D, he had just like not thought about it and it scaled up 20x and it was a boring thing. And it's like one of the great, you know, achievements that he had that he built something that you he literally just could ignore. and I think we should all aspire to that. I would love to have something that's like so beautifully architected that you could 20x it and be like, it didn't fall over. It just worked.

Carter (56:39)

Yeah.

Nathan Toups (56:47)

The way I wanted it to. That's awesome.

Carter (56:49)

we're gonna skip our usual wrap ups today, 'cause this has been a little more free form. but I I I guess can I speak for you, Nathan, as far as who do you recommend this to? I think anyone. It's a blog post. It's a great blog post, seminal in our industry. Read it.

Nathan Toups (57:02)

Yep. If if you need to talk somebody off a ledge, especially, and they want to do something doesn't pass that sniff test, you know, and you're like, I need good vocabulary and a great way of like bringing this up and kind of it it's just it's a good one, it's a good part of history, especially if you're building modern web app tools. you'll sound smarter at a cocktail party if you know what innovation tokens are.

Carter (57:05)

Yeah, I guess that's fair. Yeah.

And another plug for just being well read. And I I like that when I was exploring this kind of chat thing and I was talking with Claude about it and it introduced event sourcing, just kind of immediately being able to grok and be like read a book about that. I know what event sourcing is, I know why this pattern is used, and not just kind of blindly accepting it. So yeah, just be well read. And this is an easy way to be well read because it's about takes about five minutes to read. Anyhow, thanks for listening, everyone. Remember, we programmers next week. no promises, but Uncle Bob has been on the podcast twice and.

Nathan Toups (57:39)

Yeah.

Carter (57:52)

I'm optimistic we'll be able to interview him again. And you can always find us on bookoverflow.io. Email us at contact at bookoverflow.io. We're on Twitter at BookOverflow Pod. I'm on Twitter at CarterMorgan. And Nathan does work with his consulting agency at rohoroboto.com and his newsletter is there at slash newsletter. Thanks, folks. We'll see you next week.

Nathan Toups (58:11)

See ya.