Matt Harrison, author of many Python books, is putting together a course, Effective Book Authoring, to help other people write and publish books. As part of this course, he’s including interviews with people who have already written books. This is one of those, and we talk about self publishing vs working with a publisher, the process, the format, book promotion, and advice to writers.

Transcript for episode 137 of the Test & Code Podcast

This transcript starts as an auto generated transcript.
PRs welcome if you want to help fix any errors.

00:00:00 Matt Harrison has written a lot of books on Python. He has self published some and worked with publishers on others. He is putting together a course to try to help other people write books. It’s called Effective Book Authoring, and I’ll leave a link to it in the show notes. As part of the course, he’s including interviews with people who have already written books, including me. I’m including it here because I really want you to write more books, and I’m hoping his interviewing me might help inspire you. After the interview, I realized that I talked about my wonderful development editor, Catherine Devorak, but that I got her title wrong. I say in the interview that she’s a design editor. The correct term is development editor. She was awesome to work with. Anyway, here’s the interview.

00:00:55 Welcome to Test and Code.

00:01:06 Okay, Brian Hawkins, thanks for joining me. Let’s start off with an introduction. What’s your two minute story?

00:01:15 Well, I’m a software engineer, mostly. Right. Embedded C Code for wireless communication test equipment.

00:01:23 I do system testing in Python, and in 2011, I wrote a custom test framework because I needed one. In 2012, I started thinking about other test frameworks and trying those like Unit Test and Nose and pytest and writing about it on Python testing. Net.

00:01:42 Later, I turned some of the most popular articles into an ebook, and then I thought this was fun. I should probably write a book.

00:01:50 And then contacted Pragmatic and started writing in Python. Testing with pytest. Actually, I was going to write a different book, but it morphed into this, and that came out in 2017, and I do that and I podcast and work, and that’s me.

00:02:11 Awesome.

00:02:13 Awesome. Well, so the book that you wrote is Testing with pytest.

00:02:24 You kind of went into this. Why did you write the book?

00:02:29 Was there a book inside of you that just wanted to get out? Do you just like writing? What was the impetus for writing the book?

00:02:37 I do like writing, and I also like reading, and there were aspects of different technical books that I didn’t like, and I wanted to try my hand at technical writing.

00:02:56 There wasn’t a pipeline book out there at the time, so I chose the topic because it was a need that needed filling. So I didn’t have a good reference to tell people when they said, I want to learn this. There also was a lot of at the time, there was a lot of people that thought between Unit Test and PY test. Py test was powerful but more complicated to learn, and I really thought that was the opposite. I think that Pi test is easier to learn, and I wanted to write a book to prove that to people.

00:03:29 Yeah.

00:03:31 I think the main draw for me of Unit Test is that it’s in the standard library, but that’s about it.

00:03:39 Yeah. There’s more to remember.

00:03:42 You have to memorize. I don’t memorize very well, so I like things that don’t make me memorize stuff.

00:03:47 Yeah, I think we’re in the same boat there. Awesome. Well, this isn’t about testing or Python per se. It should remain somewhat agnostic, so we won’t go down that rabbit hole too much.

00:03:57 Okay.

00:03:59 But thanks for sharing why the book came out. I think that’s a common thing that causes people to write books is they want something to be able to share, a point to write. And often there is a need, especially for a lot of these technical things where tech seems to move very quickly and there’s an adoption curve with tech, and when it’s a new library, no one’s going to write a book about it.

00:04:31 Right.

00:04:31 But then during this Hype cycle or whatever, there might not be a book about it. Right.

00:04:39 I think there is a need for documentation, and I think books provide a really good source of documentation in that authors tend to think about a whole path through something versus random blog posts or random videos that tend to niche down on just certain subjects, but not necessarily take a reader with them along the journey.

00:05:02 Yeah, definitely.

00:05:07 Thank you, Datadog, for sponsoring this episode. Are you having trouble visualizing bottlenecks and latency in your apps and not sure where the issue is coming from or how to solve it? With Datadogs EndToEnd monitoring platform, you can use their customizable built in dashboard to collect metrics and visualize app performance in real time. Datadog automatically correlates logs and traces at the level of individual requests, allowing you to quickly troubleshoot your Python applications. Plus, their service map automatically plots the flow of requests across your app architecture so you can understand dependencies and proactively monitor the performance of your apps. Start tracking the performance of your apps, sign up for free and install the agent, and Datadog will send you a free T shirt to get started. Visit Test And Code. Comdatdog.

00:05:59 Okay, so did you self publish this book or go with a publisher? I mean, you sort of answer the question, but maybe we dive into that a little bit more. I think there’s a little bit more story to find out there.

00:06:09 Yeah, definitely.

00:06:13 I did have an ebook at first, but the writing I did on Python was blog posts, and I did try to follow a path. I tried to do a project in different frameworks so that I could equally fairly compare all three at the same point in time.

00:06:33 But I got a lot of feedback from people, which is good.

00:06:39 But I bundled a bunch of the most popular blog posts into an ebook that went fairly well, which actually surprised me. It’s content that people could read for free, and they were sending me cash for it. It was just $5 or something, but that was neat.

00:06:58 I liked the experience and I wanted to reach out, so I reached out to a publisher. The reason why I tried to go with that. I chose Pragmatic and went with them. Is the Pragmatic programmer book, oddly enough, not published by Pragmatic, but it just changed my career, changed my life. And so I really respected the people that behind it.

00:07:27 I also like how they treat authors. They treat authors fairly well at that company. But the main thing is I wanted to work with an editor, a design editor, so that I could really get the best book possible to help teach people.

00:07:43 That’s something that I know you can hire Editors yourself if you’re self publishing, but that’s a little bit harder to do, I think.

00:07:51 Yeah. This is a common theme between a lot of the interviews that I’ve done is that if you are going with a publisher in general, not always the case, but in general, they do assign an editor to work with you. And a lot of times, Editors are professional Editors. Right. And similar to how you as an embedded C Plus Plus developer. If someone wanted some embedded C Plus Plus done, they probably wouldn’t want necessarily a Ruby developer or some fresh grad right out of school who maybe hasn’t done C Plus Plus. Right.

00:08:30 They would prefer to hire a professional who has experience and who has done that.

00:08:35 And similarly, working with a professional editor.

00:08:41 These are people who look at a lot of writing and kind of can pick out things and can give you a lot of insight into your writing that you probably maybe could have got to maybe not, but it probably would have taken a lot longer for you to get to that point.

00:09:01 I also want to say, though, that I was approached by other publishers with horrible contracts.

00:09:09 Okay.

00:09:12 I think the Pragmatic contract was fair, and I don’t think it would have been worth it just to get an editor if I were to give most of my revenue to somebody else.

00:09:23 Okay. So remind me, did Pragmatic approach you or you approach them?

00:09:28 Yeah. So after I got approached by a few other publishers, the plan was I was going to talk with Pragmatic first. And O’Reilly, I’ve heard good things about both of them, and I contacted Pragmatic, and I got contacted back, like, very quickly saying that they were seriously considering it. So it really was within a couple of weeks that we had things fairly nailed down. So good.

00:10:01 That’s cool. I know a lot of people are choosing between self publishing. Some people are like, I just want to get my book out. Other people are like, I really want to have a publisher. Right. For whatever reason, they want an animal on their book. Or there is this notion that a published book makes you an author versus self publishing. Maybe you’re not really an author. You just call yourself one per se.

00:10:32 But I think your path to going about this is a nice maybe called a hack or a technique to getting access to publishers.

00:10:42 That might have been a little bit more difficult had you not originally had your ebook around. Do you think it would have been easy for you to quick turnaround had you not had the ebook? Had you just been Brian Akin with no blog, but with an idea about writing about pytest?

00:11:03 Well, it’s a couple of things. It’s not just that I had an ebook that I’ve already written something. It’s also having a platform. So I had Python was five years and four years in, and I was getting at the time around 40,000 hits a month.

00:11:27 So a decent amount of traffic. So I had some audience. I had been podcasting already, or at least I can’t remember it was around the same time I started podcasting.

00:11:39 That was a good platform there, too. So a publisher doesn’t just want to know that you can write, but they also in today’s world, you’ve pretty much got to self promote your book whether you’re going with a publisher or not.

00:11:58 So having a platform definitely helps. And I also having started writing, I’ve always enjoyed writing and I blogged before, but this particular topic writing since 2012. I had four years experience writing already and tons of content for them to be able to look at my writing style to see if they like it or not.

00:12:25 So certainly grease the skids made things a lot easier having a platform.

00:12:31 Yeah. And there was definitely I had actually researched whether or not to go with just self published the full book or not. And there’s a lot of work there that I just didn’t want to take on.

00:12:49 So having somebody else help me, I wanted to get the book out as fast as possible and have it be as high quality as possible. And therefore, and at the time, things have even grown since then. So there are more options now even than there was in 2016 for tooling. So things are even getting better now, I think.

00:13:11 Yeah.

00:13:15 Sorry. It wasn’t a money thing, though. I wasn’t trying to make money from the book.

00:13:20 Making some money would be good, mostly to compensate my family for all the time I spent away from them writing the book. But I definitely heard from other authors already that writing a technical book is not the fastest way to get rich.

00:13:36 So was your proposal process? Did you have to go through a full proposal process where you filled out pages of information about your book and audience and potential buyers and competition?

00:13:51 Yeah, I think that’s fairly standard.

00:13:55 And since submitting a writing sample, I just attached the ebook.

00:14:02 Okay. But my first thought was it was just going to be like I thought my book was about two thirds done.

00:14:10 I was just going to fill out the ebook more.

00:14:13 But that was a comparison of unit test by test and knows.

00:14:19 And that’s not what the final book was. The final book was focused just on by test.

00:14:26 Yeah. So what was that process working with the publisher? What did it look like?

00:14:31 Can you sort of walk us through? You had what you thought was a book, and apparently two thirds of that, the non pytest related stuff sort of got thrown out.

00:14:45 Then did you come up with a new outline? How did you work on the chapters? How did you get feedback from an editor? What was that back and forth looking like?

00:14:53 Yeah, I can’t remember. I do think that we originally for the first little bit, maybe the first month or so, I wanted to rough out an outline.

00:15:06 Did they immediately reject the non Pi test?

00:15:10 No.

00:15:11 The original agreement was for something to cover multiple platforms. Okay. But as I was trying to flush out the different chapters, trying to write not flush them out, but write the outline for what the flow through the book was going to be, I realized that my punchline was going to be here’s how to do all of these things, but you should use pipest.

00:15:39 And I also didn’t really want to write about the others anymore.

00:15:45 I explored them, and I think of them as, at least for me, dead end. So it wasn’t energy I wanted to put in to learn those more.

00:15:57 I also realized it was going to be a longer book if I tried to write a complete treatise on all three.

00:16:05 And that wasn’t what I wanted. I wanted something smaller. So focusing there was concern at first that there was going to be enough content to fill up one book with just pytest.

00:16:19 But I think it’s good that it’s short. So it’s under 200. I think it’s about 180 pages or something.

00:16:26 Yeah, no, it’s a good book. I have it, and I recommend it often.

00:16:32 Was there any consternation or issue pushback from the publisher? I mean, it sounds like you had a contract at that point, and you sort of said, like, this isn’t going to work. I’m going to change everything.

00:16:44 Was that a mutual decision or they were okay with that?

00:16:48 So I worked with I think it’s called the Design Editor from the beginning, and she and I a couple of phone calls with her.

00:17:01 We probably made phone calls maybe once a week or every other week in the beginning to try to keep up to date, and I just was struggling. I’m like, I don’t think this is the right direction for the book. Let’s try to figure out something else. So we did a little bit of a pause and did a new outline.

00:17:22 I don’t remember really the details. I think she went and talked with some of the other people at the company to think if the change in direction was okay for that.

00:17:35 So it was definitely a collaboration at that point.

00:17:39 Now and then with your outline in hand, what did your process for writing look like at that point? You had some book. Did you keep that? Did you throw it out? What happened after that?

00:17:51 Well, I did change things around quite a bit.

00:18:02 I changed the topic of the subject I was testing.

00:18:06 I kind of just started from scratch.

00:18:08 At first I thought I was going to be able to reuse a lot of content, but it’s mostly reusing the learning.

00:18:14 And I just decided if I wanted to actually, at first I wrote the first draft of the first four chapters I wrote in order, and I even wrote the preface first, even though the advice from my editor was just pick a chapter and write it and probably don’t pick the first one. But I thought of this as a path through the system, path from start to end. And I didn’t know how to get to the middle without going through the beginning.

00:18:47 So I just went ahead and wrote from the beginning to the end.

00:18:54 And then things moved around quite a bit. We shifted things a lot, and there was a heavy edits. I knew that the first chapters was I just getting into the swing of things and would have to be rewritten. And they did. I think I rewrite the first couple of chapters of two or three times.

00:19:15 And that was just working with a copy editor or someone who is looking at sort of the overall flow, not necessarily diving into the technical content per se.

00:19:25 Right. Just the overall flow. It wasn’t a copy editor, just a book design kind of editing. Okay. And the technical aspect, she has edited other Python books, so she’s not a developer, but she’s familiar with the language.

00:19:45 And there were a few things we had to with the copy editor. We had to warn the copy editor about some capitalizations because pytest is lower case, lower case, and they kept trying to upper cases at the beginning of sentences.

00:20:02 Yeah. I’ve run into similar things with Pandas writing about that where the library is lower case. Right. But how do you start a sentence with Pandas?

00:20:16 So what tools do you use while you’re writing it?

00:20:20 Well, they have a custom workflow, but there is support for some.

00:20:28 I am comfortable writing a markdown, so I did almost all my work in markdown and source code. So there’s a way to pull the source code snippets into your document without having to actually copy and paste them so that if you update the source code, it just updates in the book.

00:20:53 Because this was a technical book about coding. You went out and made the code project first, and then you sort of wrote about that and sucked in the code to make sure that the code that you’re putting in there wasn’t just random code that might not work, but there was actually working code from your project.

00:21:15 Yeah, definitely.

00:21:17 Okay.

00:21:17 And the code built up after during the writing of the book as well.

00:21:24 And so they take the markdown and they have some back end process or they’re just fine with Markdown.

00:21:35 I don’t really know what the process is now with them, but it was something other than Markdown that they took, but I just wrote my own converter.

00:21:44 Okay. So they had some other format, but you reformatted your markdown to that.

00:21:51 It’s a very reasonable format, though.

00:21:53 But it was just like a ski dock or something.

00:21:56 Well, it’s a proprietary thing.

00:21:59 Oh, can’t talk about it.

00:22:01 I could tell you, but then, I don’t know.

00:22:04 Okay, let’s not go down that place. Okay.

00:22:08 So proprietary tools, but you are able to get by with nonproperitary tools.

00:22:13 Awesome. Yeah. And they use version control, so it really felt like a software development environment.

00:22:21 Okay, so you complete your book or you think you complete it. What happens after that?

00:22:27 You’re done with all your markdown, then that was it.

00:22:32 Any more process after that or there like Brian Singh.

00:22:36 There was two stages where we after for the first four chapters, and then at the when we were, I guess, through the last chapter. So at two stages, we sent the book out to maybe a dozen or two technical reviewers, and then they gave their feedback back so that we could incorporate it, try to incorporate it.

00:23:08 The major changes in the first four chapters caused a redirection of the book, and then at the end, there were just minor tweaks.

00:23:18 The feedback from the technical reviews was actually pretty important, at least for the first part of the book.

00:23:24 Yeah. Actually, for everything. Like, for instance, I don’t normally use Develop on Linux, so having a developer that is more familiar with Linux to point out that there were some quirks in how Pip worked on Ubuntu, for instance, helped because I had an appendix that talked about Pip.

00:23:50 So, yeah, the review from the technical Editors were good. The process at Pragmatic also is that you can optionally do a beta release of the book when you have like three quarters or 70% of the book done or something like that, and they start selling the book in e book form as a beta reader. And then there’s a feedback form for people to go to tell you if there’s errors. So there’s a process to go through, and then we’d go through on a regular basis. I think on a I can’t remember if it was every two weeks or every once a month, we’d update the ebook for all the beta readers with fixes and Mark problems finished and stuff like that.

00:24:46 Very simple.

00:24:47 That was pretty useful then having the beta program as well.

00:24:51 It was, yeah, definitely.

00:24:53 But there’s effort there, too. It’s very helpful to get feedback and people looking at it, especially with a technical book, just to make sure that things are really working. Like you said, they were going to work.

00:25:05 Also, when editing, you kind of jump around into different sections and it does take a fresh pair of eyes or many pairs of fresh eyes to read through it to say, wow, this transition between these two chapters is too harsh. Or you said you were going to teach me about this during this chapter, but it didn’t happen.

00:25:27 Things like that.

00:25:28 Yeah.

00:25:31 A common piece of advice, even if you’re editing your own book. But if you’re self publishing as well. Right. Is to separate the writing from the editing. Right. And treat them as different activities. Do you find that to be the case?

00:25:48 Yeah, definitely. It’s important to separate those.

00:25:54 Also. One of the reasons why I try to keep my book short is because I also wanted to several times read through it from beginning to end to make sure I understood the flow and make sure it kept going. Well, that knowing that writing and editing are different things is important, but it’s natural to try to do it at the same time. And of course, I would have to. It’s kind of like a meditation practice. You have to remind yourself, oh, I’m not editing right now. I’m writing. I need to stop editing, and vice versa. When I’m editing and fixing things, if I have new ideas that I want to write about, that’s fine. Just write them on a piece of paper or something. Write them down, but don’t try to jump into the writing mode right away.

00:26:46 Interesting.

00:26:47 So eventually, at some point, all your PRS are marked as Invalid or they’re fixed, and then you put the golden stamp on it and you send it off. And after that, you’re good. You’re just twiddling your thumbs.

00:27:07 No, it’s a pretty quick process, I guess. Once we had the final form in hand, there’s a lot of stuff that has to happen, though.

00:27:19 There’s the final copy editing that happens.

00:27:23 So making sure that spelling and grammar is correct, we went through, like a couple of rounds of that because the copy went through, and then I had to review the copy of changes to make sure that they were appropriate for the textbook.

00:27:37 And this was done in the proprietary or this was done at Markdown in the proprietary form.

00:27:43 Okay.

00:27:45 And then after that indexing happens. So going through and figuring out at the back of the book, being able to jump to different page numbers for different topics, that’s something that you get with a published book, too. And I don’t know how to do it if it’s possible with today’s self publishing books or not.

00:28:14 So they had an editor or an indexer go through and create the index, and then you sort of gave it a thumbs up. Or did you do editing to the index?

00:28:24 I think I had the option to, but I just flipped through it and made sure that the most important things people would be looking up were there.

00:28:35 But actually, they did a really good job.

00:28:38 Yeah. Again, I’ve found that.

00:28:40 Well, I’ve actually had mixed results with editing or with indexing. But there are people who do an amazing job of indexing. And hopefully if you want an index or you get one of those people to do it, because a professional can do a really good job. Okay, yeah, go ahead.

00:29:01 But because the final copy editing and indexing does take some time, it’s a laborious process, but it still was in the order of weeks, I think, before we had a book in my hands shipped book.

00:29:20 Okay.

00:29:23 At that point, you’re sort of done and the book is live for sale. What promotions did you do to promote your book?

00:29:33 Most of the promotion was I was talking about it almost constantly on Python Bites talking, and we go through our topics, and then at the end we talk about what’s new with us. And I would mention that I got another chapter done or the beta is available. And I think that that was the best advertising that we could do.

00:29:56 Then I also went to we had the beta available right before the first PyCon I ever went to. So Michael and I got a booth at Python, one of the community booths for the podcast, and I got a big poster with the book cover on it to try to promote the book. Gave out stickers.

00:30:25 I think just getting there and talking with people was good.

00:30:30 I also had a lot of the beta readers show up and ask me questions.

00:30:34 Awesome.

00:30:35 Which was great. And then the following year did that again, and I went to PyCon, and I actually had a stack of books that I could give out. So I’ve been doing book signings at Pycons ever since, whenever I can. Of course, 2020 didn’t happen.

00:30:54 Book signings are a fun thing.

00:30:56 Yeah, that’s cool. And so this promotional expense, has this come out of your pocket, or have they provided you with a banner and stickers and books?

00:31:10 Yeah.

00:31:11 It all came from me.

00:31:14 And I get a discount for buying my own book, but it’s not a huge discount.

00:31:26 I took with me, like 20 or 40 copies or something like that. It’s still kind of expensive.

00:31:32 Yeah. I think for my published books, I think if I order like 100 or 200 books, I get like a 45% discount or something like that.

00:31:46 Okay.

00:31:47 But if you just order a few books and it seems like it’s almost cheaper to wait for Amazon to put your book on sale to buy it that way than to get the author discount there no.

00:32:00 I mean, Pragmatic is pretty good. So even if I only buy like ten or something like that, we get a pretty steep discount.

00:32:07 But even if it’s half price, it still adds up pretty quick.

00:32:12 Yeah.

00:32:13 Awesome. So you’ve been through this process sort of twice. I mean, you’ve done a self published version and then put that into a more formal published version. What advice would you give to yourself before writing your book for you to do it again.

00:32:32 I think to go faster. I think I sweated the tiny little details that I don’t think mattered too much. Hurry up and get through the first chapter or the first draft first get a complete book there and then start tweaking it. I think I dwell too much on little tiny things like whether or not how many examples to put in or which examples just rush through it, get it done.

00:33:06 Premature optimization, what we call that in the programming world. Right. But the favorite agile process where get the MVP out and then iterate on that.

00:33:17 Yeah.

00:33:17 And also just be with test driven development, you need to be willing to throw away your code and start over. And I think with writing, that’s the same part.

00:33:33 It’s sometimes hard to if a chapter doesn’t flow. Right. And you’re just trying to tweak it and trying to change it little bits at a time.

00:33:41 Sometimes it’s just easier to just and you don’t even have to throw it away. You just rename it some other file and start another file and start writing and just see if you can do it better than the second time. And it’s always faster. Just with code, as with writing, even if even if a chapter took you a month to write, you could throw it away and rewrite it in a week or less. It’s not going to take a month again to rewrite the same thing.

00:34:13 Yeah.

00:34:14 Awesome.

00:34:15 Well, do you have any plans for a future book?

00:34:18 I would really like to overtake you at some point in the number of books I have out now, at least a couple of books. More books. I’d like to some targeted, focused books. I think it would be fun. Yeah. I got more books than me.

00:34:37 Awesome.

00:34:39 Well, I think we’re at the end of our questions. Do you have any additional things that we didn’t talk about that you want to add or any insights that you know for aspiring authors, advice you would give them, or words of wisdom?

00:34:55 I think that one of the reasons why people and at least myself, I wanted to write so that I could teach people. But the interesting side effect was there’s a lot of interesting side effects for writing a book. And one of those is I think I learned more than I taught because I thought I understood the path from A to Z. And in reality, I didn’t quite know all the pieces. And if you have to write it down, the holes are glaring and you have to go do some research, did a lot of research and learning new techniques and learning new things when I put it together.

00:35:39 The other thing is I’m not a core pytest developer, so I had the imposter syndrome. I didn’t understand why anybody would be okay with me writing this book when there’s people that clearly understand the topic more.

00:35:57 And that’s just not fair to me. It’s not fair to anybody to put that on yourself. If you have a passion for a topic and you want to write a book about it, write a book about it. It doesn’t matter if you’re the right person to write it or not.

00:36:09 Yeah. And I think to your point, oftentimes someone who isn’t a core developer can write a better book on it, or I would say possibly has better insights because they’re not looking at the guts and they’re coming at it from probably a user’s point of view versus a lot of times someone who’s very involved under the covers probably cares a lot more about minutia than most end users do. Right. And so there’s a potential for misunderstanding the audience. And I think coming out the content from a way that the audience probably.

00:36:55 How do I say this? Impedance mismatch. Right. Where the core developers thinking about things this way, but the users don’t think about that way and want these features. Right. Right.

00:37:08 I think being a user. Yeah. To your point, imposter syndrome is common, but don’t let that stand in your way.

00:37:17 The other thing I wanted to point out is that books are one person’s perspective or maybe a handful of people if they’re writing it with a handful of people. And that’s one of the reasons why people buy books is to get your perspective. Yeah.

00:37:35 When I started writing the book, I tried to give people lots of options. You can do A-B-C or D, but I recommend that you do C.

00:37:44 You can do some of that. But if you do that all over a book, it’s tedious and it gets long.

00:37:51 Just go ahead and give your opinion of how to do it. If it’s just C, just cover C.

00:37:59 Actually, that was some of the feedback I got in the first half of the book was maybe not spend so much time on all the stuff we’re not supposed to do. Just tell us what we’re supposed to do.

00:38:10 Get to the chase.

00:38:12 Awesome. So I think that especially in today’s world with technical books, all the other options are findable on the Internet. So if somebody doesn’t like your solution and go, well, I don’t like how they did that. Well, they can look up some other way to do it. But I think opinions are important in books.

00:38:31 Yeah.

00:38:34 I keep saying this, but one of the values of a book is that it puts you on a path. Right. And it can be an opinionated path. But that is super valuable. Right.

00:38:44 To your point that you thought you knew. pytest. But after you wrote your book, you realized you didn’t really know it. When you teach or you write about something, you understand it a lot better. And so people who put in the effort to write a book or create a course to teach something often have a nice path for you to go along and learn along with them and that can be super valuable.

00:39:10 Yeah. I even had some of the core developers that were part of the technical editor group come back to me and say that they learned about it. So even though they are a core developer, they’re focused on one part of the system and they don’t understand the rest of the whole thing as a big picture as much so it’s good.

00:39:32 Yeah. Awesome. Well, thank you so much for chatting with me. This has been really useful. How can viewers stay in touch with you if they want to check out your book or ask you a question? What would be the best way to do that?

00:39:45 I hang out on Twitter too much, so I’m on Twitter at Bryan Hawking okay. And also encourage people to there’s a contact form at test and code so that’s a good place to send me a message if you want to send me a message.

00:40:01 Awesome. Well, thanks for your time, Brian. Have a great rest of your day.

00:40:04 You too. Bye.

00:40:08 Thank you, Matt for interviewing me. It was fun. Thank you Datadog for sponsoring check them out at Datadog and thank you to all the listeners that support the show through Patreon join them by going to support those links as well as links to Matt’s course and my are in the show notes.

00:40:26 That’s all for now.

00:40:27 Now go out and test something or maybe go write a technical book.

00:40:31 That would be cool.