Reading 40 Software Books and Comparing Them All Head to Head!

[music] Hey there. Welcome to Book Overflow.

Hey there. Welcome to Book Overflow.

This is a podcast for software engineers by software engineers where every week we read one of the best technical books in the world in an effort to improve our craft. I am Carter Morgan and I'm joined

craft. I am Carter Morgan and I'm joined here as always by my co-host Nathan Tubes. How you doing Nathan?

Tubes. How you doing Nathan?

>> Doing great. Hey everybody.

>> Well, thanks for listening everyone. As

always, you know, if you're on YouTube, like, comment, subscribe. If you're on an audio platform, leave a fivestar review. And you know, take the moment

review. And you know, take the moment right now, especially uh if you're on one of those platforms. Actually do those things because I I know I I tune a lot of that out and I've just had a couple podcasts who have been recommending that to me. I'm like, you know what, I listen to this guy every

week. I never like his videos. So, you

week. I never like his videos. So, you

know, that really helps the podcast. So,

take a moment to do that if you can. Um,

speaking of podcasts, this is just a fun little thing. I mentioned a couple weeks

little thing. I mentioned a couple weeks ago that I was working on a passion project of my own. I will link it for this description. I have a another

this description. I have a another podcast with my brother. Everyone who

listens to this knows I'm a big theme park fan. So, we have a new podcast.

park fan. So, we have a new podcast.

It's called Please Remain Heated. And

you I [laughter] was thrilled that no HVAC company stole that domain name. So,

we have please remain heated.com. Uh,

but every week we're uh pitting two theme park rides against each other and we have kind of like a series of like criteria we evaluate them on and then we decide which one's the better ride. So,

we're having a lot of fun with it. And

so, if you have listened to this and thought, you know, I love Carter Software Engineering Contest, but I just wish he would talk more about theme parks, have I got the podcast for you.

Um, and then Nathan, you've also got some new stuff you're working on. We

included a little uh pre-recorded clip of it last week, but you want to kind of talk to the audience about it a bit more?

>> Yeah, happy to finally announce uh I've started my own business. I'm going back into consulting. Uh, it's a company

into consulting. Uh, it's a company called Rojo Robbo. Uh, it's something I've been operating for, I guess, almost 15 years at this point, but now I'm going back full-time. Uh, now it's

focused in platform engineering and, uh, cloud architecture, a lot of the stuff I talk about on here. So, if anybody's interested in working with me, I actually have a 10% discount code at roarabatoto.com/bookoverflow.

roarabatoto.com/bookoverflow.

Uh, I also have a newsletter that I'm excited about. Uh, it's a weekly

excited about. Uh, it's a weekly newsletter. We just had the new the

newsletter. We just had the new the first issue come out and it's really short. It's like a one minute,

short. It's like a one minute, two-minute read. Uh, one insight, one

two-minute read. Uh, one insight, one piece of wisdom, and a question, sort of a reflection that you can, you know, have for the week. And, uh, already had some really great feedback. So, I'd love

for you to to join that as well. And um

yeah, we'll we'll be talking about these new projects more, I'm sure, because it's they all have a feedback loop back into Book Overflow, which is fun. I

>> I once had a uh I I was looking at trying to do some consulting of my own, decided not to do it, and instead wound up joining my current startup. Um but I I Michael Feathers, author of Working Picular Legacy Code, was nice enough to

hop on a call, just a personal call with me. And one thing he mentioned with uh

me. And one thing he mentioned with uh consulting and doing your own business is like you just got to get get out there. you've got to make a name for

there. you've got to make a name for yourself in the programming world. And

so listeners, if if uh you've been following this podcast, you know just how gifted and talented Nathan is and all the value he could bring to your organization. So I think Nathan,

organization. So I think Nathan, >> it's cool that uh you know, I think we're seeing this podcast pay off and it's cool that now that you're doing your own thing, like you've got a year and a half worth of backlog of people

able to tune in and hear your technical thoughts. So good head start there.

thoughts. So good head start there.

Speaking of uh cool things the podcast is doing, you want to talk about our new our new stuff with uh O'Reilly?

>> Yeah, we've entered a partnership with O'Reilly uh which is really cool. We we

just got connected over LinkedIn. Um but

O'Reilly has authorized us every O'Reilly book we read from here on out, we are able to give away 10 free copies. And I and we'll get back with them, but I believe it's 10 free copies per episode. So for

longer books, we'll be able to hand out a bit more as we do multiple episodes on them. Um, and we also are working on

them. Um, and we also are working on other partnerships for our listeners to get free access to the O'Reilly platform for maybe an extended trial period of time. Um, we're still working out all

time. Um, we're still working out all the details with them, but stay tuned in the coming year as we read more O'Reilly books for how you can get some of those for free. We are going to most likely

for free. We are going to most likely tie it to sharing the podcast in some capacity on LinkedIn or Twitterx or honestly even if you send a screenshot to us if you share any of your work

slack and you got a sufficient number of emoji reactions maybe emoji reactions.

Um but stay tuned for the details there and we'll uh figure it out. And man I just feel like there's a lot of big news at the top of this podcast but I want to mention it here just because you'll if you're with me on LinkedIn you might see

mention of it here soon. Uh we are excited to announce my wife and I that we are welcoming a fifth child into our family, our first girl. So that will be coming June 25th. Uh exciting news for

the Morgan family, but um as you know, sometimes when life gets busy here on Book Overflow, we read an essay instead of a book that week. So blame it on the pregnancy if uh that happens.

>> Yeah. And the in the sleep deprivation that you're going to get during the the first month.

>> Yeah. Um, okay. So, lots of big news for the podcast, but nothing fundamentally changing the podcast. The podcast is actually only improving. So, we're

excited about that. And we're very excited about today's episode. We are

doing something that I would wager has never been done in the history of the world, which is that we have created a March Madness bracket of every book and

essay we have ever read, and we are going to compare them against each other. Now, if you've listened to any of

other. Now, if you've listened to any of our sort of ranking videos in the past, you know that Nathan and I's opinions on what we've read tend to be we tend to like the same stuff, but sometimes how

much we how much we like it can differ between one or the other. So, I knew we would need some tiebreers. So, I want to take the moment up top to thank three of our super fans. If you remember, I I issued a call for super fans in a

previous episode who took the time to rank every episode we've ever done on a scale of one to five. And should we need a tiebreaker, uh we will sum up their rankings and compare them against each

other and and for some of the uh books, they've even provided a couple comments of their own. So, we'll make sure to read that. But we want to shout them out

read that. But we want to shout them out at the beginning of the episode. And

with their permission, we've included their LinkedIns in the episode description. So, please go connect with

description. So, please go connect with them and like when you connect with us, just uh say that you're from Book Overflow and we'll let them accept or reject as they choose. But this is Jose Viala. And this is where I get to

Viala. And this is where I get to butcher your names like I butcher the author's name. So, please forgive me

author's name. So, please forgive me guys. So, Jose Viala, David Johnson, and

guys. So, Jose Viala, David Johnson, and Nick Severincip.

So, Jose, David, and Nick, thank you so much for filling out your uh answers. We

will use them if we need them, but Nathan and I have not walked through this together. We don't know how this is

this together. We don't know how this is going to go. And there's also no criteria for like what makes a book better than another one. This is

completely subjective. We're just making this up. So, you know, let's see how

this up. So, you know, let's see how this goes. Nathan, how's this going to

this goes. Nathan, how's this going to go? I I have no idea. I I'm I'm uh I'm

go? I I have no idea. I I'm I'm uh I'm learning as we go just like the rest of the audience is. So, I'll be the representative of the audience that's uh also educated since I was actually present at all of these episodes. So,

[laughter] >> okay. So, I'm using like this bracket

>> okay. So, I'm using like this bracket website. I'm not going to like share it

website. I'm not going to like share it or anything like that. Um but if I can't figure out how to move things between the different rounds, I don't know. I'll

just do it manually. Um, this was completely randomly generated and some of the seating is brutal, so we're just going to go with it. And we got a lot of books to get through. This is literally

everything we've ever read. Books and

essays. Um, so we're gonna we're gonna find out how this goes. So, Nathan, this is a five. Let me see. This is six

rounds. Six rounds in total. Um, round

rounds. Six rounds in total. Um, round

one, I think about half the books got to buy and only start competing in round two. But some unlucky books do have to

two. But some unlucky books do have to begin in round one. So, let's start with two of those unlucky books. And one is quite unlucky. Uh, Hyper Media Systems

quite unlucky. Uh, Hyper Media Systems versus 99 bottles of OOP. Oh, [laughter]

>> well, you know me. I'm I'm a I'm a I'm a fanboy of HTMX. So, that's a HTMX is the clear winner in my book. [laughter]

Yeah, I I 99 Bottles of OP is literally the only book in that we've ever read that we just quit reading halfway through because we didn't like it. So, I don't

think we need to deliberate on this one too long. Um, yeah, this is Hyper Media

too long. Um, yeah, this is Hyper Media Systems right?

>> Yep.

>> Okay, let me see. I'm submitting the scores. Okay, great. So, I gave Hyper

scores. Okay, great. So, I gave Hyper Media Systems a score of one and OP a score of zero. So, that has advanced to round two. Okay, let's get through some

round two. Okay, let's get through some of these other ones. Okay, this is interesting. The practice of programming

interesting. The practice of programming versus radical cander.

>> Oh, not fair. Oh man,

>> this isn't fair at all.

>> Um >> uh >> are there crit are there objective criteria that I'm supposed to be, you know, is there a rubric or >> there's nothing. This is

>> subjectively which one did you enjoy more?

>> Um uh the practice of programming this book overflow of lore. Literally our

first episode, not the first book we ever read. That was a philosophy of

ever read. That was a philosophy of software design, but um the first one we released was Practice of Programming and Brian Kernahan came on the book or came

on the podcast. I really really enjoyed Radical Cander. I had my criticisms with

Radical Cander. I had my criticisms with it, but it's a good read. There's a lot of applicable advice. Yeah, I've been using radical cander a lot actually like

as a framing of having conversations espec specifically ruinous sympathy but I'm going to I'm going to go towards practice of programming partially because um I'm also a huge fan of Rob

Pike which we have not had on the podcast.

>> I know he's a white whale for us.

>> Yes. I mean, I would love to have Rob Pike on. Um, but I am a huge fan of the

Pike on. Um, but I am a huge fan of the Go programming language and you can see the sort of the seed that was planted.

Uh, and and Brian Kernahan I the book's so well written even though some things are dated. Uh,

are dated. Uh, >> it's it's not a fair comparison though.

One is incredible career advice. The

other one is incredible sort of like advice on craftsmanship of of programming. So, I'm going to go with

programming. So, I'm going to go with practice of programming. So,

>> you know what? I'll join you. I We've

had Ryan Kernahan on the podcast twice.

Um he's one of my favorite people we've ever interviewed. Um it's been a long

ever interviewed. Um it's been a long time since I've read this, but just this is getting the nostalgia points for me.

I love Brian Kneahan and how can you how can you boot the first book we ever read out in round one. So

>> yeah, there's some nostalgic biasing the the score here for sure.

>> Right. Again, this is it's whose line is it anyway? The points are made up. Score

it anyway? The points are made up. Score

doesn't matter. Um so sorry Radical Cander. That is a rough draw, but

Cander. That is a rough draw, but practice the programming advances.

>> I used my radical cander to make my decision though. So that was [laughter]

decision though. So that was [laughter] >> okay. Here's one. Uh, the fundamentals

>> okay. Here's one. Uh, the fundamentals of software architecture by Mark Richards and Neil Fords or the software engineers guide book by your

>> Oh no, >> this is brutal. How did this happen?

H >> I I love software engineers guide book.

Like I I mentioned on the episode that like so many of the lessons I had to learn through like years of trolling Reddit and Twitter or

mistakes in my career. All that

information is just there for you in software engineers guide book. But

here's what I'll give fundamentals of software architecture. This is one of

software architecture. This is one of the ones we've announced we're going to be rereading some books in the upcoming year. This is the one I've been most

year. This is the one I've been most excited to reread.

>> Right. Yeah. And I actually have uh they also have Surer Architecture, the hard parts. I actually threw that into our

parts. I actually threw that into our backlog because that's another one of their books. Um I'm actually going to go

their books. Um I'm actually going to go with fundamentals of software architecture. So I think we need a

architecture. So I think we need a tiebreaker from a super fan.

>> No, I'm going to give it TO FUNDAMENTALS.

>> REALLY? OH WOW. OKAY.

>> YEAH. YEAH. I I love software engineers guide book. I love G. It's so cool for

guide book. I love G. It's so cool for him to come on the podcast, but like >> Fundamentals of Software Architecture is just one of the books that I think can level up your career.

>> Mhm.

>> In a huge way. Like just getting exposed immediately to all these different architecture types and like we're doing some stuff at work right now where we're we're toying around with like event- based architecture and like that's

something that is kind of top of mind because we read this book and >> interesting.

>> Is great but >> but I'm going to give it to fundamentals. So

fundamentals. So >> I I was actually recently working with a sub a subcontractor with some work who are they're making the transition event based and uh it's such a fun domain of problems to solve. So yeah

>> we're really excited and we're trying to make sure that it is the right solution for our problem and to not overengineer it but we're becoming more and more confident about it.

>> Okay, this is I think the most brutal of all the seating and I haven't looked at all the seating but this one stuck out to me. Clean coder by Robert Martin

to me. Clean coder by Robert Martin versus a philosophy of software design by John Osterho.

>> This is cool.

>> This is a no-brainer on my side. I'm I'm

team Oster Hel, but I'm an Oster Hell fanboy. So, [laughter]

fanboy. So, [laughter] >> I know that's why I'm saying this is cruel because I really like Clean Coder.

I believe it made my top five last year.

>> Um I think I know Uncle Bob and some of his advice can be controversial. Uh but

Clean Coder I think is a really good vehicle for it. I appreciate some of the more narrative driven stuff. There are

so many books in this list that I would put clean coder over, >> right?

>> But but I can't do it over a philosophy of software design. I think a philosophy of software to design is >> really really well written. It's uh

it'll really challenge a lot of your assumptions about how to make software.

Um, and again, it was the first book we ever read.

>> I can't I can't award it. I can't award clean coder over it.

>> It It's It is interesting because like I really appreciate Uncle Bob's contributions as well. Like it's not a it's not a statement against and I think Clean Coder I have I still haven't read Clean Code, which is the controversial

book. Clean Coder is actually not a

book. Clean Coder is actually not a controversial book. It's actually full

controversial book. It's actually full of excellent advice um regardless of coding style, right? It's like a a way to have accountability in these other pieces. But um little fun fact in my

pieces. But um little fun fact in my first newsletter, uh the piece of wisdom actually comes from a quote from John Osterhel talking about so uh design it

twice. Uh it was a question that Carter

twice. Uh it was a question that Carter actually asked and there's a great little nugget of wisdom in there. And so

um yeah, cool feedback loop in general.

>> Yeah, this is a philosophy of software design. So all right. Oh, we're so

design. So all right. Oh, we're so sorry, Uncle Bob.

That was a draw.

>> I also put on our um backlog for next year. I don't know when we're going to

year. I don't know when we're going to read it, but uh >> Uncle Bob has like the Yes, the Wii programmers the history of programming.

Uh it looks it looks like such a wonderful book and I I I would really hope we can read it and then have Uncle Bob back on to talk about it because he seems so passionate about it. So that

would be really cool.

>> Okay, two essays. These got pitted against each other. So, we've got uh number one, worse is better, or number two, the Dow of Programming.

>> Oh, brutal.

>> Yeah. [sighs]

>> Like I like funny stuff and we don't get to read enough funny stuff on this podcast and the Dow of Programming cracked me up.

>> Yeah. No, for sure. And it again I also have like a fondness for I've read so much Alan Watts and the Iching and other things over the years that I've I'm like

into the Zen and uh Da De Jing type stuff. So um

stuff. So um but worse is better is so important. Um

I'm going to do this. I'm going to take a contrarian view on whatever you pick because I want to see what our tiebreaker is.

>> We want to see what our what our listener said. Okay.

listener said. Okay.

>> Cuz I'm I'm split 50/50 on this one actually.

>> Okay. That's fair. You know what? I I

could I could go both ways. So, we're

going to pit this one to the listeners.

Okay. So, let me see. I just want to make sure I I get attribute everyone's comments appropriately. Okay. So, let's

comments appropriately. Okay. So, let's

start with Nick. So, for worse is better.

Uh he gives it a four.

Uh no comments, just a four. Okay.

>> Okay. I'll write this down >> for the Dow of or sorry, for worse is better. This is Jose. He gives it a

better. This is Jose. He gives it a five. Oh, it's gonna be tough to beat.

five. Oh, it's gonna be tough to beat.

David Johnson gives it a three. Uh, so

no comments from any of them. Okay, so

that's 12. All right, remember that number. Okay, for Dow programming,

number. Okay, for Dow programming, >> we get a three from Nick.

We get a three from Jose.

And uh we get a two from David Johnson.

>> So there's a clear winner.

>> Care for Yeah. He said, "Do not care for this. Need more D in my life."

this. Need more D in my life."

[laughter] Um so 12 versus eight. All right. Uh by

virtue of the audience, we are going to award it to worse is better.

>> Yeah. Which that doesn't make me mad.

That's a that's a that's a great great essay and it had a huge impact on the industry.

>> Under pressure. I might have given it to DA, but that's why that's why we had the listeners. We got to we got to see their

listeners. We got to we got to see their scores.

>> Yeah. Okay. Uh, all right. Advanced

React versus Made to Stick. I'm I I can't uh I I can't I I love Made to Stick. I love it. Love it. Love it. Love

Stick. I love it. Love it. Love it. Love

it. Um Oh, man. I'm I'm going to I'm going to go with that as well. I

think Made to Stick Made to Stick as far as like it has so much staying power. I mean,

the book's been written many years ago.

And, uh, also, again, if you're an author who's come on the podcast, uh, you're going to get you're going to get a little bit of bias from me as well.

[laughter] >> Yeah. I mean, with me doing this new

>> Yeah. I mean, with me doing this new theme park podcast, um, it was motivated by the comments from Dan Heath where he's like, you just got to do what's most fun, >> and if it's the most fun, you'll work

the hardest on it, and you got to trust that flywheel that good things will come. that that pushed the that pushed

come. that that pushed the that pushed me as well. I mean, I was on the fence.

I was actually interviewing for some other jobs. Um, and I was also thinking

other jobs. Um, and I was also thinking about I've been kind of like sitting on the fence thinking about this since I guess October I think is when I started talking to Carter you about this and um

that actually that and one other piece of feedback from one of the job interviews that I gave actually interviewed with one of the the CEO for a a job fit and he was just like why don't you just start your own thing? It

was like it was at first I was >> I was like seven interviews in so I ended up failing getting the job because he's just like no on culture fit >> but he gave me beautiful feedback as far as just like dude do your own thing man

like it was very like it was like the most positive rejection I've ever had.

So >> that's nice. Yeah. And yeah I love Made to Stick and I don't want to talk about it too much because we're going to keep comparing against other books as we go

on. Um, and I have a feeling just for me

on. Um, and I have a feeling just for me that Made to Stick is going to make it uh very far in this round or in this bracket.

>> So, um, we'll give we'll we'll save some of its flowers for later, but yeah, Made to Stick wins this.

>> Okay, next.

>> The Agile Manifesto versus Tidy First.

[sighs and gasps] >> I think I give it to Tidy First here. I

think he's read the Agile Manifesto more as like a history exercise. Mhm.

>> Um, and it's cool to see where a lot of the thinking around agile originated.

Um, but Tidy First, I think is a really great book that talks about kind of the the business constraints around programming and like when does it make sense to make things better and this

idea of like optionality and programming that as you if you structure your code well, you give yourself options about what you can build and those options around what you

can build have like direct monetary value. Um, lots of interesting thinking.

value. Um, lots of interesting thinking.

I love any book that kind of ties um the technical aspect to like the how does this make money aspect. Um and Ty first does that in a very interesting way.

>> Yeah, it's you know in a way we're kind of comparing a thought system to itself because Kent Beck is also signatory on um but I will say you know it would it

would tell you something if an idea from 25 years ago had more weight than newer thinking from one of the signitories on the agile manifesto. And I think Kent

Beck shows his evolution in his thought process really well because Tidy first is contemporary but still has that sort of like lineage from the agile manifesto. I I think it's more

manifesto. I I think it's more applicable these days. I think that agile manifesto really was a moment in time when they were trying to kill waterfall once and for all and tidy

first tidy first gives you a framework on your like how do I prioritize cleanup versus feature development and what's actually going to move me forward and yeah I'm in agreement tidy first

>> we give it to tidy first okay >> y >> that completes round one >> we now quick >> so yeah so so that was only about half the books or half of what a normal round

size because uh a couple of the ones in round two I've got in buys. So uh yeah, now we're moving on to round two. Let me

see how many books remain. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 32. Okay, so 32 books remain. And this is a traditional

books remain. And this is a traditional bracket at this point. It's just 32 and it halves at each round. Okay, so Hyper Media Systems returns against working

effectively with legacy code.

Huh.

I found both of these books while enlightening some of our less pleasant reads. And I don't mean that as

pleasant reads. And I don't mean that as a a dis. We we've just talked about kind of again the end to end test like how enjoyable is this book to read end to end. Both these books are very

end. Both these books are very technical. um working at Factory with

technical. um working at Factory with Legacy Code in particular, I just have this awful memory of like and this is my fault. I put off reading it and so like

fault. I put off reading it and so like the night before the podcast I had to read like a hundred pages of this thing.

Um and again, it's a great book and I think about it all the freaking time at work. But um

work. But um >> yeah, so I but I think it's more useful than Hyper Media Systems. I'm sure about that.

>> I was about to say like from a staying power standpoint, I I found hyper media systems enjoyable from a contrarian hottake, but how many of those ideas can

I generally apply? I think legacy code um legacy code is applicable because it it gives you techniques and tactics to

deal with these train wrecks that you might run into. And

>> um every co every bit of code will end up becoming legacy code especially if the test coverage isn't where it's supposed to be. Right? That's just kind of >> the book that kind of it taught me like hey um you don't it's it's not normal to

be scared of your code base. Like if you are scared of your code base and you're scared to touch it then you're working with legacy code and you need to deploy all these tactics

>> to fix that. And so

>> Exactly. Exactly.

>> Yeah. Yeah, that was a really good reframing in my mind of of how to work with legacy code bases. So, yeah, I'd give it to working effectively with legacy code here. Are you agreed?

>> Same. I'm in agreement. So, so far so good. But I can see now these brackets

good. But I can see now these brackets are going to get brutal as we get >> further down cuz it's all going to be our favorites. [laughter]

our favorites. [laughter] >> I know. I wonder do I wonder if listeners, let us know if this would be a fun tradition each year if like every year the bracket just gets bigger and bigger and we just do everything we've

ever read against each other. Um, okay.

So, this next round will determine who matches up against working effectively legit code. Next, we have thinking like

legit code. Next, we have thinking like a large language model versus refactoring by Martin Fowler.

>> Refactoring.

>> Refactoring. Yeah, refactoring is a classic. Um,

classic. Um, I I think this is another one like when we talk about like the central ideas you get out of this book. This book helped me understand that refactoring shouldn't be something that you should be able to

stop refactoring at any point. You

should refactor in such a way where you're just making small changes and you're running the test constantly. And

so if you need to stop in the middle and move on to something else, it's not like like we just hear all the time like, oh, I need three days to refactor this thing and oh, you can't I'm not done yet. And

so I think this really anyone who uses the term refactoring needs to read this book. And I am a stickler now for the

book. And I am a stickler now for the proper terminology of refactoring which is to make you change something without changing its behavior. I hear too much refactoring where you're actually rewriting the application.

>> Right. Yep. Agreement. And I think I think we'll see a bias here that breadth versus depth. I think if we pit up,

versus depth. I think if we pit up, >> yeah, >> breth that has longevity, it's probably going to be a favorite of the two of us.

Um, but that may not always be true, so we'll see.

>> Okay, refactoring wins. Okay. Oh, I

don't like that we have to compare these two. Staff Engineer by Will Larson

two. Staff Engineer by Will Larson versus Groking Concurrency by Cyro Bov.

Uh, these are both really, really good and very, very different from each other.

I enjoyed staff engineer more, but I also just tend to enjoy some of our more career focused stuff. Um, some of that's selfish, like it's easier to read.

Groing concurrency is very well done and his drawings in it are really fun and I think I don't know.

I think you we got to put respect on its name for taking a very heavy technical challenge or technical concept and really explaining it in depth and doing

it consistently well throughout the entire book.

>> I certainly re recommend Staff Engineer to more people, but there's not a concurrency book in the world I'd recommend over rocking concurrency.

>> Yeah, this is a this is a coin flip for me. I

I think I agree with you as far as like the general applicability and I also like Will Larson's um his newsletter is phenomenal. I don't know if you're

phenomenal. I don't know if you're subscribed to it as well, but I I I it was a few months back actually I realized that it was the same person like I've been reading his newsletter

for a while. Uh

and I think that that biases but I'm actually going to pick groing concurrency. Uh so that's where I think

concurrency. Uh so that's where I think we might need a tiebreaker. I think I we're going to do a tiebreaker. I I

cannot bring myself to pick between these two, so I'm going to make the audience pick.

>> Yeah, let's get the audience to pick.

>> Nick says, "Groen, he has a five." He

writes, "Wonderfully well written and a joy to read. Quite an achievement considering the subject. I also love the wholesome illustrations." Okay,

wholesome illustrations." Okay, >> so that's a five from Nick Jose gives it a four.

>> Okay.

>> And David Johnson gives it a four. He

says, "Pretty specific topic, but I really enjoy the conversation on it."

Yeah, >> help me with rethinking some code and suggesting ideas to my team. So, that's

a five, four, and four. Okay, that's 13.

Oh, that's going to be tough to beat.

Okay, staff engineer. Nick says two. Oh,

that's interesting. I'd love to know why that got so low. Um,

five from Jose.

That's seven.

And four from David. Okay, so that's close.

We almost had a time to get it. Uh,

we're gonna have to We'll have to shout out Kyle for that because Kyro, that is a huge accomplishment to beat >> Yeah.

>> Will Larson. Um,

>> if I had to guess, um, and I think this is great from our sample size, we're if you're a little more fang or Mang and Silicon Valley centric, I think that

staff engineer probably resonates with you more. And if you are in the industry

you more. And if you are in the industry outside of that world, it's less because it's very much speaking to the career path, you know, dual track kind of world and that doesn't exist for everybody.

Um, and so I think that's fair and I'm really glad our audience kind of, first of all, both of these books had very high favorability, but Groing seems like it resonated well. That's awesome. Well,

congrats.

>> Huge, huge accomplishments, Cairo.

That's uh we'll see how far you go in the bracket, but to to beat out Will Larson, incredibly impressive. Okay,

next one. The Unicorn Project by Gene Kim versus Web Scalability for Software Engineers by Artur Edgemont.

I've wanted to have Artur on the podcast for a while. I think he's one of the few authors I've reached out to multiple times and I've just never been able to to get a hold of him. Um,

Unicorn Project.

I I really really like these. Like I I think Unicorn Project and Phoenix Project. I'm off to read Phoenix Project

Project. I'm off to read Phoenix Project one day. Like the narrative structure is

one day. Like the narrative structure is fun. Uh web scalability would win it for

fun. Uh web scalability would win it for me if there was a second edition because web scalability is a little outdated at this point. We talked about this like no

this point. We talked about this like no talk about Kubernetes, no talk about Docker, no talk about like service discovery, >> right?

>> Uh I don't know. What do you think?

>> I'm clearly on the DevOps side of this.

So I'm going to be I'm going to be unicorn project. It's got a special

unicorn project. It's got a special place in my heart. So, I'm biased, but I'm unapologetically biased. I'm going

to pick Unicorn Project.

>> Yeah, I think a second edition of Web Scalability could really win it for me.

Um, but I'll give Project here, too.

>> Yeah.

>> Um, Arur, come on the podcast. Redeem

yourself.

>> He's listening to the podcast who won't come on it. Like, [laughter]

>> and uh and Jean Kim, if you want to um you know, have a fighting chance for the next bracket, you gota you got to come on, too. So,

on, too. So, >> um Okay.

Rework versus the practice of programming.

>> Oh, rework.

>> Rework.

>> I know.

>> I give any I give I give extra points to any book where I feel like I had an epiphany with it. And yeah,

it. And yeah, >> Rework was another one. This I read this one right after getting laid off at my last job and looking for another job.

And I I know Dan Heath were giving a lot of credit for this idea of like do what's fun, but rework really made me think like, hey Carter, you you have plenty of money and you have a lot of

opportunity and so why why are you like trying to like max out compensation or prestige or whatever. Like just do what sounds fun. Do what you think

sounds fun. Do what you think >> would be an enjoyable way to spend 40 hours a week. And so this was pivotal me taking my current job, which I have not regretted. So I for me I would give it

regretted. So I for me I would give it to rework and I I hate to do that to our friend Brian Kernneahan but >> no no this is also our friend.

>> Yes. Exactly. And I'm I have a fondness for 37 signals much some of my friends should grin that they're just like please stop talking about how cool they are. But

are. But >> yeah I'm I think I'm going to go with Rework 2. It it

Rework 2. It it >> that's brutal. pulls it pulls two different parts of me and I think it is it's kind of weird to have a the business and like sort of motivation

inspiration side of things versus the practice of programming which is again it's in the like ivory tower upper echelon but I'm going to go with rework.

This is controversial. Let's do it.

Let's own it. Let's own it.

>> Do rework. I think if we do this again next year, I think we'll have regions and we'll have because we we kind of talk about like we have our culture and career and technical and so maybe we will pit those guys against each other

until they they match up in like the semi-finals or something. So, but hey, bracket is already made. This train has left the station. So,

>> it's a global bracket. Yep. Here we go.

>> Okay. Team topologies versus finite and infinite games.

>> [gasps] >> I can't >> as much as as much as I loved finite infinite games as a troll to you a after the fact um I'm gonna obviously team topologies is like super it's actually

become really important in my consulting stuff too because I do think that uh you know these these optimizing for flow oriented you know feature development and stuff is is actually a really

important part of how I'm engaging with folks so u yeah >> team is awesome >> I've been able to use it as much ever since I joined a startup where we have one software engineering team. But as we

grow, I'm going to come back to this a lot. And uh like we said, Finite

lot. And uh like we said, Finite Infinite Games is just the episode where you trolled me. So um [laughter] I can't >> It wasn't intentional. It wasn't

intentional until I got like a two chapters in and I was like, Carter's going to hate this book so much. And

you're like, I hate this book.

>> Our audience said like, we want to hear more from you guys when you don't like something. And and they've got that in

something. And and they've got that in uh in flying colors in in that episode.

Okay. Team topologies wins. Moving on.

Mastering open telemetry by Steve Flanders versus Fundamentals of Software Architecture by Mark Richards and Neil Ford. Oh,

Ford. Oh, look, I I appreciated Mastering Open Telemetry. Um, I think it was really

Telemetry. Um, I think it was really cool that it was written by Steve Flanders who like like listen like fundamentals of software architecture has a lot of great thoughts on event driven architecture, but uh Mark Richard

Neil Ford did not invent event driven architecture. to read Mastering Open

architecture. to read Mastering Open telemetry by one of he doesn't call himself the inventors but the founding member of Otel um is really really really cool but we

also talked about this book where it's um there's a lot of content to it and it's designed a little bit to be more reference material we talked about how

maybe it could have been a little more focused to a specific audience fund fundamental software architecture is a book I feel like I give to almost anyone and they get value out of it. Mastering

open telemetry is a book where I think you'll only get value out of it if you have some very specific questions about open telemetry.

I don't know if that's fair to criticize it on that dimension, but those are my initial vibes.

>> Yep. I I I think from a lasting power standpoint, I I think we're already seeing this too. He's Steve Landers actually has had some really good LinkedIn posts about where things are

going. And for instance, how do you do

going. And for instance, how do you do large language model agentic telemetry is just different. um how do we get context from you know uh rum stuff with

in the browser up into the other things those are still unsolved which means the book will be outdated there needs to be a second edition that comes out in a couple of years where fundamentals software architecture it's got lasting

power so I think that kind of tips it in how it's written so I'm in I'm in the same boat fundamentals software architecture >> and that taught me the term distributed monolith which uh I have seen so many times

>> oh yeah that's such a could own I mean if you just like >> mic drop on somebody be like >> this is a distributed monolith >> I'll be like this is the worst of both worlds like

[laughter] >> okay what is chat GBT doing and how does it and why does it work by uh Steven

Wolram versus beyond vibe coding by addi >> gosh >> these are interesting are two AI books >> yes they're two AI books they're evenly

matched it too in that they really expand upon concepts that you kind of have been wondering about but you didn't know even how to verbalize you know like I didn't even know how to start asking

how does a large language model work until I read Steven Wolfram's book and I'm like oh wow I learned so much I think I got a honestly reading the LLM

Wolram's book helped me with beyond vibe coding because I I >> um >> I I would give this to wool from um I have this is another one which I've been

very excited to reread. I remember

understanding like I really really understood the parts about like it explaining that large language models are guessing machines and and talking about temperature and how it assigns the

next token and then it got into like the mathematics behind the transformer model and that kind of went over my head and so I've been excited to read this one again because I I just want to

understand that a little better. But I

think in this era of AI, >> I I have recommended this book several times to people and I've said like you really should understand what's going on underneath the hood here. It makes your

ability to work with these tools. It's

much more intuitive. Um I'd give it to Stephen Wolf from here.

>> Yeah, I I found that the beyond vibe coding though has been more applicable to specifically what what he calls context engineering.

Like >> I'm going to actually pick Beyond Vibe Coding. So I think we need a tiebreaker.

Coding. So I think we need a tiebreaker.

>> Okay, we got to go to the fans.

>> I agree with all of your arguments, but I still think that Beyond Vibe Coding has had more help in 2025 for me. So

>> okay, so Nick gives What is Shajb Doing a five. Said this one I've actually read

a five. Said this one I've actually read or this isn't one I've actually read, but it's at the top of my reading list.

I like to understand how the systems I use work under the hood. And from your guys' review, this feels like a great entry point. It is a great entry point,

entry point. It is a great entry point, Nick. Okay. Um

Nick. Okay. Um

Oh, Jose gives it a four.

>> Okay.

>> And David gives it a two. He called it niche.

>> Interesting.

>> Okay. Okay. Okay.

>> That's 11. Okay. So, we got a fighting chance for um >> Did they find Beyond useful or hype machine? So, let's find out what they

machine? So, let's find out what they they >> Oh, Nick gave it a one. [laughter]

>> Yes.

>> Sorry. Sorry, Addie. Uh, but Jose gives it a four. That's five.

>> And uh, David gives it a three. Says,

"Bought the book and started reading.

Episodes were great. Made me excited just having imple just just having he says having implemented anything from it." But I'm guessing he said meant

it." But I'm guessing he said meant haven't.

>> So that's so so what is that? That's

four, one, and a three. That was an eight. What did the other one get?

eight. What did the other one get?

>> Uh, five, six, seven, eight, nine, 10, 11. So

11. So >> 11. Okay, chatbt wins.

>> 11. Okay, chatbt wins.

>> Okay, thank you.

>> I'm not mad with that. I I think the audience that's a fair assessment. Um

>> yeah, I think uh also Wolram's interview was so cool. I I got to I got to fan out on that one, too.

>> I've been trying to get Addy on the podcast. We are mutuals on LinkedIn, but

podcast. We are mutuals on LinkedIn, but he's a busy guy, as you can imagine. Um

okay. uh building evolutionary architectures by Neil Ford, Rebecca Parsons, Promote Satal, lots of uh names and a philosophy of software design.

>> OH NO, >> the book that started the podcast versus the book that broke the podcast. Uh

building evolutionary architectures, if you aren't familiar, is the book where we tried to finish it in one week. It

was like 180 pages and we had been trying to do 200 pages a week and we're like this is too deep. And so that's when we started setting a strict 150 page limit for ourselves.

>> Um I I love building evolutionary architectures. I wish I were in a role

architectures. I wish I were in a role where we needed this more often. We're

still flying by the seat of our pants a little and there's just enough lowhanging fruit on like kind of the traditional DevOps side that >> we haven't really needed something like this. I can see how this book would be

this. I can see how this book would be so stinking useful, especially if you're at like a scale up or, you know, maybe like a series C, series D company that's growing rapidly. Um,

growing rapidly. Um, but I how can how can we go against Sean Oserode here for on a philosophy of software design?

>> It's funny and it's brutal because I quote both of these books all the time.

Like I literally I was having a conversation with a founder. So it's

funny I have this idea of like and this has kind of been the core of Robo. I

want to shift left on these DevOps practices for evolutionary architecture for earlier stage startups because I've seen these >> I've seen these really awful growing

pains and you don't you want to dance on the edge of not being premature optimization but giving the ability to evolve a system and I was actually the CEO is actually an architect and so we were talking about I was like you know it's like if you build a building I

would imagine if you knew you were going to do an expansion later he's like oh yeah you you terminate plumbing and the power you you you put it there because you know that you're going to build onto the building later. And I was like,

that's exactly what building an evolution architecture is. You just say, I'm not building this other building right now. I don't even know what the

right now. I don't even know what the building's going to be, but I might want to. And so, it's just easier to wire up

to. And so, it's just easier to wire up the stuff so that I have the choices later. And there's a lot of really

later. And there's a lot of really interesting things where you just put a little bit extra effort and you do a little bit more. And so, I I talk about evolutionary architectures all the time, but I talk about philosophy of software

design more.

And I I so so I I think this I think Oster House is going to win for me >> even though I have had so much wonderful use out of evolution architectures really.

>> Yeah. We talk a lot at my work about that threading the maturation curve which is like how do you >> Yeah. How do you not prematurely

>> Yeah. How do you not prematurely optimize? At the same time, I think

optimize? At the same time, I think there are some decisions that have been made at my company and just that are made in general where it's like you should have done this from the beginning. And you know, like it it

beginning. And you know, like it it maybe would have looked a little premature at that point, but if we had just done something like this from the beginning, we would not be having all these headaches right now. And building

evolutionary architectures helps you understand what some of those decisions are and when to make them. Um, but I'm giving I nostalgia. Nostalgia wins. I

cannot in in this round give it to anything but a philosophy of software design.

>> This this is hard. I this is good. We

need to we need to have hard conversations. This is this is important

conversations. This is this is important for our health.

>> This is Radical Cander, a book which we eliminated in the first round.

>> Yeah. [laughter]

>> Oh, it's brutal.

>> Okay. Recoding America uh by Jennifer Pala versus Just for Fun by David Diamond and Linus Torvalds.

like Recoding America was interesting.

This is one of the few books that I consider a bit of a whiff on the podcast. I I felt like we I think we get

podcast. I I felt like we I think we get devoted two episodes to this and maybe didn't resonate with our audience as much as I would have liked it to. I

really enjoyed just for fun. I think

about this all the time. Just the other day at work, I to announce the reveal of our baby. Um,

I set up like a fun kind of like treasure hunt, but I embedded I cleared this with with our manager before doing this, but I embedded it in one of our internal tools. And so just like on like

internal tools. And so just like on like one of the tabs you could choose from on the side showed up in different color, it showed up as treasure hunt with three question marks. And then that linked out

question marks. And then that linked out to another to a website I had built. And

but I to make sure that no one knew who did it, I just changed my git username on the commit and my email to anonymous and it made people flip out and like and

our manager and CEO jumped in the Slack thread immediately and were like, "Hey, don't worry. This is not a threat. It's

don't worry. This is not a threat. It's

not a security vulnerability. This is

someone internally at the company did this."

this." >> Hilarious.

But >> one engineer in particular was upset that that had happened. I was like, "I don't know, man. take it up with Linus Torvalds. He invented Git. Like why why

Torvalds. He invented Git. Like why why did he, you know, why why does he let you change your username willy-nilly on a commit? Um anyhow, long story, but I

a commit? Um anyhow, long story, but I like just for fun. I think it was really really cool to figure out how Linux uh was created and I think it was really cool to learn about Lionus and and who he is as a person. Um

>> Yep.

>> So I gave it to this just for fun.

>> I I loved Recoding America. I think

Recoding America was actually a recommendation from Brian Kneahan.

Yes. And I learned a lot actually about it was kind of cool to see that Obama era where there was these brighteyed and bushy tailed folks who were like, can we

make government work? Like can we actually like inject stuff? Um, so I thought that was an interesting glimpse, but and I guess maybe we're a just for fun oriented podcast because we keep

bringing this up of like, hey, let's have more fun. It's not all about money and not all about these other things. Um

I Linux and Linus Torvolds and the whole story behind it was huge. So I that one wins for me too. Just for fun is the winner in my book.

>> All right. You know if we do this bracket again and like let's say like our my startup goes bankrupt and Rojo Robboto doesn't take off and we're like and we're just like screw it. All these

books that told us have fun >> these books are getting last place. like

>> right [laughter] >> it won't happen because >> I'm going to get a I'm going to get a sweepy emo blackhaired you [laughter]

>> um okay uh system design interview by Alec J versus Worse is better by Richard P Gabriel worse is better has more interesting

ideas that explores system interview is very useful and there are some things I've really taken away from this like um we talked about this uh about like and I I think our accountability episodes like

back of the envelope math like this is something I find I've been doing a lot of systems design interviews for we're hiring right now and um I wish candidates would do this. I wish when they're talking about like what database

to choose that they would be doing some back of the envelope math about how much data we'll be storing and what you know how much we think it'll grow and especially if any candidate can start

busting out like the different pricing tiers on AWS like you know even if you have like ballpark numbers like this is a for a startup these are really important considerations to us and I'm

I'd be very very impressed if any candidate did something like that Um, so I like that. Um, worse is better is more timeless. I don't know. What do you

more timeless. I don't know. What do you think?

>> I'm picking worse is better.

>> Worse is better.

>> Yeah. And the reason I'm choosing worse is better is Yes. I think from a impact on the industry, it was really opened up some great discussions. Um, if you're getting ready for a systems design

interview, that's exactly the book you should be reading. Like these this is where your brain should be.

understanding back of the envelope stuff, um, understanding the sort of like the dance, >> but again, it's very Silicon Valley oriented in that

>> it's part of that courting ritual.

>> Um, you know, that's I will tell you that I did I did an interview track recently where I should have read through this book because I didn't realize that we were going to do system

design interview stuff and um, I winged it and it was fine. Like I actually I ended up getting uh like an offer, but um I also know I didn't perform at the

level that I should have because I was like, "Oh yeah, there's like a game to this and I should have done that." But

I'm going to go with worse is better whimsically.

>> Worse is better. I don't feel strongly enough about system design interview to disagree. Okay. Worse is better wins

disagree. Okay. Worse is better wins that. All right. Thinking in systems

that. All right. Thinking in systems versus looks good to me. Uh looks good to me. I really like looks good to me

to me. I really like looks good to me and I really like this. one of the few times this and like Kyro Bob we've gotten to highlight a new author on the podcast. Um

podcast. Um >> Adrien Bonza uh wrote the comprehensive book on code reviews which I did not think could be done and she did it.

>> She did an awesome job. Yeah.

>> And thinking in systems is the one episode where a listener said you guys could have read Dune and had the same episode because we just talked about so many things that weren't the book.

>> Um >> yeah. Um,

>> yeah. Um, >> yeah, >> I I understand the importance of the systems uh book, but I'm also I'm gonna be in the I I I think I I think I see

where you're going with Looks Good to Me was the winner in my book. So,

>> yeah, I'll give it to Looks Good to Me.

Great work, Adrian. Um, I feel like this book that book has come up several times in the podcast and Adrienne Bonza as well. Um, about just uh

well. Um, about just uh >> my my daughter made a Python joke the other day uh and she goes she goes, "Dad, 1 + 1 is 11." And I was like I was

like, "Okay, tell me about this." She's

like, "Yeah, if it's a string cuz in Python you can add the the string of one plus the string of one, it makes 11."

And I was just like, "This is the nerdiest thing you possibly could have said." And it's because of Adrien Bonza

said." And it's because of Adrien Bonza also wrote a beginner's Python book. And

Lyra loves it. Like that's awesome.

>> Yeah. Yeah.

>> Okay. H this is brutal. The DevOps

Handbook versus Made to Stick.

>> This isn't fair. These two should match up in like the >> semiinal. I'm going to be on I'm again

>> semiinal. I'm going to be on I'm again my bias is my bias is uh DevOps stuff.

So, I'm going to pick DevOps Handbook. I

think I know where you're going to go with this, which means >> I I got to I got to do Made to Stick. I

love Made to Stick. I think

>> And >> I'm not mad that that's your conclusion, but I but I the DevOps handbook again has also been really important for me for getting the consulting stuff off the ground. Um,

ground. Um, >> this is brutal. We're going to make the audience do this. Um,

>> yeah. So, blame it on Nick, Jose, and David if you don't like >> Okay. I should have remembered the

>> Okay. I should have remembered the scores they gave to each one of these.

Um, but actually maybe we haven't done this. Okay. Uh, Nick for Made to Stick

this. Okay. Uh, Nick for Made to Stick gives it a four. Says, "This is pretty high off my reading list. I remember the episode well, which is a good indicator of the book success." And I I've said that with Made to Stick, too. The fact

that you remember the book as you read it kind of helps prove the concept of the book. So, that's a four. Made to

the book. So, that's a four. Made to

stick from Jose a four. David Johnson

made to stick a five. Very useful in how to present ideas at work and in life.

Bookbot suggested it to others in leadership. 13 for made to stick. Oh,

leadership. 13 for made to stick. Oh,

this is this gonna be tough handbook.

>> Three from Nick.

>> Okay.

>> Okay, that's all the points he could afford to lose.

>> Jose a two. Jose, explain yourself. It's

a five. Okay, we'll do David just for completion. He gave it a five.

completion. He gave it a five.

>> David's my boy. That's my

>> said pretty much anything Dean Kin is on, I'm for it. I would agree. Oh,

that's not fair to the DevOps handbook.

Not fair that it had to go up against the Titan that is made to stick. But the

audience has decided and made stick.

>> Life isn't fair. This is uh this >> Okay, I'm I'm not mad with that. Uh I'm

I you know I I put my put my flag down where I'm a happy died on that hill and uh [laughter] made Stick wins.

>> Okay. The Good News Factory by Kent Beck versus Unix, a history and a memoir by Brian Kernahan.

>> [clears throat] >> These are tough.

>> I'm gonna Unix a history and a memoir I've quoted so many times because I'm just like, "Oh yeah, did you know that?" And then I would talk about some piece of history uh sometimes to an audience that was

receptive of it and sometimes you're like "Dude what?"

what?" >> Yeah.

>> But um no, I I love I loved this book.

Uh, I hope it gets high up in the brackets and uh, yeah, so that's >> this has whenever we do an author interview, I always try to find a meaningful quote from it and then stick it at the beginning of the episode as

like a teaser for what's to come. And

this one has I my favorite of all of them. I don't remember it exactly, but

them. I don't remember it exactly, but it's just Brian Kernahan talking because I believe I asked him the question like, so Unix was invented by just a couple of guys and it changed the world. Could

there could that still happen today? And

and he's basically talking like, yeah, like I think it could like I think smart and motivated and talented people will continue to discover things that change the world.

>> Look at Transformer paper, right? It

kind of sat dormant for a bit. Nobody

even could wrap their heads around it.

Now it's, you know, >> Yeah.

>> fundamentally shift entire US economy.

[laughter] >> You're right.

>> Oh man, imagine having that pressure.

you're like wrote this one paper and it's like >> Nvidia being a multi- trillion dollar company is uh >> tied to it.

>> All right. Unix history and memoir wins that round.

>> Okay. The 12 factor app versus Tidy first.

>> Oh, I'm team 12actor. I love Tidy First.

>> I've said I've I've used and abused 12 Factor so many times. Um, I think it's worth defending the other book, but I'm going to be clearly on 12 Factor.

>> Yeah, I'll give it to 12 Factor. It's um

I am not as much of a 12 Factor fanboy as you are. Um, but this is another one that I'd be happy to revisit. Um, and

Tidy First, yeah, is great, but I think there's something about 12 Factor that just packs a punch in a very small package. If you want to find a really

package. If you want to find a really good refute of 12 factor, Internet of Bugs is not a fan of 12 Factor and he has a really good episode because I was doing research about it and I was like,

man, he has some really good hot takes.

I even like debated in the comments, which I never do. Um, but I'm a big defender of it and I understand where he comes from and I think that of course anybody's gonna say it's the no true no

true Scotsman thing, which is like I think that there's some misrepresentations or probably some poorly implemented environments that he was in. But I think it's also good

was in. But I think it's also good critique. If you also feel that maybe 12

critique. If you also feel that maybe 12 Factor is not what it's all cracked up to be, go listen to him because he he makes great arguments.

>> Okay, next book or our next round, I guess. Uh, in the Plex versus Slow

guess. Uh, in the Plex versus Slow Productivity.

>> I I really enjoy these like journalistic narrative books. I I've actually been

narrative books. I I've actually been reading a lot of these in my spare time.

I just read one, this was uh autobiographical by Mark Randolph, the founder of Netflix. Um, I'm reading one right now called Hatching Twitter, which is of course about Twitter. Uh, one of my favorite books is The Everything

Store, which is about Amazon. In the

Plex definitely falls in that same vein.

Um, this is probably one of the few books that I would read, well actually both these books are books I'd probably read outside the podcast just for fun, >> right?

>> But slow productivity, this this idea of like pseudo productivity was a big wakeup call to me. Um, there was a part of me that just felt like, well, as long as I'm at work and I'm doing things that are workrelated that I would not do in

my spare time, then I'm working, right?

And just kind of realizing like, no, you need to be doing things that really move the needle. You need to be doing things

the needle. You need to be doing things that actually deliver business value. um

big wakeup call for me. Maybe an

embarrassing wakeup call for me, but it was a wake-up call nonetheless. And I

believe this one, this was my favorite book of 2024.

>> So, I got to give it to Slow Productivity.

>> So, I'm I'm on the fence on this one. I

a huge fan of Cal Newport. I think that you're absolutely right. Indeplex,

there's an the same CEO who failed me in that culture interview and says, "Why aren't you doing your own thing?" is

mentioned inside of In the Plex. And

maybe I'll maybe I'll write a blog post about this one day cuz I think it was one of those like >> I've never seen someone use radical cander >> true Silicon Valley style until I had this conversation.

>> Who failed you?

>> Yeah, I wish. No, it was not. It was but it's someone who's like in a passing reference cuz I was looking at his resume and I was like >> this is weird. I saw someone go do this and um yeah, I'm sure I'll write about

it eventually. I'm gonna go with

it eventually. I'm gonna go with Iniplex, which means and again listeners, >> go to the audience.

>> Go to the audience.

>> Okay.

>> I also put crypto, which is another Steven Levy book on the history of encryption, um, public key encryption, and it's going to be a good one. So, I

think we'll have maybe next year, maybe the year after, we'll see.

>> Okay. Slow productivity.

Uh, Nick gives it a five, saying, "The essence of this book wasn't new for me, but it was only after reading this book that the message sunk in and my behaviors changed. Maybe it was because

behaviors changed. Maybe it was because of those sticky anecdotes." Uh, so slow productivity, um, which got a bonus from made to stick, it

sounds like. Okay. Slow productivity

sounds like. Okay. Slow productivity

gets a four from Jose.

>> Okay, >> so that's a nine and from David a four. So 13.

a four. So 13.

>> Okay, that's in the >> It's going to be tough to beat. And the

plex unfortunately from Nick gets a two.

>> Okay. Um,

it gets a three from uh Jose, so that's five.

And it gets a three from David, so that's eight. What was it? What is that?

that's eight. What was it? What is that?

Nine versus eight.

>> Uh, no, no, no. That's 13.

>> 13. Okay.

>> Versus eight. So I I think that's a totally fair. I think Slivity is a

totally fair. I think Slivity is a deserved winner. Um, and yeah, I again I

deserved winner. Um, and yeah, I again I think I think we have a ant Silicon Valley antibbias uh amongst our listeners which is again completely fair.

>> That's fine. Most people do not work in Silicon Valley, >> right?

>> Okay, that wraps up round two. And now

there are 16 books remaining.

>> Oh, sorry. Is that correct? 1 2 3 4 5 6 7 8. Yep. 16 books remaining uh as we

7 8. Yep. 16 books remaining uh as we begin round three. Okay. working

effectively with legacy code versus refactoring.

>> I got to give this the refactoring. It's

more easily digestible.

>> Easy.

>> I love both books, but from a general longevity standpoint, um, yeah, I'm going to say refactoring.

>> Refactoring is a classic in the industry, and I think the fact that to even stand on the same stage as refactoring is a huge accomplishment.

But for me, it's refactoring. I'd

recommend this to more people. And

>> I think we learned >> we learned about legacy code >> book from refactoring. So

>> they have a circular dependency.

>> Yes, they do.

>> They reference each other.

>> Mhm.

>> Um yeah uh you know working effectively with legacy code. Look that book is going to get you out of a bind if you're deep in the weeds of working effectively with legacy code. Um but refactoring I

think is just one where you could read it and pretty immediately take away some good patterns and behaviors that are going to make you a better engineer. And

I think you got to reward a book that does that.

Okay. Grocking concurrency versus the unicorn project.

Oh gosh.

>> I'm going to go with Oh, this is not >> it's not easy. I did not when I asked the audience to um give us their feedback on the books and use our

scores, I did not anticipate how often I would need this just to bail us out so that we don't have to make a tough decision.

>> Right. And I will say we should I'm I'm thinking this for next year. We should

do the Maris Brown Lee thing where we should probably make a public poll where they all fill out the bracket and then we'll discover what the users choices are for this.

>> Um I think our audience is big enough that we could do that because like >> yeah that'd be a lot of fun.

>> He did that and then he has his brackets for like iPhone cameras or whatever and so I think that it's always fun to or not iPhone sorry smartphone cameras. The

iPhone never wins actually. But

[laughter] >> um I love these books for different reasons.

>> I know. Very very different books.

>> I'm biased because >> I'm going to I think Grocking Concurrency is going to be the winner here for me.

>> Groing concurrency.

>> You surprised by that? I know. I know.

I'm I'm on team DevOps, but >> Grocken concurrency it data engineering is one of those >> things that is like it will next level your engineering

abilities if you understand how to do embarrassingly parallel and how to right size workloads. Um

size workloads. Um >> and the book's just beautifully written.

So >> I think I would say rock concurrency is more impressive uh from like the fact that someone wrote this and wrote it well. But I enjoyed The Unicorn Project

well. But I enjoyed The Unicorn Project more, and that's not fair because The Unicorn Project is a book that's designed to be enjoyed more. It's just

it's a narrative. Um, I listened to this one on audiobook and really liked it.

Uh, so we got to go to the audience. I'm

not going to I'm not going to choose between these two. So, or maybe I just did. Anyway, we're going to go to the

did. Anyway, we're going to go to the audience. Okay. Unicorn Project.

audience. Okay. Unicorn Project.

Uh, did we already tally these? We might

have. So, sorry if we did this again.

We're already doing this again. Uh, we

should be memoizing this. Um,

>> okay.

>> Unicorn Project gets a two from Nick.

It gets a two from Jose and it gets a five from David who says, "This set of books really helped really got me into getting CCD going on my struggling team." That's awesome to

struggling team." That's awesome to hear.

>> Um, so nine overall groing concurrency.

Uh, yes. So we already we did we already did this. Um, so five from Nick.

did this. Um, so five from Nick.

>> I think 544 is what that one was.

>> Is it 544? Okay. Growing green currency, you are killing it.

>> Yep. Amazing.

>> We're going to have to tell him about this. Um,

this. Um, >> oh yeah, >> cuz this is this is really impressive.

Um, okay.

Rework versus team topologies.

I'm going to be on team topologies.

>> What?

>> Yeah, >> this this is where we need the audience because I I think I'm going to go rework.

>> Yep. That's understandable. I

>> Yeah, >> these are not there there's no there's no loser at this point because these are all books that we've picked before. So,

>> yeah. Okay. Oh, interesting. Okay, so we got to go to the audience here. Rework.

Nick gives a one. Nick, I'd love to know why you gave that a one. Uh

uh Jose gives it a three and David gives it a three. So that's seven. Oh, that's

not going to be too hard to beat.

>> Um team topologies gets a two from Nick.

>> Um >> I love Nick. I love that.

>> Uh four from Jose. He said, "Didn't read but really like the episode." So that's six. Okay. So unless it gets a one from

six. Okay. So unless it gets a one from David.

Um okay. Sorry. Okay, trying to find this here. Five. Okay, says great

this here. Five. Okay, says great discussion on setting up teams for success.

>> Okay, team topologies. Uh,

>> winner >> lives to see another day.

>> Winner winner.

>> Very, very impressive.

>> Yeah.

>> Okay, so team topologies. Um, I think it's so funny when we get to these books that are like really far in for us and then we see like what did what did Nick give us? It's like one [laughter] like

give us? It's like one [laughter] like we just have terrible taste. Okay,

fundamental software architecture versus what is shap doing and why does it work.

I I really like fundamentals and I know I've said that over and over again during this episode, but I think this is a like this to me is like if you're breaking out of that cocoon from like

junior midlevel, just give me the tickets. I are just I understand one

tickets. I are just I understand one codebase really well to like okay, how do you build systems? How what do our systems look like? What patterns are they following? like fundamentals of

they following? like fundamentals of software architecture is such a great book to help you achieve that transformation in your career.

>> I I agree. I'm in the same boat. So, not

controversial to me. Fundamental soft

architecture is an is a heavy hitter.

>> It's like you say, at this point, we're really just comparing great books and great against great books. Sorry,

Stephen, but we're going to give it to fundamental software architecture here.

Okay. A philosophy of software design versus just for fun.

Philosophy of Software Design.

>> I think so. Just for fun is a great book. Um the philosophy of software

book. Um the philosophy of software design is I think it's really impressive that it's the first book we've read and we keep coming back to it.

>> Yeah.

>> Um I agree.

>> Yeah. This is this is a book that I think is going to survive generations in a way that just for fun won't. So I got to give it to philosophy of software design. Worse is better versus looks

design. Worse is better versus looks good to me.

H >> I'm going to go with worse is better just from its staying power. Um

>> though it is interesting we're actually comparing an essay to a book.

But I think if you only could come away with one piece of information understanding why worse things win

>> is uh is actually a more important core concept.

>> Yeah. Not fair. Not a fair matchup, but I'm >> though I think if you want your teams to like you, you should go with looks good to me. [laughter] So,

to me. [laughter] So, >> we'll give it to worse is better. Okay.

Made to stick versus Unix a history and a memoir.

>> I'm going to give it to Made to Stick.

You know how much >> I'm going to go with Unix. So, it sounds like we've got a typewriter this weekend.

>> Is is made to stick just going to muscle its way up the bracket because >> I think it will. I think it will. So, I

know I do have made to stick. Made to

stick is almost impossible to beat. I

don't remember. We don't We haven't done Unix. I

Unix. I >> What does Made to Stick get? Do you

remember?

>> Made to stick is a four, a four, and a five. Um

five. Um >> Oh my gosh. That's a 14.

>> Yeah.

>> Okay. So, uh Unix a history and a memoir. We get a three. So, it can't

memoir. We get a three. So, it can't beat it. But I just to thank our our

beat it. But I just to thank our our listeners who contributed. Nick gives it a three. Jose gives it a three.

a three. Jose gives it a three.

>> Yeah. David gives it a two. Says,

"Doesn't really help me with my current job." It's not supposed to, David. It's

job." It's not supposed to, David. It's

a classic.

>> It's a way to honor your elders.

>> Yeah. Those who came before us.

>> Made to stick.

>> I have I have the audience on my side.

>> Watch this be made to stick versus grocking concurrency. That would be like

grocking concurrency. That would be like the funniest.

>> That's crazy if that's what happens. Um,

the 12 factor app versus slow productivity.

I'm gonna say I'm actually going to go with slow productivity. I I as much as I love to factor, I think that this is so much wisdom packed in there. Uh this

generally applicable.

>> Yep. Okay. Slowd. Uh okay. We have now made it to round four. What is that?

This is There's Okay, so this is the quarterfinals before the semi-finals.

So, refactoring versus grocking concurrency. Oh,

concurrency. Oh, this might be where Groking falls out.

>> I think you're right. I think I'm going to have to go with refactoring. Um,

>> yeah, >> worthy adversary. And I would imagine if they're really battling things out, you know I

But I Yeah, refactoring is the winner for me.

Yeah, there's no shame. Cyro, if you're listening, you lost to Martin Fowler, >> right?

>> I mean, that is insane.

>> Yeah, you're you've made it pretty far into this. It's amazing. So, um

into this. It's amazing. So, um

>> Okay, refactoring.

>> I would have worn your t-shirt. I would

have worn your t-shirt to the to the competition. I'll put it that way.

competition. I'll put it that way.

[laughter] >> Team topologies versus fundamentals of software architecture.

fundamentals as much as I've been a huge advocate for team topologies this whole time, but fundamentals is the winner in my book.

>> I'll I'll give it to fundamentals. Oh,

it's it's crazy like as we're getting further and I've watched other kind of like March Madness brackets from other people across categories. And it's

interesting because as you get further in them, you spend less time deliberating just because you've kind of like pre-eliberated in the rounds leading up to it.

>> But I don't feel good about some of this, man. I don't feel good about so

this, man. I don't feel good about so quickly. Apologies.

quickly. Apologies.

>> Yeah. It's it's the radical cander part where you're like you need to give this feedback. So, um

feedback. So, um >> a philosophy of software design versus worse is better. I feel like this is a little easier.

>> Philosophy of software design.

>> Philosophy of software design. Yep. Oh,

man. Okay.

And now we come to made to stick versus slow productivity. Oh,

slow productivity. Oh, >> okay. I actually So, between these two,

>> okay. I actually So, between these two, made to stick. I

>> You'll do. Okay. Yeah,

>> then I'll do made to stick too. I really

like slow productivity. Um, but made to stick is just uh >> So, this is an interesting one. If we

had been in our audience is also divided on this. Both of these have a 544.

on this. Both of these have a 544.

>> Oh, interesting. So, I I think this is a tough one because slow productivity uh Nick gave it a five and then Jose and David gave it a fours, but on made to stick it's Nick gave it a four, Jose

gave it a four and David gave it a five.

So, >> interesting. we would have been doubly

>> interesting. we would have been doubly stuck. Uh I don't know how we would

stuck. Uh I don't know how we would tiebreaker or the tiebreaker.

>> I think if it had come down to the tiebreaker, it still would have gone to made to stick because Dan came on the podcast.

>> That's true. Okay. The that's the that'll be the second tier. If if the guest came on the podcast now, if it if they came on the podcast and they get an even score, I think we'll have to like flip a coin or something. So,

>> oh just the seating the seating is rough here. So, okay, we are now at the

here. So, okay, we are now at the semi-finals. Refactoring versus

semi-finals. Refactoring versus fundamentals of software architecture.

>> [sighs and snorts] >> fundamentals. I'm I'm going with

>> fundamentals. I'm I'm going with fundamentals.

>> Yeah, fundamentals. Something Mark

Richards said on when he came on the podcast, he said that uh weirdly enough, the audio book for this sells really well, but I think that's a sign of like how accessible it is. And

>> I think >> I listened to the audio book.

>> We lean for Yeah. Oh, did you?

>> Mhm.

>> Yeah. I think we lean a little more on like breadth here and refactoring is the definitive book for that specific category of how you refactor something.

But fundamentals, I mean, you're it's going to be hard to learn as many software concepts in as efficient a

package that are relevant and are going to make you a better engineer than fundamentals of software architecture.

So, I'll give it to fundamentals.

>> I'm I'm going to commit to making a visualization of this bracket um and when the tiebreers came from the audience because I think it would be really cool to look at. Uh

>> that would be I'll send you a screenshot of the uh >> um >> of the the bracket tool that I'm using.

Okay.

>> A philosophy of software design versus made to stick.

>> Philosophy of software design for me.

>> Uh part of me one thinks like we're a software podcast and so I have to give it to a philosophy of software design. I

just I enjoy made to stick more. Umh

here's my thing with philosophy of software design.

Off the top of my head right now, what are the principles I could teach you from a philosophy of software design? Design it twice.

design? Design it twice.

Comment uh interfaces or modules should be deep or what what is what what's the idea?

>> Something should be shallow. is that

interfaces should be shallow but modules should be deep. Is that the the principle out of that? Um

>> and and that all of this is about tackling complexity, right? Like that's

the fundamental idea behind this is that these are all trade-offs and >> things that we're doing as far as understanding how complexity interacts with our systems. >> Um we I don't actually know what the

audience thinks about philosophy of software design. It wouldn't I wouldn't

software design. It wouldn't I wouldn't mind at this point it being between those unless you have unless you have I'm gonna be on philosophy of software design. If if you're conflicted, I'm

design. If if you're conflicted, I'm happy to punt this to the audience.

>> I want to see what the audience has to say. Look, we're we're getting down to

say. Look, we're we're getting down to the finals here and there's just a part of me that feels like this is a software engineering podcast and I don't know if I could in good conscience can can put

made to stick in the final round. So,

I'm leaning towards a philosophy of software design, but let's see what the audience has to say about this. Um,

>> just for posterity sake.

>> Yeah, I would love to know what Nick Jose and David have to say.

>> Okay, so Nick, so what is so made to stick is 14 or 13?

>> 13. It's made to stick is Nick for Jose for five for David.

Okay, Nick gives a philosophy of software design a five, saying, "Bob Martin was the most influential voice in coding for me, and this was the first book to radically challenge my thinking and approach to software development."

You know, I really like >> a cool piece of feedback. Yeah.

>> And I really like that because I think Bob Martin gets a a bad rap, but like there's something to be said for starting somewhere. And I think if

starting somewhere. And I think if you're just going to kind of completely wing it in in how you structure your code versus clean code by Bob Martin, clean code is the better option here.

And I also think it's fine to say like, you know what, and then I read some other books and I I saw some other opinions and I changed my mind, right?

Um so yeah, I think that's great feedback, Nick. So five for a philosophy

feedback, Nick. So five for a philosophy of software design. Um

okay, >> what's his say? a five for philosophy of soft design.

>> There's a possibility that this might get a perfect score.

>> Oh, but David Johnson's gonna take that away from us. A four for that 14.

>> That's the closest thing we've had to a perfect score. So

perfect score. So >> So that would beat out Made to Stick.

And yeah, I love Made to Stick. Um but this is a software podcast. Dang it. And we

have to award the software book and we have to put two software books in the finals.

>> Yep. So made to stick I love you maybe my favorite book of [snorts] all my favorite non-fiction book of all time but I have to give this to a philosophy of software design.

Okay, let me submit it. Okay, this brings us to the

submit it. Okay, this brings us to the final round. Fundamentals of software

final round. Fundamentals of software architecture versus a philosophy of software design. Let's pause for a

software design. Let's pause for a moment and reflect here. Nathan, did you think this is how we'd wind up?

>> No. And this is the final this is the final standoff.

>> It's just the last two.

[sighs] >> You know, looking back, it makes total sense.

>> I didn't think Yeah, >> it does not surprise me to see John Osterho here. It does surprise me to see

Osterho here. It does surprise me to see fundamentals here. Not because it's not

fundamentals here. Not because it's not an excellent book, but just because >> we haven't talked about it in a while.

We haven't read it in a while. It's one

of the very first ones we read. So to

make it here all the way to the finals.

>> It's funny that both of these books are some of the earliest books that we've read and we've had so many of the authors on uh >> yeah we have yeah we >> actually we've had all the authors of these two books. So

>> you know um I want to know so here's the deal. I want to know what the audience

deal. I want to know what the audience feels. I know we do know philosophy of

feels. I know we do know philosophy of software sign. I don't think we've

software sign. I don't think we've gotten their feedback on >> on fundamentals >> on fundamentals. So let's let's see what they say too. I I think we got to commit, Nathan, that you and I will be

the deciders on this. This is our podcast. But we do have to find out what

podcast. But we do have to find out what the audience thinks.

>> I would like to know what they they have to think. Yeah.

to think. Yeah.

>> Nick gives fundamentals a five.

>> Okay.

>> Jose gives fundamentals a five.

>> David gives fundamentals a five.

>> Wow, >> that is a perfect score. Fundamental for

all developers and developer adjacent roles.

So what I will say here is >> first of all we're in alignment with our audience. I'm very proud of us for

audience. I'm very proud of us for getting the two book like it would have been really sad if like >> you know something that they really didn't like um

ended up making it to the final.

>> Um and yeah I mean we are so close to a typer. I feel like if David probably

typer. I feel like if David probably was, you know, taking this at a different time of the day, he probably could have given philosophy of software design a five as well and then we'd be

in a really a big pickle. Um,

>> just while I'm thinking about it, I want to because now we for everyone that made it to the semi-finals, we now know their audience scores except refactoring. So,

I just want to do for refactoring. Nick

gave it a four. Um,

Jose gave it a four and uh David gave it a five. So that's a 13.

So So everything that made it to the the semi-finals did very very well with our three super fans.

>> Mhm.

>> Amazing.

>> This completely shocks me, >> but I'm going to go with fundamentals over philosophy of software design.

>> I I think I am too. And I'm so conflicted about this because I'm such a I'm such a philosophy of software design fanboy. I think it could have gone

fanboy. I think it could have gone either way. Um, but I think fundamentals

either way. Um, but I think fundamentals welld deserved. This was great.

welld deserved. This was great.

>> A philosophy of software design is a very opinionated book. Yeah.

>> And that's really cool to see. But by

nature of it being opinionated, it may grow outdated. You can disagree with parts of it. Um, fundamentals I just think is like

this is like the best bang for your buck book we have ever read there. and and I think um who I believe was this David who said yes for fundamental software

architecture fundamental for all developers and developer adjacent roles that's high praise and I think it's I think that's why you got to give it to

it fundamental software architecture can we do it can we crown it the winner >> crowned >> crowned okay I did not anticipate this

fundamentals of software architecture at least in This year 2025 is the best thing we have ever read on book overflow.

>> At least when you put it up in this bracket bracket sequencing. But hey, I mean, >> yeah, >> it it had to fight its way through some titans. Let's let's take a moment to

titans. Let's let's take a moment to appreciate fundamentals journey here.

Um, >> it did get lucky. Oh, no, no, it didn't even get lucky. It did not have a first round buy. It beat so first off it comes

round buy. It beat so first off it comes out swinging beating the software engineers guide book >> right >> then it beats mastering open telemetry then it beats what is shad doing and why

does it work then it beats team topologies then it beats refactoring to ultimately beat [snorts] a philosophy of software design >> well very very impressive and and let's

give philosophy of software design some flowers too this let's see >> amazing book >> also did not get a first round buy Um, beats clean coder, beats building

evolutionary architectures, beats just for fun, beats worse is better, beats made to stick, and then gets beat by fundamentals. You know what? I actually

fundamentals. You know what? I actually

feel good about that because I think fundamentals had the tougher journey to the top.

>> It did. And um, it did beat out another Neil Ford book.

>> Yeah. [laughter]

>> Um, >> consolation prize.

>> Yeah, that's this is awesome. And

honestly, the I couldn't be happier about the the final two books that we had to pit up against each other.

They're both phenomenal books.

>> Um and I think we're also in alignment with our audience, which is cool. I

think very narrowly audience it preferred fundamentals as well.

>> Yeah.

>> And so, um did it get was this perfect a perfect score from the audience?

>> This was the only book that we found so far that was perfect score. I bet it's the only book that got a perfect score if I had to guess.

>> I bet it is. Um well, that's very very impressive. Very cool. And I I'm proud

impressive. Very cool. And I I'm proud of myself for the restraint to not just musling made to stick through to the very end.

>> Um >> so hey, um maybe we'll do a followup or something. U we're still figuring out

something. U we're still figuring out the O'Reilly stuff, but this is an O'Reilly book, so maybe we can figure out a follow-up um you know, some kind of follow-up

thing to to do this. Actually, you know what? I I can do this. We will send um

what? I I can do this. We will send um we will we will have a prize for our super fans. So, we will we will

super fans. So, we will we will >> three super fans, >> our three super fans, we huge huge appreciation here. Um, we're going to

appreciation here. Um, we're going to we'll talk to O'Reilly and we we'll get y'all something cool from them. Uh, as

>> we'll get you guys something cool. Um,

and you know what? Let's flex our O'Reilly muscles right now because this is a winner. Um, if you share this the podcast on LinkedIn, you can share this episode um or any episode and and we

have a LinkedIn like company page for Book Overflow. So you can tag us there

Book Overflow. So you can tag us there or you can tag Nathan or I on LinkedIn or if you tag me on Twitter or the podcast on Twitter. Um we uh we will get

you if you're one of the first 10 um or we'll say seven because we're going to give three to our super fans. We will

get you a copy of Fundamentals Software Architecture.

>> Yeah.

>> Um and >> so yeah, first first seven to reach out to us, we'll we'll make it happen. Um,

if our [snorts] super fans already own a copy of of fundamentals, uh, we'll we'll hook something else. So, yeah.

>> Great. Okay. Hey, uh, so fun to do this and I think we'll have to do this again next year as it grows and just kind of see, you know, if we keep doing this every year and fundamentals just keeps winning every year. Maybe we'll quit doing this, but for now, [clears throat]

uh, this was fun. And thanks so much everyone for a great year. As for

chronologically, I believe this is the last episode you'll get from us in December. Um, and then we're gonna go

December. Um, and then we're gonna go dark for the holidays. Uh, we have, uh, yeah, I believe this last episode you're hearing from us. Um, but thanks so much for a great year, everyone. Uh, we love

doing this. Um, we're going to keep

doing this. Um, we're going to keep doing this as long as it's fun. And oh,

I I want to make sure I I shout this out before we um before we sign off. One of

our He was not a super fan who contributed to the episode, but he did give us a generous $20 super thanks on YouTube. um we already made sure to

YouTube. um we already made sure to respond to him there and it is not a requirement on this podcast to give us $20. Um but we like to say about this

$20. Um but we like to say about this podcast, it makes enough money that we never have to talk about it both in a good way and a bad way, right?

[laughter] Um and we uh so so when our fans do contribute um monetarily, that means a lot to us. And so I just want to make sure we shout out. This is from Francisco_m98.

Francisco, really kind of you to uh contribute to the podcast and it means a lot to us fans when you do reach out and if it's not monetarily, if it's just a comment, if it's a like, if it's a connection on LinkedIn, just letting us

know that you like what we're doing because, you know, it's a it is an effort to put on this podcast, but um knowing that there are people out there listening and and enjoying it, uh really does mean the world to us. So, thanks

for a great year. Nathan, anything you want to tell the audience before we sign off for 2025?

>> No, we really appreciate you. It's been

fun to grow this together. We We love the feedback, especially I think most of our negative feedback is, "Please fix the audio. We're we're continuously

the audio. We're we're continuously working on it." [laughter]

>> But yeah, be honest. Um, you know, books are, you know, special episode ideas.

Like, we're we're doing that. And, um,

we do think that we're going to have some more community focused stuff. We

haven't figured out exactly next year, but it may be, you know, something like a Discord or something. Um, we'd love to get more, you know, space to to talk to y'all. So, sounds awesome.

y'all. So, sounds awesome.

>> Yeah. And uh you can also connect with us on LinkedIn. I've had more people reaching out and doing that. And my work is doing a competition for LinkedIn impressions and so I appreciate all of you who look at my stuff. Um yeah,

thanks a ton guys. Uh we'll keep doing this as long as it makes sense to keep doing this. Um but you guys listening

doing this. Um but you guys listening and contributing is part of what makes it make sense to keep doing this. So, uh

super fun. Uh again, contact us at contactbookerflow.io.

contactbookerflow.io.

Uh I'm on Twitter, Carter Morgan. for

the podcast on Twitter at book overflow pod and Nathan uh is pivoting from functionally imperative to Rojo robboto and concentrating all of his thoughts there and so what do you say is it rojo.comnewsletter

rojo.comnewsletter where they can >> roboato.com is the is the landing page and then if you want to subscribe to my newsletter uh it's rojo.comnewsletter

>> okay that is a wrap on 2025 we'll see you next year for 2026 thanks everyone >> [music]