JS Party – Episode #314

Take a look, it's in a book

with Adrienne Braganza Tacke & Dylan Hildenbrand

All Episodes

Nick delves into the intricacies of technical book writing with authors Adrienne Braganza Tacke and Dylan Hildenbrand. We talk about the process of working with a publisher, coming up with an outline, actually writing the book, and everything that comes after the book is finished.

Featuring

Sponsors

Fly.ioThe home of Changelog.com — Deploy your apps and databases close to your users. In minutes you can run your Ruby, Go, Node, Deno, Python, or Elixir app (and databases!) all over the world. No ops required. Learn more at fly.io/changelog and check out the speedrun in their docs.

Changelog News – A podcast+newsletter combo that’s brief, entertaining & always on-point. Subscribe today.

Notes & Links

📝 Edit Notes

Chapters

1 00:00 It's party time, y'all
2 00:55 A hoy hoy!
3 01:59 Getting to know Dylan
4 02:49 Getting to know Adrienne
5 03:50 Delectable explanations
6 04:59 Let's mention their books
7 06:19 On writing books
8 11:04 On reading books
9 17:53 Estimating (aka guessing)
10 22:39 Different publishers
11 23:12 Writing a book in Vim
12 27:43 Working with an editor
13 32:23 Sponsor: Changelog News
14 33:44 Looks Good to Me
15 35:59 SvelteKit Up and Running
16 37:48 Overcoming writer's block
17 41:00 Supplemental materials
18 44:20 Getting the book on a shelf
19 48:28 Book signings
20 50:29 Tips for new writers
21 53:06 Closing time
22 54:58 Outro

Transcript

📝 Edit Transcript

Changelog

Play the audio to listen along while you enjoy the transcript. 🎧

Ahoy-hoy. Welcome to another exciting JS Party. I’m your host this week, Nick Nisi, and I am joined by two amazing friends. First, I have Adrienne Braganza Tacke. Adrienne, how’s it going?

Not bad, not bad. Happy to be here.

Yeah, great to have you here. I don’t think I’ve really seen or talked to you since Nebraska Jazz Conf… Was it 2019?

Yeah, that was a life-changing conference, so this is kind of cool to be back here… But we can talk more about that later, if it lends itself to that.

You don’t have to flatter me with that, but I will definitely chat about that more. [laughter] Yeah, and we have another guest as well, we have Dylan Hildenbrand. Dylan, how’s it going?

It’s going well, thank you so much for having me. As someone who’s listened to the show for a while, it’s really exciting to get a chance to be a part of it.

Yeah, well, I’m excited you’re here… And the topic that we’re going to talk about today is writing books; writing technical books, to be more specific… Which both of you have done. I definitely have not. And Dylan, you kind of scared me away from it a little bit, if I’m honest… But that’s all good. It’s all good. So before we dig into that, Dylan, why don’t you kick us off and tell us a bit about yourself?

Yeah, sure. So as you said, my name is Dylan Hildenbrand. I’m lucky enough that I’ve been married to my best friend for 10 years, and we have two awesome kids together; a very curious seven-year-old and a very driven two-year-old. I’ve been a full stack developer for over 10 years, and I’ve worked primarily with the small teams, which has meant that I’ve had to learn a lot of different subjects, and become not quite a master at anything, and just be a jack of all trades type. So yeah, a lot of experience with small teams, and optimizing flows so that we can do the things that the bigger teams are doing, with fewer resources.

Yeah, well, welcome, Dylan. Thanks for joining us. And Adrienne, why don’t you tell us a bit about yourself?

Sure. Hi, everyone. I’m Adrienne. I was a software developer since 20– should I use years? I don’t want to use years. I’ve been a software developer for a decade, let’s just put it that way. Really cool, Dylan, is that I’ve also been with my best friend for 10 years. We’re both software developers. Today’s our 10-year wedding anniversary, so it’s a super-special thing.

Wow, congrats.

And you’re here with us?

Yes, of course. We have plans like tomorrow, because it’s Thursday. We have work, right? But yeah, and… Yeah, I’ve been a software developer for 10 years, I fell into developer relations, like I said, because of that conference at NebraskaJS, my very first conference talk… And so I pivoted into developer relations, and I’ve found out that I actually really liked the combination of combining, explaining or teaching technical concepts to developers or people who want to learn about that stuff. So that’s where I am today. I’m a developer advocate at Cisco.

Oh, that’s so awesome. That’s – yeah, that’s amazing. And for reference, that conference, NebraskaJS Conf, it was 2019, and the name of your talk was “Delicious JavaScript: Delectable explanations of the power of JS.”

Yes. I’m thinking back to it and all I remember from that is still feeling like, you know, these are all JavaScript experts; who is this person to tell them about array methods that they all probably already know…? And then I also very much remember that I screwed up at the end when I was trying to do the last part of my demo… But because the attendees there were so welcoming, and we kind of debugged and figured it out together… I was terrified. I was sweating bullets, because I’m like “Great, now I’m going to be even found out… Why am I on the stage?” But we found out together, and then once we debugged it and figured it out together, everyone was like cheering, and it was such a cool feeling to have that. It could have been very different. If the people were not as accepting or easy on me, then I probably wouldn’t ever have spoken at a conference again… So that’s why I say it’s a life-changing conference for me, for real.

That’s awesome. And yeah, I’m glad it turned out that way, because… Yeah, I had no doubts about Nebraska developers, for sure. [laughs] Alright, so we’re here to talk about the book writing process. So both of you have written books, and neither one of you mentioned that in your intro. So Adrienne, you’ve written a couple of books, is that right?

Yes, I’m currently writing one, and I have written another one. The first one I have published is called “Coding for kids, Python. 50 games and activities to play with your child, or learn.” And then the one I’m currently writing is “Looks good to me. Constructive code reviews.” So yeah, it’s a process, but I’ll leave it at that.

Awesome, awesome. We’ll dig into that process a little bit. Dylan, what about you?

Yeah, so my book is “SvelteKit up and running.” If you can’t guess from the title, it’s all about SvelteKit, which is this Svelte framework for building high-performance web apps, and compiling those into pure JS. I know that this show has had the likes of Rich Harris on, and all sorts of amazing developers who have contributed to the actual project… But I’m excited to talk about the book-writing process, and what went into that… Because you’ve got people who are far more - how do I say - qualified to talk about Svelte and SvelteKit than I would ever be, so…

I don’t know, you literally wrote the book, so… [laughter]

[06:14] Yeah, that’s one thing [unintelligible 00:06:14.19] putting on it. Yeah.

So I guess a good place to start would be how do you even get into this? Is it something that you want to do, and you approached a publisher about, or did you get a publisher reaching out to you? I don’t know, how did this start?

Adrienne, do you want to go first?

Sure. Both of the books I’ve been approached by a publisher. So the first one for Python came during the Instagram days, where - I don’t know if you’ve been on Instagram when web development was a thing, and everyone was posting their laptops and coffees, and like sharing their stories… I was a part of that.

I’m still a part of that.

We all were.

That’s true. That’s true. It’s just converted to reels now, or short-form video.

True, true.

There was a series there where I shared different types of cloud models, and different types of – what I was learning at the time, which was the Azure Cloud Provider, and Azure DevOps. So the publisher reached out to me and was like “We really like how you explain these cloud models. We’re looking for an author to write a book on Python.” I’m like “I’ve written some Python. I don’t know why you think I’m the person to write a whole book on Python…” And then they’re like “Yeah, this is also targeted for kids, 10 and up.” I’m like “Sure, I think I can do it.”

So initially - and I don’t know if it’s the same with you, Dylan - it’s kind like “Of course, this is such a cool opportunity to do this, to see your book in a store, to have it on Amazon…” There’s certainly that part of it there that drives you to say “This would be a cool thing to do.” And once that glowy part is over, you’ve signed the contract and you realize you now have deadlines, you’re like “Oh, my gosh, it’s actually so much harder to write a book.” It starts to go away, and you’re like “Why did I sign that contract?” And so that’s kind of what happened for me. But yes, a publisher approached me both times for the book.

Was it the same publisher both times?

No. The first one was Callisto Media, which is from Rockridge Press, which makes sense, because they were more focused on children’s books… And the second one for the code review book is Manning.

Nice.

Very nice. Yeah, so I was also approached by a publisher. One of my earlier roles in web development was actually for an advertising agency building WordPress themes for their clients. Customers need websites, and they need to advertise, and so I was the one who was making the websites happen. When I started that, I realized I quickly needed to learn more about WordPress, because I had no experience with it at the time… And so I spun up an old Pentium 2 PC that I had hanging out in one of my closets, I threw a lightweight Ubuntu distro on there, and I put WordPress on it and I started tinkering and tinkering. And I’ve been tinkering on that same installation for 10 years now, and that’s where I write closingtags.com, which is my blog about web development. It’s mostly just content that any problems I come across and solutions I come up with, I say “Hey, this would be a great blog post”, because I’m constantly finding other people’s blog posts. It’s mostly there for documentation for myself, and I have comments enabled, which is great when people say “Hey, this really helped me. Thank you.”

And so I’d written a post about getting global CSS in SvelteKit. At the time, SvelteKit wasn’t out of beta yet, so we’re not even in SvelteKit 1.0, and there wasn’t a defined method for doing this outlined in the documentation yet. I’d come up with a relatively hacky strategy, and written about it, and it got a lot of traction. It’s one of my most viewed posts on the site to this day, even though it is now incorrect. I’ve put a little disclaimer at the top of the post saying “By the way, Rich Harris said don’t do it this way. Do it this way instead.” But it happened to land in GitHub issues where a lot of people were saying “Hey, how do I do this?”

[10:04] Somebody linked to it, and from there, a publisher came across it, and they reached out to me and said “Hey, we want a book about SvelteKit. Would you be interested in writing it?” And like Adrienne said, it seemed like “I don’t know, this seems a little bit scammy, because I got an email, and they’re like “You should write a book.” I was like “Yeah, that’s obviously a scam. Somebody doesn’t know what they’re asking…” But then I kind of dug into it a little bit more and realized “Oh, wait, this is how this publisher actually reaches out to people.” And so I kind of asked some questions, and I set up a call to make sure things were legit… It was totally legit, and the rest is history.

Nice. Nice. That’s about how I would picture it going… “This can’t be real”, all the way to “Why did I sign this contract?”

Yeah. Yup. At first, I was trying to figure out what’s the angle on this scam? I write a book and - how are you gonna make money off that? But it’s not a scam, it’s a real thing… So yeah.

Well, that’s awesome. So before that, were both of you prolific readers of technical books at all?

I would argue that there were a few. There was like the Headstart series that really helped me when I started out. Headstart Visual Basic and Headstart C-sharp. So those were the ones that really made sense for me. And also, there were a couple actually Manning books that would go into some of the languages, so C# at the time it was like 6… And those were really good referential books for me. So yes, they did help while I was on the job, for some of the more esoteric things or things that you wouldn’t know; those did help me, yeah.

For me, I was actually kind of on the other side. I’d read a few technical books, specifically from Packt, the publisher that I worked with, and I found that several of them were really dry and difficult to get through. That was one of the things that frustrated me about technical books. It was like “I really want to learn this material, but it’s really hard to dig through code, and commands, and…” Especially in a text format, it can be really – reading other people’s code isn’t always exciting, and it can be really difficult. And then, if you’re getting really dry explanations for that code, it can be really frustrating.

But in the past, I had purchased books from Packt through Humble Bundle, which does like charity type things… And so I have like a bunch of security books, because security is just like a thing that interests me as well… And so after stumbling through a few of those books, finishing a couple, I was like “You know what, maybe I could do one different. Maybe I could break that mold and make something that people can actually finish, and can actually digest.

Nice. Yeah, that’s kind of my experience as well. Reading code, especially code oftentimes in a book is not syntax highlighted, so it’s kind of hard to follow along, too. But I’ve definitely – the Headfirst books; Headfirst in Java, I think, was my first book technical book that I got in high school, that really got me into it… And I was like “This isn’t super-boring. I can actually continue and pay attention in this.”

The visuals certainly helped… That’s what made it not so bad, because it chopped up the text with those visuals. That’s why I liked those books.

Yes. I think I got like a follow-up book for that, that was like Headfirst Ajax, and it was just all about –

Oh, yeah. Yeah.

Yeah, it was a good book. So yeah, that’s awesome. So Dylan, you had mentioned reading very, very dry books, and from that publisher, too… Did you do anything to prevent yours from being dry, or anything like that?

So I’m naturally a very snarky and sarcastic person. A little bit of that bled into the book. I had to dial it back a few times during the editing process… And one of the limitations of books is that they don’t have gif support. This publisher also didn’t support Unicode, so I couldn’t put emojis in the book… Which was a whole other thing.

[14:05] A lot of my writing on my blog is more - how do I say…? I try to keep it light, and funny… And so I think that was something that they had appreciated; it was something that they had mentioned early to me, and flattery will 100% of the time get you anywhere with me. So that’s kind of what pulled me in, was “Hey, maybe I can do this differently.” That was my motivation.

I tried to keep it as technical and light as I could… But there’s certain things that I can’t. When you’re explaining configuration options - there’s nothing exciting about configuration options. So it’s hard to just go from point to point and say “Here’s how this one works. Here’s how that one works. Sorry…” You know.

That’s the best place to be snarky. You’re like “Yeah, you don’t need to set this setting. That’s fine.” [laughter]

So Adrienne, I’m trying to like break down the process here… You were reached out to by a publisher, you agreed, you signed the contract… And then what happens? Do you just open up a Markdown file and start going? What do you do to actually get that? Or actually, before you even sign that contract, were there steps that you needed to do to prove that you can actually write this book?

Yes, there were a few steps beforehand, because part of that contract is agreeing to what you’ve worked out and discussed beforehand… So in both of those processes I’ve had to lay out a table of contents, a tentative table of contents, and then have maybe a small description or two of what those chapters would look like. If you had an idea of what the subsections would look like for those chapters, you would write that out as well. So at least having a table of contents and like a rough estimate of how many pages you think you could write about this topic, and roughly how many graphics or figures you think you’ll have in the book - those are kind of the basic asks that they have you give out. And you discuss this too in meetings before you sign the contract, but… Yeah, once those have all been agreed to, everybody is happy with what those things are, then you sign that contract. The contract lays out “This is what you agreed to do, and then you can start writing from there.”

Depending on the publisher, it can be more flexible. For example, with Manning, at the time that I wrote my table of contents, my last chapter was focused on something that I don’t think is relevant anymore. I think something that’s more relevant is how to do code reviews and how to deal with it on remote teams, which is something that’s more relevant now. So in that sense, as long as you can justify “Hey, I had this chapter previously, but I think this one’s more relevant”, they actually appreciate that. They want the books to stay relevant. So in that sense, you can change it a bit. But what I wanted to say was the first step was despair. You look at this and you’re like “Oh gosh, this is on me. This is on me. Oh, man…”

Oh, and then the other thing that you also agree to are deadlines, rough deadlines. So either you go chapter by chapter, you lay out according to your schedule, or you do percentages. “A third of the book will be done by this time.”

Okay, that sounds terrifying to me… Because what is one thing that I’m terrible at, just like relating this to writing code, I guess, is estimates, right? And that’s always based on “Oh, I wrote a component like that before. It’s probably a week or two.” And “Oh, I’ll throw in some padding for tests, and stuff.” How do you say “You know, I think I got like 382 pages in me”? How do you get to that number?

[18:02] That’s a tough one. For me, it was honestly just guessing. It was like “I don’t know, maybe that’s 10 pages, maybe it’s 15…” And then at the end, I think the publisher, with Packt they had asked for about 200 pages. I came in a little bit under that, and they were fine with that. I didn’t want to add extra bloat and stuff to the book that was going to not really add any quality to it… And so I said “It’s kind of close to that… Is that fine?” They’re like “Yeah, that’s fine. Go ahead.” They were very flexible, and so as long as you’re upfront with everything, and with deadlines too being proposed… Say “Hey, I have vacation this week. I have this that week”, and being upfront with them about that was just “Okay, great. We’ll pencil that in, and then we’ll push these other deadlines back.”

In my case, I was given a proposed deadline, and they said “Hey, do you agree with this? Can you do that?” And I said, “Yeah, probably. I think I can make that happen.”

Yeah, absolutely. The first book that I wrote, the Python book - that was more strict the way that they dealt with deadlines… So there they cared more about actually the 50 activities that were part of the book. Because it’s 50 Python activities that a kid is supposed to go through to learn. So as long as you had a certain amount of activities done by a certain time, that’s what they cared more about. With Manning, and as I’m writing this now, they’ve been way more flexible. I’m like “Yeah, I’ve had conferences to go to, I’ve gotten sick a couple times…” My initial deadline was actually supposed to be August 2023. Yeah… So I talked to my editor, I’m like “I have a new proposed deadline for the remaining chapters that I have.” I think you only know better once you start writing. So at that time, I was about five chapters in, which is about halfway through for me, and I said “This is the pace that I can write, and this is the pace that allows some buffer with work, and anything else that could happen.” So I revised my deadline to be way more padded. And luckily, they were very flexible with that.

I don’t want to say that that’s the case for everyone, specifically for Manning. I’m lucky because my topic code reviews is kind of evergreen. Some topics, they want to get it out there quickly, because they age very fast, especially if it’s on a specific technology. So sometimes they might not be as flexible. like “No, we need to publish this now, or else it’s not going to be relevant.” But for me, they’ve been quite flexible, which is great.

Nice. And I suppose yours would be the opposite of that, Dylan…

Yeah. And actually, I think SvelteKit 2 was just released not long ago, and so parts of my book are already possibly obsolete. I tried to keep it as general as possible. But even during the writing process, technology moves fast; these frameworks are always adding new features, always building new things, and I would get to a chapter and I’d reference something in the documentation, I said “Oh, that’s a new feature that wasn’t there. I’m gonna have to incorporate that into the book.” And so the book changed while the book was being written, because I was trying to keep up with the developers.

Nice. Yeah, I suppose you really have to do that. Dylan, I was also going to ask, with regard to what Adrienne said about the flow, the table of contents creation, and then signing the contract and kind of getting going… Was there anything about that process that was different in any relevant way to you?

It was actually really similar. One of the things that Packt had me do is put together a product information. It was basically just market research… And I think this was more of a box to check, because they had approached me about writing the book. They clearly wanted to write a book about the subject. But authors can also approach them, and when they have an author approach them, one of the things that they want to see is not only your outline of the book, but also any market research that you’ve done.

[22:09] Are there any other books about this subject? What have those books done? How long are those books? How is your book going to be different? What are your readers going to take away from this book? Who is your target demographic? All sorts of information about selling a book that they wanted to see. So that was one or two pages of questions that they’d had, and I would fill that out and send it back, along with my outline. So that was pretty much the only thing that was different, though.

Nice. Okay. Yeah. It sounds pretty similar, though. And Adrienne, you’ve worked with two publishers. Was it roughly the same between both of them as well?

It is more similar to Dylan’s with Manning. With the Python book it was “Just start writing.” That’s what they wanted. But yeah, with Manning it’s also similar. What other books are out there? How is yours different? Who could this apply to? A lot of the same stuff… Because they do help you with marketing later on; Manning does. So all of this information will be used at some point to help you once your book is published.

Nice. Okay. I think I’ve held out as long as I possibly could… I hate to do this, but – I’m cracking my knuckles, if you can’t see. I want to talk about tooling. Can I use Vim to write my book?

So I’m a Vim user, and it was incredibly painful for me to not be using Vim. With Packt they had a SharePoint instance setup, where I could then upload Word documents. They also had an Office365 in there, so I could write in the cloud. Part of the contract that I’d signed though stipulated that should either of us part ways with the other, any chapters written up to that point would then become my property. And so I wanted to make sure that I had local copies of everything, should anything happen. Not that I was saying things were going to, but if for whatever reason one of us had to back out of the deal, I still wanted to take the work that I had and be able to publish later at my leisure.

I’m a Linux fanboy, and so I used Libre Office, and I was also given style guides that I needed to follow… The style guides are there to – I was told that I can ignore them if I wanted, but I think it made a lot of the editing process a lot easier, for both myself and the editor, because things were… You know, keywords are bolded, that can later be looked up in the appendix; chapter titles are highlighted appropriately, and subsections are also laid out in a way that I think that they will look best for the reader. And when it comes to code, I didn’t want the code to look hacky, right? I wanted the code to be nicely indented, and easily readable, because one of my frustrations, like I said earlier, was reading other people’s code can be painful. So I took a lot of care and effort to make sure that the code was properly formatted and followed the style guidelines. But ideally, it would have had some sort of Vim markdown with a git repository setup. So I think if I ever write another book in the future, that’s something that I’m going to push hard for before I sign any contracts. [laughs]

How about you, Adrienne? What kind of tooling did you use?

Oh, it was all reliable. Nothing too exciting. In both instances they just used Google Docs. So we have a very stringent folder, directory. With the style guide, specifically Manning is quite strict about that, because they probably have some internal automations that expect this formatting. So they give you a style guide, a very thorough style guide. They give you sample chapters, they give you a lot of things to show you the way you’re supposed to write the book. And even in the review process, so after every chapter that I write a draft, it gets reviewed, and I get notes back from my editor, as well as the technical editor. And each time, I always get some notes, like “Oh, you’re supposed to use this specific font for code.” Or “You can’t use this font for code in within a paragraph. Please change it.” Or you forgot to label your figure with Verdana Six point, dark red.” I’m like, “Okay, I’m sorry, I’m sorry.”

[26:24] Because sometimes when you’re in the thick of writing, you don’t think of those, you just kind of go through. And that’s what the editing process is for. So yeah, just good old Google Docs, which is great. I can work on it from anywhere, and that’s how I’ve been working.

And was that like a doc per chapter, a doc for the whole thing?

Yes, it is a doc per chapter.

Okay. Yeah, that sounds pretty good.

Vim sounds better, but… Yeah.

Like I said, not exciting. It works… It’s reliable…

It does work.

Exactly. No, that’s why I was joking about jumping into tooling, because that’s where I love to nerd out about, but it’s not the actual productive part, right?

Right. Especially when you’re working with a team of editors too, and they are not necessarily fluent in code. They don’t really know… I mean, they are in that they’ve edited other books with code in them, but they also have to – they’re very familiar with Word documents, Google Docs… So it’s pretty easy to pick up and work with collaboratively.

Editors on Dylan’s manuscript were like “How do I leave a comment on this thing?” [laughter]

Like, “Oh, you’ll have to send me your PGP key, and then we’ll go from there.”

That would be insane.

So you both mentioned working with an editor, so it doesn’t sound like you’re completely alone once you sign the contract. You’ve got someone to help you… What’s the job of an editor in this case? Adrienne, you’ve also mentioned two types of editors - a technical editor… What was the other one? Just a regular editor?

Just a regular editor, yeah. Yeah, so my editor, her name is Rebecca. She’s great. She focuses on “Does the chapter flow well?” Are there things that could be rewritten to be more clear? Are there things that could be added to enhance the chapter? Should you add a personal anecdote here? Do you need a visual to help bring to light what you’re trying to explain in this paragraph? Those types of things are what she’s really great at adding, and is her main focus when she reviews my chapters.

And then I have another editor, a technical editor, Miroslav, who’s also awesome. He typically checks for “Are there any code samples? Are they correct? Are there any processes that I describe, actually match what developers do in their code review process?” Is the tooling that I’m mentioning still relevant today, or are there other processes or tools that are being used? I would imagine the technical editor gets a little bit more work on a more technical book, like Dylan’s, because they go through and check code samples are working, they go through step by step, documentation is correct… They’re the extra step to make sure anything in your book is technically correct.

So with those two, the book really, really gets polished by the time it’s done. And then the last part, they’re not really an editor, but at least for Manning, we have three big reviews. I’ve just finished the second one. So at the second point, I had about seven chapters, and what they do is they give this entire packet of seven chapters to some reviewers; around 10 to 12 reviewers. And they give them some time to review it, and then I get feedback back. And those are very, very helpful, because those are real people, spanning the demographics that I’ve listed as my target audience, and they give their true and honest feedback of what could be improved, and all that. So all of that together makes the book really great.

[30:02] Yeah, definitely. I also had a senior editor, Amir Ahmed was his name, and he would – any typos I had or mistakes I’d made in my wording, he was there to correct it. He and I had some disagreements about semicolon usage, but other than that, he was a great guy. So it’s a great team; you have a whole team of people that are there to support you. You’re the author, yes, but they’re there to make sure that you succeed as an author.

As far as the technical stuff goes, I did have a technical editor. My technical editor didn’t have a lot of feedback for me. However, Packt also introduces a technical reviewer, which is a lot like what Adrienne was saying. And I was fortunate enough in that I have a friend who happened to be the target demographic, and I said to him, I said “Hey, would you want to be a technical reviewer, get your name in this book?” And he said “Yeah, totally.” And he had a lot of great feedback for me. And so anytime there was a mistake, or an npm package wouldn’t install because the developers are moving quickly, things are being updated, he was there to make sure that “Hey, this didn’t work for me. What’s going on?” And I said “Oh, you know what? This is what we’ve got to do.” And so I had worked through that, and would fix those problems, send it back and say “Hey, this is all better now. The code works, and that’s no longer an issue.” So a technical review process is incredibly important when writing technical books. You want to make sure that the code that you’re saying “Hey, here’s how you do this” actually works.

Yeah. And that’s something that I have been involved with, with at least one book in the past, being a technical reviewer on it, and then providing a quote that got printed in the book, either on the front or back.

Yeah, it was Josh Goldberg’s TypeScript book. I can’t remember the exact title of it, and I was trying to look on my shelf and I don’t see it… It’s over there somewhere. But anyway, yeah, that was a lot of fun, being able to go through it, give feedback, and just kind of get an idea of “Before this is published, what thoughts are going into this, how it flows” and things like that. Really, really cool being a part of that. So I encourage that if you get reached out by Adrienne or Dylan or someone else, to jump in and help with that.

Yeah, especially if you’re trying to learn – like, if you have an interest in writing a book, starting with reviewing is a great way to see what’s involved in the process, too.

Adrienne, the name of your book is “Looks good to me”, right? That’s such an awesome name, and it’s something that’s probably my most used phrase on code reviews. So it’s just so perfect. I wanted to talk about one of the hard things in computer science, and that’s naming things. Did you come up with that name? Did they approach you with that name? Did you work together to find that? How does that work?

I’m very proud to say that was all me. And I fought, I fought for that name… Because you know, once you have the contract signed, that’s one of the early things you decide, is a tentative name. So we went through so many iterations of that… But I said “I don’t care what you choose as the subtitle that matches the data, or what’s being searched for…” They had their own sets of requests that they want me to add as part of the title, but I said “Looks good to me.” It has to be the name. I don’t care. And I even had to go so far as when they were unsure of the name, they had to ask the first set of reviewers that I had, they actually added a couple of questions that said “What do you think about the title? Is it relevant? Is it this?” And every reviewer was like “Awesome name. Great name. When I see this on a bookshelf, I know immediately, my mind as a developer associates this with code reviews.” So every single one was like “Great name. Keep the name.” And I’m like “Can I keep it now, please?” And they finally gave in, and I was like “Yes! Okay.” And until this day, anytime I share a post or an update and stuff like that, share about it, that’s some of the things that people will still comment on. It’s like “Oh, great name.” I’m like “I know.” [laughs] So yes, I’m very proud to say that I totally came up with that name.

That’s awesome. And it’s even more awesome that you had to fight for it, and then it’s just like universally like “Yes, that’s perfect!” Because it really is. It just sticks. It’s so good.

Yes. Yeah, at that point I conceded with the subtitle. Because at first, it was something super-long, like “Actionable advice for constructive code reviews.” They’re like “It’s too long.” I’m like “Well, I’m not cutting “Looks good to me”, so let’s change the subtitle.” And then that’s what it ended up being, is constructive code reviews. I’m happy with it.

Yeah, that sounds great. Dylan, what about you? Is yours more of a series?

I had very little to do with the name. It was all proposed ahead of the time. The original title, I think, was Mastering SvelteKit, which is a series that they have, that Packt publishes for tons of different technologies. I think they were trying to just steer away from that name, for whatever reasons…

Somewhere in the process - I wasn’t consulted, I didn’t really care - they said “SvelteKit up and running.” I was like “Cool, that looks good to me.” And then they throw on the subtitle, which I think is a mouthful, and I never use it. It’s “Leverage the power of a next-generation web framework to build high performance web apps with ease”, which is kind of a summary of something I’ve written in the product information. It’s a bit of a mouthful, I don’t ever use it. “Up and running” is pretty much all that I go with. And I think they have several other Up and Running books, too. So they do a few different types. They have like cookbooks, where it’s several different things for tackling this technology… Like, if you want to do binary analysis, there’s a binary analysis cookbook by Michael Bourne, which is another great one for people interested in security. So I had very little to do with a name. I wish that I could have done something awesome like like that. So…

Well, then, on the spot, what would you have come up with?

Oh, man… Oh, geez…

Sorry…

I’m a sucker for alliteration, so I would have been like “Super-slick web apps with SvelteKit”, or something. Something along those eyes.

Yes. Alliteration is so much fun. Sometimes I get stuck while writing, I’m like “Oh, this could have some alliteration in it.” And then it’s like an hour goes by, I’m like “Oh, I still need to write the rest of this chapter.” [laughter]

So speaking of… Writer’s block. You alliterate your way through it, Adrienne… Is there any other cool tips and tricks to overcome writer’s block?

[37:56] Oh, yes. I just need to stop. That’s honestly the best thing for me. Sometimes I will stop for a day, maybe two if it’s really bad… Other times, the one thing I’ve read, which was good advice, was if you have trouble writing, read. And that also very much helped. Because I started to go through research papers, I started to go through blog posts… Any of the research material that I’ve had saved up, that I thought would be relevant for using in my book, I started to go through those. And then sometimes that kind of jogs the creativity and says “Oh.” Or somebody has an opinion on it, or a story that they share, and then that is what kickstarts me to start writing again.

So even after that, if I read and I’m still like “Okay, those are all great points, but I still don’t know what I want to say about that, or what I could add to my book that would be relevant”, then I do take a break. And then usually after about a day or two, sometimes three, I go back into it and I’m able to start at least writing a sentence or two, or outlining something for me to pick back up.

That’s a far healthier response than mine was… [laughter] I occasionally needed a glass of bourbon, I won’t lie. It loosened the inhibitions, and just kind of let things flow… Don’t overdo it. Who was the Microsoft guy that said something about – the Ballmer curve, right?

Steve Ballmer.

Steve Ballmer. So there’s that. But a healthier alternative for me was actually just taking every little thought in my head and dumping it onto page. It didn’t matter if it was relevant to the chapter or not; just putting stuff on the page helped.

I found after the first chapter or two, actually taking what I’d written in the outline and copying it into my draft document for that chapter was really helpful. And then while I’m brainstorming my way through the chapter, how am I going to make this connect to that? How am I going to do this? How is this example going to work? I would just take every little thing that I had thought of, “I need to make this happen”, I’d throw it on there, bullet points, and use headings, subheadings, whatever I needed to within the formatting, to kind of make it look like the thoughts felt in my head, if that makes sense.

One of my policies was never delete until I was ready to start writing. And so chapters would frequently be 20-30 pages long, until I’d finished it. And then I would start purging things that were not relevant. And then go through and re-edit my chapter, and then I would submit it to my editor. So that’s a healthier alternative than the initial one that I’d offered.

Yeah, that – if I were gonna do this… Because I’ve thought about it long and hard. The only time I would have is like between like 5am and 8am to write. I don’t know if I want to do bourbon at 5am.

Yeah, it’s not a great – I mean, it could be a great way to start your day. It depends.

It could. So when it comes to - Dylan, in your case, you have a lot of code examples, and things like that. Are there ancillary materials or examples or projects that you set up as like supplemental materials for the book-writing process? Is that something that you’ve done before?

Yeah, so there’s actually a GitHub repository that goes with the book. And that has – essentially, it’s a collection of small projects that are one singular project, just because I didn’t want to have readers have to go through and reinstall every single time. Like, just keep it as one project, and we’ll make a new page that demonstrates this concept. Okay, we’ll create another page and we’ll demonstrate this concept behind it. And then you can tinker with that and play with it in your own time. And so you can go to the GitHub repository, and I think that information can be found on the website I set up for the book after. It’s sveltekitbook.dev. I should have a link to that. And you can view all of that code.

[41:59] You can clone that repository, if you want, and you can just look through the code… It’s really encouraged to work through it with the book, as you’re reading. So if you have a physical copy of the book next to you, have your laptop or your computer open and be working on it as you can, just because that’s kind of how I’d intended it to be. You get more learning it by actually writing the code and seeing it, tinkering with it on your own than you will if you’re just looking at my old crusty code.

Nice. Adrienne, how about you? Is there any supplemental or additional things that go along with a book on code reviews?

Yes, actually. A lot of what I talk about in code reviews is the dynamics between teams, and how a lot of those are not documented. So a lot of what goes into making a good code review process, in my opinion, is to talk about these things with your team, and then to codify it somehow. So there are supplementary things, like for example one of them is a team working agreement, where for example if you – what’s your definition of done as a dev? Does it mean when you open a PR, or does it mean when it’s merged? For some developers, it’s one way, for others it’s another way. And then that causes friction and contention, because people are not on the same page about what done means for the team. So all of those types of things - naming conventions, style guides, all the things that are implicit, I tried to say make explicit.

So those are the types of ancillary things that you’ll see, that come with my book. A lot of them are also just kind of stepthroughs for team leads and engineering managers to talk through with their teams. For example, if you don’t have the code review process defined, I outline “Here’s a way that you can do it with your team, and kind of iterate on the process, and how to get feedback from your whole team and put it together.” So it’s more like a workshop type of ancillary directions, and others are like templates, like the team working agreement, where teams can fill it out themselves. And similarly, they’ll also be available in a GitHub repository, which is something I still have to do as part of my checklist of the never-ending checklists part of this book.

Nice. So you’ve signed the contract, you’ve written the book, you’re sticking to the deadlines, you’re going through all of that, and you finally get to done-done. What happens then? I think you mentioned that there’s like a final review process maybe, but then… What happens to actually get the book on a shelf, from your perspective?

So in my case, it was, like you said, that final review, and then it was just kind of waiting. There was like a month in there where I hadn’t done anything, and I was told the book will be finalized, it’ll be published here… And then with Packt you get two free copies of your book. They send you like a physical copy, which is really cool to see; when you get to hold a book with your name on there, it’s like “Wow, I did it. I did the thing. I set my mind – I did it.” That’s the best part about it, I think, when you finally see that.

I don’t see a lot of stores carrying my book, and I wasn’t really expecting to, just because it’s a very niche book; it’s a very small thing. But I think the local library, I can reach out to them and say “Hey, I wrote a book. Can you stock it?” And then I can come in and see my book on a shelf somewhere. And I think they would probably do that, which would really give me warm, fuzzy feelings.

Yeah, it’s similar. For the Python book it was the same; it’s about a bunch of waiting. But they do start telling you “Alright, now you go from author mode to marketing mode.” So this is where you start drafting Instagram posts, and reaching out to your local Barnes and Noble to see if you can do an author signing event, and you reach out to libraries… You completely switch to marketing mode, which they have someone help you with as well.

[46:08] And thankfully they do, because they are way more on top of that. They’re like “Here’s all this stuff that you could possibly do. Which ones do you want to do? I advise you to do everything, because that gives more awareness to your book.” And so that was that.

With Manning, it’s the same thing. You have a whole team for marketing. The marketing starts way before. So for example, now that I’m almost done, I have about two chapters left to right, someone who’s solely dedicated to marketing on Reddit reached out to me and was like “Have you thought about promoting your book on Reddit?” and I’m like “I have. I know how powerful Reddit is, but I don’t want to be spammy.” And so you have those conversations of “How do you draft a post that’s not spammy on Reddit, while still promoting your book?”

You have someone on YouTube. Have you thought about creating videos and shorts to promote your book? So there’s all these different avenues, and it’s really just up to how much time and what you want to do, and they start thinking about that way before. So yeah, I’m assuming once I’m done with the final review, that it’s going to – same thing, switch to marketing mode of the book.

Yeah, that’s a really good point. I did get contacted by some marketing people at Packt, now that I’m thinking back to it. I try to block it out, because marketing is really not my thing… But I did go and set up a website for the book, and I used all the techniques from the book to do that… And it was easy enough to do. I had someone who does it for a living. So setting up a website was really quick, really easy… And I did get asked to reach out to other influencers that I knew… I was a little not too keen on burning some of those bridges and saying “Hey, you have several thousand followers. Will you promote my book for me?” I didn’t really want to do that, so I refrained from asking influencers to do promotions for me. I did promote it on my blog, and social media, and stuff like that… But that’s about the extent of my marketing capabilities.

Nice. And to be clear, I was not contacted by any agents to get you both on. [laughs] I was genuinely interested in the book writing process when it comes to technical books.

Thank you. Thank you for saying that. [laughter]

Not that I’m an influencer, but you know, just – to set the record straight on that, I suppose. [laughs] Yeah, that’s really cool. Adrienne, did you do a book signing event?

I did for the Python book. That was super, super-cool, because at first I actually didn’t know that it was going to be in stores… And I actually had a friend just send me a message. They were like “Hey, I saw your book in Barnes and Noble.” I’m like “What!?” Because I was only expecting it to be those you order it online, and then they print it for you, or an ebook… And so I’m like “There’s no way…!” And she took a picture of it and I’m like “I’m going to my Barnes and Noble right now.” So I went to mine, and I was like “Where is it? Where is it?” It’s not in Children, so I went to the Technology section. I’m looking, I’m looking, I’m like “Oh, my God! It’s there!” It was such a cool, cool feeling. But yes, after – at least for Barnes and Noble, they have these author signing things, which you can set up yourself… So you contact the store manager, I believe, or the Events Manager, and they have a specific email for each store… And you basically just say “Hey, I am the author of this particular book. Would you be open to having an author signing?” They look for an open time on their schedule, and then you’re scheduled. And so I had one at one of the Barnes and Nobles here in Vegas, which is where I’m based… And it was cool. Not a lot of people came. My grandma came, and she’s so proud… She’s like “I’m so excited for you.” Of course, my husband was there, and a couple of my husband’s co-workers who had kids went there, and I was like “Oh, you guys are awesome.” So it was cool.

That’s awesome. I would totally do it, and only my mom would come, but I’d be happy with that.

[50:02] It was so cool, because what they do is they print out a little thing that says “Author Signing”, and it has your name on it… It’s like a super-simple poster. They set up a table, they put some of your books there… But I was like “Oh, this is cool. I’m right next to the Starbucks.” As people are waiting in line, I’m like “Hey, are you interested in Python? Is your kid interested in Python? I have the book for you.” So yeah…

That’s awesome. So before we close down, I did want to give you both the opportunity to share any advice or feelings or thoughts that you have to someone who’s listening, who might be currently being contacted by a publisher, or maybe they’re thinking about reaching out to a publisher… If you have any insights to share, now’s the time.

I will say, if you’re doing it for the money, you’re not gonna get rich off of technical books. So that’s like the one thing I learned. You could write like a few books, maybe in the tens, or hundreds, and then maybe… But yeah, if you’re doing it for the money, you’re not going to be happy. So if you do find something, a topic that you’re approached to write about, and you are really interested in it, it is worth considering. Consider that it does take a lot of time, you will probably have to dedicate way more time to this, and kind of put everything else on hold, if you want to make those deadlines… Unless you’re just very efficient with your time. And overall, I don’t regret it. We joke about how difficult it is, and how sometimes I’m like “I can’t write anymore. I don’t want to do this. Why did I sign this contract?” But in the end, once that book is in your hand, you’re like “Ah… This was great.” And then you do it again. [laughs] So that’s the advice I would give.

Yeah, you hit the nail on the head there. That’s pretty much everything that I was gonna say, too. You’re not getting rich off of it. If you’re passionate about the technology or the subject matter, then by all means go for it. Because in the end, when you finally get to hold that copy of your book, it’s something to be proud of. Something that you can look back and say “I did this. I did it. I set my mind to it and I made it happen.”

That’s awesome. It’s like a tangible thing. We don’t normally build things that are tangible in this line of work…

Right. Especially if you’re writing code all the time. You don’t get to whole you code.

Exactly.

And it’s published, which means it’s done, and there’s no changing it, which is also probably kind of a nice feeling…

Yup. It’s a little nerve-wracking too, because I can’t go back and fix things, but… [laughter]

It’s gonna go out into the world now… [laughs] Yeah.

Alright. Well, yeah, thank you both for joining and sharing your insights in that. We’ll have links to your books in the show notes. Dylan, yours is “SvelteKit in action.” Was that the title?

“SvelteKit Up and Running.”

Up and Running, I’m sorry.

You can find it at sveltekitbook.dev.

Okay. And then we have the – I’m so bad with names, and then titles of books, apparently… Adrienne, “Looks good to me”, obviously. That’s a very easy one, and an awesome one. Is that available as like an early access thing right now?

Yes, it is currently available as early access. It has eight chapters out, and I bought a bunch of domains. So if you do looksgoodtomebook.dev, .io, .com… Just one of those. I bought like six of them, so they should redirect to the meaning link. But yes, Looks Good to Me and my name should pop it up.

Nice. And then your Python kids book?

Yes. Coding for Kids Python. I actually don’t know if they’re still publishing it. I think the publisher went out of business for mine… I still see it on Amazon. That’s like Part Two podcast episode, but… I still see it on Amazon, I think you can still get it… But yeah, so “Coding for Kids Python” with my name, because it might come up with a couple… There’s a lot of Python children’s books.

Nice. Awesome. Yeah, that is – I’m definitely interested in both of those books… And the Python one, not that I’m into Python too much, but getting my kids up and running, or getting them exposed to it is a high priority for me.

Yeah. I think my seven-year-old would really enjoy it, so I’ll be getting a copy of it pretty soon here.

Sweet. Yeah. My favorite chapter is the turtle chapter, where you draw with the turtle module…

Nice. Turtles all the way down. And on that, Dylan, Adrienne, thank you so much for joining us, and we will catch you next week.

Changelog

Our transcripts are open source on GitHub. Improvements are welcome. 💚

Player art
  0:00 / 0:00