97 Things Every [Java] Programmer Should Know

Listen to this episode on:

Apple Podcasts | Google Podcasts | Spotify | Overcast | Pocket Casts

---

Discover the voices behind the 97 Things Every Java Programmer Should Know in the GOTO Book Club episode with Trisha Gee, Java Champion & leader of the Java Developer Advocacy team at JetBrains, and Kevlin Henney, Thought Provoker at Curbralan. The book authors will highlight how to make the most out of the book and why it is not intended as an exhaustive list or only targeted at Java developers.

Preben Thoro: I'd like to welcome you, Kevlin Henney, and Trisha Gee, to our book club here. Our book club has been an enormous success since day number one, and we are really delighted to be able to continue doing this and for having your support in this. Thank you so much for being here today.

Trisha Gee: It's our pleasure to be here.

Kevlin Henney: Likewise.

Why 97?

Preben Thoro: We're talking about your book about "97 Things that Every Java Programmer Should Know." When I see this title, I cannot help thinking that 97, that's just a clever way to create some interest in the book. What is magic about this number?

Kevlin Henney: Ok. I'm probably in the best position to answer that question. This has quite a long history. It goes back to the first 97 things books. So that's actually, I have to have that here, "97 Things Every Software Architect Should Know" by Richard Monson-Haefele. This book was born on Bruce Eckel's programming list. And Bruce Eckel, the author of Thinking in Java. Richard asked people, "I'm doing a talk. What are 10 things that every software architect should know?" And everybody came up with so many suggestions, he said, "You know what? There might be a book in this," lots of independent suggestions. And so he went and spoke to Mike Loukides at O'Reilly and the idea was like, "Yes, let's go for it. How many should we have?" And it was gonna be around 100. But 100 is a bit of an obvious number. And as Richard said, 99 and 101 are trying too hard not to be 100. So 97 gives you the right, kind of, figure.

So 97 was chosen. It's nice and prime, but I'm fairly sure that wasn't part of the consideration. Actually, that was the idea. If anybody else has any other ideas for a book, then we'll have a series. So it got hardcoded as 97 things, which I actually found frustrating. I edited a previous book 97 Things Every Programmer Should Know, which I have somewhere, there we go. And I remember doing the selection process for that, and I came down to 99, a final list of 99. That was really hard to get the last two selected.

So the standard lesson kids don't hard code numbers into anything.

We knew this, but that's why it ended up in the book. But I guess going on from that is there was a period of a hiatus and then they relaunched and started talking about doing the series, picking it up again. A few years ago, I was approached about this. And, of course, I didn't have the time to do many things, but we settled on the idea we should do one for Java because that has a very large and very broad user base, the number of people who use Java, the number of places that Java exists, and also the fact that it's so cross-platform in many ways. I mean, JVM is the platform, but the fact that it touches everything was, kind of, the interest it's like, "Okay, we should do that."

That was the initial thinking. Then as we were progressing, it was like, "Okay, we need to have sort of a broader reach." That's where you go involved Trisha. Zan McQuade from O'Reilly and I got in touch with you because you've already contributed. I get to say this because at that point, you were the co-editor and you had already contributed three really good pieces. That's gonna give us a really different kind of, approach and a much broader base, pulling in a very different grouping of people.

Trisha Gee: Yes, it was really fun to get involved at that point. I think Zan and you got me involved because I pointed a bunch of people your way like "Oh, you should ask this person and you should talk to this person and let me introduce you to this person." And so it just sort of flowed fairly naturally from there. Well, why don't you kind of help out, like creating this book?

Kevlin Henney: Yes, you're quite good at this. But the best bit is that there were loads of really different people I wouldn't have contacted. But also on your hit list, it turns out I had a hit list and it was a really strong overlap in certain areas is like, "Okay, we are of a similar mind on this one," which was really good. So...

Trisha Gee: Yes.

Compiling the book

Kevlin Henney: I think that was one of the other things is we also managed one of the things I'm actually really pleased about with this is it really good cross-section, with 97 things, one of the things that you can end up with and some of the books and series haven't ended up with is a very strong skew, some people submit lots. It's like open-source software in the sense that there are some people who do loads and loads of commits and really contribute a lot and then there are some people who just do one. And certainly, my experience with the other books is that sometimes you've got one person submitting up to eight or nine pieces.

We put in place fairly early on the threshold of three. So that actually pushes out the grouping. We ended up with 73 contributors, which is a really good cross-section. It's one of those things that I think one of the nice things about these books is and we've got all of the contributors on the cover. So that was always a feature of these books is to have contributors on the cover. It's just, like, this is not my nutritious book, this is their book. We, kind of, acted as conduits and it's just like, "Yes, come in. Show us really cool stuff."

So there was that aspect but I think that also is very obvious. There's a lot of different points of view in the book, which I think is the other thing is that sometimes people will misquote the title as The 97 Things Every Java Programmer Should Know. I'm always keen to say, "No, no, no, this is just 97. It's a sample of a much bigger space."

Trisha Gee: A 97 things.

Kevlin Henney: Yes. I think that was quite key. I think if you look at what we've got it's a really good cross-section.

Trisha Gee: I think another confusion there is that, so I saw I read some of the reviews, like, you should never read reviews it's like reading comments on YouTube. But I read some of the reviews and some of the reviews are like, "Oh, these 97 things are contradictory."

That's very much part of the point because our industry is like that. The ultimate answer for everything is it depends. So if it depends, then one right answer in one circumstance is not the same might answer in another circumstance. So it's really important to have like 73 different voices talking about 97 different things, some of which are contradictory. 

Sometimes it can even be the same author doing two contradictory points of view because, you know, that's the reality of software. This is the sort of thing that with this book, it's the thing that you want to have at university for students so that they can get confused about what the real world is like. Because at university with computer science and things, it's like, this is the right answer, this is the right way, this is how you do things and the reality is that that's not really true. There are some good things to do.

I think you and I both, were keen on making sure that testing is in there a lot because automated testing is important, coverage is important, understanding performance applications is important, but you have to know what those limits are. For the rest of it, there's not really any right or wrong answers. There are different approaches and finding the right approaches for you and the team and the domain. So it can be a quite confusing book because you can read it and be like, "Okay, so are certifications a good thing or a bad thing? Should we do, like, full coverage or should we just, kind of, like, wave the thing in the air and just write that tests that we, kind of, want to see? " You know?

And I like that.

Kevlin Henney: I think that was one of the things that I think and that was certainly one of the philosophies I had before, but I think we're both very much of like, "Okay, we need somebody else to have a counterpoint to this piece." So it's very much that idea of like, the book is not some, kind of, magical, single source of truth it is supposed to be this representation, this sampling of the Java verse, all these different voices and different points of view. 

Where there is something that people hold a different view on and your example of certifications is a really good one, it's, like, well, let's get two sides of that story and actually, actively seek out rather than give people, well we both have particular views on certain things, it's like well, yes, but that's not our job here. Our job is to try and get that voice. So sometimes and I had that criticism in the previous book as well. And it is a case of like no, it's not a sole deal. Although I have a preference, your preference may be different, but we can offer you the information, especially where there are two sides. Let us show you there are two sides here.

For the testing one, if you actually try and do the testing exactly according to the of the pieces we've got, we've got so many different points of view on testing, if you actually try and do it, you will find contradictions. And that's not a hard thing. It isn't this sugar-coated, you know, year one year two, you know, computer science course. That's definitely not what it is.

Trisha Gee: Yes, and it was nice to get all those different opinions and different backgrounds in there. I also like the fact that, obviously, it's the Java books. There's a lot of people from the Java world, you talked about the fact that I pulled in some different voices that you didn't have access to. I tried to pull in a bunch of the Java champions because that's, kind of, one of my groups. But I also made an effort to pull in people who are not, they have, like, 20 years industry experience, but not necessarily 20 years experience programming Java at the keyboard because we have to open our eyes, we have to look beyond just the code. We have to see what makes you a good developer. It's not necessarily writing lines of if statements, it's who do you talk to? How do you communicate with them? Like, how do you get involved in the community? I was really keen to showcase that it's important to be part of a Java user group. And why is it important? Not because you have to give back to the community, but because you get a lot out of it and it helps you. You know, it's actually quite a selfish thing.

Kevlin Henney: Yes, I think that's a really important point. In fact, I think if we play around with the title a bit, it's not 97 things you should know about Java, it is, you are a programmer, this is your profession, what do you need to know? You happen to concentrate your technology in the Java area, but that is not the only thing that you're gonna do. You need to have a much broader, you know, a well-rounded view. 

I think that community aspect because that I think that's one of the things I often associate with the Java universe when we often talk about, you know, that's the JVM, it's not just the language. So we've got some couple of groovy things in there, Kotlin Closure, there is the JVM mechanics, then there's the ecosystem, all the way out through your tooling, then your tests. 

Then actually, what about the people? What about interviewing? What about the community? All of these things. This is what it takes not to know about just about Java but to be a programmer in this space. I think it's really important. And that's one of those things that makes the book, I think, more generally applicable than just, you know, is this book just for Java programmers? Well, that's its primary target audience, but a lot of the advice, even the code advice, actually, a lot of the code advice is actually applicable outside Java. It just clearly has an intended primary audience. But actually, there's a load of other people who benefit and have benefited from this actually.

Trisha Gee: So I have a friend, he's a NodeJS, JavaScript guy, and also, like, Big Data and stuff like that. So and he did Java at university like many people do. 

He read the book because I've got like a stack of them on my shelf. He's like, "Oh, can I borrow that?" And he read it he's like, "This is great. There's loads of stuff in here that I learned. I don't need to go back to Java, I don't intend to do any more Java, but I learned a boatload from this book. Because:

 a) I can read Java, so that's helpful, but 

b) there's a whole broad spectrum of stuff, like, the community stuff, like, how to grow your career, like, how to ace interviews, stuff like that, that are applicable across the board."

I feel that's the strength of the book. But I also feel, like, is a weakness, and you can easily market it to the other developers and say, "Hey, yes, you're a JavaScript person, but you can learn a lot from this." And, like you were saying about Java as well having a nice broad base, one of the things about writing Java code is that JavaScript developers, C developers, C# developers, they can all read Java, it's not necessarily applicable. They don't care about which version of Java or which libraries they're using, that the code is still readable to them. But it's difficult to sell it to a C# developer and say, "You should read this," but you should because there's a lot of stuff in there.

Kevlin Henney: Yes, and I think that is the thing is for a lot of books, any good book on programming normally says more than just the thing that it set out to do because, you know, you can't just put things this in a box to be a good here's things you should know as a Java programmer that you should not know as somebody else. It would be a very odd, kind of, title, but it would be a ridiculously hard thing to the boundary. So I think there's a lot there. And that, kind of, leads to there is this interesting question that I've been asked is like, having been involved in these two books a decade apart, although I'd like to point out that when the 97 things, we didn't have a pandemic 10 years ago, that was new. That was a new twist. But I guess it did allow you and me to actually finish the edits on the book quite nicely, suddenly, like, we're not traveling around and doing stuff. It's you actually have time at home to sit through and make final selections on this. And so there was that.

There's this question of overlap. And I will say the first thing is because it's a book that has chosen a language, there is code in this book, but there's a lot more code in this book because it has many choices of language. So I find that if I look back at the "97 Things Every Programmer Should Know," there's some of the advice is a little broader, perhaps a little more generic, occasionally somebody will launch into a piece of code, but there's less of that whereas by saying, we're doing Java, we have the opportunity to say, let's get specific, let me show you exactly what I mean. And indeed, that was a license as well. We see it with the Kotlin code and the Groovy code, it's like people much more open to letting code. There's a lot more detail here, which I found, kinda, gratifying. So that was really nice. But it is there is a difference there. It is specific and again, you can learn from it even if you're not a Java programmer but because we've said here is the language, we can be much more specific. So that has a value in it. Of course, it does anchor it a little bit potentially in time because, you know, if we drop the book into it, you know, there are a few things that are mentioned there that are going to change, definitely within the next two or three years and if we would look at it 10 years' time, there are a number of things that I expect the world will have moved on in a number of very key ways, both from the ecosystem point of view, what a VM allows you to do, but also the language. But on the whole, is, kind of, like, as a reasonable core, kind of, timelessness to it and there's a few things that will probably age a little more rapidly than the others.

Trisha Gee: Yeah, I agree. I think that overall, probably 80% or more of the book will be absolutely fine in 10 years' time, even the technical pieces. Obviously, there was a certain emphasis on things like streams and streams API, how to use it, which is Java 8. Well, Java 8 now is I think it's 5 years old now. But that's the one most Java programmers are on. But I think things like the streams API, this is sort of thing that you're gonna have to grasp as a developer, like, from now on, regardless of, you know, whether it's 10 years' time or not. For some of the other pieces, we had to be a little bit careful about whether that's gonna change over time. So for example, I wanted to be careful to make sure that the var word was, like, used where appropriate because, you know, we don't have to have all the boilerplate all the time. And that came in, in Java 10, and will become probably more used as people evolve their versions of Java. Similarly, records are on its way. So some of the stuff about, like, again, reducing boilerplate and how to write nice domain objects, there has to be a certain caveat to some of those pieces, like, when records come, this is going to change. So it was a bit difficult to balance the technology with the going forward.

But I think we did a reasonable job of that. Even the JVM stuff that you were talking about and we tried to be fairly general, there's a piece on garbage collection, but it's more about how do you sort of understand the garbage collector, what does matter what doesn't matter. There are other multiple garbage collectors that will be coming in overtime and about JVM optimization. The fact that are a lot of developers when they learn Java, to begin with, they, kind of, learn Java, the language, they don't necessarily understand the JVM platform. They shouldn't have to. So a couple of pieces explaining that the JVM optimizes stuff and developers don't really need to know how, why explicitly, like what's happening under the covers just a few pieces explaining that it does happen is enough, I think, to open people's eyes and sort of say, you know, this is something to be aware of, and in 10 years' time, they might optimize it differently, but the fact is the JVM is doing optimization for you so don't pre-optimize your code, for example.

Kevlin Henney: Yes. And in other words, what people are gonna learn from that is there's a principle here that's at stake and, you know, that that's the message to pick up. But I think there's also that other interesting side that when looking at some of the pieces there is this recognition that and that's actually the value because, you know, we're, kind of, like, the 25 years of Java mark when this book came out, that there is a legacy spread people are dealing at different times. Not everybody is sitting there going like, "I can't wait.

I can barely wait for the next release of Java. I'm gonna use all of the experimental features and absolutely everything in my code." That's not people's reality. For some people, it's a case of like, "Oh, I pine for Java streams, I would love to be able to do that. But actually, we're on a version of this Java 7" and that the point there is that that it's a case of, like, although the book has a time spread in it and a certain part or age, the thing is that the way that the industry is actually there's a sort of sedimentation, glacial sedimentation. For some people, some of this stuff even in five years' time is gonna tell them new things that they don't see in their codebase and things that are only just being accessed. And so I think that that is actually a lot of people's reality. Recently I sat in on a team that was making a decision about moving to Java 8. And, you know, I wanna say, thankfully.

Trisha Gee: Oh, bless them.

Kevlin Henney: Bless them.

Trisha Gee: I feel sorry for them.

Kevlin Henney: Well, that's just this is the last few weeks, you know, so the point there is not everybody is where the excitement is, it turns out there's this trail. So again...

Trisha Gee: Quite rightly as well, because enterprises, they need that stability. They can't be moving Java versions every six months. And so not everyone's gonna be able to use the latest and greatest all the time. That's just the reality. 

Kevlin Henney: Yes. I have a really good connection normally, but this meeting is an absolute nightmare.

Trisha Gee: Well, why don't we change the subject so it makes it easier to edit it together, like, afterward?

Kevlin Henney: Yes. Okay. So what should we look at?

Key takeaway no. 1

This book is a collection of insights that are valid for software developers in general, not only for Java programmers. 80% or more of the book will be absolutely fine in 10 years' time.

Diversity of voices: not just those at the top

Trisha Gee: I would actually like to lead on from what you were saying about the previous version of 97 things every developer should know, versus every Java developer should know. So just first up, I did like the first book, I did read it, and I already knew Kevlin when I read it, so I was like, "Oh, this is Kevlin's book so that must be good." But I do remember when I was leafing through it, as a woman developer, I was a bit like, there were not that many voices like my voice in this book. I'm sure that because I understand how difficult it is in this industry, I'm sure you worked really hard to try and get that diversity of voices. 

I'm pleased with what we achieved for "97 Things Every Java Programmer Should Know." We did, again, I would love to have a book where it's 50% of women's voices. I would love to have more people of color and more other, like, diversity across the board. But we did okay with the gender diversity for 97 things.

Kevlin Henney: Yes. It's interesting to say because that was one of those things. So again, it's this whole thing about having people's image on the front. There are eight women on the cover of this there are by coincidence, 73 contributors to this book. 

I had at the time, and I put in quite a lot of effort trying to reach out to various groups. I was pleased with my results when I looked at the glass ceiling effect that was certainly much more visible in 2009, 2010. 

So going to conferences, I would notice that you expect whatever I see in the office, and people's offices, it was one in 20 speakers were women. It was really trying to push that number up. 

One in 10, yes, that is up. But I found that at the time, that was not enough. I was not entirely pleased with that. I had two really interesting comments from people and it was quite interesting at the time. One comment was from and they're both men, one comment was, "You got a lot of women for this book." And the other one was, "You didn't get very many women for this book." And one of them was in software development and the other one was not. The one who was in software development said, "Wow, you managed to get a lot." Somebody from another profession said, "You didn't get very many." 

I said, "Yes, I know. I got as many as I could at the time, but that's something I would like to concentrate on." That was an explicit agenda point in my head that any other book that I did was going to really try and address that, which is fortunately also something that you strongly believed in and pulled the connections. We managed one in three. So that's not 50/50, but what I like about what we did, particularly as in the book, has people's photographs on the front. One of the most common things is people have that experience, do I see me when I... You know, it doesn't matter what profession is do I see...? Is there a person like me in that space? On the cover of that book or in that movie, whatever the profession is, do I see me? And I think that 97 Things Every Java Programmer does a better job of do I see me? Yes, I probably do. There's a lot more. That probability is a lot higher and 50/50 would be great, but one in three, I would say if I've got all the other 97 things books, there are six at this point and our book has the best representation of all six, definitely.

Trisha Gee: You were talking about when you went to offices, you didn't see the same representation at conferences. My experience is that in technical careers, generally, we see about 20% women, generally speaking, roughly, it's difficult to get the numbers, so getting 30% women in the book is good because again, it's pushing that up. But yes, I would like to see 50% because I want people to be able to see themselves and I would like to do better if we do something in the future in terms of racial diversity and things like that as well. Because I think we should be representing where we want to be, not where we are.

Kevlin Henney: Yes.

Trisha Gee: Yes, 50/50 would be good.

Kevlin Henney: I think that it's timelessness. I think, again, that ties in there as well. Is that idea of what this will look like in 10 years' time. We have a choice here about setting the direction and that idea of making sure that people look at that and go, "Yes, this actually makes sense." Oh, in fact, that they don't notice, that would be a really nice thing. That would be the really nice thing, it is not they don't say, "Oh, that was an artifact of the past." Now, if actually, they can say, "This was forward-thinking," or that they actually don't notice so they think, "Oh, this is okay. This is not unusual in some respect."

Trisha Gee: It is something that you have to work at, though. I get asked a lot about how to fix the women in technology problem, which is a bit difficult because I'm like, "Well, I'm already here. So I don't really need fixing. I don't really know what's broken because I made it." But, you know, a lot of people, a lot of conferences, a lot of collections ask me, like, how to get better representation for women specifically. 

I think this is first and foremost, don't tack it on at the end. Don't go, "We've got 73 contributors, oh, only two women quick, let's get some more women," you have to do right at the beginning. You have to reach out. The women in our industry, particularly when you're looking at the women Java champions, the women conference speakers are enormously overloaded because they are trying to be role models. They are bearing the burden of the fact that there's less representation for women. So they are speaking at more conferences, doing more events, writing more articles, writing more books if they can. So they're already overburdened. So you have to get them early and get them bought in and also tell them, like, what's in it for them.

Kevlin Henney: Yes. This is the thing that you are weighed down with the burden of like, hey, you're not just technical, you've got to be an ambassador as well. That is, unfortunately, part of the responsibility, which is a burden. But also I think all the way across there's this idea and actually, we were quite clear when we were talking to O'Reilly about a couple of other things when we came to discuss in the back blurb, there was this idea of like, "Here we have 97 things from the best Java programmers in the world and why we both pushed back." So, No, no, no that's not what the book was composed of. We're not saying these are the best in the world, that's not our ranking. 

In fact, it was this idea that what we're doing is we're getting 97 things, they're not even necessarily the best 97 they fit together the best. It is a construct there. 

This is not all just famous people. I think that's the problem. Some people self select out or perceive, "Oh, well, you know, I can't contribute to that because that's a book where big names are contributing." It's like, no, no, no, most Java developers are not big names. 

So there's this idea of, like, everybody can come and contribute to this. I think it's that idea of participation, invitation and participation are that involvement, I think that is quite hard. Sometimes when people look at the idea of a book or a conference, they perceive an extra hurdle there and the ways that you've got to do, as you said, you've got to get this right from the beginning. You can't present people with a huge great step at the end. And say now jump over, this is a case of like, let's get that right, let's lower that right at the beginning. We're interested in your voice and what you have to think.

Trisha Gee: It's like what you said at the beginning, it's about voices and voices isn't just the people at the top, you're never going to change everything by having the people at the top always saying stuff because you hear them all the time. You can hear the people, the CTOs, the leaders, I'm not gonna name names, the people in the community who I don't necessarily approve of, you hear their voices all the time. 

We don't need a book full of people like that. We need a book full of the real people, the real developers, the real people who are doing the work, walking the walk, not just the people who go to conferences and, like, chat about stuff, like how it would be if everything was lovely. That's not the reality of the situation. 

I like the Java Community because it's a community. Because we're real people because we help each other. I speak to a lot of women specifically in other technical communities and I get the feeling that every community is different for different reasons, but I get the feeling that one of the benefits of the Java Community is that we really do wanna help each other. We really do see value in every individual and if your point of view is different from my point of view then I should listen to that because maybe there's something I haven't heard before, whether it's because you're more senior or more junior it doesn't matter.

Kevlin Henney: Yes, I think the danger, your highlighting is the one of becoming a monoculture. It is exactly what we're trying to get away from, but also those voices where people don't necessarily speak up, but they also don't just have different experiences. 

Key takeaway no. 2

The contributors are real developers who are doing the work

Respecting different perspectives  

Kevlin Henney: One of the questions that I've had quite a lot is when people said, "Well, could you've written a book with 97 things and stuff like that?" 

You can get any individual and get a spreadsheet, or grab a piece of paper and write out, you know, here's a magic number, write out a number of things that you would recommend to people. It would be a consistent, coherent narrative that I would never ultimately end up writing. But it will be consistent, coherent, and it would show one person's point of view. What I love about these things is not only as people coming to you with something that is different from your point of view, even the things that you're familiar with, they write about in a different way. Simply, I look at a number of the pieces and it's just that I could not have written that, although I agree with the author, or I do what the author has done, there's no way that me, I could not have written that, it wouldn't be the kind of thing I'd write, but I want to read that. So I think that's the other point of view is that it's a very that openness, that, kind of, I don't know, it's almost like a collage of points of view.

Trisha Gee: It was an interesting exercise for me, it's my first attempt at editing something. I do a lot of writing, not as much as I would like, but I do a lot of writing and I sort of found my voice and I have several different styles depending on whether I'm writing for JetBrains or for myself or whatever. But when you're editing someone else's, I had to really resist rewriting it so it sounds like me. Because that's not the point that you're saying. It's really about different people's sentence construction, different people's way of leading into a problem, different... I don't want to rearrange stuff or reword things. But my temptation was like, "Oh, I want to write it the way that I would say, definitely." "No, no, no, leave it well alone."

Kevlin Henney: Yes, it's the issue of how do I help this, but how do I make this piece more of what it is rather than more of what I would say and that's a slightly different thing. It's quite interesting because often when we talk about code, we tend to converge on a consistent or more uniform style. That's the basis for communication. But this is not a codebase. It is supposed to be a sample of this large, huge, huge space for which you could potentially have thousands upon thousands of items. 

It's just like, we're gonna pick 97 and it's that idea of can we do a reasonable statistical sampling, but that they should not have the same voice. Because I think that's the other thing that's, kind of, quite nice about this is that you can pick a topic and do it as, kind of, a lunchtime discussion, or do as a group discussion or you can read this from cover to cover, but if you're reading the same thing all the time in the same way that's gonna give you a very different experience. It's that idea of each, you know, at the end of two or three pages, you're now onto something not only a different topic, but somebody else is telling you something in a different way. That actually makes the reading of it much more enjoyable, I think.

Key takeaway no. 3

It's really about different people's way of leading into a problem.

How to make the most out of the book

Trisha Gee: I get asked a lot, like. "How am I supposed to read this? Do I read it front to back? Do I dip in and out?" And, of course, the answer is, it depends.

Kevlin Henney: Yes, how do you want to read it, you know?

Trisha Gee: How do you want to read it? I think it's interesting because it was ordered alphabetically in them, wasn't it? So there's no order, there's no narrative. I think we picked the chapters to be ordered alphabetically. So you can pick up whatever you want to do. If you are interested in the cody technical type pieces, then by all means pick them up first. If you're not a Java programmer, feel free to skip over the bits which are very specific to Java. Because there's still like I said, I reckon about 70% or 80% of it is gonna be relevant whether you're Java or not, maybe. Pick a few articles which might be relevant for your team, your company, or whatever, and use them as a conversation starting point.

Kevlin Henney: Yes, or book bombing, if you're gonna make a point to somebody, it's like, "Here. This is the chapter you need to read."

Trisha Gee: Right.

Kevlin Henney: It is an interesting one because there is that question of how to impose a structure on 97 things. That's why it is alphabetically ordered. Actually, in the back, there's a reverse lookup because sometimes the way that people remember things is they think, "Ah, it was by somebody or other," or "It was about halfway through," and to have some kind of stable structure there. If you can go and look at the person in the back and see, "Oh, they wrote this." So it's, kind of, cross-linked like that. There's no other reasonable way to order these things unless you did actually get people to submit in particular areas. 

When we look across the themes, what's interesting is always something that stands out very obviously. So we could pick testing and say, actually testing is a category and do that. A lot of the other pieces don't. They straddled multiple categories. That if you did try and say, I'm gonna push this into a category it's only half in, it would mean it wasn't at another point in the book where it would also fit quite well. So there's this, kind of, interesting idea of like, well, these are the voices as they are. Then it's not gonna be a random order. You know, a couple of the books are actually ordered fairly arbitrarily. I know one of the 97 books is ordered based on the sequence of submission, which is known to nobody but the original editor. It is a mystery. It's, like saying, "Okay, what's the order of things in a hashmap?" I don't know.

Trisha Gee: I think that's a really good way of basically getting to name and shame the authors for who does it at the last minute.

Kevlin Henney: Yes, exactly. The ones at the end, it's just like, yes, okay. If when you know the story, you know, whereas if you were the first person to submit, well done, you're in the first opening pages. But fortunately, we didn't tell everybody, "Guess what, this is gonna be alphabetically ordered, " otherwise, I'm sure people would have gained an image of the word aardvark in there somewhere. The other way of classifying things in an inheritance hierarchy. You know, that would have been good hindsight tells me maybe there's a second book here I can do that.

Trisha Gee: That's just you, Kevlin.

Kevlin Henney: Yes, that might just be me. Yes, gaming the system. When you know the system, how do you game it?

Trisha Gee: When my husband was reading it he was like, "Oh, I've just got like..." And this third one, which looks like this. I can't remember because I'm looking at the index now, I think it's because there's four that start with learn, which is quite cool, right? Because, of course, you want to learn something. But he's like, "This feels a bit repetitive." I'm like, "It's ordered alphabetically." But up until that point, he hadn't figured out that it was ordered alphabetically.

Kevlin Henney: Ok. Yes. Actually, it's really interesting you pointing that out. Just looking there and there are five “learns” in a row. There are only two “knows”. Whereas I think the previous one, it was a lot of “know” this and know that and know the other, so there's only two knows. 

We got to make it very instructive there. It is, kind of, interesting. And obviously, there's quite a strong clustering around the letter J. But that's on the sensitive side.

Trisha Gee: Yes, I was looking at that.

Kevlin Henney: So when you look at it like that, there's an interesting overlap there.  

Trisha Gee: We got your back. We got your back.

Kevlin Henney: Oh, yes. I'm actually got a ping window up here just as an aside, I've got a ping window here and it's five pings. It goes out four and then it comes back. So, yeah. Yeah. So they closed off the local roads, by the way, as well, just for kicks. So, yeah.

Trisha Gee: It's all right the UK is in lockdown, you're not going anywhere anyway.

Kevlin Henney: Tell me about it. Right. 

Trisha Gee: I had one more note, which was any piece that we wanted to highlight. But I sort of think that we covered themes rather than pieces. 

Kevlin Henney: Yes. I have to admit that I'm always reluctant. Whenever anybody says, "What's your favorite piece?" I'm always kinda, "Oh, I'm not gonna play favorites here."

Trisha Gee: But, like I said, my pieces are my favorite pieces. I'm very happy with my pieces.

Kevlin Henney: We could choose the easy option there. But I think that's another one of those ones that if you have to choose your favorite pieces it's, kind of, difficult because it also depends on what conversation you've just had and why. You know, if I've just been talking to somebody about something that is intensely curly bracket focused, and detail-oriented, and I say, "Well, you know what, funnily enough, there's a piece in here that deals with that," that is gonna be front of my cache, you know? It's just, like, that's the most recently accessed topic and therefore, it will associate very strongly with that, whereas if I'm talking to somebody at, kind of, a bigger picture level, perhaps I've been talking to somebody about their career, then I'm gonna think, "Oh, no, no, you need to read this. That's the one." So my favorite is very context-dependent.

Trisha Gee: It is. I'm thinking about that. We picked up four when we did it was one of the GOTO book clubs, the lunchtime book club. And when I went back to have a look at what those four were, I was really surprised that a different piece wasn't in those four because I've been thinking a lot about this other piece. And I'm like, "Oh, I could have sworn I would have put that in those four." But it wasn't. So the one I'm thinking of is Gene's definition of done piece. But that's because, at the moment, I'm thinking a lot about planning, about arranging pieces, about arranging work, about work in progress, about estimates so, of course, I'm thinking about her definition of done piece.

I'm not thinking about garbage collection, for example, because I'm not doing garbage collection right now. But yeah, ask me next week and it'll probably be something like, oh, like a couple of weeks ago, I was doing the keynote for Java Zone, and it's about career advice for programmers. So I would have been like, "Oh, you should read my interview piece," because that's relevant at that time. So...

Kevlin Henney: Yes It is very much that. I actually had somebody last week ask me about what are my top five science fiction movies? So I gave him my top 13 and that's just not 20 because I just thought I can tell you what the top three are, but beyond that, oh, that's quite difficult. And ask me next week, and the answer will be different. And also, I find that again, is that context, exactly as you said, it depends what you've just been doing and where you've been focusing.

Trisha Gee: Yes. And there were some pieces in 97 things I really like because I didn't know that thing or because I don't agree with it. And so, you know, they really gave me a new perspective on stuff. And that's really cool, too. But I think this book is worth reading with an open mind because there are some pieces, especially when we're editing and trying to choose stuff, there's some stuff around like, "I'm not putting that in because I don't agree with it," you know? And you have to be really open-minded about well, okay, step back from your prejudices and your background and your environments and the projects you've worked on and have a think about, well, where is this author coming from? What were they probably working on when they came up with these conclusions? And are there other things that you might learn from it, which are going to be applicable in the future?

Kevlin Henney: Yes, I think that, again, that editing thing is an interesting one because it is the criteria that we use for evaluating things and it is one of those things that are distinguishing between here's the thing I disagree with, whereas here's the thing that is factually wrong, or is potentially damaging as advice. If you do this, actually, I can see there are gonna be problems. I have reservations about that. And again, it goes back to that idea of trying to help contribute to say better what they're trying to say, which is not always what you know. And there were a couple of cases where we did have to sort of point out questions of fact, or, you know, things that were known to be problematic and people restructured appropriately or said, "Actually I can't," that that won't work in this particular context. And I certainly had that one in the early days of editing the book. So I think that's quite an interesting one is like, okay, as an editor, I don't totally agree, but I love the way you said it or we need to hear this so that somebody else can go, "Hmm, why don't I just why don't I agree with that? Or, "Actually, I do agree and it's made a difference to my daily work." And that's the role there.

Trisha Gee: It was really difficult tryna recognize what your own biases are and what your own preferences are. And it was really educational for me, but I think also reading the book, I think that for anyone who is reading it because, obviously, it's not everyone watching this is gonna be editing their own book, for anyone reading it, I highly recommend not instantly going to that place of no, no, no.

Kevlin Henney: I think that's the other virtue of embedding potentially, pieces that people may not agree with, in a much larger context of things that they would find themselves in agreement with, is there's a pause for thought rather than I reject everything. That, kind of, immediate feeling, but also the value of having relatively short pieces. Again, there, it's the, yeah, don't ignore it, it's a couple of pages, see where it ends up. That may cause you to Google something, it may cause you to see things differently. There's always that chance.

Trisha Gee: Or just stick in the back of your head until that time when you come across that circumstance and you just need to be a little bit more open-minded.

 Key takeaway no. 4

You will get the most of the book if you just dive in and explore it.

• 

About the authors

Trisha Gee is a Java Champion, published author and leader of the Java Developer Advocacy team at JetBrains. Trisha has developed Java applications for a range of industries of all sizes, including finance, manufacturing and non-profit. She has expertise in Java high performance systems, dabbles with Open Source development and is a leader of the Sevilla Java User Group.

Kevlin Henney is an author, presenter and consultant on software development. He has written on the subject of computer programming and development practice for many magazines and sites, including Better Software, The Register, C/C++ Users Journal, Application Development Advisor, JavaSpektrum, C++ Report, Java Report, EXE and Overload. He is a member of the IEEE Software Advisory Board. Henney is also coauthor of books on patterns and editor of 97 Things Every Programmer Should Know.