Algorithms + Data Structures = Programs - Episode 194: The One Thing Every Programmer Should Know with Kevlin Henney

Episode Date: August 9, 2024

In this episode, Conor and Bryce chat with Kevlin Henney about the top recommendation from 97 Things Every Programmer Should Know.Link to Episode 194 on WebsiteDiscuss this episode, leave a comment, or ask a question (on GitHub)TwitterADSP: The PodcastConor HoekstraBryce Adelstein LelbachAbout the GuestKevlin Henney is an independent consultant, speaker, writer and trainer. His software development interests are in programming, practice and people. He has been a columnist for various magazines and websites. He is the co-author of A Pattern Language for Distributed Computing and On Patterns and Pattern Languages, two volumes in the Pattern-Oriented Software Architecture series, and editor of 97 Things Every Programmer Should Know and co-editor of 97 Things Every Java Programmer Should Know.Show NotesDate Recorded: 2024-07-11Date Released: 2024-08-0997 Things Every Programmer Should Know (GitHub)97 Things Every Programmer Should KnowPattern-Oriented Software Architecture: A Pattern Language for Distributed Computing, 4th VolumePattern Oriented Software Architecture Volume 5: On Patterns and Pattern LanguagesEffective C++ Series by Scott MeyersBeautiful C++: 30 Core Guidelines for Writing Clean, Safe, and Fast CodeIntro Song InfoMiss You by Sarah Jansen https://soundcloud.com/sarahjansenmusicCreative Commons — Attribution 3.0 Unported — CC BY 3.0Free Download / Stream: http://bit.ly/l-miss-youMusic promoted by Audio Library https://youtu.be/iYYxnasvfx8

My 1890s French carriage clock. Welcome to ADSP The Podcast, Episode 194, recorded on July 11, 2024. My name is Connor, and today with my co-host Bryce, we finish our five-part conversation with Kevlin Henney and chat about the one thing every programmer should know. One final and important question for, I suppose, both of you could answer. And it's a very Bryce question, which is you, Kevlin, have written a book, 97 Things Every Programmer Should Know. But as listeners of this podcast will know i bryce don't have time for such things so can you tell me what is the one thing that every programmer

ah right so i took a minor correction i didn't write it i edited it i ran the product i kind of got everybody i contributed a few items that i wrote but therefore it is a crowdsourced and open source book. So yes, it actually is under creative commons license. That was intentional on my part. So you can actually find a few versions kicking around online every now and then I get, yeah, you're not allowed to have the PDF of the book, but the original entries were originally available on a wiki. And so I've had people, people have scraped this and put this into Git books and GitHub in various places. So you don't have to buy the book. You can find the items online if you wish. And that's perfectly okay. The reason I'm saying it's perfectly okay is because occasionally I get an email from somebody saying, hey, guess what? Did you know

somebody's ripped off your book? And no, it's intentional. Creative comms license, that's absolutely fine. They can't rip off the PDF. That's kind of differently copyrighted. But the individual items, absolutely. They're under creative commons. Now, why am I telling you all of this, Bob? That so that we don't inspire more emails to me that aren't necessary,

but also to allow people to do this if they don't want to part dollars. But more importantly, there are lots of contributors to that book. So I've got an opt-out of this question that you've just asked because I'm not going to pick favorites. There are 73 contributors to that book. I'm not going to pick one because that's unfair on the other 72. So I've got a get-out clause here that Connor doesn't have.

Ah. Ah. Yes. So Connor, what is the one thing that every programmer should know? I mean, I just went and found the git thing because I'm trying to find the one of the five because I'm pretty sure that one of the things in the 97 things is it quotes i'm not going to remember the name of the book because the original quote comes from another

book and i've mentioned this in talks before but basically like i think potentially it's learn foreign languages yes but i've gone to that there's languages that one if i remember um correctly is klaus markfart there is another one no more than one language well if i remember correctly um more no more than two no well more than two programming languages um that was russell winder so but wait wait kevin so i may have to revoke you out. And the reason is these things are numbered, which means that somebody had to pick which one was going to be number one. Ah, right. They are, strictly speaking, the original book, they are not numbered.

They are numbered in the electronic copies. Ah. But if you look at the titles, you will understand how I ordered it. Is it alphabetical? It is alphabetical. Ah. But if you look at the titles, you will understand how I ordered it. Is it alphabetical? It is alphabetical. Ah. Because I thought I can't play favorites. But also, if you try and group things by topic.

It's very hard to group things. Yeah. You often find one, you find a piece and it's actually under two good. You can file it under equally well under two different... Categorizing stuff... As somebody who's in the role of being a software architect, taking ideas and concepts and

categorizing them is like one of the... It's like a big part of the job and it's also one of the hardest things. Exactly, yeah. And I chose... So it's interesting how other 97 Things books in that series have chosen to do it. The original 97 Things Every Software Architect Should Know had the most arbitrary order. So I was originally part of the group.

I could kind of make sense of it. But when it was published, it was the order in which they were submitted. Now, that is utterly meaningless to anybody reading the book. I mean, you don't know what order they were submitted. Why is that useful so it meant that sometimes you know that you'd end up with topics that you could you'd say well why is this person has submitted two items why are they next to each other and then this other person who submitted two items their items are like 50 pages apart well that's literally the timeline um there was another i guess one could argue that the people who had their shit the most together probably submitted early. And so at the very least, those were the ones that had the most urgency and the people who were best at getting it done on a deadline. So that's not a terrible mechanism. That's a very positive way of framing it. On the other hand, maybe they just got something done and they didn't let something gestate and mature over time.

So maybe the ones at the back of the book are better because people were more deliberate about them and they'd let the ideas sit with them for longer. Yeah, I mean, both of these lines of argument work. I do like the first one, which is Act with Prudence. Yeah, by Severus. I think that's a good one, I think. Yeah. It's kind of interesting is that alphabetically that one, you know, that's obviously first, but also actually it's quite a good opening to the book.

Yeah, it is. I was delighted by the coincidence because obviously reverse order was also an option. But I decided up front there's no rational way of organizing 97 things when you don't delighted by the coincidence because obviously reverse order was also an option but i decided up front there's no rational way of organizing 97 things when you don't know what 97 things you're going to get i tried putting categories on them but i already knew it was a it's a library problem in the sense of like there's no natural structure here if i'm creating a book from scratch and i solicit individual items explicitly i can say we want, this, this is my vision for the book. But this is very much an emergent architecture

where I got, you know, I got nearly 200 submissions. It was around 100, it was around towards 170. And what you've got to do is kind of say, here's what I've got, what can I make with it? You know, it's, you know, it's go to the fridge and I don't know what happened with your fridge there, Bryce, but, you know, I don't know what the narrative is with the know it's it's go to the fridge and i don't know what happened with your fridge there bryce but you know i don't know what the narrative is with the fridge but it's go to your fridge and i go to the fridge i'm hungry go to the fridge i need to make a meal what have i got so you in other words something emerges from that without necessarily saying i am planning

to make this meal so i chose alphabet and i did that in the other 97 things book as well it's the alphabetical is the only rational way to allow people to find things all other approaches are arbitrary let me tell you the other arbitrary approach that was used uh one of the other arbitrary approaches that was used was for 97 things every project manager should know that was interesting because i was looking at it going like i can't see any sense to the ordering of these the editor of that book decided that the ordering of the book should alternate u.s contributors from non-u.s contributors or u.s based contributors from non-u.s based contributors honestly that's almost as good as random number generation i think that's a good that's a good approach because it accounts for some of the um bias of a lot of tech is very

US centric and based in the US. But the point is that if half your items are US and half them are not, there isn't actually, I would say there isn't a, why? Yeah. If I read the first one, US author, second one, non-US author, that's not a useful criteria for finding that item again. Yes. Yes know I would I would agree yeah so the question of representation is certainly an important one and is definitely something I dealt with I tried dealing with it with moderate success on the first book but not

as much as we managed on the second one but it's the idea of like this is how we're going to order the items it's just like that's not useful i don't know if this author is us or not um and you know i can't tell um you know you know that's not helpful to me i can't so i i structured it um and i intentionally put in a reverse look up as well at the back of the book. So you might remember, oh, I remember the thing was written by so-and-so, you know, by this person. Let me – I can remember the name, but I can't remember the title. So I did it alphabetical by name. Are any anonymous or under pseudonyms?

There's one that is a pseudonym. Okay. Yeah. And how did you pick, why 97? This is a good question. It wasn't me that originally picked it. As I mentioned, it emerged, it got created out of a separate discussion, a separate list. It's a list that bruce eckel maintains so uh some listeners may may be faintly aware of bruce eckel he wrote thinking in c++ and he actually made that the that book freely available um so decades ago very very influential approach to making um the stuff

available but also quite a deep and thorough book at the time um for anybody who was trying to get into c++ uh And this is on Bruce Eccles' list. And a guy called Richard Monson-Hayford, he originally wanted to, he said, I've submitted a talk. I think it was 10 things every software architect should know. I've submitted a talk to a conference. Now I've got the title and they've accepted the talk. I need 10 things. What do you guys think? So everybody started chipping in these ideas. And after about 30 suggestions, he said, you know what, there might be something here for a book. And that was the order. But then he said, okay, how many should we have? And he said, I 100 is a slightly cheesy number. And he says, 99 and 101 are numbers that are trying too hard to not be 100. They're too obvious. And he said, 97, it doesn't look like it's trying to be 100, but it's its own thing. And that really is it. That is the only reason for it.

Good for SEO, right? If you search like like like i'm sure there's a bazillion listicles of 99 things programmers should know or 100 things or 101 things but 97 that that's yeah it's for those that care it's a strong prime although you'd never use it in cryptography but it is 97 it's a strong prime but it is it is distinct you know it's seo friendly um the reason 100 works is he wanted about two pages. So 200 page book, that's actually quite nice. It doesn't give you depth on each item. But one of the things I really liked about it

and why I ended up really pushing the program book was I thought this is really useful because it's helpful to start conversations. It's the starting point. You read something, you can read it in a break. You can read it in a break you can look at it and go hmm i want to know more or this has already influenced the way i'm thinking oh i see what they're saying and it's just enough to get you going sometimes it's enough to just change the way that you approach the problem or to present something new to that you perhaps hadn't considered before but it's not a whole you know you're not committing

um you know an hour or a day of your time to it but it'll it gives you just, but it's not a whole, you know, you're not committing, you know, an hour or a day of your time to it, but it gives you just enough. But it's also quite good for book bombing. And I know a couple of people who did that. It's just like, send this to a friend, send it to a friend and make sure you put a post-it on the page that you wanted them to see, you know. So the physical form of book bombing is quite useful. A subtle hint, sometimes when you have a a disagreement with a colleague about um a particular practice yeah just leave that book on there uh on their on their table with a little post-it there so i mean i'm not you know the weaponization of 97 things has been interesting but uh but yeah uh so that that that was that and that's the the

rationale for a lot of these things so so you i mean i i'm very impressed here because i always like to work smart and not uh hard and you've been able to write a book without having to write 97 things yourself by being a curator of things and that is that is uh that is very very commendable that's yeah that's uh i i think i think there is that there is an interesting thing because i actually really enjoyed the whole process of doing the editing because it allowed but actually the other motivation and why i was happy to do it was really into doing another book so i actually really enjoyed it was when you read across what other people do although sometimes you say yeah i know that i don't know it the way you know it i don't know the way that person knows

it and i wouldn't have written it like that and And the way they've written it is fresh. If you read across the 97 things, and Connor has, you look at some of them, they're real gems. And the point is, they're not the variety of style and the differences of approaches. You go, oh, okay, that's really interesting. You're not going to get bored. A single author has control over the narrative. Okay. There's value in that. You want want that consistency but when you're trying to take on you know something as complex software development you probably want to do this by sampling you know i want different points of view i want uh i want to be surprised by stuff and i was surprised by both books and in fact by some of the other books where i'm looking at it

going like i kind of knew that but i didn't know it the way they do it and i wouldn't't have said it that way, but I like the way they say it. That's fresh. It makes me think of different things. And that I think is quite valuable. But yeah, you're right. Ultimately. How much did you have to edit to get to like a consistent language or to get to consistent, like, is it very lightly edited or is it more like you had to draft things a little bit and reshape things a bit i uh it depended it depended on the it depended on the contribution i mean sometimes and actually that was another thing i explicitly although i don't know if this was richard monson haefel's original intention but i explicitly made a point when i was um you know when people would contact me i'd sort of talk about this at conferences and say you know let me know if you're interested in

contributing i mean i contacted a few people saying hey would you be interested in contributing but actually a lot actually came uh from people i don't know um uh just because i advertised it on twitter at the time and stuff like that and i made a real point about saying on the landing page it was done through a wiki i made a point on the landing page, it was done through a wiki. I made a point on the landing page. It's just like, if you're not comfortable with writing, perhaps English isn't your first language, don't worry. You're talking about 500 pages. I can do the editing. If you're worried about language, I want your enthusiasm and your knowledge.

Give me the story and I can shape it. So sometimes I'm getting stuff and I'm having to do a lot of syntactic level work or phrasing and voice stuff. And I always did that one-to-one via email, obviously, but one-to-one with the author. And I put a lot of effort in. So I would say there was a lot of effort involved in the writing because I wanted to have a proper consent

and agreement and to give, you know, just say, is this okay with you? And so on. Whereas for other people, there's a couple in there, I didn't even move a comma. It's just like, it's just like, I don't want to touch this. This is so good as it is, or actually that captures their voice perfectly. So it varied. But overall, the whole set is I edited all the items before I selected. So I edited nearly 200 items as they came in. And so I'd be doing something. That's how many submissions you got? Yeah, it's 170 submissions, around 170.

And so I was editing everything pretty much as it came in. I created a proper workflow for myself. And so there was a continuous amount, you know, in a given week or on a given day. I would always be devoting a certain amount of time to it. And so there was certainly an effort there. But I found that but ultimately I found that easier than than writing. I mean, I've written a couple of books myself and it's just like, I don't know, it's it works differently for different people. But all I will say is that my wife told me after 97 things, she said,

Kevin, you're a lot more pleasant when you're editing a book than when you're writing one. As a human being to live with, okay, I get that. So, yeah, I can see that it's funny because despite my despite my my joke earlier um i actually can imagine that uh having to be an editor for 97 different was it 97 unique individuals that submitted no 73 unique individuals okay yeah having to be having. Having to interact with and work with 73 different people, some of whom you had to go back and forth with edits on and you had to make sure you got everybody's sign off and everything. Most of whom I don't know. So that's the other thing. This actually sounds like a good bit of work, a different type of work. I guess maybe the nice thing

about this versus writing a book on your own is if you're writing a book on your own, you have to push the work out. Whereas if you're an editor in this sense, you have all this stuff coming in. You have to keep up with it, but you don't end up in that writer's block mode. Yeah's block mode yeah i i mean although i guess i'm listed as the editor i would call myself the the project driver because it was kind of like i really kind of pushed this one

because i've noticed that a couple of the other editors in the series they're very very passive in other words they say i'm going to be the editor and then they expect the publisher to go out and do this and i said no no this is my baby i'm gonna i want you know this is going to be the editor and then they expect the publisher to go out and do this. And I said, no, no, no, this is my baby. I'm going to I want you know, this is going to be social media, the whole thing. I'm interested. I'm genuinely interested in what people have to offer here. So I'm going to drive this project. And it is, you know, as you say, it's got a different enjoyment, but it's got a steady state to it. And that's what I appreciated.

But I think there's also an irony. After I finished, I co-authored two pattern books with Frank Bushman and Doug Schmidt. And Frank Bushman made the point, and I suddenly realized all the stuff I've done is contributing to other people's books or stuff like that in the past or co-authoring. And he told me, Kevlin, having worked with you, I don't think you're ever going to write a book on your own because I used to write columns and a column has a deadline. If you're writing for a magazine or a website, you have a deadline and I can work to a deadline. So this is ADHD brain. Okay. I can work to a deadline. You give me a deadline and it's meaningful. Oh, I can do that. If you've got something really abstract and there's a whole book, I find that very difficult. And if I'm working with other authors, actually, that's a collaboration. It's like, this is all like developing software. You know, this is all feels like you're working with colleagues and they're driving you, you're driving them, hopefully not mad, but you know,

there's all of this. So that was the funny thing. Frank said, I don't think you're going to write a book on your own. So what did I do? i went out and found 73 people and uh or rather ultimately it was 100 people who contributed so ultimately i proved frank right by going the opposite end rather than having a book of one i had a i had 100 uh contributors all told so the opposite end of the scale oh yeah right so uh the other books you've written was uh it's the two pattern oriented ones right yeah yeah those are the ones that my name appears is that i've edited a couple of other things and contributed to a couple of other things where i'm not necessarily directly credited why didn't o'reilly want to do uh 97 things that every c++ programmer should know

i don't know yeah yeah that was uh peter somerland approached them um so i don't know. Yeah, yeah. That was Peter Sommelad approached them. So I don't know the conversation he had. I think he did that around 2020, 2021. Oh, yeah. You know what? I recall him. I think he emailed me about that. Yeah, yeah.

I think it would be, I think it's a mistake not to do that because you've got an active language community you can look at any programming language um uh you know top 10 um and uh yeah yeah connor knows this you'll get into it and you'll see c++ isn't there you know it's a point is that this is this has a large pool not simply of contributors but people who would be interested um and it kind of ties back to what we were talking about, normalizing culture, voices. We have a lot of good C++. We have a lot of good people individually who are good at this, who have individually produced good books and good resources online. We tend to associate that with them. We're also very familiar with the idea of open source development in the software. The point is that a project like this brings the two together. It gives you a cross section.

It gives you a variety of thoughts. And importantly, I think that's important because not everybody's going to agree with each other. I actually had a couple of emails in the past where people have emailed me and said, Kevin, you're the editor. How did you put together two pieces here that contradict each other? And I said, well, that's for you to figure out. I'm saying I don't have the answer or rather, I might believe I have the answer, but I'm respecting your intelligence and the fact that

there are two points of view on this and I'm going to show you both. And I want to present where there is contention or diversity on this view. You should be the person who makes the choice. I'm going to present you with both of those. It's not a done deal. There isn't the one true way. These are not the 97 things in one unified, mandated way. These are a selection that happens to be 97 from a variety of people who overlap, but in some cases contradict. And we leave it to the reader to do that.

And I think in the C++ space, that's also important. Imagine having 97 practices that are from top level to low level, that are across your tool chain into the detail of the language, that are about how you relate to your colleagues, as well as how you relate to your code, that talk about legacy, but also talk about new code, that talk about testing, but talk about pill pipeline, a book that really just samples the whole space 97 things and a whole lot of different people contributing i think that'd be really interesting because you're then getting a sense of oh this is the c++ world and i think that is true for pretty much any language and it is a value there so i think you know i yeah i find there's value in the project, but I'm not a publisher. Well, I think it sounds like it would have been a good book.

I like the C++ books that I do like that I've talked about on this podcast before, ones that are a collection of, you know, like the beautiful code or the effective C++, where it's like I don't have to read through a whole thing. It's like a list of little snippets that I can consume. You can dip in, you get a point of view you learn you walk away having thought about something um and you know i think that that's i think that's the real value but also the fact that you you're not just getting one voice i think that's really important all right well we probably ought to uh wrap up because my uh my 1890s french carriage clock

the ac slash fridge tobaccos. Oh, uh-oh. It looks like it's, uh, maybe I'm losing internet now. It does look that. Yeah, it's actually a great screen. Your screen is frozen. It's fantastic. It's like you're having a 90s

rave moment. Anyways, that may be a sign that it's time for us to wrap up. The universe is speaking. Be sure to check these show notes, either in your podcast app or at ADSPThePodcast.com for us to wrap up. The universe is speaking. Be sure to check these show notes, either in your podcast app or at ADSP, the podcast.com for links to anything we mentioned in today's episode, as well as a link to a get up discussion where you can leave thoughts,

comments, and questions. Thanks for listening. We hope you enjoyed and have a great day. Low quality, high quantity. That is the tagline of our podcast. It's not the tagline.

Our tagline is chaos with sprinkles of information.