Two Years of Book Overflow!

Carter (00:06)

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

Nathan Toups (00:18)

Doing great. Hey everybody.

Carter (00:20)

We got a special episode for you today. this is our two year anniversary. I don't do you know the exact I'm actually seeing it right here. June twelfth is the day the the the first two episodes launched. June thirteenth, we launched another one. So a bit past the two year mark. and before we get into kind of what the activity of the day is and and what we're gonna do, it's worth reflecting. I mean, two years, Nathan. How do you feel?

Nathan Toups (00:28)

June twelfth.

You know, I'm living in a different country. both of us are finished with grad school. You've got another child on the way. There's like a lot of life that was happening over the last two years. Yeah. Yeah.

Carter (00:56)

That's that's true. We both changed jobs. You switched to full

time consulting. I went from big tech to a a startup. So it it's it's been a while, but I we wanted to take a moment to thank the audience. We're thrilled for all of our supporters. We're thrilled that you guys provide what it takes to keep making this podcast. I think a couple episodes out I I put out a call to connect with us on LinkedIn. And I know I've gotten a lot of connections from

Nathan Toups (01:05)

Yeah.

Carter (01:26)

folks and and that's been really exciting. It's always fun to kind of put like a a face to the listeners. and yeah we we we just couldn't be more thrilled at how people have responded to this and we just kind of want to reflect on the past two years. We're gonna do it in hopefully a fun way, which is you know we say at the top of every episode where this is we read technical books every week to improve our craft.

So we thought, you know what? Let's go through every book we've ever read. And we're not gonna spend too much time on each of them, but we just want to kind of say the one thing from the book that sticks out in our mind the most. The thought being here that, like, hey, for every one of these books, we spent at least a week of our lives reading it. And so hopefully there's something from it that we think is still influencing us today. And I want to set kind of that bar. Like, this is not like can you remember and any random factoid from the book? But was there anything in this book?

You feel like did shape how you think as a software engineer. yeah. so, and then if you can't think of any of that, maybe you get a share random factoid. I don't know. but with that, let's go ahead and get started because we've got like 40 books to go through. I don't know the exact number of books we've read. What I do know is we have done 120 episodes, and I believe 90 of those are book episodes, and then 30 are interviews, and then I think it's something like.

Nathan Toups (02:23)

I like that. That's good framing. Yeah.

Carter (02:48)

Forty seven books? I don't know. we'll figure out by the end of the episode.

Nathan Toups (02:50)

Yeah. That's that sounds

that sounds like the right ballpark. Something close to that.

Carter (02:55)

All right. Well, let's get started. this is this is embarrassing. this is episode one: The Practice of Programming by Brian Kernahan and Rob Pike. fun fact: this is actually the second book we ever read. A Philosophy of Software Design was the first episode we ever recorded. and I gotta be honest with this one, I can't remember anything. I I I love Brian Kernahan. I love Brian Kernahan. He's been on the podcast twice. I can't remember.

Nathan Toups (03:16)

Yeah.

Carter (03:23)

anything from this book, so okay, okay, okay. Save us. Yeah.

Nathan Toups (03:24)

I so I rem I'll I'll I'll I'll t I'll step up on this one because I feel like we're gonna be doing

this back and forth a bit. I remember this one because this is one of those books before the podcast I never finished. And I'm a huge fan of Rob Pike because I'm a big Go programmer. And what I remember from this book was that a lot of the the cores of the ideas of what good programming looks like ended up coming from this book and going into Go. I also remember that there's some LD stuff, like there was no good CSV parser. It's just kind of like a hot take I remember.

Carter (03:52)

Okay, yeah,

yeah, I remember that. Yeah.

Nathan Toups (03:53)

that Brian Curnahan like brought up in

in the interview we had with him. but it was be it was something out of this book. And I remember it was one of those where we started reading these books from like twenty plus years ago, where some things are timeless and some things are super dated. And we knew that this was gonna be something that came up. And I think we'll see this theme as we go forward.

Carter (04:12)

Yeah. Okay. Well, I can save myself with the second book we read. Well, first book we ever read, second episode of Philosophy of Software Design. design it twice. I I think for me as an engineer, there and this has actually been something we've been talking a lot about, like with AI usage. Like there are some things you can only know about a system when you get in and start building it. And I think

Nathan Toups (04:23)

Yeah.

Carter (04:39)

And I think this is actually one of the really exciting things about large language models is it's a lot less effort these days to design something twice. And so I think I used to kind of feel like if I didn't get right the first time, that was a sign I was a bad engineer. And this kind of gave me the permission to to design things twice if if I feel like I learned something valuable in the first pass that should be implemented in a second pass.

Nathan Toups (05:06)

Yeah, yeah. This this book again, it's held up. It's funny that this was the actual first book we've read. It's been cited, I think, the most across all the books that we've read as well. And it wasn't written that long ago. you know? So yeah, that huge impact. It still has a huge impact. I still come back to it. I think I even have some of the principles in my in my like claude.md file. I'm not joking. Like they're like straight up use these principles that are in there.

Carter (05:15)

I think so.

Yeah, yeah.

That's awesome.

Twenty eighteen is its publishing date. any anything from you for this one or or do you kind of agree with design it twice?

Nathan Toups (05:41)

Yeah, no, I liked obviously design it twice. encapsulating complexity and his approach to it, which is not necessarily object-oriented, though object-oriented stuff works with it. I really like his idea of interface design. Also, like, shoot, I'm gonna mix it up, but factoring errors out of existence, right? Or making it so that the error state is some default behavior, that you don't necessarily have to like trickle that up all the way to the user. there's some really powerful ideas in there.

Carter (06:05)

Right.

Nathan Toups (06:11)

And and again, guests, you know, guests on the show. I think this book is even richer because we got to talk to John Osterhout and even got to frame it in the his dislike of T D D and some of the critique that he had. the fact that he got to talk to Uncle Bob and it even improved Uncle Bob's newer revision of Clean Code is just cool. Like it's our little like impact in the universe. I'm like so excited that we read that book.

Carter (06:18)

Totally.

Yeah.

Well, let's talk about our third book, Refactoring, Improving the Design of the Existing Code by Martin Fowler. For me, the concept that if you do refactoring properly, you you should be able to stop at any point. I I I think I I kind of thought of refactoring as like, okay, I gotta carve up out a chunk of time, and if you can't finish it, then all that time was wasted.

I liked his idea that like refactoring is something where you should you can just clean up a little bit and then because the idea behind refactoring is that you're changing the design of the code but without modifying the actual output, that you should just be able to do it in little bit little chunks and call it a day at any given point. I think, yeah, help me reframe what refactoring is.

Nathan Toups (07:28)

Yeah, I I think I was over I think and there's a lot of stuff that we learn from these books is overloading words, especially if words become buzzwords. I think everyone uses refactoring as a catch-all for rewriting code. And refactoring in in Fowler's definition is a very narrowly scoped thing. And I I think anytime I I violate that boundary, I'm sad. So I even this morning I I just did some refactoring, true refactoring on rohrobato.com.

Carter (07:34)

Yes. Yes.

Yeah.

Nathan Toups (07:56)

Where I was like, I was trying to do some performance optimizations, some better use of Next.js and React. And I wanted no functional changes, I wanted no UI changes, but I had very clear ideas of like how I wanted to restructure the code with an agent, like using like ultra code or whatever. And it was awesome. It like I ended up stacking up like five commits that were very easy for me to review and push it through. And I and so even though I'm using, you know, cutting edge tools, I'm still using Martin Fowler's principles.

Carter (08:18)

Awesome. Yeah.

Well, let's talk about what is ChatGBT doing and why does it work by Stephen Wolfram. I'll say both with Martin Fowler and Stephen Wolfram. They've both been on the podcast. They were among our har some of the harder guests to get on the podcast. Not because like they were just busy guys and it I was it was very cool when we b got them both on. Martin Fowler in particular said, I don't go on anything unless I like the content. And he listened to a few of our episodes and was like, Yeah, I like what you guys are doing, so I'll come on. So validating early.

Nathan Toups (08:38)

Right.

Mm-hmm.

And in

by a few of the episodes, I mean I think that you know, we'd not published that much. We ha I guess we at that point we had probably covered some ThoughtWorks stuff at that point, but Yeah.

Carter (08:59)

Yeah, I know. Wait. Yeah. We had done like seven or something.

I remember being in the airport for a business trip and like I had sent out some of these emails like the day before, and I was like, it was like to our first seven authors, and I was like, Well, we'll we'll hope that maybe one responds. and I was like in the airport the day later, like messaging you and like, So three have already said they'll come on the podcast. Like, this is great. why why don't you tell us what is Chat GBT doing and why does it work? You got anything from this, Nathan?

Nathan Toups (09:27)

I remember almost no details from this one other than s smart people writing really smart books in a way that I could like kind of understand was really eye-opening. And I I appreciated that, you know, what felt like a series of blog posts was actually a really well-structured breakdown. And it in the in the recentness of reading this book, I think I had I felt like I had a pretty good understanding of like thinking through the problem, but I I don't remember any of the details.

At all anymore.

Carter (09:57)

You you

might be not giving yourself enough credit there because since then you gotta remember we read this in June 17th, 2024. So ChatGPT is only maybe 18 months old at this point. and if that might it might have been less than a year old. and I think there was now we all understand a little better like how LLMs actually work. But I remember this kind of being the first, like just describing like the next token prediction mechanism.

Nathan Toups (10:19)

Mm-hmm.

Carter (10:25)

Describing some of the science, describing the concept of temperature, which I feel like is still not understood very well today. That like we we do bake a degree of randomness into LLMs, and that's what makes them so powerful. so I mean, to me, that that I I've thought about that for a while, and this this book taught me those concepts.

Nathan Toups (10:25)

Yeah. Yep.

No, you're right. You're right. I think I think that I think it did give me again vocabulary and a framing that has been foundational. And I I guess I kind of just forgot that this is still a lot of hidden knowledge. I was just giving some coaching to someone recently doing s some job search, job interview, and she brought up temperature and I was like, like I we're good. I know she's like she's I put the temperature to zero so that it'd be more deterministic. And I was like, I I understand exactly.

Carter (11:11)

Yeah.

Yeah. well, let's get into our we got the this is our first three parter and the winner of Book Overflow's March Madness bracket last year, Fundamentals of Software Architecture by Mark Richards and Neil Ford. So we better remember something from this. I think I could cite a lot from this, but just thinking about okay, what what's stood out to me and has influenced my career the most is the whole last third, which is all about.

Nathan Toups (11:16)

What you talking about?

yeah.

Carter (11:44)

The need to sell your architectural vision to both technical and non-technical stakeholders. I I think it really resonated with me this idea that like you're never gonna need to quit selling. You're always gonna have to prove yourself to some degree. And and to an extent, like you don't wanna work at a place where it's just like, that guy, whatever he says, goes. and so I I thought I I like in a book that's about the fundamentals of software architecture that they consider this the the ability to communicate your vision.

A fundamental. I think that's an underappreciated aspect of software engineering sometimes.

Nathan Toups (12:18)

Yeah. A couple other takeaways that I remember coming out of this was not living in an ivory tower, meaning that you should be in the code, working with the teams, like living with the design that you've that you've advocated and built for. And that you should be preempting the needs of what's going on. So that you should you should be really kind of living a couple of steps ahead of like.

Carter (12:26)

Yes.

Nathan Toups (12:43)

trying to see where is the next area of stress cracks going to be, where where are the constraints to to the design that are going into place. I think it was also they make a really good advocate for like the role of an ADR, right? Of an architectural design document, for decision making and letting that be in the version control or in some place in which, you know, you can sort of evolve these decisions that were made.

To the rest of the organization, and that they don't have to have this huge RFC review process. They can actually just be, here's a decision, you know, here here's who talked about it. So that I think what was the there was a thing that they talked about. It was like the Groundhog Day phenomenon. I remember this now. So the Groundhog Day thing was you make a decision in like Slack or something, except not everybody sees it. It's not recorded anywhere. And so you end up ha coming back to this over and over and over again.

Carter (13:37)

Right.

Nathan Toups (13:39)

Like Groundhog Day, where you just it's like, why is this decision? I thought we made this decision three weeks ago. Tom wasn't on the call, you know? And it's just like, don't do that. If you make a decision, have a place to record decisions, put it there. I've been using anytime I I stick to this pattern, I'm always happy. So that that was another big thing that came away from that.

Carter (13:59)

there we go.

next up, our I was gonna say our first book from Uncle Bob. I think the only one we've read, although we do have another one of us on the calendar. Clean Coder by Uncle Bob. I guess Robert, Uncle Bob Martin. I liked this is a book I I remember really enjoying reading. It's it's a lot of stories. and I think we're familiar with like Uncle Bob and his programming. I don't know, if dogma might be too strong of a word, but

At any rate, I thought it was interesting to learn more about Uncle Bob the Man. And this I he talks about this idea that, like, okay, are you a professional? And he talks about this kind of first company he worked at. I don't even remember the exact story, but basically, like he found out that like one of the partners he had been working with, like one of the non business partners, was pretty dismissive of engineering because he was just like, I think they they needed something done. And he's like, accounting will get it.

He's like, he's like, do you know accounting? We'll get it done. He's like, well, they're professionals. It's like you guys aren't. And that made Uncle Bob mad or mad. But then he was like, wait a minute, maybe he's right. Maybe maybe he's right that we aren't professionals. and so we that's what the book is really all about is like this idea of, are you a professional? And and you know, there's some things like I think in in classic Uncle Bob fashion, it's like full of hot takes. But one of the hot takes is that like you should never, ever, ever provide a deadline.

Or like a an es an estimate. again, I think like that's probably too hot a take, but you know, that's what we're all reading on Uncle Bob for as his hot take. So there's this overarching idea of like what does it mean to be a professional? I thought was interesting.

Nathan Toups (15:36)

Yeah. I yeah,

it was funny. And and anytime I hear like I'm a professional, I still think about arrested development. There's like this there's this this like, yes, Wayne Jarvis is a he's a professional and yeah, he'll like it's great. please go check that out if you haven't. But the the the thing I do remember is that yeah, like I was notoriously bad about the mixing of a you know, committing to a deadline and then giving an estimate.

Carter (15:44)

Yeah. Wayne Jarvis. Yeah.

yeah.

Nathan Toups (16:06)

Right. Because I think in in engineering culture, it's very easy to kind of be like, yeah, I think it'll take this long. And if a business tries to make a decision on that and then your s timelines slip. I mean, we see this in Mythical Man Month and other things like this, which again I think is also a book about professionalism in a lot of ways. yeah, you gotta step it up. Like if you want to justify your high income and you want to have people rely on you, you really do need to think about that aspect.

Carter (16:06)

Yeah, right, right.

Mm-hmm.

Nathan Toups (16:31)

I also, I think this was a good glimpse of the fact that I understand, even if I don't agree with necessarily everything Uncle Bob says, he's very charismatic and he's a very good writer. Like this book is well written. I just remember thinking, this is easy to get from cover to cover, which of course, exactly. It was like we're very biased to that because we are reading books cover to cover, and we know that not all books are appropriate for cover to cover. actually, I think that'll get into our

Carter (16:45)

told I read this on a plane. Yeah.

Nathan Toups (16:57)

our next episode, or at least the next book that we covered, which is not an easy one to read cover to cover.

Carter (17:02)

Yeah, and why don't you go first in this one? This is Working Effectively with Legacy Code by Michael Feathers.

Nathan Toups (17:06)

Working

effectively with Legacy Code again, much cited, much cited book, excellent guest. Michael Feathers was awesome to have one. And I think the big takeaway that I remembered was legacy code is code that has no test coverage, right? Or like no nobody understands how it actually behaves, right? Like that that's kind of like a kind of broad definition that he kind of brings up in there that you don't understand, that you might be scared about.

Carter (17:23)

Yeah, yeah.

Nathan Toups (17:33)

I liked this as a complement to refactoring because I I remember thinking of the framing because that was the recent book that we had read. of hey, you don't have a greenfield project, you don't have necessarily con code control over the code base, you maybe you don't even like the way that things are structured. How do you even get started? How do you start pulling this thing apart and making taking ownership? And it it's just it's

Each little section of the book is like very self-contained. I think it'd be an excellent reference book to have on your wall. and you can just pick up that part and put it away. You don't need to read it cover to cover. It's actually kind of difficult to read cover to cover from what I remember.

Carter (18:11)

Yeah, I this is one of the books that actually has affected me the most. and it from the just the very simple idea that code should not be hard to change. It should not be scary to work with. And if code is hard to change and scary to work with, then that is a sign that it's poorly designed. and I think I kind of thought that like that was a sign of quote unquote good engineering. Like, some wise man before me came and

Wrote all of this code and it's load bearing. And if only I were smart enough to understand what it means, like, not really. and if you find that code is hard to change or scary to work with, you can do the work to make that not the case. And that's what this whole book is about. so I I really like this and I really like Michael Feathers. He's been very kind to us and was also a guest on the podcast.

Carter (19:00)

Okay. Next up is Web Scalability for Startup Engineers by Artura Edgemont. I'm gonna have to punt on this. I don't remember a ton from this. Like I remember some of the well, I okay. I'll give myself a pass here. It's hard to say like if this was something I learned from the book or if I just kind of knew this, like load balancers. Like coming

Nathan Toups (19:21)

Yeah, I remember.

Carter (19:24)

and it also needs to load balancers. I did really like this book, but I can't tell you a ton from it.

Nathan Toups (19:34)

Yeah. The the the impression what reminded me was that you're building something different when you're an early stage startup and that you're gonna transition a couple of times to like what's appropriate. I think this was this had some really good stories on not doing premature optimization. You know, like don't have like perfect fault tolerance, high availability when you have like two customers, right? and that that's a really big wasted effort that you're trying to move fast.

Carter (19:57)

Right, right.

Nathan Toups (20:02)

And but at the same time though, knowing when to start investing in those is is important. And I and I just kind of remember that this book had it hit touched on this some topics. I also remember this, I think there's this weird spot of specificity. We always try to figure out like what's a good general evergreen book that we need. And some books age poorly. And I do remember that the kind of what he fixates on in this book was very important in like the 2010s, I think, when this

Carter (20:26)

Yeah.

Nathan Toups (20:32)

Book came out. and some of the a lot of these had been like solved by software as service companies or platform as a service companies. You know, vers things like Vercel did not exist, right? So you had to kind of come up with some scrappy whatever. And and so I I think it would be really cool to see an updated version of this. You know, a handbook for first-time founders or something on like what you should focus on and what you shouldn't.

Carter (20:43)

Right. Right.

It's a pamphlet. It says just use Vercel. Says raise it raise a bunch of money so you can give it all to Vercel. Right, right.

Nathan Toups (21:01)

Yeah, exactly. Or when to not use Vercel, right? Like what what's

gonna what's gonna paint you into a corner with Vercel? I think those kind of things of like what are the trade offs? Are you doing a consumer facing app where no one really cares and you're really trying to get time to market and Vercel's perfect? Or are you trying to change the way that software engineers fundamentally do some sort of workflow? And as soon as you get data heavy, you're gonna fall over and be, you know, paying paying crazy bills into oblivion using Vercel. And I I think that that something like that would be

Carter (21:14)

Right.

Nathan Toups (21:30)

Super cool. next book. This one was interesting because this was actually the first book recommendation we took from an a guest. This is Recoding, yeah, Recoding America by Jen is it Jennifer Paul Polka? a little bit of a different book for us. I think it was the first time we did something that's sort of more, you know, tell all narrative type story. It was not a technical book. But I also thought it was like really eye-opening to see.

Carter (21:39)

yeah, yeah.

Paulka. Yeah, yeah.

Nathan Toups (22:00)

Two things. Number one, a glimpse of how crazy government software can be, especially legacy government software. And then what happens if you're like bright-eyed and bushy-tailed and you believe that government software can be good? And like what could you do? What could you do with this? And I just it was a whole world that I've never thought about before. And I remember number one being like, Brian Kernahan has awesome book recommendations. And number two, like, I never would have read this book if if he hadn't recommended it.

Carter (22:27)

Yeah, my my biggest takeaway here was that government software is bad because when you're building software for the government, you're evaluated on like, did you complete the checklist? Did you follow all standard procedures? You're not evaluated on does the software do its job? Right. and really, like I know Agile has, you know, some people love Agile, some people hate Agile. We have read the Agile Manifesto, and the idea behind that is like strip everything away that doesn't matter and just get

Nathan Toups (22:37)

Right.

Carter (22:55)

Get to the basics of delivering working units of software. And this kind of gets to the idea of like John Osterhoop's design it twice, which is you can't really know some things until you actually start building. and and the way we build our software and our government, and when I say our the the American government, I know we have international listeners, although I you know let us know is your is your country's software awesome? I'd be surprised if it was. does not reward that process of discovery. It rewards following the checklist.

Nathan Toups (23:01)

Mm-hmm.

Carter (23:23)

So yeah, really, really interesting book there. I'm sad we've never been able to get around the podcast. Okay, next up Building Evolutionary Architectures by Neil Ford, Rebecca Parsons. we just have the last name here. Kua. I think it's Patrick Kua, but I don't remember. And promote, yeah, yeah. Promote Satalage. three of the four guests of the podcast. All right, Nathan. I think I know what you're gonna say for this, but I wanna I wanna see how I got it right.

Nathan Toups (23:37)

It was Patrick, yeah.

No, I now I feel like I'm on the spot. yeah, fitness functions. Is that what is that what so yeah, this one is and I'm like a fitness function maximalist at this point, but I I refer to this, I think I refer to this book the most, actually. just because I especially as a consultant, a lot of times what we're trying to do is take an existing system and make it easier to change, right?

Carter (23:54)

Fitness functions. Yeah, yeah. And I'll I'll piggyback off you.

Nathan Toups (24:16)

And is if you're doing software architecture work, I'm an outsider working with existing teams, making it so that we can evolve a system over time. So we give ourselves permission. You a lot of times we'll talk about crawl block run, putting these things in place. And a lot of it is making sure that it does the system behave the way we expect it to, right? That's the idea of a fitness function. Rebecca Parsons, who was all a guest on the show, and honestly, I wish that she was more of a voice in the community because she's

Carter (24:43)

Yeah.

Nathan Toups (24:44)

She is from that background of doing you know, sort of evolutionary AI type system stuff and are are the these evolutionary functions, right? These all kind of like what you think of Conway's game of life. There's much more sophisticated versions of of that type of thing. and that perspective overlaid on top of infrastructure and software architecture is such a cool way of framing things. And so yeah, I I refer back to that book all the time. And yeah, it's a it's an awesome one.

What about you?

Carter (25:15)

Now plus one, everything there, fitness functions. I think it's a I think it's a really interesting way. I I wish I were better about doing that in software development. But I think the idea of like, hey, we're gonna have one or a vr a variety of things we care about, we're gonna have an objective way to evaluate them. And as we continue building, if we find that what we're building is deviating from the these criteria we said we've cared about, like that's that's a sign that we need to change course. So

Big fan of this book. Looks Good to Me by Adrian Braganza. I feel bad because we love Adrian. I remember really enjoying this book. this is another one that's like a lot of reference material, but I I can't remember any specific pieces of advice here. And and I think that's more on me because I have not been fo like and we should mention, right, that like not being able to remember anything for this book doesn't necessarily mean like, well, the book wasn't memorable. It also just might mean that we haven't been focusing on these areas in our career.

And so they haven't we haven't been kind like cementing those like knowledge pathways in our brain. And it also doesn't mean that we shouldn't be focusing on these areas in our career because I I have been thinking a lot about pull requests. yeah, for anyone curious, if you've been following the podcast, you have heard about the migration that I've been leading at our company. it is done. We finished it. we will be ceremoniously turning off the old system in a couple of days. We're just leaving it running for a while, just to be extra super sure. But

Nathan Toups (26:33)

Yeah.

Carter (26:44)

At this point, we're pretty darn sure. but anyhow, one of the we've got into a bad habit over the course of this migration of like essentially rubber stamping a lot of PRs. Like we've just been generating a lot of code with Claude, which I have not loved, but we have been okay with it because like look, we didn't write the old system either, right? And at least this new system, you know, the performance is like five X better and it has full test coverage and the architecture.

architectural bounds we put around Claude's code generation, I believe, have led to easier to read code with that that is is less tightly coupled. And so, but I've been clear with the team. I'm like our our pull request hygiene is bad and we need to be better about actually reviewing. We need to not be submitting regular 50 file pull requests. and so I I should I should take a look at yeah. I should take a look at this book again because I've been thinking about this a lot and and we could use some some good pull request advice on my team.

Nathan Toups (27:35)

Yeah, it'll bite you.

Yeah. I what I remember from this book is how much there was a focus on the social contract around things. And I do think that that's very company specific. Like figuring out where the bottlenecks are, figuring out where those like, are we are we write down what your standards are? Are you living up to these standards? I remember this sort of like there's really good guidance on how to define that. It sounds like going back and taking a gander, it would probably be really great for your team. and and

Carter (28:09)

I think so. Yeah. Okay.

Nathan Toups (28:12)

And that's another thing I I

think is worth bringing up is that these books, you know, once you kind of have this in your you know, indexed in your mind, the this is what's so great about technical books. You just go back and flip through it and figure out like, yeah, I I need to spend some time with this idea.

Carter (28:19)

Right.

Yeah, as we've read these, I don't think there are any of these that I'm like, man, that was a waste of time. Like we shouldn't have read that. and and when we do get to a book like Looks Good to Me and I don't remember a ton from it, like, yeah, I I'm like, dang it, like I don't think that says something about Adrian's work. I think that says something about me not prioritizing pull request etiquette on my team. And so, you know, it's good signal.

Nathan Toups (28:32)

Yeah.

Carter (28:50)

you know, this is one of our favorites. I listed this at the end of year one as my favorite book of the year Slow Productivity by Cal Newport. Nathan, what do you got here?

Nathan Toups (28:58)

Yeah, so I I love this book. I didn't give it enough credit and I keep coming back to it. Actually, I'm doing I'm doing a a live session at Leland on how to stand out as a software engineer. And this book comes up in my like techniques and tactics for like making time to do impactful work. it's super important. Actually, I think this is one of those kind of like deep thinking type books that Cal Newport's

Famous for. I think we actually have another county report book coming up soon that we'll be reading. yeah, it it's just one of these like do less, find meaningful work, and you know, it it had a I think I I stopped I I stopped doing two or three busyness activities around this time that actually helped me focus more deeply on things like book overflow. So yeah, that that's what I remember from the book.

Carter (29:55)

Yeah, for me, I got hit over the head with pseudo productivity. And I realized in my career that I've that, you know, I think the classic example is like filling out expense reports or whatever. And I realized I was doing things from I had this kind of thought pattern of like, well, I'm working and I'd rather not be working. And what I'm doing is like technically useful. so clearly this must be work. And the answer is especially as you move up in your career, like.

Nathan Toups (29:58)

Yes, yes.

Carter (30:24)

That doesn't really count. who is it that talks about that that this is Will Larson, the idea of snacking. And and pseudo-productivity, I think, is even a a layer lower than snacking. but yeah, you have to be as you move up further in your career, you have to be rushing towards the highest leverage, highest value activities you possibly can. and I've been enjoying my work at this startup because I I feel like I've been able to do that. It it's also worth

Nathan Toups (30:30)

Snacky.

Carter (30:52)

Saying at a startup, sometimes those high leverage activities are it's like lower hanging fruit. It's like, hey, like our release process sucks. Like I'm gonna make it so our release process doesn't suck. High leverage? Totally. Do they have all that stuff built for you already at Amazon? Yes. Right. So, but but just for anyone out there, I mean, that that's my advice for anyone in any career, which is like look at your domain, look at your sphere, find whatever the most important thing is.

And you know, whatever's going to give your team the most leverage. And if you just keep doing that over and over and over again, you'll rise in your career. And pseudoproductivity is absolutely not the way to do that. So lesson learned on me, and good job, Cal. and phrase it very elegantly in his book. Okay, we've got Unicorn Project by Gene Kim. I'll go first. There's a lot in this book. I'll just start with the first thing that sticks out to me, which is I remember there's a section where like

Nathan Toups (31:34)

Yeah.

Yeah.

Carter (31:49)

It's like the build is broken or the site is down. I don't remember exactly, but they have to find the release manager, right? There's like one engineer out of like 300 who has the permission to like look at like detangle the code and find the exact right commit and then send that out. And like they're all waiting. It's like a room of like 80 people who are just like waiting for the release manager to get. Again, this is one of those things that like you think makes you like, we're a team that cares about secure.

Nathan Toups (31:56)

Right.

Carter (32:19)

Practices. We're a team that like we understand the gravity of what we're doing because only the release manager can release the code. and it's just it's stunted thinking. if you truly cared about yeah you know, the good practices, you would you would make your automated practices so good that there's no need for a release manager. Anyone can be the release manager. I mean, a robot is your release manager. You commit to main, and then you should have all of your automated checks in place that verify the release is good to go.

and I I've seen companies like this where, you know, like they they get burned by something. They say, okay, we'll institute process. And process makes us a a very serious engineering team. but you're not solving the root cause. So and I think that's what a lot of this book is about. It's like solve the root cause. Solve the root cause. It's actually making it hard for you to deliver at a good velocity.

Nathan Toups (33:12)

So years ago I read The Phoenix Project, which is the book that came before this. if you're in DevOps and you wanted to do cool stuff in DevOps, you absolutely listened to folks like Gene Kim. And I would love to get him on the podcast one day. That'd be so cool. But Unicorn Project, I think, and this is one of the reasons I think you said you'd not read the Phoenix Project because it just didn't feel like it applied, right? Because it was very DevOpsy.

Carter (33:36)

Yeah, right, right.

Nathan Toups (33:38)

And I think that it was really smart of him to write the Unicorn project, which is a software engineering perspective on the same sort of set of events of why you should care. Like why should you care that this DevOps processes of these CI C D pipelines and all of this stuff is here so that you can ship the most amazing software that that a team can ship, right? And i again, it's an allegorical story. It's really smart in how he

has it written. Actually he cites the book called The Goal as one. It it's actually in our backlog. I think we'll probably read it at some point, which is the framework upon which how he wrote this this book. and you can see actually and we'll bring this up because Neil Ford and Neil Ford and Mark Richard to talk about this. It kind of moved to the bar. There's now an expectation that you kind of have an alleg allegorical story that rides along with your technical book.

Carter (34:29)

Yeah, yeah.

Yeah.

Nathan Toups (34:33)

And I think it's because of I I it's because of books like this. and it does it. It makes it easier to it makes it easier to process really technical things if you have a story, because you know, at the end of the day, humans are all about story.

Carter (34:46)

Absolutely. Okay. Tidy First by Kent Beck. I enjoy this one and the optionality, this idea that there is value in optionality. he could he equates like code, he talks about like the time value of money, basically. I don't remember exactly what it is, but I I I enjoy this book for getting to like the nitty gritty of like hey, code is supposed to make money and you should and basically trying to sell to stakeholders like.

Here's why having good extensible code will make you more money. And optionality is one of those keys there that you you don't necessarily know what your code is going to need to do when you first write it. And so if you write it in a way that provides you that optionality, you know, it just you get some that extra flexibility there. And then how much that overlaps with like gold plating is a a a question for another day, I suppose.

Nathan Toups (35:42)

Yeah. This book this book really punched a bunch above its weight. It was very short. it was actually I I don't remember how long it was, but it didn't take us that long to read. I I listened to the audiobook version and I remember I was at a company off site and I was running in I was running in Tennessee and like running by Vanderbilt University and I was like on my run listening to this book and just thinking about like how fun it's to think about software things while going on a run and

being at an off-site and that's kind of like a, you know, pretty neat life, I think. And the optionality thing really hit me. I I anytime I go back and go, man, transferable skills from one discipline to another, like thinking about options trading or, you know, the futures markets or these other kind of things and taking an idea that another industry does to keep keep their options open. It's like a really real thing. And he's like, hey, we should do this in software. Like you should make it so that you have this escape hatch or you have this ability.

To kind of like make it changeable in some frictionless way is again, it's a sign of maturity. I I ended up becoming a huge fan of Kent Beckett. He has a newsletter that's built up all around this and just lots of great ideas. He's been shipping amazing ideas for a long time. And yeah. we skipped a book. Unix a history in a memoir. Yeah. It's okay.

Carter (36:58)

Absolutely.

did we? we did. I can't believe that. I love this book.

Nathan Toups (37:07)

We had a lot of interviews happening. So we're looking through our timeline. So we haven't even brought these up, but like, you know, there's a lot of authors' interviews that happen in twenty twenty four. but yeah.

Carter (37:16)

for me, I'll keep it simple. Pipes. I didn't really understand pipes. This book helped me understand pipes and that I thought that was neat, you know, the idea that like that's one of the the building blocks of Unix, and one of the things that makes it so powerful is that like every program just takes input and returns output. And so the pipe operator can just make the output of the last thing the input of the next thing. makes it very flexible, extensible. yeah, I

Very practical takeaway from a very philosophical or I guess maybe nostalgic book, but it helped me learn that. So that that's what I got here.

Nathan Toups (37:53)

Yeah, and speaking of pipes, Doug McElroy is some as an unsung hero that I had not given enough credit for like why how how important he was to kind of like literally gluing Unix ideas together. Pipes came from some him pushing on the team and figuring out how to make it easier to move, you know, the input of one part of the code into another. And so I think he was pretty instrumental in like really shaping what Unix philosophy was. And

Carter (37:58)

yes.

Nathan Toups (38:21)

I don't think I would have under ever understood that unless I heard Brian Koenihan talk about Unix and how it was developed at Bell Labs. It's just such a cool and then we had him on the podcast to talk about it. I mean, I have to pinch myself when, you know, thinking about that kind of stuff.

Carter (38:31)

Yeah, yeah.

All right. okay, did we tidy first? Okay. the twelve factor app. This is embarrassing. It's an essay. I don't remember anything from this. I know you're a big fan of this, so I I I feel bad.

Nathan Toups (38:48)

Yeah, it's

y this came out of the Heroku days. it it's a b you know, it's a basic set of principles that you look at and you're just nodding your head. I will also say it's very funny. Carl Brown, you know, Internet of Bugs has some like really h like strong opinion, hot takes on why a lot of these are bad ideas that I disagree with, but I also like respect where he's coming from. Like I feel like if you misapply some of these, it really does make things really obfuscated and hard to reason about and it really

Carter (39:06)

Yeah.

Nathan Toups (39:17)

bad decisions. I I think that that's true for any type of software, like people who use Kubernetes and don't understand why to use it. but I still I still look at these and we still talk about twelve factor principles all the time. Like that that and fitness functions. I'm yeah, big one.

Carter (39:35)

I gotta I gotta reread this one because again, it's an essay that it doesn't take that long. speaking, we did another essay, Agile Manifesto. I like Agile is just so baked into modern software engineering, it's hard to say, like, well, what did I learn from this? but yeah, I kind of hate like true agile has never been tried, right? But you know, just this idea that like I think it's interesting.

You have to contrast Agile with what came before it. And I think Agile as a response to waterfall and this idea that like we are not getting we're not getting working software out fast enough. We are not responding to customers' needs fast enough. We're not getting customer feedback fast enough. What can we do to change that? and I think when people think of agile, they mostly think of all the ceremony meetings with it, stand-ups, backlog grooming,

Sprint planning, things like that. And so I get why this leaves a bad taste in people's mouths, but the general idea that we should try to deliver working units of software as fast as we can to the customer or the stakeholder and then be working very closely with the stakeholders and customers to refine what we build, I think is a very solid theory for software development. And it was interesting to see where that kind of theory first originated. And we learned, and we did learn this that it was written in Utah.

So I'll I'll shout out Utah any point.

Nathan Toups (41:02)

Yeah, written in Utah. And of

the original signatories, we have Kent Beck, Martin Fowler, and Bob Martin all on the podcast, right? Those are three of the signers of this original document. You know, and I I think its critique is worthwhile. This isn't an amazing manifesto if you're a software consulting shop and you need to have a accountable way of, you know, showing that you're delivering value. I do think that a lot of the

Carter (41:13)

Yeah, yeah.

Nathan Toups (41:32)

Ways that it was applied over the years have probably not aged well. As a a rebellion against multi-year waterfall planning, I think it was incredibly effective, right? It it changed the conversation. It said, hey, we should we can't know how to build everything that we're building. Software's just too complex. We need to break it up into small parts. we need to ship valuable things in smaller increments. Even if we abandoned the original agile sort of like methodology.

Carter (41:43)

Mm-hmm.

Nathan Toups (42:00)

This is where, you know, things like Kanban and a lot of these other techniques have come out. And I think we all agree now, multi year waterfall planning is just a bad idea, right?

Carter (42:11)

Yeah. No, I agree. And I I've been kind of harping on some of my team with that with like AI agents. We're we want to be doing more like autonomous AI agent development. some of which I I am a big fan of. Like I had it was actually really cool that the this whole whole little system we've set up. and we couldn't find like any good online hosted versions. And so ours is literally just a MacBook running in the office, kind of in a a constant loop. Yeah, yeah.

Nathan Toups (42:34)

That's hilarious.

Carter (42:37)

And I I did have the a fun little version or interaction with it where I said, like, hey, we have the ability to like edit categories on the websites and we have an ops tool to do it. And I tried to edit the category and it wouldn't let me. And so I I pinged the agent, we call them our ponies. I p pinged the ponies and said, like, in Slack, and I was like, Hey, like, I can't edit this category. Seems like a bug. And it responded to me and said, like, that's not a bug. You you got a 403 because you don't have the specific can edit categories permission, to which I responded.

But I have admin permissions. So I would assume that admin permissions would encompass the ability to edit categories. And I told like I I would like it to do to have that permission. And then it created a ticket in linear and and got it all running. And like I I reviewed the PR. It was like three files. Like it changed like three three lines and added some integration tests to be safe. And I was like, that's fantastic. Like I don't I don't want to take time out of my day to do that. And like it it did it about exactly the way I would do it. So for things like that.

I'm a big fan of more autonomous development. but there are things, especially more like complicated features, where I think some of our juniors are a little starry-eyed about this idea that like we'll just describe the result perfectly to the agent and it will execute it while we're sleeping. And I and I'm just like, that's waterfall. Like, we we can't we we learned that. We learned that, like, and again, it gets back to Osterhood's design it twice, which is.

There are some things you can only know once you get into the code base and start working with it. And so I've been trying to figure out like where do you draw the line between like this task is probably small and simple enough that like it would be dumb to like stick it in a backlog and and prioritize it and assign it to an engineer, versus like let's see if an agent can generate it autonomously for us. and and kind of which things do need more human in the loop development. I don't know, weird time in the industry.

Nathan Toups (44:29)

Yeah.

Carter (44:30)

Next up, Software Engineer's Guide Book by George Oraz. again, so cool to have Gerge on the podcast. there is so much in this book. And if I'm being honest, I can't remember anything that like really, really stands out to me, except for the overarching theme is I've already mentioned this episode, this idea that like as you increase in as you like level up in this field, you need to be working on higher leverage stuff. You need to be actively owning your career.

I believe this book talks about the idea of like you need a manager and a sponsor. I think that's something I I learned too late, which is like if you want to get promoted at pretty much any place, not even just like big tech, you need your manager to like be going to bat for you, to be lining up projects for you for you to succeed. And then it's on you to actually accomplish those projects and succeed, but provided you do, then your manager kind of has the ammunition to go up to their manager and say, I think we should promote this guy.

I was I think I mentioned the podcast, but I was I was recently promoted at our startup from just a kind of regular lead engineer to the company's principal engineer. So but but a lot of that comes from just my manager because he I think saw potential in me and and I repeatedly delivered on I think what he thought I could do. And it's been a good relationship between the two of us. So find a good manager, you know. I that that's that's what I recommend to anyone out there. Your your career is very

Closely tied to your manager.

Nathan Toups (46:02)

Yeah, this book is on brand with his The Pragmatic Engineer, which has just exploded. I mean, it there's a reason that it's the most popular engineering newsletter in the world right now. He's also been doing just absolutely amazing interviews. I think I think one of his more recent ones was with Kelsey Hightower, which is just phenomenal. And there's also a new one with someone on on like modern CI C D with agentix stuff. It's just super amazing information.

Carter (46:16)

Yes, yes.

Nathan Toups (46:31)

And it it exudes this in the book as well. Like a lot of good career advice that I I I think we talked about like a lot of us we've learned it piecemeal in different places. And it's just in one spot, which like if you could just hand this to somebody and be like, hey, be intentional, you know, do these things, you know, understand that career paths are complex and but advocate for yourself and have the right frameworks in place, I think you know, it's it's a great book.

Carter (46:58)

All right. Well, let's go to hypermedia systems by Carson Gross. And then I don't remember the first names here, but we got Sipinski and Ux Simpsek. HTMX. Like I I read this, I'm like, man, like some of this is wacky. Like sorry guys. Like I I've said on the podcast before, but I'm very much just like, what is the most tried and true system? even if it's not maybe the exact perfect fit for the job, what's the the thing where

We're gonna have the most reference material and an AI age. I think that's important too. And I think about it from a hiring perspective, like who am I gonna be able to hire and not have to train on like our obscure framework? But I love that Carson Gross like is just thinking about this kind of stuff. I think it's a very, very interesting idea. And I'll say that some of this would you say that that some of what he complains about with the web has been addressed or at least been tried to address with.

Nathan Toups (47:44)

Right.

Carter (47:56)

server side rendering with Next.js?

Nathan Toups (48:01)

So I

think there's a lot of thinking about I again, I I think the book really advocates this idea that hey, the original ideas in hypermedia systems are actually really cool. And that we don't need to have this super thick JavaScript client to do all the neat things that you think you do, that you could actually do a lot of it server-side and that we just need a good spec and we shouldn't really care about what your backend is. I again, I think that

HTMX code is going to continue to run for 25 years, right? Like if you wrote it in HTMX, it's so simple that you could the odds of it being able to like spin it up and get it working pretty high. Where I think that if you're using the latest and greatest framework, it very likely could fall over and break, right? In the same way that like flash websites don't work anymore. And I think as a critique, it very similar to Agile Manifesto, as a critique, I think it's really effective.

Is HTMX the way that we're gonna do it? Probably not. I do think that these kind of contrarian takes will make you a better engineer. Either say, hey, you know what? There's some ideas in here that I like, or not for me, right?

Carter (49:03)

Yeah, yeah.

All right. Well, Team's apologies by Matthew Skelton and Manuel Pais. Nathan, what you got anything out of there?

Nathan Toups (49:14)

My

big takeaway I remember from this is, and again, we read the first edition. So we have not read the second edition, which came out not long after we read this, or maybe later that year, but optimizing for flow, right? So this this whole idea of teams should be oriented around reducing the number of coordinations that have to happen across other teams. And these were ideas that were kind of like coming around. We talked about, you know, the what the inverse conway maneuver and things like this.

We started hearing people mention team topologies from the ThoughtWorks folks like Neil Ford and we had to read the book. And it it's had a big impact on me when I think about if we're running up against something, is it structural in our software architecture or is it actually organizational? Right. That we're just like building things the wrong way as a team.

Carter (50:04)

Yeah, I I I don't know if I can credit with this book exactly, but I love just the idea of Conway's Law and and you're you're just gonna ship your org chart, right? And and I think it's worth thinking about like yeah. I I I think companies think of Steams sometimes as infinitely malleable and like, we'll just allocate these widgets around and we'll we'll we'll find the the maximum

productivity combination of all the widgets. Like that's not how it works. And the whatever shape your teams are, that's the what the shape of your software is going to be. So, you know, think carefully when allocating your teams. Okay, next up we got AC the system design interview by Alex Ju. for me, back of the napkin math. he advocates for this idea that like there are some things like what is it? Like one text or like there you

You can know, like, for example, like I I forget exactly, but like how many milliseconds does it take for a data center in California to reach New York City? Right. and it has like this whole chart of basically like before you go into an interview, you can memorize some of these like common times or like common data, like storage sizes. and then when you start doing your system design interviews, it can be

Helpful to do kind of back of the napkin math. Like someone says, like, okay, like this system needs to be able to handle 10,000 tweets an hour. And now you're not guessing. You're like, okay, well, I know how many bytes a character is. And I know a tweet is 140 characters. And so you kind of get like a a some bounds for the problem you need to solve. and I remember thinking about that in particular because like you might think, like, wow, that's a lot of scale.

We're gonna need no SQL. But then if you actually do the math, you might be like, like that's only like over the course of a year is gonna be like 60 gigabytes of text. Like maybe we could do like a really beefy Postgres instance. maybe that would be better for our our our needs here. So yeah, back of the NAPPY math I think is something I rarely ever see system design candidates do. And I'd like to see more of it. And I I've integrated it in when I've done system design since then.

Nathan Toups (52:24)

Yeah, no, I think this gets into that category that we talked about earlier, which is like understanding where the high impact is. So you can go down these little rabbit holes of things that are completely meaningless for what the question was actually asked of you. And I think this is what kills most people in their system design work, which is like, did you actually find the nugget of the thing that mattered? Right. Are you focused on the part of the design that they're asking for? Right. don't just try to impress them with a bunch of like, we're gonna use

Kafka and throw these things in. You're just like, why? Why like maybe Kafka is the best thing, justify it, right? Use some back of the envelope being like this many payloads are this large and this is the throughput that we need. You know, like justify these things. And what's nice about this, and again, I remember from the book, talk about this out loud, like rubber ducky this with the interviewer and be like, hey, can we agree? You know, this is about 100 milliseconds of latency if we're talking about from here to here.

They go, okay, that yeah, that sounds about reasonable, right? Like they'll give you feedback, or they'll be like, are you sure about that? You know? in which you're like, maybe I'm thinking about this. You know, you kind of just say it out loud. They'll give you so many hints, right? You don't have to go off and come up with the perfect design in your head. You can you're neat you're gonna be riffing in the real world anyway, right?

Carter (53:20)

Yeah.

All right. Well, what's what's I was trying to count the books ahead of us, so I I lost my place. Okay. Good news factory by Kent Beck. This is a sequel to Tidy First. man, I gotta read this one again. I remember really liking the the core of this is basically like the idea of the good news factory is is this is a a message to like C suite people saying, like, how can your software team be a a good news factory where it's just kind of constantly coming out and saying, like, good news, we've done this, good news, we've done that.

Nathan Toups (53:37)

Yeah.

Carter (54:05)

And it's basically selling the idea of how clean code and extensible systems turns you into a good news factory. But I can't remember examples of the specifics of this. So I should reread this.

Nathan Toups (54:17)

I yeah.

I don't either I I should take another look. And this one was super short. I think it was actually more like a report, technically, like from O'Reilly. but you know, and and it is true though, like from yeah, I remember that that this idea that, hey, look, if you're not pumping out good news and you and showing that your processes are working or that your hypothesis was correct, like no one else will. And you're just gonna like people will.

Carter (54:23)

Basically, yeah. It's like forty pages.

Nathan Toups (54:43)

create their own narratives, right? And if you aren't c kind of in control of it, it's can easy get easily get out of control.

Carter (54:49)

All right, thinking in systems by Donnella Meadows. stocks and flows. That's what I'll say here. just just the idea of I I've thought about this and you know, I actually thought about this like there was a tweet where someone's basically like, In or like NVIDIA is now worth more than Canada because NVIDIA their valuation is now higher than Canada's GDP. And someone's like, Stocks are not flows, right? Like

Nathan Toups (54:55)

Yes.

Carter (55:15)

GDP is a flow and market cap is a stock. Like, I know that. I know that from Donnello Meadows. So yeah, yeah.

Nathan Toups (55:21)

Isn't that funny? Th this

is the one where the this is one of those books where like the people I respect respect this book. So, you know, Will Larson brings this one up all the time. And you'll you I think Gerger Oraz also talks about this. And I think anyone who does lots of strategic or systems type thinking, they like to think at this level of abstraction. I do remember when we read the book, it some of it was like, man, this is like very abstract. But as I've let it kind of sit in the back of my mind, I'll go, you know what, th this is actually.

This is a great one. If if you're interested in the str strategic type thinking, I I think revisiting this book from time to time it'd be really valuable.

Carter (55:59)

All right, Grokking Concurrency by Kyro Bobrov. This is another one where I'm gonna have to punt on, and that's not because this isn't a good book. This is possibly the best book on concurrency out there. I just don't do a ton of work with concurrency. I like this low level. And so I I haven't had the need to cement some of these ideas in my neural pathways. So

Nathan Toups (56:12)

Mm. Yep.

I've been doing a lot of data, data mesh and sort of data delivery type stuff. And this the book the big takeaway that I remember from this was right sizing your concurrency models, meaning that like you can make things too granular and there's no advantage to it, and you can make things too broad and there's a lot of disadvantage to that. And like really understanding what's that unit of work that you can parallelize or break into concurrent operations so that you can sort of tune the system.

and in the book have has like a lot of good approaches for testing this. And that's what I that's my big thing I remember from that book.

Carter (56:57)

There we go. Okay. rework by Jason Fried and David Heinemer Hansen. that it's okay to be small and that you should you like if you're starting a business and you should use that smallness and that obscurity to your advantage. Like that's your time to iterate and to reinvent yourself and to figure out what's working. By the time you're big, it's a lot harder to do that. And so I think that's yeah, I think that's a a really valuable lesson for anyone.

Just starting their own company. that, you know, that there's advantages to be had in obscurity. And if you kind of just think like only once we are famous or well known will we have what it takes to succeed, like, well, it's actually when you get to that point, you might be losing a key advantage of success. So take advantage of it while you have it.

Nathan Toups (57:45)

Yeah, same. the Jason Freed and and DHH are phenomenal writers. The book is very well argued, even if you don't necessarily agree with everything. And I think it it kind of is a rallying cry for, you know, why you might want to bootstrap something or or or build something that maybe doesn't fit the mainstream notion of what success is. And that you really have a lot more power and control over defining what success is for yourself instead of letting everybody else do it. And

They're they're a proof of that, right? Like most people that I know don't use Basecamp and thirty seven signals, and yet they've still been a part of the conversation for a really long time. You know, Ruby on Rails and all the other stuff that they've they've developed. And I don't know. this book has held up over time. I think it's a a pretty cool one. It's one I've I was happy to reread and it still made me excited.

Carter (58:37)

Next up, In the Plex by Stephen Levy. I love these kinds of books, so I won't dwell on any one specific thing. I think there are well, okay, there are two things. One, I remember Google reinvented like a type of auction from first principles. Like it like it's like this type of auction, like auction theory that like the the you know, whoever invented it like won a Nobel Prize or something like that. And a Google engineer just kind of reinvented it based on the constraints of of of their problems and

Nathan Toups (58:54)

Yeah.

Carter (59:07)

I saw someone on Twitter saying that like that's a lesson for just hiring smart people and trusting that they will kind of get to the correct solutions when when faced with a problem. The other thing is I actually reference this book a lot when talking to prospective candidates or when talking to like our junior engineers, which is I work at a startup and like most startups, I I what I say is everyone wants to work at Google in 1997, where it's like you made it on, like I imagine it's kind of like joining Anthropic a year ago.

It's like you got your seat on the rocket ship. And so long as you just stay on the rocket ship, you're good. and I say that about our company. Like, we're growing, which is great, but we're not like rocket ship growing. And I I like all the plans and the things we're building. Like, I think we have really solid theories for why there's a lot of success in our future. But I tell anyone kind of considering joining our company, like, our success is not guaranteed. We all need to work really hard every day.

to make sure that this is worth something. And I think it will be. but this isn't Google in nineteen ninety seven. It's not just destined to to succeed. so I don't know. I think about Google in nineteen ninety seven a lot.

Nathan Toups (1:00:16)

Yeah, this book was interesting. Ste Stephen Levy is or Levy, I'm not sure how to pronounce it, but it he the excellent writer, I've I've read some of his other stuff as well. his book Crypto is really excellent. And really weird thing, and I won't get too into it too much. I actually interviewed a company, got pretty far into the interview process with the CEO of the company is in this book.

Carter (1:00:21)

I normal neither do I.

Nathan Toups (1:00:44)

He was like he was like

Carter (1:00:44)

yeah.

Nathan Toups (1:00:46)

an in you know, he was like a intern or like ear early product person that was kind of like featured as a section of this book. And it was surreal when I realized that it was him. because I like w literally went back and full text searched to the Kindle version of this book and I was like, This is again super weird that I I read this book for this podcast. I'm interviewing at this company. This guy's listed in the book and this is what he's doing 20 years later. It's kind of nuts. that was the biggest that was the biggest memory I took from that book.

Carter (1:01:13)

Ha ha ha.

Nathan Toups (1:01:14)

also, yeah, what an unstoppable force Google is and how they continue to surprise. I think, you know, a lot of people wrote off that hey, maybe open I was gonna win the AI wars. And then, you know, even in 2024 or in 2025, I think when we were reading this, I didn't know a hundred percent where Google was gonna be. And I think I was already changing my opinion, which was Google already has the infrastructure. They already have the AI talent. What they were missing was this new approach to how LLMs and GPTs work.

Carter (1:01:37)

Right, right.

Nathan Toups (1:01:44)

And I think it's pretty arguable that they're gonna be a major player for the long term. They're not going anywhere. Yeah.

Carter (1:01:50)

I think so. Yeah,

yeah. meta is crying sadly in a corner. let's see. We got thinking yeah yeah yeah. thinking like a large language model by Makund Sundarajan. I don't remember a 10 from this one, just being honest.

Nathan Toups (1:01:57)

Yeah. The cautionary tell of AI psychosis in your CEOs.

I don't either. Yeah, let's move on.

Carter (1:02:09)

Okay.

All right. sorry. DevOps handbook. Okay. This is like has influenced so much of how I work. like this we choke all the time at my company that like my first day there, I someone says, like, hey, is the site down? And someone's yeah, I just deployed. I'll I'll get it back up in a sec. I was like, what the heck is going on? And I was like, that's gonna change. Like we cannot have that anymore. We don't have that anymore. Thank goodness. and

There's just so much from the DevOps handbook that influenced my like yeah, wanting to get us to like a real deal software engineering team with like a real deal C S C D pipeline with automated rollbacks, with better observability. and I have integrated all of that at our company because of this book. the other thing I haven't been able to do, which I really want to do, is I like this idea having like shadow traffic. Like I think the example he gave was like you have a new

search functionality. And so you want to see like if it's going to work. And so something you can do is as people are using your old search functionality, you direct like 10% of that traffic to the new search API, but like in a way that doesn't return the results to the users. And so you can kind of just run your new search functionality against real production traffic and observe the results in an invisible way. and the other big one I can't believe I didn't mention this decoupling deployments from releases.

Nathan Toups (1:03:36)

Yes,

it's huge.

Carter (1:03:37)

This is

huge. We use feature flag. Feature flags were like the basics of our entire migration strategy. So we just do trunk based development, continually committing to main, guarding all of the migration actually behind a feature flag. And then that helped us if we shipped a regression with the migration. We just toggle the feature flag, switch it back off. Super valuable book. I recommend this to anyone.

Nathan Toups (1:03:58)

That's awesome. Yeah. Star set of authors, Gene Kim, Jess Humboldt, Patrick Dubois, which we ended up having as a guest, and then of course Nicole Forsgren and John Willis. Nicole Forsgren is a in another book that we'll be you know covering later, but yeah, DevOps Handbook is it's the complement to Unicorn and Phoenix Project, where you actually get into the nitty-gritty of what good DevOps work is. And yeah, I was really glad that we covered it on the podcast.

Carter (1:04:29)

There we go. Okay, move it on. And and we're we got we got some hard outs for us here. So we're gonna be a little faster. Okay, speed run. discussing so just for fun, how Linus Torvald started an accidental revolution. I love this. I I think that this gets back to something Dan Heath told with Made to Stick, which is like you should just work on what is the most fun and trust that whatever you think is the most fun is what you're gonna work the hardest on. Linus Torvald's exemplifies that principle perfectly. Like he just built you

Nathan Toups (1:04:33)

Mm-hmm. We got this. We're gonna speed run. We're we got this.

Carter (1:04:58)

Linux because he thought it was fun and it changed the world. I don't think all of our fun projects will change the world, but you should live like Linus Torwalls, just work on what you think is fun.

Nathan Toups (1:05:08)

Right. Yeah, it was great. I it was it was a blast from the past 'cause the book came out again, I think, twenty years ago or something, maybe more. And it was so wild to see what the like was possible. And they kind of rewrote a lot of the playbooks of how you even can make money with open source software and you know, living your principles and other aspects of just completely unconventional approach. And you know, he's Linus Torvalds just kind of

He's an anomaly. I don't think I've seen any other projects or its leader in open source work as well. And it just happened to be a very important problem that was being solved. And yet he was having fun solving it the whole time. I it's I don't know. It's i he made a huge impact on the trajectory of how we run servers, how we commit code. and I I don't think we even talked about this, but another thing that he's written not too long ago is

scuba software. He's like a scuba diver. And so like some of the best scuba dive logging software on the planet is like Linus Torvald solving his own problem. So yeah. Yeah. The patron saint of solving your own problem, right?

Carter (1:06:09)

yeah, yeah.

There you go. Okay.

99 bottles of OOP. We did not finish this book. We did not like this book. We will not discuss this book further. we're not gonna beat up on it anymore. made to stick, we will discuss. I love this book. just the central premise of this book, which is the idea that like sticky ideas follow a pattern and that you don't need to be a creative genius to make ideas stick. You just need to you just need to follow this these patterns and that will help your ideas stick.

Nathan Toups (1:06:26)

Yeah, we'll skip it.

Carter (1:06:47)

But really the biggest thing from this came out of that interview with Dan Heath. It was instrumental me taking my current job, which is this idea that like what we just said, just work on what's fun and trust that you'll work the hardest on the thing that's the most fun and that will lead to more opportunities that will be fun. Like trust that flywheel. That was very, very influential in my life. So big fan of Dan Heath. So grateful he came on the podcast.

Nathan Toups (1:07:09)

Yeah, this is one of those books that'll just break you out of your shell. Sometimes you just need something that'll kinda like, you know, kick your butt a little bit and it was great.

Carter (1:07:18)

All right. staff engineer by Will Larson. a snack avoid snacking. You have to be working on high profile, high priority things at the staff engineer level. And really just as you that's a good metric for as you progress through your career, the higher up you get, you need to be working on high impact stuff. So yeah, big fan of that.

Nathan Toups (1:07:38)

Yeah, this was my first glimpse of how like what a talented thinker Will Larson is. His pot his his blog is excellent. my big thing I remembered was all of the staff engineer stories that are the second half of the book and how varied their backgrounds are, right? Like y there is no one path to becoming staff engineer. There's no template that's gonna guarantee your success. I think it's a lot of it being working really hard and being ready.

And then investing in these like higher order thinkings, but there is no path. Like you you read through these and you're like, that's kind of cool. That's kind of cool. And these are you can tell these these unique individuals are solving these really cool, complex problems in a bunch of varied ways. So that's what that was my takeaway. Is like, yeah, you can be an oddball. If you can frame it properly and show a lot of value, then like there is a there's a path for you on a technical leadership standpoint, which is neat.

Carter (1:08:37)

discussing finite infinite games by James P. Cars. This one threw me for a loop. I don't remember anything from this. I know you like this one a lot.

Nathan Toups (1:08:45)

I remember you were so mad about this book. And

then I think I think I at least got you to be like, okay, you know, a little bit by the end of it. I I were so the big thing to me was, and this kind of gets into it, there's actually a through line here with the Linus Torvolts part, right? You could argue that Linus Torvolts, the finite game of becoming the most popular operating system on the planet, right? Only somebody can win that, right? There there is objectively someone's

Carter (1:08:52)

Yeah yeah yeah yeah.

Nathan Toups (1:09:15)

the most popular operating system on the planet or not. But he that he wasn't playing the game to be the most popular operating system on the planet. The infinite game that he was playing was, you know, building the best operating system that he could imagine in his mind and building a community around doing this and not having a bunch of commercial software, you know, ham sh hamstringing everything. you know, finding this book is really pushing you to find these infinite games. The games that are, the point of playing it is to play the game, right?

Carter (1:09:23)

Right.

Nathan Toups (1:09:44)

And that inside of this, he's not saying don't play finite games. Perfect example. He's a PhD, right? A PhD, getting earning your PhD is a finite game. and then you know, what you do afterwards with your tenure and you write books like finite and infinite games is the infinite game. So yeah. Anyway, I I love that this is the kind of like woo-woo stuff that I love. So I this is I I I still look at this book.

Carter (1:10:02)

There we go.

Yeah.

On the opposite end of Woo-woo, we've got Radical Candor by Kim Scott. I the central idea of this book is just like it is not nicer to dance around the issue. I really, I really enjoy that. And I think there's an anecdote in particular where like she's got her dog out on a walk and he's like kind of going crazy, like trying to escape the leash. And it's like a busy street. And a man next to her just says, Like, I can see you care for your dog, but you're gonna get him killed. Like, you need to,

And then like he gives the dog a command, like a very strict command, the dog obeys. He's like, see, it's it's not mean, it's direct. And she said, like that man, like, he cared about the dog. He cared about her. And even though he gave her some harsh truths, like he did it because he was concerned for both of their well-being. and I think that concern for one's well-being should map to being direct about the problems at hand. this is a hard skill, but it's a good skill, and we should all be a little better at it. And the book gets into the idea that like,

Nathan Toups (1:10:52)

Right.

Carter (1:11:05)

You don't need to be a big a-hole, right? Some people love the idea of radical candor because they can just say what they want without worrying about what anyone feels. but the whole idea behind radical candor is that you actually do very deeply care for the person you're talking to. and I think good managers practice this and are very good at it.

Nathan Toups (1:11:14)

Right.

Right.

Yep. Same. I definitely think that this book has been used and abused, but I also think that if it's applied properly, it it there what was it? Ruinous empathy. I think is what the the counter is. And that's where I'll default to it. You try to be a nice person and you're actually causing harm. Right. It's like giving a drunk giving a drunk a drink, right? You're not actually helping them. it's very similar idea. And I I need to I think I need to revisit this from time to time just because yeah, it's you're not doing anybody any favors if you

Carter (1:11:35)

Yes, yes.

Right, right.

Nathan Toups (1:11:54)

You water things down.

Carter (1:11:56)

Okay, mastering open telemetry and observability by Steve Flanders, another guest of the podcast. The thing I took away the most from this is something I've been reevaluating, which is the idea. He the whole book is about avoid vendor lock in, avoid vendor lock in, use open telemetry. I have been wondering in an AI age if vendor lock-in is less important. and I think that that obviously differs at scale. I'm thinking about my team in particular. We are gonna buy Datadog here in a few months, I think.

And I've wondered if Datadog, the SDK, just gives us a lot of niceties and we don't think we're gonna switch anytime soon. And with AI agents, yeah, I I see you grimacing, right? we'll have to talk about this more. I'd love to get your opinion on this because I I've just I I overall I I still am in the camp of avoid bender lock I've just been wondering how much AI agents changed this. So we'll have to discuss this later.

Nathan Toups (1:12:40)

Yeah.

Yep. And I

think that this is yeah, same thing, same takeaway. I think the other two things that come from this book that I I still have big memories of. We just had a LinkedIn post from a guy who just got his open telemetry certification. And he gave us a shout out, and it was because of our interview with Steve Flanders. and I think that and you know, I contributed a very small contribution to the Go SDK for open telemetry. This from a as a catalyst to like

Carter (1:13:02)

yeah, yeah.

Nathan Toups (1:13:17)

Do things and think about stuff. I think this has been a really positive part. And that's sort of my memory of this book. yeah, we should definitely have a discussion later about this because I know we're running short on time. But the big thing I always think about is the Hotel California, you know, the song Hotel California. And so, you know, yes, it's alluring to have some special feature that only Datadog has, but are you going to like if let's say pricing changes or they get

Carter (1:13:32)

Yeah.

Nathan Toups (1:13:45)

acquired by somebody or some fundamental thing happens and you can't use the tool anymore, how bad of shape are you in? Right? Like what would that migration away from that tool look like? So

Carter (1:13:52)

Right, right.

Okay, I'm gonna bundle these next two together because I don't remember much from either of them. Beyond Vibecoding by Adia Osmani and Advanced React by Nadia Makarevich. Advanced React kind of falls more into like reference material. And so I think I could always go back to that. I feel like I should remember more from Beyond Vibecoding. I don't remember a ton.

Nathan Toups (1:14:14)

Yeah, I think this was the first book that I saw the reference to the term augmented AI and talking about how, yeah, vibe vibe coding gets all the headlines, but really really productive engineers are using some combination of letting it the coding agent do a lot of coding for you, but that the practice of software engineering hasn't gone anywhere, right? That's what I kind of

Carter (1:14:34)

Yeah.

Okay. The Tao of Programming by Jeffrey James. I like one of the the Dow. This is just a really funny read. You guys should all read this. It's you know, on a lunch break or something, it cracks me up. but I love the idea. He says that, like a junior asks a senior, like, what's easier to build a payroll system or an operating system? He's like an operating system easily. So when you're building an operating system, all you care about is what's technically correct. But a payroll system must model the real world. And you have stakeholders and

You know, all sorts of other problems. I thought that was really interesting because I that is not intuitive for a lot of programmers. And it gets into the idea of like Fred Brooks' essential complexity and domain driven design, which is that like modeling the real world and software will always be a complex problem. in a way that maybe creating an operating system is not. There it's different kinds of complexity, obviously.

Nathan Toups (1:15:11)

Right.

Right.

No, I I think that's

true. It's it's why th something like Tailwind can be an amazing CSS library that everyone can you pick up pretty quickly if you like the design choices that are in it, because it has no opinion about the very messy and complex things that are in life. Actually, you know, we skipped there was one other thing we skipped. I'm just gonna give it a quick shout out because it was a it was an essay, Worse is better. And I the reason I bring it up, Talv programming or the Dalve programming and worse is better are kind of both in that same vein of.

Carter (1:15:39)

Right, right.

worse is better.

Nathan Toups (1:15:54)

These little truisms that kind of come up and kind of make you think and kind of again punch above their weight class. and yeah, I I again thoroughly enjoy this. Super easy to read. you also get to you know it it's still hosted on like what looks like a nineties website, which is great and you know, I think it's using iframes, which is even better. So

Carter (1:16:11)

Yeah, yeah.

all right. Mastering the behavioral interview by Austin McDonald. what in 2026. Look at that. yeah, I love this. There's a whole section on transforming like your work stories to like the Silicon Valley archetypes, which I think is really interesting. They talk about like the lone hacker or whatever. essential reading if you're ever gonna go do like one of those Silicon Valley style tech interviews.

Nathan Toups (1:16:21)

we're we're now in twenty twenty six. We're in the final yeah.

Carter (1:16:43)

And and really just gets at the idea of like telling stories and how to tell stories, which is something I've always been kind of good at in my interviews. but it's worth giving a shout out to the concept.

Nathan Toups (1:16:55)

Yep. Yeah, I this is one of those where I think he he was maybe doing a media blitz or something. It came up on my radar and I'm so glad we found it. you know, he's a first time author. Austin was a great guest as well. And he was even, you know, interacted on our Discord and on LinkedIn and stuff. Like he's just really active and super, super friendly person. That's my memory.

Carter (1:17:18)

okay. designing data intensive applications by Martin Kletman. Holy cow. tons and tons of stuff in here. I the first four parter, hopefully the only four parter. yeah, we'll see. well wait until our four parter the very hungry caterpillar. It's gonna be great.

Nathan Toups (1:17:26)

Yeah. I think it's the first four parter that we've done.

We'll we'll see.

What about we

what if we had a an eight parter? What if that happened?

Carter (1:17:40)

Yeah. gosh.

I I there's so much in here. I don't even know what I would say in particular. I really like some of the early stuff on like what it what reliability means and talking about like latency versus throughput, what it means to have a system that is like resilient versus a system that is quick to recover. I I I can't do it justice. lots and lots of good stuff in here.

I I I imagine I will reflect on this more, especially as I build higher demand systems than what I'm currently working.

Nathan Toups (1:18:16)

Yeah. Weirdest thing for me, there there's two parts. Number one, I loved how low level it gets into like thinking through, you know, what is the data actually doing in some distributed database or or what are the guarantees. I also really enjoyed the thinking about data privacy and you know, attention harvesting and stuff that's at the end of this book. And I also I I honestly cannot believe that we finished this in February. I feel like we just finished this book, but it's already, you know, mid June. So that's not true.

Yeah, if you look at reality, but

Carter (1:18:45)

Yeah.

Okay. Reflections on Trusting Trust by Ken Thompson and coding machines by Lawrence Kesselute. I just found coding machines a really entertaining story. and I think it's something we're gonna think about a lot, which is like, yeah, machines can code these days, and how much of that do you trust? I don't know. Like it's just constantly rattling around in my head. I can't say there's a big takeaway here, aside from like, I'm thinking about this all the time.

Nathan Toups (1:19:13)

Yeah, I know this it it got me to thinking a lot about, you know, could you imagine some dark patterns of things being embedded into all of this AI generated code? I think there's a non zero chance that these tools at some point are going to be embedding like steganographic hidden messages to themselves and that either Neil Stevenson's gonna write an awesome book about it or it really is gonna happen in real life, or maybe both. So we'll see what happens.

Carter (1:19:33)

Yeah.

Yeah.

Frictionless by Nicole Forsgrin and Avi Noda. I this one kind of this is very, very much targeted towards like.

People leaders at big tech companies implementing DevX initiatives. I think there's a lot of good stuff in here. I can't say anything really stuck with me just because it's very much not where I'm at in my career in this time. And so I can't say I have a huge takeaway here.

Nathan Toups (1:20:09)

Yeah. Same. I I mean

I I've I've personally interacted with Abi and a huge fan of Nicole Forsgrin. There's some really good thoughts in here, but you know it's funny, I of the other books that we've read, this one I don't remember the specific takeaways other than it's a great book on DevX. It's probably something that you're gonna be more important to you, you know, series C and beyond. Yeah, kind of organs org structure. Yeah.

Carter (1:20:34)

Right, right.

and you know what? I'm I'm gonna call us at th this last book. there's a few other ones. We've got like crafting engineering strategy, soft architecture, the hard parts, learning domain driven design, mythical man month, but we've read those so recently that I think it's almost cheating a little to be like, What did you remember? It's like, well, we we we read them so recently. so and this is a good one to end on Project Hail Mary. I thought it was really fun for us to read the podcast.

I love so much about this book. But actually the thing I'll say is something that Ryan Gosling said in his press tour for this, which is one reason he really likes this book and Andy's Weir Andy Weir's work in general is that the future is not something to be scared of. It's just a problem to be figured out. and I love that about Andy Weir's writing. He's very optimistic about humanity and technology's role in humanity. And and that's a lesson I would like my children to to know, which is just that the the future's just a problem we all gotta figure out. And

And I'm doing my part to to help try to figure it out, you know, in in my day. And I hope that they'll do their part in their day. So excellent book, great movie, fun to cover it on the podcast.

Nathan Toups (1:21:37)

You're right. Yeah, there there's an optimism to this book that I think it's really easy to slip into, man, things are getting worse or, you know, everything's garbage. And it's a it's books like this and thinking like this that you're like, you know what? Things can get pretty terrible, but with enough focus and attention and the right, you know, sort of breakthroughs that happen, hey, you can pull off some crazy stuff and this book's a fun exploration of that.

Carter (1:21:59)

All right. Well, we didn't get to everything, but the four most recent books, you can just read, you know, watch our episodes about them. and we will cover them if we do this exercise again in the future. Thanks everyone for listening. Thanks again for a great two years. we got no plans to stop this podcast anytime soon. but I I will say anytime you comment or send us a message or an email and say, This podcast means a lot to me and I'm I'm grateful for what you do. that really that gives us all the more motivation to keep producing this. So

yeah, find us at bookoverflow.io. that's our website. You can contact us at contact at bookoverflow.io. I'm on Twitter at Carter Morgan. The podcast is on Twitter at Book Overflow Pod, and Nathan's consulting agency is Rohoroboto at rojo roboto.com. Thanks again, everyone. we'll see ya for another great year of Book Overflow.