Programming Parables to Astound your Coworkers - The Tao of Programming by Geoffrey James

Nathan Toups (00:00)

that's a type of programming that I've always appreciated, but I've never done myself. And that attention to detail, and I think there's this sort of like, there's a mix of like eccentric genius that exists in this. And I think that that's what attracted this

Carter Morgan (00:04)

Right.

Nathan Toups (00:13)

era of programmers.

Carter Morgan (00:22)

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

Nathan Toups (00:33)

doing great. everybody.

Carter Morgan (00:35)

Well, as always, make sure to like comment, subscribe wherever you're at, especially everyone on YouTube. If you're on an audio platform, leave a five star review or a written review. And, know, I'll just take a moment to kind of shout out our loyal listeners to pause for right now. And if you haven't actually left a review yet, go ahead and do it. I noticed a lot of podcasts that I'm huge fans of will kind of put that call to action out and I'll be like, Oh geez, I'm a giant fan of this podcast and I've never left a review. So, you know, that really helps the podcast helps boost us in the algorithm. Uh, if you want.

Personal advice or one-on-one coaching, you can always book time with us on Leland. And you can also check out our new episode with Dan Heath, the author of Made to Stick. This was really, really fun. Wasn't it, Nathan?

Nathan Toups (01:13)

He was a blast. Again, he's got his own podcast. He's obviously been in the limelight for a while and he's just rich with knowledge and I think he had a lot of fun reminiscing on the book. He wrote back in 2007. So he said it was fun for him to think about something he hadn't thought about in a while.

Carter Morgan (01:35)

Yeah, he's, he's a delight. Just a note for any of our video ⁓ viewers, Dan Heath, so generous and so kind of come onto the podcast. He did ask that his video not be used. And so you'll just see a copy of the book when he's speaking. ⁓ but I was, this is probably my favorite interview we've ever done. And we've interviewed some really cool people and that's not to, I think there are some clear highlights we've had in the past. We've, we'd love Brian Kernahan having him on twice. ⁓ uncle Bob and John Osterholt, Steven Wolf from Jersey or Oz. We've been really.

privilege to talk with some really great people. I think, and I've been very open about how much I enjoy Made to Stake, how this is a book, my enjoyment for it predates the podcast. And so getting to talk with him was just such a delight, such a pleasure.

Nathan Toups (02:14)

Right. Yeah.

I knew how excited you were and I agree. It was a fantastic podcast episode. ⁓ It's just, nice to have great folks to talk to and yeah, we're so appreciative. We've also got, we've got some stuff in the pipeline too that we're really excited about. don't ever, it's a policy that we don't talk about these things until they happen, but ⁓ just, you know, live through our excitement that things that we know about that you soon will ⁓ are pretty cool.

Carter Morgan (02:32)

We do.

We

have one recorded in the bag, another one with a name we're very excited about, scheduled, and almost all of the ones that are scheduled go through. ⁓ And then one where we are in communication and hoping to get that scheduled soon.

Nathan Toups (02:46)

Mm-hmm.

Also,

a quick shout out, we're not going to say who yet, but one of the book publishers has actually reached out to us. ⁓ Pretty, yes, pretty exciting. So this is a little ⁓ pressure. If any of the other book publishers also want to speak out to us and you know who you are, because you haven't reached out to us yet, ⁓ we would love to, I think this is a perfect community. ⁓ Obviously it helps us with the bottom line of like, know, free books or preview books. Those are really great. And then we would love the opportunity to have things like

Carter Morgan (03:05)

Yes, yes, one of the publishers did reach out to us.

Nathan Toups (03:28)

know, book giveaways and other kind of cool stuff that would be, you know, just positive benefit to everybody. So.

Carter Morgan (03:34)

Yeah. Well, we, we've been really excited about obviously all the people we've been able to talk to and about how the podcast has grown. obviously none of that is possible without the listeners help. And you know, you guys are the reason we can do all of this. I guess you guys are the reason we can do all of this and feel good about ourselves. guess Nathan and I could just do this and get a zoom call ⁓ once a week and talk to each other. ⁓ but it's fun to be able to do it with an audience. feel like it's learning and growing along with us and

Nathan Toups (03:55)

Right.

Carter Morgan (04:02)

in recognition of our audience. We've got a fun little treat for you guys this week. I guess it's really more a treat for us. You guys know that we do essays every now and again. We take a break from the books and do an essay. And say, why do you do the essays, Carter and Nathan? Is it because they're so informative that they beat a book? Maybe. The real reason is that recording this podcast is very easy. Editing it is a little harder, but also not too difficult.

It's reading the dang books that consume so much of our time with this podcast. so every now and again, we give ourselves a little break, but still want to provide quality content to you guys. And we pick up an essay and we've been really happy with the essays we've chosen. I think they have been really informative. This one is just a fun essay. ⁓ How would you even describe this, Nathan? Should we just go into the, Claude generated introduction?

Nathan Toups (04:32)

Right.

Yeah,

and I'm gonna nerd snipe. So you can say towel, but I think most folks actually pronounce it dow, even though it's spelled with a T. Yeah, so it's the dow of programming. ⁓

Carter Morgan (04:56)

Okay.

Dow, okay, then we all pronounce it Dow.

The Tao

of Programming by Jeffrey James. This is weird in the best possible way. It's funny. So I guess let me just introduce Jeffrey James and let me, there's no traditional book introduction for this. So this is, we just had Claude generate this for both these things. So here's what we got. Say Jeffrey James is an English literature graduate from UC Irvine who worked as a software architect and system architect in the 1970s and 80s before writing The Tao of Programming in 1987.

which became one of programming's most widely quoted books despite being published as a satirical parody. He transitioned from technology writing to business journalism, serving as tribute editor at ink.com since 2007, where his sales source blog reaches over 1 million monthly readers, though his 1987 programming humor remains his most culturally influential work. So what is this? Again, it doesn't have a introduction on the back of the book, so this is what Claude generated for us. We have, The Dow of Programming is a 151 page satirical masterpiece.

And it's not actually that long. I don't, maybe that's hallucinated or maybe this was like all printed out. Okay.

Nathan Toups (06:05)

No, no, no, this is real,

because I looked at the print book, I checked these things. ⁓ It's written in the form of the Dao De Jing, ⁓ which is a traditional sort of Chinese wisdom book, where a parable is on each page. And so it's very short, but it's 150 like little koans or little wisdom sayings, proverbs kind of things. But yes, it's a stretch to call it 150. Yeah.

Carter Morgan (06:19)

Okay.

Okay, so it was 151 pages,

but I we read this in about 30 minutes, if that. Well, it's a satirical masterpiece that reimagines ancient Taoist texts as programming cones, using master novice dialogues to skewer corporate bureaucracy while celebrating programmers as creative artists rather than mere technicians. Written during the rigid mainframe era by software architect Jeffrey James, it spread virally through pre-internet BBSs.

Nathan Toups (06:33)

Yes.

Carter Morgan (06:52)

and academic networks become one of programming's most quoted books, directly inspiring the Zen Dao project management software and earning canonical status alongside the Mythical Man Month. Its enduring relevance stems from addressing permanent human tensions in software development, autonomy versus control, simplicity versus complexity, craft versus process that remain as applicable to modern agile and DevOps practices as they were to 1980s waterfall methodologies. So this might be a bit of a shorter episode. It's funny, we say that at the beginning because we think it might be, but

You can see the time right now and know whether it actually turned into a short episode. ⁓ but yeah, I mean, I, maybe before we get our general thoughts, I should just start with the very first Dow just so you guys can kind of get an idea of, ⁓ what it is. mean, like, or maybe I'll do the second one. So the first one's a little introductory. like the Dow gave birth to machine language, machine language gave birth to the assembler. The assembler gave birth to the compiler. Now there are 10,000.

Each language has its purpose, however humble. Each language expresses the yang and yang of software. Each language has its place within the Dao. But do not program in Kobol if you can avoid it. So that gives you an impression of kind of like what this is all about. Yeah, give me your thoughts Nathan on the Dao of programming.

Nathan Toups (08:10)

This book is hilarious and it's a quick read. It's weird how...

how like prescient this book feels. It feels, it still feels very fresh, especially in things like the corporate management and like, yeah, like there's like a manager's section, there's like a corporate section. And you're like, some things haven't changed. Like, you know, I would have been, you know, what, four years old when this book came out, four or five, you weren't even born yet. And, ⁓

Carter Morgan (08:21)

Right.

I wasn't born now.

Nathan Toups (08:47)

And yet the same things that people run into, I will say that there is some stuff like I think in the age of like in the lens of time, I guess, some of this, the way that he talks about programmers would be considered like, quote unquote, toxic or like sort of like toxic programmer culture or something, or this idea of like a programmer shouldn't be accountable for anything and goes off and does something mystical and comes back. ⁓

But who cares? None of it's mean-spirited. None of it's saying programmers are better than non-programmers. If anything, it shows how eccentric they can be. And I think especially these kind of mainframe and systems-level programmers, it's still true. When you think of Greybeard Linux guys and stuff like this, it's still very much an eccentric encapsulation of how things are done. I think he got a magic, there's a magic and a ⁓

inside knowledge that think we've all seen a glimpse of. ⁓ somehow he does it in this really whimsical form that I got a kick out of it, really.

Carter Morgan (09:55)

Yeah, this this book. ⁓ So one love the web design and you guys will link the web the website. It's hilarious. This is it's like black text on like a green and white gradient background. ⁓ Yeah, I think I'm with you, Nathan, in that like there's there's a bit here about like the programmer as you know, the old you know, the crotchety graybeard who doesn't want to do with deal with anyone. We have talked on this podcast about how you as a programmer will

Nathan Toups (10:03)

yeah.

yeah, it's amazing.

Carter Morgan (10:24)

would be much more likely to succeed in your career if you are engaged with the business, have good people skills, all of that. And so I think about this a little like, I don't know, and everyone knows, if a lot of people who listen to podcast know that I'm a Latter-day Saint. And so one of my guilty pleasures is the Broadway Book of Mormon musical. I do enjoy it. And part of it, I can enjoy it because I can look at it and kind of see where they're making fun of us and what they're exaggerating and what they're not. I have a, you know, obviously end up.

understanding of theology, I would be mortified if anyone listened to that musical and kind of came away saying, ⁓ that's exactly what Mormons believe and that's exactly how they are. This kind of gives me a similar vibe, right? Where like as experienced programmers, we can read it and it's funny and we're fun at ourselves. I think if someone ever read this and considered a serious text, I don't know how you could, like it'd be a little embarrassing, but yeah, I mean, this is just fun. It's silly, it's stupid in the best possible way. It's very like,

Conan O'Brien talks about how his favorite kind of humor is at the intersection of stupid and smart. And that's exactly what this is right here. ⁓ So yeah, just really, really fun. ⁓ I guess it's divided into nine books. ⁓ Again, all very small. I don't know anything. Do you just want to go through the nine books and pick out our favorite DAO from each of them and just riff? ⁓

Nathan Toups (11:39)

Right.

Yeah, yeah.

And I will say, so I actually like, I'm a big fan of Eastern religious studies, and there is a little bit of mixed, so like, I actually just reread the Tao Te Ching not too long ago, like less than two years ago. And even, I think I even wrote about it on Functionally Impaired a little while back. I read it with The Creative Act, which is a book by Rick Rubin in a similar style to Great Book.

This captures a good bit of that, but there's also Zen cones, and Zen cones are this sort of master student sort of talk back and forth. And that's not the way the Daldeshing is written. It's like the Daldeshing will talk about these sort of like great truths, you know? And so anyway, I'm being pedantic. Maybe that's the programmer in me, ⁓ being pedantic about this. Like, well, actually, this isn't actually the way the Daldeshing, but anyway, it's kind of funny. I think there is some critique of this, but... ⁓

I actually think that makes the book great. it's not a criticism of the book, but anyone who's actually read the Dao De Jing or has actually read Zen Coens will kind of notice that he kind of hops back and forth at his own liberty. But I think it makes the book, it flows quite nicely actually. So yeah.

Carter Morgan (12:44)

Yeah.

It does. Very easy to read. I read it in

between. I was writing a lot of Terraform last night and while I was waiting for the Terraform cloud to do my runs for me, I would hop here and read a couple of these and yeah, lots of fun. go ahead.

Nathan Toups (13:12)

Do you know the story?

⁓ Before we get into this, this actually fits quite well because the kind of programmers here are the ones who like you hear stories of programmers at build labs and stuff. Like I actually was thinking about, you know, Unix history and a memoir. The joke at Google who created the Go programming language, it was Ken Thompson and Rob Pike and ⁓ Robert Grisemer. And while they were waiting for the C++ code to compile, they wrote the spec for Go.

Carter Morgan (13:24)

Yeah, yeah.

Nathan Toups (13:42)

So there's this idea of doing creative work while you're waiting for the compiler to run or waiting for your jobs to deploy. So yeah, it's a wonderful time.

Carter Morgan (13:43)

really?

It's ⁓

Well, so we start with book one, the silent void. I shared my favorite one dot two. Is there any that stand out to you, Nathan, or should we just move on to book two?

Nathan Toups (13:59)

Yeah, so again, this captures this sort of like, a lot of these ancient texts would kind of look for these paradoxes. And I actually loved the fourth one that's in the first section. says, the wise programmer is told about the Dao and follows it. The average programmer is told about the Dao and searches for it. The foolish programmer is told about the Dao and laughs at it. If it were not for laughter, there would be no Dao. Right? And just ridiculous. The highest sounds are the hardest to hear.

Carter Morgan (14:09)

Okay.

Yeah.

Nathan Toups (14:27)

Going forward is a way to retreat. Great talent shows itself late in life. Even a perfect program still has bugs.

Carter Morgan (14:37)

Yeah, very kind of self-important and silly. And I guess we shouldn't say the DAO of programming. doesn't exactly say, like the DAO is kind of like the overall arching essence of programming. 1.1 says, something mysterious has formed, born in the silent void, waiting alone and unmoving. It is at once still and yet in constant motion. It is the source of all programs. I do not know its name, so I will call it the DAO of programming. If the DAO is great, then the operating system is great. If the operating system is great, then the compiler is great. If the compiler is great, then the application is

The user is pleased and there is harmony in the world. The Dao of programming flows far away and returns on the wind of morning." So that's what you're in for today, folks. ⁓ Book two is The Ancient Masters. ⁓ I know.

Nathan Toups (15:19)

Which is hilarious to think about. There's ancient masters in 1987, but

there were programmers who had been programming for decades at this point. It's hard to imagine, but really they were.

Carter Morgan (15:28)

Yeah,

two dot three kind of gets to that idea of, and again, this was written in the eighties. think tech has become, especially in our day and age, much more hip, much more cool. And tech has become a landing place for a lot of generally ambitious people. would place myself as falling within that. I don't think I would have been a programmer in the eighties. I think it's kind of funny to like,

look at the history of programming, say like, okay, when would I have hopped on? And like, I think maybe the nineties I would have because of the dot com boom. But in general, ⁓ think tech has gained a lot more prestige in a way that it didn't maybe back in the eighties and two dot three kind of illustrates that he says a programmer from a very large computer company went to a software conference and then returned to report to his manager saying what sort of programmers work for other companies? They behave badly and more unconcerned with appearances.

Their hair was long and unkempt and their clothes were wrinkled and old. They crashed out the hospitality suite and they made rude noises during my presentation. The manager said, I should never have sent you to the conference. Those programmers live beyond the physical world. They consider life absurd, an accidental coincidence. They come and go without knowing limitations. Without a care, they live only for their programs. Why should they bother with social conveniences? They're alive within the Dow. You know, we all know that kind of programmer.

Nathan Toups (16:45)

I love it, yeah. Also, it's just,

exactly. ⁓ We had this one guy who was like one of our software architects at one of the companies I worked in. Super nice guy, but he would go off and work on some really hard C++ problem. And he was the kind of person who would inspect the assembler that was generated. He was doing very low level system stuff. He cared about the instruction sets.

that were being generated and like, is there a way that he could, and I almost thought of it as like, could he whisper to the compiler, right? Like, could I structure my code so that the assembly language, the assembler that comes out of the other side is beautiful, right? And I just, that's a type of programming that I've always appreciated, but I've never done myself. And that attention to detail, and I think there's this sort of like, there's a mix of like eccentric genius that exists in this. And I think that that's what attracted this

Carter Morgan (17:34)

Right.

Nathan Toups (17:43)

era of programmers.

And in some ways, you know, there's this, there is, there's this sort of like quiet beauty, almost enlightenment type of, you know, pursuit that is in there. So, so in this chapter, the ancient masters, 2.2, Grand Master Turing once dreamed that he was a machine. And when he awoke, he exclaimed, I do not know whether I'm Turing dreaming that I am a machine or a machine dreaming that I'm Turing, which again,

It's, and this is actually a direct quote. There's a, this came from one of the Dao De Jing, just a little side note. There's a Dao De Jing passage about one of the ancient masters dreaming that he was a butterfly and then not knowing was he a human dreaming he was a butterfly or a butterfly dreaming he was a human. And so like some of these, if you know the history to them, you're like, makes it even funnier, I guess, because it's ridiculous.

Carter Morgan (18:38)

I'm going to cheat. I'm going to read another one from this one, 2.4, because this one cracked me up, too. It says, novice asks the master, here's a programmer that never designs, documents, or tests his programs. Yet all know who know him, considering I'm one of the best programmers in the world. Why is this? The master replies, that programmer has mastered the DAO. He has gone beyond the need for design. He has not become angry when the system crashes, but accepts the universe without concern. He has gone beyond the need for documentation. He no longer cares if anyone else sees his code.

He has gone beyond the need for testing. Each of his programs are perfect within themselves. Serene and elegant, their purpose self-evidence. Truly he has entered the mystery of Dao." And I think like, yeah, I don't know. There's some wisdom in this. I think it's more mocking the people who have just been around so long that they don't care.

Nathan Toups (19:23)

Right.

I think this is what every founder thinks that their founder's code is. ⁓ You're like, this is perfect. I got the perfect, and you're like, I'm glad you, right.

Carter Morgan (19:28)

Yeah, exactly. Right.

And he no longer cares if anyone else sees his code. Well, so

book three, we've got design. You got one in here, Nathan, out of the four dows here, or the four verses, I guess.

Nathan Toups (19:43)

man.

Yeah, I remember thinking I

enjoyed this chapter, but let me, ⁓ yeah, three one is pretty funny. It's a little bit longer. I guess it's still worth a read. It's been cracked me up because I didn't, yeah, the punchline's great. says, ⁓ there once was a man who went to a computer trade show and each day he entered, the man told the guard at the door, I am a great thief, renowned for my feats of shoplifting. Be forewarned for the trade show shall not escape unplundered.

Carter Morgan (19:55)

Go for it.

Nathan Toups (20:15)

This speech disturbed the guard greatly because there were millions of dollars of computer equipment inside. So he watched the man carefully, but the man merely wandered from booth to booth, humming quietly to himself. When the man left, the guard took him aside and searched his clothes, but nothing was to be found. On the next day of the trade show, the man returned and chided the guard saying, I escaped with a vast booty yesterday, but today will be even better. So the guard watched him ever more closely.

but to no avail on the final day of the trade show, the guard could restrain his curiosity no longer. Sir thief, he said, I am so perplexed. I cannot live in peace. Please enlighten me. What is it that you are stealing? The man smiled. I'm stealing ideas, he said.

Carter Morgan (21:05)

⁓ Press scans in the age of AI.

Nathan Toups (21:08)

Right, exactly.

It's literally every AI scraper on the planet right now.

Carter Morgan (21:13)

Yeah.

No, I love this. I remember my first internship. was struggling with some sort of like, I was, writing a code for an Android app and I was struggling with something. Um, I just going to figure it out. And I had this realization. I was like a very new programmer. was like, someone somewhere in the world knows the answer to this. Like they just know straight up like how exactly you should solve this. And they're not here and I don't know how to get to them. Um, and

I think that's something that's so fun about our industry is just that a lot of what we've done, we're in this weird industry where it is considered a somewhat difficult profession, or least a cognitively demanding one, yet most of our day consists of solving solved problems over and over and over again. Again, different in the age of AI. I've been very grateful at how quickly we can get solutions these days as opposed to back in my internship. ⁓

You know, we shamelessly steal ideas in this industry and I'm a big fan of it.

Nathan Toups (22:14)

think it was Picasso, or at he's attributed to Picasso that said, real artists steal. And I think that that is absolutely true. And of course, the thing is, that can you steal an idea? Because an idea isn't, to me, an idea is a copy of itself, right? If somebody comes, if we're living in caves, and then one of us comes up with the idea of a thatched roof hut, and it's useful because there's just not enough caves for our tribe.

Carter Morgan (22:27)

Bye.

Nathan Toups (22:42)

And then I see this and I go, oh, that's really smart. And then I build my own thatched roof, or maybe you even teach me how to make the thatched roof hut. Did I steal? Did I steal this? I don't think you did, right? And until we come up with these ideas of like copyright and these other things, ideas are meant to be contagious and the good ones stick around and the bad ones go away. But again, it's funny, we were even grappling with this back in 1987, right? Like what is software?

Carter Morgan (23:10)

Right, right.

Nathan Toups (23:12)

Who owns it? Who gets to make copies of it? And this is a ⁓ long fight. it's funny, because I think that there's a place, I've kind of gone full circle on this, and I appreciated it, then I was very against copyright. And then now I'm just like, to each their own. I think that if you feel you need to use copyright in the IP law system, go for it. I think that there's some spaces in which you protect things in the open source, and it's actually like,

beneficial to everybody and I think that both of those coexist in a really nice way.

Carter Morgan (23:44)

Yeah, I loved 3.3 and I guess maybe we should be opening these books. They start with, all of them start, believe with the say the master programmer. So for book three, have the say the master programmer. When the program is being tested, it is too late to make design changes. And so one of the verses 3.3 is, there was once a programmer who was attached to the court, the warlord woo. The warlord asked the programmer, which is easier to design an accounting package or an operating system and operating system replied the programmer.

The warlord uttered an explanation of disbelief. Surely an accounting package is trivial next to the complexity of an operating system. He said, not so, said the programmer. When designing an accounting package, the programmer operates as a mediator between people having different ideas, how it must operate, how reports must appear, and how it must conform to the tax laws. By contrast, an operating system is not limited by outside appearances. When designing an operating system, the programmer seeks the simplest harmony between machine and ideas. This is why an operating system is easier to design. The warlord of blue nodded and smiled.

That is all good and well, but which is easier to debug? The programmer made no reply.

Nathan Toups (24:49)

I love this. does make you think, you're like, and again, I've seen this where I've spent most of my career doing that sort of like accounting site implementation work, but I have seen the systems thinkers who try to make platforms for how, make, well, and I'm dealing with this even with some of the blockchain stuff I'm working on. Like blockchains are trying to be this sort of operating system for a type of financial transaction.

Carter Morgan (24:50)

Yeah, I think there's a lot of truth here, right?

Nathan Toups (25:19)

By default, they're trying to be as simple as possible to let the expressions between what you can do with a ledger and what you can do with other things. And it's a very different mindset. And I think this, humorously captures it quite well.

Carter Morgan (25:33)

Yeah, I mean, I've been having a bit of an experience with this where so I led our migration away from Azure onto AWS for our services. But when I did it, I did it just kind of very quickly and I did it all doing like click ops, like just creating stuff in the console and right. Obviously that's not great. You want Terraform to be able to do an aversion controlled way to have a source of truth for your architecture. I didn't do it. Sorry everyone, but I really wanted to. And so.

What I have been doing and actually just wrapped it up last night was I was taking all of those resources and writing the Terraform modules for them and importing them into our Terraform state. And so just last night I finished up, got everything in staging imported into Terraform. And the reason I was actually putting in hours after work on this and the reason I was doing it is just cause it was fun. And the reason it was fun, was like this great combination of like, it was self-led, no one was asking me to do this. So I kind of had my own leeway.

I was learning a lot. I haven't done a ton of Terraform work in the past, so I got to do that. But it's also pretty high impact because, obviously creating all your stuff and ClickOps and having no history of it is not a great place to be. So it's very high impact and like better programming practice for us, but also in modeling behavior for the team. But the other really nice thing about it just that like, it had a really nice flow to it because I wasn't trying to like balance business concerns or make design decisions or anything like that. It was just like this architecture exists.

Get it imported, write the module, get it imported. Okay, that works, move on to the next thing. And so it's just very, you know, it was like a high impact, very satisfying task. But I think part of the reason it felt so satisfying is what this DAO talks about. Just that like there wasn't that, ⁓ you'd have to balance business needs or any sort of real life representation of the world. You just had to write the Terraform modules and get your architecture imported into it. So lots of fun. And I think speaks to the truth of this DAO.

Nathan Toups (27:29)

And I think this also gets back to like when we were talking to Jason Fried, and they talk about this idea, it doesn't have to be crazy at work and finding fun. Being butts in the seats for eight hours a day isn't actually exactly what you're being hired for, right? It's these epiphanies. If you're taking a shower and you're thinking about a work problem and you're like, man, let go write that thing down before I forget about it. Those little breakthrough moments are incredibly valuable. Obviously you need to put in time.

Carter Morgan (27:47)

Right.

Nathan Toups (27:58)

saying, don't be accountable for the amount of time that you work. But sometimes I do feel the most productive. And again, I'm kind of a night owl. like my wife goes to bed pretty early. My daughter goes to bed pretty early. And there's this like hour and a half window where I feel very productive before I go to bed. And I'll actually use it. I allocate that time, not because I'm a workaholic, but a lot of times it's personal projects or some, you know, side hustle type things I'm thinking about.

Carter Morgan (27:58)

Right, right.

Uh-huh.

Nathan Toups (28:26)

But just, it's like, I know it'll be there. I know it'll be quiet. And I know I can be super creative in that way that's good in those twilight hours. And that's not, to me, that's not like a toxic thing. I think that's like, ⁓ I just know how I work. And that's, know, yeah, so.

Carter Morgan (28:38)

Yeah, yeah.

I try to ride those waves when I can. They'll just be like, like nights like last night where I'm like, this genuinely sounds like the most fun thing for me to do right now. I don't want to, you know, scroll Reddit or play Bellatro, you know.

Nathan Toups (28:53)

Yeah. I

will say, I should probably write about this because like I'm a huge fan. So I'm a huge Terraform fan. And there are some folks who are like, oh, you should always write Terraform first. But I'm actually a big fan, especially if you're doing exploratory work, of doing click ops to kind of get the shape. It's like the creative side of it. Get the shape of what you want and then do Terraform imports until you understand how to describe the thing that you've built. there two things. So two things come from that run. One is...

Carter Morgan (29:10)

Right, right.

Yes.

Nathan Toups (29:19)

I know exactly what I actually click ops now. And the other one is, let's say if I'm using like a special module or something, I know the gap that I had, right? So like, it's like, it wants to create this extra security group or there's this role that I'm missing. You know, yeah, I am missing that. Like this is really good that it's pushing me back and saying, hey, your state management needs to be a certain way. And so I'm a big fan of like a yes and, like it's, you know, no production should not be in click ops. Yes, you can use click ops to kind of get the shape of what you want, cause you're not quite sure what you want yet.

Carter Morgan (29:22)

Mm-hmm.

Nathan Toups (29:49)

And now moving forward, you'll just use Terraform. know, that's, I think that's a cool way doing it.

Carter Morgan (29:52)

Yeah, I really

enjoyed that. We, all of our services kind of follow the same like Dockerized ECS architecture. And so we had our four original services that I migrated when I, we needed to make a fifth service that followed that. And that one I did do entirely in Terraform because I'm like, I know the shape of what I want. And so I'm just going to write the Terraform. And then I use the legwork from that to import the rest of it in, but also say that, you know, with ClickOps and the idea of like, okay, now

Nathan Toups (30:11)

Exactly.

Carter Morgan (30:21)

You do the click ops, then you write your Terraform. ⁓ Large language models are very helpful for that because, you know, my general flow was like, okay, I have this resource that already exists. You give me the AWS CLI command to describe the resource and then I will give it to you and then you write the Terraform, right? And then, you know, it doesn't get it right all the time. And there were certain like, like sometimes it would like mess up a dependency, like, cause my whole point was like to. Yeah.

Nathan Toups (30:32)

Mm-hmm.

Right.

And Terraform has changed too,

so sometimes your Terraform recommendations will be outdated, you know.

Carter Morgan (30:48)

Yeah,

yeah. Well, that part I wouldn't know about because I am now the team Terraform expert and know very little about Terraform. ⁓ Well, let's move on to book four. This is coding. go ahead.

Nathan Toups (30:58)

actually, no, I

do want to cover one. I just kind of was dallying on this. So my favorite was the last one, 3.4. It says, a manager went to the master programmer and showed him the requirements document for a new application. The manager asked the master, how long will it take to design the system if I assign five programmers to it? It will take one year, said the master promptly. But we need the system immediately or even sooner.

Carter Morgan (31:03)

Okay, okay.

Ha

Nathan Toups (31:26)

How long will it take if I assign 10 programmers to it? The master programmer frowned. In that case, it'll take two years. And what if I assign 100 programmers to it? The master programmer shrugged. Then the design will never be completed, he said.

Carter Morgan (31:34)

You

This is the mythical man month to a T.

Nathan Toups (31:45)

Yes,

yes, it It's the Cliff's Notes version of Mythical Man Month.

Carter Morgan (31:51)

Yeah. I mean, I, I know that I, I was on a team. had one manager, there were 18 engineers, simply too big. I, I've mentioned the podcast before. I am a fan of the Amazon two pizza team philosophy. I think that's the idea that your team should only be so large that two pizzas can feed it entirely. So that roughly translates to about eight engineers. ⁓ I like that. think that's a good size. ⁓ I know other people have different thoughts, but, ⁓ but you know,

Nathan Toups (32:17)

You know the

Two Pizza Team has arrived when I'm listening to the audiobook of Build a Business You Love by Dave Ramsey. And Dave Ramsey has an entire section on why two pizza teams are great.

Carter Morgan (32:25)

nice.

interesting. Okay. So Dave Ramsey

agreed. Did you see that meme? It was like, because you know, there was talk about like a 50 year mortgage this week and it was like Dave Ramsey in critical condition after hearing about the 50 year mortgage.

Nathan Toups (32:42)

Yeah. Yeah, it

is nuts. It's funny too, because these longer term mortgages have actually existed in other markets. I think in Japan, they've been doing 50 year, they even have like a 100 year inheritable mortgage and other kind of weird instruments like this. yeah, Not saying we should go that path. It sounds like the opposite direction where we need to be.

Carter Morgan (32:51)

commercial realistic? yes, they do. Yeah.

wow.

Let's go to book four coding. is, Thus Make the Master Programmer. A well-written program is its own heaven. A poorly written program is its own hell. I really like the introductory verse here, four dot one. A program should be light and agile. Its subroutine is connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much. Neither needless loops nor useless variables. Neither lack of structure nor overwhelming rigidity. A program should follow the law of least astonishment.

What is this law? It is simply that the program should always respond to the user in the way that astonishment emleased. A program, no matter how complex, should act as a single unit. The program should be directed by the logic within rather than by outward appearances. If the program fails in these requirements, it will be in a state of disorder and confusion. The only way to correct this is to rewrite the program. I think Martin Fowler might refer reference to lawfully astonishment in his book, Refactoring. Maybe it hops up in a philosophy of software design. I don't remember exactly which. ⁓

hey, while I'm on the topic, ⁓ listeners, let us know. We are planning this upcoming year to reread some books. There are some books we have felt like we, like I've been feeling a pull in my career, like I really wish I could crack this one open again and give it another read. And so obviously that lessens our reading burden a bit because we're able to maybe skim a bit more than we have in the past. But I am excited about the idea of revisiting some of these books. Let us know in the comments. Is that something that

You'd be interested in getting like another episode of philosophy of software design or refactoring or are you here purely for the new content?

Nathan Toups (34:41)

I think I'll also put a little amendment to that, which is that sometimes books have a new edition that comes out. And so for instance, team topologies has a major revision that's out. I think, ⁓ and so even, yeah, I would love to hear your feedback of like revisiting one of the classic books, especially because we've developed as podcasters since we've read, especially some of earlier ones. But also if you are interested in, should I check out the second edition of a book maybe that we've covered in the past or a third edition or whatever?

Carter Morgan (34:46)

That's true.

Nathan Toups (35:09)

Maybe that's a sort of middle ground. I'm a fan of both personally. think revisiting a classic would be great. I think it'd also be a good opportunity to ask new questions, especially if it's an author we've had on before. Like philosophy of software design, revisiting that, and then talking to John Osterhout with a new set of questions, I think would be really cool for the audience, in my opinion.

Carter Morgan (35:24)

Absolutely.

Yeah. Well, and so I think the reason this now jumped out to me is I love that idea of the law of least astonishment. I am not a fan of clever code. My goodness. I don't know why our code base is riddled with like turn areas that are chained like eight deep, like chained turn areas. No, no. Like I saw it and I, and then like my very first week, like a junior engineer submitted a PR where they just added to the turn area. was like, Nope. Like you got to refactor that change it into a function that just, you know,

Nathan Toups (35:47)

No.

Carter Morgan (35:59)

with some early guard clauses or something, anything but all these turn areas. ⁓ So yeah, I love the idea of the law of least astonishment here. Well, what do you got, Nathan?

Nathan Toups (36:02)

All right.

Right. Yeah,

so, no, this one's really, oh, I love this one. 4.3. A master was explaining the nature of the DAO to one of his novices. The DAO was embodied in all software, regardless of how insignificant, said the master. Is the DAO in the handheld calculator, the novice. It is, came the reply. Is the DAO in a video game, continued the novice.

Carter Morgan (36:18)

Yeah

Nathan Toups (36:37)

It is, even in a video game, said the master. And as the DAL in the DOS for a personal computer, the master coughed and shifted his position slightly. The lesson is over for today, he said. So yeah, it's funny too because I think that this is like the creeping complexity of certain systems and I think yeah, there's no love lost on DOS even though.

Yeah.

Carter Morgan (37:04)

I'm a web dev at my core, right? Like, and I'm happy I don't have to do a ton of work in the DOS. And our respect to the Linux graveyards of old and of today who handle all that for us. We've got a book. ⁓ go ahead.

Nathan Toups (37:18)

But no,

no, no, it's just funny too. I wonder what the DOS of today would be though, because I feel like maybe, yeah, I wonder what the like tangled mess of insanity would be.

Carter Morgan (37:25)

I guess that's fair, huh?

Kubernetes?

Yeah. All right, book five, maintenance. Thus spake the master programmer. Though a program be but three lines long, someday it will have to be maintained. I loved 5.3 here. A novice programmer was once assigned to code a simple financial package. The novice worked furiously for many days, but when his master reviewed his program, he discovered that it contained a screen editor, a set of generalized graphics routines, and artificial intelligence interface, but not the slightest mention of anything financial.

When the master asked about this, the novice became indignant. Don't be so impatient. He said, I'll put in the financial stuff eventually. I think this is, you know, we as software engineers love to focus on kind of the more nitty gritty technical details. ⁓ I'm really fortunate. I work at a startup and I'm fortunate to work at a startup where there's not really a culture of like any of it done yesterday. Like everyone in the business is very aware of the need to prioritize and that only so many things can be important.

And we try to have that same thought process as an engineering team. And that means that sometimes refactoring or migrations might get delayed or not done at all because we're trying to focus on what's going to deliver business value. But I think this kind of engineer gets a reputation in working with their business partners where they're so concerned about all the techie, more interesting

implementation details of the code. But at the end of the day, the code you write has to have a business file. It's got to make money for the business. you know, you can't forget that.

Nathan Toups (39:05)

Yeah, my favorite was 5.1 actually. So it says, well-used door needs no oil on its hinges. ⁓ A swift flowing stream does not grow stagnant. Neither sound nor thought can travel through a vacuum. Software rots if it is not used. These are the great mysteries. And it's true that we will talk about bit rot a decent amount. ⁓

especially if there are code paths in which we're changing the code a lot and there's some that we hardly ever touch, and those are actually the highest risk areas, especially if you're in a fast moving company, because you realize, oops, I didn't update the testing framework, or there's a bunch of dependencies that maybe kind of creep in. And it's funny that software rot was even, again, talked about in 1987. It just cracks me up that this is something that could have been written by somebody today.

Carter Morgan (39:57)

Right, Ram.

We got after this, we got book six management. So that's the fun one. Thus spake the master programmer, let the programmer be many and the managers be few. Then all will be productive. Six dot four I liked. The manager went to his programmers and told them, as regards to your work hours, you're going to have to come in at nine in the morning and leave at five in the afternoon. At this, all of them became angry and several resigned on the spot. So the manager said, all right, in that case, you may set your own working hours as long as you finish your projects on schedule.

The programmers, now satisfied, begin to come in at noon and work to the wee hours of the morning. I think there's a lot here. I'll say for myself, I'm a nine to five kind of guy. Those are my core working hours. mean, maybe sometimes it's more 9.30 to 5.30 or 9.30 to six or whatever, but I'm not someone who wants the, like in remote work in particular, some people really want remote work because they want kind of fully synchronistic stream flexibility in the hours they choose. I'm a believer in kind of.

us all needing to be awake at the same time and collaborating, whether that's remotely or in person. ⁓ But there is a lot of value here and I think being treated like an adult and I think programmers, especially in non-technical businesses, can fall in they can fall in this like grouping where like managers feel like they have to babysit them. And that's really, really frustrating. It's frustrating as a software engineer to kind of constantly feel talked down to.

by the business. And this happens a lot of places where you are viewed as a cost center rather than a, ⁓ gosh, what is the other? What's a benefit center? No. A cost, a product, opposite of cost center. How do we not know this?

Nathan Toups (41:38)

I don't know. what would be?

Profit Center, yeah.

Carter Morgan (41:46)

Okay. Profit. Yeah, I guess that makes sense. The opposite of cost is profit rather than profit center. Right. ⁓ so I appreciate when I'm treated like an adult at my job. ⁓ and I think this Dow kind of gets at the essence of that.

Nathan Toups (42:00)

So 6.2 says, are programmers non-productive? Because their time was wasted in meetings. Why are programmers rebellious? Because the management interferes too much. Why are programmers resigning one by one? Because they're burnt out. Having worked for poor management, they no longer value their jobs. This could be written about all the quiet quitting stuff that's happening. It could be written about, I mean, so many folks, people have been writing think pieces complaining about Zoomers or whatever. You're like,

No, this thing's been going on forever, dealing with bad management, it's just like been a part of the life of technical workers forever because I think it's just, it's hard to bridge this gap between deeply creative technical work and the sort of daily needs of paper pushing parts of the business. It's just, again, it's just funny because I'm like, ⁓ these aren't new problems. These have been happening forever. This is, know, this book's almost 40 years old at this point. ⁓

Carter Morgan (42:55)

Yeah.

Yeah. I think, ⁓ I've been fortunate. A lot of the management I've worked with has been like dysfunctional in a, like one-on-one line management, kind of people management sort of way, but I've mostly worked at like, you know, capital T tech companies. And so I actually haven't worked at a ton of like

Like this was written in 1987, where I think there was kind of before the advent of the modern tech company, your Amazons, your Googles, where like engineering was, is king. Um, and so I've been fortunate enough to work at a ton of companies where like, I'm just stuck in hours and hours of unproductive meetings that have nothing to do with me. And instead it's all just product managers arguing with each other. The one kind of Fortune 500 tech company I worked at on one particular project I was assigned to.

had exactly that. But for the most part, I worked at places that understand that software engineers are valuable. I was on call and trying to resolve this. It was halfway between a regular support taking in an actual technical challenge. And I had been going at it for a bit. And eventually, our head of product said, he just stopped and stormed into our conversation. He's like, Carter's hourly is too high to spend even a minute longer on this. Give it to someone else who can figure this out.

It's fun to work at places like that. Try your hardest to work at a place like that if you can. We've got after this book seven, we've got corporate wisdom. I might read a couple from this one, because this one is great.

Nathan Toups (44:33)

Yeah, you know, it's

funny too because you're like so much source material for like Dilbert comics and stuff like this.

Carter Morgan (44:38)

Yeah, yeah,

I love ⁓ Book 7, Corporate Wisdom. Thus spake the master programmer. You can demonstrate a program for a corporate executive, but you can't make him computer literate. A novice asks the master, the 7.1. In the east there is a great tree, a structure that men call corporate headquarters. It is bloated out of shape with vice presidents and accountants. It issues a multitude of memos, each saying, go hence or go hither, and nobody knows what is meant. Every year, new names are put onto the branches, but all to no avail.

How can such an unnatural entity exist? The master replies, you perceive this immense structure and are disturbed that it has no rational purpose. Can you not take amusement from its endless gyrations? Do you not enjoy the untroubled ease of programming beneath its sheltering branches? Why are you bothered by its uselessness? I can't relate to this one as much because, like I said, the big companies I've worked at have kind of all been around software engineering.

Right. And, and now I'm at a startup. And so like, I, I sit three desks away from the CEO. Right. So, it's not quite like this, but I do like kind of the attitude here of like, why do you care about this? Like we are able to program beneath it's sheltering branches. Right. Like they facilitate us to do our job and to do our job, hopefully well. Right. Don't you care about all that's going on over there at the one kind of fortune 500 company I worked at, like, yeah.

They reorg to the company every six months, right? And the people who had been there for a while very much had this attitude of just like, now they're reorg. Is my project still the same? Am I still on the same team? Great. Like let's keep going and we'll wait for them to reorg in the next six months.

Nathan Toups (46:17)

Some McKinsey consultant had to fill a very important, I have an idea, a reorg, and they're like, wow, wow, you did it.

Carter Morgan (46:21)

Yeah, yeah. I know.

Well, what do you got, Nathan?

Nathan Toups (46:29)

No, that I actually, it didn't hit me until you read it back again, but the why are you bothered by all of its uselessness is really kind of hilarious. I was just having a conversation with my daughter yesterday. was, she's in fifth grade and she was like, she's like, yeah, our teachers keep giving us a lecture, right, for lunch. She's like, but we're hungry. Like, I wanna go to lunch.

And she's very riled up about it and she's just very passionately talking about it, which is fun. I mean, think she's 10 now, so she's not quite a teenager, but you can see the sort of beginnings of heightened emotional states. And of course, I wish I had had this sentence in my mind of, are you bothered by its uselessness? Like, because that's I was just like, I was like, well, what are you gonna do about it? I was just asking her open-ended questions and just like, you know, was like,

Carter Morgan (47:06)

Right, right.

Hahaha!

Nathan Toups (47:23)

It seems like that was an important thing for your teacher to talk about. if your class was well behaved, then you would go to lunch. So maybe that's what you should focus on and not frustration that the teacher's lecturing you right now. But yeah.

Carter Morgan (47:34)

Yeah, I think there's

a certain amount of kind of like knowing your place, right? And like, and not knowing your, I am a big fan of programmers extending their sphere of influence and influencing other parts of the business. But I think you can also like get yourself really frustrated by things that ultimately don't have an impact on you. And so, know, just kind of focus on what's in your control, focus on what actually affects you.

Nathan Toups (47:52)

Right. Well, and

we saw this actually, you know, in the Plex, this same exact problem was happening in Google where there was this sort of like, you know, obviously you have an engineering first culture, but there's a usefulness to good management and leadership. But there would be a pendulum swing where things would shift and they'd go anti-manager, pro-manager, anti-manager, pro-manager. And I think there's a sweet spot that we haven't quite fully unlocked.

Carter Morgan (48:15)

Mm-hmm.

Nathan Toups (48:22)

⁓ I think Will Larson actually talks about this and he has some other blogs and stuff. He's the one who wrote the staff engineer book. ⁓ But he talks about effective management and like the myth of effective management and these other kind of like things about the good managers and things. And I think we just don't even have a good conversation about it. Even now, like we, there are some managers that are super hands off and don't do any one to ones. There's some managers super hands on.

There's some that do the radical candor technique. There's some that do others. And it just depends on who you're managing, what you're managing, the organization you're in, ⁓ and the absurdity of it all. It's interesting. It's an unsolved problem. I really do think so.

Carter Morgan (49:07)

Do you have one from book seven that you want to share? Oh yeah.

Nathan Toups (49:10)

Yeah, I think the last one. So the master programmer

moves from program to program without fear. No change in management can harm him. He will not be fired even if the project is canceled. Why is this? He is filled with the Dow.

And I've known programmers like this, who like, they're kind of like the permanent government, right? So there's like people elected to office, you know, they come and go, but there's like a permanent government folks, you know, you could also call them the deep state if you want to, but there's like the folks that are literally lifetime intelligence agency people or lifetime wildlife and fisheries people or whatever, right? And they're just like, they know, you know, some new elected officials going to come in and be super anti them or super pro them and...

they're just gonna have to weather the storm, they're gonna get through this. And the ones who last in their roles and can contribute can get through this. it is just, again, it's funny. I love this text.

Carter Morgan (50:09)

But I also think it speaks to value, right? Because

if all of the value you bring is that you're buddies with the manager, right? Or that your project is the CEO's pet project right now, but actually isn't that useful, and is the only thing you know how to contribute to, then of course you're going to be worried if management turns over if your project gets canceled. If you are a generally talented programmer and will thrive on kind of whatever project you're put on, then...

Nathan Toups (50:17)

Great.

Carter Morgan (50:36)

You don't have to worry so much about management changes or project cancellations. and I think we've talked about this a lot of the podcasts, but like, we're, so fortunate to work in an industry where the harder you work, the more you learn, the better it pays off for you, right? There there's like almost a direct, there's direct payoff to, to, doing those things. And so, you know, I think when you don't work hard at your job, when you don't try to learn more about this field, the only person you're really cheating is yourself. ⁓ and so.

Nathan Toups (50:54)

Yeah.

Carter Morgan (51:05)

If you're listening to Book Overflow, have the hunch that you're the kind of person who does push themselves and try to learn and do more. ⁓ But yeah, so be like the master programmer who is filled with the doubt. We've got book eight, the final book, Hardware and Software. Thus spake the master programmer. Without the wind, the grass does not move. Without software, hardware is useless. I enjoyed 8.1. This is a novice ask the master programmer.

I perceive that one computer company is much larger than all others. It towers above its competition like a giant among dwarfs. Any one of its divisions could comprise an entire business. Why is this so? The master replied, why do you ask such foolish questions? The company is large because it is large. If it only made hardware, nobody would buy it. If it only made software, nobody would use it. If it only maintained systems, people would treat it like a servant. But because it combines all of these things, people think it one of the gods. By not seeking to strive, it conquers without effort.

You know, this is kind of like the Apple philosophy where Apple has insisted for years and years and years and years that they will own both the hardware and the software. And in general, I think that has proven to be a very good philosophy, least business-wise and in terms of anything, making a comprehensive product. Microsoft is kind of the opposite and insisted for years and years that they were a software company. That's all they did. They just had the software. And that's been their big push, you know, in the past decade or so.

Nathan Toups (52:05)

Alright.

Carter Morgan (52:30)

is really getting into the hardware business and trying to make, they think they can make a better product by owning the process from start to finish. Again, this book was written in the 80s. I think we've seen some examples of very big, very successful companies that never get into the hardware space. Facebook has gotten into the hardware space with the meta, but all of their money is actually made on their social media websites. ⁓ You have like your Ubers, your Lifts, I mean,

Nathan Toups (52:54)

Right.

Carter Morgan (53:00)

Amazon, think the hardware it makes is not nearly as big, unless you count the robots who are doing the distribution, you're working the distribution sites. But in general, ⁓ I think this has proven less true after the internet age, but in general, there's a lot of truth to it.

Nathan Toups (53:17)

Well, I don't know,

I think though, if you think about it, cloud vendors are actually invisible hardware, software coupling. So like Amazon, I think it's rise, especially in this profitability, which is Amazon Web Services, obviously their most profitable section, right? No, no, no, I hadn't thought about it till, you're right, they all stopped doing, like,

Carter Morgan (53:25)

You know what? That's fair. That's fair.

Yeah, you know what? I stand corrected.

Nathan Toups (53:44)

HP and Dell are not the providers of hardware for these huge cloud vendors. They all have OEM manufacturing, right? OEM meaning that they work directly with the people who make all the core hardware components and they, know, huge data center designs. It's just invisible. And I actually do think that Apple proved this from a consumer device standpoint, that if you own the entire ecosystem, you know, it has stood the test of time.

Google has done this obviously with Android. ⁓ While there are other companies like Samsung that can make devices, Android, they still have the pixel line, which is still considered flagship and is more, most comparable to Apple's lineup. ⁓ But the cloud vendors, like Google had to get into the data center business and then offers a software layer for you to use their hardware, right? You don't think about the hardware, but it is interesting to think about. ⁓

I think there are a few exceptions, but it is interesting that the biggest profit center for Microsoft now is their cloud offerings, right? And ⁓ I think there is some huge, this is a good example for open AI, doesn't have hardware yet, ⁓ entropic, but I think it's inevitable. They're going to have something. I think it's gonna be probably something like a pendant-like device or glasses-like device.

Carter Morgan (54:50)

Yeah. Yeah.

Yeah, yeah.

Nathan Toups (55:12)

Facebook's really trying, or Meta is really trying to get into this space and I think they've been early adopters, but yeah, I mean, guess if you're into the VR headsets section, Oculus is definitely the most popular platform for that, but it's definitely not general audience, at least not yet, but I don't know.

Carter Morgan (55:24)

Right.

Yeah,

I'm a big fan of Metta's work in the headset space. I personally find headsets very, very interesting. And I think that the industry is not incorrect that this is the next big hardware revolution. very, very early to the game. And I don't know if there'll ever be anything as big as the smartphone again. It's just a very, Marques Brownlee calls it OP, overpowered and just like the one big touchscreen that fits in your pocket is

Nathan Toups (55:44)

Right.

Right.

Carter Morgan (55:58)

a really, really hard form factor to beat.

Nathan Toups (56:01)

I think if Apple, ⁓ there's one reason I have not, I'll actually, I'm not a fan of meta from a privacy policy standpoint, and so ⁓ I have not, I don't own an Oculus. I do think of all the vendors though that if Apple could make a $1,000 VR headset, I think that would be a big changer. And I also think that years ago they actually invested in some folks from Warby Parker, and I assumed, I thought that they were gonna get into glasses earlier.

Carter Morgan (56:09)

Sure, sure.

Yeah.

yeah, yeah.

Nathan Toups (56:31)

But I think if Apple figured out a way to make a sub $1,000 pair of fashionable glasses that were a way for you not to have to take your phone out of your pocket, right? Like maybe most of the compute power was in your phone and it was sort of like a, you know, heads up display compliment to it. That feels very Apple ecosystem to me. I know nothing about this, but I'm just like thinking about how would I, how could certain devices like seep in? ⁓

Carter Morgan (56:41)

Yeah.

Nathan Toups (56:59)

I think that because the phones are so overpowered, having something that just could sit in your pocket and not have to come out is a very appealing thing to me because there's certain things I want to use my phone for. But I've had an accessory that was really a nice compliment because the phone has so much compute power. ⁓

Carter Morgan (57:10)

Right, right.

Yeah. Well, I mean, I,

but I think you see the power of the ecosystem there because Meta has, as they've just released those new glasses, which are like, they actually look like glasses and they have that cool kind of neural wristband you wear. And so that's how you can control them. ⁓ which is neat, but then it's like, put other glasses on it. Cause I was curious. I'm like, I like this sort of stuff. And that's like a thousand dollars. Maybe I'll buy it just like as a toy, but then it's like, well, what can they do? It's like, well, you can, you can scroll Instagram. You can message on WhatsApp.

Nathan Toups (57:29)

Mm-hmm.

Carter Morgan (57:44)

And I'm just like, no, like if I want glasses, I want them to be able to read my text messages and be hooked into all of my notifications and work with FindMind. So just that there's such a huge advantage in the ecosystem there. ⁓ I owned the Apple Vision Pro. I bought it when I thought I would have time to try to develop for it ⁓ and just never had the time, so I returned it. ⁓ But yeah, really, really neat product. ⁓ Maybe a little ahead of its time. Well, what do you got, Nathan?

Nathan Toups (57:50)

Right.

⁓ These hardware and software ones, they're a little bit longer reads. think I'm going to skip over it, other than the fact that, again, I think it does tie into, there's some really nice ones. There's really, actually, I'll read the last one. So 8.4. Hardware met software on the road to, software said...

Carter Morgan (58:14)

What?

Yeah.

Yeah.

Nathan Toups (58:37)

You are Yen and I am Yang. If we travel together, we will become famous and earn vast sums of money. And so they set forth together, thinking to conquer the world. Presently, they met Firmware, who was dressed in tattered rags and hobbled along and propped on a thorny stick. Firmware said to them, the Dao lies beyond Yen and Yang. It is silent and it still has.

Sorry, it still is a pool of water. I'm sorry, side of my ⁓ scroll bar covered up this. Okay, it is still and silent as a, still as a pool of water. It does not seek fame, therefore nobody knows its presence. It does not seek fortune, for it is complete within itself. It exists beyond space and time. Software and hardware ashamed return to their homes.

Carter Morgan (59:09)

and it still has a pool of water.

Nathan Toups (59:36)

⁓ I loved this one because it is, firmware is this silent victor, and it's incredibly important interface between all of these things, and you don't ever think about it, and yet it's this super powerful thing. ⁓ There's a really great Ken Thompson ⁓ piece, actually we should probably read this at some point in the future, called On Trusting Trust, ⁓ about can you even trust your compiler to actually compile code in a secure way? And he actually proved that he built a

Carter Morgan (59:37)

Hahaha

Nathan Toups (1:00:05)

He built a compromised one that existed within Bell Labs for two years. And ⁓ firmware isn't the same, but it's like when you bootstrap your system from the ground floor, firmware is doing all of this interesting interfacing between ⁓ trust and reality. And ⁓ the coolest hackers are the ones who are firmware hackers.

Carter Morgan (1:00:30)

Well, we have book nine, the epilogue, it's just, thus spake the master programmer, time for you to leave. And that actually applies to me right now. I have to get to work here soon. So let's do our hot takes real quick. Give me your hot takes, Nathan.

Nathan Toups (1:00:37)

Yeah.

Yeah, so I have one, which is that corporate dysfunction is an unsolvable problem. So I think that this book is good evidence of this, that 40 years ago, or almost 40 years ago, this book was written and it was well established even before that. I think we keep hearing horror stories from people all over the world that still keep running into this sort of like fight. And yeah, I think it's here to stay.

Carter Morgan (1:01:11)

Yeah, my hot take is this is all well and good and it's a lot of fun and especially it's fun amongst us as software engineers to laugh about this. But just remember your farts, you know, your farts, they stink, right? And, you know, like don't think that you're going to smell like roses, right? There was, I was seeing some online discourse about a particular subset of people, you know, a type of profession that a lot of people

had distaste for. And the people in this profession were saying basically like, why does everyone dislike us? If you look at all these metrics, we're such great contributors to society, the people who don't like us just must hate us. And someone was kind of saying like, yes, your metrics are correct. But if you're still seeing this widespread dislike towards you, maybe there's something that says that the metrics aren't capturing. Jeff Bezos was kind of famous for that with saying that like anecdotes revealed something that hard data couldn't. And so

I think it's very fun to be a software engineer. are professionally seen as hip by lots of people, you know, especially the people who want to be software engineers who admire us. We are highly compensated. We, the skill we have is tough to do and results in cool things and results in software and creating things. And it can be really easy to think we are the coolest people in the world and everyone else's job is fake and...

Everyone in this business is just wasting money except for me, who's worth every penny. Don't be that kind of software engineer, right? Work in harmony with your product managers and your ops people and your PR and your law and all that, right? And then truly you will have mastered the DAO. I was talking about what we're going to do differently in our career as a result of having read this essay. What do you got, Nathan?

Nathan Toups (1:02:58)

I know the beginning of the book says, but do not program in COBOL if you can avoid it. But now I'm intrigued and actually want to give COBOL a try.

Carter Morgan (1:03:04)

⁓

Yeah, just gonna, I'm not gonna take anything serious away from this book, but I'm gonna post it in the work slack today. Share it with my coworkers. I think this is a great little read. ⁓ I might even make a Slack bot that like posts one of these dows each day in the engineering channel or something like that, you know, that might be fun.

Nathan Toups (1:03:23)

You

should have one of those nerd snipe ⁓ ones that scans for certain keywords that you're like...

Carter Morgan (1:03:30)

yeah, you know that that would

be fun. Maybe that's what I'll do. ⁓ as far as who would recommend this book to, I'll say everyone. I think if you're listening to this podcast and if you're a software engineer in general, just read this. It takes like 30 minutes. ⁓ and it's just funny. We read a lot of it to you right now. This is another one of those essays or episodes where just by listening to the episode, you actually got most of the book out of it. ⁓ but if you liked this podcast, go read the whole thing. It's fun. It's quirky and, ⁓ you can see why this is a classic. How about you, Nathan?

Nathan Toups (1:03:56)

Yep,

same boat. Our audience is prime candidate for this. would say if you're listening to this, you've made it this far, you should absolutely read it. We already read like half the book to you today. And there's also some rich history. I think it was in 2003, there's an interview that he did. I think it was around that, you know, 25th anniversary or whatever, or 15th, 15, then you do basic math, 15 year anniversary.

Carter Morgan (1:04:06)

Yeah.

Ha

Nathan Toups (1:04:22)

and he had some interesting insights on it. This thing was widely spread on the bulletin boards, like BBS systems, pirated all over the place, and I actually think that's what led to the rise of its popularity. ⁓ At the same time, you can get it for free online, but if you actually went like an original out of print copy, it's like 200 bucks to get original version of book. So it's like a perfect example of it's very valuable in its ability to be a nerd snipe.

Carter Morgan (1:04:43)

wow.

Nathan Toups (1:04:50)

to have the actual physical copy, but you also can just read it for free, say a 30 minutes read.

Carter Morgan (1:04:56)

Well, thanks for listening everyone. Hopefully this was fun for you guys. You know, we always appreciate covering something a little more light and fun like this and it makes our week a little easier. So hopefully you guys still got some value out of it. Message us at contact at BookOverflow.io. You can find me on Twitter at Carter Morgan. You can find the podcast on Twitter at BookOverflowPod and you can find Nathan and his work at the Functionally Imperative at FunctionallyImperative.com. Thanks for sticking around folks. We'll see you later.