Hey there, this is 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 and I'm joined here as always by my co host Nathan Toops. How are you doing, Nathan?

Nathan Toups (00:25)

Doing great here, everybody.

Carter (00:26)

Well, thanks for listening, everyone. Make sure to like, comment, subscribe, join the Discord. You can check out our new schedule lineup. We've got that all online at bookoverflow.io. We're excited this week. We've got another episode devoted to the Pragmatic Programmer by Dave Thomas and Andy Hunt. this this is a good one. I'll introduce the authors again and give you the book introduction. Dave Thomas is a computer programmer, author, and editor. He's written about Ruby and together with Andy Hunt.

He co-authored Pragmatic Programmer and runs the Pragmatic Bookshelf Publishing Company. Thomas moved to the United States from England in 1994 and lives north of Dallas, Texas. Thomas coined the phrase code cotta and dry, don't repeat yourself, and was an original signatory and author of the The Manifesto for Agile Software Development. He studied computer science at Imperial College London. Andy Hunt is a writer of books on software development and chill sci-fi. Hunt co-authored the seminal text, The Pragmatic Programmer, The Popular Pragmatic Thinking and Learning, and Award-winning

Practices of an agile developer, a half dozen other books, and many articles. Andy was one of the 17 original authors of the Agile Manifesto. He and co-author Dave Thomas founded the Pragmatic Bookshelf Publishing House, specializing in books for software developers, testers, and managers. And the Pragmatic Programmer is one of those rare tech books you'll read, reread, and read again over the years. Whether you're new to the field or an experienced practitioner, you'll come away with fresh insights each and every time. we should point out that

Carl Brown recommended this book to us, didn't he, Nathan, when he was on the podcast?

Nathan Toups (01:54)

Yeah. Yeah,

he when he originally came on and we had him like talk about books that he had an impact. And it's funny, he called out the second edition. And again, big shout out to one of our listeners in the Discord who reminded me of this. he he did. They they apparently from the first edition to the second edition dropped a chapter on code generation, which I guess is in some ways kind of old school. Yeah, unless you're in a programming

Carter (02:18)

Yeah, right.

Nathan Toups (02:19)

language well, I will say with the exception of Go,

Go because it doesn't doesn't have parametric polymorphism or more commonly known as generics, or at least it didn't for a long time. There was code generation that was a pretty important part of building stuff out. but I still think that they're like especially if you're using things like protobuf and some other tools, you still have probably a good code generation line or doing some sort of metaprogramming around that. but apparently the taper was just good.

good ideas, good practices. it was actually an extension of the dry principle and like, hey, you could use code generation to kind of do these unique implementations, things like this. But yeah, it would be worth going back and hearing Carl Brown's insights on this as it juxtaposed ours, right? So I think that's a kind of a kind of like a fun thing to go back into history and and see what he he has to say about it.

Carter (03:12)

Yeah, yeah. I've we were big fans of Carl Brown. I I I was actually thinking about him a lot this week. with I mentioned this on the podcast a few times, but Carl had a great video where he basically says that like this idea that like this is the worst the models will ever be is kind of a lie because models are software, they're not hardware, and software doesn't necessarily get better with each release. And there's been a lot of discussion this week on Twitter about Opus V and how Opus V is like

Kind of unusable and outputs a ton of like really technical techno babble jargon. I know. I still use Opus five and it works for me, but I don't think I like it any better than I did Opus four point eight and I don't know the thing about Carl Brown there. as far as or or you go ahead.

Nathan Toups (04:00)

Yeah. He also

shout out to shout out to Carl Brown as well. if you're if you follow Internet of Bugs, which hopefully you do, he also has a new podcast that he does. He has a co-host that is a PhD in AI. You know, I can't remember exactly which discipline in AI. The two of them sort of like go into these deep dive topics, and it is it's a small but growing podcast, and it's super good. Like I think anyone who enjoys

conversations that we're having here and you want to see first of all Carl Brown's strong opinions mixed with a PhD who really knows what he's talking about when it comes to the sort of AI frontier stuff, it's super good. So, you know, I'll we'll put a link in the show notes. I'll make sure that that shows up for the episode. just yeah.

Carter (04:47)

Yeah, yeah.

and I I was wondering, we had Jerge Oroz on the the podcast once. I I don't know the origin of the n of his blog name, Pragmatic Engineering, but I feel like it has to have something to do with this book, wouldn't I mean but do you think?

I don't know.

Nathan Toups (05:03)

I would imagine

so. I mean, you know, I think the big thesis of this book, and again, if you get anything from this, is that just like we've talked about in the past with Neil Ford and their sort of ideas at ThoughtWorks, everything is a trade-off, right? And I think the pragmatic this pragmatic programming book really is about, hey, look, here's a principle, here's why it might be applicable, here's what happens if you take it too far. And it's sort of this pragmatic approach, right, to doing our craft. Everything's a set of trade-offs.

And think that seed is I mean it has to be a shout out. I would'm I mean I'd be shocked if it wasn't just 'cause the pragmatic programmer and then the pragmatic, you know, pragmatic engineering is there's a lot of overlap as far as, you know, taking these practical approaches. So

Carter (05:51)

Well, so we are now about two thirds of the way through the book. We first week of chapters one and two. Now we've done chapters three through six. Nathan, give me your thoughts on this latest chunk of the book we read.

Nathan Toups (06:03)

Yeah, so you know, I talked about this the first week. It's the same same case here where it feels like there's a lot of like these truisms. Any one of these topics kind of stands up on their own, but it it does feel odd to me to kind of just go through a string of ideas, kind of like blog post-y kind of feel. None of it makes me mad. I mean, there's some things that I'm like, you know, maybe that's not my approach to certain topics, and hopefully we'll get into that.

But it doesn't have a through line where like I've learned these principles and now I'm gonna build onto it to the next one. It's more like, here's some themes on a topic, and then we're gonna move on to another set of themes. And so reading it cover to cover, and again, that's kind of our the way we operate. I don't know if you Yes,

Carter (06:51)

The end to end test, as we call it.

Nathan Toups (06:53)

the the end to end, you're right. The end to end test excellent.

Carter (06:56)

Yeah.

Nathan Toups (06:58)

The I the end to end testing suite for this is not necessary.

this is one of

Carter (07:02)

Ha ha.

Nathan Toups (07:02)

those where you can buy the book, put it on the shelf, kind of flip through the topics and familiarize yourself with things that you think you might need to dig into. But you I think it's really kind of meant to snack on. You just kind of snack on an idea, snack on an idea. you know, you could read it cover to cover, but I I don't know if I would if I wasn't doing this podcast, I don't know if I would.

Carter (07:24)

Right, right. And you know, and that common disclaimer on the podcast, we've said that about some books before, like I don't know if I'd read this cover to cover. That's never a knock on the book, right? Like we we just we

Nathan Toups (07:34)

No. Mm mm.

Carter (07:35)

have to do it for the podcast format. And so, it's just one of the kind of the oddities of this podcast, and that's totally fine. I yeah, I I kind of felt the same around a show notes. Is this a book or a dozen blog posts wearing a trench coat? and you know

That's not a problem. One of my favorite books in the world is World War Z. You ever read Read World War Z?

Nathan Toups (07:56)

I have not, it's I'm I'm I'm embarrassed to say. I've not read it.

Carter (07:59)

Well, it's a

great book, and but it's told as it's called an oral history of the zombie war, and it's told as a series of interviews, and so it's actually like 50 interviews between like a reporter and a subject matter, all told written in the style of someone of two people talking to each other. And so I love that book. And it's you know, it it tells an overarching narrative, but there's no really recurring characters in it. so I'm I'm I'm never gonna fall into the book for being a dozen blog posts wearing a trench coat. I think.

Reading this book, I have this constant kind of battle with the podcast, which is in an era of LLMs, what still matters as a programmer? Because while I I think that you know, I've said in the podcast before, like, I don't think our jobs are going anywhere. I think we've all just kind of moved up the abstraction layer a bit. And I think that experienced software engineers are by far the ones reaping the most productivity gains out of.

The LLM craze, which is, you know, really neat. But at the same time, it's like just just reading about Andy and Dave. And you can tell these people are just so such talented programmers. I remember feeling this at one of the bigger companies I worked at. I had the opportunity, I was like, I'm I was on an incident call with like one of like the senior staff engineers at the company.

And I just saw the way he manipulated code and like worked in his terminal. I was just, I was kind of like in awe of that. And and you wonder in an LLM era how much some of this stuff matters. And I and I genuinely mean that. Like sometimes when people say, like, you wonder how much this matters, what they're really saying is like, this doesn't matter. To me, I'm genuinely asking myself, like, what if this matters anymore? What if it is it?

Is this not important anymore? Or has it actually become more important than it ever has been?

Because in an era where you can move so fast, of course, the people who know how to steer the car are gonna be more valuable than they ever have been. I don't know.

It's it's yeah, okay.

Nathan Toups (10:05)

I'm I'm in the second camp in in a in this

in the same sense that like I'll put it this way there's a lot of tasks that I farm out to professionals, right? Like for instance, we have we have somebody coming by saying we have a these mini split air conditioners, right? Like down in Costa Rica, you don't have central AC, you you have these like sort of air conditioners per per room. And one of them is just it needs a maintenance cycle on it.

And I can watch a YouTube video and I could get the equipment and I could do it myself, but I really don't have to. And so I have two choices. I can either like dial it in, find somebody I trust and let them just kind of handle it entirely, or I can educate myself enough so I can call BS if they try to quote me way too much money or they tell me a bunch of things I need to get done to it that I don't need. And so I still think it it's still good for me to be educated into the fundamentals, even if I'm not doing the task myself.

And I think the same as per programming. It's like th there's a chapter in here, right, where we talk about like big O stuff and premature optimization. We're gonna get into that section. Even if you're not writing hot code path code because you've farmed it out to an LLM, you still need to understand like what your objective is. You know, what

Carter (11:20)

Right.

Nathan Toups (11:21)

are acceptable criteria for it to operate within? So you can farm it out. And I think that this gets into that sort of philosophy of software design realm.

Which I think is more important than ever. So I'm gonna be in the more important than ever camp, which is these books actually are incredibly important for us to be effective at you know interacting with things because I I've seen this over and over again, where I'll see really smart folks which I'll do all use what I call prototype grade code. You've described

Carter (11:50)

Mm-hmm.

Nathan Toups (11:50)

the thing, you've let the LLM kind of do it, you don't really understand the inner workings, and you kind of are in such a time crunch that you just kind of like dial it in, you like let it do a bunch.

And then you st need to start maintaining it. Or you realize there's an edge case that wasn't handled properly. Or you realize that like the model that you gave it was misinformed and the business actually needs to operate a different way. And then you get so tangled up. It becomes this

Carter (12:12)

Right, right.

Nathan Toups (12:13)

monster of it getting it confused itself and you're confused because you don't actually know how to reason about the system. And all of this gets back to like things we've saw time and time again before large language models when like dealing with legacy code bases, right? How was that different?

There was no test coverage, nobody understood how the code is. We're all scared of it. we're just doing this in real time with personal projects and y teams that are moving too fast. So

Carter (12:37)

Right, right. Your your

your personal project is now legacy code, right? Cause you Well, okay, so

Nathan Toups (12:41)

You you exactly. You

Carter (12:45)

maybe maybe I can share some of the like some of the things I read and I'm just like, you know, does does this matter as much anymore? Because I I'm I'm with you. This I I wanna make it clear to the listeners. I have not read the the middle third of this book and had a crisis of confidence and been like, my gosh, like you know.

What happened? But to me, it's a little, I don't know, there's a part of me that it's it's like, is it a little like watching John Henry, who is very he's a very skilled at building the railroad, but it just doesn't matter because the machine came in. And the answer is that like John Henry would be better at operating that machine than I would be, right? And

Nathan Toups (13:24)

True.

Carter (13:24)

you know, and so I'm not disputing the scale of John Henry as a as an expert of building railroads.

I'm wondering about the the mechanical skill of swinging the hammer and how much that matters. and and it that splits into kind of two things of like, there's some

Nathan Toups (13:41)

Carter (13:44)

more mechanical parts of programming, then there's also some of the lower level details. And just for example, like topic 18, this in chapter three. This is actually the basic tools, power editing, which is this idea that, like, you know, being mouse-free, we talked about this last week, right?

being able to to work in the terminal and I'm just like, I don't know, does that matter as much anymore? Does it matter like sometimes I feel it does matter a lot more? Like I actually because I'm in the terminal so much more with Claude Code, I and then like I have to pull up VS

Nathan Toups (14:13)

Right.

Carter (14:15)

code. I'm like, I don't know, man. Maybe I should just kind of lock in and finally learn how to use VIM.

Nathan Toups (14:18)

And

I'll tell you, this is a big debate. I've I've had this debate with folks because some folks are like, hey, you know, we're dropping into the terminal because the editors haven't caught up quickly enough and they're gonna come back, and then you know, basically any workflow you're doing is eventually gonna make it to cursor or you know, some other

Carter (14:34)

Right, right.

Nathan Toups (14:35)

AI first agenc thing. Pragmatic, the pragmatic programming book actually makes an incredible counter-argument, which is that you're always gonna run into these things. Like as soon as people start.

As soon as you start thinking about workflows, that the imagination it hasn't reached the IDE creator's imagination. You're really stuck on the workflows that they've defined. And I remember this happened. So there's it's kind of funny, like all things old or new again. I remember this happened within the Ruby community because they really, Ruby on Rails came out, the way that they started pushing web development really kind of got into this like really highly automated, super, you know, test-driven sort of.

methodology

and that they were building these pipelines that were just so optimized that IDEs hadn't caught up for a long time. And so everyone started getting back into like, we should learn Vim or Neo Vim and we should have preprocessors and post post postprocessors and do all these like kind of cool things. And it's just code. So we'll just like wire these things up. And so every time I hit save, it does like a bunch of magic. And at the time it was pretty novel. Like these things were pretty interesting and new ideas.

And and inevit inevitably we get back to code editors. And I did the same thing. I actually was really into Vim for a while. Then I got into Sublime Three. And then I got into VS Code. And like I just kind of and then and then it was like super easy for me to just like have a few plugins, not worry about it too much. I always had a terminal open, but VS Code was just super nice. Up until very recently, until we got back into the large language model stuff. And now I've gone all in. I feel like I'm like kidding out my computer like I used to, like 10

Carter (16:09)

Ha ha ha.

Nathan Toups (16:10)

year fifteen years ago.

I now have dot files that I keep. I have a Git repo for my dot files. I have a bootstrapping setup so that I can easily bootstrap virtual machines because I like to put

Carter (16:23)

Yeah.

Nathan Toups (16:23)

things in small blast radius. I'm back to using NeoVim. I'm actually using this thing called Herder now. I'm it's so it's very much like a terminal terminal emulator, you know, pane, you know, using like sort of a you know, using sort of a a Windows manager inside of the terminal editor.

And I love it. I'm like, I might I'm having a blast, but I've seen the counter-argument. They're like, nobody wants to do that. Everybody wants to have good GUI tools. You know, this you're like a strange anomaly here, which could be the case, but I'm I'm telling you, like, I'm loving it. I actually love that I have a whether I'm working on my local machine or I'm SSHing into something that's they're the exact same environments now. Like and and I'm

Carter (17:06)

Right, right.

Nathan Toups (17:07)

doing exactly what he's talking about here of the basics of the tools. And I think it

I think this part's aged well if you accept this type of workflow. And I don't think everyone will. But the idea is that, hey, if you in some of its novel, like they they have a whole section on like, why you should use version control. And I'm like, this is not a debate right now. You know,

Carter (17:27)

Yeah, yeah, right.

Nathan Toups (17:28)

this must have been left over from the 1999 edition.

Carter (17:31)

Right, right.

Nathan Toups (17:33)

though I you know, I'm I'm gonna contradict myself. I'm gonna probably get into debate myself several times on this episode.

I still am surprised when I run into folks who don't know the basics of Get. And I'm not meaning this in a shameful way, but I'll be like, you know, they'll they'll be like kind of deer in the headlights and be like, don't know how to deal with this merge conflict or something.

Carter (17:53)

Right, right.

Nathan Toups (17:54)

And then I'm like, hey, well, you know, what about, you know, just do this and you can rebase you like we're just kind of like the stuff you'll do. And they just kind of get deered in the headlights. And I'm like, okay, we actually need to take a step back. And I you just forget that like.

fundamental concepts of Git are ubiquitous. And there are people who've probably, because of IDEs and some of the magic of GitHub, have

Carter (18:14)

Right, right.

Nathan Toups (18:15)

probably sidestepped a lot of and maybe have never even used the Git command line tool, right? which can be scary. You know, it get

Carter (18:22)

Now I

I I'll say I will shame you if you don't know how to use the Git Cli. Right.

Nathan Toups (18:27)

Yeah, well, okay. There you and and

and so but then I'm deeply encouraged. I'm like, hey, let's do a session. There's actually like four git commands that if you know these, you can get pretty

Carter (18:38)

Yeah, right.

Nathan Toups (18:39)

far through, right? Like you know, like obviously there's ways to level up and do more more stuff. I will say also, Claude and Codex and these other tools are really good at teaching. And I've also encouraged folks to be like, teach me how to use reflog. Teach me

How to use the rebase tool interactively so that I can walk through, you know, like if you learn these tools and then it kind of helps you conceptualize what's going on, all of a sudden gets like the coolest tool ever, right? And and you're like,

Carter (19:11)

Right, right.

Nathan Toups (19:12)

I can do, I can manage all kinds of things. And so I I think that where I like about this first chapter three is that part of our craft about being pragmatic.

Is that you should just invest time and understanding your tools and don't have to worry about shying away from custom workflows. Right. I think this gets back to like Mythical Man Month. The the the there was that one persona that he had in there, which is the person who built the bespoke tools, the sharp tools that happened internally. It's so easy to build sharp tools now, right? It

Carter (19:44)

Right, right.

Nathan Toups (19:45)

used to be that we would go yak shave and go off into a weird path, and now we can build pretty good personal workflow tools.

that I don't know, I I have all kinds of bespoke stuff that, you know, digs into this and this I think this book gives you a philosophical framework on like why this is actually not a crazy thing to do. It's actually like a really good thing to do.

Carter (20:07)

I I totally agree on this idea of like how how much easier it is to create bespoke tools these days. I just had Claude write a simple script for me because now that obviously we got a bunch of agents running, there's like the validation is kind of the bottleneck on a lot of code these days. I was getting tired of like I'll take screenshots of the stuff I work on so I can put in my in my PR right as I'm validating it. And I got tired of having to rename the screenshot file. And so I have my screenshot the shape.

Save directly to my downloads folder. So I'm like, Claude, can you just write a script like that I can run from my command line that just renames the first item in my downloads folder? It's like, yeah, totally. I was like, wow, like we're living in the future. I another note on version control is I remember when we read Just for Fun by Linus Torvalds, and I forget the name of his co-author. but and like I was so excited.

When I was listening to that book, I was like, man, like this is great. Like, I I love hearing about Unix. Imagine how exciting it's gonna be when he invents Git and then the book just ends because Linus Torvald contributed so much to the programming world by that by before he had invented Git to justify writing a book about him. And so I was like, dang, like, I know we

Nathan Toups (21:23)

Isn't that wild? Yeah.

Carter (21:25)

need a sequel. yeah, yeah, and and I'll point out version control too. That is, do you remember what Martin Fowler told us about version control?

Nathan Toups (21:35)

I actually don't.

Carter (21:36)

Yeah, we we asked because Martin Fowler's the one who told us that he doesn't like the term best practices. He likes the term sensible defaults. And he said he was having a debate with a buddy once and they asked, is there anything you should always do when programming, no matter what? They said the only thing they could agree on was version control. Says even logging. You might have programs where it doesn't make sense to log. but version control is the one thing that you should

Nathan Toups (21:56)

Interesting. Yeah.

Carter (21:59)

that it's basically there's no reason you shouldn't have it in any program.

Nathan Toups (22:03)

Which speaking of, I the again, me, maybe just because I've watched too much YouTube, there's a there's a YouTube channel I've watched forever. It's called the Eight Bit Guy. love that love that channel. And he's still like doing assembly programming on these like Commodore type systems in you know 2026. He has like some games and other kind of cool stuff. He doesn't use version control. He l he I think he has like

a Dropbox folder, if I remember correctly.

It's like a Dropbox folder where he'll each day he'll make a copy of it and then like date stamp it and then do his work. And of course, the comments are hilarious, but he just never learned version control. And of course, he was programming way before the era of any modern version control system. I think this is just something he's comfortable with. And of course, he has I mean, I guess it's kind of version control. I mean, maybe if you squint, very manual. You don't get any of the like cool like diffing tools or this other stuff.

But it just it kind of blew my mind that anyone wrote code in twenty twenty six that didn't use version control. And

Carter (23:05)

Yeah, yeah.

Nathan Toups (23:06)

so yeah, it's still quite applicable. 'Cause you know, I I think until you kind of like wrap your head around certain patterns, you know, you just pick the tools that work best for your mind.

Carter (23:18)

Here's here's a problem, or I guess a problem space, where I do agree that it is still more valuable today. In fact, incredibly more valuable. I have a whole topic on debugging in chapter three. And I love this that they they say when you see hoof prints, think horses, not zebras. And there's this whole idea that, like, when debugging, you should be thinking about like what the most common problem is. Don't go racing off to some

Really weird you know solution

Nathan Toups (23:50)

No.

Carter (23:50)

or you know, theory. And this I think can only come from experience. This is what happens just as you encounter more and more bugs, and that's when you start to learn, okay, this is very clearly a horse. And okay, wait, I've I've never seen this before. I've ruled out the the three most common solutions. This might be a zebra, this might be something really strange. And

Nathan Toups (24:12)

It's

Carter (24:13)

yeah, like, no, no, go ahead.

Nathan Toups (24:15)

I I

love that. No, no, no. It's it's this is really interesting too, because I remember there's two sides to this. One is I think you can get jaded enough to always assume it's a horse, right? I've seen so many

Carter (24:26)

Right, right.

Nathan Toups (24:27)

hoofs, it's always a horse, it's never zebra. And most of the time you're gonna be correct. And it comes with experience of being like, dude, it's not a zebra. It's not this exotic, crazy, weird thing. Like you didn't get hacked, somebody

Carter (24:41)

Yeah, yeah.

Nathan Toups (24:42)

just did something really dumb, right?

But sometimes you do get hacked. Sometimes it is a zebra. And I think that sometimes having young minds looking at this where you're like, you know, I know you think it's a horse. I know it really looks like a horse, but I I in this case I don't think it's a horse, right? And so sometimes I think this is actually why it's nice to have a mix of experienced and inexperienced. Some of it is to teach them, hey, it's not a zebra, right? It's really not.

Carter (25:07)

Right, Mm.

Nathan Toups (25:07)

I sounds exciting. it's always it's also exciting because you've learned about zebras recently in college, you

know?

Carter (25:14)

Yeah.

Nathan Toups (25:15)

And so you're like, man, zebras, it could be a zebra. And you're like, it's just a horse. It's just a horse. The the other side to this though is I remember when my my grandfather on my on my mom's side is a was a doctor. He passed away a few years ago. But my my father is also a doctor. And I remember when he first got out of medical school, it was exactly this. Like he would look up his diagnostic manuals, he would look at the stuff, and you know, the his mind would be inspired by some like,

strange and like edge case, you know, prognosis. And my grandfather, who is just kind of a country doctor, his he just kind of very practically, yeah, I think you need to try the simple thing. And you know, if it that doesn't fix it, then we'll come back later. You know, and he just always started with these very practical things, not saying that it couldn't be that strange

Carter (26:05)

Right, right.

Nathan Toups (26:05)

edge case, but most likely it's not. Most likely, and so it's and so he wouldn't like confuse or concern the patient.

where when my dad was like a brand new medical school student, you know, that's what they do. They're like, it could be this rare condition. So we need to keep an eye on it. And then of course the patient's like super worried, is like, my God,

Carter (26:23)

Right, right.

Nathan Toups (26:23)

I have this like the craziest illness potentially. And so I think this is the same thing where like you can get these, I I I've run into this in the software world. A new engineer can just totally derail something on accident by putting in a red herring where it's serious enough, if it's true, that we should pay attention to it.

But it probably isn't true. And it's like how much how much like how much space do they take up on the room can like put us all off on a red herring or a wild goose chase? And there's something to that with like the debugging piece, which is it's typically the boring thing. And you should start from the most basic assumptions and then build up exotic assumptions on top of it, right? but yeah.

I like this debugging section. I will tell you, I've seen folks who use like advanced debuggers and stuff. I've actually never been, I'll be be completely honest, I've never been like an advanced debugger tool person. I am

Carter (27:22)

Neither am I.

Nathan Toups (27:23)

I use and abuse print statements and I use and abuse test suite coverage if I do want to like get into the inner workings of stuff. and I think we we will get into a bit of the of the testing stuff too, which I which I think is good. But I do like what they talk about this debug mindset.

Of the the debug mindset where you know you basically have to have you have to be in the right headspace to try to think about how things can go sideways or things can go wrong. and not in sort of question your assumptions, right? That you you need to be, you kind of have to have this pull. I'm I'm witnessing the stuff that's going on around me. You know, don't go in and immediately prescribe a solution to it. You're like, I I really do try to like kind of clear my mind and go.

What could have gotten us here? Like how, why

Carter (28:12)

Right.

Nathan Toups (28:13)

are these surprising logs showing up? Or why is the output of this not what we know that the state of this should be? and it's it's a good thing to practice. I I I really do. I I again, I think this book's full of wisdom. and people who get twisted up and tangled up, it's because they skip these basic steps.

Carter (28:33)

Right, right. Well, I I I've talked about kind of the sugar high with large language model development where you're just like, I can I can tune this up and ship this feature and and blah blah blah. And like I I've been doing that. we just redesigned our mobile app, which is great. I think our mobile app has been neglected for a long time. I'm excited we're making a lot of div investments into it and and I'm really, really happy with the design language that we in product and design all came up with. It looks really good.

But you know, I just have been spending a lot of time just having Claude run around the app and just tune things up and tweak things and make them look better. And and so I'm thinking to myself, kind of like this past week of work, I'm like, well, how much debugging have I done? And the answer is like, not much. Cause I've basically been do playing extreme home makeover with a React native code base, right? and like, and it's fun. But the answer is that, like, that's not any different than pre-LLM. Pre-LLM, it was exactly the same. You could get a sprint.

Where all you're doing is just writing easy code, you know, adjusting for kind of some trivial front end or UI stuff. and and and so like, yeah. I I don't think I I can spend a week doing this and being like, gosh, like what or do I even do anything in this profession anymore? I'm just like, well, no, I think the answer is you just had some important work, but some easier work. And this work was easy before L.

Right. Cause anytime I get into kind of these like you're talking about where you need the debugger mindset, it's like, well, I think LLMs, they certainly type faster than I do, but it's not like they are just constantly solving novel bugs. And I'm just like, I don't even know what's going on here. Right.

huh.

Nathan Toups (30:20)

I I think part of this comes with with getting good at your craft, right? You know, I

Carter (30:23)

Right, right.

Nathan Toups (30:24)

would imagine if I go to a master pro master potter and I want some custom bowls or something, I would hope that like the act of making the bowl isn't the hard part for them anymore. Right. Like I hope that they would

Carter (30:36)

Right, right.

Nathan Toups (30:36)

actually be therapeutic or even simple, or they might even think in their mind, I can't believe I make money doing this. I love this. My favorite thing in the world. But when if we get a challenge of like, hey, can we use this color, this material, or

You know, I want the theme to be like this. And they have to really kind of think about like, how would I express this? Right. Like them being this higher order creative, that's where I want them to be struggling a little bit. Right. and I think that's really hope what I hope with large language models is that, hey, part of the craft we can actually kind of like, you know, okay, I have a set of principles. Here's my expectations, these things are in place. And where we get to like sit there and go, is this well architected? Do I have

Do I understand the the expected behavior and the test coverage? Can other teams rely on the contract? And we'll get into the contracts a bit, but can they can they rely that, hey, we're not gonna break this contract? We're doing crazy aggressive stuff internally. those things again, they don't change and they're constraints that you have to put on your LLMs, otherwise we all lose lose our minds, right?

Carter (31:40)

Right,

right. Because nothing about software development has changed. I I stand by this, right?

Nathan Toups (31:45)

Mm-hmm.

Carter (31:45)

That you can argue that you can create this software factory that builds itself, but really you're arguing that you can coerce the LLMs into creating well-designed software. We we're not we haven't

No one is disagreeing about what well designed software looks like, right? Like th it's not like L L Ms have introduced this new paradigm. Well

Nathan Toups (32:07)

Well, so I do think people are just I don't think it's a solved problem. I g where I guess

it's still aesthetics, right? So and I and I'll say this

Carter (32:13)

Right, right.

Nathan Toups (32:14)

in the sense that like you can open up architectural digest or dwell magazine and go and look at the types of houses and you go,

Carter (32:20)

Right, right.

Nathan Toups (32:21)

Wow, somebody thinks that this brutalist architecture is beautiful, and I think I would want to die if I lived in that. Or you may look at it and say, they've done a neo-Victorian, you know, rebuild, and then you're like, this is the most over-the-top.

Gross thing ever, and somebody else goes, that's amazing. I'd love to

Carter (32:38)

Right, right.

Nathan Toups (32:39)

live in that. I do think that there's still an aesthetics to it. and but I do think that we know what bad looks like. Like I think that it all of us can go, okay, that's a design

Carter (32:49)

Yeah, right.

Nathan Toups (32:49)

perspective that's not my cup of tea, but it's internally consistent with the what they're going for, right? Versus like you look at somebody like, this was just duct taped together and it's insane. It looks like it's gonna fall over. And you know, like all of us can understand sort of aesthetically.

Carter (33:04)

Well

l let's talk about I want to talk about chapter four, but this is a good segue into parts of chapter five, which is called bend or break, right? And this is about decoupling. And and I think that to

Nathan Toups (33:11)

Yes. Yeah.

Carter (33:14)

me is like no one is arguing in the LLM era that like actually coupling tightly coupling things is a really good thing, right? With the power of LLMs, you can tightly couple your software and doesn't matter anymore. Like, no, like I think I hope no one's saying that, right? Like decoupled software.

is still really, really valuable. And and that's the other thing is like it's so weird in the LLM era because like there there's a very frustrating feeling of like you ask the LLM to implement something for you. And and you, you know, you define, you think you prompt it pretty well. And then before you even read the code, especially if it's like a UI thing, you'll go and you'll use the you'll you'll validate the feature, right? And make sure that it's working.

And

then you're like, that's awesome. It works. And then you read the code. And you're like, what on earth happened here? Right. Like I had this happen where it was like, like I needed it to get the details of of a relationship between two users. And that relationship is model in the database. And so we have a list relationship or we have we have just a get relationship endpoint on the back end. I'm like, I assume I'll do that. I come back, I look.

That's not what it did. Instead, it lists 300 relationships and grabs just one of them off of it. And I'm like, what on earth happened here? Like, why? And so I asked, like, why did you do that? It's like, well, it says the shape between these two back end endpoints is actually different. And the single get relationship endpoint doesn't have all the information I need, but the list relationship endpoint does. And my first thought is like, why on earth are the back end endpoints running that way? But

At the end of the day, it's like, if I were programming this by hand, I would have ran into this. And I would have said, what? This is goofy. Like, what's going on here? Okay, before we can build the front-end feature, we've got to fix the single get relationship endpoint. But now it's like you look at the code and it's so frustrating because it's like, man, this thing works. And I can't just submit it and move on with my day because I've got to, you know, fix this madness that it did. And that's a

It's just very weird. It's very weird to get that kind of like dopamine of here's the working feature and then have to be like the responsible grown up and be like, but I can't eat candy for dinner. Right. Like I gotta

Nathan Toups (35:43)

Right.

Carter (35:43)

like I gotta go and fix this. But before I never would have even gotten to that point, I just would have fixed it before I even got the feature working.

Nathan Toups (35:50)

Well, and again, th this is why you know, it I think that it's so dangerous. And I don't mean dangerous in like the world's gonna end. I mean dangerous in the sense that it's very easy to fool ourselves that we actually are talking to something conscious or you know, with intelligence, when it's absolutely not. Right? It's

Carter (36:04)

Right, right. Right.

Nathan Toups (36:07)

a tool, it's not a person, and so like reasoning with it or thinking that it's gonna think ahead and like sort out the bigger picture is not it it's it that it gets us to the so s soctic.

it Socatic Parrot? but you know, the the whole idea that like it's gonna give you an answer that sounds like what you want, and it doesn't think into the bigger question of like, hey, if I categorically simplified this, this is what you really want, right? This is what we're good at as agents, as humans. We look at the business, the business asks us to do something, our gut tells us this sounds kind of crazy, or our gut says, you know, I don't think that's possible in the way that you're doing it.

And you look at things and you come up with a new solution that says, hey, I can get you the outcome you're looking for. Not only can I get you the outcome you're looking for, if we do it this way, we can 10x or 100x what you're looking for. We're going to build this machine that does this thing better than any human ever could. And this is what machines are great at. And if we structure the data this way, we can do these things. you know, I don't think like at least the way that these tools are built right now, that higher order thinking isn't just isn't part of it.

One of the things that helped me, I and again, I think it again, it ties into the pragmatic side of this. I I keep talking about Matt Pocock. I like I think it's probably just like a meme at this point. If you're gonna do a drinking game, it's a good one to to, you know. but I've been using Wayfinder. He it used to be called Grill Me with Docs, but now it's Wayfinder, which is like an even better tool, which helps you break up any sized problem into smaller pieces that you can have in small context windows.

And you can use whatever backend you want. So you can use like a to-do list type, you know, plan.md file. But I typically will use whatever issue tracker that we have, which is cool because humans and LLMs can read it and you can break up problems and you can map things out and you can do this just nice like work stuff. It asks you a bunch of questions to make sure you understand what you're asking for, which I think is really helpful. Kind of work through it, plan out stuff. And then I find myself at checkpoints doing a lot more where

I'll get it to do a chunk of work. I really have to understand it with certain code paths that I'm on. So I'm me I'm being a little slower, quote unquote, or a little more hands-on. But these are like I'm working on something right now with a client where we're building a Kubernetes operator on some really important state machine stuff on some really important custom you know custom resource stuff inside of Kubernetes. It's like pretty hairy things. It has to be super battle tested.

And so a ton of what I'm doing is like what I I have like this whole stress test suite. I have this whole stress test suite. I have these we're trying to look for state machine thrashing issues, all these other things. And so I spent a lot of my time building that out. And then

Carter (38:58)

Right, right.

Nathan Toups (38:58)

we build the then we build our controllers, all these other things that kind of like do all this Kubernetes magic. And I can go in with confidence, farming out certain things, understanding what's happening in place, and then appl applying this. My lines of code are way down.

like way down than their a

Carter (39:16)

That's great.

Nathan Toups (39:16)

previous implementation. I'm very confident about the tests not being BS. And this is the kind of I've I've been trying to take this approach to the type of work that I'm doing. but it but again it's super principled. And it's me being like anytime I ask it to do something, I'm like, how could it try to trick me? How could I be tricking myself? what's really going on here? It could if somebody

Took

a look at the code and then asked me, What is this thing doing? Am I gonna be deer in the headlights? That's the my biggest one is like, I've had this happen in the past. It's been very embarrassing. Where somebody's like, this is really interesting. I've never seen this pattern. And like, yeah, me either. Me either.

Carter (39:53)

Yeah yeah.

Nathan Toups (39:56)

yeah, don't do that. Don't be that guy, right? So, and

Carter (39:58)

Right, right.

Nathan Toups (39:59)

so anyway, it's and it's mostly scar tissue, right? It's like, I'm like, how much can I find it in? actually.

Anything I care about or anything I want my reputation on, I'm still going to understand. Even if I farm out it again, I I know I'm going on the whole screen right here. I think part of this too is that like I've been an engineering manager in the past. And engineering managers also have to be able to speak to the output of the code, even if I'm not looking at every line of code. I'm not. If if you're an engineering manager, you shouldn't be looking at every line of code. You should have a team that you trust that is making

Hitting the specs, but I should be able to get into the code. And I should be able to talk to an engineer and grill them and be able to get into what I'm doing. I do think it's different using large technology models. You're not straight up an engineering manager because you're not managing humans. But I do think that you're

Carter (40:47)

Right, right. I think it's more like being a staff engineer.

Nathan Toups (40:50)

yeah, or like a tech lead, right? Like I'm accountable

Carter (40:52)

Yeah, yeah.

Nathan Toups (40:52)

for the output. I do need to be super hands-on in the code, but I might be like get this other person to help write some implementation, and then we kind of like meet up in the middle, right?

Carter (41:02)

Right, right. No, I and i it it's it's really nice hearing about your kind of the this this Kubernetes work that you're doing. I am I I've said this mod podcast before, but I I I really like product work. Like I am that's that's really fun and fulfilling to me. I like anything kind of like as close to the customer as I can get it. And so being able to like

Redesigned the mobile app this week. Like I love it. I love just holding up like I took just screenshots of before and after in a like demo day. I'm just gonna show them to the company and be look how much better this looks. This is awesome. but I'm I'm not gonna kid myself here and say that this is like super deeply technical work, like shuffling React native UI components around a screen, right? But I like it. I I I like it a lot. but I also really like, you know, two weeks ago or so when I

Created this whole notification registry concept and, you know, was able to migrate kind of our bespoke bespoke notification handlers all into this one unified pipeline, which reads from this custom registry. And then that lets you, you know, it that registers all the different channels that a notification gonna go out and how they're rendered. Like that was a a stickier engineering problem. I really like that too.

But then, you know, I'm I'm also thinking about like when I set up our when I migrated us off of Azure to AWS. And that's actually one looking back that I think I did this in it's like August of 2025 and it was before January of 2026 this year was when the models kind of got like really good and everyone started going like okay, maybe there's a a there there. And so I I freaking migrated us from Azure to AWS by hand. Like I didn't even write Terraform, which is crazy. Right. And now

Nathan Toups (42:51)

Yeah, yeah.

Carter (42:53)

it it would have been so much easier.

I should have done Terraform anyhow. I had like this 30 point checklist of like how to set up the system. Like, you idiot. Like just write the Terraform.

Nathan Toups (43:02)

Well, I will tell you though, we

just did this recently where there was a new I was working on an Azure project actually, and we just did this yesterday. So this is like hot off the press. We were setting up the managed Kafka that's in Azure. We needed it to talk to Databricks. It's just two systems that we had. Those are just core systems. And we're doing more event streaming work. We want this to go across app contexts. And we it gives us these really nice.

decoupled features. Now we can talk about these, you know, these data contracts that go across Kafka for anybody who wants to pay attention to the whatever topics. And we had never set we'd set up these tools, other systems, but never these exact ones. So we did a mob programming session where really it was a mob click ops section where we had an LLM who like kind of gave us a guide. We just were like, we've never done this. We're not going to dial it in.

We click ops our way through. We like did an implementation in the dev environment by hand, made sure it worked. And then we're like, okay, cool. Like we're gonna go back and write this in Terraform, right? Like we're gonna but it was it was one of those things where it was like, I can't, I don't know if I'm just gonna agree to the vibes if I just let it tell me, versus I need to personally experience it. And so I think that doing a checklist where you've manually done it gives you a deep appreciation of like what you're actually doing so that you can be educated if you're gonna lean on something to help you.

generate a bunch of terraform, right? because I've seen

Carter (44:33)

Right, right.

Nathan Toups (44:34)

I've seen it generate some pretty awful terraform if you don't know you're doing. or twist through a bunch of crazy, you know, formality it is. It doesn't need to be there when you really just need something much more pragmatic. So chapter four, we we've been talking about this a bit.

Carter (44:47)

Yeah, I wanna talk about chapter four.

Nathan Toups (44:49)

Yeah. So chapter four is called Pragmatic Paranoia. And I I spend a lot of time in this world. Maybe it's just because I'm a paranoid person. you know if you want to have a good

conversation

about what the CIA and the NSA is up to. This is this guy. You know, like I I that's just me. I love intrigue and conspiratorial stuff. I also like to think of my computers this way. And defensively building design by contract, making sure that you like are, you know, trying to make sure that your programs don't act in surprising ways is a way of thinking about systems that I love. So this chapter was really a f a fun one in in in general.

Carter (45:30)

Yeah, yeah. I I I enjoyed the the design by contract chapter. basically I'm I'm trying to remember. We we got here in our show notes. I like that this idea of lazy contracts, that you should be strict about what you accept, promising as little as possible. I'm a big fan of kind of strongly typed languages. I like this idea that you can be very specific about like, hey.

You you I need exactly these things from you and I'm going to give you exactly this data back. there is I again I we we used MongoDB for a bit. I do not like MongoDB. and part it's web scale.

Nathan Toups (46:11)

It's web scale though. It's web scale.

Carter (46:15)

I I I think we've put that in the show notes before. Yeah, yeah.

Nathan Toups (46:16)

Who needs to think about schemas, okay? Just

just don't worry about the schema.

Carter (46:21)

That that's a great it's a great video. The the MongoDB is web scale. It's like

Nathan Toups (46:25)

and that

that I don't it I don't think they they cite that the the strict in ex what you accept and lean I'm sorry, strict in what you omit and lenient in what you accept is postel's law. That's actually like one of the

Carter (46:36)

Mm-hmm. Okay.

Nathan Toups (46:38)

the the concepts. And I think it's a good one in general, right? So hold yours i I like to think of it as I hold myself to a higher standard, right? I I've talked about this with my daughter. You may not you you might be doing something that's not against the law, but maybe

Carter (46:52)

Right.

Nathan Toups (46:52)

breaks a moral code.

You should hold yourself to your moral code, even if it's not technically illegal. and this

Carter (46:59)

Yeah.

Nathan Toups (47:00)

is how society, a proper society functions, right? Like I try to be internally consistent with my values. and I maybe try to even hold myself to a very high standard, but I should be lenient in what I accept from others, no, understanding that maybe their standards are slightly different than mine. Now, I shouldn't violate my standards, right? I'm not going to accept you know, certain things, but

You know, I think that this this this sort of like method is just a good one for general life, but it's a great one for programming. you know, y

Carter (47:31)

Yeah.

Nathan Toups (47:31)

you you try to react to like, maybe it's not quite right if I can put in a couple of defensive, you know, correct, you know, self healing type of rules in place and I can get exactly what I need, think cool. But I'll be super strict to the spec for anything I send out, right? It's like pro social behavior.

Carter (47:48)

Yeah.

I'm a big fan of pro social behavior, not just in

Nathan Toups (47:51)

Yes.

Carter (47:52)

in society, but in programming.

Nathan Toups (47:54)

Yes,

yes. Be pro social. Make it be the engineer that all the other engineers are happy to work with, right?

Carter (47:59)

know. I I and I think about yeah, it's a but you know, I I had it bite me twice this past week where I I went out of my way to to solve a very specific problem for a user. And then I just like fat fingered something and and it broke a a chunk of the website. which was one of them was we switched over to

this a couple weeks ago, we we rewrote our messaging service. We we got off of a a provider and decided to bring it in house. We brought it in house using Cloudflare durable objects, which gives you it's like a kind of a WebSocket technology, really neat stuff. but Cloudflare, they just give you the default, they just give you like a workers.dev URL, right? And it was working for us, and so we didn't think anything of it. And so we're just like, okay, that that's the URL. Anyhow, customer gets back to us and it's like, hey, your inbox has always worked for me, but it doesn't work for me anymore.

What's going on? And and so I'm like, okay, you know, like this it's one specific guy. And so I said, like, okay, can you I instructed him how to download a hard file from the computer to so I get a history of his network requests. By the way, Claude is super helpful with that. And so I fed the hard file into Claude. I'm just like, this guy can't connect. Like, what's going on? And he said he's like, and Claude was like, it he's got a z scaler on. It's it's a and his computer is blocking any requests to the workers.dev yeah,

To the workers.dev address. And so I write back to this guy, and I'm just, I'm like, by any chance, are you using this on a work laptop, not a personal laptop? He's like, Yes, I do all of my personal business on a work laptop. I'm like, well,

Nathan Toups (49:37)

Yeah.

Carter (49:38)

for starters, don't do that. But I was like, you know what? Fine. I'm gonna be a nice guy. I'm gonna set up a custom domain. We'll have, you know, inbox at dot leland.com tool. And that's what we'll do our our worker.

Nathan Toups (49:49)

Yeah.

Carter (49:50)

We won't do the workers.dev URL.

And because I'm such a nice guy, I talk to the people who do the live stream because the the our live streams have their own chat functionality. And they they do a similar pattern to us. I'm like, hey, while I'm getting our custom URL set up, do you want me to get a custom URL set up for your WebSocket, you know, durable object thing? Like, you know what, that'd be great. I'm like, great. So I do that. And then because I'm such a great programmer, I don't hard code these values. No, I I'm like, well, we'll we'll we'll do them via config. And

And do it via environment variable. And we even inject our environment variables via GitHub variables. And so I'm like, I'll do it all the right way. And it works. And I'm like, and because I'm such a good programmer, we'll test it in staging first. We won't, you know, just to make sure it all works locally, but let's make sure it works in staging. And then if it works in staging, we'll get it set up in prod. And so I have two variables: one is inbox.jointLeadan.com, the other is chat.jointle.com for the two different web sockets. And when it comes time to deploy it a prod, I set both to be inbox.jointLean.com.

Instead of inbox and chat, and it broke the chat

Nathan Toups (50:52)

yeah.

Carter (50:53)

functionality. And I'm like, this all stems from trying to be a good guy and solve this one person's very specific problem and then extended past that. I'm trying to be pro-social

Nathan Toups (51:00)

Yeah. I don't know.

Carter (51:02)

and be hey, as long as I'm doing all of this, let me help out the other team too. And then just at the very end, like I just fat fingered it. And so it wound up, we had to post more about it. It wound up being a good thing because we said, you know what? Why do we even have some of these config variables in like injected via GitHub and environment variables? We don't need that.

And if we were doing this via code review, we would have caught this. We would have caught the fat finger. And so we wound up switching everything to to do that. So, like, you know, blameless post mortem and and and it made sense.

Nathan Toups (51:26)

Cool. Yeah. Sounds like some good

like five wise type material and getting down to like the essence. That's yeah.

Carter (51:30)

Exactly, right? Well, no, what

I learned is don't help anybody. If I just you know yeah if I had

Nathan Toups (51:35)

There you go. Never help a person and then it will never bite you because

Carter (51:39)

been incredibly antisocial, this wouldn't have happened. but but it it really actually speaks to having a great team and everyone no we're very very big into the blameless post mortem and and we just kinda yeah, we kinda did the five wise thing. We're like, okay, well, wait a minute, like why why is this even possible? Why is it even possible to have this mistake? And so really that's what hurt.

the LM era era, I can't recommend that to enough. Like just have good teams. It's always been good to

Nathan Toups (52:05)

Carter (52:05)

have a good team.

Nathan Toups (52:06)

there's some interesting ideas in here too. And I think, you know, we have a pretty decent part of our community that when I was we were talking about validation versus parsing, we got some pushback and they were like, hey, parcel validate. There's like a really good theory on this, especially from the functional programming world that hey, you can lean on types and type systems to do a much better job than like a bunch of validation logic.

And it's funny because topic 25 in chapter four is called assertive programming. And it actually advocates for doing a bunch of I'm thinking this thing should never happen. I should throw an assert in here that set it makes sure that it is it fails, you know, sends a big stack trace or something if if if this existential thing ever happens. it is a school of thought, and I will say that I understand where people are coming from. I'm actually not.

And a fan of doing assertions. And again, maybe this is because I'm a Go programmer. We don't have you are panics are considered a really bad thing. Control flow, we don't lean on exception handling. Like that's just not you know, errors are values like anything else in Go. And so panics are really this like sort of existential thing. Most programming languages, that's not the case, right? You're dealing with a try-catch, you have exception handling, it's control flow in like most.

Languages and then there's languages like Erlang, who that's like the way that it works, right? You just you just kind of like it it it's whole like way of doing self-healing. And so I think that depending on the what your type of programming you're doing, this sort of assertive programming approach where I literally throw in an assert existential thing that should never happen and and then have it there.

I'm a much more of a fan of the Osterhout ideas of, you know, could write the errors out of existence, right? If if at all humanly

Carter (54:03)

Right, right.

Nathan Toups (54:03)

possible. and so those are two different schools of thought. I think they make a good case for the assert side. Again, I I I can I can look at something and go, yep, I can see why that's useful. Even if that's not the style that I typically pick. I try to make it I I'm much more of a type system person where I want my type system to be able to handle these existential things.

So that it you don't have to have a bunch of asserts, but that's not always the case. And if you do need this sort of type of programming, I mean, they make a a pretty good case for it.

Carter (54:33)

Yeah, well, and they have a great story with he like their buddy's company where they do a ton of assertive programming. It was like a it was like a networking devices company, but because d just because networking devices can have so many different kind of combinations and permutations of failure modes, that they did a ton of assertive programming in the devices themselves. So when they were deployed to the field, whenever there was any sort of error, and this was kind of before like

open telemetry or you know the ability to kind of send the the data back over the internet. They had like really good error screens and like output when when something would happen. And so they would just every anytime it would fail, they just asked the customer, like, okay, you know, what are you seeing? And they would walk them through if they could fix it themselves or they could, you know, email all the data to them. And they wound up making just such robust, such stable devices that like they got acquired for like hundreds of millions of dollars in part just because

Nathan Toups (55:28)

Yeah.

Carter (55:29)

their code

Was so good and so usable, which was pretty neat.

Nathan Toups (55:34)

And I will say there are again, there are paradigms. Like airline, their whole the whole point is that you should crash. Like they're much more aggressive about crashing. And you know, the it again, it was made to be sort of in mobile, I'm sorry, in the telemetry space where you're on highly constrained resources. You really need to have certainty around how things function. I think it's so important for us to understand the paradigms and assumptions and trade-offs.

I have a huge appreciation for the Erling community. I've I've never professionally programmed Erling, but I pay attention because I've seen a way that they problem solve that I think is is worthwhile. It's just it's interesting to say, if I was in this domain and I accept all these constraints and I'm using the tools that are available, it seems completely reasonable and you know, deep respect for the computer science sort of contributions that communities like that have made.

Carter (56:28)

Well

the all of chapter six is about concurrency. We could talk a lot about concurrency. I feel like we did a whole book on concurrency, right? We did Crocking Concurrency

Nathan Toups (56:37)

We didn't.

Carter (56:39)

by Kyro Bobrov. Great book. if you really want to understand concurrency, you gotta that that's all you gotta take care of. or I guess what you should read. I don't know, is is they they do use the analysis of like a pina colada robot, and they said like if you're on a

They talk about if you run a pina colada making competition, I'm like, don't tempt me with a good time. Right? Like, but it's you know yeah, virgin colour

Nathan Toups (57:04)

I'll have a version colada, please. Yeah.

Carter (57:07)

a virgin pina colada. I just like I I I like I like the f the flavoring. Yeah. Yeah, yeah. Yeah.

Nathan Toups (57:12)

I just thought of Jimmy Buffett. Anytime somebody talks about Pina Coladas. no, wait, that's not Jimmy Buffett. No,

I thought that was the if you like Pina Colada song is not Jimmy Buffett. It's gonna drive me nuts.

Carter (57:23)

No, no, who who sings that? Wait, who who is it?

Nathan Toups (57:25)

it's somebody it's it's not him. it's Rupert

Carter (57:29)

Rupert Holmes.

Nathan Toups (57:31)

Holmes. I confuse Rupert Holmes and Jimmy Buffett just cause it this reminds me of the old like, I'm gonna be, you know, a slightly sunburned man in the tropics, you know.

drink it on a boat. That's just that kind of music. So

Carter (57:43)

Yeah.

Nathan Toups (57:45)

Mar but he but also it's cause he has margaritaville and I'm like, okay well margaritas and pina coladas, you know, that's two different

Carter (57:50)

Yeah, yeah. You know, it is we we can accept this. D did Rupert Holmes do

anything else? Is or is he is he the definition of a a one hit wonder?

Nathan Toups (57:59)

You know, I have no idea. Any any diehard Rupert Holmes fans out there, let us know in the comments.

Carter (58:05)

He's a he's British? No, he's a British born American. yeah,

Nathan Toups (58:08)

Okay.

Carter (58:10)

he's he he won Tony's for writing musicals. he has two hit singles, Escape and Him. I don't know. I I don't maybe I'd recognize him if I heard it. It it is a very strange song.

Nathan Toups (58:15)

Well, I hadn't I had no idea. What so obviously Pina Colada, which is such a strange song because it's about two different

people wanting to cheat on each other, realizing that they both answered the the personal ad

Carter (58:28)

Yeah.

Nathan Toups (58:29)

and then realized we're perfect for each other. And you're like, Okay, well, I guess you are. So

Carter (58:32)

I yeah. I I I

I don't know how I'd feel if this happened to me. I I I recognize the romance

Nathan Toups (58:37)

No.

Carter (58:38)

in it, but at the same time yeah, it's it's like the Spider-Man meme of like pointing at each other, right? Like that that's what happens when they meet on the beach.

Nathan Toups (58:43)

Right. You're like I y yeah, you're

like this is terrible and I'm like, Yeah, well we both did it and you're like, Yeah and I guess we're perfect for each other

Carter (58:49)

Yeah. Duche.

well maybe maybe we can just wrap up then. as far as like hot takes, like yeah, I you know we

What I the there's been such a a step change in the industry over the past year. Although I'll say this about LLMs, which is we if you listen to the podcast, you remember we did this big code base migration, kind of through like February through June-ish. and something my manager said at the start of it when I we we talked about the the bet of of of kind of doing the migration. Well it's it's kind of two things. He says one, I think with LLMs.

We could get this done a lot faster than we ever have been able to in in history. And so I think it made the economics of it work. Like if we can get this done in three months, about I think it'll have been worth it. Whereas I think before it would have taken at least six, maybe longer, and and it probably wouldn't have been worth it in that case. He said, But there's a flip side to this, which is it's possible, he said this back in February, that six months from now, you could just feed this into the models, and the models could just one shot the migration.

Right. And and and we he was in we we were very much just in a like a we don't know. We don't know based on the rate of change we had seen from say November to February, if they kept getting as better, you know, as good as they did over those that four month period, then four months from from February, of course they'd be able to kind of one shot it. And I was on doing my one on one with him the other day and I said, you know what, we're six months past the mic, you know, from when you said that. And I just want to say, like, I I don't think that's true.

I don't think the models could do it. I don't think they could do the migration and one-shot it. Like, I just don't think they could. And he and he agreed with me. And he said, you know what? There hasn't been a step change like kind of when Claude Cote got really actually good. and I I theorized about that back then. I was like, I don't think it's that the models got that much better. I think it's that the the harness was invented and you can only invent the harness once. And you can iterate and improve on the harness, but like.

At a certain point, we figured out how to get the supply the agent with tools and get it to kind of call the tools and talk to itself in a loop. And that's a big advancement, but you can't invent that again. And so, do I think there's been a big step change in in LLM capabilities over the past six months? No, I I haven't actually. And in fact, I think some ways the models are getting worse or at least harder to use. And I think they they hyped up Fable as mythos and said, my gosh, it's gonna change everything. And then they released it and like

I don't really use Fable. I I use Fable every now and again when I have a very kind of like d do you use Fable

Nathan Toups (1:01:33)

Really? I'm

Carter (1:01:34)

a lot?

Nathan Toups (1:01:35)

I'm constantly running out of Fable tokens. So and maybe I'm

Carter (1:01:38)

okay, interesting.

Nathan Toups (1:01:39)

just maybe I'm just to being too

Carter (1:01:42)

Yeah, issue.

Nathan Toups (1:01:43)

too crazy, but I'll yeah. I I'm I've been a fan of Fable, but

Carter (1:01:48)

I like Fable. I like Fable a lot when it's like sometimes I had this like the other day. I was like, okay, we need to translate this modal on web into like our kind of bottom sheet on mobile. And here all the logic for what the modal should do is already written on web and what back end endpoints you should call, and our house style for what a bottom sheet should look like. Here's a component that has a really good implementation of it. And so I handed that to Fable and said, like, just just translate it for me.

Right. And for kind of those fuzzier tasks like that, I really I I liked what it came up with, but I don't know. we we we should talk more a different episode

Nathan Toups (1:02:27)

Yeah.

Carter (1:02:27)

about where we're using Fablon. Anyhow, all of that to say that like I don't think that the models are just getting so much better that we're all gonna be out of a job. But you do read this and it's just kind of like, man, like the bygone days of programming and

Not

that I n necessarily want to go back, but like, you know, reading this book, it's like there things were simpler before LLMs and it's it's a little like watching home videos of like back in the 90s or whatever, before smartphones in every pocket. And it's like, I love my smartphone. I think it it brings a lot of value to my life. But at the same time, you can look back at the old days and be like, you know, it's a little simpler back then. And I guess I reading this book has made me yearn for a bygone era.

Nathan Toups (1:03:15)

Yeah, it's I think it's really important more than ever to try to figure out how to get detangled and to not lose your attention. I think, you know, if I'm not careful, and again, maybe it's because I have undiagnosed ADHD, is I will easily multitask and distract myself into oblivion if I'm not intentional

Carter (1:03:36)

Right.

Nathan Toups (1:03:37)

about it. and it's

It's it's it's been interesting. I again I I do like this book in the sense that like I'm trying to think of hot takes. I do have hot takes. One is I feel this is like this is like snacking ideas at the buffet table, right? We don't

Carter (1:03:56)

Very.

Nathan Toups (1:03:56)

there's no real a through line in this book is it kind of introduces a lot of ideas, and I think that actually could be dangerous if you just stop there. Like, for instance, the concurrency chapter is good, it introduces especially ideas like the actor model.

Some other things that maybe aren't going to be in the Grockin concurrency book as much because that's most like high throughput data concurrency stuff. The actor model is a cool one and it can be actually be really nice, but there's no depth to it in that you come out of it the other side being like, I think I understand what the actor model is in general, and here I could go and use it. It's really sort of like, hey, I should go learn about the actor model. And so if you think of this book as a catalyst.

to deeper ideas that kind of inspire you to say, Hey, I need to learn this. I think it's good. I think you can have the illusion of you know, the endless beginner if you just read the pragmatic programming book and stop there, right? Like you'll know just enough to sound smart, but not enough to actually like be effective, I guess.

Carter (1:04:58)

Right.

Well, as far as what we're gonna do differently in our careers, this isn't a direct result of the book, but just like I feel the need to slow down a bit. And it's tough because like I also feel the need from a business perspective to deliver and ship. And I and I I don't even mean that from like a no one is imposing that on me. Like I I don't work at a place where like management is like, come on, ship, ship, ship, ship, ship. Like I I I'm the most productive out of my coworkers.

In part just 'cause I really like what I do and I think I put in more hours. and again, not because anyone's asking, just 'cause I I find it fun, right? but there are times where I kind of look at a piece of code or a unit of work that I ship and just like, what it would it have killed you to take an extra 30 minutes and to really make this good and not just functional. And I think r tallying up my work over maybe the past week, I'm like, there's a little too much there. There's a little too much that I wish I'd just I I know this is gonna need to be fixed later. And so

I should be a little more pro social. I should fix it now. so you know, that's I'm gonna try to slow down just a bit.

Nathan Toups (1:06:03)

Yeah, no, that's a that's always a good one. especially if you use the Cal Newport sort of focus of like what is the most effective use of my time and being really sort of, you know, there's always more things to do in a day than you can get done if you're properly cueing things up as a software engineer. And so ruthless prioritization and slowing down so you can focus on the stuff that if you don't contribute to really will affect the business, is it's it's hard, right? It's hard to do.

Carter (1:06:29)

Yeah. Right.

Nathan Toups (1:06:32)

We didn't talk about it, unfortunately. we kind of s skimmed past it. There's a section in the book about property-based testing. I've become a big fan of this, and so I want to be doing more of it. The the idea is that, again, the idea of property-based testing is that after I do a bunch of stuff, I go and like spot check di is the shopping cart is the values inside of the shopping cart what they're supposed to be, right? Like you kind of like t check the properties of the system themselves, kind of poke at them and see see if they're the way that you want them to.

And it's kind of a ki a type of black box testing that I think is really kind of fun, especially if you want to make sure that you're not changing like emergent behaviors of a system. So that's an area that I I'm gonna spend some more time in.

Carter (1:07:10)

There go. Okay, as far as recommendations, I mean I would recommend this just kind of basically anyone, her general audience. Again, it's it's a bunch of blog posts wearing a you know, styled as a book, but all of them are good. So I'd recommend anyone

Nathan Toups (1:07:21)

Yep.

Again, snacking at the buffet, you're gonna get introduced to a lot of great ideas. you should not stop here. You should get go in deeper. And luckily we have a lot of other content that you you would learn into. you know, philosophy of software design, fundamental software architecture, all of these are gonna be natural second steps. But if you want to get an introduction to a lot of great ideas and, you know, point you in a really smart direction, I think this is a this is a great book for everybody.

Carter (1:07:48)

There we go. Okay. well, you can always find us on bookoverflow.io, on Twitter at BookOverflow Pod. I'm on Twitter at Carter Morgan, and Nathan has worked with consulting agency Rohroboto at Rohoroboto.com. All right, we'll see you later, folks.

Nathan Toups (1:08:01)

See ya.