I've noticed that once you start getting the curse of knowledge, once you start communicating in abstract, jargon-heavy ways, you can even if you were an effective communicator in other other aspects of your life, you can get so used to talking to a particular audience that you realize like I'm I'm literally speaking another language,

Carter (00:25)

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

Nathan Toups (00:37)

Doing great. Hey everybody.

Carter (00:38)

Well, make sure to like, comment, subscribe, join the Discord. you can check out our new schedule lineup that is now live at bookoverflow.io. this this week we're doing the first of our kind of next how many how many books have we planned out? Six?

Nathan Toups (00:53)

sounds right

Carter (00:54)

Hash.

Nathan Toups (00:54)

yeah it's something like that it's it's pretty close if it's not exactly I'm I'm actually curious I'm gonna go I'm gonna go look it up yeah one two three four five yeah and some of them are a doozy like I think I think there might be two different books that are five parters so

Carter (01:15)

Great.

Nathan Toups (01:15)

this it this brings us into 2027

and I'm not assuming any breaks, which we will, I'm sure have those. We have special episodes that'll be coming up. so we'll see. This may be an aspirational list, but there's some important ones in here and it's largely from our public backlog and voting system. So this is all these

Carter (01:35)

There we go.

Nathan Toups (01:35)

are community involved books.

Carter (01:38)

Speaking of special episodes, we're coming up now. I I think this right now is like our ninety-fifth non-interview episode. And so I think we're we're getting an exciting I think we'll we might have to do something for the hundredth pure book overflow content episode. I don't know. we'll figure it out.

Nathan Toups (01:58)

It's also

I think this is our one hundred and twenty-seventh full length episode, which if we are starting with zero, that would be, you

Carter (02:07)

Yeah.

Nathan Toups (02:08)

know, two to the seventh. But I think next episode will be our hundred and twenty eighth episode, right? Which is, you know, if for those binary fans out there, we're about to get to a the next significant digit.

Carter (02:20)

We we can always just do what the Simpsons did when they had to air a clip show in the middle of it's just season seven, episode ten, but they just called it the Simpsons one hundred and thirty eighth episode spectacular. We should just pick a random number and and declare that our spectacular. Yeah.

Nathan Toups (02:30)

that's good. We should. That's a it's a that's about our style, so I also

want to give a shout out. I think you know, I like y it's nice to see milestones. We just hit fifteen thousand subscribers on YouTube. So yeah.

Carter (02:43)

On YouTube. That's

fantastic. Well, thanks everyone. That's that's why we keep making the podcast. And as long as people keep subscribing, we'll keep making this thing. until Nathan and I's inevitable, very dramatic falling out. yeah. Yeah,

Nathan Toups (02:55)

Yeah, it's gonna be public and messy.

Carter (02:57)

but you for all the people who who listen to this podcast for the regular drama we give you. no, you let you listen to this podcast for for our quality book insights. And you know what? I'm actually really excited about this book. This is the Pragmatic Programmer, your journey to mastery.

we're I believe we're reading the 20th anniversary edition. That's what I'm reading.

Is that what you're reading? Okay, great.

Nathan Toups (03:17)

We we are. It's the twentieth anniversary edition.

Carter (03:21)

originally written in 1999, second edition in 2019. this is one of those books that I I feel like in the software engineering book canon kind of floats out there. Sometimes I'll tell like, I'm reading Mastering Open Telemetry. Like, I didn't know that was a book, but I feel like the pragmatic programmer is one that is a little more.

known amongst people who know software books, would you agree?

Nathan Toups (03:46)

Yeah, and if you ever see like social media posts from the sort of the bigger blogs that will say, Hey, these ten books that every software engineer should read, this one is almost always in that list. and I I think that's why it was in the backlog, because it was one that I knew that we should read. You know, and there's like there's a subset of books that you're like, I I should read this book and we're finally getting to it.

Carter (04:07)

Yeah, I there was a Reddit post like a a few like a week or two ago of someone being like my top 10 software engineering books. And shout out to whoever one of our listeners in the comments for that was like, if you like books, like you should listen to Book Overflow. They've done at least one episode and sometimes as many as four on every one of these books in this list. I'm like, that's pretty cool. Cool to see our fans repping us in the wild. but at any rate, yeah, pragmatic programming. This by David Thomas and Andy Hunt.

Dave Thomas is a computer programmer, author, and editor. He has written about Ruby and together with Andy Hunt, he co authored the Pragmatic Programmer and runs the Pragmatic Bookshelf Publishing Company. Thomas moved to the United States from England in 1994 and lives in north or lives north of Dallas, Texas. Thomas coined the phrase code kata and dry, don't repeat yourself, and was an original signatory and author of 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, Award-winning Practices of an Agile Developer, a Half Dozen other Books, and many articles. Andy is 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. So this is adding to our growing list of reading books by

some of the original signatories of the the Agile Manifesto.

Nathan Toups (05:36)

I I we gotta it's like Pokemon, we gotta catch them all. And also to

Carter (05:39)

I know, right?

Nathan Toups (05:41)

to any eighties or nineties kid, Dave Thomas is not the same Dave Thomas who owned the Wendy's franchise.

Carter (05:46)

I was gonna say,

yeah, yeah. It's like you ever see office space?

Nathan Toups (05:51)

Yes.

Carter (05:51)

Yeah, yeah, it's like Michael Bolton. It's like, why don't you just change your name?

Nathan Toups (05:53)

Right, Michael Bolton.

Carter (05:54)

He's like, why should I? He's he's the one that sucks. If we have Dave Thomas on, maybe we'll ask him that question.

Nathan Toups (05:57)

Right. That's great. man, that

move that movie is actually it's it's amazing. It still holds up.

Carter (06:04)

I love that movie. I love I don't remember the main actor's name in it, but he's also in Band of Brothers. He plays like Captain Nixon in Band of Brothers, but I like him.

Nathan Toups (06:12)

Yeah, he's a very talented actor, which again I'm

I'm terrible about names, so

Carter (06:18)

that's we're just gonna review. Is there a novelization of Office Space? We'll review that one day.

Nathan Toups (06:23)

There we go. There we go.

Carter (06:26)

Let us know if you would like us to review Office Space the movie, and and maybe we will.

Nathan Toups (06:29)

Right. And maybe maybe

we could review a read our favorite TPS report that

Carter (06:37)

Yeah, why what is it you'd say you do here? Okay, well we got the pragmatic program. This 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, so you'll come away with fresh insights each and every time. It's a short book introduction. but I when reading this, I I kind of got the I I I see why this is a seminal book. I've been enjoying this. What how have you been feeling that, Nathan?

Nathan Toups (07:01)

Yeah, this reminds me of like Will Larson's version of snacking for books. Like at least the first couple chapters. Each section

Carter (07:06)

Yeah.

Nathan Toups (07:09)

is a little it's like little truisms, little nuggets of wisdom. So far we haven't gotten into great depth. but I definitely it's it's it's been a good sort of like buffet style practical advice that I'd be happy to pass along. there's are some opinions that I'm like, okay, yeah, you know.

But most of the stuff in there, I'm I'm like, okay, this is actually if somebody's never seen this way of thinking, it's structured really well and it's very easy to read.

Carter (07:39)

Yeah, I I don't mind the book being a bunch of blog posts. I am regrettably a Twitter addict. And so, you know, anything that reads like a series of tweets is, you know, fine for me. It doesn't read like a series of tweets, but it is broken. So we we did chapters one and two, which is about the first third of this book. And each chapter is broken into a topic. And each topic is probably, I don't know, five pages-ish. and so you know, I

I I really don't mind that format. I

Nathan Toups (08:11)

Mm mm, no, no, no.

Carter (08:13)

and I think all of the advice here is really, really good. yeah, I there are some parts you get to where you're just like, you know, maybe maybe that's just your opinion, or I I don't know about that. But at least the the whole first chapter is called A Pragmatic Philosophy. And when I was reading that, like I went into the office the next day and and told like our junior engineers, like, I've got a new book.

This is kind of rocketed to the top of my recommendation list. The the best bang for your book, Buck book I have always recommended is Fundamentals of Software Architecture, which was our number one book. Philosophy of Software Design is really good too. This is right up there with those right now. We'll see how it holds up through the rest of the remaining chapters.

Nathan Toups (08:59)

Right.

Carter (09:00)

but I I'm enjoying this. I think it's a good book.

Nathan Toups (09:02)

Yeah.

And and I will say this isn't a class i some people will be attracted to this and some people won't.

You know, there's a category of book that are kind of from the consulting class of software engineers, right? This would be folks that are in and around ThoughtWorks.

Carter (09:14)

Right.

Nathan Toups (09:15)

These are the folks that are in and around the Agile Manifesto. I like I like hearing those voices and opinions, but they're very oriented around being a professional, doing what you say you're gonna do, you know, how to think about breaking big problems into smaller problems, which again, you need to be able to do, but you also think about

And then they have services that they're selling on top of this, right? They're they're bringing structure to an unstructured world. They're trying to modernize the enterprise. they maybe are bringing in new patterns. And I always like to see where the motivations are coming from. And again, I like I like this book. but you're not gonna get into like DDIA type topics, at least not so far. May maybe again, maybe we get into more details further in the book. I haven't actually looked ahead, I normally do, but maybe they're just laying a foundation of

their approach to doing stuff, which again, I I think is excellent advice.

Carter (10:11)

Yeah. so we can just start with chapter one. This is a pragmatic philosophy, which is just kind of their overall take on software engineering. I I like this because this gets back. I think one of the reasons I really jive with this book is because it kind of gets to like our fundamental thesis with the podcast, which is that you can be better at your job. And you can be better

Nathan Toups (10:33)

Yeah.

Carter (10:34)

at your job by putting a by

By putting effort into it and kind of the the whole forward of this is really interesting. I forget who wrote it, but they basically say, like, hey, have you ever met like a programmer? And I'm gonna use the term programmer. I typically prefer the term software engineer, but like, but have you met a programmer who's just like really, really good at their job? and they says like Dave Thomas and Andy Hunt, those are those programmers. And one of the reasons they're so good at their job is because they are very

Actively involved in how they think about their job and how they process. And the the word they use obviously is pragmatic, which is a philosophy I have always found very interesting. Like maybe it's just a cover for narcissism, but like I've always been very like interested in kind of observing how I behave, how I react to things, how I go about doing things. I'm always like very interested in like maximizing like small efficiencies in in kind of my personal life. And so

This idea that you can become better at your job by being very deliberate in how you approach it, is really, really interesting to me. And I I also find it really interesting because, you know, I I've been open on the podcast about this, but for the first couple of years of my career, like I wasn't a great software engineer. It was only I kind of have a moment where I'm like, okay, I gotta lock in. and then

Nathan Toups (12:02)

Right.

Carter (12:02)

that kind of combined with us doing book overflow.

has really read me to appreciate the craft of what we do and to have gotten, I think, much better at it. And so another one of these books from like I w I wish I had learned about this earlier in my career, but I also probably wouldn't have appreciated it. but yeah, I mean, what what do you think about their philosophy, Nathan, of like

observation?

Nathan Toups (12:23)

Yeah, so again, I I love

that I love this part. Pragmatic is it is an sort of an overloaded term, but I love it in the sense that it it it leans into this idea that there's an art and a science to what we're doing. And that, you know, I actually love how it starts out the topic one is it's your life. And it's basically saying like, hey, are you not if you're not happy with where you are, like you have a lot more control than you realize, right?

if your job if you want to work remote and your job's not open to it, you can go find another job, right? Like you can go

Carter (12:59)

Right.

Nathan Toups (12:59)

find and I will say this is at a time in which we're getting into this world where 2019 doesn't feel that long ago, but it also feels like a lifetime ago at the same time, where, you know, this is before all the LLM stuff, this is before COVID happened, this is before like all of this crazy amount of change in art industry specifically, where

You really did have all the bargaining chips, right? You in

Carter (13:25)

Right, right.

Nathan Toups (13:26)

twenty nineteen, money was still cheap. you you know, maybe we weren't exactly what it was like in twenty twelve where you literally could have any idea and get it funded. But engineers it were were one of the f few fields in which you can literally say no for a living or really kind of get things down to what can and can't be possible. And you get just a ton of bargaining chips.

We've I think we've all been knocked off a little bit off balance, but this still rings true. Like your company's mandating using AI, you don't have to use it that way. If you try to voice your opinion and you say, Hey, I think harness engineering is better this way, or hey, the code quality's gone down and no one listens to you, you can either try to double down and make a change in your organization or change your organization. I think that was the there's a qu there was a Martin Fowler quote.

that was in there about that. It was like change your organization or change your organization. Like basically like,

Carter (14:23)

Yeah, yeah, yeah.

Nathan Toups (14:24)

you know, like you can change things internally or you can go go somewhere else. And if you feel trapped or if you've made this like f I I I see this a lot. People give this like false duality. I either have to do this or I have to do that. And then they kind of take a fatalistic sort of Eeyore approach and go, Well, I can't do the first thing, so I guess I have to do the second thing. And that's just not true. Like most cases there are a

so many other options in between one extreme or the other. And I think this is where this sort of pragmatic philosophy sort of like falls in here. It's like, hey, take a step back. You know, think about the impact you're having in this organization. Can you have a different impact? Can you change your approach to what's going on here? And yeah, I don't know. It's w were there was there a topic in this first section that really stuck out to you?

Carter (15:14)

I just still kind of hung on this idea. Like, I I have two thoughts. One is that we when we read So Good They Can't Ignore You last week,

Kelly Newport

Nathan Toups (15:24)

Yeah.

Carter (15:24)

talks about this idea that, like, hey, if you you need deliberate practice, be good. And most like white-collar knowledge work, no one practices it. And so if you can figure out a way to practice it, you will pretty quickly rock it to the top of your field, like in a in a shocking way. which I have seen very

Easily in my career with Book Overflow, like just by reading all of these books, like it's kind of surprised me just how much like better informed I've become than my peers and how that's paid off in actually building things. I

Nathan Toups (15:58)

Yeah.

Carter (15:58)

obviously can't compare myself against every engineer in the field, but I think there's a lot to be said for kind of deliberate practice. And this book is all about how you can kind of deliberately practice. the other is just kind of

Yeah, like that learned helplessness you're talking about. I I can't remember. I think it was like some VC guy on Twitter who he had this interesting take where he said, like a lot of like high agency people in their lives have this moment where they lean against a wall, so to speak, and find that it's actually a door. And it kind of surprises them. And from then on, they start kind of pushing instinctively against walls to see which ones are actually doors.

and I've kind of found that in my life, like it's like, wow, like it's kind of surprising what you can get by just asking or just kind of taking a little bit of initiative here or there. And so, yeah, I I really jive with this whole philosophy. I think pragmatic is a really good way of of thinking about it. I think I mean, I I love just topic two, they call the cat ate my source code, which is this whole idea of like responsibility.

Right. Like again, that that

Nathan Toups (17:07)

Yep.

Carter (17:08)

kind of helplessness of like it is the opposite of helplessness. The opposite is opposite of just being like, I've just been given what I've been given. You talk about this idea of like kind of being like, you know, a boy scout when it comes to code. Like leave it better than you found it. Right. There's no excuse. There's no excuse when you kind of touch a a part of the system to to not clean it up. there's no excuse for like, it's just too hard to operate in this part of the code base. Like, well, make it better, make it easier. I had

I I need to be better about this because obviously like with code generation, we're just generating so much code and there's, you know, at at review time, I I've had moments where I've been like, it's close enough. And I'm like, and that's the thing with code generation. Like it's not that hard to to actually significantly I mean John Osterho talks about this with like the whole design it twice philosophy. One of the really cool things about LLMs is how easy design it twice is now. Like they'll come out with an implementation, I'll review it and like, well, you know.

Seeing that implementation, I actually don't think I'd do it this way. I think I'd actually do it this way. And then it's a prompt or two away. and and I was just thinking about some changes I had approved this week. And I'm just like, I think I think that was sloppy. I think I should have taken more responsibility over that part of the code base.

Nathan Toups (18:23)

Yeah,

it's it's interesting. I've recently was working on a project where me and another engineer were sitting down and whiteboarding, purposefully not using LLMs, because

Carter (18:34)

nice.

Nathan Toups (18:35)

there was another part of the project that seemed it we were we were just getting really tangled up.

And it really just came down to questioning assumptions, thinking clearly. And it was honestly refreshing. And it was this powerlessness thing. There's like, the system's so complex. It would be ridiculous for me to try to model this from the ground up. And then we went through the process and it made me appreciate the existing code base and this other implementation that we've been thinking about. And we may or may not use that full implementation, but it gave us a clear clarity of thought of how the system could flow in a simplified form.

So that when we go back into this complex thing and figure out, okay, well, is this complex vibe-coded part of the system serving us well, or could we model something off of this? It it really got to the the the the the ownership idea, right? Thinking through an idea isn't gonna go out of fashion. And we've talked about this. I think this is like one of the sort of critical pieces here is you know, if anything.

the cat ate my source code is the you could say the LLM ate my source code and very easily

Carter (19:40)

Yeah, right, right.

Nathan Toups (19:41)

apply it to this thing where you're like, well, you know, we can't ship code without LLMs doing everything since we've been doing it so much here. And I I think you can actually do it some back and forth, right? because the LLMs this this is an interesting thing to think about here. The LLMs will dutifully do what you ask within the framing that you've given it.

And sometimes there's forms of thinking in which the framing itself is wrong, right? I assumed the wall is solid. It's actually a door. Well, the LLM will be like, that's a beautiful wall. This is just a characteristic of walls.

Carter (20:14)

Right, right.

Nathan Toups (20:16)

Some walls look like doors, but they're not really. And you're like, then you're like, wait, you know, you have this whole document internally. It's like door like walls, right? Like, and you and then you're like not thinking about the world as it really is. And you're like, wait second, it's a door. I can just use the door. And and

Carter (20:31)

Yeah.

Nathan Toups (20:32)

so yeah, like I

There there's something here where getting back to these axioms or getting back to these core principles are very grounding. And it's also I think this is also really good advice for folks joining a new team. Do not assume because you're the new person, everyone else has figured out the system, right?

Carter (20:50)

Yes.

Nathan Toups (20:53)

Ask those dumb questions and they're probably not dumb. There's actually probably more parts of the system that haven't been well thought through than you realize, right? And you have a real opportunity to come in with a fresh set of eyes and go, hey, we've all gotten really comfortable with this, but no one really understands it. Or we've gotten really comfortable

Carter (21:09)

Yeah. Yeah.

Nathan Toups (21:09)

with this and man, we're doing like 15 things that we shouldn't be doing right now, right? and you will miss that if you don't

Carter (21:16)

What

Nathan Toups (21:16)

if you don't chime up.

Carter (21:18)

and I just want to register. What is this? This is the year twenty twenty six. This is we are recording this August 20th. So you you can rec you can s clip this if it's wrong. But I think kind of in January and February of this year, there was a lot of fear in the industry of kind of like, man, these coding agents are coding really good. What's happening to our jobs? I'm just saying right here, right now, I don't think our jobs are going anywhere. I think the coding agents are remarkably good, right? I I use them extensively. I think

On an implementation by implementation basis, they are much better than I am. just from like kind of a pure syntax perspective. And just the more and more I work with them on kind of new feature development, the more I'm like, man, like these things need a lot of steering. And like, you know, just the other day, I think it's really interesting because I I I talked about this on the podcast, but my my workflow is that I have basically like five copies of our mono repo all in different work trees.

And and that's kind of how I'll bounce around between features between them. And it was really funny the other day. I was doing some work on one work tree and kind of like sequential, like, okay, here's your prompt, execute. Okay, now do this part, now do this part. And I accidentally gave the prompt to the wrong work tree, which did not have like any of the pre-work done. So this prompt should have made no sense. And the LLM dutifully executed on it and just like created this total like.

Crap that wasn't related to anything. I was like, geez, like that's kind of insane. That it like any human would have like, what are you talking about? What do you mean you want me to build this part of the system? This part of the system doesn't exist yet. and so, yeah, like I think our jobs are gonna be here for a long, long time to come. I agree with what we read, you know, with Uncle Bob that like maybe one day we will summon the code with our minds, but at the end of the day, someone's gotta care about the code. which kind of gets into this idea.

Nathan Toups (23:08)

Summ summon the code

in our minds with Lisp, okay? Or or you know, we're gonna have a scheme.

Carter (23:11)

Yeah, with with Lisp. It's common.

but that gets to this kind of concept of software entropy, which is yeah, like this I think is even more important in

Nathan Toups (23:25)

Yeah.

Carter (23:26)

with LLMs these days. they they talk about this kind of this broken windows idea from Urban Decay, which is that like, you know, studies have shown that like if there's a broken window, that will kind of accelerate the decay in an area if it's not fixed, because it kind of teaches the people around it like.

Hey, no one cares about this, right? and it's the same way with your software, right? If if you let a bad pattern creep in, that'll signal to other people like no one cares about this. It's not, it's not well built. And so if you want to add more crummy code here, who cares? Because all the code is crummy. And holy cow, that is so much truer with LLMs. It's crazy. Like LLMs will kind of dutifully mimic your house style. And if there is no house style,

Holy cow, they will just spaghettify and slopify your code base like crazy. I have become so passionate about just like having clear patterns and making it so that it is harder to write bad code than to write good code. but man, like I mean, this was written in 1999, refreshed in 2019, all pre-coding agents. And this idea of entropy has only, I think, become more relevant in our workflows today.

Nathan Toups (24:37)

Yeah.

another Claude Shannon reference, but entropy was translated into the computer science world because of him. Actually, with

Carter (24:46)

Ooh.

Nathan Toups (24:47)

with a von Neumann was the one who recommended that he used the term entropy cause I think partially because he said no one understands what the word means and so you should use it.

Carter (24:56)

Ha ha.

Nathan Toups (24:57)

in the Shannon information theory standpoint, or what they call Shannon entropy, you can think of it as like how e how easy is it to predict the

The next byte or the next bit that's coming up. So if you have all zeros, for instance, that would be a low entropy. If you have a pseudo-random number generator generating ones and zeros, it's high entropy, right? And so the

Carter (25:21)

Mm-hmm.

Nathan Toups (25:21)

idea is that randomness is correlated with entropy, right? The more random, the less guessable the next token is or the next bit is, the higher the entropy. and then the lower, yeah, lower entropy just means that hey, it's pretty predictable.

And so yeah, I I think that you know, as chaos seeps in, it it becomes harder and harder to manage the system, right? And yeah, it's it takes effort. So if we get back to physics, again, entropy topic's really fun. I'll ask you this question. This was a veritassium episode. What is what does the what does the sun what's the sun's primary contribution to the earth?

Carter (26:04)

Keeping us warm.

Nathan Toups (26:05)

Yeah, so it it does it feels like the it the the heat it introduces is the thing, but if that was true, the earth would continue to warm up, right? And we would all die

Carter (26:15)

That's fair.

Nathan Toups (26:15)

because it gives us a ton. And so Veritassium actually argues, and I think Roger Penrose made this argument as well, it's actually that it gives us low entropy, meaning it's a very predictable set of energy that comes to the earth, and it's the low entropy

Carter (26:30)

interesting.

Nathan Toups (26:31)

life on earth is low entropy.

We organize ourselves in high entropy is that once we die and all the at the atoms are distributed back, our physical bodies, there's a high entropy. And so what happens actually each night is that the energy gets disp kicked off of the earth in the dark as high entropy, energy just scattered everywhere. And so we take low entropy and turn it into high entropy, and that that's actually pretty balanced. Like it otherwise the earth would heat up every day cumulatively. And so the point of this is saying that.

You have to introduce low entropy energy to the system or it goes to chaos, right? we have to continue to introduce effort, reason, thought, otherwise things decay, right? If even BitRot is a good example, right? The the system will go to chaos even if you don't touch it because package managers update, so operating systems update, right? the web standards change, what browsers expect to change, right? Those things all you have to continue to introduce energy into the system to make sure that it's

Ordered and structured.

Carter (27:34)

Well, I mean it's so do you think we need to continue to introduce energy into software systems?

Nathan Toups (27:40)

Yes, I mean that yes, exactly. So like the the care and maintenance, it's kind of like, you know, you notice that over time you have to replace your roof, right? you know, a twenty-year-old roof just gets old. It's not like you did anything particular to it. It's just, you know, okay, well, I have to mend the shingles, I have to paint the walls, I have to do these things, are just part of the upkeep. Obviously you want to build new systems and do new and innovative stuff, but the the the care and upkeep is important, otherwise

Yeah, I think what'll happen is again, just like in the broken windows neighborhood piece, whatever goes. Whatever sloppiness is there, hey, you know, all the windows are broken anyway. Like it doesn't matter our window broke. Like we'll just we'll just deal with it. We'll put duct tape over it. You know, that's fine. As long as the airs air conditioner's not leaking out or something. which is unfortunate, right? 'Cause it's like, it's also like pleasing to have a nice window. You can use the window to see what's going on outside. Those of the things. So so the next section

Carter (28:34)

You can use the window to look at

your duct tape. Yeah.

Nathan Toups (28:36)

Yeah, exactly. No, maybe you're really into duct tape and then that's the whole other thing.

stone soup, this is the next section. Stone soup and the boiled frog. I this one I have kind of like a double edged thing with I I definitely have used the stone soup methodology before, but I also always feel kind of dirty and manipulative for doing it. Yeah.

Carter (28:58)

Yeah, explain so soup to our audience.

Nathan Toups (29:00)

So the idea of stone soup is that these and I'll probably I'll paraphrase it a bit.

These

hungry soldiers are visiting this village and they they're sort of like asking for for some food and no one is willing to give it to them. This it's in wartime. and one of the guys comes up with an idea and he goes to the middle of the town, he puts a stone and in the in in a big bucket a pot of water, and he's like, We're making stone soup, and you can, you know, have a meal from this delicious stone soup, and the town is amazed. Like, how can you make soup?

With just a stone in water. and then he goes, yeah, yeah, well, it's coming along great. if we only had some carrots, you know, it it makes the stone soup so much nicer, right? And somebody finds some carrots. The same people that didn't introduce any, had said they didn't have any food earlier. this will be interesting, and then go get the carrots. it'd be so nice if it had potatoes, right? And they they go through and all of a sudden they've built a a delicious, you know, beef and vegetable soup. At the end of it,

And the people are like, this is the most delicious stone soup I've ever had, you know, in my life. And of course the soldiers, you know, they're being sort of wily like a fox, right? They've kind of tricked people into doing something in their favor. They of course the community got to share a meal. all of them probably were hoarding little bits and pieces that aren't that useful by themselves and by making culmination of all these things together, they all got to have a like a hearty and healthy meal. I think that's kind of the point, is like, hey, sometimes you have to coax people.

To do something for their own good, right?

Carter (30:33)

Right, right.

Nathan Toups (30:35)

but I also think that the road to hell is paved with good intentions. I think that sometimes you can think that you're doing something in everyone's favor, but really it's self-serving, and really you're manipulating people, and really they wouldn't have done it if you had been honest with them in the first place, right? that's the sort of like dark side of Stone Soup.

Carter (30:56)

I get that I get that big organizations are just comprised of lots of people and that this is part of being a software engineer and especially I I was talking with one of our junior engineers about because it, you know, it's his first job out of college and you know, it's a startup and you know, there's not there's forty people in the whole company and and he was just talking about all the great experience he gets working at our our current company, which I agree. I think at the technical knowledge he's been able to kind of

understand and build on in this year at a startup is is much broader than you would get at a big company. And just kind of talking about, well, why even work at a big company? I said, like, well, especially as you get more senior in your career, the act of guiding large amounts of people and coordinating effort across teams, like that's a skill in and of itself. And it's just a skill that we don't even have the opportunity to practice here.

and so I I recognize the importance of that skill. And and sown soup is very much a technique for doing that. But man, I kind of hate the the the the idea here. Like I hate this idea that like you have an idea, you know it's a good idea, you know everyone will be better off if you do it. and you have to like kind of coax and trick and guide people to accepting.

your idea. Like I get it. And I also know that not every idea I have is a good idea. And so the stone soup approach is kind of a good way of kind of like pressing and and figuring out if, you know, how how strong the resistance to your idea might be. But it's fun to work at a place where just everyone's kind of aligned on everyone. But it's also hard. It's tough at a start because I can kind of right now be like, hey, everyone's aligned. Like this is a good idea. but part of it is just because like at a start you have a lot of low hanging fruit.

as far as like what constitutes good ideas and so I don't know. I guess I'm I'm happy where I'm at in my career right now. I recognize the importance of this in larger organizations. It's also frustrating to be at larger organizations and feel like you have to play these sorts of games, you know?

Nathan Toups (33:06)

Right. Yeah, it again

I've seen this used effectively. And I think that if depending on I still think that this is dishonest, right? meaning if someone found out that the origin of the stone soup was actually a way, a manipulation tactic to get you to make a beef stew, that would undermine your credibility, right? Now the soldiers in this case are passing through. It doesn't really matter. If somebody wakes up the next day and goes, wait a second.

Stone soup's not a thing. He just got us all to like put things in it, right? They still got what they wanted and they moved on. But it's very transactional. If you actually have to decide that you're going to live in the town moving forward, you then have to double down on, no, there really is something magical about stone soup and really become like the stone soup guy. Like, hey, stone soup stew is better than regular stew. or you have to be you real you just own up and be like, Yeah, I was really hungry and I won't do that again, right?

Are there other ways to kind of rally up the troops and get people to do something that you do think is in their advantage? And I bring this up because I think I've talked about this in the past where I was leading a developer experience initiative at a Serious C funded startup. There was no like earnest way of measuring developer productivity or understanding what made engineers happy or unhappy. And it required sponsorship from the top and it required buy-in from the bottom, right? You actually have to be able to measure things and people feel safe.

or fill out surveys and think that your manager will actually do something with it and not just use it as a way to punish you, right? So there's a lot of like wrangling that I had to do. And I'll say like the stone soup aspect of this is that I decided I'm gonna go after one particular part of the organization that I knew that the higher ups thought were struggling. But I also pr said it like, hey, we should do this org-wide initiative so we can measure this group and figure out why they're performing differently than the rest, right?

And did I disclose that information to the struggling group? I didn't, right? That this kind of stone soupy in the sense that I was like, hey, I've noticed your managers aren't listening to you. You guys are struggling. You need a way to communicate. If we did the survey, I think I can get the higher ups to listen. And over here, I'm like, hey, this is an org-wide thing, right? I'm kind of like talking to different groups different ways, showing them how this is actually in everyone's best interest, right? It's stone soup-ish.

And I do think that if some groups were in some meetings and other groups were in other meetings, there would have been more resistance to doing those things. but we got what we wanted at the end of the day. It became a company wide initiative. we got to celebrate the teams that were most effective. We got to help the teams that were struggling, which again was the outcome that I was shooting for. And yeah, I I do think you have to get scrappy and creative sometimes. I guess that's my my point is that like I do agree, but just be really careful, right?

Carter (36:04)

Right,

right.

Nathan Toups (36:05)

Yeah.

Carter (36:06)

No, no one like this actually gets to this idea of topic seven, which is you gotta communicate. this idea that like great ideas are worthless unless you can communicate them. and lots of good stuff here, kind of about like like knowing your audience. I I thought it was great. They said like someone who like you're in front of the VP of marketing and you're just like kind of monologuing about like the the technical details of the system. They're like, You're not communicating, you're talking.

And that's annoying. I know I've certainly been in conversations like that where I'm like, I don't think this person actually wants to they they want to hear the sound of their own voice, right? And I actually I I do like we we have a company, like every three weeks we do a company demo day where we kind of demonstrate to the whole company what we've been working on. And I do take care during my demos. I always like to talk about kind of the the finer engineering details. Like we are, you know,

We have like this whole new notification system for kind of like I I I built like this notification registry for keeping track of which notifications we're sending out and how often on through which channels. And so I I some people like to focus a bit more on like, look, we have a notification page. I do like to kind of take some time to explain like here's a bit of the engineering that went into this, but I do always try to bring it back to like something I really I I'm really passionate about good engineering, but I'm only passionate about good engineering because.

Good engineering delivers value to the customer faster over the long run, right? either through, you know, increased performance, better latency, or just the ability to kind of change a system faster. but it but it's a balance because some people just love to, you know, get up and kind of just monologue about something completely unrelated that no one really cares about. so yeah, I I

Nathan Toups (38:00)

Yeah.

Carter (38:00)

I've

We we've talked about this a lot on the podcast, but I'm a big fan. I think the ability to communicate your ideas effectively as you become more senior in your career is what starts to set you apart from other engineers. Or at least it's a very visible thing that can set you apart if you're good at it and if you practice it.

Nathan Toups (38:17)

Yeah, and I it's it's interesting too because like my background, you know, I actually have an improvisation and theater background, like that grew up doing that kind of stuff, knowing nothing about computers. And I've noticed that once you start getting the curse of knowledge, once you start communicating in abstract, jargon-heavy ways, you can even if you were an effective communicator in other other aspects of your life, you can get so used to talking to a particular audience that you realize like I'm I'm literally speaking another language,

right?

The marketing team doesn't have any understanding of why this is actually applicable or valuable to them. Even if if I figured out a way of communicating in concrete terms, they might get super excited, right? It's something that might be dry about, you know, an asynchronous event notification system within our system. And I could talk about it in abstract terms and how beautiful and elegant and, you know, it does these things. But if I could put it into concrete terms of saying, hey, I can get you a real-time feed.

To our customer onboard and see what the churn is. Would you like that if there was a way for you to get like real time notifications to see if you could like help somebody through the funnel onboard to the rest of the system? Marketing persons, they're perked up, right? They're listening. They're like, Okay, wait,

Carter (39:29)

Right, right.

Nathan Toups (39:29)

you can do what? And I'm like, Yeah, yeah, we can feed this into your, you know, I saw that you have that dashboard once a month. Like, what if I get you that in real time? that would be amazing. Like, we would, you know, we've actually been trying to figure out ways to do this. And so

Understanding who your audience is, understanding like why is a system serving the business better. you know, what problems am I solving? What pain is there that could be applicable? I think the the communication side is is huge. And I guess my point is it's really important for us to ground who the audience is. I did I did this recently. I was doing a like a security audit discovery document. I I'll do this with new clients sometimes where

onboarding part of it's for me to understand what am I even getting myself involved with, right? So I do this like fixed cost sort of onboarding piece. The other part is I have to communicate it back at the end. What are my findings? What what are the risks? What are you doing well? celebrate the parts that are great. Show why maybe you're a little tangled up in something and what we can do to fix it. And many times I'm talking to the execs, right? So I can't really get into well if they're not engineering leadership or something. I have to make sure I I'm like

Hey, your engineers are going to move faster. you know, you had this security breach a few months back. This would categorically fix that, right? Like the where they have peace of mind where they can go to shareholders and talk about something in a meeting, that that their SOC two type two audit's gonna pass, right? You have to put this into terms of what they care about and not be like, the Okta single sign on handoff is exactly what you like they're not they're not gonna

care about that, right? so yeah.

Carter (41:01)

Yeah, right. I

we gotta give a quick shot at the topic six, your knowledge portfolio. This just talks about this idea that like should be building knowledge. and that that kind of knowledge is is valuable but can also go out of date. But one of the recommendations they write they give for build knowledge, read a new book every month. So I like to say we're doing pretty good on that front.

Nathan Toups (41:26)

Yeah,

no, it's I I'll also give a shot. We're we're working backwards just very slightly. In topic five in this first section, too, is called good enough software. And I think this

Carter (41:37)

yeah, yeah.

Nathan Toups (41:37)

is when we're again, especially once you start getting excited, you start reading all these books, you start caring about craftsmanship, you really also do need to think about what good enough is in that, you know, is this long lasting software that'll be used by millions of people for a long period of time? Well, maybe the bar.

for how much time and attention you spend is quite high. this would have this is what I would call like the John Osterhout side, right? You're building a replacement for TCP in the data center. That code should be pretty nice, right? You're building the Raft protocol or whatever, you know, kind of things. Or you're wiring up the CI pipeline for an experimental project that you don't know it'll exist in six weeks, right?

You should probably not spend six weeks on the CI code itself. Right. That that that's sort of like the argument here is like, what's good enough? Like, can I can I just throw a bash script at the beginning that doesn't handle every edge case, but it's okay because we're not sure if this is gonna live or not. And yeah, I think really understanding your trade-offs is it I'll I'm glad that they spent a beat talking about this because yeah, it's really easy to fall in love with the building of the building.

Carter (42:49)

Yeah, but but I also think they say like you gotta be careful about what good enough means. I I wonder about this sometimes, right? Like I have I have more of a tolerance for bugs than other people do. and I I I don't know. I don't know if that's the right approach. I don't have a tolerance for like major things being broken, but sometimes we'll I just remember like we

Yeah, like because this was a big shift for me coming from big tech to a startup. I remember like last year we did the we migrated from Azure to AWS. I led it, I got it done. We switched over. I think once we switched over, I don't remember, there was some sort of bug in it that was like big enough that I don't remember if it brought the site down for a couple of minutes or something, but it was something that if if this had happened at a one of the bigger companies I'd been at, this would have like catastrophic. This would have been like,

How on earth could you have screwed this up? And I was kind of like apologizing to my CTO. I'm like, it's okay. Like, you know, I'm sorry, I'll be better. And he just kind of looked at me like, what on earth are you talking about? Like you migrated us from Azure to AWS, something we've wanted to do for years and and we haven't been able to get to, and you took care of it, and like all it cost was like this little teeny tiny blip in service. Like, who the freak cares? I really jive with that philosophy. I really like this idea of like,

Hey, we're gonna ship something. Like we just shipped like the new version of our our inbox, like our messaging platform. And that's something that the people, you know, the people on our platform have care have complained about for years because the old version stunk. And the new version is a lot better. And as people have been using it, they've been flagging, like, hey, here's this little bug, or hey, here's this little thing. and there's been nothing major, but just a little bit like,

Hey, it turns out that like when I'm trying to search for I was trying to search for someone and their name was Rafal, but it was actually Rafal, but the L had like a slash through it. It's like a special character. And I couldn't find them because we weren't unaccenting our searches. And I'm just like, like, okay. And you know, you put in a fix and and you move forward with it. Like, I don't know. I really like that style of development. And I understand how

Nathan Toups (45:01)

Yeah.

Carter (45:02)

you could I understand how you could be have less bugs. The answer is slow down and and the test more, but it's a little like, I don't know. So

'Cause he says with good enough software, they say like, well no it's not lowering the bar, it's not sloppiness, it's it's more it's it's less feature complete, but more bug tolerant software. I get it. I don't know. I I don't mind the occasional bug.

Nathan Toups (45:24)

There

and again, I this is a thing that this book does quite well, which is show that there's an aesthetic quality in any environment, right? There isn't a I I've been in different startups with like different types of founders where the cultures are different as well and the in the in the

Carter (45:39)

Right.

Nathan Toups (45:40)

the talent set is different, right? I'm working with with one group right now that are advanced Kubernetes users. And so the idea of building like a custom you know controller and operator pattern.

with you know with custom records and all all kinds of custom resources and stuff internally is not a crazy thing to do. And I've been in other environments where Kubernetes is like you know the craziest idea ever. And why would you ever use this? Because it's too hard to reason about. I would I've been in companies where the founders were database like systems level programmers.

The level of complexity that you can keep in your head, or the level of abstraction, or the the tolerance of minutiae, is just different in the different organizations that you're in. And so what's acceptable is good enough is also going to be defined by who's there, right? and I, you know, and again, there's also a finite amount of resources. There's a finite amount of time in the day. There are trade-offs. There are, you know, realizing when is the last responsible moment for actually really categorically solving a problem.

These are things are you they never go away. Every I anybody who's moving sufficiently quickly, everybody that I know in every startup that goes, man, I can't believe we didn't solve this problem for as long as we did. And we finally did it. And I'm thinking, why didn't I do this six months ago? And I'll tell you, six months ago, you probably were putting out so many fires that there's no way that

Carter (47:05)

Yeah, right.

Nathan Toups (47:06)

you would have actually optimized for that. And people have looked at you like you were crazy.

Now,

maybe it was super easy and you checked a couple boxes, but you didn't even know if that was what it was going to be. It could have been that you sunk three days into it, beating your head against the wall, and had nothing else to show for it, right? and so yeah, I I I again I I like this acknowledgement of maybe you can define thresholds yourself of what is good enough, right? You know, if I can get this thing done by the end of the day today, that's good enough.

I'll put my to do list of items. Maybe as I have time, I'll try to improve it to h deal with these edge cases that I'm thinking about. But the edge cases are so rare twice a year that if I have to go manually restart the process, I'll do it. Right. That's I

Carter (47:50)

Right, right.

Nathan Toups (47:51)

think a good example where

Carter (47:52)

W I I think a lot about Martin Fowler, one of the revelations when we were at refactoring was this idea that if if you're refactoring properly, you should be able to stop at any point. If you feel like you have to be like, No, no, I can't move on to other tasks because I'm in the middle of this big refactor, like, well then you're not refactoring properly. You're taking you're carving off too much big chunks. You should be moving one thing at a time, and if you stop, it's it's great that the system is still in the position it it's is it's still in a good position, a better position than you found it.

and this gets to kind of some stuff with with chapter two, they call it a pragmatic approach. This gets into more of the actual software engineering tactics, with like the idea of reversibility, which is topic eleven. because I I tell our my and my team all the time, I say we we've just got to find the halfway point. Like our whole job is just finding halfway points where we can kind

Nathan Toups (48:43)

Yeah.

Carter (48:43)

of build something and say, This is good. And then if we want to continue to build on this.

It would be very easy to continue to build on this. you know, I I I can't remember if I talked about this last week, but yeah, just this this we have this principle in our system that only the back end or are kind of one. We have just one back end can write to the database. we have several things that read from it, but only the back end can write. And as I was building this note new notification system, we wound up having this kind of long living Docker task that pulls twice a second to kind of basically just

Pull things off the database and claim them and then dispatch notification. It's like, it's a queue, essentially. and I was looking at it and like it just made sense for this thing to write to the database for it just to have a scope-down role and only handle like two tables in the database. and and I kind of told the team, I'm like, yeah, like this makes the most sense. And we've built this in a way that, like, in the future, if we want to go like the full microservice approach and build a real API for this and

Give it its own database and have everything kind of communicate over the network, like we could do that. It's it's a clean cut. but finding that cut is a skill in and of itself. And how do you build things in such a way where if you want to reverse the decision you made, you can reverse it pretty easily. and

Nathan Toups (50:02)

Right. Yeah.

Carter (50:05)

or if you want to take it further, you can.

Nathan Toups (50:06)

Absolutely. Yeah. You know, the second chapter will be very familiar in concepts to anyone who's read Fundamentals of Software Architecture, any of the ThoughtWorks related books, you know, Martin Feller's refactoring.

And anything Kent Beck had w written about, right? Reversibility is also that idea of optionality. It they they kind of play off each other. There's a section on orthogonal orthogonal or is it orthogonality? Wow, that's a mouthful. But you know, orthogonal decisions where yes, there's coupling, but they're sort of at a 90 degree angle to one another, and that you can actually speed things up by making categorical decisions that slice through layers. you know, and again

To put this into perspective, picking open telemetry for all applications in your infrastructure is an orthogonal coupling, right? It's

Carter (51:00)

Right, right.

Nathan Toups (51:01)

it's this idea that I'm gonna pick a standard for how we do metrics, logs, and tracing, but it unlocks the ability for us to not have the cognitive load of thinking about what how do I do this every time I do an implementation. And if we have a standard sort of interface to

expose these things, maybe a scraper endpoint or a a a common place to push things to, like an alloy, you know, hub that's like from Grafana. You push that into those things or you have it scrape it out. Well, okay, we've categorically solved a problem. you know, I don't have to think about the implementation details of how's it get how does it get into our dashboard and alerting system. and it actually unlocks this, you know, huge sort of cognitive load that a team would have otherwise.

Carter (51:49)

Yeah. Yeah. I I I love this idea of orthogonality because it this kind of is that idea of finding the cut too. And and when can you recognize like, hey, these two things they intersect, and that's what orthogonal means, basically, like two lines that intersect at a right angle. Like they touch each other, but they don't affect each other. an example of orthogonal cut thing is it like it is kind of like your database, like theoretically.

If build your application properly, you can swap out the database underneath the hood. And you shouldn't

Nathan Toups (52:23)

Yeah.

Carter (52:24)

have to change too much. You you shouldn't have to change anything on the front end. And on the back end, if you've built everything using like database access objects, then you should be good too. you know.

Nathan Toups (52:35)

It exactly. It

it's funny too, because I I've actually run into this with folks where they've they they thought the abstraction I was introducing was a little too much where I'm like, hey, for instance, let's say we need it to annotate something being written to the logs and I always want to have this inversion of control sort of like log interface thing, right? Even if it's a thin wrapper across the the logging interface that we really like from let's say open telemetry, I'm like one day this might not be the best way to do things anymore.

And it's much nicer for us not to have to go through 45 business logic sort of, you know, methods and rip out all of these, you know, very specific implementation details where it would be really nice if I had a, you know, a log a logger provider init that happens when I spin up the server and it just happens that I implement the open telemetry SDK version of this. Right. Now I'm exposing my info and debug logs or

know using some decorator depending on the language that I'm in. And I've never regretted it. Right. It's it's not too much in direction for what's going on. And databases are exactly the same thing. Like I love having a client abstraction, right? Where I can I decide that the client exposes these methods, you know, these standard sets of methods. And then I can easily throw in a fake or a mock, right? If I'm doing it makes it better for unit testing because I can have something that just gives me enough of the client interface.

To do the unit tests with all of the cases of what a database might respond respond with. it gives you the ability to put a fake behind it where it actually behaves entirely like a database, but it's actually not a real database, right? And it yeah, it's it it is. You you you're absolutely right. Like I should be able to use SQLite or Postgres without changing

Carter (54:23)

Mm-hmm.

Nathan Toups (54:24)

anything in the main parts of my business logic, right? It should be that I can wire up the differences in those languages or differences in those yeah.

Query languages, but the big deal. Okay, we skipped it. I'm gonna go back to it because I'm I'm not on the dry train. I'm gonna tell you this.

Carter (54:40)

You're not on the dry train?

Nathan Toups (54:42)

So dry, right? Don't repeat yourself. I agree in principle that if you notice a pattern and that you can abstract it out, that can be a good thing, right? But I think that it's kind of it's been taken to some extremes that I find really.

dizzying and kind of like cultish. And I'm not

Carter (55:05)

Right.

Nathan Toups (55:05)

I'm not anti Rob Pike has an excellent counterexample. This is a go proverb. There's like these go goisms, these go proverbs. And one of them is a little bit of copying is better than a little bit of sorry, a little bit of copying is better than a little bit of dependency.

Carter (55:24)

Yeah.

Nathan Toups (55:24)

And this is what I'd call the left pad argument to why dry is okay.

I'm sorry, why being anti-dry is okay in certain circumstances. So years back, this is like ancient history now. This guy rage quit the internet. He had written this really small JavaScript library called left pad, and it was like five lines of code or something dealing with left padding. And it was a

Carter (55:43)

Right, right.

Nathan Toups (55:44)

dependency on like node or something, like some like fundamental piece, and it broke the internet

Carter (55:48)

Yeah.

Nathan Toups (55:49)

for like a hot second. And, you know, the fact that somebody with a five-line package and a package manager could break the internet is a real

problem. And it's okay to vendor that code and to make an idea and have your own implementation of left pad and just do it. It's okay. Like that code's not going to change. You're not going to like fundamentally change like it the cycle of adapting left pad to the changing internet is going to so slow. And you'll know when it's going to happen that you should just implement your own left pad and not have a dependency there. and so I think that's obviously it's a like a steel man argument or

straw man argument that like that you know it's an extreme case. But I will say that I I hate this I if I start seeing somebody who's like implementing some little small chunk of code and then kind of coming up with like the most generalized version of it so that every, you know, kind of like weird partial implementation is just s preventing you from having to write five extra lines for something, it's a code smell to me.

It just really is.

Carter (56:58)

No, I agree. We have that with like name formatting functions and you know, we've we've gotten less strict about it with Claude because like it's like, well, we have the one sanctioned name formatting function. I'm like, I don't know. Do we need that? is it fine if if this is repeated a a little bit around the code base? I th they they talk about dry, not even as a concept of just code, but of just information in general.

And that if there are multiple sources of truth for information, that's a problem. They have an interesting example too of like they basically give the example of like two different formatting functions. One for like, I don't remember the details, like let's just call it price and weight. And you might look and the the logic might be identical between the two. And so someone might say, dry, don't repeat yourself. And they say, But no, no, no, the code is identical. But these are two different things. One is validating price, one is validating weight.

Yeah, I I I like the idea of dry it's it's another one where it's like

Coding agent. There's two kinds of schools of thought with Dry. One is don't have multiple sources of information because that can drift. And that can yeah, like and that drift kind of results in it can can result in errors. There's another philosophy on it, which is don't write something that's already been written, like save yourselves the time, just reuse the work that's already been done. I think that has always been the less valuable part of Dry.

And it's especially not as valuable with coding agents because it takes a coding agent 10 seconds to write that function. Right. And so, so yeah, I I I'm kind of with you on that front. But I don't know. I I think when we redid we did our big migration and I had to migrate the orders chunk of it of like how we processed all the orders. Like, yeah, there were we were processing orders different ways in different places, which was really,

Nathan Toups (58:59)

yes, and

Carter (59:00)

yeah, right.

Nathan Toups (59:00)

and I don't I I mean it's it's the I don't like it. I think it was the primogen talks about this where he he he doesn't like these I think they did a review in their sh the stand up where they these truisms that people just say without thinking, right? And I worked with a guy one time who is like a he was not a great software engineer. He was obsessed with dry.

And he would just that would be his like go well this isn't dry enough or you know blah blah blah like and I was just like it would just be so annoying. And sometimes I would agree with him and sometimes I wouldn't, but it was just like his way that he chimed in. And I think that there's like knee-jerk reaction, let me say something to sound smart kind of things. And unfortunately try gets sucked into that, right? It's like a way for you to sound like you're saying something and not saying anything.

And and yet I'm not disagreeing. Like sometimes generalizing a pattern is absolutely what you need to do. I'm not saying that, like if you notice that you've implemented the same thing three different ways, and then you in your big brain moment go, you know what? This is a general pattern. Like I should just write this thing, this library that's shared across these three pieces, because I'm really afraid of implementation drift. I think that this team's gonna overdo this thing over here, this thing's gonna do this thing over here, and like

I realized that this is a multi-step, you know, database, right, that needs a transaction around it. And I think if we just like implement this transaction multi-state thing one time and then you can insert the implementation inside of it, life will be better. We'll do it the correct way. I couldn't put proper test coverage in front of it, blah, blah, blah. Right. Absolutely. And they also bring up this one that again, I'm on the fence. They also say dry can happen with comments in code.

And they say, hey, if you write these big comments about a function, you know, some little functions like add, you know, X and Y. And then you write this like three, you know, three line thing about the behavior of it that you're basically repeating yourself where the the function's self-evident in like what it actually does, right? You don't need a big explanation of what the add function actually is. I think that there's a truth to that. And and I will say there's a caveat in that.

I really like languages that use comments as a way to annotate generated documentation. So like in Go, for instance, it's quite common to describe, like in John Oester Help method, describe the intended behavior of something so that you document your code. and I don't think that that's repeating yourself. Like you shouldn't just say add takes an X and takes a Y and returns a Z, right? Or whatever, but you should say, hey, the the add function is intended to use.

Integers and is, you know, handles this edge case that can happen in this one implementation. You know, if like if you need to give some extra context to it because it's part of some specific thing and there's a reason you've implemented add, like why did you do that? First of all, right? There probably a reason. It deals with overflows,

Carter (1:02:07)

Right.

Nathan Toups (1:02:09)

it deals with, you know, whatever, like the things that you're doing. Those things absolutely should go in the comments,

Carter (1:02:13)

Okay.

Nathan Toups (1:02:13)

right? Like those those are things that you need to like warn others why this was here. and so again, I I I agree.

Like but it it comes back down to like, are you thinking? Are you a thinking person? Are you thinking about what your intent is? and so yeah, yeah, dry.

Carter (1:02:32)

Well, we gotta wrap up. I gotta I got an earlier morning meeting today.

Nathan Toups (1:02:37)

Okay.

Carter (1:02:39)

but it's yeah, I I'm really enjoying this book. we weren't able to talk about everything here. my only hot take is is just like it's funny. The 20th anniversary, they they didn't modernize some things, like like there'll be references to Slack or like social media. And then there's some things that read as like very anac or like yeah, anachronistic or just very old. I can't remember off the top of my head.

I think there there was this whole one on like email etiquette, which I I don't even think that's necessarily old. I just I it modern workplaces are funny though. I can't remember the last time I really checked my work email. I we just do everything over Slack, but I think that's more a

Nathan Toups (1:03:15)

that's funny.

Carter (1:03:17)

a a our company thing. I got any hot takes? We shared some of them over the the course of the podcast.

Nathan Toups (1:03:21)

My hot

take was mostly around dry, but even they acknowledge this. I think that maybe the way that they communicated dry in nineteen ninety-nine is different. It's more nuanced now. And I think they do acknowledge that, you know, there's some caveats to it, which I again makes total sense that the origin of this as understands that there's limits to it. But no, I I mean, I think anything I any hot take ish thing I had was in flight today.

Carter (1:03:47)

There we go. Well, as far as what we're gonna do differently in our career, I this is cheating because I did read ahead a bit. This was in chapter three. They recommend taking a week to use your computer without a mouse. And I don't think I give them a week, but I am jealous

Nathan Toups (1:04:03)

Ooh Carter.

Carter (1:04:06)

of those who can just do pure keyboard stuff.

Nathan Toups (1:04:09)

Next thing I know, you're gonna be like a Neo Vim user and r writing things in Lisp. I think it's gonna happen, man. Yeah. I I'm just saying this is like the gateway drug for for all of this world.

Carter (1:04:15)

Not not Liz, oof, not that far. I I don't I don't get it. I I

there are some things like I like. Like I've I've been trying to get better. I use CMUX as my terminal. I've gotten better with like the hotkey so like I can t toggle between workspaces and and tabs like easier. Like I think that's useful.

Nathan Toups (1:04:33)

I've moved on to an this is I've moved on to something called herder from CMUX. It's gonna I know I did, I know I did.

Carter (1:04:36)

Yeah. A herder? You you introduced me to C Mux. Yeah.

Nathan Toups (1:04:43)

And CMUX is great. Herder is CMUX, but it can run anywhere. It's not just Mac oriented. So I can SSH into Linux servers that are running my isolated

Carter (1:04:49)

Yeah. Mm. no, that's nice.

Nathan Toups (1:04:53)

VMs in yeah, herder. H E R D R. You know, because you gotta have that.

Carter (1:04:57)

But I like

I like that CMUX is Mac integrated because I like that it has the notifications API.

Nathan Toups (1:05:05)

Herder has notifications. It's

Carter (1:05:07)

What the heck?

Nathan Toups (1:05:08)

mind boggling. If if you're using it with like Ghosty, which has this like Yeah. Anyway, it's we'll put we'll put a link to it. We actually talked about this in the AI workflows. I think is it either AI general or AI workflows? Herder's become my new favorite, I guess, harness interface. It's it's replaced Tmux. It's replaced Tmux for me for remote Linux stuff. Because I I run client mish workloads, isolated environments because I

wanna reduce my blast radios. And now I have this like consistent interface for it. So anyway, yeah.

Carter (1:05:41)

There we go.

Nathan Toups (1:05:42)

I gotta get out of here. This was a lot of fun. I can't wait to see these next two parts of this book though.

Carter (1:05:48)

Well, I'm excited. You can always find us on our socials at BookOverflow Pod. I'm on Twitter at Carter Morgan. Nathan is work functionally imperative at functionallyimperative.com. And you can find us at bookoverflow.io. We'll see you next week, folks.

Nathan Toups (1:05:59)

See ya.