Hey there, welcome to Book Overflow. This is 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:24)

Doing great. Hey everybody.

Carter (00:25)

Well, thanks for listening, everyone. Like, comment, subscribe, join the Discord. check out all the links in the episode description. we'd love to connect with you however we can. and it w we were just talking about this in the Discord, but my wife was debating whether or not to announce our baby on Facebook. She just we we kind of both just left Facebook and and never really missed it. And so she's like, Yeah, be nice, like some of our high school friends do. And so we're

Debating how to do it. And I told the family group chat, I said, if you want to know that Heidi exists, you should join the Book Overflow Discord. And my brother said, that's where I get all my Morgan family updates. So

Nathan Toups (01:01)

Here you go.

Carter (01:03)

that's if you want to know about my personal life, I guess that's where we're posting it now. and then yeah, I'm trying to think if there's any other housekeeping. No, we're we're just back at it with week two of We Programmers. This is by Uncle Bob, Robert C. Martin, his full name.

An author introduction if you haven't heard him, Uncle Bob, but most of us have. He's been programming since 1970, is one of the most influential voices in software craftsmanship, best known as the author of Clean Code, The Clean Coder, and Clean Architecture. He was a co-author of the Agile Manifesto in 2001, served as the first chairman of the Agile Alliance, and coined the solid principles that shaped a generation of object-oriented design. In this book, we programmer, software legend Rob Robert C. Martin dives deep into the world of programming, exploring the lives of the groundbreaking pioneers who built the foundation of modern computing.

From Charles Babbage and Ada 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 read week to we're about two-thirds of the way through the book. This week covered a lot of other historical figures. I want to see if I can pull them up right now, just to give you kind of an overview of who we we're not gonna have time to talk about everyone here, but the people we

Nathan Toups (02:15)

Yeah.

Carter (02:16)

did talk about, we got Hilbert Turing and Von Neumann.

Or no, we covered them last week. Yeah, so we we start Grace

Nathan Toups (02:22)

We did. So we're at

Carter (02:24)

Hopper.

Nathan Toups (02:25)

Yeah, we start we start strong. Yeah.

Carter (02:27)

Grace

Hopper, John Bacchus, Edgar Dijkstra, Nygard and Dahl, John Kemene, and Judith Judith Allen, and then Thompson, Richie, and Kernahan, who we're quite familiar with. one because we actually know Brian Kirnahan, and two because we read his book Eunuchs a History and a Memoir, which talks all about the development of Unix. So yeah, we've card lot more historical figures in this book. we have now entered the period where some of these figures, although very few of them,

Are still living today. so Nathan, tell me what you thought about this middle third of we programmers.

Nathan Toups (03:04)

Yeah, so this we're we're kind of concluding. There's there's kind of two parts to this book. One is this sort of short, you know, narrative of of the history of programmers, right? This really focus on the we programmer part. The second part of the book is really a memoir. It's a memoir of of of the author. And so he kind of goes back and tells the story again. And I I kind of peeked into the next section a little bit just because I was listening to the audiobook, which is kind of cool because it we're kind of getting two books in one.

And I think what this first part really does is kind of like set the groundwork for all these things were changing. And if you really what I loved about this book is that you kind of see how radical these changes were over the 20th century up into the 1960s and 70s, because people were just kind of like I mean, the the jumps of abstraction of thinking about how to even solve problems was not a settled thing. You know, there was no playbook.

And I I think he does a really good job kind of like giving this narrative. I do think that just like I I pointed out with the lack of Claude Shannon, I think he necessarily has to breeze over some other folks, especially if anybody who reads computer science history maybe goes, huh, they didn't talk about this person or this was like a footnote on one page. I think that that I'm I'm more of an a more understanding as to why after getting through chapter 10.

though I do think that like this book's to me is a catalyst for like, ooh, I wanna look at this history this part of history, like what what was really happening in the nineteen fifties or the nineteen sixties, when you know, we invented, you know, a new type of memory, you know, or or we invent or the the first versions of a hard drive comes out or you know, these other kind of

Carter (04:50)

Yeah.

Nathan Toups (04:51)

cool, cool things.

Carter (04:52)

It's really interesting to watch the Genesis. Like something I'm fascinated about as we know from like early human history is that we had to invent the concept of zero. Like for a

Nathan Toups (05:03)

Yeah.

Carter (05:03)

long time, humans just didn't understand that. We had to invent the concept of more numbers. Like we we instinctively understood one and more than one. But then the idea that you could like quantify after that was like a an

Nathan Toups (05:14)

yeah.

Carter (05:15)

an invention, which is just like so crazy now.

Nathan Toups (05:19)

Well,

I I I completely agree too. Like there's a I'll I'll cite Veritassium from time to time because they do such an incredible job of communicating these like more complex things to a general audience. One of my favorite stories that they tell, and and I'm just if you're in the Discord you'd see this too. I've talked about Euler a couple of times. Euler, right, who's like famous for his like to shent stuff, it's like he came up with some ideas on a a

This relationship of like cyclic integers that ends up becoming really important for cryptography 240 years later. Right. It like a couple of his ideas, one is Diffie Hellman, the other one's RSA, that kind of like are deeply impacted by it. But he, if you go back and like read about what he was like obsessed with, because you know, he obviously a peculiar human who's like pontificating about this stuff,

Carter (06:09)

Right.

Nathan Toups (06:10)

he was like

really troubled with negative numbers. Like the idea that like what is a neg what is a what is a minus one apple? You know, like and if you think about it, you know, like what is that?

Carter (06:18)

Right, right. Yeah. That is a weird yeah, yeah.

Nathan Toups (06:22)

And but also there's all these sort these sort of like I, you know, things that you when you really think about like what am I representing with mathematics here? And like how is this useful? we take a lot of this for granted but for the longest time, yeah. Like is zero representable? Like what is a zero?

What is a zero apple? You know, or or or whatever.

Carter (06:40)

Right. Yeah, yeah, yeah. And

I get when you put it that way, you're like, yeah, what is a zero apple? but your sea Yeah. Line, I

Nathan Toups (06:46)

Right. Or what's an apple squared? What is an apple squared? Like this?

Carter (06:50)

know I could I could draw a square apple for you. I I I have an idea. yeah.

Nathan Toups (06:53)

There you go. Yeah, touche. I can make a cubed apple too, you're right.

Carter (07:01)

but it it's interesting seeing like I I found the Grace Hopper chapter really fascinating particular because

The you start to see the genesis of some ideas that we just completely take for granted in programming,

Nathan Toups (07:11)

Right.

Carter (07:12)

which is like, what if we could take the same code and and store it and reuse it? What if we could put parameters into that code? Just this idea of like, hey, we have this giant machine that needs to run to do these computations, but not all of it is running at the same time. What if we could figure out a way while this part over here is doing its work that we could use this part over here?

For other work, you get this idea of kind of like, you know, yeah that, multitasking. You get this idea of multitasking.

Nathan Toups (07:44)

Yeah.

Carter (07:45)

and it's just so interesting because, like, of course, this is so fundamental to our understanding of how computers work today, but also, of course, these concepts had to be invented at one point. And so it's really interesting to see like they were invented, and just because our discipline is so young, they weren't invented that long ago, less than a hundred years ago.

So it's it's a really

Nathan Toups (08:07)

Yeah.

Carter (08:08)

fascinating look at history.

Nathan Toups (08:09)

I I you also see that the the real struggles you see across software community, even to this day, were there at the very, very beginning. And I what it would be n neat about looking at, you know, specifically when we get to like Dijkstra, is there's this real there's this real like cognitive dissonance between wanting to make programming as mathematical as possible and

Is is is it is it a mathematics or is it a science? And I didn't really understand the distinction until he makes this kind of case of like, as we get into it, and I mean maybe we'll address it a little bit later, but I think this this topic's worth bringing up before we even talk about any of these people is you know, in mathematics you have to prove something is the way it is, right? Like you you you hit you have some set of, you know, you you

foundational principles, and then you make these these proofs and these arguments on top of it, and then the system itself is complete within the mathematical description. And there's a school of thought that says all computer programming should be completely describable by its mathematics components, right? And I think this is people who want like formal proofs for everything. And then there's the science part which is like, hey, we're really constrained by what we can observe. We can have an idea, but in we have to all we have to do we have to actually invalidate whether something is true or not.

And we actually can't know all possible states. It's it's not, you know, science is sort of the an observing reality. So I build something, I think it's gonna work a certain way, and then I try to falsify whether that actually behaves that way in reality. and it's funny, like I never thought about the computer science part of this and like the framing of obviously we want everything to be knowable and true, but then we also have this thing where we're like we're constantly surprised th from the emergent

Carter (09:56)

Right.

Nathan Toups (09:56)

behaviors of the complexity. And I I think he made a really good case for.

why we're a science and not a subset of mathematics. And I I

Carter (10:05)

Right.

Nathan Toups (10:06)

was surprised. I was not expecting that reading a history about this stuff and being like, yeah, that's actually a really nice observation. I hadn't thought about that before.

Carter (10:14)

Well, let's we can start talking, I guess, first with Grace Hopper. I I found this chapter, I think it's one of the it's the longest, if not one of the longest chapters in the book, and for good reason. This is where I will share my least woke opinion, which is I get ready, folks. It's gonna get spicy. It's not actually

Nathan Toups (10:32)

well.

Carter (10:32)

gonna get spicy. I all I know about Grace Hopper is the Grace Hopper convention, which is like purely for female computer science students. And so

Sometimes like we joke about this, like I'm a Mormon. And sometimes we joke, we're like, is someone really famous or are they like Mormon famous? Which is like, like Donnie Osmond is real famous. Mitt Romney is real famous, right? David Archoleta is like Mormon famous. We're like Mormons, exactly. You don't even know who that is. He was like the runner up on American Idol when I was in high school. Right. Exactly. Exactly. Cause you don't know who he is. Because

Nathan Toups (11:03)

Okay. I learned something today. Yeah, there we go.

Carter (11:08)

and so we're like, is this person like actually famous?

Or are they like or do we are they kind of famous and we only know them because we're Mormons? And so I I kind of wondered, was Grace Hopper like that for women? Y right.

Nathan Toups (11:19)

That's like me in Louisiana. Me in Louisiana. do you know who

Wayne Wayne Toops and the Zydeco Cha Cha's are? Because, you know, that's Louisiana famous right there. So

Carter (11:25)

No. Yeah, yeah. Yeah.

But so I yeah, I I kind of wondered that. I'm like, is Grace Hopper like actual computer science pioneer or more like just because the feel

feel is so male dominated, you had to find like the most prominent female one. And so it was really great reading this chapter because I will it completely convinced me that Grace Hopper is like, yes, actual fundamental computer science prompt or pioneer. yeah.

Nathan Toups (11:53)

unquestionably

Carter (11:54)

I just did not know. And so it was cool reading this and being like, I mean, she's called the first software engineer, and reading about her, I'm like, absolutely. I I I 100% see how we're kind of descended from her.

Nathan Toups (12:04)

I remember a few years back, I remember was looking into stuff and of all things, I think it was the NSA that published some videos not too long ago of Grace Hopper giving sp giving talks. And I actually like I started watching them. She's an incredible orator. She's really

Carter (12:21)

Right.

Nathan Toups (12:22)

they and they talk about this in the book that like she became like an unofficial

college professor because the professors themselves were actually having trouble teaching the mathematics concepts to some of the students. And she kind of stepped in and as a student was able to very effectively you know, compel these folks to how amazing these these topics were. And that f fed through in in her whole life. And I I came away from that and some of the other understandings of her radical reimagining. I think she she was scoffed at.

Right. And this this chapter kind of brings this up, which is that she thought that we should have a way of writing code that was more that was more like language, like natural language. And but the code itself at the time wasn't quite as efficient. And so all of these sort of like gatekeeper, you know, sort of purists were like, well, this is stupid, it's a waste of time. And then it turns out that all of these core ideas that she and her contemporaries had around

The way they were developing ends up becoming COBOL, ends up becoming the first compiler that was ever built. And that the journey, I didn't know the details of all the of the journey to this. And I think this is why he spent the extra time, is that this was super eye-opening and COBOL, whether you loved it or hated it, inspired this entire generation of we should have some intermediary representation, and that that thing should be then turned into something that the machine understands. and there's this whole

world and in in in like how early this was, right? Like we're talking about the n early nineteen fifties, nineteen sixties. I think it was the I think the first version of COBOL came out in like fifty nine or something like or at least the one that the first major like phloumatic syntax thing that she was working on. might be off a little bit on the timing.

Carter (14:14)

It's

yeah, it's really interesting reading about her because she so I and this is something I just I I cannot promise a faithful replication of every detail in the book. like we said, you're you're listening to to two guys discussing a book that they both read. think about it like here overhearing two coworkers at lunch. but it's so she joins basically the war effort in like the summer of nineteen forty-four, to run the heart.

Nathan Toups (14:41)

Right? And divorces her husband,

right? Right. It wasn't Yeah, so she

Carter (14:43)

Divorce of her husband, yes. Yeah,

Nathan Toups (14:46)

she was so motivated to do this thing that she like joins the war effort. It like apparently ends her relationship and she like starts a new life. Like I I d which is a detail I did not know.

Carter (14:56)

Well, and she's

and we should also mention she's the first female math PhD at Yale, right? And and so Yeah.

Nathan Toups (15:01)

Right, right. Just a trailblazing, left and right. amazing.

Carter (15:05)

So she joins Howard Aiken. Howard Aiken is in charge of the Harvard Mark One. I believe he is the inventor of the Harvard Mark One, which is just this, you know, it's a giant computer. not even punch cards at this point. I think it's punch, it's tape that you gotta like feed into it. and

Nathan Toups (15:23)

You could even do

loops, right? Like you had to manually do a loop, with

Carter (15:25)

Yeah, y exactly, right.

Nathan Toups (15:27)

feeding it back in and watching the counter on it.

Carter (15:31)

So she

joins is basically a second in command.

Nathan Toups (15:34)

Right.

Carter (15:35)

and their whole job with this computer is like calcul they're doing like calculations for the Manhattan project to like, you know, figure out like nuclear fission detonation stuff way above my head. I saw Oppenheimer and she's she's so yeah, what what's she doing here? Like

I find it so interesting to kind of all of these stories. There was an interesting Twitter thread the other day with someone saying, like, how come software engineers are not mad that their job is being automated away? And obviously, we are not a monolith, and there is diverse opinions about LLMs and and coding agents. But in general, a lot of the responses I saw, and this is the response I or the camp I tend to fall into, is that like I want to solve problems. I find that

Really, really interesting. And so this technology has enabled me under careful stewardship to solve problems faster and to eliminate some of the drudgery of programming. and again, I know not everyone feels that way, but there is a an ancestral through line all the way back to Grace Hopper, of basically wanting to take care of the drudgery because they're, you know, they just want to solve the problem. They just want to get to the, you know, to the result.

And operating this machine is so cumbersome that Grace Hopper is has to start coming up with all of these kind of workarounds for okay, well, how do we speed this up? How do we make this faster? and that's really what this entire middle third of the book is about, which is just how do we make the actual act of programming faster? And so she comes up with the idea of like subroutines. I mean, what we would these days call like functions.

Nathan Toups (17:23)

Mm-hmm.

Carter (17:24)

which is just it's just shared notebooks. Just of you know, and and the way that the the code worked was it was just yeah, it was it was it was just punches on a tape. And so, you know, it's just like basically dot I I don't think it was dots, I think they described it with numbers, right? Like they basically like would write like one, three, four, and that would tell you if the you know that that line meant that there should be a punch in the one spot, the three spot, and the four spot. And so

Nathan Toups (17:51)

Right.

Carter (17:51)

It's just all these lines, but then she gets these subroutines and and then they can start sharing those. Again, no real way to reuse it. You just have to punch it again. But you know, you're not having to kind of figure out how to do this specific thing over and over again.

Nathan Toups (18:08)

Yeah, the the other notable things, and I guess everyone has some sort of I guess some awareness that Grace Hopper was an important person and that maybe you knew that she was involved with COBOL and the maybe the first compiler. she's also in this is debated on whether this is a true story or not, but it's part of the mythology, is that debugging actually came out of like they

Carter (18:31)

yes.

Nathan Toups (18:31)

actually had bugs in the machine, like physical bugs in the machine. And so this this idea of debugging was from work that they had done.

he also mentions that they when the registers, if they if there was like a problem with it and it would fail, whatever the position in the tape was, they would send the dump of that tape back to the programmers to like figure out what had gone wrong. And so, like, even a stack dump, right? Or are the the these concepts of like how do I troubleshoot? How do I make it easier for me to understand how to like get correctness out of the out of the program? Like, they're doing a lot of this just from necessity of.

Also, I I will say I know one little some Grace Hopper quotes. I I recently did a a talk on how to stand out as a software engineer at Leland. There was like a they have a you know online sort of webinars you can do. And Grace Hopper was in my slide deck this

Carter (19:21)

Right, right. nice.

Nathan Toups (19:23)

is a few weeks back. And she actually also understood, and he doesn't talk about this in the book. I I want to bring it up though, because I think it's worth her legacy. She said that there was going that the data.

That machines were generating is actually more valuable than the machines themselves. And that was a controversial

Carter (19:39)

Interesting.

Nathan Toups (19:40)

thing at the time because at the time, machine time was incredibly expensive. Far more expensive than

Carter (19:43)

Yes, yes.

Nathan Toups (19:45)

any paid labor to work on the machines. We're talking hundreds and hundreds of dollars per hour to operate these things. And that's not inflation adjusted, right? That is a that is a

Carter (19:55)

Right, right.

Nathan Toups (19:55)

so you're probably thousands of dollars per hour for these things to operate. And so it was really important not to make mistakes and all these other things. And then she still argued.

Yeah, but the data that we're producing and the way that we manage it and the way we access it and the way that we'll store it, that's actually where the real value is. And I think that's crazy to think that she saw that far ahead in time.

Carter (20:16)

Right.

Well, and I don't remember if this is something that comes from Grace Hopper in particular, but it's kind of a theme throughout these chapters is she has the claim to the first compiler, the A0 system. and and you start to see more and more compilers pop up. And again, I I'm gonna attribute this to Grace Hopper, but I can't remember. But basically, she makes this compiler and says this is great because now programmers can write code a lot faster, but it doesn't matter.

Because it takes the machine about 30% longer to process compiled code than uncompiled code. And because the machine time is so expensive, it's not a worthy trade-off, which just we obviously in our day, we just know it's a complete inversion. That's what coding agents are, right? Is like our time as the humans is expensive. And so if we can get something that can write the code faster, then that's a huge unlock for us.

Nathan Toups (21:12)

I feel like we always have these pendulum swings too, because I remember when Go first came out, people were excited because you could basically get, you know, C like performance. If you wrote good Go code, you would be maybe 20 to 30% slower than C code. but it was garbage collected. And so therefore it really attracted the you know, I think the the original Go team thought it was gonna attract people like Java programmers, because it was gonna, you know, had some new modern features, but really it attracted Python and Ruby.

programmers, people who are doing interpreted languages and realized, I can get the correctness of a compiled language, but the productivity of an interpreted language. And but I it's funny because like then you hear all these stories of, well, Go starts fell falling over on us. Like you look at Cloudflare or these other places that have rewritten stuff in Rust, because they need to get every ounce of performance out of it. And I think this is like, again, this this is a theme that goes all the way back to the beginning of computing, which is which is more expensive.

the like the time to get the idea out the door. And then when I

Carter (22:16)

Right.

Nathan Toups (22:16)

actually get the idea working, how do I make this work as efficiently as possible at scale? And you you can see this, you can see this debate happening. Cause you know, I think that people who are doing really highly optimized code kind of prematurely optimize for that always, right? but yeah, but one day we're going to need super optimized code. so

Carter (22:37)

Right.

Nathan Toups (22:38)

wouldn't it be a shame if we did something slower

But got the feature out faster. And then, you know, and so folks who have worked directly with the machine and understand exactly how to manipulate registers and really understand how the inner workings of that, telling them, don't worry about it. I've got this abstract language, and will the the compiler's gonna kind of sort out how to implement that on hardware is a weird thing to let go of in the same way that when we started doing

Interpreted languages, or now that we're doing large language model stuff where you're like you're kind of being a little more hands-off in an area that was considered absolutely impossible to be hands-off one. And we're trying to figure

Carter (23:16)

Right, right.

Nathan Toups (23:18)

out again what's the right trade-off. I these all these trade-offs

Carter (23:20)

Right.

Nathan Toups (23:22)

are they're they're fascinating. And so yes, I think this another thing that's cool about this book, and I think why I'd recommend folks read it, is these are fundamental problems in computer science, right? These are fundamental problems that

have plagued this industry since the beginning. a lot of soul searching has always been there. And the cast of characters change, the abstractions change, the scale of things change, but it is it's kind of like heartwarming at the same time to be like, man, the manager wants it done this way, but the staff thinks this way it should be done and they figure out some creative way to do what the manager needs and sneak in their little idea on the side,

Carter (23:59)

Yeah.

Nathan Toups (24:00)

right?

Carter (24:01)

I'm I'm really hoping because I know that he he does talk about AI later in the book. and I know that he started writing this book in twenty twenty-three, but really coding agents don't become kind of viable until like late twenty twenty five. because he kind of plants his flag at the beginning of the book and says, like, people think AI will make programmers redundant, they won't. And just seeing

history of this book, it it's just 100% like I remember when AI kind of first started taking off in 2023-ish. And one of my friends was nervous and I I told her and I was like, look, I I I can't see the future. I I don't know. But what I will say is that every development which is supposed to put programmers out of a job just increased the demand for more programmers.

And I I said like I if I had if I were a betting man, that's why I would bet this time, but I just don't know.

And reading this book, you just keep seeing that over and over and over again, which is like the this constant fear of, but holy cow, if you can make what what previously would take 10 programmers, now only take one. What's gonna happen to all those jobs? And then said, nope, a programmer just got more valuable. So I don't know.

Nathan Toups (25:18)

And I

and I will say, like, at the same time, you know, you being the world's leading expert in Flowmatic or understanding the inner workings of a Univax system or the PDP seven, those things went away, right? Like if that was what you

Carter (25:29)

That's true. That's true.

Nathan Toups (25:30)

were basing your whole identity on, it's gone. Like there is no opportunity for that. If except for maybe I guess I bet you could start a PDP seven, you know, YouTube channel and just go all in depth of like,

Carter (25:42)

Yeah.

Nathan Toups (25:44)

you know, and and probably find a cool niche audience. But that took a long time.

come back to that to the for the world to care about the the novelty. the type of systems thinking, and I think that this is really what it comes down to of like there is no planned path. And I think another thing that he

Carter (26:00)

yeah.

Nathan Toups (26:01)

really shows here is that all of these folks are oddballs, right?

Carter (26:05)

Yeah, yeah.

Nathan Toups (26:06)

Grace Hopper I unfortunately I didn't know this about in her until this she's period of her life, even after her success, really dealt with like crippling alcoholism and then had to come out of that.

she ended up having sort of you know some highs and some lows in her career that again it's easy to glaze over once you see the success of somebody in the long run. and of course a decent amount of what she was working on was completely secret for a while. Like we know now, but you know, when she's d working on Navy stuff or things for the intelligence services or the Department of Defense, it wasn't until many, many years later that things were unsealed. and so, you know, there there's a whole class of folks

you know, in the world that we don't really know what they're up to 'cause they they happen to be working for, you know, three letter agencies and stuff like that. 'cause, you know, a lot

Carter (26:54)

Yeah.

Nathan Toups (26:55)

of times those three letter agencies have really interesting and complex technology, you know, that are that are there. So

Carter (27:04)

Well, we start to see a kind of this progression with John Bacchus, which is a a

Nathan Toups (27:09)

Mm-hmm.

Carter (27:09)

character I did not quite understand. This he did remind me of you, Nathan, because he the beautiful drifter.

Nathan Toups (27:14)

Yeah, no, is what we were talking about. This this guy is kind of just

like flying through life and despite everything is yeah. And it we actually see this theme come up a couple of times too, which is like f people who've just figured out how to play for a living.

Carter (27:29)

Yeah.

Nathan Toups (27:31)

but yeah, yeah, Bacchus, he he was interesting

Carter (27:36)

I I'm trying

Nathan Toups (27:37)

he he I'm sure he he's one of these people he was smart enough to kind of like get through his coursework.

But he was also very like undisciplined when it came to like doing what he's put. He was just very flaky about a lot of stuff, which I thought was really interesting. And then despite all of that, he ends up and I think we see this a lot too. He ends up falling in love with some technologies that allow him to dive in deep into into into types of work that just again did not exist.

Ten years, fifteen years before, right?

Carter (28:13)

You see this

with a lot of the figures in this story. It's kind of like what got them first interested in computers. and the very, very early pioneers, like Charles Babbage, are just like very like they're just weirdos. Like there you can't nothing can get you interested in a computer because it doesn't exist, right? And so it's just like a big weirdo who just is having all sorts of crazy ideas. And like we we need those people, right? Someone's gotta get the ball rolling.

Nathan Toups (28:39)

yeah, it's a Bacchus, he is it Bacchus or Bacchus? I think it's Bacchus. I don't know. He there is so I w Okay, cool. I think it it

Carter (28:46)

I th I you call him Bacchus, I'll call him Bacchus and we'll split the difference. Yeah.

Nathan Toups (28:51)

it probably is Bacchus though. Cause I will say I I will there's some more forewarning. for instance, later we talk about Ken Thompson and Brian Kernahan and and Dennis

Carter (29:01)

Dennis Richie or Brainer.

Nathan Toups (29:02)

Ritchie, but he he'll actually he pronounces it instead of McElroy, he pronounces it

Carter (29:09)

McElroy, was that? Yeah, yeah.

Nathan Toups (29:10)

McElroy. Yeah.

And so anyway, I you know, I've so what we heard and what what's the actual pronunciation, please forgive us. it reading and listening to stuff can be a little tricky. But he is a creator of Fortran. So I guess we should kind of

Carter (29:23)

Yes.

Nathan Toups (29:23)

give this thing of like he ends up making a really high impact thing. Fortran actually is super innovative as a language. And I think people who are comparing Fortran like COBOL, which again, you know, these are contemporary pieces. Fortran has this sort of very mathematical

you know, it it's it's still I and again, there are still folks who run Fortran to this day. There's still certain things that Fortran does that I I think are actually like super optimized on the compiler level that I was surprised by. But like I think you can make a really good living right now, in these like niche Fortran

Carter (29:58)

Right.

Nathan Toups (29:59)

pieces. and we started introducing a lot of like there's a lot of cool ideas. I think a f first I remember it was a huge

cost. I think it was like 10 to 20 times the these first efforts before Fortran, it was like 10 to 20 times more expensive for runtime. and then Fortran comes around and it wrote some optimized code that I think actually beat handwritten assembler on

Carter (30:30)

wow.

Nathan Toups (30:30)

on certain tasks. And so and again these are like this is like in the 50s, right? and I I think that what happened kind of out of these

was this whole like like BNF, algol, a bunch of languages kind of emerge. And and you you can see these charts sometimes of like showing the heritage and the history of of programming languages and source his influence in a sort of accidental. Like I think he accidentally got into mathematics if I remember correctly. Like he kind of stumbled into a math degree. and then he kind of like somehow got his hands on some IBM stuff. And then

he realized that like computers could actually solve like really interesting types of problems, especially for mathematics. And yeah, I I he I had no idea this wasn't even on my radar. Like Grace Hopper, unlike you, like I had actually done some research and I knew

Carter (31:20)

Right, right.

Nathan Toups (31:21)

a bit more about her. That that's how John Bacchus was or Bacchus was to me. I just I I knew Fortran existed. I had no idea the history of it or who who made it.

Carter (31:32)

Yeah, it's and and I I find just this idea like he he saw you know, a computer in IBM's Manhattan street window. I mean, I I've said on the podcast before, like for me, my introduction to programming was Microsoft Excel in a business class.

Nathan Toups (31:48)

That's right.

Carter (31:49)

And just the if formula was so interesting to me that the value in one cell could determine the value in another cell. And so I I think

Yeah, it's always so interesting seeing what gets these people interested, especially these early pioneers who like were Edger Dijkstra actually says what on his marriage license he has to list his profession and they would not accept the term programmer. It just didn't even

Nathan Toups (32:12)

Right.

Carter (32:13)

exist. And so he writes down theoretical physicist, which like he's not at this point in his life. and so yeah, like what it how enticing this would have to be to you.

To kind of say, even though this profession doesn't exist, this thing is completely new and completely alien to anything humans have ever really built, like, I'm gonna devote my life to it. in a lot of ways, we're like I I will say this about my computer science journey, which is that I did not know this field paid well when I decided I wanted to do it. I I just found it interesting. And it was a happy little surprise that I found it I paid well. And I actually

Nathan Toups (32:53)

funny.

Carter (32:54)

I actually found out it paid well too late. Like I I got a job out of school at at Disney, which was like my dream company. And so I was just happy that they hired me at all. And I and then later on I found out they were paying me like well below market rate.

Nathan Toups (33:10)

Right.

Carter (33:11)

and anyhow, so but I but I think there are a lot of people who these days

take up computer science because yeah, they find it interesting, but they also know this is an in demand field that pays well. I mean, back in the day, you know, John Bacchus, like, who knows what this pays? Does it pay anything? I don't know, right? But you're just so interested, you have to do it.

Nathan Toups (33:31)

I and I think a lot of these folks,

yeah, I thought I think a lot of these folks would have just done it if they if it paid the bills and they could make a living doing it, that that that was like, you know, good enough for a lot of them 'cause it gave them the ability to kind of push the boundaries of and and be fortunate enough. And it and again, I think one of the other things you see here, every one of these people that we study in these next few chapters, they have a group of people with them, right? And

Carter (33:56)

Mm-hmm.

Nathan Toups (33:57)

they all kind of influence and have feedback loops and

react to either vehemently agreeing or disagreeing. speaking of vehemently agreeing or disagreeing, I Dykstra is probably this is we're now in chapter six, like the most controversial and probably one of the most impactful people up to this point. I think Dijkstra had a huge impact on a lot of the idea. He i the book actually calls him the first computer scientist. And I I guess I'll I'll take a quick step back. He Uncle Bob calls Grace Hopper the first software engineer.

And he kind of defines this, you know, of somebody who's thinking about the structures of stuff. Dexter's the first computer scientist in that we're really kind of understanding the theoretical boundary. And again, his background is in physics and in mathematics. he really was obsessed with provably correct algorithms, right? So he really wanted algorithms that you could say mathematically did exactly what they said, and certain characteristics come out of these, and I think.

One of the cool things that you'll learn it with you know, Dijkstra's algorithms that you'll learn in in an algorithms class is a lot of his algorithms have there's a beauty to them. Like you you kind of once you wrap your head around some of his graph theory stuff and some of the other pieces that he has, you're like, that's really cool. And it sounds some of them seem counterintuitive, but you're you're like, this actually does solve for this path, weighted path in this really interesting way where

You only need to know about neighbors. And all you do is like traverse the graph knowing about neighbors and the, you know, the values kind of like bubble up and then, you know, and you look at it and you're like, man, this is the mind that this came out of. It's really an interesting mind. And

Carter (35:43)

Right.

Nathan Toups (35:43)

at the same time, it wasn't without controversy. I there what was it? they they were talking about like the pretentiousness of a software of a programmer is measured in like nano deikstras or something, or might it it was a very funny like little

bat at him 'cause Dijkstra was, you know, he's very famous for having written the go to statements considered harmful paper.

Carter (36:05)

Yeah, yeah. Yeah.

Nathan Toups (36:08)

which is funny, he he actually didn't give it that title. I I didn't know this until reading this it was a it

Carter (36:12)

Yeah, what what's the original ty I think it's like i it

it's like a case against the go to stipe statement or something.

Nathan Toups (36:17)

Yes, it was it was a

it was much more like actually scientific sounding. And then the editor was like, Mm-mm, we've gotta punch this one up. And so I

Carter (36:24)

Right.

Nathan Toups (36:24)

I don't think he was actually trying to like rage bait as much. but then it's turned into this whole thing, like considered

Carter (36:30)

Yeah.

Nathan Toups (36:31)

harmful papers. I yeah. I would love to write a paper called considered harmful, considered harmful. And we can

Carter (36:37)

Yeah.

I know that was I know too much about American presidential politics. In the two thousand twelve campaign, Mitt Romney wrote a an op-ed because he's from Detroit and and his dad was like in the car industry. He wrote an op-ed bas

Nathan Toups (36:53)

Did not know that.

Carter (36:54)

yeah, basically saying like that and and the American auto entry was in a big crisis in the two thousand eight recession.

Basically an argument th the the the content of the op-ed, well controversial to some was more along the lines of like, this is fine, this is healthy, the car industry will emerge stronger from this. There might be some losers, but you know, we've done this before and and and we'll see. But the op-ed, the I I can't remember who printed the op-ed, but they titled it Let Detroit Go Bankrupt. And and so, like obviously it's just like a a terrible title. And so, anyhow, similar similarities to this idea of

You know, the I yeah, instead of a case against the go-to statement, it's go-to statement considered harmful. But what I also find really interesting about Dykstra here is you see this tension. And and there's tension still exists today to a degree. When talking about programming, which is like, okay, is this a science? Is it a craft? Is it like some people I know some people kind of call programming like blue collar work. And I think there are there are cases for all of these. Dykstra. Yeah. Yeah.

Nathan Toups (37:57)

Who what people who are you c who are you talking to that calls

the what? Like

Carter (38:01)

Yeah, yeah, yeah.

Well, no, exactly, right? Like and Dijkstra was kind of very like, no, no, no, this is like it's it's a it's a science. Like he th he envisioned a world where yeah, you would be able to kind of like mathematically prove individual subroutines, and then programmers, much like a mathematician, creates his or her proofs from the compendium of existing proofs, that we would instead kind of like mathematically prove.

These chunks of code correct. And then programmers would just borrow from them to create higher level code, which is so interesting because like you can see this model with like package management. This idea of like we have we're not mathematically proving that like this date format or library is correct, right? But we are trusting this functionality and pulling it in and using it. But

I I mean I'm more of the opinion, like I I have kind of said for years that programming is a fundamentally creative discipline. and so I like and you see this kind of like with the development of COBOL and and all these kind of early level languages, which is like, okay, well, should should programming be something that's even accessible to non-programmers? Right? Like, should you even there was debate over COBOL like

Should you use the the multiply symbol for to say multiply something, or should you have the full word multiplies? Right. and and so it's really interesting to see these these kind of tensions at like how accessible should this be to a to

Nathan Toups (39:45)

Right.

Carter (39:45)

an individual? And honestly, we still see these tensions today with like large language models, which is like, have we perhaps made programming too accessible? and given the power to people who don't quite understand.

what they're doing. but it's just, you know, what do they say? Like time is a flat circle, right?

Nathan Toups (40:03)

So I will say I'm in the

camp of I love putting power in the people who don't understand what they're doing because they're gonna constantly surprise

Carter (40:08)

Right. Yeah.

Nathan Toups (40:10)

us. And I think we we do see this, right? Like you know, when we took ideas of Unix out of the Ivory Tower that was Bell Labs and, you know, put it in the hands of the Linux community, it really thrived. And even though it lost its purity

Carter (40:23)

Right, right.

Nathan Toups (40:24)

and it probably made a lot of mistakes along the way, especially amongst the original creators, it also became something much bigger than itself. And

I will say I I've a a few months back I had like said something stupid on LinkedIn about which I don't really post on very much anymore, but I said something like there's no responsible way of running open claw. And I mean I actually I agree with this, but I also I what I should have had a follow-up with is like it's okay, you don't actually have to be responsible all the time. Right. Like you there's no responsible way to base jump, right? There's no responsible way to do all these other things that you may want to do because you have the gumption to do it.

And it's okay. we don't have to get approval from some, you know, approval board to do all the things we want to do. And

Carter (41:06)

Right, right.

Nathan Toups (41:07)

programming, again, also has this sort of like software in general has this idea that we kind of again we go through and say, hey, you know, Dykstra has this idea. I remember he he calls this out. I don't he d we don't really bring it up in the book, but I kind of looked up a few things. he argued that COBOL cripples the mind. He said that basic was mentally mutilated.

students beyond hope of regeneration, that APL was a mistake carried through to perfection. Like he he had some hot takes, right? He was like the king of hot takes. and to think that strongly about so much stuff in this in this area is just hilarious, right? You look back and you're like, man, come on. Like, did it really hurt people to

Carter (41:44)

Right, right. Yeah.

Nathan Toups (41:48)

learn basic? Basic was my first language and I don't write basic nor do I have any desire to, but it definitely it was my introduction in the sense of what could you write?

into a program like keeping track of a bunch of variables and then having those things interact with each other and it was the magic unlocked, right? Where I was like, I can like do stuff. I can like I'm limited by my imagination. That's how I looked at it. You know, I was like, okay, if I can think about how I want the system to function and then I can like write code to kind of do this. And I don't see that as I mean, sure, maybe I'm completely wrong. Maybe I'm mentally mutilated beyond any hope of regeneration.

Carter (42:24)

Ha ha

Nathan Toups (42:26)

And I just had no idea that that's what happened to me. And so Dykhtra, you know, is crying from wherever he is now. but at the same time,

Carter (42:34)

Yeah.

Nathan Toups (42:35)

like it's okay. It's okay to do things that are like the dumber version of something. Like,

Carter (42:41)

Right.

And I think you need to be able to have confidence and like and and conviction in the value you bring it to the world. And and and sometimes I'll see people online be like, We need to make this like a real deal engineering profession where you must be certified by a board. And and I'm like, Like I I I just fundamentally can't get behind this. Like I my bachelor's is in business management. Your bachelor's I mean theater, right? Right. We we went on to get our masters. Right.

Nathan Toups (43:04)

Yep. Theater. Theater with it focused in sound design. Yeah. Well, and

I will I will say there's a difference between you so, you know, I I don't think I should should need to go down to the permitting office to build like a skateboard ramp in my backyard, right?

Carter (43:18)

Right, right.

Nathan Toups (43:19)

But if I'm gonna build a house and sell it to other people,

Carter (43:23)

Right.

Nathan Toups (43:23)

I might need to get some extra, you know, am I using the right material? Is this thing gonna fall apart? Is like I do think we've avoided software engineering has avoided.

I haven't I guess I should say I have a nuanced idea here, which is if you're building a high-res apartment, I would really hope that the structural engineers have passed

Carter (43:41)

Right.

Nathan Toups (43:41)

some mustard. It wasn't just some guy who's like, I love structural engineering, I'm gonna buy some software,

Carter (43:45)

Yeah.

Nathan Toups (43:48)

let's build some buildings, right? Because you

Carter (43:49)

Yeah yeah.

Nathan Toups (43:50)

you have the the Dunning Kruger problem, you have the you know, all these issues where you're like, you don't know what you don't know. And that building might collapse. And I kind of I'm okay with a little bit of gatekeeping when

We're talking about getting a bank involved and having people build it and selling these properties to others. so yeah, maybe if you're building AI tools that change a 12 year old's perception of reality at Meta, maybe there should be a different way that we approach as a civilization what you're building and what claims you're making than me building a e-commerce platform for my mom and pop shop.

Right. Like I that's me building a ramp in my backyard, but in my opinion.

Carter (44:33)

Right.

Nathan Toups (44:33)

And is there some sort of like is there a way for us to say, hey, let's let these wild ideas, you know, get built and developed. But as soon as we rely on them in a certain way, or as soon as start making certain claims about the wellness of others or what you can rely on, maybe we need the equivalent of like a structural engineer or review board or something.

Carter (44:54)

Right.

Nathan Toups (44:55)

I don't know the answer to that, by the way. I I don't know what's the right level of

I think there's room for lots of corruption, in things that they there's lots I don't want to like add bureaucracy for the sake of it. but I don't know. I think there is a there there in the sense of like, you know, I don't want a vibe coded bridge, you know, like the the

Carter (45:17)

Yeah.

Nathan Toups (45:17)

you know, yeah, I don't want a vibe coded bridge from one city to the other that's gonna have a bunch of eighteen wheels drive on it all day.

Carter (45:24)

It's been really

interesting to see. Like I I've I've actually really enjoyed working at a startup for a lot of reasons, but especially with like as the field is undergoing a big transition with coding agents, because it's really fascinating being at a startup with a lot of really smart people, not just the engineers. but we have some and and and cooler heads prevail who are who are kind of like chomping at the bit to get into like the code code. We we we use a monorepo. And so like they want to get into the monorepo and like.

build features into the website. And we have ambitions to let them do that in like a, hey, you can tag the agent in Slack and be like, I would like to A B test this thing, right? Like I think the copy on this page is wrong. Or, you know, I think this button's too big or whatever. Like we have a we have ambitions and we're working towards that. Cause like I I love that. I I don't want to do that. I'm like let someone else do that. But sometimes someone would be like, I want to build this feature. And I've I've kind of taken the line of like,

You should use AI to get better at your job. Like your job is to like you're in the growth org, right? Your job is to bring more customers to the business. Like you shouldn't be spending your time vibe coding. Like be better at what you're good at. Don't become

Nathan Toups (46:37)

Interesting.

Carter (46:38)

the world's most mediocre engineer. But I think the reason people are like chomping at the bit to do it is because we are told AI is transforming the world, right? But here's the thing.

It it's really not, right? Like AI is really, really good at some things, like text and image generation. Like, yes, it's certainly transforming. I'm sure the world of stock photography will never be the same. And it's very, very well suited to programming. Like it it generates code really, really well. And so you have all these people who like want to be involved, and they're like, I I AI is transforming the world. I gotta, I gotta get on the AI train.

But then they're just reaching for the one thing it's really good at, which is coding. And so there's kind of like two ways as a software engineer to think about that, which is like, okay, maybe this advanced technology is coming from my job in particular, or maybe this technology, which is very, very powerful and has a lot of money behind it. Maybe I'm the only one who actually can utilize it effectively, which is a

Nathan Toups (47:44)

Right.

Carter (47:44)

really interesting place to be.

And and yeah, just seeing like that FOMO from other people, like I gotta be doing something with AI, I gotta be so doing something with AI, I'm like, you don't have to convince me to do anything with AI. Like I I saw the value and I see how it's transformed my work already. I don't know, it's a it's a really interesting place to be at with you know, the onset of this very weird and new and exciting technology.

Nathan Toups (48:10)

Yeah, it it and I th I think the through line of where where it ties this into some of these these folks in history as well is that getting tangled up in the details and the implementation part is the hard part, right? Like that I

Carter (48:24)

Yeah, yeah, yeah.

Nathan Toups (48:25)

think the AI tools can very if like they can tell you exactly what you want to hear, generate a hundred thousand lines of code to you know, to do the thing. And I would say it's gotten really good at like I think we we've talked about this else.

elsewhere like demo grade code where you it

Carter (48:42)

Yes, yes.

Nathan Toups (48:43)

basically like passes what I'm like, yeah, that's that is that's what I was looking for. But then you think about it as like, well, how does it integrate with the larger system? And is this

Carter (48:51)

Yep, yep.

Nathan Toups (48:52)

actually like well reasoned? And is this actually, you know, I it's funny because I spend a lot of time I have a personal project that I've been using Claude on a decent amount, but I I spent a tremendous amount of time like duking out

Carter (49:08)

Yeah. Yeah, yeah.

Nathan Toups (49:08)

design docs and

and i i really care about data structures and i've i've actually i'm experimenting with this like local first thing and i'm using SQLite but I'm also working on some sync sync engine stuff but I don't want any of the frameworks I actually have like a very particular idea of like how I want to do this and so I've decided to kind of like go down this rabbit hole of designing out this and that's the part I love. I love thinking about the

Carter (49:32)

Yeah, yeah.

Nathan Toups (49:34)

the minutiae of

Well, how does it need to work for my system? And how do I guarantee correctness and these other pieces? And I won't I don't want to vibe that away. Like I actually a guy asked me the other day, I was like, Total am I building something and he's like, you're vibe coding it. I was I'm I'm not, and he kind of rolled his eyes like, yeah, you're not augmented AI or whatever. And I was No, I I r that's true. Like, I I don't think

Carter (49:53)

Yeah, yeah.

Nathan Toups (49:54)

you understand. This is a a power tool, but it doesn't do my job for me, you know?

Carter (49:58)

Right, right.

Nathan Toups (49:59)

I I enjoy understanding why a system behaves a certain way. Now

It's a lot of the stuff I'm doing is written in Swift and I take care to read through, but I don't really understand all of the aspects. So, like from a from a from a Gellman perspective, I'm sure that a real Swift programmer is gonna look at this and go, man, you're not using this pattern, you're not doing that.

Carter (50:22)

Right, right.

Nathan Toups (50:23)

I'm sure I'm making some mistakes there. Though I am, I have found a few things as I've educated myself in Swift, and I'll bring it up and say, Hey, actually I want to use this pattern, or this is a

part of Swift UI that I think would be really useful and we'll do re retooling of it. I'm learning across a way and I'm not just sitting here and dialing it in. Right. I and I think that again, whatever level of granularity you want to have fun and play and think about stuff, it's really up to you. Right. Like I I do soft architecture stuff. I really care about the behavior of little machines. So I'm going to spend more time there. If you're like a product person and you actually don't care what the algorithms are.

And you really

Carter (51:03)

Right.

Nathan Toups (51:04)

just need to get like customers and subscribers and, you know, a bunch of stuff. Who cares if it's two times less efficient or not beautiful

Carter (51:12)

Right.

Nathan Toups (51:13)

to somebody who else is in the software industry? Like I get it. I

Carter (51:15)

I do find it's interesting because, you know, LLMs have just taken away the at the very least, what they have taken away is the physical act of typing on the keyboard for for most most of the time, right? Like

Nathan Toups (51:28)

Right.

Carter (51:28)

and just churn out code faster than we can. So I asked myself kind of like, okay, where where does that free us up bandwidth-wise? And and I was kind of telling my team, I was just like, I was like, we have this obsession, like we feel like we just need to be producing tons and tons of code.

And so it's like, if you have your agent running, kick off another agent so you can do more code. And I was telling them, I was just like, I don't know if that's the right approach for us as a team. Like, what I would love if while your agent is running, I'm like, go try to check out on the website and just

Nathan Toups (51:59)

Right.

Carter (51:59)

right and just like form some stronger opinions, right? About like how our checkout process works. I'm like, do you know how many daily active users we have? Go find that out, right? Can you tell me exactly like someone goes to a

Coach's profile page and they don't buy. Why aren't they buying? Can anyone answer me, answer this question? Right. I'm like, that's the kind of stuff. And like, and I have other engineers who just are not interested in those questions. Like, I have another engineer who like what he likes to do in his spare time is we have kind of our custom AI agent orchestrator, and he really wants to tune that and make that better, which I find really interesting for him, because for me.

I'm just the total opposite. Like, we're working in kind of a big new initiative that I'm in charge of. And I have found it so liberating to think much more of it from the product perspective of like, okay, how are we gonna kind of tie everything in the website together so that like navigability is really easy? Or how, if we want people to be looking at this new part of the website, how are we making sure that's not cannibalizing sales on the existing part of the website? and

I've always found that more interesting. Like there was a a point in my career, like a few years in, where I wasn't loving, I was in a very kind of like technical in the weeds part of software, which I've just learned for me is not what I want to do with my life. I I am much more of like a product-minded engineer. And I

Nathan Toups (53:24)

Right.

Carter (53:25)

but I was like, I didn't quite understand like the dynamic and that you could be that, but I was like, I'm gonna quit and be a product manager. Like that's what I find more interesting. And so for me,

Nathan Toups (53:33)

Yeah, that's

yeah.

Carter (53:35)

Yeah, it's a d I I like this new paradigm. I I like all this bandwidth to to think about all this other stuff.

Nathan Toups (53:45)

no, it's it's it's been really it's it's really interesting to see like which areas that I my favorite, and I think this is one of the things I loved as a CTO. So this is one of the things I loved working in platform, is one of the things that motivates me is like, can we maximize the number of best days at work that you could have? Right.

Carter (54:01)

Yeah, yeah.

Nathan Toups (54:02)

Am I working around people who are like super excited about the things that they're working on, the technology, the trajectory that we're going on, and I actually really care about others?

When it comes to this, like I I really want to help solve this sort of like problems for teams. And I think if if I do think of a through line of like what's kind of I've gravitated towards now, I also love diving in deep. I really enjoy the computer sciencey parts to this.

Carter (54:29)

Mm-hmm.

Nathan Toups (54:29)

And that's helped give me cloud. Like I can have a good conversation with somebody who feels supported, who maybe figures out a more a better way to say, Hey, look, if you give me enough wiggle room, I can

categorically solve problems for the business. If you would just like take me out of half the meetings and like let me just kind of like

Carter (54:46)

Right, right.

Nathan Toups (54:47)

go wild. Right. And and it could also be with AI stuff. But also we need, we need folks who product I I'm a huge fan of in the sense that it keeps us honest, right? Product says, are I actually building something valuable? Not just something

Carter (55:00)

Mm-hmm.

Nathan Toups (55:00)

I think is cool, but is it actually something valuable to other people? And I to me that's the sort of like, I need good product people to make sure that I'm not just got the wonderlust of

Carter (55:11)

Right.

Nathan Toups (55:11)

yeah, but

my algorithm's like so efficient. You're like, yeah, it's super efficient for the like two customers that we have, right? What do you Yeah.

Carter (55:16)

Yeah, I well but

my first year at this startup I I kind of took on a lot of low-hanging technical fruit, which was like, hey, guess what? The site went down every time you deployed something. Like I'm gonna I'm gonna I'm gonna fix that, right? Right.

Nathan Toups (55:25)

Right. Remember that. Right.

Carter (55:29)

I so you know, we got CICD. I'm like, we don't have anything in Terraform. Like, I'm gonna fix that, right? We we were on Azure and wanted to be on AWS and migrated us to AWS. And then the big one was rewriting the back end, you know, the migration as we called it, right? And so that was a really interesting technical challenge.

Okay, how do we, especially the biggest part was getting from Mongo to Postgres? And like, how do you we had to have three months where we were basically running to, we were writing to one database and reading from another. Like, how do you, how do you do that? And how do you cut over? And and so like it was a really, really interesting technical challenge. I was very happy to lead it because like I felt like I hadn't done a project like that in my career as a nice little feather on my cap. But I also said I'm like, look, I'm aware that at a certain point, this is the coward's way out because I can kind of point to the the

Real d just the the results and be like, I succeeded. I can tell you I succeeded because the website used to run in this language with this stack and this database and this protocol, and now it doesn't. And I can point you to our metrics and I can say P99 used to be the latency used to be like two and a half seconds, and now it's 400 milliseconds. And so I can say, like, look, that was a success, but at the end of the day, that didn't help the business make any more money, right? Like there, there, there are some value there in that, like.

I'm sure we're making some more money that the site doesn't just freeze up you know at times. But now it comes like the product perspective, which is like, okay, now I have to design this product that there there aren't as many clear right answers. But I do, I again, I'm I'm loving it because even a startup, when I joined a year ago, before kind of coding agents really took off, and I would kind of have all like these product ideas and I'd be like, well, what about this? What about this? What about this? Right. And and some of the product are like,

like bristle a little. I'm like, I don't know. Why is this engineer offering ideas? And I I kind of talked to my boss about it. I'm like, I don't know. I feel like my ideas aren't being taken seriously. And he said he's like, it's not a you thing. He's like, people just get like this. Engineers are expensive. And so anytime an engineer isn't doing engineering work, people kind of go like, well, why are you talking about this? We need you just producing as much code as you possibly can. Yeah.

Nathan Toups (57:36)

That's so fascinating. Yeah.

Carter (57:38)

But but it's flipped now because now it's like, well,

Nathan Toups (57:41)

Right.

Carter (57:41)

the the engineer is faster.

And so maybe and and and sometimes the engineer can move and certain domains can move faster than the product person can. And so we are really evangelizing in our company this idea that like engineers need to be product thinkers because they can have an idea and they can build that idea in a day or two. Right. And so, and obviously this is a startup, right? I'm well aware of the complexities of larger organizations. we've gone off the rails a bit here, but I have to kind of yeah.

Nathan Toups (58:08)

No, this is great. So

I think where this t actually ties in is like I think we can kind of speed run seven through ten.

Carter (58:17)

Right. Well that yeah, Thompson, Richie, and Kernahan we did two full episodes on, right. Or or one, right.

Nathan Toups (58:21)

Yeah, yeah. And I

and I will say, while actually we can skip to 10 and then move loop back real quick. This is a great introduction to the Thomas Ritchie and Kernahan Bell Labs days of like what was the environment that created Unix, the C programming language? what role did Kernahan play in publicly communicating the, you know, sort of the style guides and understanding of like why this approach to programming works so well? And you can see that.

Uncle Bob was deeply inspired by what they call the KR book, which is the Kernahan and Richie C book that came out in 1978. and it changed he he was like an assembly programmer, sort of died in the wool and realized this higher level language, you know, at the time was considered higher level language, was amazing. And he ended up, you know, sort of evangelizing this. Like the places that he worked, he became they they became C shops. I will say if you are interested in this topic.

I highly recommend reading Unix a Philosop you know, Eunuch's A Philosophy in a memoir, which is the Kern book, which goes into much more depth on all these, but from a large overview standpoint, I thought it was really, really good.

Carter (59:31)

Yeah, yeah. Well, and we've talked a lot about Unix, but again, just it gets back to this concept of like things that we consider fundamental, someone had to invent at a certain point. The idea of the pipe, right? That programs should just be able to, you know, they should have input, they should have output, they should be able to connect to each

Nathan Toups (59:45)

Yeah, McElroy well, and

Carter (59:48)

other.

Nathan Toups (59:48)

I also did love that how quickly they were able to kind of you know, the the sort of heyday of all of these ideas happened within like a four-year window of like the real systemic sort of core Unix philosophy ideas. And then of course the whole world took these things on. I also loved that it kind of came out of the ashes of Unix of of multics, right? Which again,

Carter (1:00:09)

Right.

Nathan Toups (1:00:10)

big ball of mud, right?

Too many people involved, way too ambitious in what it was trying to do. It was trying to solve every type of problem. And so every committee had to come up with like 15 different ways of of doing things. And Ken Thompson came in and solved a very specific set of problems for himself and realized it was generalizable. And I think that it's just a constant reminder that the tools that we choose and their approach that we take to a problem can have these sort of revolutionary breakthroughs if we give them a chance.

And that if you try to do a complex system from day one, it's just gonna be irreducibly terrible, right? But if you can come up with some foundational principles and build off of it, you don't have any control over whether it's gonna actually catch on like wildfire or not. I think that they just happen to be at the right place at the right time. with some prolific thinkers, right? Richie Thompson and Koernahan, McElroy, all these folks were just such a unique

group Bill Labs at the time was a unique place to be able to be the catalyst for this. the types of business problems they tried to solve, which is a bunch of document processing things. They just got lucky, right? They I think really lucky and amazing, all mixed up in one.

Carter (1:01:23)

Right, right. well we can talk a bit about John Kimetti and Judith Allen.

Nathan Toups (1:01:30)

Yeah, we yeah,

we yeah, well so we yeah we have Nygarden Doll, which I think one a quick quick shout out

Carter (1:01:35)

no, you're not at all. Yeah.

Nathan Toups (1:01:35)

to, right? Which is simula and then Algol 60. I think these are sort of the foundations of object-oriented, even though it wasn't that, it was really

Carter (1:01:45)

Mm-hmm.

Nathan Toups (1:01:46)

more of like domain modeling is the focus. But object oriented per like encapsulation and stuff kind of came out of this, and I think he makes a really good argument that simula

To small talk to C. Like there's a this yeah, Bjorn who creates C, which is this object oriented version of you know, is the goal being it compiles down to C and then C compiles down. it there's a lineage to Java, right? So it's like simulus, small talk, C Java, right? And this is huge impact in thinking. And again, two interesting folks who invented this whole new way of thinking about computing at the time. And I

I think it would absolutely deserve the same chapter.

Carter (1:02:32)

yeah, this John my gosh, how do you say Keminy? I think. Yeah.

Nathan Toups (1:02:37)

Yeah, that sounds great. I didn't I'm

not 100% sure how to pronounce it either. But he's the inventor of basic, right?

Carter (1:02:41)

Yeah, he is the inventor of basic. Yeah.

Nathan Toups (1:02:44)

yeah, much to Dykstra's chagrin. he is the inventor of basic. But again, I think this is to me, this was the equivalent of he's the programming equivalent to making the Raspberry Pi, right? It's like this very approachable language that literally was on every system. Everybody if anybody had like a Commodore or any these things, some version of a basic.

Down the road was probably your first language. That's probably, you know, if you grew up in the 70s or 80s, it was probably your first time programming. and yeah, it again, I I think there's this thing of like the worst is better idea, right? Dijkstra, sure, you probably had some beautiful way that if you had, you know, advanced mathematics and everything else, you probably could express your thoughts in a much more performant and clear way. But if I could turn on something and have it show up on my

TV screen at the house and write a couple lines of code and have something come out the other side. There's something, there's a value to that, right? There's there's something really special about.

Carter (1:03:45)

Well

and he's he saw the future of of networking.

Nathan Toups (1:03:51)

Yeah,

yeah. It there's so many there there's beautiful I d and again he this idea that he wanted everyone to have the ability to program, right? Like his where Dijkstra I think probably thought, hey, only a subset of people actually even deserve to program. You know, you kind of have to be up here in these this ivory tower.

John was like, no, actually, we should get this in everybody's hands. Like, how cool is this? Like we should make it as cheap as approachable as possible for people to to write programs.

Carter (1:04:22)

Right, right. Well, and then we should give a quick mention to Judith Allen. This chapter is very, very short. I'm trying to

Nathan Toups (1:04:30)

And she's also like not not a lot known. There's another Alan. shoot, I forgot her name. There's another woman.

Carter (1:04:36)

There's a famous Judith

Allen like the actress.

Nathan Toups (1:04:41)

Yeah, no, there's there's a there's another Alan, another woman in computer science. And there's actually a couple of women that were not mentioned. There's another woman with the name Alan. I forget now. She was actually the first Turing Award winner.

Carter (1:04:51)

cool.

Nathan Toups (1:04:51)

shoot. And and then also Lis Liskov. She's not mentioned in this at this point. She is mentioned later. Liskov is really important. again from Dike like Dijkstra level algorithms and stuff, but I'm sure we'll get into her through the memoir

Carter (1:05:05)

Yeah.

Nathan Toups (1:05:06)

section. But

She was interesting because it I didn't think again, I didn't think about this of like what did it take to actually like ship computers and get them in the hands of schools and like general customers. And this lady who's like largely been forgotten to history, actually played like a really important role in let me go back and look in the book.

Let me pull her her section up because it was it was very interesting because there's like a personal piece to this.

She yeah, she kind of had this like saying she was like a product of the sort of like feminist movement that had emerged at this point and kind of didn't take no for an answer and kind of got her way in to what was it? What was the specific thing that she was working on? Yeah, first she was the first girl in the computer programming class.

what what was the thing? I I'm I'm sad that I'm like at a loss to what

It's gonna drive me nuts.

Carter (1:06:29)

I know, this is

This is Yeah.

Nathan Toups (1:06:34)

But yeah, she ended up

she she was working on this machine called the ECP eighteen. And I'm I'm trying to remember exactly what her contribution was here. It was a really a cool story. It's a short chapter, but it's a really cool story. That's gonna drive me nuts.

Carter (1:06:50)

Might have to get on the next episode. Okay.

Nathan Toups (1:06:51)

Yeah.

Yeah. Yeah. I'll I'm gonna go back and do my research and we'll give we'll

Carter (1:06:55)

Like it's

Nathan Toups (1:06:56)

we'll give Judy Allen her proper her proper credence 'cause I yeah, I I

Carter (1:07:01)

What do I say?

This is not a book, it's not a book report mass grading as a podcast. This is a book club masquerading as podcast. And so

Nathan Toups (1:07:07)

Yeah.

Carter (1:07:08)

sometimes we don't remember all the exact details. But at any rate, this is you know, we are now through the historical section of the book, and now it turns into a bit more of a biography of Uncle Bob, which I'm curious about because I actually really liked his clean coder book, which is a biography in the same it's it's a it's like life lessons for programmers, but it's well as a biography of

Uncle Bob. And he gets pretty, you know, like I think some people could be inclined to think of Uncle Bob as someone who's just like, well, aren't I so great? But what I love about Claim Coder, he talks about, like, yeah, I was a screw up. Like I got fired. Like I did this

Nathan Toups (1:07:42)

Right.

Carter (1:07:42)

wrong. I did that wrong. And so I'm curious if this final third will lean into some of that. I and I think we see that with a lot of the figures in this book, is that like you can kind of look and be like, well, Grace Hopper, like Grace Hopper was amazing and fantastic. And

I could never do what she did. And you know, that's probably true. But Grace Hopper had low points in her career and points where thing, you know, things didn't look like they were going great. And so I always find that inspiring to read from, you know, the giants whose shoulders we stand on that they were people, people just like us. And you know, just like we have our low points, they had theirs. And, you know, whereas if we take inspiration from them, we'll get past those low points. yeah.

Nathan Toups (1:08:30)

Yeah. Yes, they had people who that either inspired them or that they were rebelling against, right? These sort of ideas. every one of these people though gets into this this what I would I'm calling what mihai chisek mi hai calls the the autitelic pursuits. This idea of fe finding this feedback loop where you find something that you're that's useful.

and that you're just doing it for the love of doing it and it actually ends up being valuable to other people and that you get to like play where you're working hard but you're also kind of playing right it's a it's kind of like feels weird because you know I guarantee you that Ken Thompson when he was working on these deeply interesting problems in building an operating system wasn't doing this for some specific outcome. He was doing it because he was deeply interested in like could I do this? Can I give this

File system abstraction on top of a machine so that all you have to think about is the file, right? Like that's a deeply interesting problem to him. Grace Hopper is the same way. It's like, and so yes, while we are not of the, you know, esteem or intelligence or at necessarily you know, these incredibly unique individuals, can we tap into something that gets us excited for its own sake? that's also valuable to other people around us. You know, I I think.

studying these people says like, hey, can I get a glimpse of that? Can I be trusted to take a risk on an idea with people around

Carter (1:10:03)

Right.

Nathan Toups (1:10:03)

me that I enjoy working with? Right. And sure, maybe you're not going to get written into a a history of programming, but did you get to enjoy more days than you didn't, you know, working on interesting problems with cool people.

Carter (1:10:14)

Yeah, I I think all the time it's hard to compete with someone who thinks they're having fun. And you know reading

Nathan Toups (1:10:20)

That's exactly right. That's exactly right.

Carter (1:10:23)

reading about these figures, like that's that's them. I don't really have any hot takes this week,

Nathan Toups (1:10:29)

No, no hot takes for me.

Carter (1:10:31)

No,

no. Good, good history lesson. Good to know your history. as far as what we're gonna do differently in our career, I this is something I've I've said on the podcast before. I wish I understood computers at a more granular level. Like, and and I think like you can't fault yourself too much because, like, for example, I spent a chunk of last week setting up. We wanted to do preview environments for our services on like feature on on PRs. And so I was like, you know what?

I don't know a ton about Kubernetes, but like this seems like a job for Kubernetes, right? Just the ability to spin up and spin down services kind of ephemerally. Like I know, I know that. And so I I had Claude whip up this Kubernetes thing and like it worked. And then I spent like six hours chatting with Claude about it and and figuring, like, okay,

you you made a namespace. What what is a namespace? Talk me through that. And like I wrote this big document, like this big QA to really understand what was going on.

Nathan Toups (1:11:29)

If ever wanna talk

Kubernetes, I I'm a I'm a big fan in the right scenarios. So it's it's

Carter (1:11:34)

Yeah, yeah.

Nathan Toups (1:11:35)

a beast, but it can be amazing too. So

Carter (1:11:37)

Yeah. And so for us, I I since it's just like pure preview stuff pointed at our staging and like gated behind like we we use Cloudflare some authentication. Like I'm kind of okay if this is like minorly vibe coded. But I guess what I'm getting at here is that like Grace Hopper never had to learn about Kubernetes, right? Not that she could, right? You know, she was a genius, right? But like I'm having to understand this kind of like galaxy brain networking. And so like of course I've never kind of

try to understand like how the individual bits are flowing into the registers. But reading about this and especially hearing Uncle Bob talk about this, like he just understands this at a very deep level. And I'm like, man, I wish, I wish I could do that. I wish I were a little better at that. So I and the problem is I don't think my career will ever lead me to need to be able to do that. But I do have respect for it. And so I I don't know. I want to get better at that. I don't know how I'm going to do it, but I want to

Nathan Toups (1:12:29)

Carter (1:12:29)

get better.

Nathan Toups (1:12:29)

it and as I've brought up in the Discord, I'm a big advocate for doing working on useless things. And by useless, I don't

Carter (1:12:37)

Right.

Nathan Toups (1:12:37)

mean a waste of time. I mean it's okay if you just kind of explore the depths of something that looks interesting. You're like, it may not turn into anything directly, but I guarantee you that yeah, understanding how memory registers work on one of these old computers, it will give you a deep appreciation for, you know, things.

Carter (1:12:56)

Have have you ever heard of from

NAND to Tetris?

Nathan Toups (1:13:01)

No.

Carter (1:13:02)

It's yeah, NAND to Tetris. It's NAND number two Tetris. But it's an idea, like it takes you from like the very fundamental bit like of how computer works, and it's a whole kind of course. It's very useless, like you talk about. But from that, you build a working Tetris game. and

Nathan Toups (1:13:19)

That's cool. Yeah.

Carter (1:13:20)

and like that's something where like I've wanted to do this for a while. I am a busy man at a startup who was getting a master's degree and now I have five children, and so I just have never had time to do this.

Nathan Toups (1:13:28)

Hey, but this is a good replacement

for Doom Scroll time or whatever. You know, like they're

Carter (1:13:31)

That's true. That's true. Right.

Nathan Toups (1:13:33)

and we we know we can make time if we really value it with grad school. And

Carter (1:13:37)

Yeah, that's fair.

Nathan Toups (1:13:38)

that kind of thing, especially if you time box it, I think it could be that's really awesome. That's really awesome. I I want to actually

Carter (1:13:42)

Yeah, I I that's a project I've been wanting to take on for a while. So yeah.

Nathan Toups (1:13:46)

I want to learn more about Grace Hopper. I I mean

Carter (1:13:48)

okay.

Nathan Toups (1:13:49)

I have a more than average knowledge, but actually I think I would like to do a research spike and really kind of appreciate.

her contributions, especially when it comes to data, 'cause I I don't know, every time I see a quote of hers, I'm just like, that's a deep, insightful, like, understanding of the universe. And I think the more I expose to her thinking, the better. So

Carter (1:14:10)

Yeah, yeah. Okay. Well, that takes us through the middle third of this book. We'll be back next week to finish it. as always, find us on Twitter at Book Overflow Pod. You can contact us at contact at BookWorldflow.io. Our site is bookoverflow.io, which is more beautiful by the day, as Nathan has taken quite a quite stewardship over it. and Nathan and his work with the consulting agency at Roho Roboto dot com, with his newsletter there at slash newsletter. thanks for tuning in, everyone. we'll see you next week.

Nathan Toups (1:14:39)

Yeah.