Helen Scott, Co-Author of Getting to Know IntelliJ IDEA

The transcript below is unedited output from OpenAI Whisper.

====

Hi, I’m Len Epp from Leanpub, and in this episode of the Front Matter podcast, I’ll be interviewing Helen Scott. Based in the UK, Helen is a lead Java developer advocate at JetBrains, the well-known software development company, and a growing source of Leanpub authors. You can find her on Twitter at Helen Jo Scott and check out her website at HelenJoScott.com. Along with her colleague Trisha G, Helen is the author of the Leanpub book, Getting to Know IntelliJ Idea. Level up your IntelliJ Idea knowledge so that you can focus on doing what you do best. In the book, Helen and Trisha use a combination of tutorials and a questions and answers approach to help you find ways to use the IntelliJ Idea integrated software development environment that enables you to work comfortably and productively as a professional software developer. In this interview, we’re going to talk about Helen’s background and career, professional interests, her book, and at the end, we’ll talk a little bit about her experience writing. So thank you very much, Helen, for being on the Front Matter podcast. Brilliant. Thanks, Len, and thanks for inviting me. It’s great to be here. And that was a perfect introduction. Thank you. Almost. Perfect. We were talking a little bit before we started recording about how hard video is. I always like to start these interviews by asking people for their origin story. So I was wondering if you could just talk a little bit about how you first got into programming and technology. Do you know, I’m never sure if people have a, if there’s like a typical route into this because everybody I talk to, they have a different story. For me, I graduated quite some years ago, over 20. And I took the course that I did in part because I could, to some extent, see the writing on the wall in terms of technology. And I was like, right, if I do that, then there’ll be a job at the end of it and all the rest of it. I also had some kind of external pressures being applied of, you know, try this or do that. So looking back now, I see I was quite woefully unprepared. I was kind of young and potentially a little bit stupid, to quote the phrase, but I ended up doing the course, computer science. And I look back and I go, I don’t really know how I did those three years at university, because every single one of them was kind of marked by something different. I can remember in the first year meeting some great people, including Tricia G, as it happens. And then the second year, so much study, so much study. And then the third year, I didn’t quite believe that I’d done it, I’d got my degree, it didn’t really feel real. But then I made the mistake of putting myself in a box and I still see this happening in the education system nowadays, which drives me potty. But the box I put myself in was, I have a degree in computer science, therefore, I shall be a Java programmer. Because as I’ve already implied, Java was in its infancy when I was doing my degree. So we were taught Java. And it was we were taught Java 1.1 to 1.2, if you want to apply a date to it. So I went ahead and I thought the only career open to me is Java developer. So that’s what I ended up doing. It was at a time that IDEs were not a thing. Even IntelliJ IDEA when I started, certainly at university and in my first role, IDEs weren’t a thing. They didn’t exist, even IntelliJ IDEA wasn’t around. So it was, I find it really hard. I would go as far as to say I struggled with it because I, well, not because I didn’t have the tooling, but I now realize the level of support that a tool, a good tool and the right tool for you can provide. But I struggled with a lot of the aspects and I realized, and indeed some very good friends of mine realized and told me that I was excelling at communication and I hadn’t really seen this for myself because I looked back at my, you know, you have to do a third year project at university and a bit of coding and a bit of a write-up and a bit of this. And I loved doing the write-up and I loved doing the interviews. I hadn’t really loved the coding part, but I went away. I ended up leaving programming after a couple of years because I wasn’t very happy and I wasn’t having a good time and I wasn’t in a great environment. I left the UK for a year. I went to teach English abroad because I didn’t really know what I wanted and I needed some time out. Yeah. You went to South Korea, right? I did. Yeah. Yeah. I just, I needed some time out and my mom said I couldn’t go back and live with her. So, you know, what do you do? So, she was right though. Whilst I was abroad, I did a long distance learning course in technical writing, which I enjoyed and I thought, hey, you know, maybe I can do this. And I came back, took my first role in 2003, probably should have read my own LinkedIn profile for this interview, 2003, I think it was. And I loved it, long and short of it. I loved doing technical writing and I realized over the years why that was. I still got to work with developers and I think they’re just a super awesome bunch of people. Yeah. Thanks very much for sharing that story. There’s lots I want to talk to you about when it comes to working with developers and things like that. But before we go on, there’s two things we should probably sort of clarify for listeners because not everybody who’s listening is necessarily a programmer or something like that. But so an IDE or integrated development environment is something. So coding is writing, but it’s the sort of joke I have. I think it might be my joke is that it’s the kind of writing where if there’s one typo, your book won’t open, right? So that’s a really good way of looking at it. Yes. Yeah. Yeah. And so the writing tools that programmers have developed over the decades are very sophisticated and including this idea of an IDE is that like it’s something you’ve got a keyboard and you’ve got it open on a screen. It’s an app basically, but it’s something that you use to write your code and because programming languages have repeated elements, like this is just one way into all the many things that these tools can do, but because they have repeated elements, you can build tools around that repetition and that repetition specific to a particular programming language. So with that description aside, what’s technical writing? Firstly, I just want to repeat, I love the way you described that. If your book has one typo, you can’t open it because that is exactly how I felt very early on in my career, that one mistake, but I didn’t have any idea where that mistake was. Nothing was underlined in red squiggly lines, that was just a mistake somewhere. I find it quite demoralizing, so great analogy. Technical writing is the process of creating, I’m going to widen, creating content for the end user. That’s fundamentally what technical writing is. A lot of people, not a lot of people, what technical writing used to be and to some extent still is, depending on where you’re performing the role, it’s creating the so-called user manuals. I think that’s quite an old-fashioned phrase nowadays, if you think user manual, you basically think of a two-inch A4 book spiral bound that you only look at when, well, you don’t really. We went from user manuals and we kind of levelled up to online help, which may or may not be online back in the olden days. It was often shipped as part of the product, especially for some software that has to be used offline, some banking products, perhaps anything in FinTech might not have access to the internet, same with some other industries, there are some restrictions. Now technical writing, the door is open, the world is wide. It is fundamentally content to help the end user with the product, and there’s lots of great exciting innovations now that we’re seeing in technical writing. It’s no longer dry user manuals that nobody reads, it’s a huge raft of content, it is a faster feedback, technical writing, this is probably a whole other rant, but it used to be the classic waterfall model of software development where you get the new analysis and then the design, sorry, analysis, design, coding, testing, technical writing, maybe, get squeezed, squeezed, squeezed, squeezed, and then the software goes out the door. I worked through those times, those were not good times in many ways, and then now we’re seeing technical writing function being part of teams as required, being called on, crossing many teams as well, which is often something that I did, so fundamentally that’s what technical writing is. Yeah, it’s super interesting when one thinks about, most listeners are probably familiar with the idea of a shift from waterfall to agile in programming, so for those who aren’t, you can think of waterfall and I like the cartoonish analogy of like, imagine someone, in advance of actually coding a program, someone got a Microsoft Word document out and wrote a 300-page description of everything that needed to be done in the coding part, and then they handed that off, and then people, it’s a cartoonish analogy, but the idea is there’s a detailed plan that’s done in advance, it is handed off to the programmers to bang it out and follow the rules, and then after that it goes to some testers who are under heavy pressure to find no bugs kind of thing, and the shift to agile was from something called the Agile Manifesto that a few people got together and said, hey, there’s gotta be a better way of doing it, and the basic idea there was to, again, to this sort of cartoonish way of putting it, is to just kind of loosen up, right, and get things out the door, usable kind of code out the door in people’s hands, whether that’s testers or what have you, and then kind of iterate instead of just following a step-by-step plan, you know, point by point, and as that changed, the need for technical documentation kind of changed as well, and actually speaking, so things about being hard and dumb, one thing you can do, there’s a certain kind of writing you can do to help technical writing you do, which is blog posts, and you’ve got a relatively recent one about change, different types of change that I’d like to go into, and we’ll put a link to a great video of you doing the presentation in the transcription of the episode, and so we’ll talk about this in the context of your career, and you’ve done lots of different things in lots of different places, which is interesting because it helps you speak to people about career progression and stuff like that, but what does a developer advocate do? Little bit of everything. Yeah, fun joke, if you ask a developer advocate that, we’ll all give you completely different answers. So I can only really speak about what I do. There are various facets to the developer advocate role that are both detailed and complex, but also the various aspects that really aren’t. I mean, for me, it boils down to a relationship and that’s what it boils down to. It boils down to a relationship between the developer advocate and the community that they serve. So you’re a conduit of information and you’re a real person. You are the relationship. So you’re not a marketing department, you’re not an engineering department, you’re not a developer advocate department. You’re a person that somebody can reach out and say, I’ve got a problem. This doesn’t work for me. What am I missing? Is there a bug in the product? So it’s that relationship. And then also it’s that relationship that’s kind of the internal to the external, but then there’s the internal to the internal. So it may be taking something that you’ve received externally internal and passing that on to the relevant people. Or it may be you using the product and saying that workflow doesn’t work or we’re probably going to need to change that or that’s a really annoying bug. And then taking that feedback and equally the other way, internal to internal the other way, the product team saying, can you try this? Does this work? What does this look like? So it’s owning that relationship. I’m going to pause there in case you have any questions. No, yeah, no, I do. I guess I just want to sort of set the context. So one example of the way that kind of this work as I understand it can work is, so let’s say I’m a programmer, I work at a big company. So there are lots of decisions that are made that affect my working life that I have no say in often. And so all of a sudden one day people are like, you’re using some people had a meeting and someone made an enterprise sale and you’re using IntelliJ IDEA as your integrated development environment now. And people are like, okay, I hope it’s better. But it’s going to be, you know, I’ve got a lot I’ve got to learn in the meantime. And so the vendor of the product might then have developer advocates who help people who have like now been like in their whole team or like, you know, a lot of people might be like, okay, yeah, like I’m learning this new product. Thanks for all the awesome document, like, you know, documentation and writing and stuff like that. But I’m having a problem here. Is that because I’m doing it wrong or is that a bug? And so the developer advocate is the person they could contact and say, hey, what’s up? Exactly that. It is. And that contact, that contact happens in various different ways. You know, you’ll get people coming up to you at a conference. You’ll get people reaching out to you on on social media. So Twitter, normally, you’ll get people emailing you, you get all sorts of kind of contact and requests for help. And sometimes those requests for help can come from internal as well. And we just, it might not be us that’s the right person. But what we can do is we can track that request through. And we can provide some ownership because ultimately, we want our community to succeed. We want the product to help them be awesome. Right? It’s not about the product. It’s about them being empowered in whatever way we can to do what they want to do. So that’s why owning that relationship is just it’s really important. Yeah, I know. I’ve interviewed a few people who’ve done similar kinds of work, although as you say, it’s different for everybody. But it is curious what a sort of complex, when you think about the complex thing, like there’s an employee at some company somewhere who’s having a problem. How do they get to the people who actually work on the product at another company and communicate like, this is actually important enough that maybe you should be dealing with it. But then there’s also, you know, anyway, I just find that like bridging that divide is so interesting. It’s one thing that, one of many things actually, that JetBrains is very good at even taking developer advocates out of the equation in that when somebody raises a bug, you know, I’ve seen it for myself, it gets prioritized, it gets looks at and, you know, no software company is perfect. There’s always bugs of people like, why haven’t you fixed that yet? But it’s a case of getting those bugs, getting them on the backlog. And, you know, sometimes we’ll look at a bug and go, oh, yeah, the one that I’ve come across that’s been duplicated a few times and I ran into it today and I was like, why is this not fixed? And I went into the tracking system and I had a look and I’m like, okay, right, that’s why. But it’s very transparent and I really like that because we can’t, doing everything is rarely achievable, but being transparent and being honest and being open about where things are at, that’s really valuable because that’s what builds trust. So, you know, it’s not necessarily the developer advocate needs to be involved to fix a critical bug because certainly for JetBrains, the team are excellent at doing that. It’s a case of sometimes we will be, somebody will contact us and then we might decide that we want to track that one through the system and work with that customer to make sure that they, you know, they can be set up for success. Likewise, sometimes it’s the role goes the other way. You know, there might be a situation where the product doesn’t do something that the developer needs it to do. And as a developer advocate, it’s not your job to say, oh, well, it’s on the roadmap. It’s your job to say, yeah, it’s not on the roadmap. But let me have a conversation and I’m going to come back to you with an open and honest answer because there’s no point saying the product can do something that the product can’t do and it’s not going to be implemented in the next two years. That doesn’t help the end user. So it’s just about being completely honest and saying what it does and at times what it doesn’t do. And another fascinating dimension of the job that, at least in the way you do it, is helping people with their careers basically and sort of giving conference talks and blog posts and things like that. And there was a couple of things, I watched a great one that you did with a sort of co-speaker called the Hitchhiker’s Guide to a Great Developer Career, Sven Peters was your co-speaker’s name. And so, yeah, I just wanted to talk a little bit about that for you know, because this sort of like with someone who’s, you know, had the experience you’ve had and sort of talked to so many people about it, there might be some sort of golden nuggets that you can sort of help people with. And one of them was the quite bracing line that I saw in this talk was that hope is not a strategy. And I was wondering if you could talk a little bit about what you mean by that. Yeah, when Sven and I were coming up with that talk, we got together over a number of meetings and we wanted to understand what one thing that the audience would leave remembering. Because a conference alone, right, you’ve got several tracks, several talks, lots of mental effort, lots of toing and froing, you’re a busy person at a conference. So it’s often important with conference talks to give people something to take away because they’re going to forget a bunch of stuff and that’s OK. So we came up with hope is not a strategy because we realized for both our careers, at times we’ve tried to employ hope as a strategy and it’s not worked. And we wanted to get that across and say, look, we’ve tried this, you’re probably going to try it at some point as well. But heads up, there are better strategies out there than sit back and hope. Equally, it’s not just about being kind of go get my career and have it all mapped out and in five years I’ll be doing this and in 10 years I’ll be doing that. That’s not what the talk says. It’s more about know what’s right at the time. This is something we talk about. Maybe you’re relatively new to the career and you’re new to the job. Your personal life is relatively calm and you really want to go for it. And you want to say by the end of the next year, I’m going to make the next level up in your company, for example. That’s the strategy. It’s also a really an equally good strategy to say, right now, there’s a lot going on for me. I’m focusing on other areas of my life. Work is not the peel and end all. I’m focusing on other areas of my life, whether that’s me, my family, my hobby, whatever it is. And work’s just going to tick along. I’m going to do my job and I’m going to do it very well. And that is equally, that’s an equally good strategy. Just to know where you are and that’s okay. But just sitting back and waiting for what you want to come to you is not usually a good strategy. So speaking of if hope isn’t enough, then on the subject of what you can do, one thing you talk about is building your kind of personal brand. And I was wondering if you could talk a little bit about what that entails and why it’s so important. So I, again, the talk came from another mistake I made in that I built my personal brand. What I actually did was I made a website. That’s not your personal brand. The things we learn. So for me, I realized after making the mistake, of course, that a personal brand is, it’s not about the website or the color palette. It’s about you. It’s about what you’re passionate about because we’re all different, fortunately. We’re all passionate about different things. We all have different drivers. We all get excited about different things. And it becomes really apparent, especially in the tech world, because a lot of us have the same skills, might even have worked at the same companies, might even have got the same professional qualifications. The world’s not that big at times. And when something I’ve discovered is when you’re a hiring manager and you’ve got this big old stack of CDs in front of you, because that’s still how we hire people, it’s hard. It’s really hard. And one thing that I found can help, and I’ve had feedback from other people who’ve tried this and it’s helped, is to create this online presence, if you will. And this online presence is linked with your personal brand or links together by your personal brand. So for example, it’s what you’re passionate about. So maybe you’re passionate about open source. Maybe you’re passionate about creating content. Maybe you’re passionate about giving conference talks. Maybe you volunteer, you do some volunteer work that is something that’s really close to your heart. That’s whatever you’re most authentic about. That, for me, is what your personal brand is. It’s not the website. It’s not the color palette. It’s who, not necessarily who you really are, because I totally respect and understand that privacy is very valuable. And we all portray, most of us, you know, online and we keep some things to ourselves. Of course we do. That’s very human. But there are some aspects of our professional life that we choose to share in terms of what we’re passionate about. And that can be, that can be form your personal brand. And then you can put that on a website or on Twitter or wherever. But then you meet, you meet people like you, you meet people who share similar passions and then you can have this wonderful, authentic, passionate conversation with that person. Whereas, you know, oh yeah, I worked at such and such a place and I’ve got such and such a degree. And those are my programming languages that I like to code in, which is, is cool, but it’s, it’s not as exciting as what you’re, you’re most authentic about, why you get out of bed in the morning. And so, for example, like let’s say someone was listening to this and they’re like, oh, that’s all very, very well and good, but how do I get to be one of the people on the stage at the conference? Do you have any, any sort of advice for people about how to become that person? To get into conference speaking? Yeah. Yeah. Yeah. Yes. I do have lots of advice on that. Firstly, if you’re in the UK, have a look at the London Java community. I know you might not be into Java, but have a look at the London Java community because they have various programs for, for conference speaking and getting used to it. That is the path I took. I would say strongly, get, get a sponsor. And what I mean by sponsor is somebody who will champion you, push you at times, be in your corner, tell you you can do it, shove you forward if necessary. Because I don’t think there’s many people who got into public speaking by going, I want to go into public speaking. Most of us got into public speaking because somebody else said, go do that thing, an existing public speaker, because it’s, it’s, it’s kind of hard at times and you get knocked back and you’re like, oh, I don’t want to do this. And then all the little voices start, at least they do in my head anyway. So a sponsor is somebody who can really push you. You can start small. If it’s not the London Java community, lots of other communities, no matter what tech is your thing. I’ve only got experience in tech, so that’s what I’m going to talk about. But go to a little meetup. They might do lightning talks. So these kind of five minute talks that you can do, just dip your toe in the water. It’s five minutes. Nothing bad is going to happen in five minutes. You can go, you can give a five minute lightning talk. If it’s your first one, it’ll probably take your hours to prepare and that’s fine. Certainly did. Then once you’ve done the lightning talk, you can do another, or you can scale up and do a 30 minute talk again at a user group. Then you’re up to a 50 minute conference talk, then start applying for conferences. And I, I am ashamed to say that I was too scared to apply for conferences for, for quite a while, because I was convinced that I couldn’t do that. I couldn’t possibly do that. And then I, I actually joined the program committee for one of the conferences on the advice of, of my sponsor. I said, go, go, go on the program committee. I said, okay, fine. We’ll go and do that. And the program committee are the people who they review all the talk submissions. And they are the people who say, right, that one’s going to appeal to the community. That one’s probably not, that one’s got no detail on. And in the end, they are the people that build the conference schedule. And it was only when I did that, that I realized I was good enough and I could do it because I saw some of the other submissions and I was like, Hey, I can do that. I can do that. And lo and behold, uh, I started submitting to conferences, got started getting accepted, also rejected, been rejected, um, quite a few times. So don’t take that to heart. Don’t take that personally. It will happen. And it’s, it’s easy to think when you get rejected from a conference that it’s you and it’s probably not, certainly not. You know, you’ve got to remember the program committee, they have to balance the conference. They have to balance all the tracks. They have other considerations as well. So if you get rejected, just move on. Yeah. That’s, that’s, that’s really interesting. It reminds me of, you know, the, the, um, one of the, one, one of the really good things one can do to expand one’s kind of, um, experiences to try and get on the, the, the other side of the desk, I’m going to say. Um, cause if you, for example, you know, in, in my, you know, sort of university years, I was the editor in chief of a couple of, you know, university papers. And once you’ve been on the side where you’re getting submissions, yeah. The, you, you understand how typically impersonal rejections are, um, uh, that there was just someone had only so much space and you know, it, yours wasn’t necessarily worse, you know, or, or anything like that. It could just be that they, you know, they’re sort of like, Oh, I see a theme developing in the selections I’m doing for this issue or something like that. Right. And the similar thing can happen with conferences, which I’ve, you know, I’ve done a little bit of that myself too. And, and, and particularly hiring, um, once you’ve been the one with the big stack of CVS, um, you know, you use, you, you do understand that it’s, it’s, it’s easier to internalize the fact that it’s, it’s an impersonal decision, that rejection that you got. Um, and what you should do is just try and try and, you know, maybe have a drink or whatever you need to do, but you know, sort of carry on and understand that, you know, this is not necessarily like, Oh, I have to give up on that. My plans to become a conference speaker. Cause I got rejected the first few times trying and get better. And again, it’s easier said than done, but getting on the other side of the desk for anything, basically, including creating podcasts or whatever is just a really great thing to try. Yeah, a hundred percent. It, it, it made a huge difference to me. And I, I definitely, you know, advocate for, for anybody to, you know, to give it a go. If you’re given the opportunity, definitely say yes. Um, likewise, if you ever invited to speak on a podcast, uh, say yes, because it’s, it might be a little bit out of your comfort zone, uh, but you will learn a lot from the process and it’ll be good for your personal brand as well. And I can say specifically on that note, the person, the person who invited you on, on the podcast, uh, or who, who accepted your application to be on the podcast wants you to do well, right? Like this is, this is something that’s also sort of like, cause I’ve got the voices in my head too. And like, you know, people want you to do well. Um, and that’s an important thing to remember as well. Um, just moving on. So, um, we, a little bit before we started recording, I sort of, we were talking a little bit about how to, how to structure the interview because typically we’d probably spend more time talking about the book than we will in this case, because I actually interviewed your co-author Tricia about it, but let’s just maybe just take this for, you know, people who’ve been waiting for this moment and don’t want to listen to that other podcast. Um, what, what is your book about? And, uh, how did it, how did it come about? So the book is getting snow intelligent idea. It came about, about two years ago when, uh, my co-author Tricia messaged me saying, I think I want to write a book and I want to write the book with you. And I thought, Oh, she’s potentially a bit mad. Um, but I, I said yes, because I known her a very long time and I know she very much has, um, a lot of experience and I would learn an awful lot from her doing it. So with her very longstanding knowledge of intelligent idea and, you know, she’s, as you know, you’ve interviewed her being a professional, uh, developer for many, many years. Uh, but what she was hoping to tap into with me was my new user approach. So being much newer to the IDE, because with all due respect, she’s been using it for years. So there are elements of it that she just skips right on by. Um, whereas for me, I’m like, no, wait, what, what does that do? So it’s tapping into that and also content creation, which is something that I love doing part of the developer advocacy role. Um, so we kind of brought together two, two very different approaches to very different skill sets to, to create the book, uh, which is of course about the IDE, intelligent idea by JetBrains. Yeah. It’s really, it’s really interesting. I love the way that you, you captured those two different perspectives throughout the book and these, these, these little call outs. So one is, one is Helen’s hints and one is Trisha’s tips. And so the Helen’s hints ones is the like, Oh, if I’m, if I’m, if I’m new to this, this might be the thing for me. And the Trisha’s tips one is the like, if you’ve been using it for a long time, actually, here’s something that even, even I just learned or forgot I knew. Um, stuff like that. Exactly. Yeah. It’s, it’s been the one, your other question, how is the book structured? Um, we, we didn’t actually set out with too much of a clear structure, but it became apparent relatively quickly, I would say. I’m now wondering what Trisha said when she did her podcast. Um, but it, we split it into four parts. So part one, uh, very much an overview, very much, uh, if you’re new here, let us show you around. Here are the elements we’re going to use in the book. Here are why we’re going to use these elements. And if you’ve never opened IntelliJ IDEA before, this is what you’re going to see. Um, then we went on a, a slightly deeper dive. Then we moved on to tutorials, which we built on throughout parts two and three. So we kind of built up the difficulty. So people can follow along all the codes on GitHub, which is great. If you’re that kind of, you know, you need to follow along to learn many of us are, um, or if you just want to read, you’re like, okay, yeah, I know how to do that bit, but I didn’t know that. That’s interesting. That’s what we, we hope to get from that because everybody’s different. We’ll have different learning styles. And then part four was, part four started so small and ended up so big. Uh, part four, we, we went for a more feature driven approach because there are certain features, many of them in the product that not even experienced developers, but you know, developers who’ve been using the product for a few months up to several years will recognize and skim, skim the index for, so something like code with me or local history, they’ll go, Oh yeah, let me just have a look at that and see if there’s, so it’s very much, you can dip in, you can dip out or you can read the book from start to back. Uh, I think I want to say the page count. Nope. Can’t remember the page count. Um, but there was a Like 500 pages in print or something that I read somewhere. And like, I think the, the ebook is, is huge because it’s a much smaller dimension. Um, I think it’s, yeah, it’s, it’s a few hundred. Um, it, it’s been a lot of work has gone into it and I, yeah. Yeah. Well, congratulations. I mean, it’s a great book and I would say for anyone listening and a lot of our listeners are actually sort of like self published authors themselves or people thinking of doing it. And like, I would seriously recommend, um, getting a copy of this book as an exemplar of what to do. Uh, Ellen and Tricia really know what they’re, they’re doing. Um, and, um, it’s, it’s really well, it’s just really well thought through and really well executed as an example of a book like this. Um, the last question that I always ask on the podcast, if the guest is a lean pub author is if there was one, um, terrible problem that you had with lean pub that had you shaking your fist at the screen all the time, or if there was one magical feature that we could build for you, um, can you think of anything that you would ask us to do? Ooh. Um, but there was no fist shaking. Uh, I shake my fist all the time. Feel like I’ve missed a trick now. Um, no, uh, we, we, we wrote the book in IntelliJ IDEA. We used the collaborative tool code with me and it worked. Um, we had, we had some nuances sometimes, but they were more to do with the code that we’d set up for the, for the build pipeline, uh, rather than on the lean pub side. So no, you, you get off on this one. Okay, good. There was, there was no fist shaking, no, no magic, um, no magic thing you can build for us. But if I think of anything, I will let you know. Yeah. Please, please reach out if you do. Um, uh, you know, we get some of our best, best ideas that way from people who are using the product and again, who, you know, aren’t like, you know, so familiar with it, like, like we are or whatever, but the, the, um, the thing that I just thought of one, but I know why you do it the way you do it. When we published the book on, it was a Sunday evening and we were going through, you know, final checklist. We’d been at it for hours just going, right. If we’d done that, if we’d done that, if we’d done that, if we’d done that, if we’d done that. And then we set the book to, um, published and we expected the slider to go to a hundred percent like, why is that not changed? But of course it’s because that’s exactly the lean pub model, right? You allow for books to be updated on the author schedule, which is also wonderful. So that’s the only weird thing I find. That’s, that’s so interesting. Yeah. Just, just for people listening who, you know, sort of the sort of whole lean publishing philosophy is that you should, we, we encourage people to publish their books as they’re, as they’re writing them, not appropriate for all writers, not appropriate for all writing projects, but for some it is. And so on lean pub, we have a feature where you can sort of set the percent complete, um, with a progress bar or whatever, and it’ll be 25%. Then you publish four new chapters and you set it to 50% or something like that. And it’s, it’s funny. It had actually never occurred to me before that someone might expect it to leap to a hundred percent at any particular point, but it actually does kind of make sense. Um, I was like, look, it’s done. It’s out there. Yeah. We, we have, it’s, it’s, it’s actually, that’s a super interesting thing because, um, uh, I forget who it was. It might have been one of our, our authors, Simon Brown, who sort of left his book at 95%. His, his, his, what he wanted to do was just leave his book at 95% forever because it was like a living book, like something he was always going to be working on, like editing and adding stuff to it. But then he would get people who’d be mad. They’re like, I bought this book three years ago and it’s still only 95% done. When are you going to finish it? And so he was, he was like, well, I don’t know if he swore, but he was like, whatever, fine. You know? And he, he finally, he got so much feedback like that, that he finally just set it to a hundred percent. But of course he’s still, he’s still updating it all the, whenever he got something to update it with. And it, it actually is just a curious sort of dimension of the whole sort of our approach to publishing where like books are changeable things. And, and sort of people’s expectations are kind of like something that it’s just, it’s just a constant thing to manage. You know, we don’t, you know, in, in a way, you know, it’s sort of like having a, marking a book as done is kind of like that might send a message that it’s not going to change. And you can just imagine someone going, Hey, I thought the book was done. You marked it a hundred percent complete. And now you added a chapter. Like, what are you doing to me? You know? Right. Yeah. That’s a really interesting one, isn’t it? I actually really liked the idea of the 95% because it’s a living book. I can, I can definitely get behind that, but I, I can understand why, why he’s changed it now. Yeah. No, we’ve, we’ve had one. I can remember just, just before I let you go, I can remember one specific example where we had sort of a, sort of like, you know, an actually relatively seasoned lean pub reader who contacted us about a book that we’d included in one of our weekly or monthly sales. And this person pointed out this book, because we also on our under, under the cover image for our lean pub book on the landing page, we show like last updated on or, or, or whatever. And this person pointed out, Hey, this book was last updated in 2018 and it’s only 80% done. You know, why, why are you promoting this, this unfinished book that the author’s not working on anymore? And of course the book’s like 400 pages long and amazing, totally worth it. And the author, I don’t know exactly what her, what her kind of her motivation was for doing that. But basically I think it was like she realized like she only completed 80% of her plan, but she realized that was enough for that book. So she was being kind of funny by leaving it. It was a little bit of a joke, like, you know, it’s 500 pages, but that’s still only 80% of what I was hoping to do at the beginning. You know what I mean? And so there’s, there’s just sort of interesting sort of communication issues around, around stuff like that, but there, but there, they also make it a little bit fun. And one thing we’ve learned too, is that like even something that starts as a negative interaction with a reader or potential reader can often end up being amazing. Once you explain to them what you’re up to, it’s that communication, right? That’s what really matters. Exactly. Well Helen, thank you very much for taking the time out of your evening over there to be on the podcast. And thank you very much for choosing Leanpub as one of the platforms for publishing your book. Great. Thanks for having me. And it’s been lovely to talk to you. Thank you. Thanks. And as always, thanks to all of you for listening to this episode of the Front Matter podcast. If you like what you heard, please rate and review it wherever you found it. And if you’d like to be a Leanpub author yourself, please check out our website at leanpub.com. Thanks.