Let's Talk Technical Books!

[MUSIC PLAYING] Hello, welcome to Picture Me Cutting with Erik Aker and Mike Mull.

My friend Mike Mull is with me today.

Hi, Mike.

Hey there.

How you doing?

I'm doing pretty well.

Finally stopped raining.

Finally stopped raining, and I finally got running water in my house.

I'm hoping never to take running water for granted again.

It's nice to have running water in your house.

Those two things are uncorrelated, right?

Not going to.

Well, the rain is correlated with-- we need to run a new sewer line at my house, and they can't dig up the yard until the rain stops.

So it is a little bit correlated.

It's sunny outside.

Hopefully it'll be sunny for weeks now, and they can dig up my front yard, so we can get back to indoor plumbing, which is this thing I've heard about, and I have newfound respect for.

Yeah, it's going to be big.

Big deal, indoor plumbing.

Have you been listening to music?

I've been listening to construction noises.

I have been listening to music, yeah.

What do you got, something I'm going to be interested in?

Yeah, I think this week another jazz album.

I keep saying I'm not a jazz guy, and I keep talking about jazz albums.

That's like I'm not a surfer.

I'm embarrassed by the culture, but I think about it all the time and dream about it and go regularly, but I'm not a surfer.

Yeah, I think it's pretty fair parallel.

But anyway, I mentioned here, I think, before that a few years ago there was this jazz album called "On Easy" by this trio, VJ Iyer, Linda May, Han Oh, and Taishan Sorry.

VJ Iyer.

You're kind of like a big VJ Iyer fan, huh?

I was not before that "On Easy" album, but I think I am now.

They just came out, this trio just came out with a new album called "Compassion," which I think is also really good.

I have found over the years that I prefer piano jazz, so that's probably a part of it.

I do too, actually.

But all three of these players are just top notch.

Probably one of the best bassists I've ever heard than the May Han Oh.

Just sometimes when she's playing, you can't really believe that it's a bass.

It's just so intricate.

And I say that as somebody whose son was a pretty one of my sons was a pretty high level bass player.

So I think I've heard good bass.

But anyway, check it out.

It's another really good album, solid, from start to finish.

I keep listening to the "Smile," the radio head-off-shoot band, Johnny Greenwood, Tom York.

They already have albums called "Wall of Eyes."

And I just think it has absolutely amazing guitar work in it.

I keep being kind of shocked and surprised by the guitar work in that album.

Did you listen to that one?

Did you like it?

Yeah, I've listened to it a lot.

I like it a lot as well.

I have to admit that I am one of those people who thinks that radio had peaked at OK Computer.

I don't agree with that.

But I have this shame about listening to radio head.

It's a cliche to listen to radio head.

Like in the first season of "Silicon Valley," where the main character is like, you know, this music analysis program is going to figure out which bands steal from each other.

And then the other guy is like, all bands steal.

And he goes, but-- and he goes, even radio head, OK?

It's like cliche.

But Johnny Greenwood is a genius.

He did one of the most amazing film son tracks I've ever heard.

And for "There Will Be Blood."

Just a complete genius.

Yeah, I liked both of these albums by the smile.

But I think I mean, I like this one a little bit better.

Me too.

I think that-- I think it's the penultimate track called "Bending Hectic."

I just love that song.

It's got-- it's a long song.

It's kind of got two parts where, you know, there-- it's kind of a play on words because the guitar work is, you know, bending this note.

And at the beginning, it's just sort of this meandering track.

And then at the end, it breaks into this sort of almost a metal anthem.

It's just a great build up.

And probably one of my favorite songs by, you know, Tom York and "Sometime."

I think you're wrong about OK Computer.

I really like Kid A.

I really like Amnesiac.

I'll tell you what I don't like.

And this is kind of a apostasy for somebody who likes radio head in general.

I don't like any of the lyrics Tom York writes.

I think they're all kind of nonsense and silly and ridiculous.

And I don't-- kind of like if I actually listen to what he sang, I think, jeez, I wish somebody else would write these lyrics.

This is going to piss a lot of people off.

Probably.

I should probably not say this out loud.

When I listen to Phoebe Bridgers, I think, I wish Phoebe Bridgers would write the lyrics for radio head songs.

Those songs would be so good.

That's a terrible thing to say.

Yeah, I-- I don't-- I like Phoebe Bridgers as well.

I don't entirely agree with you.

There's-- there's a few-- few radio head lyrics that I've enjoyed.

I really like the-- what's the line about the Hitler hairdo?

Oh, yeah.

I don't know.

It's just they seem all like throwaway lines.

There's nothing really-- well, OK.

I'm going to stop before I offend everybody.

He buzzes like a fridge.

That's a very-- That's a very clunky-- anyway.

All right.

We had a topic this week that you wanted to bring up.

And I was like, oh, this is a good idea.

What was your idea?

What was the topic you wanted?

Tell me.

So the topic is basically technical books, and specifically technical books that we like and have-- feel that we've gained something from over the years.

It's kind of a tricky topic because I'm not entirely sure that this is a thing anymore.

I mean-- Yeah.

Do people even read books anymore?

Well, some people apparently do.

Technical books, I think, have taken a pretty serious hit, obviously, because of the internet and Stack Overflow and Reddit and all of the forums that you can jump on to ask people questions.

Blogs and stuff.

Yeah.

Yeah.

I am interested in the technical books that you would consider foundational to your work, or what's the word like that your knowledge is built upon somehow because you've been in the industry so much longer than I have.

Yeah, that was kind of the idea, I guess, is to-- there's been about hundreds of books over the years, and probably 90% of them are in recycling at this point in time.

They were on topics that are no longer not merely not relevant, but nobody uses the technologies anymore.

Well, do you have an example?

I used to own a book on DCE.

I don't know what that is.

Yeah, nobody does.

It was kind of a predecessor to CORBA, kind of a procedure calls over the network type of thing.

Oh, OK.

I was in a bookstore in Seattle with friends of mine.

It's a coffee shop, and they sell all this maker stuff, and they have this book section that's all technical books.

And I was meeting some friends of mine, and I said out loud, wow, they've got a lot of completely obsolete books for sale on the shelves in here.

And I offended four people.

People hissed at me.

I just thought I was stating the obvious.

It's like, who wants a book on JavaScript from 2009?

Do you really want that?

Yeah, I still have a substantial number of books on things like Olay and Com.

They had a Macromedia Flash book on the shelf in this bookstore.

Is that an obsolete-- I would call that-- it's kind of sad that we've printed so much material that became obsolete so quickly.

Yeah, that one.

It's hard to even imagine that one coming back around and being historically interesting or something.

So OK, so you've got some books.

They were meaningful to you, and you're going to tell me about them.

I'll tell you about some of mine.

What's the first one you want to tell me about?

So the first one on my list is UNIX Network Programming by W.

Richard Stevens.

I have the version that first came out in 1990.

I think it's been through three or four versions at this point in time.

So my version was a little bit obsolete.

But I think this is one of those books that is kind of a-- it's almost like a keepsake for me, even if I never open this book again, it's something that means a lot to me and that was a very important part of my early career.

And it's a well-constructed book.

It's well-written.

It's the sections and the diagrams and the example code are all good.

So this is pretty low level.

It sounds like UNIX Network Programming, sockets, acts and acts, stuff like that.

Yeah, it talks about the OSI model, which was relatively new back then.

It talks about TCP/IP.

There's a very long chapter on Berkeley Sockets, which was kind of like the thing I was focused on for many years.

I don't think I've ever heard of a Berkeley socket.

Is it better than a regular socket?

It is a regular socket.

Oh, we just started calling them sockets after a while.

Nobody calls them Berkeley sockets anymore, but-- Oh, OK.

Yeah, I remember a couple of years ago at my employer, I gave a little presentation on stuff that I thought that programmers should know about networks.

And I think that was the last time I cracked open this book just to run through it and see things that I picked up over the years.

But one of the funny things is that at this point in time, sockets are considered to be extremely low level networking.

Yeah.

I tried to describe just this week somebody was asking me about disconnects in their app talking to a network resource.

And I was like, well, the socket gets closed on the server side.

And they kind of gave me a look like I don't understand what you're saying.

And so then I tried to-- and I'm not friendly claim I have a huge amount of knowledge-- I tried to describe the socket.

It's like a file descriptor.

And I sort of stopped and realized, I'm not doing a good job here.

I'm sucking at this description.

Yeah, if you look at the Python socket stuff, the documentation specifically says, this is a very low level networking interface.

You probably want something higher level.

But back in the day, we thought of this as being pretty abstract and high level, because we didn't have to know anything about the networking devices.

We could just open up these endpoints and start chevendata down them.

And it seemed extremely convenient.

And I guess when you're programming and see abstractions like this seem pretty high level.

But-- So UNIX network programming, all the examples in C, it's all about writing stuff in C to talk over the network.

Yeah, all the programming examples here are in C.

Do you remember any examples that came out of the book?

Anything where you're like, oh, this cool thing that they built, I could use this for inspiration?

Well, they have some client server code using sockets that's in the book that has probably been-- back in those days, you couldn't copy and paste it.

But it's probably the most copied code from the early '90s.

I know I essentially started using their stuff as an example and gave my versions of it to various other people who built more sophisticated things.

So just the example code for using sockets, both on the client and server side, has probably been reproduced over and over and over again.

What about formatting those?

What were the examples they would use when they're formatting?

Is that where the example comes from of, well, first, we're going to send a number which says how long our message is.

Did they do that kind of stuff?

Yeah, although they didn't really talk too much about-- it doesn't really talk too much about application level protocols.

Oh, OK.

But yeah.

All right.

That sounds interesting.

Unix Networking Programming.

There's probably contemporary versions of it.

Low level stuff.

What else?

What other books in your career have been an influential for you?

So the second one I wanted to talk about is a book called Software Architecture and Practice.

This book has been interesting enough to me that I have actually bought two editions of it.

So I bought the original edition back in the '90s and a few years ago I bought the most recent edition because things have changed a bit in 20 years.

So there's a couple of ideas in this book that were sort of foundational for me and that have run through my career since then.

So let me set the stage a little bit.

Back when I was looking at this, this was pre-internet days, early '90s or mid '90s.

And the worldwide web was around, but it wasn't too common yet.

And there weren't a lot of guidelines about building applications.

And so I would have been probably building enterprise stuff back in those days.

And the big talk back in those days was "Enter Architectures."

"Enter."

Can I get you to pause for a second?

So when I think Software Architecture now, if I were going to read a book about Software Architecture now, I would imagine it would talk about system design, probably microservices versus Model-List, probably domain-driven design, stuff like that.

But you're talking pre-internet.

So what is the software architecture in practice?

What is this book about pre-internet?

Well, the first versions that were pre-internet, all the same ideas are there.

It's just that the network was not nearly as much of a factor at that point in time.

It was in play then.

And they talk about client server architectures in here.

But there's a couple of ideas from this book that were important to me and I think are still pretty valid.

And one is that Software Architecture is not really about the structure.

So the boxes and arrows type of thing is not where you start.

The starting point is what are you trying to achieve?

And they use this term quality attributes in the book.

And so those can be things like I need it to be low latency or I need it to be maintainable or I need it to be high security or high availability.

And so these are things that you want to achieve by using certain types of architecture.

So this was kind of a really-- I don't know why it was, but it was kind of a epiphany for me that you should start thinking about systems in terms of what you want to achieve with them rather than starting off with what you think the structure should be.

Oh, I guess I can't remember a time before I thought that.

Maybe I've just been hanging out with you too long.

Yeah, like I said, it doesn't seem like it should be something that you should have to learn.

But for me, it was kind of a revelation because at the time my thought process was, does this need to be end tier?

Do I need to-- do I need to have a data layer for this?

And so I was kind of floundering trying to figure out what the structure of systems should be.

And then this book introduced me to the idea that, well, the structure should be something that achieves the qualities that you're trying to achieve.

And that was a very focusing idea for me.

It sort of took the burden off figuring out specifically how you should break things up and more on terms of, if I break things up in this way, is it going to achieve this thing that I'm trying to achieve?

Hmm.

That's interesting that we say that.

I don't remember learning that.

I must have at some point.

I don't remember learning that.

The other thing that this book taught me, which I still have mixed feelings about, I believe that it's definitely true.

It's just not something that makes me super happy, which is they talk about architecture being a process of building consensus among the stakeholders.

You don't have to do that.

You build it, and then they come because they're like, oh, cool, you solved that problem, right?

Yeah, that's kind of my attitude, or was my attitude.

But they talk about how there's a lot of different people involved in building a system, not just the engineers and the architects, but also the end users and the people who are paying for it and the people who are worried about the security of the data and all those sorts of things.

And there may be trade-offs between finding something that all of those people are happy with.

And I think that's an important idea in architecture, which is sort of fundamentally non-technical.

Building consensus.

Yeah.

Unfortunately, I'm not good at that part because it involves people, and people are not my strong point.

But-- I'm pretty good at that part.

You are.

Yes.

I could tell you about some of the books I read that were influential for me.

I had to look this up because I remember this book being over 1,000 pages.

Probably in 2004, I started getting really interested in Linux.

And the reason I got interested in Linux is I complained to my brother-in-law.

You know how every time you go to put a file in the recycling bin on Windows, and it says, are you sure?

It really pisses me off.

And what he said was, I think you would like Linux.

It won't ask you if you're sure.

And I was like, really?

Every time I go into the application folder, it says, oh, there's dangerous stuff in here.

Are you sure?

That makes me so mad.

And he was like, yeah, you need to try Linux.

I was like, all right.

So I started getting into Linux, and I was like, oh my god, this is amazing.

All this stuff is free, and there's so much of it.

And it's so cool.

So I started getting shell scripting, and I really wanted to know more.

So I bought this book.

It was called A Practical Guide to Linux Commands, Editors, and Shell Programming.

It's over 1,000 pages.

I looked it up.

It was over 1,200 pages long.

And it had a massive section on Auc, and a section on sed, and a section on Emacs.

And I had already used Emacs in college.

And Vim, I loved this book.

I thumbed it.

I learned so many things from every foundational piece about Linux that I learned started in this book.

I learned much more later on, of course.

But that was related to Bedrock for me.

I loved this book.

It was really a reference book.

It was like a textbook.

I gave mine away.

I kind of almost wish I still have it, but very good book.

Yeah, I definitely wish I had had that book in 1987.

This would have been early 2000.

It's probably 2004, I think.

And then the next book I read-- so I started writing shell scripts.

And someone who I knew who was a sysad man said, oh, you should learn regexes, and you should learn pearls.

So I bought the Pearl book, and I bought mastering regular expressions.

The Pearl book just-- I couldn't just read it.

I didn't know at the time that to learn to write a language like Pearl, you have to actually try to write it and fail and write more.

I just tried to read the book and understand it.

That didn't work.

So I failed completely.

But the regexes book really worked for me.

And the funny thing about regexes is I would go to-- when I became a software engineer, I would go to all these jobs, and I would think, OK, here's the regexes.

And I would write regexes.

And I just assumed everybody knows regexes.

I assumed it was a foundational programming 101 skill.

And then later on, I worked for someone who had a PhD in computer science.

And I remember making a comment like, oh, well, we should just use the regex here, or we can modify this one.

And he looked at me.

We were friendly.

And he finally said, I'm a little embarrassed to admit, I actually don't know regexes.

And I was like, what?

I thought everybody knew regex.

I thought that was just a thing like you learned this to walk in the door.

Yeah, I thought of that as being a very computer sciencey thing, too.

So I guess I'm surprised a PhD would not have familiarity with that.

Yeah, I think his PhD was in security.

But I don't know.

He was embarrassed about it.

He was embarrassed about not knowing regexes.

And since then, I have not used regexes as much.

But it was a pretty foundational-- I don't know why it really sunk in that I could use this convenient expression language to find patterns that really made sense.

I think the first two programming books I've read that I really, really liked that really made sense to me was I had started learning-- I had done some JavaScript before, never really learned it.

And I had really started teaching myself Python pretty thoroughly and doing a lot of programming in Python.

And I read two books.

One was JavaScript, the Good Parts by Douglas Crockford.

And the other one was the NLTK book, Natural Language Processing with Python.

Because my background was literature and philosophy.

And I started getting into Linux as a hobby.

And then I started getting into Python programming as a hobby.

I started doing a lot of Python programming because it was super fun.

I would spend hours every day writing programs.

And then I found Natural Language Progressing with Python.

I was like, wow, I can analyze books with my Python programs?

It's amazing.

But I think probably Crockford's the JavaScript of Good Parts is a book that I will keep because it's a pithy, interesting book written by a guy who has a lot of love and disdain for the language he's talking about.

Here's this really funny line in there where he's like, this is a book about the good parts of JavaScript.

And as a result, it's a very short book.

[LAUGHTER] He says, I love this language.

It taught me a lot.

But there's a lot of stuff I hate about it.

It's a really interesting, opinionated book.

That's the first book where I ever saw those railroad diagrams.

So look at Programming Language Grammar.

Or what do they call it?

Train diagrams?

Is that what they call those?

Yeah, I'm not sure.

I think I know them as Backus Nour.

Backus Nour.

Yeah, that's the official term, right?

But they're like, informally, are called railroad diagrams or something for parsing programming languages.

It's interesting.

I think the only programming book that I've ever dug in too deeply is probably Kernhenn and Richie.

Yeah, so that was the next book that I read.

Tell me what you-- when did you read that, and why did you like it?

I had it in college.

So it would have been mid-80s.

It was the first-- C was the first high-level programming language that I learned.

And-- [LAUGHTER] Sorry.

So-- High-level makes me laugh.

Well, so when I started programming, well, the first programs I wrote were in high school, and they were in basic, which was pretty standard on most of the microcomputers at the time.

But when I was 18, 19, and trying to do things more seriously, I started writing assembly language because I couldn't afford anything better.

At the time, if you-- there wasn't a C compiler that you could go by.

I think Microsoft started making a C compiler around that time, but I think it was $700 or $800, which for me-- It's GCC wasn't around.

Yeah, at the time, that was like a semester of tuition for me.

So that wasn't really an option.

So I was writing mostly assembly language before that, and then I got hooked up with a C compiler by a classmate of mine.

And I bought Kernhunt and Richie.

I think I bought a used copy and just really dug into it deeply.

And C was kind of like-- it was like the scene in Harry Potter where Hagrid comes and tells Harry that he's actually a wizard.

He's going to go to Hogwarts.

It was like I discovered this magical text, and I now had superpowers.

And so it's a pretty formative experience for me back at that point in time.

And I definitely wore that book out.

In fact, I don't think I even have it anymore because it literally came apart.

I'm going to give it my way.

I liked K&R.

The funny thing for me about K&R is I'd been programming Python for two, three years, maybe four years.

And I'd been doing it on the side.

And then I got a job writing Python.

And at first I was like, wow, people are going to pay me to write this language?

It sounds so fun.

It's like somebody asked me for a job.

Hey, how's it going?

And I was like, this is my first full-time software development job.

I said, it's like if you went home and play with Legos all day, and then one day you got a job and somebody invited you in, and they dumped this massive box of Legos on your desk and said, hey, can you play with ours for a while?

The problem with Python, I felt at the time was I felt like I was not a serious developer or a real developer.

Because I thought-- and I don't think this now-- but I thought that Python was too easy.

It's way too easy to build stuff in Python.

A serious developer would know C or a harder language, like a serious language.

And so I bought KNR, and I started reading KNR.

And I really liked KNR.

But I did not enjoy writing code in C.

It was so much more fun to write Python.

The only thing that I really got out of KNR-- the thing I like about KNR is it's a small language, C.

You can learn pretty quickly all the core elements of the language.

Reading KNR motivated me to actually go back to Python and read the source for C Python, which was hugely instructive.

But I never really wrote anything in C.

I really have a lot of respect for KNR.

And then I thought, OK, well, I'm still not a serious programmer because I don't write C.

I could passively read it now, maybe.

I need to find a programming language that will make me a serious software engineer.

And I had read somewhere that Haskell was the hardest programming language you could write.

And so I thought, oh, I should learn that.

It sounds hard.

It sounds like if I were a serious engineer, I would learn Haskell.

So I started learning Haskell.

And I was like, oh, this is too hard.

I don't want to learn.

This is frustrating.

And I stopped because it was like self-flagellation exercise or something.

I had the wrong motivation, obviously, for learning it.

But I had gotten enough of a taste with Haskell that once I-- I was like, I'm not going to do this language.

I'm not going to use this language.

I stopped programming in it for a few months.

And there were these weird ideas that kept trickling back into my brain like a bubble up through the muck.

Like, whoa, what is that idea?

Fungtor, monoid.

And I was like, ah, there's some weird stuff in there.

And I was sort of organically, magnetically sucked back.

I just had to understand a little.

It was no longer about I want to be a serious-- but I just wanted to know what was going on in Haskell.

And I bought a book called An Introduction to Functional Programming Through Lambda Calculus.

This is one of my favorite software books.

If you could even call it a software book, it's by Greg Michelson.

I probably read this around 2014, 2015.

And I still find it puzzling because you look at Lambda Calculus.

You could write it with a pen and paper.

And it's still like there's a leap of faith you take when you go, OK, we will-- this is an executable program.

I learned a hell of a lot from that book.

Building a functional programming language kind of just through Lambda Calculus expressions.

It just was a huge puzzle.

I found it totally fascinating and mind-bending and erratically completely changed how I thought-- what I thought programming is.

Yeah, I have not-- when I started learning Haskell, I think I went immediately to learn you a Haskell, which was online.

So I never did buy a Haskell book.

I have a couple of them now, but they're on specific topics like concurrency and data science and stuff like that.

An introduction of functional programming through Lambda Calculus actually doesn't even talk about Haskell.

Just builds up this Lambda Calculus.

And after I read that book, when I went back to Haskell, it was kind of like that moment in the matrix where I could see the things behind reality, the green, the code.

It was like, oh, it makes so much sense now.

I could see the universe happening.

Everything made so much sense after I read that book.

Have you gone through structure and interpretation of computer programs?

I never have.

This is a kind of embarrassment, maybe not embarrassment, but I know people recommend it.

I've started it.

I've tried to hack bits of it.

I never have fully gone through it.

I just wondered how it compared.

Yeah, I don't know.

There's some other books that I read that were meaningful to me in the years after those.

I read Kubernetes up and running when it was first published, and I really liked it.

I was like-- I read the first edition of that right after they published it, so probably 2017, 2018 maybe.

I read a book called Building Microservices, which is a book people cite now.

It's a pretty good book, Sam Newman.

I think the two books in terms of system design that really meant a lot to me were Enterprise Integration Patterns.

And I didn't actually read the entirety of Enterprise Integration Patterns, but this is where I first encountered messaging patterns, like point to point and Pub/Sub.

And I had heard Pub/Sub, but it was like suddenly somebody gave me a definition that I could really-- like a real definition of these things, and I could really grasp and use and think about all these different patterns for systems communicating.

And then finally, designing data intensive applications, which is one of those books that virtually any software engineer working in a system design should read by Martin Kleppmann.

That's a great book.

Yeah, those last two, I definitely agree with you on.

I think by the time that the Enterprise Patterns book came out, I had already been exposed to that stuff quite a bit.

So it probably was less practical for me, but it's still a good reference.

The data intensive applications book is definitely something that people should-- I've learned stuff from it even secondhand.

Yeah, it's a good book, really legitimately good book.

One other book that I feel like I have to mention, even though it's kind of a historical artifact at this point in time.

In the early part of my career, I was really into computer graphics.

And I thought that might be my career focus.

It became pretty apparent even at the time in the early '90s that this was something that was kind of moving to hardware, and there probably wasn't going to be a lot of low-level graphics programming in the future.

So kind of-- You're talking graphics cards.

Like, you knew the graphics card was going to be a thing?

Yeah, I mean, even at the time.

So I had access to silicon graphics machines.

And they had primitives where you could rotate and translate things, and you didn't have to think about the linear algebra of it.

I had been to the lab at North Carolina Chapel Hill, where Fred Brooks was the head of the department.

And they had the time of working on this thing called Pixel Blanes, which was sort of a precursor to the GPUs that are common now.

But-- OK.

Anyway, the book is-- at the time, it was called Fundamentals of Interactive Computer Graphics.

But it was universally called "Fully in Van Damme."

I've never heard of that.

I've heard of the Dragon Book.

Yeah, it's kind of like the Dragon Book, where people don't know the title, but they have a-- in the case of the Dragon Book, they know it's on the cover.

With "Fully in Van Damme," I never heard anybody call it by the title.

It was just "Fully in Van Damme."

And I think there's newer versions of it.

So it's still like a fairly current book.

But back in the day, it was sort of the Bible of computer graphics.

And people would say, hey, have you seen my "Fully in Van Damme?"

And that's in chapter three of "Fully in Van Damme."

Anyway, it was sort of the "Computer Graphics" book.

And I still have my early '90s copy of it.

And it still has all of the yellow sticky notes in it.

You still got sticky notes in your '90s copy.

Yeah, it's probably a dozen or so sticky notes still in there of places that I refer to quite frequently.

So yeah, even though it's not really a thing that as much anymore, it was a very important book to me.

And I hope that people remember it in some way in the future.

"Fully in Van Damme."

There's probably two other books that I would reference as, if somebody said, oh, coding, software, industry, and software engineering books.

One would be the SRE book, the Google SRE book.

I read that.

I've read bits of it multiple times over the years.

And the thing I find about that book is I go back to it when I want to demonstrate to someone, OK, there's a reason why these systems are the way they are.

And here's a reference that you can use.

You can see they had this practice.

And they came up with this practice for this reason.

And here's what they're trying to achieve.

I think the SRE book is worth reading.

But the last one I would tell you about is one of the most fun books I've ever read.

It's called "Mazes for Programmers."

It's by James Buck.

It's chapter after chapter of writing and modifying and making fancy mazes for building mazes in code.

All the examples are in Ruby.

It's a super fun book.

I love this book.

And I like to make mazes with my son and print them out.

And he'll put monsters in them and be like, oh, you've got to go this way.

But you've got to fight this monster here.

This book is absolutely phenomenal fun.

And if you want to just write code and have-- not for work, but just enjoy yourself, have a good time, I would recommend "Mazes for Programmers" by James Buck.

That's an excellent computer science project to build mazes and maze solvers.

He does talk about Dijkstra and shortest path in there.

I would, in terms of fun books, one that I would mention.

And this is for maybe a slightly different definition of fun.

But several years ago for Christmas, one of my sons gave me this book, "Hackers Delight."

Oh.

And it's sort of the ultimate Bit Twiddler's book.

Bit Twiddler.

It's, roughly speaking, a book about computer math at sort of the bit level.

And it's definitely a good learning experience and a fairly practical book, but also just a fun thing to sort of pick up and read through and learn new things.

Computer math at the bit level.

Are we talking adders, binary adders, half adders, stuff like that?

Or am I going too far down or not far enough down?

Yeah.

I mean, it's everything from basic arithmetic to floating point to things like cyclic, recidendent, G checks.

And there's even some relatively sophisticated algorithms in there.

Huh.

That might be one I might want to borrow from you someday.

If you ever want to know how to compute a square root in a floating point square root at the bit level.

Maybe I do.

Maybe I do want to know that.

I find that when I have access to O'Reilly online and there'll be a PDF of a book, I can't stay focused on it.

I really want a printed thing to hold in my hands.

But the fundamental conflict for me with software and just sort of technical stuff that's printed, it is nice to have it printed.

But I need to have a computer next to me.

And I need to go back and actually type the things.

So I like books now, a book like "Mages for Programmers," where it's-- or writing an interpreter.

Is here, write this chunk, test it.

Oh, cool.

You built a little thing.

And this is foundational to a body of knowledge that we're building in the book.

I guess as I'm summing up here, I feel like I'm not going to be reading a lot of books in the future about software and technical stuff.

And that's maybe a shame.

Yeah, I think the era of books, practical books about specific technologies, is probably over.

I think people still are producing them.

I mean, they still come out with the animal books, right?

Yeah, really?

Yeah, so I mean, it's still a thing.

Yeah, I'm kind of the same as you.

If I buy a book at this point in time, it's probably going to be on something relatively abstract.

Like we didn't mention it, but "Petzold's Annotated Touring" is another good-- it's a tough read, but it's a good book to read.

But it's not going to teach you anything about how to write Rust code or build systems.

It's just explaining Turing's famous machine, where he introduces the Turing machine.

I should probably go back and buy another copy of "Programming Pearl," because I never successfully got through it.

I bet I could learn "Pearl" now.

I bet I could.

You can borrow my copy.

Do you want?

Oh, I probably will.

All right, this has been fun talking about books.

We will put some notes here together.

If anybody wants to look up any of the books we talked about.

Thanks, Mike, for the topic.

Hope you have a nice weekend.

And I will see you again.

This has been "Picture Recoding" with Erik Aker and Mike Mull.

See you next time.

Bye-bye.

Bye.

[MUSIC PLAYING]