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

Nathan Toups (00:26)

Doing great, hey everybody.

Carter (00:28)

Well, thanks for tuning in, everyone. You can like, comment, subscribe, check us out in the Discord, share us with your friends and coworkers. We we got some Nathan, you sent me something. Where'd you find that? Was it like a coworker or yeah.

Nathan Toups (00:39)

A a l

a longtime friend of mine, actually and a guy I was a c we were working together at one point too. he sent me a screenshot of their Slack inside of their company and somebody unprompted was like, Hey, here's Book Overflow, it's a great podcast or whatever and he sent that along to me and was like, This is, you know, completely organic, internally. I thought that was yeah.

Carter (00:59)

That's that's awesome. Yeah, yeah.

So, you know, w I sharing in the company Slack. Like we have a learn engineering channel at our company, which unfortunately turned mostly into a meme channel. but you know, I still learn a lot from the memes. but if you have any sort

Nathan Toups (01:12)

Yeah.

Carter (01:12)

of like learning channels like that, you know, share

And yeah.

Nathan Toups (01:15)

Also, I I love it when people

talk trash. So if they have it internal and then somebody's like, This

Carter (01:19)

yeah.

Nathan Toups (01:19)

is awful, take a screenshot and send it to me. I'd love to see that,

Carter (01:22)

Let us know.

Nathan Toups (01:23)

you know.

Carter (01:25)

we yeah sometimes I listen to our own episodes. I'm like, you know what? They could have been a little better. Yeah, yeah,

Nathan Toups (01:31)

What are these guys talking about? Yeah.

Carter (01:33)

yeah. One day we're gonna be like 60 and it's gonna serve us up and be like, who's this whipper snapper? Doesn't know what he's talking about. Like, wait, that was me. anyhow. Yeah.

Nathan Toups (01:39)

R that was me. This quote's ridiculous. Who would ever th yeah.

Carter (01:46)

Well, we're we're gonna wrap up this week our little tour with another Uncle Bob book, We programmers.

you know, we've introduced Uncle Bob. This is our third of three episodes. You don't even know what Uncle Bob is. He's Uncle Bob. And this is his book, We Programmers. This is where he dives deep into the world of programming, exploring the lives of the groundbreaking pioneers who built the foundation of modern computing. From Charles Babbage, Nada Lovelace to Alan Turing, Grace Hopper, and Dennis Ritchie. Martin shines a light on the figures whose brilliance and perseverance change the world. So we have now read the entire book. We get to the final third section, which, if you read the Amazon reviews, there

Is some controversy, which I think we both agree is not the surprise is warranted, but the the controversy or like the outrage is way too strong on the word, the upsetness is not because basically what happens here is as I I actually agree stylistically with what the book does, where he basically says as computing advances to a point where he is now low no longer an observer, but was like participating in it, the book kind of transitions to be a memoir.

talking about his story. I actually think Uncle Bob's life is interesting enough to warrant a memoir. And I'd be interested in reading an Uncle Bob memoir. The fact that this book completely changes its narrative structure to instead be about Uncle Bob, I think is a little jarring. And I think is also a missed opportunity because I do think that there are really interesting computing figures that we miss out talking about. Like just for example, like Steve Wozniak or

Like or Linus Torvald's. And and I get that this is a

Nathan Toups (03:25)

Minus two volts, yeah.

Carter (03:26)

book about programming, but I do think it is interesting that as programming becomes like the kind of dominant form of consumer technology, or you know, I guess I guess with the rise of this idea of consumer technology, why don't we talk a little bit more about maybe some of the pioneers who like made the iPod or made the iPhone or made, you know, like I'm not saying you you have to do that, but but there there could be an angle there.

And instead it becomes a memoir about Uncle Bob, which is just a little jarring, but still interesting.

Nathan Toups (03:58)

Yeah, I exactly. And I and I and I I'll kind of reiterate on that too because so much interesting aspects of computer history are are kind of bundled up into this. I I'll take a step back. This is really two books in one. And I really actually wish it was two separate books. And I mean that in the sense that he actually told really good stories of these figures and in in computer science history.

Carter (04:24)

Yeah, absolutely.

Nathan Toups (04:25)

And I wish that he had extended. I wish that he'd had more time to really dive into all the characters of the 20th century, how things are going into the 21st century. I actually think that that would be a really cool book in general. And then the memoir is also interesting. Like, I wasn't mad that I read two books

Carter (04:47)

Yeah, right.

Nathan Toups (04:48)

in one, you know, but it was two books in one. And it it it the other thing is I was like,

Going back and looking at the cover, and I was like, is there any clue that we're gonna get into a memoir? And if you read the cover, it there really isn't. The cover really kind of get sets the mood for what the first two thirds of the book are, which again I think is great. but it was and I think they he also could have either left it at that and then made a short set of memoirs and then his projections to the future, which I think we're probably gonna spend most of our time talking about, his ideas of the future, which is

an arguably very interesting part of the book.

Carter (05:25)

Yeah.

Nathan Toups (05:27)

and and there's also some things that we're like, I think we should take the opportunity to think about what we think the future's gonna be, because I don't agree with everything that Uncle Bob thinks the future will hold. I I think it's fascinating and I could be wrong. And he's got a lot of insights. and I see the world he wants to exist. I don't think that that world will exist. But I yeah

This book, I again, I I still am happy I read it. I read the reviews online and I go, I have empathy for that too. I go, if you thought this was gonna be a book about Babbage and Lovelace and you know getting up into Turing, and then you realize the last third of the book is actually a memoir, that's kind of so depending on your opinions of Uncle Bob, or depending on whether you think that

Becoming

a a programmer to sysadmin to consultant is an interesting story that you should read. I could see why you'd be like, you know, like I I I didn't love that second part.

Carter (06:27)

You know, we have read a memoir adjacent book of Uncle Bob, Clean Coder, which when we did like our top five books of the first the first year we did the podcast, I ranked as like my number two or number four. I don't remember exactly where I ranked it, but I really enjoyed that book. It it's an excellent book. and so

Nathan Toups (06:42)

Mm-hmm.

Carter (06:43)

really, yeah, I agree. I think it would have been nice to get some more stories about some influential computing figures. And really, I think Uncle Bob should just write a memoir. Like I think it'd be good. I think he'd have lots of really interesting stories.

Nathan Toups (06:55)

Yeah, I I would love a We Programmers extended edition that just focuses

Carter (06:59)

Yes.

Nathan Toups (07:00)

on the computer history. And then I would love an you know, life and memoir book extended edition as well. Cause I there's even he touches on stories like in his professional career with Martin Fowler, with other folks,

Carter (07:13)

Yeah, yeah.

Nathan Toups (07:14)

you know, that were in the I did I had I had no idea, for instance, I had no idea that he was the editor in chief of that C journal.

Carter (07:23)

Yeah,

right.

Nathan Toups (07:24)

during

the nineties. Like I that was a period of time before his like what in my mind it was the agile manifesto consulting world where he's spoken at conferences and stuff because again, I wasn't an adult until the early two thousands, right? and and so even his him in my consciousness was after the dot com bust and the emerging sort of like software as a service web application

you know, sort of methodology where he kind of was front and sitter had already had online education tooling and that that's his Uncle Bob persona was like super strong. But of course he has an origin story, you know.

Carter (08:02)

Right, right. well, so with that, we're gonna talk about the book. Again, I we want to spend most of the episode talking about kind of he has this very interesting chapter. I think it's just called The Future, which is where what what he thinks might happen in programming. anything from kind of Uncle Bob's life that stood out to you. this is just something that I always think about whenever I read like accounts of successful people is like it always strikes me how like everyone falls on tough times. And he kind of talks about the the recession being like.

After the he he has this very successful consulting agency, like throughout the dot com boom, still has success after the dot com bust, but it's you know, it it's struggling. And then basically the the recession just absolutely kills the business. And I think they have to actually shudder the business. later find success kind of via the internet. like he his Twitter has a good following and then he's able to kind of publish videos of himself.

And and start selling those and selling courses through that. but yeah, like I don't know, I I I tell anyone I meet, like if you look at anyone who's got like a pr pretty successful life, it's so rare that they've just had success after success after success. Like most people fall in hard times and have to pick themselves up and and move on. So, you know, even the big figures in our industry like Uncle Bob struggle like the rest of us.

Nathan Toups (09:25)

Yeah,

and I I thought I will say the notable parts of this, well, first of all, the the breadth of this, right? He he has stories of getting involved in computing all the way back to the sixties, which is just fascinating how dedicated you had to be to something quite abstract, right? There there was no training wheels at this point. Like

Carter (09:44)

Right.

Nathan Toups (09:45)

you really had to get into this this concept of

you know, what are memor memory registers and w what are these, you know, assembler commands that are moving things around. And then you would be captivated by the fact that you could automate certain algorithms, right? That you could maybe draw something on the screen, but most likely you're actually understanding, I can compute these complex processes. And it there there's something to that where like I think because the barrier was high or because

It was, and you know, consider there wasn't, you know, the the glamour of being a programmer and things like this. You kind of did it because you absolutely loved it or you were infatuated. And you see, you kind of get this. Like you see his journey from the 60s and 70s. that was really interesting. You also could see his business acumen and where he didn't quite fit in.

Which again I thought was interesting. And again, we're talking about a vastly different book, right? We're not talking about some cool thing that Turing's doing.

Carter (10:44)

Right, right.

Nathan Toups (10:45)

We're now talking about the journey of somebody who's made a living working with computers for a very long time. and then realizing that he over and over and over again these patterns emerge. And I think this is where it kind of gets us into the the future part, which is a lot of fun. Is that, you know, he's seen the cast of characters change a bunch. How much you had to take on mentally.

what programming tools were available to you. I I loved that one of the things I loved just kind of yeah, we'll just hop around a bit. When he first got exposed to Kent Beck's extreme programming ideas, and he was vehemently like, or he just thought that TDD was a a crazy idea, right? Like why would you

Carter (11:26)

Right, right.

Nathan Toups (11:27)

even do this? And watching him convert to the Kent Beck methodology, and again, whether you agree with TDD or not.

There's a cool story in here. And again, I wish we'd had more time to kind of see all the different Kent Beck era stuff. But he got to see how Kent Beck wrote code. And he was like hooked. At that point, he was like, they did like a pair programming session. And there's like a really cool little story in there. And I could totally see why you, you know, especially with how compelling Kent Beck is, once you kind of wrap your head around these methodologies and you're also in that consulting world, you're like, I can teach people this, right?

Carter (12:04)

Yeah, I I've been thinking about this a lot with large language models because like the the nitty-gritty implementation is just not as present in our mind as it used to be. I don't know what that means exactly. I I I've always I've never been someone to be like, we gotta have the code look beautiful just so the code looks beautiful. Like I've I've always been a fan of like clean code and not like clean code trademark.

You know, Uncle Bob, but just good good software design because it enables you to work faster because it's easier to do things. you know, I I say this like with large language models, like they're not any different. They they can't program any differently than humans do. How could they? Because they were trained on humans. Even like the juice we're squeezing out of them now is all reinforcement learning, which is all humans telling them you did something good, you did something bad, right? And so they they work like

We do. And so the easiest way to get a human to write good code is to make it harder to write the bad code. If you have good patterns and abstractions, and so someone says, you know, I want to omit a notification, right? Like send a push notification to a device, right? If it's really, really clear in your your code base, like the kind of system you hook into to do that, then then any engineer is gonna say, that's great. I'll just do that. If your code base is instead like

80 separate instances of just calling some raw method of like emit notification or something, then then that's what someone will do. They'll kind of hunt and and peck their way to the truth. and so, like I'm still really interested in like designs and patterns, but like kind of the line by line is is less interesting. And it's I think it's also interesting because.

Okay, so we should get timeline straight here. You are older than me. You're ten years older than me, but I also know you had kind of a beautiful drifter phase of your life where you weren't like doing programming as your career. So what year do you think you started your a professional programmer software

Nathan Toups (14:12)

Mmm.

Carter (14:13)

engineer?

Nathan Toups (14:14)

Yeah, so and this'll be this is some good history. I was I would identify as a systems administrator. And as sysadmin, we were pretty good at scripting, right? Like we would shell scripts and maybe some interpreted language stuff, but I wouldn't I wouldn't have at that time considered myself a programmer. I I still thought

Of programming as this thing that I, you know, was beyond my skill level. But I think it was in the early 2010s that I realized I saw the writing on the wall. I actually I can tell you exactly when it was. It was probably 2011 or 2012 when I realized that cloud computing was the future of what sysadmins were doing and that we were this thing of DevOps was starting to emerge. And I knew that if I wanted to do that, I had to be a software engineer.

Like I had to think, I had to be a programmer. I had to understand how to break things down and build complex systems through, you know, really understanding the domain that I was working on. And so my lens was really so that I could be like really, really great doing a lot of configuration management type work and realizing that there was more sophisticated stuff I could do on top. I had more fun. That's really what it was. I was like, I could solve much more interesting problems if I stopped.

thinking of myself as like a stack and rack traditional sysadmin. And I'll say this, it's funny, I knew sysadmins who were actually phenomenal programmers who just happen to be on the hardware side of stuff. And I would say those were real sysadmins. I was in that kind of camp of just like the less educated. I I understood how stuff worked. I

Carter (15:51)

Right, right.

Nathan Toups (15:52)

could like troubleshoot things. But yeah, it was in it was early 2010s, even though I graduated from college in 2006, right?

Carter (15:59)

Right.

Nathan Toups (15:59)

There was like a six year gap between finishing school

And and being in the profession of doing IT type work before I really got into like programmatic thinking.

Carter (16:10)

Do you know the day or I guess the year where maybe the first time someone paid you to produce code for them? Like not

Nathan Toups (16:18)

Ooh.

Carter (16:19)

scripts necessarily, but like

Nathan Toups (16:21)

That would have probably been twenty thirteen. At that point,

Carter (16:25)

twenty thirteen.

Nathan Toups (16:26)

there was a couple of years in where I would kind of like slip this stuff in, but I think it was twenty thirteen in which yes, I wrote a web crawler. So there was a there was a there was a team I was working with. I was do I had like automated I joked that I ought I like to automate myself out of my job. And so I did. I automated the stuff that I was hired for and then I was able to problem solve and I'd been really learning Ruby Pi in Python.

Those are the two languages I'd been like focused on. And then I started using this language called Go. and I wanted to use Go on a project. And I wrote this web crawler. It was like a serverless web crawler. We it had Redis and it had some queuing stuff that was like tied into it, and we would just like scrape and store things in S3. And right, and this is like twenty thirteen, so this is still relatively novel technology at the time. and I just got I got

the green light to do to just like dig in deep, work with this team, build this tool that was useful for what they were doing. And so yeah, I think that was the that was the transition point where I then had the badge that like I've been hired and, you know, to work on this long-term project that was an actual

Carter (17:37)

Right.

Nathan Toups (17:37)

software code base.

Carter (17:39)

So, so you're 2013. So for me, I graduate high school in 2013. I do two years on my mission, get back, 2015, start college. That's the first time I ever learned code, which is just the idea of programming. And even then, I think that's like Microsoft Excel, which is not programming, so to speak, but you has formulas and if statements and conditional logic. 2016 is where I start actually taking programming classes. And then 2017, I get my first job as a programmer.

For my church's missionary training center, which is adjacent to BYU's campus. So that's my first job doing Android programming. So you're so 2013, 2017. I I think what's what I'm trying to kind of like suss out here is this idea that like the encoding agents come for you about 10 years later, for me about seven years later.

Nathan Toups (18:32)

Right.

Carter (18:33)

And so we're not like Uncle Bob, who just had like 30 years, 40 years.

Of programming. And so I don't know. It's like sometimes I and and and it's way different for like the junior engineers I work with right now who like never got it. And like it's I don't know. Like, I don't know what the future of the industry is like. Like we have that experience a little bit of like the code will not materialize on the screen unless I literally type it in. And we and that's the thing with the coding agents, is like I actually think coding agents write.

Better code than like 70% of engineers.

Like, I think I I don't it it's so hard. Like it's it's I say this all the time. It's such a spiky form of intelligence, quote unquote. Because on the one hand, they move so fast that if you don't have any patterns in your code base, they will just write slop. But it's like if you look at any individual piece, I actually think the individual chunks of code.

Are maybe better than what you could find in like the wild 10 or 15 years ago. Like, you're not

Nathan Toups (19:44)

Right.

Carter (19:44)

gonna find anything like generally, like, they're pretty good about like doing try-catch stuff. They're pretty good about doing a little more defensive programming than what I think you could find from just your run-of-the-mill software engineer 10 years ago. I don't know.

Nathan Toups (20:03)

I'm I'm I'm I I agree and I disagree. I so no

Carter (20:07)

Yeah, push back, push back.

Nathan Toups (20:08)

no, this is good. I programming is such a broad thing, right? And and we'll even see this again. I'm gonna shamelessly plug the Discord because we have a pretty decent breadth of audience where we have some folks that are like embedded C programmers, right? I think they're

Carter (20:23)

Right, right.

Nathan Toups (20:24)

in a very different world than most of us because first of all,

Carter (20:26)

Yes.

Nathan Toups (20:28)

those a lot of those folks

try to absolutely minimize external dependencies. They have their own vendored

Carter (20:32)

Mm-hmm.

Nathan Toups (20:33)

in-house tools. They need to understand every clock cycle of of operations that are happening. And I actually think a lot of that code base is not public, right? There's a lot of embedded application type stuff that is not trained on the data. And I think that folks who do that sort of like systems level programming are the ones that I've still heard are the most vocal about

it's really just not up to what they need for their

Carter (21:02)

Right.

Nathan Toups (21:02)

standards. but of course you think about it, those people are very deliberate and really, really care about things like flow control, memory management, understanding exactly. you know, some of them are even doing like sort of real-time computing. Those are all areas that like I know exist and I know I have an appreciation for the fact that you need to be able to write code like that. But I've never personally done that. I mean I've never even written

C for an ESP32, though I know what that is, right? I have friends who dabble in all of these, you know, sort of like super lightweight areas. I think the closest I've ever gotten is like using, you know, circuit pie or whatever, right? Like writing some Python that compiles down to something that like is very efficient. the whole world's been eaten by code. And I do think that the areas that we actually have a lot of decent code is if you're wiring up web apps. Right? If you're wiring up web apps and you're really trying to translate.

Carter (21:56)

Yeah, that's fair.

Nathan Toups (21:57)

Business logic or product-based thinking,

Carter (22:00)

Right, right.

Nathan Toups (22:01)

I think you can define what you want the product to do. I think that you maybe don't care about having the absolute most efficient algorithms in place because you're dealing with latencies and timescales that are network

Carter (22:11)

Yeah, right, right.

Nathan Toups (22:13)

oriented. And so it which is the same argument as to like, why would I use Ruby when you could write a C web server? And you're like, well.

One of those is a much more productive language for the end user, right? And Ruby's, it's easier to write safer code in Ruby than it is in C. and unless you're Google, you probably are gonna like, you know, what you're doing in Ruby on Rails is probably going to be more than fine enough, right? And and the amount of developer happiness that comes out of it. All those arguments I don't think change. and so there's that piece. I I will say if I don't care.

Too too much about the inner implementation, I also think that it's fine. Like, I love it for prototypes. I love it for

Carter (22:59)

Right, right.

Nathan Toups (22:59)

internal bespoke tooling where I really understand that, like, you know, maybe if I looked at it line by line, I'd be like, I wouldn't act do it exactly like that, but it's also fine enough. And I think it's in the same sense of if another team member had come to me with this and they wrote it by hand, and I was like, but they don't use the.

You know, they don't use this like principle that I really love, but I don't really see myself maintaining this code base in the future and like it is a decent way to do it and it's fine enough. That's kind of how I look at some of the large language model stuff.

Carter (23:33)

Right. Yeah. I I

see a lot of that too. Like it's it's fine enough. Right.

Nathan Toups (23:37)

So, but I will say

it it does compound, it can turn into tech debt. And I think to get back to where you were talking about earlier, there's a principle that I love. I can't remember who taught it to me, but it was basically talking about like, am I is my documentation good or is the code structured in a good way, right? There's there's an aesthetic call to this. And my argument the argument is if you look at this objectively, would you consider this a gift to yourself in six months?

Right. Like if I if I couldn't look at this code and I went back and I just

Carter (24:09)

Yes.

Nathan Toups (24:10)

complete clear mind and I looked at this code and had to pick it up in six months, would I be delighted? Or would I

be like, man, I have to like spend a

Carter (24:16)

Right. Right.

Nathan Toups (24:18)

two days wrapping my head around all of this stuff because it's so complex. And I think to me, that's the litmus of like, even with large language models, I'll do this, I'll do the same thing. I'm like, okay, could I with a large language model pick this code base back up?

in six months

Carter (24:35)

Right.

Nathan Toups (24:35)

and have confidence that I can like prompt updates to it, that I have the proper test coverage, the documentation is for humans and for agents to like pick up. And so it does change the code a bit 'cause I I might even let it be a little more verbose in certain areas 'cause I'm like, you what, the agent does a pretty good job of like slurping this up into the context window and then like picking it up from there.

Carter (24:58)

At this point, let's bring Uncle Bob back into the picture because he has a whole chapter about AI. And this I I found this really interesting. Because one, so he writes this book in 2023. And he is a little like it's interesting because he is very like dismissive of the model's capabilities because he right. Yeah, basically being

Nathan Toups (25:14)

Yes,

Carter (25:16)

like, Yeah, you know, they like these this isn't great code. but this is really interesting because I thought go go ahead, go ahead.

Nathan Toups (25:20)

He No, no, no. Yeah, he would he would

use like a really naive prompt and be like, Yeah, this is garbage. And I'm like, Well, of course. That's what I was thinking.

Carter (25:25)

Yeah. Well, yeah. Well and

and and again, people didn't see I read this super interesting article on Twitter where basically like I didn't realize with Claude Code, one of the reasons Claude Code is so good is because anthropic doesn't just reinforcement train the model, anthropic reinforces reinforcement trains the model in the harness. And so it will train basically like it's

Like it's use of tool calls. And so, you know, it'll kind of use all these tool calls and then it can evaluate the result holistically, right? And it was basically anthropic believes, and I think they have a good case that basically any other sort of open, like any sort of coding harness where you do not own the model that it's using will always be at a disadvantage to someone who owns both the harness and the model. and so

Anyhow, Uncle Bob, I think that's something that that none of us really saw coming was the I the rise of the agentic coding harness and how much more productive that could be. I mean, I love it. I love, you know, like I'll give it a like I'll describe an issue we're having. I give it a read-only AWS account. And I say, just use the CLI. Go query logs. Go, go do this, go do that, you know, see if you can find anything. And I'm I'm all I always love.

How quickly I can get answers back. Again, we are a startup. Our engineering team is not large. Everything we have is lives in a monorepo. And so it's it's very easy. Like it has all the context it could possibly need at its disposal. anyhow, so Uncle Bob, i it's interesting because he's a little dismissive of the code it generates, but he does acknowledge, he says, Well, things will get better. I I'm sure they will get better. And on his Twitter lately, Uncle Bob has been talking a big game about how he doesn't read his code anymore.

About how we just let the agents rip.

Nathan Toups (27:24)

and I will say, you know, this is this is how quickly things are changing. This book came out, I think it was November of twenty twenty four. We all have to

Carter (27:30)

Yes.

Nathan Toups (27:31)

remember that Claude Code came out, what, February of twenty twenty-five? And that's that was actually when

Carter (27:35)

Five. That's when it starts to get good enough that people are like, Maybe there's something here.

Nathan Toups (27:40)

I can tell you this. I canceled my open AI. I think I was paying like twenty bucks a month or whatever for open AI.

Carter (27:45)

Yes, I did too.

Nathan Toups (27:47)

And I was like, Claude Code's

Very interesting. I switched over to Cloud Code and I never looked back. I actually I mean I'm to this point I'm actually a like a max user at two hundred bucks a month. personally, it's

Carter (27:59)

It's twenty twenty six, I think, where

February twenty twenty six is where everyone kind of starts to realize like 'cause it was this year.

Nathan Toups (28:05)

Yeah. And so

I think I had like a six-month like it the first serious work I started doing with Claude Code was in October. where I actually

Carter (28:13)

Yes, yes.

Nathan Toups (28:14)

was able to do some really complex stuff and I was like, there's something here. Whether it's anthropic in the future, there's something here. Like this harness piece was very interesting, especially because it helped me get familiar with a code base that was decently large, several hundred thousand lines of code.

And I was able to compress the amount of time that I was productive on the type of thing I needed to work on a lot. And it really me realized that if I had these like good context sort of engineering aspects to it, it was really nice. and yeah, you're right. I think the the zeitgeist of February of this year, pe people really started being like, There's something here. and it's very again, those things did not exist when he wrote this book, and his critique of the AI tools wasn't wrong for.

Towards the end of 2024, right? I think it was maybe even still a a bit dismissive for what we were observing. But if somebody had made this argument in the end of 2024, I'd like, I see where you're coming from. You know, like I understand.

Carter (29:11)

I don't think I

think cursor hadn't even really taken off, right? Like

Nathan Toups (29:14)

Yeah.

Carter (29:15)

it was very much like you can you can chat with ChatGPT and it'll generate code for you. But so he's been on Twitter talking a big game about, I don't even read my code anymore. I just I I and I I'm with people like I just I I have good tests, and someone's like, Well, who writes this? Well, the AI writes the tests. I'm like, okay, well, like come on, guys, right? And and where I'm also finding this so much in my work, and I I can't stand it because Claude Code.

Wants to operate like there is never a human in the loop. It wants to write all of these like super comprehensive tests every single time. Our test suite is just ballooned and our tests are taking

Nathan Toups (29:52)

Right.

Carter (29:52)

way too long to run. I I think probably 60% of them are not useful. and it's always running and working like I'm not there. And I get that there are people who do that. We have a workflow that is like that, but I wish there was like a mode where I could tell it, like, no.

I'm here. Like you don't need to write 30 tests to validate that the search bar animates in and out. I'm fine just looking and saying that the search bar animates in and out, right? And then it's like,

Nathan Toups (30:24)

Interesting.

Carter (30:25)

you know, if that functionality disappears one day, if we if we lose search bar animating in and out and it just appears one day, I'm like, I'm kind of fine. I'm fine if we we lose that.

Nathan Toups (30:33)

I I'm also fascinated. So I I just read something recently. I follow Braintree a lot. I think I've mentioned them a few times. They do eval in telemetry on top of LLM work. and that's not

Carter (30:43)

Right, right.

Nathan Toups (30:43)

only for applications that are using LLMs, but also even for the the desktop tooling that you might be using as a developer. And they just came out with this thing called beh it's like the behavior spec. And so

Carter (30:56)

Interesting.

Nathan Toups (30:57)

It's a cool idea. I think you'll get a kick out of this. So it's very easy for me to set a goal and say, hey, I want, you know, this new feature that has this, you know,

Carter (31:04)

Right, right.

Nathan Toups (31:05)

you know, menu bar with this fuzzy search tool or whatever.

Carter (31:09)

Right, right.

Nathan Toups (31:10)

Behavior.md is actually saying, and this is how I would like I want if I'm using like the LLM as a judge sort of pattern, and you the behavior describes.

What does a failure mode look like? what the expectations of the test suite should be? And you could even say things like, and we consider ballooning runtime a regression, right? Like you could say you but

Carter (31:34)

Right, right.

Nathan Toups (31:34)

put these behavioral things so that it actually has to stop and say, hey, okay, could I parallelize this stuff? Can I simplify the suite so I'm not like testing the same thing from five different directions and really need a a table-driven test that, you know, maybe only runs

On merge, but maybe doesn't run every time I do a PR, you know, for review or whatever. and so I I think that we it it it's interesting because we still have to like I would have run into that same problem before LLMs, right? If my team had been like, we want 100% test coverage and everything's gonna be great, and all of a sudden my CI takes 40 minutes to do a review.

Carter (32:11)

Right. Right.

Nathan Toups (32:12)

You know, that was a problem pre-LLM. I had been, I've seen this where there's like the cult of 100% test coverage.

and you were like do the craziest thing. So you could do this one edge case on an ifs an if-else. and you're like instead of asking the question of is this even resolvable? Is it even possible to hit that edge case? Like, did we just put that in there because this thing could return an error and it's actually not possible? Like the Osterhout idea. and so yeah, I I I think it's it is interesting that

You can't just let it replace thinking. I guess that's the point. And I and this is also what he sort of is talking about of like it can make right sounding stuff that we want all the time. But if we're not careful, it'll just kind of, you know, say things to please the king and not really do

Carter (32:59)

Right, right.

Nathan Toups (33:00)

what you want that's meaningful or helpful. but yeah.

Carter (33:04)

Yeah,

and I I find that so interesting this idea of like say things to please the king because like and and this gets to another thing that Uncle Bob kind of talks about here, which is he he admits in the book, he says I I think the models might become much better. He's like, I think that one day we might just telepathically think our you know, our intent and it'll materialize. Like he's like that that could totally happen. And he said, But here's why programmers aren't going away.

And it gets back to the very first chapter of the book where I I love I I've been thinking about this for weeks. This we talked about in the first episode, but like this idea that you're a businessman, you think if you can draw a red line on a screen, that you will be able to sell it and make a a million dollars. Okay. Like and he and he talks about like anyone can learn to program. Like business people, like CEOs, like successful CEOs are not dumb people. Like successful growth people and product people are not.

Dumb people. Like we, it's not that we can program because we're so much smarter than everyone else, but he talks about all the details you would need to know to draw a red line on a screen from scratch. And at a certain point, business and product and growth people just quit caring. They don't want to think about any of that. They want to sell it, right? And he says that's why programmers will always be around, because someone needs to care about the details.

And however we are manifesting those details, it's it's still someone needs to know. And the more I work with the models, and it's actually really interesting, Jersey Oraz just did a deep dive on, he went to Anthropic and got to know a lot of the the engineers there. And Anthropic is like the most AI-pilled company in the world. How could they not be? Because not only do they one believe this is the future of computing, have a directed financial incentive towards it being the future of computing, but also

They have unlimited token spent, right? Because the marginal cost

Nathan Toups (35:00)

Right. Yeah.

Carter (35:01)

of inference is actually pretty low. And so they

Nathan Toups (35:03)

Great.

Carter (35:03)

they like that's what he said about working at anthropic and like open AI. Like there is no token budget at all. You can run a thousand agents at the same time. They don't care. and he said that the the closer from his observation with software engineers there, the closer they are to actual software engineering, says the more sure they are that software engineering is not going away. That just like it's changing.

And I thought it was really interesting in the article. It says that they still have about two pizza teams, about six to eight people, but that the size of engineers working on projects has been scoped down. And we actually do this at our work where we have a our engineering team is eight people right now, but we have two person, we call them pods. And they're and basically those are it's just projects, right? And so two people per project. they said that anything bigger than that at this point is just it's too much coordination, it's too much stepping on toes, but they all share the same on call rotation.

Nathan Toups (35:56)

That's fascinating.

Carter (35:56)

Right.

Nathan Toups (35:57)

I I like that because that's also it's it's a interesting vindication of the six week planning cycle that Thirty Seven Signals does, right? Where they actually they they they ship a product feature set within six weeks. It's like non-negotiable.

Carter (36:13)

Right, right.

Nathan Toups (36:13)

But they were they were doing two engineered teams at the beginning of this. They felt that it they felt that if

Carter (36:18)

really? Yeah, yeah.

Nathan Toups (36:19)

you did bigger than that, you lost the autonomy to make the decisions, to move fast.

And

of course, they have this very strict thing where like if they don't get it done in six weeks, they don't ship the feature. It's like

Carter (36:31)

wow.

Nathan Toups (36:32)

it's really I I love it because it makes you really fight scope creep. It's like the you two you can commit

Carter (36:37)

Yeah, right.

Nathan Toups (36:38)

and you can realistically commit on something you can ship in six weeks. That is that's not too far of a time horizon, right? We're talking

Carter (36:42)

Right, right. Right.

Nathan Toups (36:44)

about a month and a half of planned work. and then, you know, come hell or high water, you make it happen, or as early as possible, you say, hey.

We thought that this would be six weeks scope, but actually we found much bigger problems. You know, you can kind of you still can do the the bigger pieces here. and I do I think that it I think if we go into the direction of are there some new power tools that we can use to to do work and it actually continues to make the job fulfilling and fun. there was I I can't remember which podcast it was was listening to recently, and they were talking about like

Product-based software engineering has had a huge unlock, right? Like if you're doing product-based work,

Carter (37:27)

Totally, totally.

Nathan Toups (37:29)

it's actually a lot of fun, these large language models.

Carter (37:30)

Yeah, yeah.

Nathan Toups (37:31)

But if you're you are doing stuff that actually does require a lot of like deep focus algorithmic type work, it can be pretty exhausting. And it feels like you could be fighting the tools a decent amount and the type of care and attention that things get. And I think this is why we're experiencing both I I've seen both of these, and I and and I when I hear the stories of these people.

I agree with both of them. You know, I I hear these stories and they're like, this just really doesn't do what I want. I feel like I'm spending thirty percent of my time just like fighting these tools. And I see this other person there's like, Hey, we're able to like solve problems for the business so much faster.

Carter (38:05)

Right.

Nathan Toups (38:05)

We've been able to get, you know, iterate more quickly. And I think that both of those are real. I think they're real they're real things.

Carter (38:11)

Well what

and Jersey Oraz says that Anthropic sees that too, that the platform teams, the infrastructure teams, like they're like this, it's so heady. And and agents are like and agents are remarkably helpful, but that they and this is something we've talked about in the podcast over and over again that like there's really no substitute for understanding a system deeply. And Anthropic believes that. And I and I don't say the reason I'm talking about anthropic so much is not because I'm like, well, this is how real engineering is done. These

These guys couldn't get anything wrong, but more like this is the most AI pilled you could get, right? And it gets back to this idea of Uncle Bob, which like someone has to care about the details. I've been thinking about that at work recently, where we have redone kind of our inbox messaging system. I took on that project. we we I designed a really cool system with kind of like we we now own the messaging entirely. It's this like append only event log, which then gets reduced into like a message view.

that gets served up to the front end and then it it renders there. It's really, really neat. But I'm realizing one of the trade-offs we made that maybe I didn't explicitly acknowledge up front is the idea is that now in the inbox, if like you get an order and you need to accept an order, that now shows up to you as a message. And then you can like click accept and then we have this whole kind of state machine on the back end that like after you accept it, something gets appended to the event log and then all gets reduced. And as so long as it's a valid state that you know it reduces to the the new preview of the card.

It's really neat. It's really cool. I'm actually really proud of it. And I'm realizing now that you can kind of get if the service that projects the message into the inbox fails, then you can wind up in a scenario where someone has sent you an order, but there is no way to accept the order. And so now I'm like, okay, well, wait a minute. So what's the plan here? Is the plan that we need to always make sure like

Just have really good retry and to make sure that nothing is ever dropping there. There's no reason it should drop, but you never know, right? Is the plan that we need to build some sort of separate, like maybe it's nice to have the orders in the inbox, because this is what I like about the system too. The the the inbox is just a projection of domain events across the system. And so it doesn't matter where someone accepts an order, but it will still update in the inbox, right? But just the way the sis it's designed right now, there's no other surface area of the product.

Where it's just like, here's a list of all the orders you have. Would you like to accept them? Those live individually in the inbox. I'm like, so do we need to build that? Right. And it's these sorts of things, like the details that we care about. And I find really, really interesting from like a technological perspective. We're we're working on a project right now. I'm calling it the great notification unification, which is right now, the system has no concept of a notification. Like we have a concept, like our notification is.

We call the push notification API and and put a string in it. But there's no historical record of these are all the things we wanted to tell you about, right? And so

Nathan Toups (41:11)

Interesting, yeah.

Carter (41:12)

that's what we're doing now is like building that that system and that domain. But the details for how to do it, it's really interesting. We have a new director of product and I love him. Like he's fantastic, but he has like this vision of kind of.

What he wants our notifications to be able to do. And I think it makes sense from a product perspective. And so me and my my pod partner are talking to him about this. And like we're walking through it on a like a systems model. And he was just like amazed. He was like, holy cow. Like he was really impressed. He was like, You guys really understand what you're talking about. But I thought it was so interesting. Again, this guy is not dumb. He's really, really smart.

Nathan Toups (41:52)

Right.

Carter (41:52)

But this is just not where his brain is.

His brain is not at all in the space of like, I want the notifications to be able to do this. What system do you need to build to do this? And so this is Uncle Bob's point. No matter how that system materializes, someone still has to care about it. They still have to have accountability for it. They still have to be there when it breaks. And they have to acknowledge the trade-offs. Like that's what I'm talking about with this inbox projection and like the trade-offs that are being made here. A large language model isn't gonna tell you.

Again, I used Claude extensively to build this thing. And at no point did it ever surface to me this acknowledgement that this was an explicit trade off we had made about the system.

Nathan Toups (42:31)

Right.

Carter (42:31)

I realized that after working with it. And now it's on to me. Now I gotta I have to ask myself, like, okay, was that trade-off worth it? And the answer I have is I think largely yes, but maybe it's too critical a trade off to not be able to acknowledge in some other part of the product and provide some other views. But I find that really interesting.

And and I just don't think other people will ever find it interesting. And I don't think Claude or any LLM is even ca of course it's not even capable of finding it interesting. It can't find anything interesting. It's a it's a next token predictor.

Nathan Toups (43:03)

No, I I I I do I think it's it's fascinating because y we you know, there's a lot of these business sort of domain problems. There's these deep, unsolved things that just exist. They existed before large language models. I I think that I don't know, I'm overall pretty excited. And and I kind of take the there's again, two voices that I've brought up before. I think it's very healthy to do this, even if you don't I don't necessarily agree with all of their conclusions.

But I love listening to Kelsey Hightower. I love listening to Corey Doctoro. And two things that come out of this is that Cory Doctoro makes this argument that, hey, obviously there's this hype machine. Yes, the math doesn't add up. And it's very similar to how the crypto bubble was and when it came with like NFTs and stuff. Where it's markedly what's markedly different is that there is something actually useful in its core, unlike most of crypto, right?

Which is that like there's actually like if the if the world froze, not another model was created, let's say either we open sourced the anthropic model became open weights, or we just moved on to Kimi three, right? Because the anthropic disappears, we can't use it anymore. But there's like a pretty, you know, pretty comparable model with Kimi three or some of these other open models. And for whatever reason, humanity could not develop another advanced foundation level model. We will for de we could for decades.

continue to improve harnesses and improve all kinds of things to actually use this in some really interesting ways. And I think that there's something really true to that, right? Like we probably could develop more efficient compute systems so that we're not having to build crazy huge data centers. I I think Apple is uniquely in a position in which as we can get models that can fit into smartphones, we will. It would just

Carter (44:49)

Right, right.

Nathan Toups (44:50)

be cool to have that. and Kelsey Hightower also brings up another good point that I think is always important here, which is

We are agents. Like humans,

Carter (44:59)

Right.

Nathan Toups (45:00)

we're agents, right? Like when we think about I am a non-deterministic thing that takes in some

Carter (45:05)

Right. Yeah.

Nathan Toups (45:06)

inputs, I have some state inside of here, and I have some outputs. And as a as a software engineer, my job as an agent is to create deterministic systems, right? The whole reason that you justify your six-figure salary in software engineering is that I make solutions to problems that can then take all the advantages of compute and go.

Carter (45:26)

Right.

Nathan Toups (45:27)

run at, you know, million X what a human's capable of, because we can just do this in a deterministic, a highly efficient way. And it's my

Carter (45:34)

Mm-hmm.

Nathan Toups (45:35)

job to figure out how to do that. Right. That doesn't change with large language models. Like if I use a large language model to help me do this, I what I don't want to do is have an LLM in the loop always. And that'd be like just hiring a bunch of humans all day long to solve problems at a tech company. It's like you don't want to do that.

Carter (45:49)

Yeah, right, right.

Nathan Toups (45:51)

Use an LLM to create some deterministic output. And that is absolutely your goal at the end of the day.

How do I continue to maintain deterministic output that helps me build highly scalable systems? And that again, that framing, I think, is people just get off or like they'll create a skill and then do the same kind of correct thing like 20 times in a row with the LLM because it's kind of novel and it's kind of interesting that you can throw it at it and it can pull it

in a bunch of context.

Carter (46:14)

Yeah. I see this all the time.

Nathan Toups (46:16)

But you really, you're like, hey, I've done this like three or four times. I kind of understand what the pattern is. I'm gonna use

Carter (46:22)

Right.

Nathan Toups (46:22)

the LLM to create, and this is again, maybe this is my DevOps background.

It's like I want to automate the things, but I can't automate it

Carter (46:28)

Yeah.

Nathan Toups (46:28)

until I understand what the process is. Once I understand what the process is, make something deterministic, right? that doesn't change. Like if I look at it this way, I'm like LLMs help me generate deterministic tools in a different way than I used to be able to. and yeah.

Carter (46:43)

When I see non

technical people using them and like, hey, here's my skill. I'm like, this skill is a poor approximation of a script. Like and I'm not use LLM to write the script, right? Like I think that's cool that a non

Nathan Toups (46:51)

Right. Right. Right. No, exactly.

Carter (46:55)

technical person could do that, but they don't even think of that. And I and that not because they're idiots or whatever, right? Like, I'm

Nathan Toups (47:01)

Right.

Carter (47:01)

sure you could put me on a sales call and I would botch it. And a skilled salesman would be like, Well, you didn't use this, this, and this technique, right? Which is like sales basics. yeah.

Nathan Toups (47:08)

Right. Right. Yeah, like you missed

you they they they s expressed pain at this point in the call and you didn't latch on to that. Like you know, like whatever the sales tactic is. Yeah, what that seems mean. No, it it's not mean. You're solving their problem. Yeah, like whatever.

Carter (47:16)

Exactly, right? And I'd be I didn't even know I supposed to do that. Yeah. Yeah. Exactly.

Right. Right. but but yeah, and it gets back to this idea of just like people just don't care. It actually makes me really bullish on AI-specific tooling for other professions. Like, salesmen do not want to write scripts to make their job easier, but they might want some AI native CRM, which just understands the sales workflow deeply.

And that they and they feel like they can, you know, really 10x their output because of it. yeah, it's yeah.

Nathan Toups (47:52)

It I'll even do this with skills.

So like I have a few skills that I use that are kind of like help me with for instance, I can be pretty bad if I'm not careful of like not updating my, you know, my board of like the work that I'm doing.

Carter (48:04)

Right, right.

Nathan Toups (48:05)

and so I have a skill that it bas basically helps me like catch up, make sure that I've described the things I've actually been working on in my work properly, make sure that they're in the right columns. and increasingly I have little sh scripts.

Like 'cause you the cool thing about skills is you can write scripts for your skills, right? And so once I kind of understand the correct query or the correct whatever, you'll start seeing in my in my skills directory, I just have more like sort of Python code or bash scripting that shows up in there because I want the LLM to not be creative. Like once I kind of figured out the right way to do it, I'm like, here's this tool call, right? Like, do this tool call, just like I would if I was writing a CI C D pipeline, right? I would I want probably

Carter (48:46)

Right, right.

Nathan Toups (48:47)

a make file or you know.

Whatever, and I'm like, okay, these are the four things that I want every time that I say that, you know, my fitness functions have run. and so yeah.

Carter (48:58)

Well, and it it's also interesting with with LLMs. It's like, I kind of hope we're at a a point right now where we're gonna look back on a lot of like the development practices we made and be like, that was so silly. And what the what I hope I see from that the most is like, look, if the models got three times smarter than they are today, that would be helpful. And and and I wouldn't turn that down. You know what I take 10 ti 10 out of 10 times over three times smarter? Three times faster. Because right now

I have this super goofy workflow where it's like,

Nathan Toups (49:29)

Right.

Carter (49:30)

it depends on what I'm doing. But like, for example, this new inbox thing, right? We just we we have all the patterns locked in, we feel good about it, and then we bug bashed it, right? And and we just found like a lot of like goofy little bugs. I'm not reviewing the code, it submits too hard because it's because it's all just like little UI quirks and and tweaks, and like I can look at it pretty easily in a PR and be like, okay, yep, this makes sense. I verified the output.

What we're doing here does not violate any of our patterns. It's not doing anything goofy. So so I'm fine with it. But my workflow is insane. We're like, I think I've said this podcast before, but if I haven't, like we were trying to do like work trees per feature, but it's so annoying because you have to like you know, do all the node inst the node modules installs and like regenerate our Prisma clients and things like that. It's super annoying. And so instead, I just have five work trees for the the monorepo, and I just call monorepo alpha, bravo, charlie, delta, and echo.

And then I'm using CMUX. So I have those in kind of like the left pane. And then I have tabs for each one of them. And so I will mark on the left pane, like for Echo, what kind of group of features I'm working on. And then I spin up like four agents per work tree that, and then I change the tab name to be what I'm working on. And then I'll have like 16 agents running across and like I'm bouncing between all of them. And like I I'm glad

Nathan Toups (50:45)

Right. Yeah.

Carter (50:46)

that I'm getting a lot of output, but it's so stupid. Like if they were faster, I could just get in flow state to be like.

Fix this. Great. I fixed it.

Nathan Toups (50:53)

Right.

Carter (50:54)

Okay, great. Looks good. Moving on. Fix this. Right. And so like I hope we look back on this era. I'm like, my gosh, can you believe the goofy things we were doing to like try to like maximize output? and obviously this is very different. The the next week or so

Nathan Toups (51:04)

Yeah.

Carter (51:07)

is deep work and systems design. I'm not gonna have sixteen agents running. Yeah.

Nathan Toups (51:10)

Exactly. I'm I'm actually kind of excited

because I think it was again, Alex Hermozzi actually of all people, you know, he's like the big, you know, hustle culture sales guy. But he was talking about how it's so easy to give yourself unimportant work with it with a bunch of LLMs. It's yeah, it's yeah, it's like it's like I've

Carter (51:27)

w it's snacking to an extreme, right?

Nathan Toups (51:31)

become a snack alic. And

So I have to be really careful of being like, is this actually what needs my attention? Cause I when I think now,

Carter (51:38)

Totally.

Nathan Toups (51:38)

I look you look at those old like Bell Labs, I'm sorry, the the Bell operators, and you see the switching boards, you know, and they're like

Carter (51:47)

Right, right. Right, right.

Nathan Toups (51:49)

taking a phone call and patching you to this. And it's like I feel like that's what I'm doing with LLM sometimes. You know, I'm just like, I'm yeah, you know, do this. Like I'm patching

Carter (51:51)

Mm. Yeah. Yeah. Yeah.

Nathan Toups (51:57)

things together on this patch panel. And I'm just kind of like an air traffic controller, basically.

Carter (52:01)

Right, right.

Nathan Toups (52:03)

My favorite is to get into these like long Socratic debates with

Carter (52:07)

Yes, yes.

Nathan Toups (52:09)

as a in in sort of making sure that I'm writing some like proper EDRs and getting some things in place. and so so here to tie back to again in if you're still with us, you're awesome. We appreciate you.

Carter (52:19)

Yeah.

Nathan Toups (52:22)

we we topic jacked this book in the same way that Uncle Bob memoir jacked us and the and the book as well. He does and and actually

Carter (52:27)

Nathan and I have a rule for the Yeah. No, he he talks about AI. Nathan and I

we have I was gonna say we have a c we have a rule for the podcast that we will quit doing the podcast the day it is no longer fun to record the episode.

Nathan Toups (52:39)

Carter (52:40)

'cause there there are things around the podcast like I don't like editing it, right? And like but I I

Nathan Toups (52:43)

Right.

Carter (52:43)

put up with that because the recording is still fun. So if you're like these guys won't shut up, well well too bad. Nathan and I are having a lot of fun right now. So but anyhow,

Nathan Toups (52:50)

Yeah.

no, the AI the I the I the AI future section I thought was really interesting. I'd love to dig into that and I also would I his hot take on languages. Okay.

Carter (53:01)

Yeah, let's let's talk about the languages. We can't move

on without discussing his what he thinks the future of languages.

Nathan Toups (53:05)

Yeah. So

this is kind of cool. Uncle Bob fell in love with Lisp. And I would say I

Carter (53:14)

Yes.

Nathan Toups (53:14)

there's a subset of programmers that I know personally that have gone through this phase of their life where they realized that the Lisp Lisp's the the like whole family tree of Lisps and I would say logo and Lisps and these kind of languages, that data is code and code is data, and there's this sort of like beautiful

you know, sort of very mathematical interoperability between them is alluring and it's really functional programming heavy. And that everyone I've talked to said, hey, even if you don't run useps as your daily driver, spending some time writing Lisp and thinking about how Lisp approaches programming will make you a better programmer. and I don't agree I don't disagree with this.

What I do disagree with is that he kind of makes this argument that like nothing interesting's happened in programming languages in the last like 25 years, and that Lisp is gonna win in the long term, and that in the future all we're gonna have is like Lisp that the LLMs use, and that we'll just have like one like he could see a future in which there's like one big sort of like Lisp interpreter LLM thing that's going on.

Carter (54:27)

Right.

Nathan Toups (54:29)

I really hope that that world doesn't exist. Like

Carter (54:31)

I I don't know what time about Lisp. I just looked at some Lisp code right now. I'm like, what the freak? I don't want to write this at all. Yeah, yeah, I I I'm looking

Nathan Toups (54:35)

You yeah, if you love parentheses, you would love a lisp. Yeah.

Carter (54:40)

at this. There's five parentheses in a row. I don't want that.

Nathan Toups (54:42)

So I will tell you,

there is a beaut, like there's a beauty to it. And I will say I've spent some time in Elizabeth and it really will break your brain a little bit in that you if you ever want to have a a language that makes it trivial for you to make domain-specific languages. if you have a language in which the data and the interpretation of the data and the structure of the code can kind of fold into each other, it actually is.

Pretty cool. And and the the whole origin story of how Lisp functions, there's a interconnectivity between Lisp and AI, actually. And all of the early research in AI happened with Lisp-like languages. And if we're if you remember correctly, Worse is better was this. The Worse is Better paper, he was all in on Lisp's. And he was like, these are the future,

Carter (55:38)

Right.

Nathan Toups (55:39)

this is the right way of doing stuff.

Ugh, why are these, you know, Fortran algal C derivative, you know, procedural languages catching on so much is disgusting. Like we have this beautiful thing over here. And I again, I as an observer, I go, you know, I understand where everybody's coming from. but I'm in the Brian Kernahan, or maybe it's the Dennis Ritchie camp where I'm just like, I think I'm not clever enough to be like a Lisp or Rust person. Like I

Carter (56:09)

Yeah.

Nathan Toups (56:09)

I I'm I'm a simple man and I like a good procedural or or an imperative type programming language. It just fits better in my head, right? And these would be the JavaScript and this in the Go and the you know, the sort of curly bracket style languages where I can think of things from top to bottom and I can encapsulate stuff and move on.

Carter (56:31)

Right.

Nathan Toups (56:31)

You know.

Carter (56:33)

Well, I don't want to I don't want the future to be lisp.

Nathan Toups (56:34)

I also my other langu my other thing

with languages is I also how terrible it would it be if the entire world spoke only English or

Carter (56:42)

That's fair.

Nathan Toups (56:43)

only Chinese, right? Or only Spanish. I I think it's actually really important that we protect the the languages that we have, that we th that there's

Carter (56:52)

Yeah.

Nathan Toups (56:52)

there's there's worldviews, there's usefulness aspects to this that we don't know what the future is. I think like because we're organisms, robustness is actually like a core piece. Like

We don't want just one species of bird and one species of whatever. We

Carter (57:06)

Right, right.

Nathan Toups (57:07)

need a whole broad range, because you don't know. Like the earth changes, life changes, and something that can step in and be the appropriate tool for the time. We won't know until, you know, if if we if we kind of get a monoculture, then we're really gonna miss out. If if if all of a sudden we let's say we're he's correct, and we just go to Lisps. And Lisp's, of course, are garbage collected languages. There's no way to like represent memory or any of these other things.

all that's abstracted away. I that's really unfortunate. I think we want like I think there's a reason that like Rust and Zig and Ada and Go and Clojure and in Elixir and Erlang, like all in Swift, you know, all these languages like they exist because they solve certain types of problems really well. And I I don't

Carter (57:56)

What

Nathan Toups (57:57)

I'm fine with that. I I I think it's great. you know

Carter (58:00)

And we have talked about the opposite on the podcast, which is this idea that can you even invent a new language today? Because it'll be at such a massive disadvantage to any other language just because of the presence of LLMs. And so with LLMs, like I don't think this idea that we're all gonna converge on one Lisp-like language makes any sense. If anything, I think that like TypeScripts will eat the world or something. Like I don't I don't know, right? Like

And I I that's the thing. I don't think TypeScript will eat the world. I think there's too much that TypeScript can't do or can't model as compared to like other languages to make it not the right tool for the job. like

Nathan Toups (58:40)

I I could

even see a world in which people start making bespoke DSLs, right? Domain-specific languages or bespoke

Carter (58:49)

Yeah, yeah, maybe.

Nathan Toups (58:50)

or dis bespoke languages to solve a particular type of problem. Like, does it even matter anymore? It like a a good example of this, I think. It's been a very long time since a rock band has been at the top of the billboard charts, right?

Like I think it was it was something awful, like I don't know, one of the one of the terrible sort of like, you know, post grunge rock, like you know, I'm trying to remember, like, look at this photograph, like one of those kind of songs that are awful.

Carter (59:22)

Yeah.

Nathan Toups (59:26)

But rock and roll has not been at the top of the billboards, meaning that it's not in the zeitgeist of the hyper popular music, right? Like that a lot of like rap groups or R and B or Taylor Swift type

pop music has has has stayed in. and I don't think it's a loss though, right? Like if you're into rock music, this is like the best time to be alive. There's so many bands out. There's so many interesting j sub genres. If you're into like punk rock or heavy metal or you know Nordic thrash metal or you know like whatever weird obscure thing that you're into you it's like the best time to be alive. You can literally find whatever hyper niche you want. And I think

we're going to get more hyper niched variants of programming languages. Right. Like I actually think the absolute opposite, where it's like, who

cares? I you know, like

Carter (1:00:14)

Interesting. Right, right.

Nathan Toups (1:00:16)

if I want to use Elm because I like some of the guarantees of it or Elixir or something. or you know, I like the guarantees that Beam gives me with the way that Erlang does stuff. And like we can very low cost go explore that and see if it solves our problem well. And

I don't know, maybe I'm wrong. Maybe I'm maybe I'm like completely off base, but I I hope we get a Cambrian explosion of of of language types. in that if anything, we're just like, why do all these languages exist?

Carter (1:00:51)

well, no one knows the future. least of all us. I I think that wraps us up for Uncle Bob. Yeah, there's there's lots of other interesting things in here, which we've only got a few minutes, so I don't really want to get into them because we ought do them to just he talks about hardware, talks about kind of the World Wide Web. He sees a future where I mean I w maybe we should just touch on it a bit. What was his idea? He he thinks that nothing will like everything will be done server side, or I I don't even remember what it is.

take on the web was.

Nathan Toups (1:01:25)

Yeah, it

I I can't remember the exact details, but it it is funny, is I was like I was like, so are we basically gonna have HTMX Lisp interpreters? Is this what we're talking about?

Carter (1:01:35)

I th yeah, I think that's kind of

what he th he thought the future would be. anyhow.

Nathan Toups (1:01:40)

I do think that a lot of this stuff will become effectively invisible. And I think even if I disagree with the Lisp part of this,

Carter (1:01:46)

Right, right.

Nathan Toups (1:01:48)

I do think that it could become effectively invisible in that the idea that I interact with the screen, the idea that I even need to think about what the computing layer is, could largely be invisible. That there's sort of this like the world's peppered with these magical devices that are all over the place and things just work. And if they don't work, they kind of like

self-heal and figure out how to wire themselves up and that

Carter (1:02:11)

Right.

Nathan Toups (1:02:11)

almost hard to like wrap your head around. also he he made a really quick note about ethics and I and I I think we all hear about this from time to time.

Carter (1:02:20)

Yes.

Nathan Toups (1:02:21)

And he talked about this in Clean Coder a bit as well, which is this idea that like

We're increasingly in the hot path of like the future of humanity.

Carter (1:02:31)

Right. Right, right.

Nathan Toups (1:02:34)

programmers, I mean. And and then increasingly yeah, me, yeah, you and me, hopefully not.

Carter (1:02:36)

No us, book overflow.

Nathan Toups (1:02:40)

the but but they're in large language models as well, right? and that we have really sidestepped this idea of like an ethics review board or in these kind of areas. And I he basically makes the argument that we either need to get out ahead of it and like come up with a pattern.

Or it's going to be imposed upon us, right? Like we in it in typically when things are imposed after some disaster happens, it's also not the best way of approaching it. There's a lot of, you know, overly restrictive sort of things that come out of it that actually could be the disservice to everybody. and so I I don't know, I I I think this is very it's interesting to think about the future. I think if you take nothing else away from this book, take a beat. Like

Take a beat and think

Carter (1:03:26)

Right, right.

Nathan Toups (1:03:26)

about what do you think? Like, what do you think Uncle Bob's right? And that we're gonna go to like a monoculture of languages? Or do you think like or it or maybe you think it's a monoculture, but it'll all be, you know, machine language binary? Or is it gonna be TypeScript? Will TypeScript inevitably become the language that it's what we do everything in?

Carter (1:03:45)

Right, right.

Nathan Toups (1:03:46)

Think about it. I would love to hear actually, I'd love to hear it in the comments or on the Discord

Carter (1:03:50)

Yeah, let us know.

Nathan Toups (1:03:51)

of of your opinion of like what do you think the future looks like?

Carter (1:03:54)

Well, a as far as what we're gonna do differently in our careers, I I'm gonna learn what the free Calisp is. you know, I maybe I'll write try to write like a little Yeah, yeah.

Nathan Toups (1:04:02)

You should. You

should. it I think actually use the Matt Pocock teach skill

Carter (1:04:09)

Okay.

Nathan Toups (1:04:10)

and get it to teach you the basics of Lisp and like why people care about it so much, right?

Carter (1:04:14)

I I tell our engineers all the time, I say, like, I say, form strong opinions. Form strong opinions about what we're building, how we're building it, why we're building it. I I just I don't want us to be slopperators who are just pumping out code. Like, tell me why what you're generating is good. And then I kind of feel that way about Lisp. It's I I want to have a strong opinion about Lisp. And that strong opinion can be I never want to see this again in my life. But you know, I should probably know what it is if Uncle Bob thinks we're all gonna write it one day. how about you?

Nathan Toups (1:04:43)

So I left mine as TBD. I'm trying to think what what would I do differently in my career? I think I need to take a beat and think about the future more. I think that that would be I you don't want to just do that all the time, right? I think that or maybe I maybe I should. I don't know. I sh I should definitely think directionally where things are going. I mean, I I do I think that on a like shorter term horizon, but I it this book was fun in the sense of like, what do I think's gonna happen in 15 years or 20 years or

Carter (1:05:11)

Right, right.

Nathan Toups (1:05:11)

thirty years?

And write it down, right? And be super wrong and be hilariously wrong. Like it would be really because I think in thirty years, it'd be very funny for me to go back and read a journal and be like, In thirty years I think this is gonna happen and be like, that was adorable, right? Like you

Carter (1:05:25)

Yeah.

Nathan Toups (1:05:25)

you thought that we were gonna have flying cars, right? Or whatever. so yeah.

Carter (1:05:30)

Well,

as far as who'd recommend the book to, I mean, I I would say like, look, it it it's two books. And so if you're really interested in a memoir of Uncle Bob towards the end and his speculation of the future, great, pick it up and read it, you know, the back half. If you just want the the programming kind of the heroes of programming, read the first two thirds. And again, I I I'm with you, Nathan. We need a We Programmers extended edition and we need a real deal Uncle Bob memoir. Cause I think both would be fantastic in their own right.

Cobbling them together produces a a funny reading experience, even if all the individual content is

Nathan Toups (1:06:06)

And if we get a chance to talk to Uncle Bob, I'm gonna this is exactly what I wanna ask him. Cause I I bet there's a story behind this, right? And I don't think we would offend

Carter (1:06:14)

Right, right.

Nathan Toups (1:06:15)

him being like, why aren't these two books? Or or we will and it'll be good content. Well we'll see what happens.

Carter (1:06:21)

Well, we'll see. Well, anyhow, thanks for listening, everyone. You can always find us Twitter at Book Overflow Pod. I'm on Twitter at Carter Morgan. We're online at bookoverflow.io. Nathan's newsletter are at rohorobato.com slash newsletter. That's consulting agency, rohorobato.com. And I'm excited. we are doing a Cal Newport book next, aren't we? So good they can't ignore you. My skills trump passion and the quest for work you love. Very, very interested in this. because I've been thinking a lot about passion and how it relates to work. And so

To kind of invert this idea a little and be like, you know, maybe, maybe skills are what matter. Again, I think a lot about Dan Heath and what he told us, where just like work on what you think is fun, that you're gonna work the hardest, that'll that'll make you better. I I I love Cal Newport and I think we're due. We're due for a book like this, aren't we, Nathan? We've been talking a lot about

Nathan Toups (1:07:07)

We are

Carter (1:07:08)

AI, a lot about how it relates to programming. That's all fun and interesting. Let's take a step back. Let's talk about our careers a bit and why why we even do what we do.

Nathan Toups (1:07:15)

Also, quick call to the we have a public backlog now. And I

Carter (1:07:19)

Yes.

Nathan Toups (1:07:19)

would highly recommend folks reach out. We have not we have not taken the backlog and put it onto our schedule. We'll be doing that really soon. So go ahead and if you sign up to our Discord, that's how you get to vote. So you get it you get I think you get three or five votes depending on when you signed up. and vote on the books that you're most most interested in. And we will use that as a as a s weighted scale on our prioritization, right? We're

We're not gonna guarantee that the first book in the list is gonna be the next book we read, but we definitely wanna use this as a way of measuring interest from the audience. And so this is your opportunity to kind of have an impact on the future of our our schedule.

Carter (1:07:56)

Well, there we go. All right, folks. We'll see you next week.