Getting to Know IntelliJ IDEA • Trisha Gee & Helen Scott

This interview was recorded for the GOTO Book Club.
gotopia.tech/bookclub

Read the full transcription of the interview here

Trisha Gee - Lead Developer Evangelist at Gradle, Java Champion & Co-Author of "Getting to Know IntelliJ IDEA"
Helen Scott - Developer Advocate at JetBrains & Co-Author of "Getting to Know IntelliJ IDEA"

BLOG POSTS
helenjoscott.com
trishagee.com

DESCRIPTION
We’re frequently taught to use a text editor when we’re learning to write code so that we understand the fundamentals. However, if we treat our IDE as a text editor, we are doing ourselves a disservice. As professional developers, we no longer need to learn the fundamentals; we need to deliver working applications. We can use the features of an IDE to help us with this.

IntelliJ IDEA is an extremely fully-featured IDE that can help professional developers with almost any task they need to perform, and this can be overwhelming to get to grips with. Getting to Know IntelliJ IDEA uses two approaches to help newcomers and experienced users alike:

• Tutorials that walk through writing code and developing applications that show when, why and how to use IntelliJ IDEA features to create working applications.
• A questions-and-answers approach that demonstrates which features can be used to solve the problems that professional developers face.

Seeing how to use IntelliJ IDEA from these different angles not only showcases the most useful features but also teaches multiple approaches for using these features. No matter which technologies you use or how you like to work, reading this book will help you find an approach that enables you to work comfortably and productively with IntelliJ IDEA.

* Book description: © leanpub.com

The interview is based on Trisha's & Helen's co-authored book "Getting to Know IntelliJ IDEA"

RECOMMENDED BOOKS
Trisha Gee • Getting to Know IntelliJ IDEA
Trisha Gee, Kathy Sierra & Bert Bates • Head First Java
Kevlin Henney & Trisha Gee • 97 Things Every Java Programmer Should Know
Michael Nygard • Release It! 2nd Edition
Aditya Y. Bhargava • Grokking Algorithms
Ford, Richards, Sadalage & Dehghani • Software Architecture: The Hard Parts

Twitter
Instagram
LinkedIn
Facebook

Looking for a unique learning experience?
Attend the next GOTO conference near you! Get your ticket: gotopia.tech

SUBSCRIBE TO OUR YOUTUBE CHANNEL - new videos posted daily!

Transcript

Intro

Trisha Gee: Hello, everyone. And welcome to this episode of the GOTO Book Club series. Let's do a round of introductions. I'm Trisha Gee, I'm a Java Champion. I used to be the Java advocacy lead at JetBrains and doing developer advocacy for things like IntelliJ IDEA.

Helen Scott: Thank you. Yep. I'm Helen Scott, and I'm the current Java advocacy lead at JetBrains. And we're both hosting and guesting, I'm not sure if that's the word, but we're gonna be hosts and guests on this episode of the GOTO Book Club series. And we are going to be talking about our book, "Getting to Know IntelliJ IDEA," which is available on LeanPub, and hopefully, there's just a copy sitting right on my desk here. This is a bit of a story. It was two years in the making, so there's quite a lot that we want to talk about.

Why a book on IntelliJ IDEA?

Helen Scott: But I guess the first question that I wanna ask Trisha is, let's start at the beginning. Why did you want to write this book in the first place, Trisha?

Trisha Gee: Well, mostly, I wanted to write a book. I've wanted to write a book for a long time. I was involved in doing research for "Head First Java," like, absolutely ages ago, which at that time, didn't really go anywhere. And then 2020 came around and we weren't doing conferences anymore, and it felt like, "Oh, I've got loads of time on my hands. Let's write a book." And I thought about writing a book with you, Helen, because I'd helped to edit "97 Things Every Java Programmer Should Know" and helped to put together a bunch of pieces for that. And I asked you, Helen, if you wanted to do that, and you were like, "Oh, well, I don't really have time right now. I'm not gonna do it." And then afterward you were like, "I wish I'd done that."

Helen Scott: True story.

Trisha Gee: True story. I mean, I wrote about this in my most recent blog post about the whole history of which book we were gonna write. And there was a bit of backward and forward, we were thinking about doing the Head First book, and we were thinking about doing some other bits and pieces. But ultimately, you and I came to this conclusion, "Let's do something easy, which will be quick, which we both know. Let's write something about IntelliJ IDEA, and let's try and do something, which is kind of an introduction to IntelliJ IDEA, whilst also having some useful reference material for experienced users." And, well, basically, junior through mid-level, all the way up to experienced users. So that was our easy option of the book that we were going to write. Which does lead me to my question to you, which is, what motivated you to write a book with me when I asked you, do you want to write a book?

Helen Scott: Well, you've already covered one of my motivators, and that is regret. You asked me to contribute to, "97 Things Every Java Programmer Should Know," and I didn't. And I regret that even to this day. So, I thought, I've let one opportunity pass me by, I'm not gonna let the second opportunity go. So, many reasons. I think probably the main one was I knew I would learn a lot. I wouldn't just learn a little bit, I would learn a lot. I mean, you have been using the product for how long, actually, 20 years? More?

Trisha Gee: No, not that long. The first time I used it was in 2006. No, I was using it on and off up until 2009. And then I basically have used it ever so constantly since then.

Helen Scott: It's just that I knew that I could not just learn about the functionality, but learn about how you specifically use the functionality and you use it in anger. So that was a strong motivator for me because I really like learning. I've always wanted to be an author. I am an author now, which is super cool, but I'm not just a wannabe author, I'm an actual author. And I knew if I was going to go on that journey with anyone and anyone who was going to help me and us get across the line, it was going to be you.

So, I knew I wanted to be part of the project. I didn't know it was going to take two years, but we'll come onto that. But just your enthusiasm, you have so much enthusiasm for the project. And I can still remember the conversation. It wasn't a loaded conversation at the time. It was just like, "Do you wanna write this book with me?" And it was only when the project went on, that I started to get a better understanding of what I said yes to, but I am so glad I did. Honestly, I'm so glad I said yes because you had so many awesome ideas. You had all these, you wanted the book to be quite tutorial driven, to start with, didn't you? But we kind of steered away from that a little bit.

Trisha Gee: Yes. I think what you've just said reminds me of something which I had sort of forgotten, which is, one of the things I've always tried to do to develop advocacy for IntelliJ IDEA and one of the things I wanted to do with this book, bearing in mind that I no longer actually work for JetBrains, and this is really about me trying to express to people how I use IntelliJ IDEA, not the features. Like, here's this button and it does this, and there are these things. The reference help documentation is very, very good for that.

I really wanted to have an opportunity to show the workflow, which is quite difficult, especially in a book form. It's quite difficult, which is why I was thinking about tutorials a lot, to begin with, like, "Do this, step through this, press this button, use this keyboard shortcut." And really try and encourage people to actually get their hands on the keyboard rather than just reading the book, and step through and feel what it's like to code with IntelliJ IDEA. Because the main motivation behind that was that, as I said, I've been using IntelliJ IDEA for over 10 years. Before then, I did use Eclipse and other IDEs as well. And I used IntelliJ IDEA but before then, but only when I was pairing with other people who really knew how to use it, did I have that light bulb moment of, "Oh, this is what an IDE is for."

That's what I really wanted to put across in the book. Like, not just it has these features, okay, I have to remember to do that, but really get people into the workflow of how to be thinking, what to be doing, what your fingers should be doing as you are doing a specific thing. And that's why originally I was thinking about tutorials because that kind of encourages people to get their hands dirty and really learn through doing.

One of the reasons we ended up moving a bit away from tutorials is that they're very, oh, what's the right word? They can vary a lot with the versions of IntelliJ IDEA. So, this button moves over here. The keyboard shortcuts tend not to change, but the functionality can sometimes be simplified or buttons move around a bit. And I know we're gonna talk about that a little bit later on in the call as well. But the tutorial, the step-by-step way does not date very well. And so what I really wanted to do when I started thinking more about, what I want the reader to get out of it and what you were sort of feeling back to me when you were sort of saying what you thought was valuable in this book was this mindset, the IntelliJ IDEA and mindset.

What sort of mental models do you have in order to work effectively with the IDE? And tutorials were just one piece of that picture. Tutorials are like, "Right, get your hands dirty and start to feel the flow of it," but then there are other ways to showcase, you know, what the IDE can do, where you should be looking when you want to achieve certain things. And I think we kind of wanted to pivot more towards that, how should you be thinking, where should you be looking rather than this is a tutorial for building a Gradle project, for example.

Helen Scott: Interesting that you say that, you reminded me of something else that I wanted to mention. My background for those of you listeners who don't know is very much in technical writing. So, it's kind of Java, technical writing, back to Java. And one thing that Trisha and I definitely didn't want to do was duplicate the online help because the online help's already there and it's great and it does not need duplicating.

So, one phrase that we used throughout the project, and we started this quite early on, was, why? "Why does the reader care about this thing? Why are we even doing this thing?" And that helped kind of keep us honest about our purpose. Something else that really helped, and the reason I mentioned that my background is strongly in technical writing was, I found it quite hard at times to pull myself out of that product documentation space. And Trisha \really did a great job of, you know, very nicely guiding me and saying, "Well, yes, but that's in the online help. We don't need to duplicate that." And then we would come full circle of, "Why? Why are we doing that thing? Why does the reader care?" We were at times quite brutal with that.

Trisha Gee: We were, and we threw stuff away when we couldn't come up with a why. If the why was literally like, "God, it just feels like a thing people should know, but..."

Helen Scott: Because we want to.

Trisha Gee: Because we want to, because, you know... And sometimes that thinking it's something they should know will lead to the why, but sometimes it's like, "No, this is just literally scratching our own niche. This is not necessarily..." We did throw away some chapters with great pain in our hearts. I want us to talk about something else you said about your technical writing background. And so, your technical writing background with your sort of experience writing reference documentation. My blogging background with doing much more informal messaging, if you like, I thought was interesting having us work together because you helped me to formalize my language for a book, which is a little bit different.

Technical books should be a little bit more chatty than a lot of technical books can be, but not necessarily quite as snarky as we wanted to make the book. But I think we constantly had a good tension between you wanting to sort of, I was gonna use the word sanitize the language, like, formalize the language and me just trying to get a little bit away from that technical writing reference documentation. It's okay to have opinions and it's okay to express ourselves as human beings.

Helen Hints and Trisha Tips

Trisha Gee: This actually, coincidentally, does lead me to my next question, which is, how did we come up with the Helen Scott Hints and Trisha Gee Tips elements that we added to the book?

Helen Scott: I remember this conversation. This was such a cool conversation. So, I want to say it was quite early on in the book. And one thing that I'd been encouraging you to do, Trisha, to get your knowledge and your experience in this book, where there was something that was really helpful and wasn't obvious, you know, to most developers using it. So, it might not be obvious, might be a little bit out to one side, but, Trisha Gee, you'd used it and it saved you a lot of pain, or whatever it had done. And I wanted a way to surface that experience and that knowledge in the book without it being hidden in the general flow of the book.

So, Trisha’s Tips were born, this element that we have Trisha’s Tips, which is where if it's something that generally intermediate, more advanced users of IntelliJ IDEA might benefit from, then we called it Trisha Gee Tips. So, when you see one of those as you're going through the book, you know that Trisha Gee is calling on her extensive experience with the tool, and with the language, and has some golden information to share. And then as we got more and more of these Trisha’s Tips through the book, you actually reflected back to me, Trisha, that it was starting to feel a little bit one-sided. And what could we do about that?

Trisha Gee: I didn't want it to be my book with all of my crap in it. I mean, I collaborated with you, not as a ghostwriter but as someone with your own experience to bring to the book. And it just felt really right to have Helen's Tips. And then we were like, "Wait a minute."

Helen Scott: That doesn't work though, does it? I'm not sure if a glass of wine was involved in coming up with Helen's Hints, but, you know, it's a nice bit of alliteration. And, you know, Helen Scott's Hints were born, and then that felt a lot more natural, I think it's fair to say, it felt more natural to both of us that it also helped solve, well, solve is a bold word. It also helped address something that we were both keen to do and that we wanted the book to appeal to all developers who might use or are using IntelliJ IDEA regardless of experience. You know, we really wanted to take developers who've never opened the tool before, and then developers who've maybe been using it a few years. But with any enterprise tool, there's always gonna be parts that you haven't fully investigated because we don't have time...

Trisha Gee: It was a challenge.

Helen Scott: ...or we don't have a process.

Trisha Gee: Given how old the tool is sorry, mature the tool is, not old. Given how joyful IntelliJ is and how many users there are, it's a challenge to pick the target audience. And Helen's Hints and Trisha’s Tips were quite a nice way to signpost because what we wanted really was to signpost stuff throughout the book and make it easy to skim if necessary.

Helen Scott: I think they do that because generally the Helen Hints are more aimed at users who perhaps are newer to IntelliJ IDEA or even newer to Java, or might be going, "Yeah, but what does that setting actually do for me?" Whereas yours your Trisha’sTips definitely call on your extensive experience. And I've used this in anger, be aware of this.

Trisha Gee: YesBut it was a nice place to be because otherwise, the text would've been, I would've had loads of things in brackets as I just put, in my opinion, halfway through every single step. It was a nice way to be able to say, "Yeah, we've just given you three different keyboard shortcuts, and let me tell you my preference and why it's my preference," for example.

Helen Scott: Exactly. The expressing opinions make me smile with you saying the brackets and the tension that we had between me wanting to sanitize the writing and you want to get all your opinions in there because I took out a lot of brackets.

Trisha Gee: You did take out a lot of brackets. When I wrote my last blog post, which I... Well, I've written two blog posts on it, but one isn't published yet. I was like, "I'm putting brackets in here and I don't care."

Helen Scott: Oh, brilliant. But Trisha’s Tips, and Helen’s Hints, I think we're both pleased with how those elements turned out. And they came about at the right time, and hopefully, convey different types of information to different users, at least that was our goal.

Favorite chapters in the book

Helen Scott:  I think the other thing for me that became quite apparent as we were going through the book was, I mean, we both enjoyed writing the whole book, easy to say, but equally, there were different parts that we enjoyed more. I think it's fair to say, there were some chapters that maybe I found were quite challenging or you found were a bit of a slog. And then there were other chapters we were like, "Right, let's go, let's do this." What do you think or what chapters did you enjoy the most, Trisha?

Trisha Gee: I started with the tutorials because they were the easiest. And once we'd identified the sort of really basic level stuff we wanted to cover, the tutorials were easier to write because I knew what I wanted to put in there. Although I did second guess myself a lot of times about doing a bit of test-driven development in there. But on the other hand, they're more time-consuming because you have to step through and get them right and put the screenshots. So, later on, once we moved to Part IV, and Part IV is, for those who have not read the book, Part IV is more like, "Let's take a feature, if you like, a feature of the IDE, and let's explore it a little bit."

Once we started getting into Part IV, originally, that was quite difficult because this is basically the reference part of the book, which was where we ended up in that tension between the online help already covers some of this stuff, but it doesn't really tell you, like you said, why you wanna use this feature, or what it's for, or how it helps you. And getting our angle into the chapters in Part IV, to begin with, like, run configurations is the one I really remember because, I was like, "People need to understand run configurations. Ninety percent of the time, you don't use them, but for the 10% of the time when you do use them, you are completely lost if you don't have some sort of very basic understanding of what a run configuration is and why you need it, where it is, and what you do with it." And I didn't wanna just take the run configurations dialogue and annotate it because, I mean, you could do that, but that didn't feel very us explain it that way.

Helen Scott: We did do that at one point, didn't we? And then we threw it away.

Trisha Gee: It's what we started with, and we threw away that bit right at the very end. Like, in the last two months, we threw away that. But that's what I thought we were gonna do with Part IV is we'd take an area of IDE, annotate it, and that would give us a chance to kind of explain how and why. But it didn't really work as well as I hoped it would. And with the run configurations, what I ended up doing is, like, asking why, what do you wanna do with the run configurations dialogue? And the answer is, how do I pass in arguments to my application? How do I set environment variables? How do I have more than one run configured...? Why would I need more than one run configuration? How do I share the run configurations with my team? Once you start asking those questions, what do you use this for? Why is it helpful? And then that's how we ended up coming up with the format of the frequently asked questions in Part IV.

And that suddenly became, that was, like, a light bulb moment of, "Ah, this is how we can get the important parts of the IDE across to the reader without having to explain every single stupid button." You know, because half the buttons, we could even say, in fact, we did say in some places, just ignore these bits. Like, if you need them, the help documentation points out what they're for or there's a blog post somewhere else. And that was another thing we did quite a lot of. We don't wanna repeat ourselves a lot. So, if something already existed somewhere else, we'd be like, "Go over here and read about it somewhere else. We're not gonna cover that because it's already been done."

But doing the frequently asked questions thing, really was a great focus for me to be like, "What do I use this for? When do I use this?" And I'm sure we've missed some use cases. I'm sure there's a bunch of stuff that we have not covered, but it was a nice way of sort of hitting the 80/20 rule, except that it's sort of the opposite. It's like, you know, most people only use about 5% of the features. Like, how do we cover the 5% of the features for the 80% of the use cases that you're gonna be using them for? So, I haven't picked a specific chapter, though probably "Run Configurations" is probably one of my favorite chapters in the end because I really struggled to get into it. And then once I got there, I'm like, "Right, I really get why I'm writing about this. And I think that this has not been done in this way before. And I think it'll really help users of IntelliJ IDEA to understand how and why to use run configurations." And I do know we struggled... Sorry. Go ahead.

Helen Scott: No, I can remember all the iterations of run configurations and all the, "Ah, we've gotta do this chapter again," conversations.

Trisha Gee: And on the topic of chapters that we had to do again, surprisingly, the chapters that cover features that I use the most, especially using live demos, were the most difficult ones. So, live templates, inspections, and intentions, I made you do those. I was like, "I don't want to do them." And then we both ended up iterating over those chapters, at least twice each, didn't we? Because it was just...

Helen Scott: And again, we went back to why, why should the reader care about what an inspection is. Why should they care about what an intention is? And in the end, we separated the chapters out to be aligned to the use case rather than the feature, which I think...

Trisha Gee: That's true. We don't even have an inspections and intentions chapter anymore, do we? We have Errors and Warnings and Refactoring Your Code. It's just so much better, and I just can't believe we didn't think about that, to begin with. Again, a last-minute change really, we were like, "Why are inspections and intentions not working?" Because nobody is thinking about inspections and intentions. They're thinking about errors and warnings and changing their code.

Helen Scott: Yep, yep.

Different experience levels

Trisha Gee: So, yes. So, for me, the stuff in Part IV was actually the most satisfying to write because it felt like that's where we were doing the job of getting the information across. This leads me to my next question, which is, and we've touched a little bit on this with Helen's Hints and Trisha’s Tips, like, one of the challenges we had was trying to address this range of users that we have. We knew our primary audience really is people who are new to the IDE or, not new to programming necessarily because sometimes you enter into a new team and they're using a different IDE. And so we were thinking about these different types of users, new-ish to programming, new-ish to the IDE but also experienced users who know that there's probably some gaps in their knowledge or maybe just want to cement their knowledge or figure out how to do a specific thing. Like, how do you think, Helen, people can use our book, given they've got different levels of experiences?

Helen Scott: I think this is something that we tried to address with the various elements. But to give a little bit more detail, if you're new to IntelliJ IDEA or you've not been using it for a long time, obviously that is subjective, but let's say one to two years, I think reading the book from the front to back could be really helpful for you. You will absolutely learn stuff, you'll categorically learn stuff about the IDE that will improve your day-to-day job because we didn't write the book to make the IDE shine so much as we wrote the book to help you to shine because that's what it's all about.

So, there's reading front to back, and there's dipping in and out as well. This can be for any users who might just... And you might be that kind of person that doesn't really read technical books from front to back. I mean, there are lots of us out there, we tend to just go, "Oh, I wanna learn about that" and go in there and skip to that page. Part IV as well, that Trisha's spoken about. Part IV has had such a journey. It was not supposed to be so big, to start with. But as we went through it, we realized that there was a use case for it. Because as you get more experience with the IDE, you are more familiar with the names of some of the pieces of functionality.

So, for example, local history or clipboard history, I'm on all the histories today, build tool window. There might be stuff in there that you're like, "I just want to learn how to use this feature better." And then you can scan through Part IV and you can go, "Okay, today, this Friday afternoon, I'm just gonna pick that chapter because I know my knowledge around build tools is not quite where I want it to be. So, I'm gonna go read this and get some more information. And that will help me in the future to learn more about that specific thing." So...

Trisha Gee: Absolutely.

Helen Scott: Go on.

Trisha Gee: To interject Helen's point, build tools is a good example because build tools, debugging, and version control, we did those, but we did all of them twice in the book.

Helen Scott: At least.

Trisha Gee: We did an introductory level in parts 2 or 3, and then we did a deeper dive in Part IV. It's very much split up so that you can be, like, here's the higher-level stuff you're gonna use every day. And then here's the more detailed stuff with maybe some niche things that you might wanna know about.

Helen Scott: That's a great example actually. And just to build on that, I think it's something that you did specifically very well, Trisha, when you introduced the notion of things like build tools and debugging very, very early on, in the early tutorials even. And then we layered that knowledge. However, that doesn't mean that if you've been using IntelliJ IDEA for a period of time and you jump into Part IV, you'll miss out because all the code we've linked back, all the code is available for you on GitHub, if you do want to take a look at it. And we haven't made any assumptions that you've read earlier parts of the book. We might have referenced, "Look, we did this earlier on, if you want to go back and take a look," but we haven't then gone and created content that absolutely relies on you going through a very specific set of steps. We've just said, "Look, here's the code at that snapshot in time, off you go." And I think that's a really nice way of supporting users to read the book, however, they want to go through it.

Trisha Gee: Yes, I think it was nice for me to be able to put code on GitHub. There's obviously this code in the book, but the code in books is not very helpful because you have to type it all out. So, having it on GitHub is nice because we could, like you say, people can just download it and dive straight into the middle. They don't have to follow the tutorials right from the beginning. They've got examples of the projects and they can see how it should look in their IDE based on what's in the book and what's in GitHub.

What did you learn about the IDE?

Helen Scott: Exactly, exactly. So, a question that I have for you, Trisha. Given your extensive experience in the industry and with the tool, what did you learn about the IDE writing this book?

Trisha Gee: I actually learned quite a lot about run configurations since we talked about that. I realized there are some things that I do through sort of cargo cultism, if you like, like, just following a certain set of steps because it works and you've just always done it that way. Run configurations were kind of one of those things where I'm like, "I don't really have a good mental model of what's going on here." So, actually, I had to do a bunch of research really on what it was really doing and how it's supposed to work.

I did learn a lot about the way dependency management has changed inside IntelliJ IDEA. And this is one of those weird things where I've done a complete 180 because when I saw that there was a new dependencies window and it uses Package Search from JetBrains and it works in a very different way, I was like, "I don't need none of that. I know how to do my stuff. I can do stuff with Generate Code and with code completion and I know how the Maven Repository scanning works in the way that..." And I've written all of that. I documented all of that. And then as I got to learn how dependency management works in the new world order, I was like, "Oh, this is better. I don't have to write 600 different ways of doing it. It just works the same way every single time." And really, I changed my workflow based on that. So, those are the two main things I think that I learned. I mean, there's a lot of stuff. I also did a bunch of research on the version control part of the book. This is an early print, but Part IV, by the way, is more than 50% of this book.

Helen Scott: Yes, it is.

Trisha Gee: And the version control thing I think was 30 pages, and I was like, "How do I get this to the absolute bare minimum?" And, yes, it was about 30 pages of what's a merge versus a rebase and why it looks different in IntelliJ IDEA. So there's a bunch of stuff there that I learned. Obviously, there's a whole lot of stuff I learned in terms of writing the book, creating the book, Asciidoctor, Asciidoctor support in IntelliJ IDEA, which is freaking amazing, that we were using a build pipeline from Josh Long, which is his Spring Boot and Spring Batch and a bunch of other stuff there. I didn't know how GitHub actions worked before we built the book. I learned a lot of technical stuff while we were writing the book. There were a lot of GitHub actions in particular using those things. I had no idea how any of that stuff worked. And so, technically, I probably learned more in this last year writing a book than I have done in some projects where I've been writing codes. What about you? What did you learn about IntelliJ IDEA while you were writing the book?

Helen Scott: How long have we got?

Trisha Gee: Actually, not that long.

Helen Scott: Before I answer that question, I want to mention something that perhaps we should have said at the start that we used IntelliJ IDEA to write this book, as Trisha just alluded to. What did I learn? I learned so much honestly. It's a flippant comment to say how long have we got, but I'm struggling to kind of pull out the bits that I thought I learned the most about. If I had to, it would probably be debugging. I didn't realize just how much support IntelliJ IDEA's debugger can give you. And now when I'm asked about it at conferences or wherever, my advice is always, to learn the debugger before you need it. Because when you've got a bug or you've got support, banging on your door or whatever it is, you really want to have the tools to understand what your code is doing, why your code is doing that thing, or not doing that thing, as the case may be before you need it in anger.

And when Trisha started going through the different kinds of breakpoints, and the watchpoints, and all the different ways that you can manipulate your code, you know, when it's running. I was quite genuinely blown away by that. Build tools as well. There's just so much. There is so much. I was like, "Oh, that's really cool." I think as well there...it goes back to Trisha’s Tips. It's not just about the functionality, it's also about how you have used the functionality in anger. That, for me, was a really interesting thing to note. And like I've just said we wrote the book in IntelliJ IDEA. We were using Code With Me. I think it was still an EAP, actually, when we first started using it.

Trisha Gee: When I was doing my blog post on the history, I think when we first started writing we didn't have Code With Me. I think we were doing screen sharing and we were doing standups and going away and doing our own thing. I think Code With Me came in after a few months, and we were really early access internal to JetBrains.

Helen Scott: That's right, that's right. And, of course, you know, we wrote a book about a product, a product that is released three times a year. It's a massive enterprise product with lots of developers working on it. It's in a constant state of flux, which is awesome because it's constantly improving, but that did mean that we were working with a moving target. And there were some pretty major changes throughout that, weren't there?

Trisha Gee: Yes. I mean, I've already mentioned that dependencies changed. Well, I had to throw away, not quite a whole chapter but two or three big chunks of work that I'd done right at the beginning back in 2020. And I threw them away in summer, and with all the pain in my heart, I was like, "This still works, but it's not the way I would recommend people to do it anymore because the new dependency stuff is so much faster and so much easier." Before there were three or four different ways of doing stuff and it's like, "Oh, pick this if you like this or pick this..." And with the new dependencies window, it's just the same workflow all the way through.

The fact that changed underneath us, like, when we first started writing the book, I think that I did check it, I'll put it in the book. The dependencies window came in, I'm gonna say 2021. We probably had access to it a bit earlier, but I wouldn't have been using it early on, but it was a big enough change that it was worth throwing away stuff that I knew really well, stuff that we documented very early on. To document a new feature that's, I'm not gonna say it's not stable, it is stable, but they'll still be evolving it from here on outwards, which is, that's challenging too because we've documented this workflow and, obviously, the screenshots and the way it looks. And it will definitely change because it's still very much in progress. So, that was a challenge.

The other challenge was that we were racing against the clock to get the book out before 2022.3 because we'd done all the screenshots in 2022.2 and I was not going to redo them all over again. And also because we knew that there's this new UI coming for IntelliJ IDEA too. And knowing what I know about how IntelliJ IDEA works, when new features come in, particularly very visible features like the UI, there will be a lot of users who will continue using the old UI for a long time and you can keep it on the old UI. So, I'm not too worried about how dated the screenshots will get for the user interface, but I definitely didn't want us to release the book after a brand new UI went live because that would just be really, really frustrating.

The product changing, like, the new release...the product coming out three times a year, it was a race. And one of the reasons that we worked so hard on it over the summer was to get it out before the next release and to try and keep up with it. However, I think it also offers some really interesting opportunities, because we can continue evolving the book going forward or write supplemental material. We are definitely keen on... Like, big changes that come out that impact everyone, we're definitely keen on doing more stuff for that going forward. Even if it's just, you know, God, I hope it's only just like a one-sheet reference of, "Here's the new UI." Easy-peasy...

Helen Scott: It won't be.

Trisha Gee: I know it won't be because the screenshots took me two months and I'm gonna have to do them all over again. But it also validated our original approach of, we know the product is gonna change, we really need to focus on what I called the IntelliJ IDEA mindset. And I think we actually removed that from the book in the end, but I still think of it as the mindset of IntelliJ IDEA.

Helen Scott: The guiding principles.

Trisha Gee: The guiding principles, like...

Helen Scott: Guiding principles.

Trisha Gee: Really getting us to focus on the things that aren't going to change, for example, "Use refactoring tools, don't do stuff manually." I mean, IntelliJ IDEA actually makes it easy if you do stuff manually, these days, it still says, "You should probably refer to this." But, you know, assume that IntelliJ can keep your code compiling at all times. Don't try and break it and fix stuff up because, yes, you could do that but you're really not getting the most out of your IDE. You know, all of these sorts of things, give the idea in the book of the stuff that's not necessarily going to change. And the buttons might change, and the icons might change, but the underlying principles of you keep your code green, use the keyboard where you can, and tell me what the other principle was because I can't remember it. Always green, keyboard first.

Helen Scott: Oh, now, I've gotta check.

Trisha Gee: I can't remember this.

Helen Scott: Always green, keyboard first, in the flow.

Trisha Gee: In the flow. See? Because the flow is so difficult to actually document. But, yeah, try and keep that idea there, in the flow thing being so key is so difficult to talk about because it's so intangible. When you are working with IntelliJ IDEA, you should be assuming there's a way for it to do stuff so that you don't have to break your concentration. And no amount of changing the color of the buttons is going to change that for IntelliJ IDEA. It's always going to be about staying in the flow.

Helen Scott: Integrated.

Trisha Gee: Yes. Oh, yeah.

Helen Scott: Everything is worth the IDE.

Trisha Gee: Actually, this wasn't on our scripted things to talk about, you know, but the fact that we talked a bit in the book about how an integrated development environment, the integration that is important. And we tried to cover that with the stuff you were just talking about, teaching debugging early, teaching build tools early in the book because it's not about write "Hello world" and run it.

Helen Scott: No.

Trisha Gee: It's about when you're writing a real application, you will always be integrating with all these other different bits and pieces. You won't necessarily be writing code and then the next day, debugging, and then the next day, doing build tool stuff. You're constantly flipping between these different bits and pieces that you need to do. And the fact that IntelliJ IDEA is an integrated environment, helps you to stay in the flow and not interrupt yourself.

Helen Scott: Yes, definitely. Definitely.

Challenges when writing and self-publishing the book

Trisha Gee: So, then my question about challenges for you is that given this is your first book, what was the hardest thing about the whole book writing project?

Helen Scott: I think maybe I had some unrealistic expectations. When I say maybe, I mean, I definitely had some unrealistic expectations. I did at times struggle with motivation. I did not expect it to take two years. I did not expect a long break for you to work on "Head First Java." I'm super glad you did. Very happy for you. Very awesome. I think getting started after that was a bit of a, "Come on, let's just get it over the line." But you know what? I learned so much and I learned a lot about myself as a person. I learned a lot about how I work, I learned a lot about how you work, and I learned a lot about how we work together. And I'm trying to think would I do it all again? And I think I would, but maybe it's too soon to mention that. You alluded to this earlier, actually something else that we both learned a lot about, but I think you took the brunt of the self-publishing aspect, and as I said, we were using this pipeline from Josh Long. And what would you say have you kind of learned the most or what would you say are the pros and cons of that self-publishing journey?

Trisha Gee: I mean, one of the reasons we chose to self-publish, apart from the fact that the royalty percentage is much more generous, is that I thought, again, coming back to your point about unrealistic expectations and naivety, and you gotta bear in mind that, that I have worked on two books with O'Reilly before. I thought, given what we've done before with blog posts, given your experience with writing, given my experience with "Head First Java" where I had to control a lot of the way the book looks because "Head First Java" is very much like you use InDesign and you have to draw it all yourself. And so you do a lot of it yourself. You don't use the publishers for resizing screenshots and stuff like that. I thought, "Well, it's not that hard." All we'll have to do is, yes, I mean, even if you use a publisher, you're gonna have to take the screenshots anyway. You have to put them in a particular resolution probably. They'll do a bunch of layout and formatting and typesetting and proofreading.

And it's nice that they do that, but I thought, I'm not sure I wanna sacrifice so much of our royalties towards a publisher just for that. But I think in retrospect there are certain things where...I think there's gonna be certain types of books where a publisher just makes things a lot easier because you just... I mean, when we were doing the proofreading, for example, which, in retrospect, I think we did the proofreading a little bit early because we made quite a lot of changes after the proofreading stage. I think it's nice to have someone else do that for you and you don't have to do it yourself. It's nice to have someone worry about page breaks and layout. And we don't even have a lot of control over that because, you know, we're using AsciiDoc and we're generating a PDF. We don't have as much control over that as we would like anyway.

So, there were a lot of challenges. And keeping the pipeline up and running... Every month, GitHub action was telling us we were nearly out of free minutes every month. I think it was the right decision for this book. As you say, I think we learned a lot. One of the unexpectedly good side effects of self-publishing for this book is once we had decided we were finished, we just hit publishing, it was out there.

Helen Scott: It was Sunday evening, done.

Trisha Gee: It was Sunday evening. My dad was coming to see me on Monday, and I'm like, "It's gotta be done before dad comes because I'm not spending any more time on the book." You just hit publish and it's out there. And the great thing about publishers is that you give them the book and then they sort everything out and they make it pretty and they publish it. But, like, "Head First Java," I finished the majority of the work on that, I think, in early February and I didn't get a physical copy of the book till June. And it's a long time to wait for that feeling of gratification, you know.

And with this book, because we were sort of fighting these product release deadlines, it was really important that we could just publish the book as soon as it was ready before 2022.3 came out. We had a lot of control over it, if we want to update the screenshots, we can just update the screenshots and publish a new version. And there's a lot less of a lead time between us making changes and it getting into the hands of the readers. And I actually think that's probably the main advantage for us right now.

Helen Scott: So, you're already talking yourself into updating the screenshots there.

Trisha Gee: Well, we have to really, don't we?

Helen Scott: We do. We do.

Trisha Gee: Because the new UI is actually really cool, and I think it's gonna look really nice in the book.

Helen Scott: It is. I completely agree.

Outro

Trisha Gee: I think that's all we wanted to cover. I mean, we had lots to cover and there's loads more than we could say. But I think the final thing to really say is, please buy our book. I wrote a blog post on the history of writing the book, including why it took two years to do, which you should be able to find at trishagee.com/blog.

And Helen wrote a much better blog post about what's actually in the book and how it layed out.

Helen Scott: Yeah. So you can find my blog over on my website, which is helenjoscott.com. So if you're wondering what's in the book before you buy it, this is the blog post to look at because I've got screenshots and some screenshots of the guided tutorials, the Trisha Tips and the Helen Hints that we've spoken about and the chapter summaries. It'll give you a really good overview of how the book is structured and what's in there.

And like Trisha says, it doesn't matter whether you've been using IntelliJ IDEA for years or any number of years or if you've not used the product. The goal of the book was to help or is to help you be awesome. So whatever your experience and your journey, I'm confident that you will learn something from it. Talking of which, we should tell people where to find the book, right?

Trisha Gee: Yes. I was just thinking that you can go to leanpub.com and search for “Getting to Know IntelliJ IDEA”. Hopefully, it might be on the home page because it sometimes makes it into the top ten as the home page. But if not “Getting to Know IntelliJ IDEA” and you can find it there and you can buy it from there.

Like Helen says, our goal really is no matter what stage in your journey you are. There should be something in there for you if you either use IntelliJ IDEA or have vaguely thought about getting started with it.

Thank you, Helen, for talking to me as usual, like we don't talk to each other every day. This is it, thank you.

Helen Scott: Yeah. Thank you, Trisha. Pleasure as always to chat. And to do it in this forum has been wonderful. Thank you.

Trisha Gee: Thanks a lot. Bye

Helen Scott: Bye