Bryce

My 1890s French carriage clock.

Conor

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 Kevin Henney and chat about the one thing every programmer should know.

Bryce

One final and important question for I suppose both of you could answer. And it's a very Bryce question, which is you, Kevin, 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 can be?

Kevlin Henney

Ah, right. So I've just a minor correction. I didn't write it. I edited it. I ran the project. I kind of got everybody out. Yeah, I contributed a few items, 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 uh yeah, you're not allowed to have the PDF of the book, but the original the original entries were originally available on a wiki. And so I've had people um people have scraped this and put this into Git books and uh uh in GitHub in various places. So you don't have to buy the book, you can find the items online um 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 Commons license, that's absolutely fine. They can't rip off the PDF, that's kind of differently copyrighted. But that the individual items, absolutely, they're under Creative Commons. Now, why am I telling you all of this, bop, that, so that we don't inspire more uh emails to me that are necessary, but also to allow people to do this if they don't want to uh if they don't want to part dollars. Um but more importantly, um 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 gonna pick favourites. There are 73 contributors to that book. I'm not gonna pick one because that's that that that you know that's un unfair on the other 72. So I've got a get out clause here that Collin doesn't have.

Bryce

Ah so Connor, what is the one thing that every programmer should know?

Conor

I mean, I I just went and you know, 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 97th is it quotes. I'm not gonna remember the name of the book, because the original quote comes from another book. And I've I've mentioned this in talks before. But basically, like and I I think potentially it's learn foreign languages. Yes. But I've gone to that. There's learn foreign languages.

Kevlin Henney

That one, if I remember um correctly, is Klaus Markfahrt. There is another one, no more than one language well, if I remember correctly. Um more than two programming languages. Um that was from Russell Winder.

Bryce

So but wait, wait, Kevlin. So I 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.

Kevlin Henney

Ah, right. They are strictly speaking, the original book, they are not numbered. They are numbered in the electronic copies.

Bryce

Ah.

Kevlin Henney

But um, if you look at the titles, you will understand how I ordered it.

Bryce

Is it alphabetical?

Kevlin Henney

It is alphabetical. Because then there are because I thought I can't play favourites, but also if you try and group things by top.

Bryce

It's very hard to group things.

Kevlin Henney

Yeah. Yeah, you you often find one, you find a piece, and it's actually under two good i i if you can file it under equally well under two different uh categorizing stuff.

Bryce

Like I like I as somebody who's in the role of being a software architect, like taking ideas and concepts and like 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.

Kevlin Henney

Exactly, yeah. And I I I chose so there's it's interesting how other 97 Things books in that series have chosen to do it. The original, the original 97 Things Every Software Architect Should Know had the most arbitrary order. Uh 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 who 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 one.

Bryce

Well, I mean, I I guess one could argue that the pair the people who had their shit the most together probably submitted early. And uh and and and so at the very least, those were the people who or those were the ones that uh had the most urgency and the people who were best at like getting it done on a deadline. So that's not a terrible thing.

Kevlin Henney

That's a very positive way of framing it. On the other hand, um maybe they just got something done and they didn't have they didn't let something just stay 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 both of these lines of argument work.

Bryce

I do like no I do like the first one, uh which is uh Act with Prudence. Yeah, by Sev Rosen. That's a good one, I think.

Kevlin Henney

Yeah, it uh it's it's kind of interesting, is is that that alphabetically that one, you know, that's obviously first, but also actually it's quite a good opening to the book. You know, I was delighted by the coincidence, uh, 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 gonna 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, this. This is my vision for the book. But this is very much an emergent architecture where I got um you know I got uh nearly 200 submissions. It was around 100, uh 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 it's it's you know, it's it's go to the fridge, and I don't know what I happen 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 alphabetic, and I did that in the other 97 Things book as well, is that alphabetical is the only rational way to allow people to find things. All other approaches are arbitrary. Let me tell you that 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 US contributors from non-US contributors or US-based contributors from non-US-based contributors. Honestly, that's almost as good as random number generation.

Bryce

Um I think that's a good that's a good approach because it accounts for some of the um bias of uh a lot of tech is very uh uh US centric and based in the US and so on.

Kevlin Henney

But the point is that if half your items are US and half of them are not, there isn't actually, I would say there isn't a why all of the. If I read the first one, US author, second one, non-US author, third, that's not a useful criteria for finding that item again.

Bryce

Yes, yes.

Kevlin Henney

You know, uh I I would I would agree with that. Yeah, so it it the question of representation is certainly uh an important one and is definitely something I dealt with. Um I I tried dealing with it with moderate success on the first book, but not as much as we managed on the second one. Um, but it's the idea of like this is how we're gonna order the items. It's just like that's not useful. I don't know if this author is US or not. Um, you know, I can't tell. Um, you know, you know, that that's not helpful to me. I can't. So I I structured it, um, and I I intentionally put in a reverse lookup as well at the back of the book. So you might remember, oh, the I remember the thing was written by somebody it's by so-and-so, uh, you know, by this person. Um let me I can remember the name, but I can't remember the title. So I did it alphabetical um by name.

Bryce

Are are any are any anonymous or under pseudonyms?

Kevlin Henney

Uh there's one that is a pseudonym.

Bryce

Okay.

Kevlin Henney

Interesting. Yeah. Interesting.

Bryce

And how did you pick Y97?

Kevlin Henney

This is a good question. It wasn't me that originally picked it. As I mentioned, um it emerged, it got created out of a um out of a separate discussion, a separate list. And it's a list that Bruce Eccle 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 uh the stuff available, but also quite a deep and thorough book at the time for anybody who was trying to get into C. Uh, and this is on Bruce Eccles's list. And a guy called Richard Monson Hayfall, um, 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's that that was the order. But then he said, Okay, how many should we have? And he said, I think around a hundred is about right. And he says, but a hundred 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. You know, and he said 97, that's you know, it doesn't look like it's trying to be a hundred, but you know, it's its own thing. Um, and that really is that really is it. That is the only reason for it.

Bryce

Good good for SEO, right? If you search for 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 enough.

Kevlin Henney

It's a it's for those that care, it's a strong prime, although you'd never use it in uh cryptography. But it is a 97, it's a strong prime. But it is it is distinct, yeah, it's it's SEO friendly. Um, the reason 100 works is you 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 and why I ended up uh um really pushing this the program book was that I thought this is really useful because it's helpful to start conversations, it's it's the starting point. You read something, you can read it in, you know, uh 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 approached a 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 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, uh send it to a friend and make sure you put a post-it on the page that you wanted them to see, you know. Um so the physical form of book bombing is quite there, quite useful. A subtle hint sometimes when you have a uh 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 uh you know, the weaponization of 97 things has been interesting, but uh, but yeah, that uh so that that that was that um that's the the rationale for a lot of these things.

Bryce

So so you I mean I 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.

Kevlin Henney

That's that's uh I I think I I think there is a 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 why I 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 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 gonna get bored. A single author has control over the narrative, okay? Um, that there's value in that, you want that consistency. But when you're trying to take on, you know, something as complex as 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, uh, 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 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. Um, but yeah, you're right, ultimately.

Bryce

How how much did you have to um edit uh uh to get to like a consistent language or to get to consistent like like is it is it very lightly edited or is it more like you had to draft things a little bit and three shape things a bit?

Kevlin Henney

I uh it it depended it depended on the it depended on the contribution. I mean, sometimes and and actually that was another thing. I explicitly, although I don't know if this was Richard Monson Hafel's original intention, but I explicitly made a point when I was um, you know, uh when people would contact me, I'd I'd sort of talk about this at conferences, 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's just like if you're not comfortable with writing perhaps English isn't your first language, don't worry. It's you're talking about 500 pages. I can I can do the editing. If you're if you're worried about language, I can I I want your enthusiasm and your knowledge. Give me the story and I can shape it, you know. So sometimes I'm getting stuff and I'm having to do a lot of syntactic level work or phrasing and voice stuff. Um, 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 I wanted to have a proper consent and agreement and to give, you know, just say, is this okay with you? And and so on. Whereas for other people, uh 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. Um, 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 that.

Bryce

How many submissions you got?

Kevlin Henney

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, um, 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 um, so there was certainly a uh an effort there. Um, but I found that but ultimately I found that easier um than than writing. I mean, I've I've written a couple of books myself, and it's just like I don't know, uh it's uh it works differently for different people, but um all I will say is that my wife told me after um after uh 97 things, she said, Kevin, you're a lot more pleasant when you're editing a book than when you're writing one. Uh you know, I as a human being to live with, I you know, okay, I get that, you know. Um so yeah, uh I I can see that.

Bryce

It's funny because despite my despite my my joke earlier, um I actually can imagine that uh uh having to be an editor for 97 different was it 97 unique individuals that submitted for.

Kevlin Henney

No, 73 unique individuals. Yeah.

Bryce

Having to be having to to uh interact with and work with 73 different people, some of whom you had to go back and forth with uh edits on, and you had to make sure you got everybody's you know, sign-off and everything.

Kevlin Henney

Most of whom I don't know, so that's the other thing.

Bryce

This is actually this actually sounds like a good bit, a good bit of work, a different type of work. Um I guess that the maybe the nice thing about uh uh this versus writing a book on your own is if you're writing a book on your own, you uh have to push the work out. Whereas uh if you're an editor in this this sense, you have all this stuff coming in. You have to keep up with it, but you don't you don't end up in that like that you know, that writer's block mode.

Kevlin Henney

Yeah, I I'm that I mean particularly 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 gonna 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. You know, I'm gonna I want you know this is gonna be social media, the whole thing. I'm interested, I'm genuinely interested in what people have to offer here, so I'm gonna drive this project. And it is, you know, as you say, it's it's got a different enjoyment, but it's got a steady state to it, and that's what I appreciated. Um, but it I think there's also an irony. After I finished, I I co-authored two patent uh two pattern books with um uh Frank Bushman and Doug Schmidt. And uh Frank Bushman made the point, and I suddenly realized all the stuff I've done is contributing to other people's books or you know stuff like that in the past, or co-authoring, and he he told me, Kevin, having worked with you, I don't think you're ever gonna write a book on your own. Because you know, I write, I you know, I used to write columns, and you know, 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 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 uh, if I'm working with other authors, actually that's a collaboration. It's like this is all like developing software. Um, you know, this is this all feels like there's you're working with colleagues and they're they're 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 gonna write a book on your own. So what did I do? I went out and found 73 people. And uh I or rather, ultimately, it was a hundred 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 a hundred uh uh contributors all told. So the opposite end of the scale.

Bryce

Uh yeah. Well, so uh you the other books you've written was uh it's the two pattern-oriented ones, right?

Kevlin Henney

Yeah, yeah, those are the ones that were like my name appears as that. I've edited a couple of other things and contributed to a couple of other things where I'm not necessarily directly credited.

Bryce

Why didn't O'Reilly want to do uh 97 things at every C programmer should now? I just know Yeah, yeah.

Kevlin Henney

That was uh Peter Sommel had approached them. Um so I don't know the conversation that he had. I think he did that around 2020, 2021.

Bryce

Um yeah, you know what? I I I have a call, I think he emailed me about that.

Kevlin Henney

Yeah, yeah. I think it would be I think it's a mistake not to do that because you've got a 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 it kind of ties back to what we were originally talking about about normalizing culture, voices, getting, you know, 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, so we tend to associate that with them. Um, we're also very familiar with the idea of open source development uh in the software. The point is that uh 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 put 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 I'm I'm saying I don't have the answer, or rather, I might believe I have the answer, but you are the, you know, the I'm I'm respecting your intelligence and the fact that there are two points of view on this, and I'm gonna show you both. Um and I, you know, I want you to, I, you know, I want to present where there is contention or diversity on this view, you should be the person who makes the choice. I'm gonna present you with both of those. It's not a done deal. There isn't the one true way. Uh, these are not the 97 things in one, you know, you know, 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. Having, 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 load of different people contributing. I think that would 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 th yeah, I find there's value in the project, but I'm not a publisher.

Bryce

Well, I I think I I I sounds like it would have been a good book. I like I like C the C books that I do like that I've talked about on this podcast before are ones that are a collection of, you know, like the beautiful code or the um effective C where it's like I don't have to read through a whole thing. It's like a list of yeah.

Kevlin Henney

Yeah, you can dip in, you get a point of view, you learn, you walk away having thought about something. Um and you know uh 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.

Bryce

All right. Well, we probably ought to uh uh wrap up because my uh my 1890s French carriage clock. Oh wow. It looks like it's uh maybe I'm losing internet now.

Kevlin Henney

It does look that. Yeah. Oh yeah, it's actually a great screen. Your your screen is frozen, it's fantastic. It's uh it's like you're you're having a nineties rave moment.

Bryce

Anyways, that may be a sign that it's time for us to wrap up. The universe is speaking.

Conor

Be sure to check these show notes either in your podcast app or at adsphepodcast.com for links to anything we mentioned in today's episode, as well as a link to a GitHub discussion where you can leave thoughts, comments, and questions. Thanks for listening. We hope you enjoyed and have a great day.

Bryce

Low quality, high quality, that is the tagline of our podcast.

Conor

It's not the tagline. Our tagline is chaos with sprinkles of information.