Aaren Quiambao

Welcome to Coding over cocktails, a podcast by Toro Cloud. Here we talk about digital transformation, application integration, low code, application development, data management, and business process automation. Catch some expert insights as we sit down with industry leaders who share tips on how enterprises can take on the challenge of digital transformation. Take a seat. Join us for a round. Here are your hosts, Kevin Montalbo and Toro Cloud CEO and founder David Brown.

Kevin Montalbo

Joining us from Sydney Australia is Toro Cloud CEO and founder David Brown. Good day, David,

David Brown

Good day. Kevin

Kevin Montalbo

And our guest for this episode is an independent consultant, trainer, reviewer, speaker and author. His work focuses on patterns and architecture, programming, techniques and languages and development process and practice. He has been a columnist for various magazines such as the Register Better Software Java Report and has given keynote addresses in several conferences around the world. He's also a co-author, contributor and editor for a number of books. One of them is titled 97 Things. Every Java programmer should know and we'll be talking about that one today. Ladies and gentlemen, joining us today is Kevlin Henney. Hi, Kevlin, welcome to Coding Over Cocktails.

Kevlin Henney

Hi, Kevin. Thank you very much.

Kevin Montalbo

All right. So let's jump right. In 2020 you came out with a new book, 97 Things. Every Java programmer should know. This is your 2nd 97 things book. The first one, be the Programmer edition, which was published in 2010. So what transpired within between those 10 years that motivated you to come up with this book?

Kevlin Henney

A few things, one of the things that I noticed in putting together the book in 2010 97 Things Every programmer should know is that was intended to be a general book, you know, and a few, a few years after that, there was the idea, perhaps it, what would be nice is to go into more depth in other words, to go into a particular language to choose a language or a technology., and we kind of kicked this idea around, I kicked it around with,, editors at o'reilly for a while. Um, to, as it were zoom in, allow us to get much more specific. 

And one of the things that happened with the 97 things, every Java programmer should note book is, um, that one kind of came about as a sort of mutual interests of one of the languages I have an interest in. But it was the kind of the most likely candidate, it seemed the most broadly based.  It, it, it's been around for a long time. It cuts across many, many different technology stacks and many communities, but it is still also concrete. And we got, and I'm surprising we've got a lot more code examples for that one.

David Brown

A huge community, obviously, Java is still one of the most popular programming languages.

Kevlin Henney

Yeah, definitely.

David Brown

Yeah. How do you go? I mean, you don't have, this is a collection of articles from different writers as I understand it. There's not 97 different writers, but I noticed that it's some which have written multiple pieces. But how do you go collating all of those developers and writers to write about this sort of content?

Kevlin Henney

It's a kind of a mixed process. So specifically, there were set by OK, this is turns out to be a coincidence, there are 73 contributors. And the reason I say it's coincidence is because for the previous book that I did, there were 73 contributors.  So it was not by design. It's only when I go. it's only when,, so I co edited this book with Tricia G, it's only when we actually sort of went through and said, OK, who have we got as contributors? And I looked at the spreadsheet, it's just like that's 73. That's exactly the same number as last time. So, but there, there's a few, there's a few tricks and tips, some of them are direct invites. In other words. So I was editing this book with Tricia G from jetbrains. We, we have an overlap in the people that we know, but we also know very different people and, and Trisha and I really struggled with some of the decisions, you know, from people who had submitted 45 or six pieces, but all of which were good and it's just like, well, we, we can't take them all. We have a principle here. 

So, so yeah, that was so there, there was a balance. So basically what we were looking for was a mix of things.  It's 97 things. The important thing is that as I, I've kind of alluded to is, is the voices aspect. This is not 90 you can get an individual developer and say, could you come up with 97 things. And yeah, they could probably could. This is not 97 things. One developer thinks you should know this is supposed to be a kind of sampling across the, the, the set of programs of which there are millions. You're never gonna get all of that. But that's the idea. Let's get some different voices, different points of view. Sometimes it's a different piece of information but sometimes it's the way that somebody presents it as well. They come from a different angle that it's a novel or exciting perspective or their code example is fresh. Or they've got a nice anecdote to go with it that nobody else has.

David Brown

Did you, did you have to target a specific version of Java for the book?

Kevlin Henney

No, we made it fairly broad based.  Obviously we wanted it. The book is, is pulled in a few different directions because one of course Java is version sensitive and that is a distinction with the book. The 97 things, every programmer should know book cos that is not version sensitive. It, it, it because it is if you like in one sense a little more timeless, but we had to we were assuming people would be targeting something that was relatively current. And when we said Java, although the natural default is to assume language we were really talking about also it's a platform, it's not just a language So we are dealing with other languages, although most of the submissions were Java language where they focused on language, but that means that you're dealing with different technologies, different versions.  For some people, you know, there are, there are folks out there still on kind of 1.55.  But there are also people who are chasing every release twice a year. You know, keeping right up to date. 

And we had to make sure that when people submitted things that they s we changed the tone or the voice as appropriate.  Because they were normally, in fact, we had a couple of pieces that we ended up not accepting because in the time from acceptance to editing, they actually went out of date like blog pieces. And that's a different thing is that a number of people experienced writing blogs and the point of a blog is it's now sort of certain things, if I'm gonna tell you about the new features that are coming up in the next Java release, then that has a very different target audience and sense of freshness and timeliness to a book that, you know, somebody might pick up in two years time and it's still got to be relevant. So we tried to keep it as from an editing point of view, we tried to sort of change the tense or make sure that we were re you know, people weren't saying. 

And here's a new feature as in super new but realize where the, where the cut off points were. So, for example, Java eight is a really good kind of seismic cut off. And that will, people will still be talking about that in years to come cos it's so radically different.  But rather than just sort of saying, and if somebody's referring to the latest and they use a number, then it's just like, let's pull back a little bit from there. So it's not intended, the book was never intended to be here is the latest in Java, but it should be relevant. Most Java programmers are not working on the latest version of Java and that is always gonna be true. That's the nature of a language at this scale.  Once you hit a particular size, you have a much longer legacy tale. So this has to appeal equally to people who are still learning Java from books that are 10 or so years old or code bases that are 15 years old as well as somebody who has just been getting into it.  And still wants to learn that there's more to it than just new features.

David Brown

So is that the target market, people just starting out?

Kevlin Henney

It's a broader target market. It's, it was, it, it's kind of a, it's a market for people who are either they're starting out. This is the, the book that you don't get. In other words, you, maybe you've learnt the syntax, maybe you've come out of college and you'll have a particular perspective, but maybe you're coming into Java from another language.  Maybe you're returning to work. Maybe you're a senior developer just trying to round out things because everybody at one level or another is self taught or maybe you're helping mentor somebody else. So in other words, this is, this is, I wanna refer you to something and say this one covers it quite well. This is a good starting point. So it really is quite broad in that sense. It's not just for newbies, it's not a how to book. 

It is intended for somebody who has a little bit of Java under their belt or a lot of Java and has been around Java for a long time. In fact, that's another kind of classic target audience.  Any language that has been around for a long time, has people who have come into it, gone out of it and then come back again, what's happened in the intervening period. So it is, it pretty much lives up to title.  It is kind of what every Java program should know, regardless of their experience, things that are overlooked. I learnt things, Tricia learnt things. So, you know, in that, in that sense, I'd say that it, it's, it, it lives up to it's not a specific small target audience, but I could identify different groups within the, in that very broad audience.

David Brown

I was just about to ask you that, were there some contributions made which blindsided you like were, were, were really surprising.

Kevlin Henney

I don't necessarily surprising, but sometimes it was a little detail that they would highlight just a sort of a, a sort of a technical detail, either kind of language spec or something on the GC or just just a perspective or some aspects. I simply didn't know about sometimes community and sometimes environment. So I there was nothing that really kind of completely threw me saying I did not know that and that has changed my world view.  But that might be more a reflection of of, of somebody who's on the lookout for this or potentially somebody who's jaded. I'm quite, I'm quite happy to accept that accusation as well.

David Brown

Are there any challenges in terms of like differences of opinions and you know, deciding on which angle you're going to take on a particular feature or technology.

Kevlin Henney

That's an interesting one. So, Tricia and I were fairly clear, fairly clear from the outset that what we wanted was not the 90 it's not 97 things that Trisha and Kelin think are the most important.  It, it was and we didn't necessarily agree with everything. But that's, that go again, goes back to the voices. Because there isn't one true answer here. You know, this is not a programming community of 50 people who and it's a very closed clique or anything like that. It's quite broad. There's a lot of different points of view there. And so sometimes trying to get to represent, um, that view, that's quite an important one. So having pieces that in essence might contradict one another is not a problem. Although sometimes III I got that with the previous book, that was an intention of mine. That sometimes if you're getting a book from a single author, you expect a coherent narrative, you know, there's a single story and a single point of view to be told. And here, that's not, that was not the objective, it is a representation of what is out there. 

And mostly things don't conflict or contradict in a big way. This is kind of much more of a patchwork with a little bit of overlap. But there are some things where we do end up with potential contradiction and we actually sort out some of the contradictions. So, for example, we have a piece on why certification is good. We also have a piece that is incredibly skeptical of certification. And, you know, once we had one, we wanted the other because we know that this is Poten, this, this speaks differently to different people. And different people have very different takes on that. So we actually sort out something to counterbalance that I wrote a piece on,, on checked exceptions. Um, as in, please don't. So I wrote a piece on that. We actually looked for somebody to try and write a good piece on. No, you should use them and you should use the throws in your signatures, but we couldn't find any good ones. So, that one didn't get included. But it's a case of like we actually actively sort out things that might contradict a particular point of view just to show that. Yeah, maybe it's not all settled, um, that we're, we're hearing a number of voices and it's left to the reader, you know, you read it, find where your position is.

David Brown

Well, unfortunately, we don't have time to cover all 97 pieces of advice and that, I guess that's what the book is for anyway., but in, could you just run through a few of the recommendations made in the book that maybe even the more experienced charter programmers may not know and run us through a few?

Kevlin Henney

That's a really good question because I, you know I normally try and take, take the point of view. Don't play, um, you don't play favorites. Um, as an editor. So there are a couple of ones that I'll pick, you know, I kind of pick out a couple which I think are quite interesting. So, so for example in the Java world, Java world has kind of grown up with unit testing being fairly central compared to other programming language cultures. It's a fairly central idea. you know, J unit has been around since the nineties and that's also defines many people's experience of unit testing. But there's this other question of OK, what other approaches are there? So, approval testing is something that I think is quite interesting. And there's a really nice piece by Emily Batch on that to kind of like, OK, here's a different point of view that you may find helpful. It may be helpful particularly in legacy contexts. But it fits right in.  There are a couple of nice pieces that were a little more I guess ex expand your brain. There's a James Elliott piece here on OK. You've got Java Doc. But what about also extending it into ask you Doc? And that was kind of an interesting piece. There's a different perspective there. OK. So he's showing you something else. What can you do? What you and the subtlety there and then also the reminders one by Michael Hunger on benchmarking. Benchmarking is hard is his piece. 

You know, JMH helps. But the point here is he talks a little about the subtleties and difficulties of that and really just going in there because there's a lot of myths when it comes to performance. And I think that's true of any language in any platform. But a platform that's potentially as complex as the Java stack, there's a lot of different things going on at different levels. It's very easy to pick up myths.  You know, half formed ideas that probably had their basis in some kind of truth or something that was true 20 years ago and is no longer true and it's just this kind of like constant reminder.  But then we also have stuff on kind of some fairly careful thinking. So a nice piece by Chris O'dell, frequent releases, reduce risk. She talks about the idea. We have a kind of a, a kind of assumption these days about CICD pipelines and so on. But what she does is she takes a different perspective on it. It's about risk reduction and risk management, which is a very different way. It sometimes people start from the technology say what is available. Sometimes people look at the point of view,, frequent releases are necessarily a good thing and probably they've been in a particular environment but they've never really understood the motivation and she starts from a kind of, um, a risk based, um,,, perspective. So there's a whole kind of a load of things here.

David Brown

A lot of diverse content there as well.

Kevlin Henney

Yeah. Absolutely. Yeah. And there's some counterintuitive pieces. There's a nice one by Thomas Ronson have crashed your JVM. Not something you wanna do, you know. But there's a point in there about the point that Thomas makes is very much that it's very easy to look inside your ID. This is my code and you expect everything that is defined there to be the truth. But the point there is that the world of a software system goes beyond that, it goes beyond what you can immediately see and it goes beyond the kind of the pure idealized view of the language. So what are the ways, you know, stepping outside the view of your window? What are the ways that you can crash your machine? and so on? So there's there's these kinds of points of view.  So there's kind of, there's, there's quite a lot there. And II, I also like the fact we have a couple of points and counterpoints.  There's there's a piece by and, and this was going back to your previous question about about sort of balance and contradicting point of views. There's a nice piece in here by Gail Oli. Don't hide your tools, which is on ID ES or rather, you know, don't, don't trust everything about your ID, understand the full environment. Whereas Trisha who works for an ID company clearly has a different take on it and she wrote a piece. So we were looking for that kind of balance and that there's, if you look at both pieces, you sort of say, yeah, there's truth in both and it helps you understand. What is it that I as a developer would need to know to get the most out of my tools that becomes the bigger message there. So I think that that's the thing II I like is not just the individual pieces but sometimes the interplay between them.  It's it, it's that idea of like you're invited to think for yourself. But but the point is people are putting forward different cases for different points of view.

David Brown

Java's interesting language, isn't it? I mean, it, it celebrated its 25th birthday last year. It's been around for a while. It's not one of the oldest, you know, we've, it's got some old languages which you're having a resurgence as well. But Java dominates a lot of things like it dominates enterprise applications.  It, and it's one of the most popular languages used today, but I guess when you've got a tall puppy like that, there's also been a lot of people wanting to sort of, you know, predict its demise. Yeah. There were some predictions, you know, with more recently with oracles changing as licensing for. Yeah, com commercial licensing for Java as well. How has Java remained so relevant and resilient over the decades? You mentioned Java eight, for example, was a fundamental like, is it, is it, is it just keeping pace with technology and, and the requirements of the market? What is it?

Kevlin Henney

I think it's a, that's a, that's an interesting question cos I think it touches on a number of things. I, the first thing I say is that it's a popular pastime amongst pundits to predict the death of a language.  I'm just gonna, so all to all you listeners out there, honestly, it's not a game you want to get involved in because if you're trying to predict the death of a language, you will lose. You know, this, I actually recorded a small piece for a discussion recently on the fact that languages very rarely die.  The, the, the only cases where languages die is if they are incredibly tightly tied to a vendor and were already and have always been like that and therefore occupied a particular niche that once you remove that, then the whole thing kind of disappears or that they were niche languages to begin with. a very small community, perhaps a research based language.  These are the languages that die, very few languages actually die. What they, what they might do is they might slow their growth.  They might become kind of more moribund, they become at the point of death that never actually die.  If you actually look at the, if you look at the kind of top 10 languages or top 20 languages this year, you know, this year, you will find that very few languages are, in fact, you don't find languages that are younger than five years old.  You know, when people talk about a new language, they mean something that's about 10 years old. You know.  these days we, we hear, for example, Microsoft is talking about moving stuff from C++ to Rust. 

Now, I'm not saying Rust is old but, you know, it's, it's closer to a decade than it is to half a decade.  That's young, it's still considered young. So th th th that's the interesting thing is if you compare it to other technologies.  it, it's more like languages, sometimes outlive operating systems. So languages have a really long lifetime.  Once they get in there, they're not gonna move and partly they don't move.  Yeah, they might adjust up and down but they don't, they don't die. That's just not a thing that programming languages do. FORTRAN is still in there. For heaven's sakes. People have been predicting the death of FORTRAN since, um, the 19 sixties. Um, and they have been consistently wrong. So the point there is Java is kind of like that. It's, it's, it's everywhere. It's, it's offers you a stack. It's a VM, there's lots of libraries, there's lots of open source commitment. And once you get that kind of level of connection, if it were just a thin vertical slice that you could kind of pull the rug from underneath, then perhaps it could disappear with a, a small shift in technology, but it's much more pervasive. It's much more, it's like a city, city very, they reach a particular size and they tend not to die or it takes a very long time for them to die. It's connected across different platforms.  You know, we, we find, you know, cot in on Android, for example, which is quite a long distance from from standard enterprise programming. We find Java in education, we find it, it, it's, it's got a presence everywhere. So I think that rumors of its death are, will continue to be exaggerated. J Java will celebrate its 50th anniversary without much trouble. 

Not to say that it will be as popular as it was when it turned 25 but it's kind of reached that point where it, it's fairly consolidated. It's still growing. I don't know, necessarily the evolution of the language contributes to people coming into it. Although that's certainly for some people, you know, they've, they've got some of the frustration that they may feel sometimes with the verbosity classic classic Java is very verbose.  The language is now very different. If you, if you look at the language from a kind of kind of AAA linguistics point of view, it almost contradicts all of all of its original design aims in terms of its syntax. It was originally supposed to be incredibly explicit about everything. minimal conversions, minimal, surprise mini, minimal kind of like extra stuff put in by the compiler these days. Honestly, everything's deduced which it, it's the polar opposite.  And sometimes seeing you can see code that collides these two eras.  It's, it's so it, so it's got that kind of slightly postmodern feel it's a bit of a mishmash in places. But for some people that's enough, they can feel more comfortable and say, I don't have to go to another language to get collection pipeline style programming. I've got streams in Java. I've got Landers in Java and that satisfies an itch within me that now that makes that a little bit easier. I'm OK with not having an even lighter syntax. Or if I do, I can switch to one of the other JVM languages and there's that kind of comfort that you can write a whole load of code and then say I'll switch to another JVM language. I'll do a bit of groovy here.  And it's still all of that stuff you've written, or somebody else wrote for you a decade back is still there. So I think that, you know, it kind of, there's a little bit of fashion in there, but I think a lot of it is that kind of like consolidation and entrenchment.

David Brown

You mentioned to start out as a verbose language. And of course, the trend towards technology generally is to abstract layer upon layer, whether it be docker containers on V MS on kernels on bare metal or or you know, low code on the JVM, you know, running on multiple Linux or Microsoft or Macintosh type operating systems or whatever it may be the the the the trend is to abstract. So of course, in in the modern programming world, the latest flavor of the month is low code platforms and targeting citizen developers, no code platforms. How does now low code has touted benefits for the enterprise where, where java dominates is productivity benefits. You end up producing more stuff, the greater output in less time. But one of the unexpected benefits in some ways is if you're producing less code, then that code is easier to manage and maintain on ongoing basis as well, regardless of who wrote it down the track. So how do you see load code platforms fitting into java's dominance in the enterprise space? Is there room for both? Is loco going to be running on the JVM? Is how's it going to fit together, do you think?

Kevlin Henney

Yeah, I think that's an interesting one because I've had a number of discussions recently about the low code, no code phenomenon. And you know, there's a number of different takes on it. One of which is, yeah, we've seen this before and it was not successful last time around all the time before that, all the time before that, you know, that's going back to languages that die.  Most of those actually fall into the kind of classic waves where people were trying to do this. We also saw a lot of model driven architecture type stuff in the two thousands. Again, the rationale for that was the same. But at the same time, we should also look at where the success stories are. And actually there are some, there are long standing success stories.  Let's talk about spreadsheets because spreadsheets are a programming platform. And perhaps it's one of those things that might annoy a few developers who think that they're being very cool by getting into functional programming to discover that the accounting department in your company has been doing functional programming for longer than you have.  Because yeah, a spreadsheet is kind of like a pure Declarative model. If I'm doing Excel and then I, I'm not using VBA then actually I've got a very pure programming model there. 

Now, most people, so here we have something that has a universal adoption and it, when we start looking at and we don't think of it as a coding platform, but it has little coding extras and it, it, it, when we look at how that's been used, then we start getting a feel for how it's gonna co how this kind of stuff coexists with other development. And I think perhaps the productivity thing is a bit of a bit of a red herring. I don't think that's really the issue. I think it is the citizen developer that's the issue and that's not a productivity question. You know, spreadsheets did not necessarily boost productivity of an individual or a particular role in a, in a company that was previously not was previously a programmer role. It's gonna allow certain people to do certain things without you. They wouldn't even thought of using a programmer or eng you know, saying, hey, let's talk to software development and get them to do something for us.  They would have probably just mashed together a bunch of spreadsheets or a bunch of emails and said, I've copied a link here and done this and that. And so what it's done is it's just given a kind of name to that. Um, you know, it, it's, it's very much so, I think sometimes when people are looking at the low code option, they're particularly the no code option when they're, they're looking at it from what does it mean for developers? I think they're looking at it from the wrong point of view.  Spreadsheets never stopped people developing.  It just opened up the number of people who were using certain applications.  you know, cameras and phones didn't stop professional photographers having a you know, a business. It just opened up a different set of pos possibilities. And I think that that's certainly the no code aspect and then nudging into low code, that's much more the some people will be coming in from the programmer side, but others are gonna be coming in from other numerate disciplines. And I think that's the, there's this kind of liminal area when you actually find out where people come from. When they end up in software development. You got a few people who went through a kind of computer science or software engineering background, but then you got a lot of people who came through sort of middle territory.  you know, they, they, they did a, they, you know, they came through the sciences or they came through business. you know, business with a bit of it or and they ended up picking up programming and then moved into software development as a whole. But for a while, they were kind of a little bit in between and that you, if you start looking at that as a grouping of people and a set of opportunities rather than thinking of it as productivity, think of it in terms of people who, who does this benefit, what does it do? That is different. Because that's the bit, that's why it might stick around and the and but it will also show you and this is the thing that spreadsheets teach us is most people use spreadsheets to put numbers and shapes, you know, they, they use it for pretty formatting and most people do not use the advisory. 

There's a few people who really get into formula and then there's a few people who are super power users who get into actually. Yeah, I'm gonna use VBA and stuff like that. So that again, it's that Power Law type thing and that I think again, tells you something else about the shape of the adoption and why certain things might stick where and certain things might not stick. So I think that when we look at Java and the JVM from that point of view, I don't think it's the Java stuff it may come about for low code stuff that takes Advan. Yeah, takes advantage of particular business workflows. In other words, here's a typical business workflow. You get to customize the front end, you're never actually gonna see the Java code, but it's all Java libraries, somebody has provided that and it's running on the JVM. So you've got this multiple targeting, you can shove this in the cloud really easily without having any deep discussion about native platforms and so on.  And so therefore, you've got something that is there as long as you've got access to those libraries that that's, that's incredibly powerful. So it, it will be, it will continue to be there, but somebody needs to provide that they need to provide the workflows.  There you go. You know, so I think that, so I think that that is where, so I although I know people are pushing the productivity aspect, I don't think that's the issue. I don't think that's gonna make the big difference. I think it's to do with, I think it's to do with communities and possibilities There. And cos I've never really seen any of the productivity benefits of anything that claimed to, you know, was pushed just for productivity reasons. Really take hold for that reason. Normally these things have taken hold for if they've stuck, they've stuck for other reasons. And that I think is, I think that's where that's what could be a differentiator here,

David Brown

Kevlin author of 97 things. Every program I should know. Thank you for joining us today. How can our listeners follow you and stay in touch with the things you're talking?

Kevlin Henney

I am easily stalked pretty much everywhere because my parents were generous enough to give me an internet unique name. So Kevlin Henney is easy to find on the web. I'm on Twitter. My handle is my name Ditto for Instagram. You can find me on linkedin. that actually just as kin. I think that's my linkedin URL. So, yeah, I'm very easy to find. You know, I'm definitely not dark on the internet.

Kevin Montalbo

All right. That's a wrap for this episode of coding over cocktails to our listeners. What did you think of this episode? Let us know in the comments section from the podcast platform you're listening to also, please visit our website at www.torocloud.com for a transcript of this episode as well as our blogs and our products. We're also on social media, Facebook, LinkedIn, Youtube, Twitter and Instagram, talk to us there because we listen, just look for Toro Cloud on behalf of the team here at Toro Cloud. Thank you very much for listening to us today. This has been Kevin Montalbo for Coding over cocktails. Cheers