The Pragmatic Programmer

Carter (00:00)

a lot of what they describe as like being next level programming really to me feels like programming by coincidence. Like, I I'm glad it works. I don't know how it works. But that's not software engineering.

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

Nathan Toups (00:28)

Doing great everybody.

Carter (00:30)

Well, make sure to like, comment, subscribe wherever you're at. share the podcast with your friends, you know, on LinkedIn and Slack. whatever helps, whatever you can do to grow this podcast. We always we love making it. We want to keep making it. And in the essence of keeping you making it, I guess we're making an episode right now because we're finishing out The Pragmatic Programmer, Your Journey to Mastery. This is the 20th anniversary edition. We've read the first two thirds over two episodes. It's the final third. It's chapters seven through nine. And then there's a a a post phase.

very end. a postface or a postface? It's the preface.

Nathan Toups (01:04)

You know,

I'm not that fancy. I've always said postface, but I also I also called it a primer instead of a primer, so you know.

Carter (01:08)

That I think it's probably Yeah.

I I'm I'm still mad. Like I I I once use the term enveloped, like I was enveloped in something and my friends in high school are like, Do you mean enveloped in something? I'm like, it's freaking enveloped. So I I wanna s okay.

Nathan Toups (01:24)

Wait, what? Enveloped?

I'm I'm on team enveloped. That's what I'm gonna say.

Carter (01:29)

Yeah, yeah, yeah, yeah. No, no,

that right, right. It is enveloped. And they were like, no, it's enveloped. It's pr d look how it's spelled, idiot. Yeah. Yeah. I'm s I'm still enveloped with rage.

Nathan Toups (01:34)

Well they can go hang out with themselves all day and and it's also it's okay. I mispr Yeah, I bet you are. I

I mispronounced idempotent for I called it like I'm dipotent or something. I can't remember. It was embarrassing. Exactly

Carter (01:51)

Idampotent. Yeah. That's one of those words you only ever read. And you know what?

Now now that we're mocking people, I should say that I actually am on the team of like people who mispronounce words because they've only ever read them. I'm like, you know what? It's good if you're encountering words that are kind of exotic enough that you never need to say them out loud. And so but but but

Nathan Toups (02:11)

Yeah. Same, same.

Carter (02:13)

you know, but then don't be like it. So yeah, I'm I'm a fan. If you mispronounce things, that's fine. But then don't like smugly correct your French. That's what I'm still mad about.

I still remember the exact room where this happened. It was in high school.

Nathan Toups (02:22)

Yeah. Do

you call it a GIF or a JIF? That's the you know You're Jif guy. I'm GIF but I'm you know, 'cause I'm I'm an old man, so we all we didn't know the right way to pronounce it, I guess.

Carter (02:26)

I'm a I'm a GIF guy. Yeah. But your your GIF. Yeah. Yeah.

all right. Well, speaking of old men, this book is written by two of the titans of our industry. This is Dave Thomas and Andy Hunt. They might object to me calling them old men, but you Dave Thomas was born in 1960, so he's he's retirement age.

he 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 Pragmatic Bookshelf Publishing Company. Thomas moved to the United States from England in 1994 and lives north of Dallas, Texas. Thomas coined the phrases code cotta and dry, don't repeat yourself. Was an original signatory and author of the Agile Manifesto of or the Manifesto for Agile Software Development. He studied computer science at Imperial College London. Now Andy Hunt.

Is a writer of books on software development and chill sci-fi, hunt co-author of the seminal text, The Pragmatic Programmer, The Popular Pragmatic Thinking and Learning, Award-winning Practices of Agile Developer, Half Dozen other Books, and many articles. And he 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 I think we've I think we've alluded to this on the podcast where I mentioned this before, but it still is crazy to that like we're reading a book by the guy who invented

Dry. Don't repeat yourself.

Nathan Toups (03:49)

Yeah.

Carter (03:50)

And you you kind of wonder: like, are we going to keep inventing new axioms of software development? And so the field will always kind of appear somewhat fresh and modern? Or like was a lot of that kind of foundational stuff already invented? And like, I don't know, it it's it's kind of weird. It's like being alive at Einstein's time.

Nathan Toups (04:06)

I have a feeling these

yeah, I think these patterns kind of come up once there's a sort of like paradigm shift. And I don't mean that in like a cliche way. I mean when we when when we saw this transition with we programmers, when the cost of developing software became more expensive for the engineer to be involved than the hardware, I think that there was a change in like how we cared about.

you know, software development practices, right? So before it was kind of like you're maybe computer s I mean you know mathematician or you know sort of ivory tower background, but you had this multi million million dollar machine and these very like particular folks working on it. And then once writing code was relatively quick and it like, the teams of engineers are like the most expensive part of this in some cases. I think all these development practices sort of emerged. And I don't know, I I feel like

I have a feeling that we're gonna like as we sort of mature with the new tools that we have, I I would not be surprised if there is something clever that comes out of it. before we get into the the rest of this, what is chill sci-fi? You know, like I I'm and Andy, it

Carter (05:16)

You know what? We we've read it three weeks in a row now.

Nathan Toups (05:20)

I know, I I was like i it didn't hit me till this third time. I'm like, I wanna know versus what, like spicy sci-fi? What's the or you know? Ooh, there you go.

Carter (05:26)

Yeah, yeah. Erotic sci-fi. Let's see.

conglomer. I'm I'm reading right here. He he wrote he writes Conglomera is the name of his series.

Nathan Toups (05:38)

That's cool.

Carter (05:40)

But whether or not okay.

Nathan Toups (05:42)

But what does it make chill? I

I'm just curious, you know, is it is he like surfing the information super highway?

Carter (05:46)

I'm a sucker for things like this. Like like

he's cut it's called Weatherly Hall. And I do like I I'm just seeing like after the second civil war, Henry buys a long abandoned desolate mansion. And I'm just like I I I'm a sucker for anything like the second civil war. I immediately want to know, like, well, what was it fought

Nathan Toups (06:04)

Okay.

Carter (06:05)

about? Like I'm I'm in. Like

Nathan Toups (06:07)

Hey, maybe maybe one day we'll do an Andy Hunt science fiction reading. That'd be kinda fun.

Carter (06:10)

I maybe. It's

got five stars, only seven reviews, but still. when did he?

Nathan Toups (06:16)

Hey I indie

authors are the cool the coolest. So

Carter (06:20)

He published it

recently. It was published in 2021. You know what? If Andy

Nathan Toups (06:23)

Huh, okay.

Carter (06:24)

Hunt comes on the podcast, we will also one day read.

Nathan Toups (06:28)

Read one of his books. Yes.

Carter (06:29)

But you know what? The funny thing is, the easiest way to get Andy Hunt on the podcast would be to read one of these books and be like, hey, we read Weatherly Hall. We'd like to interview about it. And then you have to like sneak in and be like, and also, can we talk about the Pragmatic Programmer? Well, we'll we'll see.

Nathan Toups (06:46)

How did the Agile Manifesto impact your science fiction writing?

Yeah.

Carter (06:49)

Yeah.

okay. Well, let's talk about the the last third of Pragmatic Programmer this week. I think I gave you the book introduction. It's 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. So finish the book this week. Nathan, give give us your thoughts on the last third. I the book is a whole

Nathan Toups (07:16)

Yeah, so I I I accidentally read ahead a bit because I thought we were finishing on chapter seven, even though I wrote down that we were finishing on chapter six. So I read chapter seven and had to keep it like a secret because I didn't talk about it in the episode. chapter seven is probably my favorite chapter of the book, but seven, eight, and nine are just like good advice. And I'm glad we're here. I think this is gonna be a fun episode by itself just because it's good. I don't know. I

I'm I'm glad that they rounded the book out this way. This is an area that I'm like super interested in. So yeah.

Carter (07:51)

Yeah, I mean, for me, I've always kind of enjoyed the higher level software engineering more than like kind of the nitty gritty details. I I always joke, like I'm a pretty easy PR reviewers or PR reviewer. My general take is that if something is getting to the PR stage or there's just like tons of glaring errors, then something has gone wrong. Either we didn't architect it well enough up front, or maybe I we we're not as aligned like the code base standards.

I don't think that's like the one true path. I we we have a junior engineer who's great and he's working with one of our senior engineers. And you know, the senior engineer is a bit more of a stickler on PR reviews. And I I I was he's the junior was kind of talking to me about it. I I told him I like, Listen, like if it were me, I would not be reviewing these as hard. But what also I will say about your coworker who is reviewing your PRs is like he's very, very talented. And this is all great feedback he's giving you. And so, you know, like, yeah, it's it's

No one likes getting comments on their PR reviews, but it's great learning, so you know, make the most of it.

Nathan Toups (08:54)

Tying this into our Discord, we actually just had this big conversation on how like PR burnout that's happening right now. There's some folks in

Carter (08:59)

Yes. Yes.

Nathan Toups (09:00)

there talking about how you know, this is a great vehicle for mentorship. I think this is a excellent example of like why is the senior engineer being such a stickler on something that seems so benignal?

Carter (09:12)

Right, right.

Nathan Toups (09:14)

and it's actually like it's actually quite important, especially if you respect that software engineer.

them being pedantic about certain things really comes down to like how tidy do you keep your campsite. That's kind of how I think about it. And they do add up over time, right? Maybe, just this once, it doesn't really matter. But and I guess we'll get into this. They actually talk about this, the no broken windows strategy. And I think it's actually ties in quite well. Where things have changed is, yeah, the the pressure that we have on ourselves, what's going on. I think it's I

I try to look I when I'm doing code reviews, it's typically is it d is it within a threshold which I think is acceptable and enough for me to knit so that they have to go back and stop their flow. that's kind of I try to find that that balance there, but I I also respect folks who are like super nitpicky. as long as I think there's a purpose to it. Some f some folks, I'm like, you're gonna drive everyone nuts and we're never gonna ship anything if, you know, you're

Carter (10:15)

Right.

Nathan Toups (10:16)

angry about the variable name choice on a

you know, private variable inside of a function. So

Carter (10:23)

Some sometimes I gotta

I gotta train myself out of like I used to very much be like, by the time the PR review is made it to me, so much work and effort has gone into it. And so to tell someone to kind of like rework everything, like I don't know. But now I'm like, that's not true anymore. Like it was a prompt that that generated this PR, right? Like or or and even

Nathan Toups (10:42)

Right.

Carter (10:42)

if a lot of work went into getting it to work, reworking it is probably a prompt or two away, right? Once kind of like the the guts of it are in place. So, you know.

Nathan Toups (10:51)

Yeah, exactly.

And what the cool thing is I try to preemptor that now too. Like I actually have this flow which I will I have like a few saved patterns. One is a I have like a pretty in intensive adversarial review process internally before I even open a PR. and then I also have like a very specific way I write prose. For instance, the document like the description and comments. I think we've talked about this in the past, but like I hate it.

When it's like a choose your own adventure novel in the comments section of code and it's like, I did this, and then we tried that, and then here's the ADR for this. And it's like, I don't need to know all this in the code. Like this is

Carter (11:31)

I know.

Nathan Toups (11:31)

this maybe is acceptable in the description of the PR. Maybe. but I also don't need a TED talk every time I'm doing a a a PR, right? Anyway.

Carter (11:41)

I lost it out

on my team. I wanted to ban all PR or AI generated PR descriptions. Like, I hate Like just you tell me, you tell me as a human what your code did. And and I try to do that in my PR descriptions as instead of being like, here's exactly how this works. I try to instead flag like, there are these two things are not quite what you would expect, or I had to choose this pattern because of this or or whatever.

Nathan Toups (12:06)

Right.

Carter (12:07)

well

We can get right into this. Is chapter seven. It's called While You Are Coding. And I actually think this is really interesting in this day and age. I'll start with topic 37. listen to your lizard brain. And the idea is basically that, like, we as humans, we are we have instincts, right? And that when you're working with code, you should really pay attention for when the code feels like it's pushing back. And I say this all the time to my team, right? I say, like, we gotta try this and we gotta see how hard the code.

Is

fighting us. Because if the code is fighting us, that's a sign that either we architected the code incorrectly to begin with, or that the way we're trying to solve the problem right now is the incorrect way. I saw someone on Twitter, they they compared it to in Interstellar, the main character, Cooper, the pilot. At one point he he talks about he needing to I think he compares it to like why flying a real plane is different than flying a simulator. He says, I need to feel the air.

And I think about that a lot with programming. and it's something we have lost or are losing with LLMs and with coding agents. Like, I still think you can feel this to a degree. I think you can tell, like, if you start getting into a lot of back and forth with Claude Code or Codex or whatever, and that's a sign that it's fighting you. But there is something about

getting in and working with in a code base with your actual, I guess, hands, so to speak, and and finding those kind of friction points. And I don't know, we don't find them as much these days.

Nathan Toups (13:45)

Yeah, no, it that it is there's a there's an intuition that we develop, right? And I think that's to me is what Lizard Brain for a long time I thought Lizard Brain meant like the fear the fear sector like or like some more primitive, like less good part. And I think this makes a good advoc a good case for

I've taught I've talked about this. I know some folks are very intuitive people. But and I think we should always try to trust our intuition, but we shouldn't always try to trust our conclusions, right? It's very easy for us to reach the wrong conclusion based off of a valid intuition. And so I think this section does a good job of ex of saying, like, hey, you should listen to this, take a step back, think about why. Like, why did this set off your spidey sense? Why is there a code smell here? Why, you know.

And if you ignore it, I think that's the part that's bad, right? Hey, like you if you get disoriented or something doesn't make sense to you, it's very likely that it doesn't make sense to other folks. Or it's very likely that maybe it works by accident, right? These are these the sort of areas where anytime I've run into big problems, it's because I kind of ignored my intuition and I was like, well, you know, everybody else on the team seems to think this is fine, even though this doesn't quite make sense to me. When I really should probably have taken a step back and been like, okay.

Why doesn't this make sense to me? Like what, you know, what's going on? And yeah, I it it it's good. I think giving yourself permission to like trust that intuition. Now, that on the flip side, every conspiratorial person that you've ever met, you know, if you've ever met an actual

Carter (15:21)

Ha ha ha.

Nathan Toups (15:22)

flat earther, if you've ever met someone like this, they also trusted their intuition, right? They knew

Carter (15:27)

Right.

Nathan Toups (15:28)

they didn't you know and there maybe their intuition was I don't trust the government, it's lying to me or whatever, right? Like which I think is a valid.

intuition to have, but then to reach the conclusion that and therefore the earth is flat. Again, I think we should all just like take a step back and be like, okay, I don't have to reach that conclusion just because I can agree on some intuition that's in place.

Carter (15:48)

Yeah.

Yeah. I mean, I don't know. It's it's they they talk about this kind of similar concept of testing. And they ask, okay, what's the value of testing? And I think it's Andy Hunt who says, like, you know what, after 30 years, I actually don't write tests anymore. He says the reason why that's the case is that the the val the real value in testing is not necessarily like making sure that your code works. It's that

It's it's forcing you to think about your code either as you're coding and thinking, will this test easily? Or when you start writing the tests and you're like, This is this is way too hard to test. You know, I think it's too brittle, it's too coupled. and and so he says, like, after you've programmed for 30 years, he says, after you've written tests for 30 years, consider maybe not writing tests, right? But said basically, like it's taken that long for him to build up the intuition. This is another one where

we're losing this with coding agents. And I think we can kind of, you know, my my very my director back at my first company used to say that like having a hundred percent test coverage is like saying that you have 100% words filling the newspaper. Like it doesn't matter, right? It's all about what words you're actually writing and what tests you're actually writing. And I feel that, I feel that with all these tests that Claude generates, it's like,

I guess maybe there might be some value in Claude generating its own tests and being like, okay, the stuff I just wrote immediately works. And so like there it's a sanity check for it as it's kind of in its own little agentic loop. But like I don't find these tests very useful from like a long-term health of the project. We're, you know, every time we we have a bug.

I'm just like, well, why didn't the tests catch that? And of course they didn't because they're not thinking about anything aside from like the most basic features. And I'm finding it's really annoying because like it's writing tests for like copy changes or like the button says buy now. And so even if I'm like, I'm just gonna get in and make this test, or I'm gonna go in and update this code really quickly because I got to move like seven lines around and like it's not a big deal. Then I'll like submit the PR and then my builds fail.

Because it turns out there are three tests that depended on that code being in the exact right order. And so then it's annoying because I get into the habit of like even if I have to make little changes like that, I don't do them by hand. I just ask Claude to make the change because Claude will know where all the associated tests are. But like that's a sign to me that like these tests aren't helpful. They're they're just wrecking my development flow. and it's just one of those behaviors like, boy, Claude loves, Claude loves writing tests. Like Claude loves writing comments. I

I mentioned how we add a we have a hook now to strip all comments after it runs or or does any sort of you know, like write action. It runs that hook. And then Claude started writing Python scripts to write code so the code could include comments. Like it's insane. I don't know.

Nathan Toups (18:56)

Yeah, that's nuts.

So I'll I'll take a pragmatic approach to this. which is that like I do think if you if the what is it, if the measurement becomes the goal, right? It's sort of you you no longer have these effective these these effective measurements. I I understand that you know if I had to choose between Claude style comments in my codes and no comments, I'd obviously choose no comment.

But I actually also am in the Osterhout camp of comments where it really should describe the why and the how of things where appropriate, where it needs to give that context to make sure that we understand the intent of code so that we can protect ourselves in the future in case we try to change something and it now then breaks the intent of its original purpose.

I don't mean writing three paragraphs necessarily. I think most of the time you shouldn't, but there are times in which, you know, you're like, why did I do this? I think it's actually like quite quite good, especially if you're doing like library level coding. The other piece is like again, I think if you do Osterhealth style testing, then the tests actually you you kind of have both worlds. Like what Dave did I this is typically how I write. I'm not a TDD person. I don't write a failing test and then write my code to the failing test and then go from there.

for a couple of reasons. When number one, I think it encourages you to be a tactical tornado, right? To get back to Osterhout's ideas, where I already th know that I have a clear idea of what the outcome should be. And so therefore I write against that outcome. And then once my code kind of like fills in the gaps and does all the things that I think it should do, I move on. I think there is a type of work that that works quite well with, but if you're doing exploratory work or you're trying to figure out what the feel of something is.

I I like to spend a little bit of time and just like write that code, like be in that flow state. Now I don't move on, but once I've kind of gotten that interface or I've figured out what the methods are or kind of done that stuff, then I'll come back and go, okay, what's a set of tests to make sure that this continues to behave that way I expect it to? Right. And that's how I look at tests typically, is that it's a contract to say, if these tests are broken, we cannot rely on the assumptions of the system any longer. Right.

And that gives you a very specific type of testing to do, right? I first I should have a pretty clear idea in my mind of the inputs, the you know, the mocks, the fakes, the stuff that I have to put in one side, and then the expected outputs of the other. and those should give you pretty good coverage of the behavior of that s of that part of the system. But again, Claude's not writing that. Claude's not being like thoughtful

Carter (21:46)

But

Nathan Toups (21:46)

and doing those things. You know, it and it will. It'll very qu easily give you a bunch of stuff to give you the warm and fuzzies so that you're

you know, manager whoever sees it, there's got some test coverage, but it doesn't it's not really doing anything. Or it's giving you that that connaissance problem where you're now having like coupling of process or, you know, something crazy where, yeah, three tests go out of order and all of a sudden it breaks. Like, no, we don't want to live like that. That's that's terrible.

Carter (22:14)

Yeah.

Nathan Toups (22:14)

So

that's my scree. There you go.

Carter (22:16)

We well, I think this episode might have a lot of screes. I thought this was interesting where they talk about this idea of programming by coincidence, which is

Nathan Toups (22:27)

Mm.

Carter (22:28)

like code that happens to work. I guess I don't know. I I don't think I ever got here in my career, which is just like, you know, typing things until eventually the pro the application might work. Like

To me, that seems harder. That seems harder than just like understanding what's going on. And like that's always what interested me in programming was being able to understand the logical, you know, the logical flow from one operation to another. Although I guess maybe this is another one that's going to increase with LLMs. Like we had this at work the other day where we our messaging system uses Cloudflare durable objects. And I guess it makes sense that that's like a third party thing.

But I always just kind of viewed as our own thing. And that yeah, like I don't know, that this is where even as I'm I'm saying it, I'm getting I I I I'm kind of of two minds about it, right? Which is that like I consider this our own infrastructure. Cause like when you think about like the services you rely on, it's one thing for your service to be like, this is like this is Stripe, which is like a third party service entirely, versus like this is AWS, which is like, yeah, that's a third party service, but I I tend to think of that as more as like my own.

Architecture. And so same with Cloudflare, these durable objects. It's like AWS, you it's it's it's infra. And so I'm like, okay, this is our own architecture. Anyhow, another team comes to me with a PR basically set like routing some requests through, we call it our outbound writer, which is the ability, like if we have anything where we're writing to a third-party service, it all goes into this queue. And then this one part of the code base takes care of writing to the third-party services, which makes sense because.

we congregate all of our rate limiting in that one place. and so it's a way to kind of have our event-driven architecture without like blowing up our rate limits. And so they they put the ability to interact with our messaging service through the outbound writer. And I was kind of like, wait a minute, this is our messaging service. Like why why are we talking to the outbound writer this way? and we we talked about it some more, and and I kind of came around to this idea of like, well, I guess it's not really.

hours so to speak. Like we are messaging a third party service Cloudflare. And they they were getting rate limited because they had spun up this new workflow where instead of sending, you know, we on average the site sends five or 10 messages a second, they were sending like a thousand messages all at once. And so like they got rate limited

Nathan Toups (24:58)

Mm.

Carter (24:58)

by Cloudflare. But I it did frustrate me a little that I I kind of asked the teammate a member who they they they sent the PR my away because like hey we know that you spun up the messaging service and so we just want to run this by you. And so I'm like

Why do we need this? Like, what's going on here? And the team member's like, I'm not sure. Claude said to add it. I'm like, well, that's not good, right? Like, we gotta figure out like what's going on here. And so, like, I don't think it was. They understood basically, like, we understand that we're getting rate limited. We understand the house pattern for avoiding dealing with rate limiting, but it was that kind of where we got to the point where, like, okay, well, previously this house pattern was meant for things like Stripe and Mailgun and and Twilio, which are

very clear vendors and like this is some something kind of halfway in between. And so we all got aligned on the pattern. But yeah, I I just like it's not quite programming by coincidence, but like heaven knows. I mean, we were talking about this before we even start recording today, Nathan, about just like some of the very influential people in our industry who I've admired for a long time. Like you just read what their their blogs or their Twitters or their LinkedIns or whatever. And it's just like,

kind of consumed by AI psychosis. And and a lot of what they describe as like being next level programming really to me feels like programming by coincidence. Like, I I'm glad it works. I don't know how it works. But that's not software engineering.

Nathan Toups (26:18)

Right. Yeah, it's it is strange. And I I think, you know, given the right circumstances, I think any of us can get in get in that sort of frog in boiling water situation where, you know, if you you kind of nickel and dime what you would have agreed to over time, you make a

little trade-off, little trade off. And then you wake up six months later and you're like, how did I get here? Like if if if you'd offered me where the state I'm in right now, I would not have accepted. And not have accepted this is how I'm gonna write code or this is what conclusions I would reach. And I think those are sort of like important wake up calls. Sometimes you can do this yourself and go, what am I doing? Sometimes it takes that fresh face of that person joining the team and you're like, yeah, this is kooky. Like why are we doing it this way? which I really appreciate.

or sometimes you go in and it's not frog in the boiling water, right? You really are. You go back and go, you know what? Given everything I know, I would still do this. And I I it it it's hard to discern right now, too, because I I feel like a lot of feet people are outsourcing thinking to these large language models. I think that's the concerning part. And again, same. Like what's the threshold? What's the thing I want to think about and what's the thing I don't want to think about? What's safe for me to

Farm out what's

Carter (27:38)

Right.

Nathan Toups (27:39)

not safe for me to farm out. I think we're all still trying to figure that out. actually, we're gotten to a point where I think this is important to bring up. My daughter, who's about to turn 11, she's been having like pretty interesting conversations. We just watched an old Kurt Kurtzgesagt, which is one of her favorite YouTube channels, from like seven months ago when they were talking about AI Slop. It's a really good episode.

Because they tried out a lot of these tools. They realized that the research ended up getting like 20% hallucinated. And they they've been really honest about what role AI tools are gonna play in their world and what what are gonna be hands-off and their concerns about it. I'm actually interested to see what a a year later would look like in their minds, but my daughter is very like she's conscious of this, she's conscious of

the AI slop, AI unhinged stuff, there's like an intuition to it. She understands that she'll call things out. She's like really proud to call things out. Like, that's an AI, that's an AI slop flyer, right? Which are I think really easy to see. Or and then she sees me using Claude every day, all the time. And I've, you know, I've talked to her about that and she understands that there's a difference between

sort of like dialing it in AI slop and then using it as sort of like an augmentation tool. But I told her I was like even that is like hard to sort of sort out. and who's in who's actually in control? And like, am I am I doing my best work or am I trying to outsource my day job? And I don't think there's an easy answer, right? because I think that any of us who any of us who you all of us risk the

There's a real risk that any of us could have AI psychosis at some point, because at that point, you don't know that you're there, right? You're so disoriented. and so this like the programming by coincidence of again, this is this book's interesting to me because it's a snapshot of the world right before we got here, right? This is

Carter (29:42)

Yes.

Nathan Toups (29:42)

2019 and so much stuff has shifted in the last I I really th I think that this book would have been like this book would be rewritten this last three chapters.

would mostly be addressing, well, what are we doing with these tools and my processes and these other things? I don't know. I it I I guess the the other piece of this, I'll again tie it back to my daughter. She's gravitated recently. I don't know if your kids have done this at all. My daughter, and maybe it's because I've indoctrinated her, she loves like 80s movies. Like s absolut

Carter (30:15)

Okay.

Nathan Toups (30:15)

like she just had a sleepover for her birthday. we're doing it early because we're gonna be traveling.

and the three three girls wanted to watch Back to the Future. Like of all the movies they could choose, they wanted to watch Back to

Carter (30:28)

Good taste.

Nathan Toups (30:29)

the Future. One of them hadn't seen it, but the other two had, and they were super excited. and I think that there's something about the fact that they're not staring at smartphones all the time, or that there's like

Carter (30:38)

interesting.

Nathan Toups (30:39)

there's just something to it. It also could be that just like movies were made to just be, you know, I'll watch an hour and a half of something fun.

And there's like a simplicity of this and there's no preaching and a bunch of other stuff. But I don't know. There I I think that there's an intuition here that kind of ties all this stuff together. And I I I think it's really important that we like really try to be mindful. And I I I think this is what ties in this like seven, eight, and nine together. this is where I kind of gone off on this whole like scree after we talk about

Carter (31:13)

Ha ha.

Nathan Toups (31:14)

from coincidence is that like

It's really easy to dial it in. I guess that this is my thesis. It's really easy to dial it in. And you really like you owe it to yourself, you owe it to your career, you owe it to your teammates to not. You know, when you realize to

Carter (31:27)

Is that I do mean dial it in

or phone it in?

Nathan Toups (31:30)

Wait, is there a difference?

Carter (31:33)

Yeah, dial in is like focus. Phone it in is like

Nathan Toups (31:36)

you're so this

is probably this is another one where, yeah, please risk me in the comments. I think I use those interchangeably, which is wrong.

Carter (31:44)

interest. Yeah,

I I just if you Google dial it in, it says means to adjust, fine tune, or focus on something. Until it's its absolute best. Yes. You have a responsibility to dial in, but you have a responsibility to not phone it in. These are really weird.

Nathan Toups (31:48)

It yeah, 'cause I say I'm dialed in. Yes. If I was saying I'm dialed in, you're right. But you're right. Phone it in. Yeah, no, you're right. To not phone it in. You have a res No,

no, no, this is good. This is good. So yeah, don't phone it in, right? Like that's the I've I've actually seen this, right? You you get a job that you don't love, you start phoning it in, and then it's hard to like come out of that. I think even in the like job interview process, they'll know. You're like, Hey, you've been here

Three years, but you look like you kinda phoned it in

Carter (32:20)

Yeah. I someone on Reddit

or I was reading Reddit and the experience dev subreddit. And just someone talking about like, hey, I work, I just joined a company, I work at startup where like everyone works. Like they work all the time. They work on evenings and weekends and and I don't want to do that. I want to work a nine to five. And what do I do? And and everyone just said, like, you just gotta quit. You gotta go find a new job. And and like I I think there's some truth to that. There's some truth to this idea of like you gotta find a place that's a good match for you and

I mean, I when you talk about phoning it in, like, yeah, sometimes you join the wrong place and you don't love the work and it's just and so you phone it in. But like I think phoning it in has never been more dangerous than now. You can get away with phoning it in these days just by, you know, having Claude generate a bunch of stuff. But I don't know, like I always get frustrated. Like one of my primary frustrations with Reddit is that like

There's so few places on the internet right now where if I say, like, I'm I like my job and I'd like to be better at it, like, where do you go? Right. Cause like I like the experience to have subreddits like, you know, there's like some gray beards there, and like, you know, some of the feedback is good. But like everyone there is just so freaking cynical about like, I just, I'm just doing this for the paycheck. Like, I don't care what happens as long as the paycheck clear is. I'm just like, I don't know. I I'm not that way. Like, I gotta care about where I work and what I'm doing.

But

you you just on my head, you were talking about your daughter. My my kids, we're watching the Marvel movies right now, like the kind of original MCU run, because he wanted to see the new one, Doomsday, that's coming out in December. And I was like, Great, we got all the time in the world, but then I found out they're re-releasing Endgame in theaters. And so like, well, like we gotta see that in at in late September. And so we've cut the we've cut it to the bone, like which movies you have to watch to be able to understand the endgame.

But it was pretty funny. My son is eight and he he's he's turning nine here soon and it's the first Iron Man, which I got I'm trying to like a little little quick on the fast forward button for some of the more risque parts, but like I didn't quite get it with it's like at the beginning he's got like the the very attractive vanity fair reporter and they like sleep together and my son who's just is not thinking that way, just like as the scene is happening, he's like, Whoa, Tony Stark has a waterfall in his house. I'm like, that's

like good

Nathan Toups (34:33)

Isn't that funny?

Carter (34:33)

good for you, son. Like

You can we'll worry about some of these other things later. we've been kind of jumping all over the place between the different chapters. but chapter eight, I kind of talk about this, but it's called Before the Project. and this is a lot of like not necessarily programming, but like teamwork and collaboration and like how do you set up a successful project? I like this idea that like they call it the requirements pit and that.

But

I'll say this is really interesting about this book is they they talk about like no one knows exactly what they want. And it's really interesting when you read some of these like more seminal programming textbooks, is like you can tell they were written by consultants because they're talking a lot about like your client or your customer, or like this idea that there's a very clear handoff from the business people to tell you what to build. But that's very different if you are.

You know, if you worked at like a thing like company, like often, like especially if you're in very technical product, like you're the one coming up with requirements. Or I'm at a startup these days and like you're I'm like hand in glove with any of the, you know, product owners. And most of the time, like I'm the product owner. but I I do like this idea that I was actually working with someone, I was doing a mock interview with them. Cause I I I coach through our, you know.

I'm on Leland and with you know I work at Leland, but I also coach you know, for anyone who like needs help and wants mock interviews. And so I was working with this one guy and he was doing a he was preparing for like a forward deployed engineer role and and and something that was helping him as he was like sh we were talking about how to talk about his past experience was this idea of like, you don't you're never telling the customer no.

Like, no, we can't build that. You are helping the customer discover what they actually want, right? And and through that process, you're gonna say no a lot of the time. but like I was saying, because like people are gonna say they want this or that, or they they want everything, you know, all these fine little details completely ironed out. Like what people really want is working software quickly. And so if you can deliver a working product to someone, they'll be okay if it doesn't have.

Some of these bells and whistles they they might have insisted they really cared about. I'm like, and that's what as you grow more senior in career, helping the stakeholders discover like, okay, what is it that you actually want? And how can I solve those problems for you? Like, that's what being a software engineer is. And it's that kind of whole slice of the domain that makes, you know, as we've kind of ranted out, coding agents for the past 30 minutes or so.

makes

me confident that the the field isn't going away because doing that slice of the work is still difficult and still critical to what it means to produce working software.

Nathan Toups (37:32)

Yeah, the the big thing here and it it kind of ties into something they brought up earlier in the book, which is that, you know, what we do is much more akin to gardening than it is to building, you know, a a a house end to end with a you know, like in the sense that when I'm building a house, I don't really want you to figure it out as you go, right? I I want an architecture plan, the city has to approve it, I have to get permits.

We have to plan out all the work that is happening in place. And you would think, well, software development kind of fits in the same model. Like, you know, houses are constructed this way all the time. You know, they have a three-month or six-month plan. They stay on budget, they stay on target. But the thing is that the type of things we're typically building, we don't know, we don't know what we want. We don't we have an idea that we think that the thing will be used this way.

But we also know that the market changes. We we we have to build this thing in a way that is adaptable and evolvable. And so, you know, they early on in the book, they bring it up this is much more like gardening, in which you have a pretty good idea of like where you're gonna grow things. But as things grow, you kind of change and adapt. Maybe this tree works quite well, right? And we're planning for the future. It's gonna be shady one day, but it's not shady yet. And so we'll kind of like cultivate it or we'll, you know, make a path and make it easier to get to certain to get to certain things as it grows.

And I think that ties really into this what happens in chapter eight. They have this section called Solving Impossible Puzzles. And I was just talking actually it's so funny because this came up before, again, talking to my daughter. She's been she's been asking a lot of great questions. I think this is a cool transition point between like between ten and twelve, right? Where I think a lot of like the conclusions I reached of who I am at my core, right, are probably pretty well formed by age twelve, right? I I I at least I know for myself, like

How I saw the world, how I see myself in the world. They're they're not that different than I was when I was 12. you know, obviously, experience and education have changed a lot of things, but who I am at my my essence, and I'm starting to see some of this sort of blossom. And so she was talking to me and she's asking me, like, not just dialing it in, like, how was work today, but like literally, what do you do? Like, explain to me how did you help your the the customer that you're working with? And I was talking to her and she goes,

You solve puzzles for a living. That's what she told me. And I would look I thought about

Carter (39:56)

That's sweet.

Nathan Toups (39:57)

it for a second and I was like, yeah, I solve puzzles. That's that's exactly what I do. I I I was like, people put interesting problems on my plate, or I find interesting problems even better, and I get to work on them. And I was like, I it feels I feel very lucky that I get to do that kind of stuff. If I feel like a it's a particularly challenging puzzle where I've worked really hard to get up to where I am, and I think I can solve it.

And we're not quite sure. And if I do, it actually is like really valuable for the business. Like that's a that's a cool spot to be in, because it means they're gonna pay me really well. I get to feel like I'm growing as a person. and again, this book frames this solving impossible puzzles section, which I think is really cool in that sense that like you know, and maybe we learn this with P versus NP in our graduate algorithms class. There are impossible puzzles. There are going to be questions

Carter (40:46)

Yes.

Nathan Toups (40:47)

that people ask you to solve that are not solvable.

Right? Like the traveling salesman problem, like, man, if we could solve this, we'll like s knock the

Carter (40:50)

Right, right. Yeah. Yeah.

Nathan Toups (40:55)

socks off of our competition. You're like, hate to break it to you. Not solvable.

Carter (40:59)

Yeah.

Nathan Toups (41:02)

but we can come up with an algorithm that actually gets us pretty close. Let's figure out, you know, what's a good enough salesman salesman algorithm that we can do in you know, polynomial time. and so these are the kind this is what our craft is, right? It's like

We're going to get problems. A lot of times there are problems on our plate are just, it's a weird puzzle and I have to like figure out how to solve it. And sometimes it's our job to be like, no, this is you've asked,

Carter (41:27)

Yeah.

Nathan Toups (41:28)

yeah, you've asked me to do the secret money printing machine. I can't do that, right?

Carter (41:33)

I when I lived in Orlando, in my in my faith, our congreg the clergy is all volunteer. And so the the pastor of our congregation, the bishop, he's i it's not his job. It was just like his he did it kind of basically part time. And so his real job, you know, I was good friends with him. He was he was the general manager for this place called Wild Florida. It was probably like an hour out of Orlando and it was basically like a big zoo kind of with and also like off-roading like

One of those, there's a lot of theme parks in the Orlando area that are just kind of like their their whole strategy is like someone will come and do five days at Disney World and then hopefully they'll do one day here. And so there's a lot of kind of like little parks like that. So he was the general manager for that place. and he thought it was I always talked to him about like how cool I thought his job was that like like he would travel for work. I'm like, Well, where where were you at? He's like, I was in Arkansas checking out some antelope, right? Or like some like

Wild, he's we had to go see like there were some hippos for sale. And we thought that maybe they would those would be good in the park. I'm like, that's crazy. but then when he would ask about my job, and and he thought it was so strange that my for my job that I did not know how to solve the problems I was dealing with every day. Like that was that was the whole thing. It's like a problem would show and like I'd have I have to think about it and be like, Well, how are we gonna fix this? Or like what's the solution here?

His job was just, there was always a lot going on, but he was never like staring at a hippo and like, how am I gonna buy this? Like, I don't know, right? Like it's either like we buy the hippo or we don't buy the hippo, or you know, like the whatever, like the the off-road vehicles, like one of them broke, and so okay, we're gonna have to, it's gonna be annoying. We're gonna have to hitch up to my truck and drag it back, and we're gonna have to pay a guy to fix it. But like at the end of the day, like every problem had a pretty distinct solution. And he found that very strange

Nathan Toups (43:23)

Right. Interesting.

Carter (43:25)

about my job.

and and I I I thought I the more I don't know, like I think there are a lot of jobs that are like that to where like, you know, the problem space is pretty undefined and you have to figure out like okay, what how exactly are we gonna come up with a solution here? a lot of kind of white collar knowledge work is like that, but you know, there is some white-color knowledge work that isn't like that. I don't know, I'm trying to think I'm I'm like going through the list of professions at my

I like our startup right now. And like I think more of it kind of falls into the domain of software engineering. But there certainly is something about software engineering that is particularly tricky. When like it, like your daughter said, we're solving puzzles.

Nathan Toups (44:06)

Yeah. It is I I don't think it's for everyone, right? And and maybe that maybe that's what when we get interested in something that is a craft, like if we're going back to the Cal Newport sort of idea that, hey, don't go for something you're passionate for. That's kind of putting cart before the horse. Get skilled in a craft. And then the passion can come out of this through, you know, being sort of a higher order you know, operation operating at a higher at a higher order. Actually, there's a

In the end of the impossible puzzles section, that they have a sort of fortune favors the prepared mind. And I think it was a it was a pasture quote. you know, the guy who created pasteurization. He said, when

Carter (44:51)

Yeah.

Nathan Toups (44:51)

it comes to observation, fortune favors the prepared mind. And again,

Carter (44:56)

Mm.

Nathan Toups (44:57)

that's the thesis of our podcast, right? It's the whole point is that

Carter (44:59)

Yes.

Nathan Toups (45:01)

hey, we can't see we can't firsthand see every pattern possible.

It would be cool if we did, but there's not enough time in in in our lives. So we should expose ourselves to the patterns recognized by experts in their field so that we can be prepared. Our mind can be prepared if something new comes to our plate and go, you know what? I saw this somewhere. I remember reading about this. Actually, you

Carter (45:24)

Right.

Nathan Toups (45:25)

know, it sounds logical, but you're gonna get super tangled up into it, right? Like this is where we're coming from. just like perfect example is like solving a Rubik's Cube. I am not

Carter (45:36)

Yeah. Right, right.

Nathan Toups (45:37)

talented at solving a Rubik's Cube, but I also understand it's an algorithm and that the people who do quite a good job are just very good at solving that algorithm very quickly. when I realized it was an algorithm, like I followed it a little bit and I like, yeah, I don't want to, I don't really like I'm impressed,

Carter (45:51)

Right, right.

Nathan Toups (45:51)

but I don't really like it's like it wasn't something I wanted to do. But at the same time, it's cool that, you know, s there are people who can glance at a Rubik's Cube and then project out the, you know, 20 moves that they need to do into the future and solve it.

Carter (46:07)

Right.

Nathan Toups (46:08)

they're a prepared mind, right? This is exactly the kind of thing where I look at it and go, you know, it's gonna take me a while to figure this out. Someone who's a prepared mind can come in and it's super easy and super impressive looking. And that's what I want to be. I want to be a good Rubik's Cube player when it comes to software engineering, right?

Carter (46:23)

I

yeah, I could solve a Rubik's Cube. It's like there's like two levels of being able to solve a Rubik's Cube. One is like the people who solve it in like three seconds or whatever. And

Nathan Toups (46:32)

Right.

Carter (46:32)

that is like you have to kind of view the cube super holistically. The other is like I think they ship it with these instructions now, but like there are certain algorithms where it's like, you know, okay, if you if you need to move this this square into this space without affecting any of like the crucial parts that you've already moved, then you do that. Like I could do that in like

Fifty seconds. but yeah.

Nathan Toups (46:54)

Right. And there was

period there was periods of time where like I had those down. I mean I could solve a Rubik's Cube. I haven't done it in a long time, so I'm sure I just

Carter (46:59)

Right.

Nathan Toups (47:00)

need to like brush up on the yeah, it's like twist, twist, back there, there, and it's like, cool, I've

Carter (47:03)

Right, right, yeah.

Nathan Toups (47:04)

moved it in position. But once you learn that, it's like you take something that looks impossible, right? Give it give an uneducated person a Rubik's Cube and it seems like an impossible task. This thing is impossibly mixed up. There's no way to get it back to the way it was. and then those of us who've learned these sort of p ways to sort of

Take a larger problem into smaller ones and go, okay, well, once I get all the corner pieces in place across the entire Rubik's cube, then I start working my way in towards the middle, right? You can kind of do these, these methods. and I think that the unsolved Rubik's Cube is such an unsettling thing for a lot of people that it does seem crazy that we are like, you know, we're getting, we're given Rubik's Cubes that don't have a necessarily known algorithm yet. but we also know that.

If we can fit it into certain patterns, it's probably Rubik's Cube like and I can probably figure out a way to do it so that I never have to think about it anymore. I write a pro computer program that like does it for me. in the same way that you could easily write a computer program to solve a Rubik's Cube faster than any human, you know, possible.

Carter (48:05)

Right. Man, I I might we talk about I wouldn't be better about like in our house, like having kind of meaningful quotes up on on the walls. And like one I've wanted for a while is from Abraham Lincoln's second inaugural, which is with malice towards none, with charity for all. And but like honestly, I might put up that that Louis Pasteur quote. I might paraphrase it to the point of fortune favors the prepared mind. just because it's

I I don't know, like it's what I find so offensive about so many like LLM hype peddlers. And I will go so far as to use the word offensive, which is this idea that like I have gained such a respect over my career, and I've mentioned this before, for mastering a craft, for doing the work, for putting in the effort to get really good at something. and and before and I wasn't like that when I was younger. I used to think like I just have such ineffable qualities that make me so special, and I'm just gonna be like

Gonna

outspecial everyone in the world. Like, no, like you gotta show up, you gotta do the work. I mean, I was actually just listening to an interview with Conan O'Brien last night where he was talking about like over his career, seeing that like it's like it's not an accident, like Bruce Springsteen is Bruce Springsteen. Like when Bruce Springsteen would come on late night with Conan O'Brien, he's like, he would show up early, he would practice, he would know the cameraman by names. Like he, you know, he would just like he would afterwards

Nathan Toups (49:27)

Wow.

Carter (49:30)

he would talk and like thank people for for his work. And he's like, Bruce Springstring had nothing to speak.

Prove by going on late night with Conan O'Brien, but he still did it. He talks about when like Tom Hanks would host SNL and he would be like there all week, like working hard to get his skits down and you know, pitching his his ideas. And he's just like, you know, he has a lot of respect for people who do the work. And I have gained that same respect. And so when I see people online being like, I made this amazing video, message me for the prompt. I'm like, message you for the prompt? I'm just like, you think that there's

That it just gets back to that idea of like, I am so special. Like I I I've been able to outthink all the competition just because I have this great little brain I've been gifted with. And I'm like, I don't know. Like I I think there certainly is something to be said for like thinking outside the box. And I I think there are people

Nathan Toups (50:21)

Right.

Carter (50:22)

who have been able to be kind of visionaries in our industry. I I I I mentioned Steve Jobs and Jeff Bezos, who are non-technical people, you know, funny enough, but

As people who not, I don't find them admirable, but I do find them impressive. And if you read about them, the amount of times they were just kind of right instinctually from the in terms of like Jeff Bezos thinking about e-commerce or Steve Jobs thinking about consumer technology, and like, and I really, really admire that. But these guys also worked really, really, really hard. and and so when we talk about like LLMs, like we know that history has rendered

certain professions obsolete. Like it used to be a job like you'd like shoot peas out of like a blow gun basically to like hit people's windows to like wake them up before alarm clocks happen. Right. Like we of course we don't have that job anymore, right? But like I actually just typed into Claude right now like what is the highest skill profession that was rendered totally obsolete by technological improvements? it said liner type operator. and then the second one they said was celestial navigator.

And that that's interesting, right? The idea that like we don't need that anymore, you know? okay. Well here d tell me.

Nathan Toups (51:35)

I'll push that back though. my father,

no, no. So my father is a retired Air Force pilot. So he was an Air Force pilot and then became a doctor. It's kind of a crazy career trajectory. But they had to all become proficient in celestial navigation

Carter (51:53)

interesting.

Nathan Toups (51:54)

because they might have to go radio off. And I mean, it sounds pretty

Carter (51:56)

Yeah, yeah.

Nathan Toups (51:57)

crazy. There could have been a nuclear war, right? He

Carter (52:00)

Right, right.

Nathan Toups (52:01)

was a B 52 pilot.

There were situations in which comms are completely out, in which they had to like turn off almost all electronics to to fly the plane as close to mechanical as possible. And he had to be able to navigate. He actually

Carter (52:15)

That's pretty neat.

Nathan Toups (52:16)

in his flight back, he had the there's like a tool that will tell you like you you you switch it to where you are what part of the year and that it'll give you the expected night sky at that point and then gives you all of the navigation parameters that you need. And he he was

quite good at it. And so

Carter (52:33)

wow.

Nathan Toups (52:34)

I mean again, you don't do this as a profession, but I these things don't disappear. There are definitely like I think that it's still a skill set that is valuable. And and this is where again, we get back into our Discord. Somebody we were talking about sort of the the worry of how much is learning to program really valuable anymore. And I pushed back saying, hey look again, using my daughter's an example once again, she's in

you know, doing pre algebra, things like this right now. And everything's by hand, right? She has to write her fact table, do equations, balance those equations, read a word problem, figure out, this is long division. I therefore need to be able to do long division by hand. And you could argue that we we have calculators. Like there's no reason for her to do long division by hand. There's no reason for her to, you know, you can plug in a thing into the calculator to see where it passes zero on a on a graphical scale and solve the problem for you.

But what we're teaching her is to think, right? We're teaching her to think mathematically. And yes, we will hand her a calculator when she gets into doing higher order things. She's gonna figure out the derivative or figure out the integral and do the more interesting sort of like bigger picture mathematical things and maybe not have to do the hand calculations. But and she will never appreciate what a calculator does unless she has to do it by hand. And I I still think that that's we still need to learn to program. You still need to learn.

how to do these things by hand. So even if you're getting an LLM to do it for you on your day job, it's we can't just outsource that. We can't outsource the thinking in the foundations.

Carter (54:10)

Yeah.

And like, you know, I I'm sure the AI Maximalist would be listening to this and be well, that's what you don't understand. It's such a it it's such a radically new technology. And like that's always where I've disagreed with the maximalists, which is that like I I don't disagree that this is a cool, new, fascinating technology, and that its impact on human society could rank up there with like the smartphone or the internet or electricity for crying out loud, right? Like

I think there's the potential for that. And heaven knows its impact is already greater than maybe, you know, other interesting technological developments like blockchain, which has use cases, and and is very well suited for a lot of those use cases, but is not kind of what the the block the

Nathan Toups (54:56)

Yeah.

Carter (54:57)

big blockchain hype guys back in the day were really they wanted it to be

Nathan Toups (55:00)

One hundred percent.

Carter (55:01)

a solution for everything. but I I I just like

If

you look at all of those previous revolutions in technology, like the answer is that like humans still have a role to play. Like, and

Nathan Toups (55:14)

Right.

Carter (55:15)

and that a lot of that hardly any jobs, if jobs truly went away, they went away over the course of like 40 years. And that really no high-skilled profession was ever rendered completely obsolete by technology. And again, just color me skeptical that software engineering is going to be the very first time and

All of human history? That that happens? I don't know. I mean, never say never, but

Nathan Toups (55:38)

Right. And

I think that you know, what we call it, the role that it may be may shift, right? I I think there's no question there. But I will say given enough giv given any long enough sufficiently peer long period of time, a group of thinking people will outperform a group of non thinking people. I'm not saying that a group of non thinking people who can take advantage of some arbitrage can't win. I

Carter (56:06)

Right,

right.

Nathan Toups (56:07)

Sometimes

you just play your cards right. But given enough time, a thinking person will always win. And I and I think this is the case that like a thinking person looks at their environment. They think about the world around them. They think about what opportunities are available. And that it inevitably leads to outcomes that a non-thinking person will not be prepared for. And so I don't stop thinking. That's the that and I I think if pragmatic engineering

The if the pragmatic programming book tells us anything. And I think that's really where we round out chapter nine. I think this is a good through through line here. Is that you know,

The way that you solve problems, the way that you share rewards and risks, the you they they get into these whole things on like delighting your users, on taking pride in your work. Every one of these requires you to think about the situation. Every one of these things says, let me look at the world around me. What's my role here? Am I actually solving high-leverage real problems? Am I using the tools that are correct? Am I well educated and

Way that I'm approaching this? Am I paying attention to my peers and seeing that they're categorically doing a better job than me? Or are they doing a worse job and I should avoid it? None of those are let an LLM dial it in and tell you, you know, and I

Carter (57:28)

Yeah.

Nathan Toups (57:30)

don't think that part changes, right? I I think that you have to do that uncomfortable work. You have to go in and you to think. and that's more important than ever. I it's it's completely nuts, actually, to see what the AI sort of unhinged AI folks are.

kind of telling you like, Hey, you don't have to think anymore. And like, are you insane?

Carter (57:51)

Yeah, the the kind of last thing they say before they they go through the postface is is this idea of like have pride in your work. They call it pride and prejudice, right? Like

Nathan Toups (57:59)

Right.

Carter (58:00)

but basically say but your pride shouldn't they call it curdle into territorial code ownership. and I I really do believe in having pride in your work. It's tough because I believe in having private pride in your work. I also believe in you need to find the meaningful halfway points and say, This is good enough.

you know, w this is this does what we needed to do and and we got to move on now. And and I I think about some of the things I've built over the say the past two months since that's kind of post-migration. Yeah, I even think about it with the migration, right? We're like, I'm really proud of that migration. It got all basically everything we wanted to done. I I told my my kind of product guy I was working with, he was like trying to fight some battles and I'm and him I like I'm the tech lead on some of these initiatives and he's like, I just feel like I have a lot of battles to fight. I'm like if you ever need like

To fight one fewer battle, just like tell them that it's the way that I want to do it. And they can pick they can take it up with me. I'm like, because I have to fight a lot fewer battles than you. I said, and I have to fight no technical battles because I won them all, right? With the migration. and

Nathan Toups (59:00)

Ha ha

Carter (59:01)

it's like, I I I like and so I look at the migration. I look at like the some of these projects I've shipped lately. I'm like, I am proud of them, but with every single thing we've done, I can look back and be like, I wish I could have done this a little better. I wish we could have done this differently, right? I wish.

You know, I think

Nathan Toups (59:16)

Yeah.

Carter (59:17)

this isn't as as resilient as I'd like it to be. And so it's like, what's the trade-off between having pride in your work and and being perhaps a perfectionist? I don't know.

Nathan Toups (59:27)

Right.

Carter (59:28)

but I but I I do think if you define pride just like the baseline, caring about what you do, wanting to be good at it, and wanting it to work for your customers, like then yeah, I I do have that pride. And you know, I and I think there are too many engineers who don't have that.

I hope few none of you are listening to this podcast. Well, I I guess I hope you're listening to the podcast if you're in that way, in that sentence. I hope you change your ways. But my guess is that if you're listening to this podcast, you are you fall into that category, people we talk about of people who are good at their jobs or would like to be better at their jobs and and do take pride in their work. So hey, if that's you, congratulations. Like I, you know, you're killing it. Well, I think that takes us about through the end of the book. I I think some of our hot takes, Nathan, I I

Do you want to share yours? I I like your phrasing here.

Nathan Toups (1:00:15)

A little little spicy, but yeah, this

is a this is a collection of really great blog post wisdom at textbook prices. That's what you know. I

Carter (1:00:22)

Ha ha ha.

Nathan Toups (1:00:24)

was a little offended when I had to I bought the audiobook and the and the physical copy, or not the I the the Kindle version, and I was like, wow, this is like forty-five dollars or whatever.

Carter (1:00:35)

Right, right.

Nathan Toups (1:00:36)

and yeah, I mean again, I think it it's a it's a great book. The audiobooks cheaper, so I would say

And it works quite well. This actually is a really great audiobook. You there are code examples, but you can skip them, in my opinion. And so, yeah, that's that's my hot take, though. It's just, you know.

Carter (1:00:58)

I you know, it's sometimes I I'll say that's the one thing out of this podcast that there's just no correlation. There is no correlation between price of a book and how good it is. And and that like they I think this book was $45. I really enjoyed this book, right? But like a philosophy of software design is like eight dollars or something like that. And like, do I think this book is more value than a philosophy of software design? Probably not, but that really more speaks to just how highly I I think of a philosophy of software design. And so

It's like there there's absolutely no correlation between price and and and quality.

Nathan Toups (1:01:33)

If if you've got a continued education budget at your work though, I totally think it's worth Yeah, exactly.

Carter (1:01:38)

Buy this 100. It's

a great book. And again, I would recommend this as you know to basically anyone. do you feel the same?

Nathan Toups (1:01:47)

Yeah, there's a general I'm I think this'll easily get in our top ten books to recommend list. Like if if we did that. It it's just it's one of those good

Carter (1:01:54)

Yeah.

Nathan Toups (1:01:55)

foundational books. You don't have to be a domain expert. Like I said in

Carter (1:01:58)

Right, right.

Nathan Toups (1:01:58)

the past, it's kind of like snacking from the buffet, right? yeah. This isn't this

Carter (1:02:02)

Yeah. And if any?

Nathan Toups (1:02:05)

isn't yeah, this isn't a high end steak restaurant.

Carter (1:02:08)

Right.

And if anything, is a very interesting historical snapshot to considering the twentieth anniversary was written in twenty nineteen. And so it's got like this it reflects this wisdom accumulated over the years by these very accomplished programmers, but right before coding agents kind of really adjusted the field. So very, very interesting book. as far as what we're gonna do differently in a I'd love, yeah.

Nathan Toups (1:02:30)

Hopefully we get a hopefully we get a opportunity to eat get one or both of

them on the podcast 'cause this is exactly what we'll expand upon and you know, see if they're gonna work on the third edition. We'll see.

Carter (1:02:40)

Right, right. Okay, as far as what we're gonna do definitely in our career, I didn't write anything down and I thought I'd get something over the course of this podcast. I don't know, what do you what do you got, Nathan?

Nathan Toups (1:02:52)

Yeah, so we we skimmed over it, but it was actually one of my favorite sections in chapter seven of talking about property-based testing, which is something I was kind of a new concept. It's not quite it it it was it was more about sort of like testing the emergent properties of stuff and and and generating synthetic data to kind of test resilient do resiliency testing of your of your code. I might be butchering that. It's a new concept to me, but I wanted to

spend more time looking into property based testing. Just kind of l seemed interesting.

Carter (1:03:24)

Yeah. I mean as far as I go, like I feel like I gotta write something down because we usually do our I don't know. I'm I'm gonna I'm gonna I'll have to get back to you on this. Sorry, folks. but I I did enjoy this

Nathan Toups (1:03:37)

It's all good.

Carter (1:03:38)

book. Okay, next week, we are revisiting team topologies, aren't we?

Nathan Toups (1:03:43)

Yep, that's what we have. we've never done this before, so I'm not a hundred percent sure of the format. but yeah, we will be revisiting. There's a second edition and I think what we're gonna try to do is sort out the diff between those and read the stuff that's new and kind of skim over the stuff that we've read before.

Carter (1:04:01)

And yeah. okay, great. I'm excited. And this is the part of the podcast where my I I lose my brain. Marshmallow. I gotta I'm gonna cut this part out. We haven't had a marshmallow in a while. Okay. marshmallow. Three, two, one, go. Okay, that wraps us up for this week. thanks everyone for listening. You can always find us on bookcorperflow.io. We're at on Twitter at Book Worldflow Pod. You can find me on Twitter at Carter Morgan, find Nathan and his work with functionally imperative at

Well, no, that's your old my goodness, marshmallow. We're doing this again. Okay. Three, two,

Nathan Toups (1:04:34)

It's all good.

Carter (1:04:34)

one. Okay. that wraps us up for this week, folks. you can find us on Twitter at BookoverflowPod. I'm on Twitter at Carter Morgan. The website is bookoverflow.io, and you can contact us at contact at bookoverflow.io and Nathan and the work with his consulting agency, RohoRoboto, at or at rojo roboto.com. Thanks, everyone. We'll see you later.