Has AI changed everything about software development? - The Mythical Man-Month by Fred Brooks

Nathan Toups (00:00)

I haven't seen someone who

is using these tools and I'm like, you're living in another universe. Like I'm a caveman over here using stone tools, banging on something and you're flying around in a spaceship. Like I've not seen that.

Carter Morgan (00:09)

Yes.

Hey there, this is Book Overflow. This 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. I'm joined here as always by my cohost, Nathan Doops. How are you doing, Nathan?

Nathan Toups (00:32)

Doing great here, everybody.

Carter Morgan (00:34)

Well, as always, make sure to like comment, subscribe and join the discord. You can book time with us on Leland. All those links are in the episode description and you should also check out our interview with Lawrence Kessalut. You're listening to this on a Monday. We just launched that on Thursday. This I really, really enjoyed this. Lawrence Kessalut is the author of coding machines. It's just a short story. Only short story he's ever written. We reached out to him. We reached out to basically every author who we could find their contact info and.

Nathan Toups (00:53)

Yep.

Carter Morgan (01:03)

Kind of say, he's like, you know, I don't really do stuff like this, but it listened to a couple of episodes of the podcast. He enjoyed it and he wanted to come on. And I thought it was a really fun, really engaging discussion. and you know, it's kind like you interview like Brian Kernahan. You're like, well, of course you're going to get tons of great stuff out of Brian Kernahan. But Lawrence Kessler is basically just a software engineer like us, but really insightful, really fascinating guy. I really enjoyed this interview.

Nathan Toups (01:24)

Also,

first Oscar award winner on the podcast, because he worked on the software that built the Edge Dreamworks that worked on Shrek, like the coding engine for that. Other fun thing, he is on our Discord. And not only that, we read his book because somebody on our Discord recommended that we read this and the Ken Thompson essay. So I will tell you that this is a very special interview to us because it only was possible because of our community.

Carter Morgan (01:33)

wow.

Yeah.

Nathan Toups (01:53)

It was only possible because of feedback. And now we've got this cool feedback loop where like Carl Brown and Kesalut are all hanging out in Discord. Yeah, that's right, and Austin McDonald, that's right. So we have several of our authors and guests of the podcast who've gotten on there. And still it's very small community. think we're still under 400 Discord members. But hey, you can get in the ground floor. I think there's only a few slots left to get a special

Carter Morgan (02:01)

Austin McDonald too.

Nathan Toups (02:21)

badge called Beta Tester. And so I think we're about to hit 256, which is the limit to how many people can be in the Beta Tester category. And yeah, we'd love to see you on there. Actually, Carter and I both hang out and the community has been really sharing wonderful links. It's very similar temperament to what we have on this podcast. There's no flame wars. It's not crazy. We get a little spam bots every once in while, but we clean them up. It's a nice place to hang out.

Carter Morgan (02:50)

You should see Nathan and I's group chat though. That is just nothing but flame wars. Constant tension. Uh, well yeah. Um, so I really enjoyed that interview and, just left really, you know, the kind of interview where you leave feeling very jazzed about our field. And, uh, it was very kind of Lawrence to come on the, on the podcast. And you know, today we're actually reading the mythical manma. This is someone.

Nathan Toups (02:55)

Yeah, yeah, we're just trolling each other all day. Intolerable, yeah.

Carter Morgan (03:19)

We're talking about we would love to interview. Unfortunately, Fred Brooks, Brooks passed away a few years ago, entirely expected. He wrote mythical man month in 1976 when he was already professional software engineer. So good, long, happy life from everything I've been able to surmise. Um, we said last week, cause we're doing on the calendar was learning domain driven design. And we're still going to read that. Um, but just mythical man month is something I've been thinking about a lot. think it's something.

we've mentioned on the podcast before like, okay, like Jeff Bezos who kind of said like, it's more interesting to talk about what won't change in 10 years than what will change. And so this is kind one of the cornerstones of software engineering management thought. And so, you know, in a world where,

People are trying to say that the entire script is flipped and everything we've done needs to be thrown out the window. We thought, you know what, maybe we should read, let's go back to the basics. Let's read this. We can kind of ask ourselves, okay, what hasn't changed? So let me give you the author and book introduction. go ahead, Nathan.

Nathan Toups (04:21)

him.

No,

no, go ahead. was like, is it still relevant? Right? Like this is should you read Mythical Man Month in 2026? And yeah.

Carter Morgan (04:27)

Absolutely.

Cause

I had never read it. Have you read it before? Yeah.

Nathan Toups (04:34)

No, I knew of

it. I think I've read the No Silver Bullet essay, which is a famous essay that came out later, but is now included in this 20th anniversary edition. I knew of it, and we've had several guests on. think it was Kernahan, and think Martin Fowler, and a couple others had mentioned this. I'm like, oh yeah, you know this concept in Mythical Main Month. I'm like, haven't read that one yet.

Carter Morgan (04:47)

Right, so, yeah.

Yeah. So, you know, we figured we got to read it and yeah, we're, you know, you can always tell us in the comments, you can always email us. there's been a lot of AI discussion on this podcast. We, we strive to make evergreen content, but I think even more important to us than making evergreen content is making content that kind of cuts through the hype, making content that, we feel is honest and thoughtful and reflective. and you know, AI is very, it's a,

It's a big topic of discussion in our industry. It was really changing a lot of our workflows. And I know when I am online or, you know, like I kind of crave like opinions from trusted voices on the subject. so Nathan, we don't know everything and in a lot of ways we can't see into the future, right? But we're talking about this a lot and we are hoping you find it useful and kind of navigating these uncertain times. But I always say in the comments, like, you know what, I like.

some of the more evergreen meat and potatoes stuff and you know, we may adjust course. Anyhow, let's talk about this book. We got the author introduction. Frederick Brooks Jr. was an American computer scientist and software engineer who managed the development of IBM System 360 mainframe family and its OS 360 operating system in the 1960s. The hard-won experience that became the source material for the Mythical Man Month. He coined the term computer architecture. Geez Louise. To have that.

on your resume, founded the computer science department at UNC Chapel Hill in 1964 and chaired it for 20 years. Brooks received the National Medal of Technology in 1985 and the ACM Turing Award in 1999 and is also widely known for his essay No Silver Bullet. He died in November 2022 at the age of 91. Like we said, a life well lived. For the book introduction, we have a few books on software project management that are influential and timeless as the mystical man month.

With a blend of software engineering facts and thought provoking opinions, Fred Brooks offers insight for anyone managing complex projects. These essays draw from his experience as project manager for the IBM System 360 computer family and then for OS 360, its massive software system. Now 20 years after the initial publication of his book, Brooks has revisited his original ideas and added new thoughts and advice, both for readers already familiar with his work and for readers discovering it for the first time.

So kind of crazy that the 20th anniversary edition was published in 1995. So, you know, we are doing at this point, I mean, this is a 30, this is a 30 year reflection on the 20 year anniversary. So we're about 50 years post mythical man month. Nathan, you know, like you said, this is something pretty much everyone knows about, but I think if you have actually taken the time to read. So after now we've read it. So give me your thoughts.

Nathan Toups (07:24)

Alright.

Yep.

Yeah, so I mean...

This one is, one of those books where I'm embarrassed that I hadn't actually read it at this point. And it's also funny that we're almost two years into this podcast and we hadn't read it, right? Like we kind of front loaded a lot of the classics. I think we're probably going to even like revisit some of those. And we were looking at books that were 25, 30 years old sometimes. And this one, you know, predates all of them. And you can see what an influence he was in the field. And you also can see like,

You get two sides of this. You get how much the world has changed. Like, he makes these predictions. He makes some ideas of like, hey, we're thinking about this wrong, or it's really important that you have sharp tools. Like, we're going to get into these kind of ideas later. And then you also see, like, what hasn't changed. The fact that, like, humans are still really bad at predicting how long it's going to take to do a project or...

Carter Morgan (08:46)

Yeah.

Nathan Toups (08:46)

that we get 90 % done and we just die in the last 10 % of the implementation. All of these things are happening way back when he was writing this stuff and reflecting on his time at IBM back in 1975. And it's so weird. In one way, the book has a snapshot into the past that you're like, oh, wow. You're really worried about the super tiny amount of addressable memory that you have or like,

the time sharing systems, like he talks about these things. And then you also are like, this could, this is advice that I need right now for dealing with augmented AI development. Like I'm slipping on these philosophical things in the same way that he was talking about the problems that people had back then. And I think he's the clarity of thinking is just so strong that you just immediately can apply it into your life. And so I don't know, like I,

I'm obsessed and we'll get into this. There's this term he uses in the book. I think it's probably one of the thesis statements of this concept called conceptual integrity. I'll probably be riffing on that a decent amount on the episode, but it like struck me. Like I was like, this is what, this is such an important thing of like, what is What is software engineering in this world of AI? How does the mind, how does our mind work with all these tools? And yeah, we'll get into it, but conceptual integrity, if you take one thing away.

That's the one I'm excited about talking on. What about you?

Carter Morgan (10:18)

Yeah, mean, great to read something that's so seminal. I think I've always found myself very interested in like the final mile problem. You know, just this idea that like,

that that final mile of basically anything gets like weirdly difficult. actually, I worked for a company once that like dealt with like final mile delivery and like it's a much trickier problem than you think. And like just that kind of, that whole 90 % done concept, right? Which like we did 90%, that's the hard part, right? And like that final 10 % is still so difficult. And I read an interesting.

Nathan Toups (10:54)

Right.

Carter Morgan (11:01)

Twitter essay, think it was called like the never ending final mile, which is like, even as technology gets better and gets better at covering the journey up until the final mile, right? Like that final mile still exists and it just keeps getting not longer and longer necessarily, but more like,

Like our standards get higher and uh, and The final mile of today is not necessarily the final mile of tomorrow And I think if you look at you know, how software was developed in 1975 and in 1995 when the essay was written when this reflection was written um Like our software is just infinitely more complex than it was back in those days, right? And so um

Nathan Toups (11:27)

Yeah.

Great.

Carter Morgan (11:51)

So long as that kind of 90 % complete problem is a problem, don't think it's like, it's not going to go away, right? It's not going to, because our expectations are just going to get higher. Anyhow, very interesting stuff from Brooks. I'm excited to kind of dig into it and talk a little bit more about it. Yeah.

Nathan Toups (12:11)

it

Yeah,

I am too. And it does, it ties into what we just finished in Tony Fidel's book, Build. You know, he also obsessed over that last 10%. Like the 90 % good enough problem is a real problem. And I actually think that the agentic stuff exacerbates it if you're not careful, right?

Carter Morgan (12:32)

Well, let's take a quick break and then we're going to get into all of that

so this book has tons of essays. It's got like 19 chapters or something crazy like that. I'm not be able to talk about all of them, but we do wanna talk about, of course, the most prominent one, which is the Mythical Man Month. Nathan, do you wanna just summarize the basic ideas behind the Mythical Man Month for any of our listeners who aren't familiar?

Nathan Toups (12:41)

Yeah.

Yeah, so I mean, he ends up getting this thing called Brooks Law. People will quote it all the time, which is adding manpower to a late project makes it later. He later kind of put some critique on the set. Actually, this isn't always true. But in general, I think especially for new managers, because in a lot of ways, this book seems like it's a book for new managers, people who are having to figure out how do I transition from writing code in which it all fits in my mind and I'm the only person working on it to having a large team.

work on some large scale project. And you gotta remember in the 1970s, this is a new concept, right? Like this idea, and a lot of it he brings up Department of Defense and all these other things, which again, who would have been the clients at the time. One of the things that I thought really brought it home, and I've heard somebody mentioned this before, of like, here's where Brooks Law kind of comes in. That it basically is saying that time and people aren't fungible.

Carter Morgan (13:29)

Right, right.

Right.

Nathan Toups (13:50)

They're not just a one-to-one, like, it's going to take a thousand man hours to do this thing. And so I'll just divide that by the number of people that I have and therefore I can get it done in some shorter period of time. One of the arguments he makes is, and I thought it was very funny, was pregnancy. So he's like, well, need 10 babies, right? So we'll just divide up the amount of time across the number of women.

Carter Morgan (14:09)

Yes, yes.

Nathan Toups (14:20)

You know, it takes nine months to make a baby. We'll just have like, we'll just add nine women to this and they can each make a baby a month, right? Like it's like, but you can't do that, right? If you need, if you need more babies, you just have to have more women being pregnant for nine months. you know, like, and it's going to take nine months, a fixed amount of time, right? You can do it in an embarrassingly parallel. can horizontally scale the number of the amount of output that you'll get at the end of nine months.

Carter Morgan (14:35)

Right, right, yeah.

Nathan Toups (14:48)

but you're not gonna make the project of making a baby faster. It's never gonna take less than nine months. And that certain types of work just have these sort of like stacked procedural things. And so if you're like, my project's running late, let me just throw a bunch more people on it. Well, now you have to coordinate, you still have external dependencies, you still have to do testing, you still have to get it deployed. Like all of these things, like adding more people to it isn't gonna make any of that stuff easier. And most of the...

Carter Morgan (15:16)

Right.

Nathan Toups (15:17)

most of the time it's actually make it harder. like, how do I get them up to speed? Do they actually understand? Are they gonna be in conflict? Like, are they actually good at working as a team? And so this idea of like sequential dependencies versus what's paralyzable, that was the big takeaway. again, timeless, timeless advice. Every one of us have made this mistake. I mean, it's embarrassing how many times I've made this mistake.

Carter Morgan (15:36)

Right.

Yeah. Well, yeah. And especially that idea that like, as you add more people to a project, like communication channels grow, right? Because it's like you add, if a team of eight and you know, it's like whatever eight times eight is, so 64, right? That's like 64 different communication. It's not eight times eight. It's eight. What is the actual formula? N times N minus one divided by two, right?

Nathan Toups (15:57)

Right.

It's geometric, it's n times n minus one divided by two, right? So it's this thing, yeah,

there's this geometric thing where, yes, the more people that have to communicate, and we've all seen those graphs, right? You have three people, that's a very simple one, and then you get to like 16 and it's just like a bunch of lines crossing each other, like 144, know, lines of communication or whatever.

Carter Morgan (16:13)

Right,

Yeah. Right.

Now this is interesting and kind of like the AI age, because I think you could argue that LLMs do really reduce this problem if there's no longer coordination required from humans. And instead it's like one engineer managing agents, right? But you can also make the same

But then I kind of think like, I know, what was it? Coinbase or whatever, like one of the companies that just did layoffs and they said, like, they want all their managers to, to be individual contributors and managers, which I usually think makes sense in this day and age. think the idea that like, you can't have a manager that's not hands on developing and in some respect is probably the correct move, but they want the managing like teams of 15 engineers. And I'm just kind of like,

Again, when you just talk about like that geometric explosion of communication paths, like that seems insane. I've worked on a team with like 15 engineers and it sucked and inevitably it resulted into like that team actually being like four squads, right? But then like those squads overlapped and like, I know it was bad.

Nathan Toups (17:32)

Great.

Yeah. No,

my back of the envelope math, I'm proud of myself. If you have 16 people, then it's 15 times 16 divided by 2 is 120. So I was actually pretty accurate. So it's awful, right? Like you have a team of three. You legitimately have just like three lines of communication. That's it. You can work so quickly. And he makes this argument actually skipping ahead to chapter four, which kind of builds on these ideas. And we'll be jumping around.

Carter Morgan (17:44)

Yeah. There you go.

Right, Wren.

Nathan Toups (18:04)

Like we're just going to be kind of talking concepts. It's called aristocracy, democracy, and system design. And this is where he really introduces the concept of conceptual integrity. And I loved this because he makes the argument, he really talks about software architecture in that you need to have, you can have a lot of people working on a project, but you need to have as few minds as possible managing the conceptual integrity of your project.

Carter Morgan (18:04)

Yeah, yeah.

Mm-hmm.

Nathan Toups (18:33)

And this idea is that one person needs to be able to hold in their mind the core values of the thing that you're trying to build. If you build by committee or if you kind of throw things around and kind of piecemeal it together, it becomes a big ball of mud, right? It becomes this really nasty, ugly thing. And I think that if you try to use AI tools to replace your conceptual integrity, you're going to fail. Absolutely, you're going to fail. This is just not there. They're not there. It's not what they do.

But if you use conceptual integrity to carve out tasks so that you can build the system, and because he talks about these sort of replaceable parts, is that you should build a system in a way in which you can move team members from one team to another with the minimum amount of disruption. Not that everyone's replaceable, but this idea that you should be able to move from being in a manager role to being an IC and back.

and be able to get bootstrapped, work on a system, kind of hop around. those people should not be in the conceptual integrity role. They're in the tactical implementation role. They should be able to evolve the design and push back and talk to the person responsible for conceptual integrity. And again, using agents or using agentic stuff where you're doing subagents and all this other stuff, you can see where you're like, hey, implement this security protocol.

using these REST API patterns, you like you carve these things out, you're providing the conceptual integrity. All systems must use this pattern. And they can go off and not know anything about the rest of the system and go and do its own little thing. And then you come back and say, is this consistent? Is this a consistent implementation of my conceptual, you know, does it maintain conceptual integrity? And that's how he was advocating working with big teams at IBM. And I do think that like,

Carter Morgan (20:16)

Right.

Nathan Toups (20:29)

that's quite applicable. we, our role has kind of shifted into being like the maintainer of conceptual integrity. And again, I can't replace that. So like there is a constraint here, which is you can't just be like, hey, you know, unless you're doing something like microservices, or, you know, we get into these other conversations of Conway's law of how do I encapsulate complexity and modularize things that I don't rely on other parts.

Carter Morgan (20:36)

Right.

Nathan Toups (20:56)

Yeah, I was just, curious about your thoughts on like, am I just being a weird obsessive over conceptual integrity or did it hit you similar way?

Carter Morgan (21:06)

No, no, although

you did mention microservices and it reminded me that I got into a disagreement at work where someone was, someone argued that you can build microservices where they all share the same database. I'm like, well, you can, yeah, I know, right? Right. I was like, I'm like, well, you can't, can build anything. I'm like, but you're doing microservices wrong. And I'm just like, we, we had an issue with our database where the database went down and it took out the site for just a little bit. And I was a little like, see,

In a microservices framework, if you're all joined at the database and like, I'm just trying to imagine debugging that failure. Cause like what it wound up being is like we had one particularly awful query that like, it just got called too much, it would bring down the whole database. And like, I'm just trying to imagine that like, but you actually share a database amongst like six different teams and like the database is down and you're just like, all right, figure out who screwed this up. Right. I'm like, no microservices, like they all have their own database. They talk to each other via API.

no conceptual integrity. I've been thinking about this a lot because I think a lot about what Carl Brown told us, right? Which is this idea that like, we've constantly been moving up the abstraction stack and like, it's easy to look at large language models and think, geez, when I started my career 10 years ago, these can knock out tasks that I was assigned as a junior engineer. And then Carl says like, yeah, but when you were, you started your career 10 years ago, like you had tasks that Google and sack overflow because it just solved immediately.

that I was dealing with as a junior engineer in the 90s, right? And then I imagined similarly like, you know, Carl Brown was working on stuff in the 90s as a junior engineer that, you know, would have taken, or I guess the stuff Carl Brown could do in the 90s with, you know, like object-oriented programming and even just more reference material, would have taken a junior engineer a week in the 1970s, right? And so I do think this concept of conceptual integrity is important.

I do think kind of like it's all a matter of scale, right? Like I I'm fond of the Amazonian like thinking of one-way door and two-way doors, right? Which is this idea that like when you're making a decision you got to think about is this You know a one-way door like we can't reverse it or is it a two-way door where we could you know? Go back and change it if we had to write and those one-way door decisions where you have to spend a lot of time thinking about

But they also point out that like, it's not a binary, like all decisions in life are a one-way door or a two-way door. Like what's a one-way door decision for an individual might not be for a team. And what's a one-way door decision for a team might not be for a group or a company or whatever. Right? And so I think kind of it's similar with like conceptual integrity, right? Which is like, you talk about like, okay, so one person has to be responsible for

the design of the system, like, well, what does that mean? At what scale are we talking about? Because like, there's conceptual integrity at like a service level. No, there's conceptual integrity at an org level, at a company level, right? There's conceptual integrity at a file level. And so you worry that someone who just gets obsessed with this idea of conceptual integrity, doesn't, could maybe take it too far and be like, the rule is that every service must have one architect.

And that architect is in charge of determining, making all the decisions for the service. then everyone else who just works on it are just the implementers of said decision. Because I think in an LLM world, like that's our job now is conceptual integrity. And I think that occurs at even a feature level and not just a service level. So yeah.

Nathan Toups (24:49)

Interesting.

I've kind of gone full circle in this in that, well, we're in the midst of something right now where I'm working on a pretty big project. We have a very heavy infrastructure piece. We're like regulated industry. We're putting in a big data lake. We have to think a lot upfront about PII and movement from one place to the other. need to be responsive. And

I will tell you that I've been so lucky that the CTO on this project has been the owner of this conceptual integrity, where I'll, in my isolation, think that I've come up with a reasonable solution. And we are very design document heavy. So we will actually write a design document before we do implementation. And it seems like we move a little slower, but in some ways, it actually allows us to move faster because we make fewer mistakes. recently,

I just had the abstraction slightly off. I was doing something, there's like multiple layers. And I was like, well, I'll just do it here because it's convenient and it like makes total sense and low cognitive load. That was my reasoning. And he was like, yeah, but there's this security model where this part needs, really needs to happen here. And he like pushed back and made this argument. And I was like, okay, this would have violated the conceptual integrity. And we probably wouldn't even have noticed it for six months, right? And then somebody would have been making some change and go, wait a second.

Carter Morgan (25:45)

Yeah.

Right.

Hmm.

Nathan Toups (26:11)

privileges are really escalated here. That's not the way it is anywhere else in the system. It's super strange, right? And so I really appreciate that fact that like, and it's a tiny implementation, has nothing to do with the business logic, has mostly to do with how we deploy and who gets access to certain resources. And so I think maybe you have to be careful, right? I don't want that to be the case for every little decision on a data pipeline or something. I really need those guardrails just kind of thought of.

at a high level, and then I should just go to town inside. I don't need to be coordinating with an architect every time I need to do a little this or that. But I do appreciate that maybe in our efforts to be scrappy, we might mangle things up, and it takes a second to just take a breath and go, am I being consistent? Is this the idea of how all systems should behave?

Carter Morgan (27:08)

It's so challenging and as you get more senior, just knowing like, you have to know what to care about. And you have to know like, hey, we should pause here and really debate the abstractions versus like, you know, this isn't as important and it's okay. And part of it is having good foundations, good abstractions, but it's also, mean, that's true with LLMs, right? It's like, they're very good mimics. And so if you have the right abstraction, the right patterns in place, odds are,

Nathan Toups (27:20)

Great.

Carter Morgan (27:37)

the code they generate will be more or less acceptable, as you're working. But you know what we had this, like I'm talking about this, this terrible database query we had, like, cause we're in the middle of this migration. And so what we're doing is like, we have these various defined contracts for the data that needs to be kind of spat out at the end. And we have our data modeled in our relational database and we have the mapping stored in code of how our old Mongo data maps to our new Postgres data. And so.

LLMs are able to, they're able to synthesize that pretty effectively and write these SQL queries and be like, great, okay, here's all the data you need for that contract. And it turns out the query it generated was just so bad that if you ran it enough, it could take down the entire database. And we were just saying, like looking at the query after the fact, we saying like a human never would have written this query. Like a human would have gotten halfway through this and been like, this is insane.

Like there's gotta be a simpler way of doing this. And so that's not necessarily a conceptual integrity problem, but it is a velocity problem where I think there are, we are already discovering and we are going to discover that there was a lot of the design process that was happening in kind of an ad hoc manner just by nature of actually typing code, taking it time.

Nathan Toups (29:02)

Great.

Carter Morgan (29:03)

Right? And I think that is where lot of conceptual integrity emerges because you start to feel that pain. You feel the pain of operating in a system that does not have conceptual integrity, that doesn't make any sense. And you start going, okay, know, is a, we need to rethink how we're doing this, right? You feel that pain less with LLMs, but I don't think, and there's like the argument,

Some people who are like really off and what I think it was like LLM, Lala land, right? Say like, well, it doesn't matter. It doesn't matter anymore. You shouldn't even read the code, right? Like code today is the equivalent of like assembly language of yesterday, right? Where it's just an abstraction we don't even care about. And I just, I disagree. One, because, you know, assembly it's compiled, you know, deterministically, LLMs are non-deterministic.

And I don't know, I think that conceptual integrity piece still really matters. think they'll just, yeah, like you'll just kind of build a mountain of slop that'll all kind of collapse in on itself at some point. I mean, I've seen human coded code bases that look just like that. And I think this idea that like, you will build that mountain of slop faster because you personally aren't feeling the pain, but eventually you will get to the point where you feel the pain in a very functional way.

Nathan Toups (30:10)

Yeah.

Well, and this gets into this. There's this we're skipping around, but no silver bullet, which is not in the original version. This is exactly that to me. So there's this idea that very, very rarely are there actual paradigm shifts. Silver bullet being, oh, well, one day when this thing. Let me see if I can actually find that. That, yeah, so there's like, guess he.

Carter Morgan (30:32)

because you can't add to the system.

Nathan Toups (31:01)

He gets into these concepts of essential complexity and accidental complexity. So essential complexity is the inherent to the problem domain. And then accidental complexity is all the stuff like, the language you're using, the tools, and the processes, and that no single innovation will just yield 10x productivity. And we're kind of getting into this hype machine where there are people who claim 10x and 100x productivity gains.

Carter Morgan (31:16)

Right.

Yes.

Nathan Toups (31:30)

And I do think that LLMs have made a huge change in like, instance, how quickly, Carl Brand talks about this, how quickly you can generate a set of code, right, upon a certain criteria. But that doesn't change the essential complexity, which is the real business problem. Like when we're building startups, we think we know what the customer wants, but we don't actually know what they want until they actually get it in their hands. And then they give us, the market tells us,

This is actually useful, right? It doesn't like the accidental complexity of I can actually iterate on ideas faster to get them to market. That does get changed by LLMs, but it does not get changed is the real business problem I'm solving in the marketplace. And if everyone can solve problems this fast, there's all of this competition on the attention of the customer.

Carter Morgan (32:27)

Right.

Nathan Toups (32:28)

on using products that are useful to them. And there's paradigm shifts that are going on all the time that you're like, do I even need a service? Could I just build this thing myself? Like all these, kind of things change and none of that changes the essence of the essential complexity. And I think that's the big piece that's here is that like, yes, I've seen all of these kinds of pieces here, but I haven't seen it. And again, up to this point, I haven't seen someone who

is using these tools and I'm like, you're living in another universe. Like I'm a caveman over here using stone tools, banging on something and you're flying around in a spaceship. Like I've not seen that.

Carter Morgan (33:04)

Yes.

Nathan Toups (33:10)

I've definitely seen really clever workflows where they've built a lot of tooling around using these chaos machines, these large language models in a really interesting way so that you can do, you can minimize the amount of like

BS work that you're doing and focus on the sort high value work. But then I've also seen those very same people slip into this sort of like AI psychosis thing where all of a sudden they're getting higher on their own supply. And I'm like, okay, well. And so, yeah, it's.

Carter Morgan (33:43)

Yeah, yeah.

Well, that

that's yeah. Like I don't know. We talk about like, okay, again, what does the future look like? Like I, I think there's some great things that are happening. Like, you know, I think it's great that marketing can update the copy on the website now. Like did you ever get that ticket and we're just jazz about your day ahead of like, boy, boy, I get to update the landing page. Right. I think anything these kind of little bug fixes I think are fantastic. I think people have these really grand ambitions. Like I hear a lot of kind of like.

Well, we're just going to craft such fine requirements, right? Such perfectly scoped and, and decided upon requirements that then we'll just submit as like a linear ticket and it'll all just execute on its own. Right. And I'm just a little like, didn't we try that? Isn't that waterfall? Right. This idea that this is just waterfall and miniature, right? This idea that like, we'll just be able to see the end from the beginning. just like,

Nathan Toups (34:42)

Right.

Carter Morgan (34:46)

I think that there is, and I've preached this to the team. I'm just like, in a world where velocity is faster, alignment is a lot more important. And I think it makes sense to really sit down and think about the problems we're trying to solve. And this is another thing, like he actually doesn't, he recants this idea like of, what is it? Design it twice, right?

Nathan Toups (35:09)

Yeah, so this is kind of cool. He calls it, yeah, let's see, plan to throw one away. Yeah, chapter 11. Well, and the funny thing is he makes this case for doing this in the first place. Like, so in the original book, he says, hey, first version teaches you what to build, you're gonna throw it away. So you need to plan for this, like just plan to throw this thing away. And then he comes back in chapter 19, so 20 years later, and he's like, yeah, I was wrong.

Carter Morgan (35:14)

Or throw, throw away. I plan to throw one away. Yeah.

Nathan Toups (35:39)

This was really a framing for when you had a waterfall, and it was super expensive to get the design messed up. since all these downstream dependencies rely on you, and everybody has to build off of this, and that really, we now have modular design systems so we can build a basic version and iterate. We'll have a complete end-to-end thing, very Agile sounding, actually, even though it predates Agile.

And he's like, yeah, the modular object-oriented programming world had already started to take off by 95. But I actually think he was wrong about being wrong. It's so cheap to generate a throwaway prototype. And not only that, I can generate 100 prototypes. And I do this all the time with Claude. I'll be like, I have a pretty good idea of what I want to do. And I'll maybe give Claude two or three

design approaches that would be good, but I ask it to give me five, right? I'll just do something like that. And then let me pick through. Let me pick through the five that are there. And I kind of do the design it twice idea from Osterhout, from philosophy of software design. And I find it very useful. I actually find it enlightening. It doesn't take that long, because I don't have to sit there and do it. I can look at kind of like a list, mean, a set of things and ask it to give me good reasoning for it and things like this.

Yeah, what about you? Like, what do you What's your pattern with throwing away stuff? And where do you land on this?

Carter Morgan (37:10)

Yeah, I'm not as deliberate about like, okay, let me consider all the different options. I have gotten more deliberate about throwing things away. I mean, I had this, you know, just working on a feature and you know, my first attempt at it with LLMs, like it worked, but then the more I looked at it, I was like, I don't know. don't know. You know, like I think we should be doing it this way instead. And you know, I'm kind of lazy sometimes. And so I think.

Nathan Toups (37:16)

Hmm.

Carter Morgan (37:37)

Previously, I would have been like, already built it. I'm not going to rebuild this thing. But instead, you know, like when it only takes 20 minutes to rebuild it, it was, uh, it worked really well, but that's, you know, I've just, and I've been telling this to the team, like we're not quite at this point yet, but again, there's a lot of grand ambitions about this idea that you can just kind of submit a ticket and then linear will pick it up and it's on his agent or you submit a ticket to linear, we'll pick it up from linear and they will.

write all the code and submit a PR. And I think there is a lot where that will work, but I also, you know, anything that's like a bug, I think that's great. But I was just telling the team, I'm like, there's something about when something like, it's kind of, it's like hardwired into us. Like I remember having this discussion at a job pre-AI where we were having trouble with some of our mid-level engineers were submitting pull requests and we were looking at the pull requests and we were just like, this is wrong.

This is not the way you should have designed this. But we kind of said like, yeah, but like that's on us, right? If it got to code review, you can't let something get to code review and be like, it'd be like you had the approach wrong the entire time, right? At that point, they've already done the work and written it and like, maybe we should just merge it in. And it's kind of like, like hardwired into us at this point, this thought that like,

once something's reached code review, it's a signal that meaningful amount of time and effort has been expended to get it to this point. And so treat it with that level of concern. But that's gone now, right? Just because something winds up in code review doesn't mean it took any time to do it. And so I'm just saying, especially with things that are autonomously generated by an AI agent with no human review, we need to be really aggressive about saying this is wrong, this is bad.

Nathan Toups (39:17)

Right.

Carter Morgan (39:28)

you shouldn't do it this way. I think that's actually an interesting little pattern with lots of modes of like human communication and creation, which is like, it used to be that if someone took the time to write something that was meaningful signal that they thought what they had written was important. And you could just know by reading anything that the fact someone took the time to write it, again, there was signal conveyed there. It's not true anymore.

Nathan Toups (39:51)

Great.

Well, Brooks

talked about this too. You can see this sort of in a... It's so fascinating. Documentation, was a big advocate for writing documentation and having it as a first-class citizen. They would type these things on typewriters, right? So there would be like a 300-page manual, and then they would annotate edits. But he said it was hard to kind of review, so they'd have to retype the 300-page document every like six months.

But it took so much effort that you really put a lot of time and energy to making sure that you have this cohesive piece. The floor of getting something usable was high. And I think that the deliberateness that you had to give. And of course, then these manuals these complex systems, each one of them was doing 300 pages or whatever for their section of it. And they'd be 10,000 page documents and things. And so they integrated Microfiche.

And of course, know, microfiche, did you ever, I mean, I'm older than you. So, okay. Microfiche, you may be seeing these in old movies, right? This viewing screen and they miniaturized all these documents onto this physical media and you would put it under basically like a microscope and you would put it under there and you could read it on the screen. And, know, old movies, I guess they would show like an investigative journalist looking up an old newspaper is put on microfiche or something. But this was like in university, even when I was at university,

Carter Morgan (40:59)

Yeah.

Bye bye.

Nathan Toups (41:24)

in early 2000s, it was considered incredibly dated, but there were certain resources you could only get from the archives in Microfiche. You had to go down in the basement and ask for this set of Microfiche and go in there. Very interesting and weird, but this was a productivity game for them because they're like, instead of having to pass around these 10,000-page documents, we can just hand out these Microfiche and they can find what they need. And of course, now we have like

word processors, right? We're just passing documents around and it's a completely different world. And of course, now we have large language models that generate a considerable amount of documentation. I mean, we have a decent number of skills, again, at this big project that I'm working on. We have a decent number of skills of just these little agents that all they're doing is anytime I'm making a change is they're making sure that I'm consistent. So like I'll write some code.

Carter Morgan (42:17)

Right, right.

Nathan Toups (42:18)

Is it in alignment with my SDD? And then is it also meet the rules and criteria that I have? And does it pass the linter? All these little CI tools that are local to my machine. And a lot of it is just to make sure that we're consistent. That am I actually building it in the shape that it's supposed to be? Do I need to modify the documentation? Do these things go along?

And it's funny, it's like, we're building all this stuff and I'm feeling very modern in a lot of ways. And I'm like, no, this is exactly what Brooks was dealing with in 1975.

Carter Morgan (42:52)

Right, Yeah.

Again, I just keep thinking about this idea that like...

Yeah, it's interesting. I mentioned on the podcast before, but this whole idea of like Chesterton's fence, right? Which is that you come across in the middle of a field, you see just a segment of a fence. It can't be blocking anything in because it's just a segment of the fence. And so you go to the, you know, someone and say, I'm going to remove this fence. And someone says, well, what's the fence for? And you say, nothing. I don't know. Like it's not doing anything. And he says, well, you cannot remove the fence until you know.

Nathan Toups (43:09)

Mm-hmm.

Carter Morgan (43:31)

what it's for because fences don't just spring up out of nowhere. Fences are, they take effort to be put up. at one point that fence must have been accomplishing something. And so once you can tell me what it was used for, then we can remove it if we deem it no longer useful. And I think there's a lot we're going to see with the whole software development life cycle that is very much that way. There's a lot of stuff that was kind of just baked in by the nature of how long it took.

that wasn't, you know, I, when we talk about like essential complexity versus accidental complexity, right? There may be things we were labeling as accidental complexity that are a little more on the essential complexity side of the equation. I don't know.

Nathan Toups (44:20)

And that's that sort

of getting into some of the Neil Ford kind of concepts from ThoughtWorks. This is that co-nascence, right? There's these couplings. There's types of couplings, of coupling of process. There's co-nascence of these other pieces where you didn't even realize the reason the system worked is because you actually accidentally had some delays built in because the process had these delays. And if you refactor it and you remove them, you now get a race condition because you know,

Carter Morgan (44:29)

Right.

Nathan Toups (44:48)

Action item A and action item D just happen to have B and C in between them, making it so that race conditions weren't possible. And then you come up with some cool new fancy async pattern and you break everything. And again, this is like a Chester Tins Fence thing. You're like, on its surface, async things moving faster is better. And it probably is from like a compute resources standpoint. But now you've broken a process with a set of assumptions that you didn't understand.

Carter Morgan (45:17)

Yeah, the more I think about it though, cause I, I've just been so interested in like, okay, what are the impacts on the labor market? And I'm particularly with like a mythical man month idea of like these kinds of communication points. like what happens in like, I don't know, I'll be bold here and say that I, I do, I do continue to feel optimistic for software engineering as a field as a whole. I think that humanity's demand for software.

is not even close to being met. And I think that there are, there's still so much software to build. And I also think that there are companies that previously would have failed because they could not build at the pace necessary to survive that will instead be able to build at that pace and will survive and grow into bigger, cooler companies that employ more software engineers.

And even at a micro level, this is something Carl Brown said, like just this whole idea that like finding product market fit is expensive. And there have previously been lots of ideas that were just not able to find product market fit because of how expensive it was. We'll be able to find that product market fit faster. And those will grow into companies that will employ more software engineers. So as a whole, I believe in that. I do think there are lots of large companies and especially a lot of like kind of

and fang adjacent companies that will shrink. And it would not surprise me to see a company like Microsoft shrink their head count year over year for the next five to 10 years.

Nathan Toups (46:52)

Yeah. Well,

we saw this. We saw this happen. I remember when the IBM had the big retraction in the early 2000s and because they kind of were irrelevant in a lot of ways. Like, so there's a, there's a few things that came up here. Number one, in his sort of 20 year reflection, he talks about how so much of this early book in the seventies was about sort of like the transition from mainframe to the mini computer. and that he's now he's like, for this laptop that

Carter Morgan (47:00)

Mm-hmm.

Nathan Toups (47:22)

is worth $5,000 in adjusted for inflation, it would have been about $5,000 back in the 70s or whatever, that was more powerful than the most powerful supercomputer. How fast he can compile code, the higher order stuff that's in place, a lot of the ways that he had talked about being very deliberate was almost irrelevant. that he saying, I'm struggling keeping up with the times, I'm struggling understanding all the tools.

And then there's also this like back in the 70s, you had to basically build all the software bespoke, right? You had to build every, all the tooling even has this thing about a person on the team just building these sharp tools to make sure that everybody had this sort of like process tools you needed custom for this project. And now you can use a lot of off the shelf stuff. What's funny is in this, the rise of open source hadn't quite happened yet, because he's lamenting, hey, there's this great commercial off the shelf software, but there's really no modular.

Carter Morgan (48:14)

Right, right.

Nathan Toups (48:20)

pieces that can just be hot swapped on a custom project. And I'm like, solved a problem now. But what's interesting though is that like, so even the concepts that he had in his mind, categorically, we keep shifting. you look back at a book like this and you realize there was never a stable time as a software engineer. You got really, you can get really like fat and comfortable being a Fortran programmer for mainframes in Fin-

Carter Morgan (48:25)

Yeah, yeah, exactly.

Yes.

Nathan Toups (48:49)

in the financial institutions or DOD. And then the whole world moves on and no one cares, right? Some niche does. If you're exceptional at it, you can keep doing it. But everyone started having personal computing and things moved on and commoditization of things. And I think that the stuff that like was hard and not in our minds, not commoditizable, a lot of those little steps in our job of what we thought that we had to do is a commodity now, like really.

Carter Morgan (48:55)

Yeah.

Nathan Toups (49:18)

You know, but if you read a book like this, you go, it wasn't that things were stable and now things are unstable. It's just that like it's unstable in a new and surprising way. And I still think that smart people working on interesting problems and being able to have that conceptual integrity, being able to use the tools available to us and then look how to solve new categorical issues, that hasn't changed. Those things are not.

going to change. You still need a smart person to really understand what's the actual business problem we're trying to solve. Like, I'm, yeah.

Carter Morgan (49:54)

Right, right. But I think there have been

a lot of engineers that don't care about that question.

Nathan Toups (50:01)

Right, well, I'm sorry.

Carter Morgan (50:03)

Yeah, yeah, I was gonna say, but I guess there are a lot of engineers who are like, know, expectations do keep changing. I've said on the podcast before, but I know people complain about, everyone wants a full stack developer these days. I'm just kinda like, yeah. There's something to be said for specialization, right? I have a lot of respect for front-end engineers, right? I know enough front-end to be dangerous, but there's a real science to it and an art.

Nathan Toups (50:05)

Hi.

Carter Morgan (50:31)

And in a lot of ways, think writing good performant front-end code is much more difficult than writing good performant back-end code. And so I think there is something to be said for specialization, but there's also a lot to be said for understanding the development lifecycle, or if not lifecycle, then the whole pipeline of how your software is deployed and how it operates. And if you just say, no, I'm just the front-end guy. I'm like,

I don't know, like I think you need to know how it interacts with the backend and how it all gets deployed. But I think if you went back to like the 90s, very acceptable, be like, all I know how to do is write HTML and CSS. don't know, gray beards out there, correct me if I'm wrong. But like that's, you know.

Nathan Toups (51:17)

Or just

be a straight-up ANSI C programmer. I think that you could... And again, a lot of web functionality was literally writing C or Perl code in your CGI bin, which is the pattern of how you did server response, dynamic response processing. And then, yes, it got rendered in HTML and stuff. that was... I I knew folks that literally were just Perl programmers. And then had a good C foundation, but were Perl programmers, and that was like...

Carter Morgan (51:21)

Exactly. Yeah.

Yeah, yeah.

Nathan Toups (51:46)

You could have an incredible living from that.

Carter Morgan (51:48)

Yeah, you know what, that is something like, we're expected to be like polyglots in languages that like, it does not seem like that was always the case, like back in the 90s or 70s. Like you could just be like, I know C, that's my job. Like I have a C programmer. And you know, I think that that comes with the trade. I've lamented like, there is no language I deeply understand. I wish there was a language where I'm just like, I know all the ins and outs of this. I wonder if I'll ever get to that point, right?

Nathan Toups (52:14)

Right.

I think it's one of those things where like we're in a world now where the biggest constraint is how deep we let our curiosity go on topics. And I definitely think you could make a very good career being a generalist and you could also make a very good career being hyper focused on a well, I'm a big fan of the T shaped engineer. We've talked about this in the past. Jurgis talked about this. The.

Carter Morgan (52:19)

LMS

Yes.

Yes.

Nathan Toups (52:48)

The idea is that I would highly recommend becoming a deep expert in some niche while keeping an eye on all the stuff around you. Know enough React to be dangerous. Know enough about how web stacks function. Know enough about AWS infrastructure so that you can have a conversation with somebody when you go, don't think it's actually supposed to be this way. Not necessarily saying I'm the domain expert, but enough to give a good prompt to Claude, go find some primary research.

Carter Morgan (53:16)

Right,

right.

Nathan Toups (53:17)

and push

back on your DevOps team when you're dragging your feet. This is not the way it is. There's five examples of how this should be better. Here's a prototype I just made in my little sandbox account. I'm not saying to be super obnoxious, but sometimes you need to push back. That's good. That's just good engineering of just not accepting the status quo when your instinct tells you, I've seen enough patterns. And yeah, I don't do

Carter Morgan (53:43)

Right.

Nathan Toups (53:45)

you know, event-driven architecture every day, but like the way that we're doing just doesn't feel right. This doesn't feel like the way it should be. Like, do that, get into that broad scale. But if you're also happen to be the like SQL query optimizer guru and you're like, hey, I know how to get every ounce of performance out of this. That's also super valuable, right?

Carter Morgan (54:07)

Yeah.

Yeah, I mean, but then again, it's it's kind of like the Russian nesting doll of it all right, which is like what your T shape but then there's like even within your niche, you can dive deeper because like if I had to say like, okay, so what what have I what do I kind of naturally gravitate towards? For me, it's it's infrastructure. It's cloud. Like I find that. Yeah.

Nathan Toups (54:28)

Yeah, I've noticed that. was like

pleasantly surprised. I'm like, oh man, you gotta dip your toes in this space.

Carter Morgan (54:32)

Yeah.

So I really like that stuff. but again, it's like, I'm not like super duper knowledgeable about like S3. Right. Like I, but I do feel like my, terms of like, okay, what sets me apart from other engineers, like AWS in particular, like I have a pretty solid understanding of like how all that works and you know, all the pieces work together there and, and Terraform and you know, how to rate up, Terraform in the age of AI is like one of my favorite little developments.

Nathan Toups (54:53)

Mm-hmm.

Carter Morgan (55:02)

Right, like just the, you know.

Nathan Toups (55:03)

Yeah,

these are the kind of things too, or like, there's two sides to this. This is what I would call it sharp tools. So this is like what's in the book. Like we'll bring these things up. He was talking about building this like custom software, but it's so easy now. Here's a good example. I just built this thing called Boktel, which is what I'm calling Boktel, which is the book overflow control command, book overflow control, which is a BOCTL.

Carter Morgan (55:18)

Yeah.

Mm-hmm.

Nathan Toups (55:32)

is a little command line tool that makes it easier for me to update our website. Very simple, very sharp tool, right? No one's, this is not a general purpose tool. It understands, it uses transactions. It lets me update, like for instance, perfect example, we needed to add Mythical Man Month into our episode list. Before I would kind of like click around and be like, okay, I'm gonna add this in and then I'm gonna bump each of the things in the future. And I was like, this is stupid, I shouldn't be doing this. So I made a command line tool that lets me insert an episode.

and bump everything in the schedule back. And it touches a few tables. I also made a skill for it so I could give it like, oh, here's the YouTube link, and here's the other things. And it will generate a Tamil. And it does this thing. And then to do this safely, I also needed to have an audit log because I don't want an agent making a bunch of changes or doing some stuff without it being in the audit log. So I made a little audit log implementation. So anyway, I have this command line tool. And it just helps me solve these little

minutiae problems where if I can get 15 minutes, 20 minutes back each week on a podcast that is free, then that's great. And it gave me the ability to be like, this is agentic command line tool building. That's kind of fun. I haven't used TypeScript command line tool frameworks in any real sense. So this is an opportunity for me to learn and get deeper in this one area and get appreciation.

and write playwright scripts and do end end testing and do these other things. so like, I think this is where like, if you have curiosity, for instance, you have this profanity propensity for AWS, but you don't know as much about S3 as you think maybe you could. When you get the opportunity to like level up, just letting yourself dive in deep, like solve some fundamental problem. And that's to me is like the most fun way of learning because like you'll become the domain expert. You may not be the best

Carter Morgan (57:21)

yeah, yeah.

Nathan Toups (57:28)

S3 person on the planet, you'll become the best, you'll become the most knowledgeable S3 person at your company. And you'll be like, hey, we've got versioning built in. You can't accidentally delete things. We do life cycle management. know, you do all the stuff that you're going to want with S3. It's locked down so that only, you know, only response to requests within my infrastructure because it's got PII, like all the things that you'll learn. And then you write good docs and you don't touch it for six months. And then you're like, man, Carter, how do we do this S3 thing?

Carter Morgan (57:34)

Right, right.

You know, and I agree with this idea that like we're just kind of limited by our curiosity, especially at this stage. And I really like that because like I've never been a guy. I know there are some people out there, you maniacs who just get like lots of really deep satisfaction out of just like reading technical documentation. And like that was your skill, your kind of superpower. And I think one, there's still value in that. But two, it is easier with LLMs.

just to be like, hey, like I just need like the, decent understanding of this concept, give it back to me. Right. And so, um, I get a lot of leverage out of that. had that when I was debugging and like database performance issues the other day, we use RDS on AWS and, uh, and I was, I was like, how do I get more insight into this? I was like, Oh, like performance insights, turn on performance insights. And so I did. And then, you know, I'm just like looking at it and like it, it's showing me these queries by like AAS. like, what is AA?

It's like that what's average active session. And so basically what performance insights is doing is it's taking a snapshot every minute of like what your what your CPU what your database is up to mostly CPU intensive at least for us, right? And so you can kind of look and and say like, okay, in this 30 minute window, the average active session over this one minute says that this query was consuming 0.12 CPU on average.

Nathan Toups (59:07)

Mm-hmm.

Carter Morgan (59:22)

And like, it was really fascinating just to learn about that. And so I find kind of this awful query that stands out and then like, you know, Claude helps me run the explain, analyze plan on it. And they even pointed me to this cool website where you can paste in that plan. It just gives you like a better visual representation. So like, it showed me like the a hundred nodes as part of this query and like immediately I can identify like the query is taking like 450 milliseconds. And like, there are four nodes out of those 100 that are each taking about a hundred milliseconds each and like they're.

Nathan Toups (59:50)

Wow.

Carter Morgan (59:51)

There it is, that's the problem, right? And so that was really fun and fulfilling to just kind of dive deep with the ability to get information back very, very quickly from Claude. It was also a day where I felt like my job is more secure than I worry about sometimes. Claude wrote this awful query and I spent all day figuring out why it was bad and, you know, kind of stitching all those pieces of context together.

Yeah, I don't know. terms of it, I did find it interesting though. This is one of my hot takes, this idea of like the no silver bullet, because like, again, he says that like, there were finding tools that kind of were just that accidental complexity, but that essential complexity is still really hard. I said, that's one of my hot takes that LLMs are probably the closest thing we've gotten to the silver bullet, but I actually don't think that's necessarily true. I think what's happening is...

LLMs are really just eating more of that accidental complexity. But I think the problem is that there are some engineers who make their living purely in that accidental complexity space. Right? And...

Nathan Toups (1:00:51)

Yes. Yes.

As someone

who's in dev, who background is in DevOps, I've seen this time and time again. They become the guru and everyone kind of resents them, right? I think everyone's been in that environment where you're like, yeah, we gotta give that to Frank and you know, he's gonna do his magic and get back to us. And you're like, that's not how that should be. It should, a good DevOps team should be like, man, Frank's a wizard and he's gonna show us how to do this and we'll be able to run with it on our own, right? That's a good Frank.

Carter Morgan (1:01:16)

Yeah.

Yeah.

Nathan Toups (1:01:34)

And that's a Frank

Carter Morgan (1:01:35)

Yeah.

Nathan Toups (1:01:35)

that's probably also used LLMs to be better at his job too.

Carter Morgan (1:01:39)

Right, and again, I thought what you were saying at the beginning, like, I haven't really seen anyone with LLM workflows that's just like, again, I'm a caveman, they're in the space age, right? But I think a lot of that is because like, I have tried to not make my living in accidental complexity, right? Like, I've always thought of myself as like a problem solver, we're using technology to solve problems, and all of that work is still very,

Difficult right it's kind of rare that like I just say Claude. What should we do here? And then Claude gives me the solution I'm like, my gosh, that was way better than anything I could have come up with and honestly The only times it feels that way are when I'm asking about things. I don't know about right Exactly, right, Yeah, yeah And so I think and I think that's why

Nathan Toups (1:02:23)

Well, yeah, and that's the gel, that's the gel man problem, right? That's the, which we talk about with Casalute actually. Yeah.

Carter Morgan (1:02:37)

When I think about like why I think big companies will kind of continue to shrink is because they have hired a lot of manpower to deal with just the accidental complexity, right? And that essential complexity also remains. And there's enough of that essential complexity that I think that there's still a very bright future ahead for this industry. But I think there are a lot of engineers who have just prided themselves on like, they don't think of this that way, but like they just want to operate in that accidental complexity. like we're the whole, again, this is not new.

In software engineering, all of software engineering has just been pushing us more and more towards the essential complexity. LMs are just another phase in that, but you got to get in there and be working at that essential complexity.

Nathan Toups (1:03:17)

When things are-

One of the things I love is actually, it's been really kind of empowering to see is I'm working with a company that they do a lot of stuff in Excel. We're introducing these new ideas with data warehousing and in a data lake. We're using Databricks and we've now gotten to these aha moments where we've got these guys in the finance and business operations team who've been really kind of apprehensive because they are productive in their minds in Excel, but they have hit some

fuzzy areas, especially if it starts being bigger data. You know, you get over 100,000 rows or something in Excel and it's going to start falling over sideways. And we're dealing with a couple million rows of some of our data sets, small for big data, but way bigger than Excel can handle. And we finally got these analytics lake house sort of in place. And we've been doing some onboarding and training. And what's been cool is that there's a tool in Databricks now called Genie, and it's a chat.

It's a chat bot with agentic stuff that it can do that is a domain expert in Databricks. Like it can go in and analyze all of the data in your catalog. It can do all these things. So you can ask it like, help me write a dashboard using these data sets. I'm trying to get these insights. And it does like a pretty good job of doing prototype level work. And it's completely changed my conversations with the team because all of sudden they don't care that they're not in Excel anymore because they've got Genie.

building dashboards with real data on much bigger questions. They can ask bigger questions than they could ask in Excel. And they don't have to write SQL queries on their own. This thing's writing SQL queries and helping them. And they can give it feedback and they're iterating. And then we'll come to a meeting and they'll show me some really cool looking thing that's not quite right. It's like mostly there, but they're like, this data is doing this one weird thing. And I'm like, OK, actually you need this extra thing. Or hey, maybe we can make a new

Carter Morgan (1:04:47)

Yeah.

Nathan Toups (1:05:16)

denormalized table that has these things in the right spots so your query is not complex, or whatever kind of data-y thing that we're doing. I love what this has unlocked. I guess my point here is that I'm a big advocate for, and I don't see this as replacing our data engineers or anything like this. It's like, can I get the business to come in and be inspired to engage with the data engineers in a more valuable way? Instead of them spending 80 % of their time being like,

Carter Morgan (1:05:38)

Right.

Nathan Toups (1:05:43)

I think I understood what he said in that meeting about the report that he wants. And the guy doesn't really get what he wants in the report, but it's like good enough. And so no one's really happy and they kind of move on. They can kind of get you 90 % there with a large language model. And you can go in and be like, I can make this awesome. This is where it might be my time to shine. The last 10 % is what I'm here for. That seems like a very positive future, in my opinion. And it's high value work.

Carter Morgan (1:05:51)

Right, right.

Right, right.

I agree.

I mean, I'm just looking at some of your hot takes here, like, I mean, do you think, you wrote here, AI turned mostly done into a crisis. On the one hand, you're describing this as very exciting, but maybe it's also a crisis.

Nathan Toups (1:06:25)

Yes. Right. Well, so

I do think that the people who've dialed in their jobs, right, these are quiet quitters, right? The folks who are like kind of in a crappy job, kind of don't really love stuff. I do think there is a crisis here where like if you're under a lot of time constraints and pressure, you really can try to like vibe out something and it's like mostly done. And then I think after like six or seven Dev cycles, you've got this huge code base. No one understands it.

It's super hard to change. It's like really, I've seen this several times now where I've come in as a consultant on a project with these like vibe coded data, these vibe coded systems. And I'm just like, what has happened here? Like there's some huge convoluted cloud file. There's a bunch of things that are like not implemented the way they should be. Because again, maybe the infrastructure component or the network security stuff is not in their wheelhouse.

and it looks good enough, and it was fine. And then they try to make some sort of bigger architectural change. And so I do think that while I find these tools exciting, and I even am fine with mostly done, I'm really clear with the person doing the prototype. This is a prototype. This is a way for you to share ideas. We're not going to rely on this as a business. This is not the way we're doing things in the future. This is a way for us to compress conversations down so that when we meet,

Carter Morgan (1:07:40)

Yeah.

Nathan Toups (1:07:52)

You can put this in our work queue. We have a really amazing working prototype of the ideas. And then we'll use our sort of conceptual integrity to make sure that this is like, if the business is going to rely on this dashboard, here's all the things that have to happen. And so, yeah. I think a lot of people skip this. They want an easy button. They want to say, the prototype looks really good. It must be good enough. And I think that's actually the worst thing. That's the crisis.

Carter Morgan (1:08:22)

Yeah, right, Yeah. And I think about that a lot too, which is like, it is dangerous that like, now you can get kind like a working prototype out more quickly. And then you can just be like, yeah, like this is good enough, right? And there was a little like, you know, if you could kind of control, if you were the only one who could build the thing, you'd be like, no, it's not good enough. Wait, be patient.

Nathan Toups (1:08:22)

me.

And I will say, I'm not so, actually, I think a guy removed, I got put in some AI group of virtual CTOs and he removed me, because I think I insulted him on LinkedIn. I'm not 100 % sure. But I basically said something about, the only responsible way of running OpenClaw is to not run it, or something silly, pithy like this. But I don't think you always have to do responsible things. guess you might want to go bungee jumping one day.

I'm not saying that just because the bungee cord could break and you will die immediately, you should never bungee jump. You have decided you're going to do something reckless or irresponsible. That's OK. I'm not going to stop you from, know, I grew up skateboarding. Skateboarding is reckless. There's all kinds of things that you can do that are exciting and they're fun. And it's OK. You can do those things. I think the same thing with throwaway code. It's kind of like...

I built a really makeshift surfboard rack in our backyard. It is phenomenal for what I did. It's a throwaway, sort of like I built it out of very cheap materials. It does a good job for what it needs to do. If I wanted to go into business as someone making surfboard racks, I would be embarrassed. Like that's not a commercial grade surfboard rack. You know, I'd be like, man, I built a surfboard rack. I should start a surfboard rack business. You should come buy it from me. No, that's like not acceptable. Like I don't have the tooling in place.

Carter Morgan (1:10:07)

Yeah, right.

Nathan Toups (1:10:18)

the materials, the quality controls, all the things that you need for a professional business around this. And to me, that's the difference between like prototype code. It's like the good enough thing. Some things are fine with good enough. It's good enough, I can move on, do this other thing. But I don't know, I think a lot of folks are letting the commoditization sort of replace thinking. And I think that it's reckless, I guess.

Carter Morgan (1:10:46)

Yeah, well, you have some other interesting stuff here I want to get to.

Nathan Toups (1:10:48)

Yeah, yeah, yeah.

Let me see. think, okay, so you've probably heard me talk about this stuff from time to time and the most interesting things in computer science happened before 1980. I actually like, that's a hill I'll die on. So one of the things I love about Go and then people don't, a lot of people criticize about Go is that it like forgot the last 30 years of computer science. And that was actually on purpose. Like Ken Thompson and Rob Pike went back and said, hey,

Carter Morgan (1:11:04)

Yeah.

Nathan Toups (1:11:17)

if I could do things over, here's the concepts I'd want in my language and here's the concepts I won't. So, know, union types and advanced type theory stuff and things that are just really cool computer sciencey stuff, and I'm not saying that those are bad. I think that those are actually really cool and great. They left it out intentionally because they wanted a conceptually simple language. They wanted one that somebody straight out of college, on a team, large scale, could write productive code that was correct and didn't have some two-year learning curve.

to learn how to write the language. And a lot of what they went back to is like old ideas of what object-oriented programming was, or old ideas of how concurrency models would work and these other things. And you also look at things like hashing algorithms, you look at like the foundations of cryptography, all these things kind of like emerged, I don't know, before the 1980s. And I think that the kind of people that got into computer science,

loved it so much that even though it was like a weird industry for weirdos, right? Like there's this really strange, it was not this glamorous thing that it is now where people think about big salaries and working at big tech companies. It's like you kind of had to be obsessed with mathematically proving correctness and building complex systems and really kind of like using your imagination in some weird ways that I think that we got a caliber thinker that just

isn't around now. Like, I don't know of the great, know, there's like, could there be a Dykstra now? I don't know. Like, I don't know of the modern Dykstra. I don't know of the modern Liskov or Merkel, you know, all these people that have like fundamentally changed how we think about algorithms and all this other stuff. And yeah.

Carter Morgan (1:12:51)

Right, right.

We talked about that with Brian Kernahan, right? Which is

like, do you think that can, that's still possible, right? Like that a couple people can have ideas that kind of changed the world, least in terms of software engineering. He said he thought so he pointed out to the transformer architecture and saying like that, the attention is all you need. It was only written by a couple people.

Nathan Toups (1:13:23)

Yeah, you're right. I mean, I don't mean to say that it's not possible. We do have, but I think that every once in there's a catalyst for a new type of thinking and they all kind of feed off each other. And there was something really interesting happening between like 1950 and 1975, 1950, 1980, where computer science was so small enough in the people who were having this disproportionate impact were deep thinkers.

And we had, had space to like sit there and just like pontificate and think and be very deliberate with like how they're doing stuff. And I think then when it became commercially viable, the urgency of just like getting commercially viable stuff is like a back pressure on being like, but is this the most efficient distributed algorithm that could be generalized for all types of just, you know, like that, type of thinking, like, yes, there are still PhDs doing cool research.

Carter Morgan (1:14:11)

Right. Right.

Nathan Toups (1:14:18)

But I don't know, there was like, there was something to that time period where anytime I go back and look at it, I'm like, man, like Tony Hoare's white paper on concurrency is like that turned into air laying and in the go concurrency model. You just read that paper and there's like this clarity of thought to how he makes this argument that I'm like, I don't know if I, I don't know if my brain thinks this way. I don't know if I could sit there and make an argument the way that

These are the way that Mythical Man Month, it's like beautifully written. is even though, again, some of it's not applicable and it's like talking about mainframes and waterfalls. It's just like, I'm reading the words of an intelligent person who's deeply thought about this topic and I'm really excited to see this.

Carter Morgan (1:15:02)

Yeah.

Well, I'm going to steal this hot take of yours. You say conceptual integrity isn't about discipline, it's about taste, which I agree with. And I think the question is like, well, how do you develop taste? And my advice to anyone would be like, try as much as you can to be in the room where it happens, right? And make decisions and then see those decisions through, right? I know that's one thing I, I don't regret anything in my career, but there hasn't been a company I've been at for like a really long time.

Nathan Toups (1:15:20)

Yeah.

Carter Morgan (1:15:33)

And I know there's some value in being at a company for a long time and seeing your decisions eventually like bear fruit or bite you. And so I think trying to make those decisions makes a lot of sense. I also, again, shameless self-promotion, right? But like, I think podcasts like Book Overflow really do help you develop taste. I know that I have developed better taste just by reading all of these books. Again, like being at

you know, like, and then that conversation, someone was saying like, well, what if we just had microservices and then we just all added the same database and just kind of immediately being able to go like, that's not what Mark Richard says. That's not what Neil Ford says. And just knowing like, or, know, we had this problem where as we moved to like an event driven architecture and we're using more lambdas. When we were discussing, we were trying to figure out like, should the lambdas write directly to the database? And, some of our junior engineers were like, yeah, you know, that seems the most simple. And I was like,

no, we shouldn't do that. We should have one thing that writes to the database. Like I've seen this pattern go poorly at other places where you have too many writers to the database and it's hard to know who controls it. And so what we decided was we created kind of a whole separate service contract for our backend that is like an internal, instead of the endpoints being prefixed with API, they're prefixed with like internal or something like that. And you can call that if you have the proper authentication. so now basically our lambdas basically just call our backend.

Nathan Toups (1:16:45)

That's cool.

Carter Morgan (1:16:59)

And then when we had like the database go down, like eventually the database got so overwhelmed with the connection that like, just had to like stop it. And so like the website was down. I was just like, shut off the instances, just kill them. Let's let it drain out and then we'll start it. We'll start it again. And then we bumped up our database in the meantime, and both those things solved it. But I turned to our juniors. I'm like, this is why you have one writer, right? Because if you have one place writing, then you can, then we can cut it. We can shut it down and we know that.

Nathan Toups (1:17:22)

Right.

Carter Morgan (1:17:29)

all connections to the database are dead at this point. And so again, trade-offs, blah, blah, right? Like I'm not saying that is the perfect pattern in all scenarios, but for us it worked out well. And I think there is just like, as far as developing taste goes, make decisions, be in the room where those decisions happen. And like, there is a lot to be said for gaining a lot of breadth by widely consuming.

Literature or media from voices that you trust right? We try to help you with that here at book overflow but again just reading kind of like Fred Brooks's work and like you said Nathan just you know it's really cool to read the very intelligent thoughts of a very intelligent man and that will kind of inform your thinking and don't just kind of mindlessly consume anything that comes your way, but Again, I think taste is everything in this world. And so you got to develop taste and that will help you

with conceptual integrity.

Nathan Toups (1:18:29)

Awesome.

Carter Morgan (1:18:32)

Well, as far as what we're gonna do differently in our career, I didn't know what I was gonna say. I put a TBD here. I still have a TBD. I don't know, Nathan, what do you got?

Nathan Toups (1:18:40)

Yeah.

You know, I'm really just gonna spend some time framing things in that conceptual integrity stance of like, can we have ownership of this concept or ownership of the shape of this thing in the fewest minds possible? And how do we divvy up our organization structure or the responsibility so that we can give this like single owner? I already am in this realm, but.

I like this idea of like, instead of pushing back on this rule by committee idea, be like, you know, why you own that? Like, why don't you own that and make sure it reconciles with this bigger idea here. So that's what I'm gonna be playing with.

Carter Morgan (1:19:24)

There we go. you know what? I'll piggyback off that, which is like, I'm going to dig into conceptual integrity too. And in particular, think about like, again, what does conceptual integrity mean at the different levels? And what, yeah, I, my gut says that conceptual integrity has to be different for a junior than a senior. And that we've, kind of exiting the age of like pure implementers that live in that realm of accidental complexity. So.

I can't promise I'm gonna do anything with that, but I do think it's a very interesting concept. I'll think about it. Oh, I'm gonna get points so much in our accountability review, because all I have to do is think about this. As far as who do you recommend the book to, Nathan, what do you say?

Nathan Toups (1:19:58)

Yeah.

This is a classic book. It's easy to recommend to anyone who really appreciates the craft and wants sort of that timeless sage wisdom. That's what I wrote down. Yeah, it is. It's one of those where like, if you want to have a seat at the table and understand where all of the derivative work from this has come from, it's just if you love the craft, if you love computer sciencey stuff, if you love software engineering, do yourself a favor and read this book.

Carter Morgan (1:20:39)

Yeah, I would agree. And I think...

One of the great things, I was actually listening to Ken Burns, the famous documentarian. He was being interviewed by Conan O'Brien, and I love Conan. he was saying one thing that's really great about being a documentarian, and Conan is a big student of history, right? He actually, that was his major at Harvard. And I really like history too. One of the great things about being a student of history is it makes the,

the present less scary, because it's easy if you don't know history to be like, nothing like this has ever happened before, right? And someone, Ken Burns is having a conversation where someone claimed that we were entering a depression or like we were on the verge of depression. says, you know, in the Great Depression, they shot the zoo animals and distributed the meat to the poor, right? He's like, when that happens, we'll talk about whether we're in a depression, right? And so,

As you learn history, there's more where you realize like, know what? We've been through tough times before and you know, we'll make it through like we did back then. And I kind of feel the same way reading something like this where you realize, know what? And then Carl Brown told us, this is not the first time software has changed. It's going to keep changing, right? And the field has continued to exist. And so, you know, I think for anyone who just wants to understand the history of our field better, it is a seminal document right here. So go ahead and listen to it.

Although I will say the audio book was recorded in a weirdly echoey environment. I was like, I don't know what that's about. All right. Well, that's it for this week. Next week, will do learning domain-driven design. It's going to be a two-parter. In June, that's going to be two years of Book Overflow. So we're going to have a special anniversary episode. We've got some interviews lined up that we're very excited about. Again, no promises until those are actually recorded. But also just a little inside baseball.

Nathan Toups (1:22:19)

Yeah.

Two of those guests, I think will be their third appearance or one of the...

Carter Morgan (1:22:43)

daughter of-

No, one is their

second, another's their third. And anyhow, that's a little clue for you listeners, if you can figure. What was I gonna say? yeah, a little inside baseball. My fifth child and first daughter is due June 15th. And so we will go dark as far as discussion episodes. We think with these interviews, we'll just kind of release them on Monday, so you should still get weekly content from us, but.

Nathan Toups (1:22:50)

Okay, yeah, yeah.

Little clue, I gave you a little clue.

Carter Morgan (1:23:16)

Just be aware, listeners. I'll post the Discord and I think YouTube can post images on the channel when she's born. as always, contact us at contact.bookoverflow.io. The website's bookoverflow.io. We're on Twitter at BookOverflowPod. I'm on Twitter at Carter Morgan. And Nathan has worked with his consulting agency, Rojo Roboto. It's at rojoroboto.com with his newsletter at slash newsletter. Thanks, folks. We'll see you next week.

Nathan Toups (1:23:40)

See you.