#148: Python Book Authors' Panel Discussion Transcript

00:00 Michael Kennedy: Are you a fan of developer and technical books? Have you ever wondered what went into the writing of your favorite Python book? This week, we'll peek inside the world of book authorship with a panel of renowned developer-focused authors. You'll meet Katharine Jarmul, Bruce Eckel, Luciano Ramalho, Dan Bader and Brian Okken. This is Talk Python To Me, Episode 148, recorded January 26th, 2018. Welcome to Talk Python To Me, a weekly podcast on Python, the language, the libraries, the ecosystem and the personalities. This is your host, Michael Kennedy. Follow me on Twitter, where I'm @mkennedy. Keep up with the show and listen to past episodes at talkpython.fm, and follow the show on Twitter via @talkpython. Hey, everyone. Before we get to the panel discussion, I want to tell you really quickly about a new course we just launched, Mastering PyCharm. If you worked with some of these IDEs, like PyCharm, you know there's so much going on. There are so many features. Those can actually be a little bit hard to discover and use. I created this eight-hour course to give you a grand tour of PyCharm. It turns out it's also a grand tour of software development. We cover things like source control, refactoring, working with databases, client-side web apps, Python packages, unit testing, data science tools, working with projects, being super productive with the editor and lots more. If that sounds appealing to you, just visit training.talkpython.fm, and find the Mastering PyCharm course. Now let's meet our panel. Hello, everyone. Welcome to Talk Python. We have Luciano Ramalho, Brian Okken, Bruce Eckel, Dan Bader, Katharine Jarmul and me, of course, Michael, your host. We're going to do a pretty large tech book author panel, which I'm really excited to share this, all of your thoughts with everybody. This is going to be so fun. Let's do a quick round of introductions. Some of you have been guests on the show before, some of you are my co-hosts, right, Brian? People know you well, but we'll go around the table real quick. Start with you, Katharine. Maybe just quickly tell people who you are and what you do day to day.

02:20 Katharine Jarmul: Hi, yeah, thanks. I'm Katharine. You might know me by Kjam. I run a data science company here in Berlin, Germany, called Kjamistan. I mainly work on data science and machine learning, but I also have kind of a focus on in production and deployment and systems. I've been doing more security work recently. Those are the things I'm passionate about.

02:46 Michael Kennedy: Yeah, very cool. Luciano, how about yourself?

02:49 Luciano Ramalho: I'm the author of Fluent Python. I currently work for ThoughtWorks, a global consulting company. I'm sometimes in projects with clients, but more recently, I'm also in our global capability team, which is a team that aims to develop the capabilities of our consultants around the world. I've been diving into the wonderful world of e-learning and MOOCs and those kinds of systems to pick one for us to use.

03:16 Michael Kennedy: Yeah, that sounds really, really fun. Bruce, how about yourself?

03:20 Bruce Eckel: I'm Bruce Eckel. Apparently what I do is study programming languages, in hindsight, 'cause I look back on my career and I see that seems to be what I do. Right now, I tried to start working on a book on concurrent Python. That, as concurrency always has been, deeper hole than I expected. There's all kinds of interesting other possibilities. In the meantime, I got sucked into a project, which we've been working on for, mm, almost a year now, called Atomic Kotlin. I'm mostly immersed in Kotlin right now. The other thing that I've done for the last almost 10 years is study alternative organizational structures to try and come up with ways of organizing groups and companies that doesn't suck.

04:15 Michael Kennedy: Because there's plenty that do, right?

04:17 Bruce Eckel: Mostly they do, which is why I realized that I went off on my own, like 30 years ago, because I didn't want to play in that sandbox. Now I'm realizing I should have created a better sandbox, but, oh, well, hindsight.

04:33 Michael Kennedy: There's a lot of stuff you can see in hindsight, that's right. Brian, people know you, I'm sure, but go ahead and introduce yourself for those who don't.

04:40 Brian Okken: My name's Brian Okken. I wrote Python Testing with pytest. My day job, I guess, I do cohost a couple podcasts. Then, also, I'm a lead engineer, or lead engineer slash software manager, test manager for a small team as part of a communication test system, Rohde and Schwarz.

05:01 Michael Kennedy: Okay, excellent. Dan, how about you?

05:04 Dan Bader: Hey, I'm good. Thanks for inviting me back onto your awesome show. I feel like I'm in amazing company this time. My name's Dan Bader. I recently published a book called Python Tricks: A Buffet of Awesome Python Features. I also do some Python consulting. Then also run a couple of Python-related websites, realpython.com, nerdlettering.com, and my own personal website at dbader.org. It's almost like 100% Python that I spend my time with every day.

05:35 Michael Kennedy: That's really awesome. Well, thanks for that, everyone. Now people kind of know where we're all coming from. A couple of you have mentioned the books that you've written. I'll just make some quick comments on that, and others haven't. For example, Dan, you have the Python Tricks book, which we actually did an episode on, 141 on Talk Python, on that. That's great. Luciano, you have Fluent Python, which we had an episode on that on Talk Python, as well. Brian, you have pytest, which we talk about a lot on the podcast. Katharine, tell us a bit about some of your authorship.

06:09 Katharine Jarmul: Yeah. I coauthored Data Wrangling with Python, which is an introduction to Python for people that, perhaps, are starting to want to work with data. Then I have a few O'Reilly video trainings. I also helped create the second edition of Web Scraping with Python or Python Web Scraping, migrating into Python 3, last year.

06:32 Michael Kennedy: That's really interesting. I feel like there's a lot of people coming into Python through the data science angle. While it feels like it's pretty similar, it's not really exactly the same type of Python that you write. I feel like when I read data science code, it actually feels like I'm reading a slightly different flavor or variant of Python than, say, if I'm reading web code or something.

06:54 Katharine Jarmul: Yes. When we started thinking about the popular data science libraries, they're often heavily complemented with either Cython, for example, if we're using NumPy, or Wes,creator of Pandas, he was an R person first, and then wrote Pandas. There's some things in Pandas that are much more idiomatic of R than they are of Python. Of course, that's changing over time, but we find these interesting influences from other places. For example, if you're working with Spark or the JVM or anything that's JVM backed, then you might also see some things that look more similar to Java. It's this weird world where there's a lot of people working on libraries. They may not be Python first. For that reason, it has some different quirks, if you will.

07:43 Luciano Ramalho: Can I jump in?

07:44 Michael Kennedy: Please, go ahead.

07:45 Luciano Ramalho: I totally agree with what Katharine just said. I just want to add another thing, which is, for instance, in Fluent Python and most of our intermediate books, we emphasize a lot the use of iterators and generators, those kinds of structures in the language. But then, when you go to use NumPy, that's just wrong most of the time because you want to use the vectorized operations. This is kind of a fundamental shift in thinking. I won't remember the name of the book now, but I have a really good reference, a book by a French author. It's Creative Commons and it's written in English, about changing your mindset from iterative code to vectorized code for NumPy. I will share with you the link later.

08:31 Michael Kennedy: That'd be great, I'll put it in the show notes. Very cool. Bruce, you've written quite a few books. I've known about your books for a really long time. You want to talk about some of 'em that are notable?

08:40 Bruce Eckel: Well, probably most people know me for Thinking in C++ and Thinking in Java, but, yes, I've written a bunch more. Then there have been a number of attempts that haven't worked out. I seem to also do a lot of coauthoring, even though I keep saying I'm not going to do that anymore 'cause it can be very hard. I started out in, actually, in hardware in my first book, which I self-published, and sometimes think, gee, I should have just kept doing that. It was a long time ago. Self-publishing was a little more challenging at the time.

09:22 Michael Kennedy: You were a real rebel doing that.

09:23 Bruce Eckel: A little bit, yeah. It was called Computer Interfacing with Pascal and C. Then I got involved in C++. I was on the standards committee for its first eight years, although I can't tell you anything about C++ now. It's changed so much.

09:37 Michael Kennedy: It's really different.

09:37 Bruce Eckel: It is. I wrote several books on C++, and then kind of moved over to Java. Then I've, let's see, I coauthored a book on Flex. I tried coauthoring one a couple of times on C#. Then Atomic Scala. Now I'm working on Atomic Kotlin. I keep trying to write a book on Python. People ask, "Well, are ya ever going to write a book like Thinking in Java for Python?" but I would say Luciano's book would be that book. It makes no sense for me to try and do that. But this concurrency project is, I don't know if anybody has looked at Julia, but that's kind of thrown me because I'm going, well, maybe the answer is not to use Python. Anyway, concurrency has probably been my biggest struggle in my career.

10:41 Michael Kennedy: Thank you. There's a lot of interesting stuff happening around Python currency right now. The whole asyncing await stuff is showing up. There's a lot of web frameworks that are sort of async only or async first. I think it's a good time for covering that topic. Very cool.

10:56 Bruce Eckel: It is, but I'm just starting to wonder if the answer isn't to kind of step outside of the mainstream Python world and connect to Python, rather than try and do it in Python. I don't know yet.

11:10 Michael Kennedy: I think it somewhat depends on whether it's computational or it's I/O bound, like you're waiting on web services and databases.

11:17 Bruce Eckel: Sure, parallel versus async.

11:19 Michael Kennedy: Yes, exactly. That sounds interesting to explore in a book, so I'm looking forward to checking that out when you finally wrangle that topic. Let's dig into this concept that you touched on there a little bit about coauthoring. Coauthoring, to me, sounds both fun and really hard. I guess it depends how you do it, if you write different chapters and stuff. I've certainly coauthored online courses, but no books. Who out there has, I know, Bruce, you said you've done it some. Anyone else done any coauthoring or considered it, and why, why not?

11:52 Katharine Jarmul: I have only coauthored books at this point in time.

11:57 Michael Kennedy: Oh, how interesting. How was your experience? Why did you go down that path?

12:01 Katharine Jarmul: The initial book that I wrote with Jackie Kazil, she actually was writing it on her own first, and then reached out to me because the deadline, she wanted to reach deadlines, and two heads are better than one sometimes for that. I think that if you're not really organized about exactly what is expected. It's the same this as, for example, if you were building a project with a friend on the side. Let's say you're moonlighting or something. You're usually doing it with someone you know or perhaps somebody who knows somebody who you know. There's some element of personal connection. You need to be really clear about deadlines, who's doing what. Make sure it's absolutely clear and that you have some knowledge sharing, in terms of who's going to cover what parts in what sequential order. This is extremely hard to do, even with bright folks by your side. I would say organization and really trying to use something as if you would almost do an issue tracker to really say, "Okay, are you going to be doing the introduction to generators here, or should I do it in a later chapter." and so forth.

13:11 Bruce Eckel: I used an organic process, which is much harder. I guess it's not harder if it's working. It's interesting 'cause I see this division between, when people talk about book authoring, and there's the, okay, ya have to have a lot of structure. Some people say you have to write from X hours to X hours every single day. Then, I guess, for me, I look at that and I go, "I understand that that works for some people, but for me, I need to be inspired to write." I don't write when I'm not inspired. If I'm working with somebody, I can't manage them. I can't say, "You have to do this or that." But I will say, one of the things, after doing this a while, and then I asked Gerald Weinberg about it, and he's written and coauthored most of his books. He had several guidelines for coauthoring. The first one was everybody works on every chapter. The second, I think, was you never sign a contract until the book is done. The third thing, and there might have been a fourth one that I can't remember right now, but the third thing is if the book fails, you walk away from it. Nobody owns anything about it. I've never been able to successfully do that, but I feel like that is a way to kind of keep you out of trouble because the times that I've gotten into trouble is when, for example, you do a contract first. Then the other person might or might not feel like, well, it's almost like working in a lab. When one of the lab partners punts, and then you go, "Well, we're committed, so I have to take over." That's all I wanted to say.

15:09 Michael Kennedy: I'm kind of like you. I know some authors, they have really strict guidelines. I'm going to sit down and work from 8 a.m. to noon every day. Just do that until I'm done. I'm one of these people who, if I get inspired, I can be five times more efficient and effective in producing stuff than if I'm not. I just kind of stare at the screen and get distracted and whatnot. I don't know if I'm particularly productive, or just particularly unproductive other times, but capturing that inspiration is really important to me. I can see how it's a tough balance with a coauthor.

15:46 Bruce Eckel: Well, the one thing I wanted to point out was that I often see the people who say, "Oh, you have to do, you have to work from eight until noon every day." They're the ones who talk about it. But the people who go, "Well, I have this organic process." they tend not to talk about it. People who are wanting to write books think that the first way is the only way to do it.

16:06 Michael Kennedy: Right, right, makes sense. Brian, did you consider trying to coauthor yours? How long did your book take you to write?

16:14 Brian Okken: Like about twice as long as I thought it would take. No, I worked on it for probably almost a year. With my lifestyle and busy work schedule, I guess, like everybody else, I don't think I could have coauthored with somebody 'cause I think they would have been frustrated. However, that being said, I did work with a development editor that was, she was reviewing it. We talked about the book content on a regular basis. She isn't a coauthor, but may as well have been. Very much appreciated the input. Then, also, getting feedback from other people. I did get some ideas from some of the core pytest people of things to add that I had forgotten. Even though I didn't coauthor at all or consider it, I did pull in input from lots of places.

17:06 Michael Kennedy: That's great. This portion of Talk Python To me is brought to you by Linode. Are you looking for bulletproof hosting that's fast, simple and incredibly affordable? Look past that bookstore and check out Linode at talkpython.fm/linode. That's L-I-N-O-D-E. Plans start at just $5 a month for a dedicated server with a gig of ram. They have 10 data centers across the globe, so no matter where you are, there's a data center near you. Whether you want to run your Python web app, host a private Git server or file server, you'll get native SSDs on all the machines, a newly upgraded 200 gigabit network, 24/7 friendly support, even on holidays, and a seven day money back guarantee. Do you need a little help with your infrastructure? They even offer professional services to help you get started with architecture, migrations and more. Get a dedicated server for free for the next four months. Just visit talkpython.fm/linode. Dan, how about you?

18:03 Dan Bader: I didn't work with a coauthor. I think, just in terms of how I like to work, I just preferred doing this on my own. Also, because I really wanted to see if I had it in me. Could I actually finish this project and then publish that? I think I might reconsider that for future book projects, but pretty much like everyone else mentioned, there's some downsides around that. If you're in any kind of partnership, it can be really awesome, but it can also be your downfall, where maybe one person is less committed than the other one. Then it becomes tricky to actually ship the final product. Didn't do it for my book, but I was very happy that I got Mariatta Wijaya's input on the book, and also she wrote the forward for the book. That was great support for me.

18:51 Michael Kennedy: That's nice. Luciano, have you coauthored any books?

18:53 Luciano Ramalho: No, I haven't, but I like that Dan just mentioned the fact that he wanted to write the book on his own to see if he was capable of doing that because for me, that was totally the point, as well. I started, actually, three other books in the last 20 years that I never finished. Fluent Python was the only one that I managed to finish. I never had a coauthor in the other projects, either, so I didn't let anyone down. But in this case, I had a contract with O'Reilly, which is a publisher that I really admire. I was self-employed at the time. I decided to just, in this case, failure was not going to be an option. I did it, I wrote about Python for about nine months. Then my editor at O'Reilly, Meghan Blanchette, who was just completely awesome. She's now working for Pragmatic programmers. I really recommend if you want to work with a publisher, one of the greatest benefits was having a great editor. She's one great editor. Anyway, Meghan started talking to me that it was likely that I wasn't going to make the deadline and so on. The writing wasn't as fast as she expected. Then I just had a serious conversation with my wife and said, "You know what? I need to write this book, and I'm not going to do anything else." I just quit my other part-time work, and worked full time on the book for the next nine months. In about a year 1/2, I finished it. I'm really glad I did it, but I know, I feel very privileged that I was able to stop everything for nine months to work on the book.

20:35 Michael Kennedy: I was going to say that's a real commitment to taking that much time effectively off work. Obviously, you're working, but you don't get paid very much as you complete chapters, right? It's not till the book is done that you actually, you see the benefit.

20:50 Luciano Ramalho: I ate into my savings, I can tell you that.

20:53 Michael Kennedy: That's pretty intense. This is a big bet. Every one of you who's written a book, you said nine months, Brian said a year. That is a big project. You don't really get that much feedback until you ship it. Katharine, you want to speak to that? How did you think about that and handle it?

21:11 Katharine Jarmul: For me, both of the times that I was coauthoring a book, I was also consulting and usually working on projects, so books were kind of like a mornings, nights, weekends. I have a very compassionate partner who would refill my coffee. It was definitely something that was more like passion time. It hasn't been said here yet, but don't expect, even if your book is popular, to make any decent amount of living wage off of a bok. This really needs to be not something that you see necessarily as a job that will make you money to feed yourself and so forth, but more as something that you do because you enjoy the other things that you might get from book writing, or you enjoy contributing back to the overall knowledge of the community and so forth. I pretty much time boxed my writing in a sense of saying if this particular chapter took longer than one weekend, then just turn it in as it was, and work with my editor. For me, this worked well, in terms of not having it take over my entire life.

22:27 Michael Kennedy: I'm sure that helps manage the stress of it, as well. Let's touch on this sort of benefits/revenue thing for a little bit. One of the first areas I wanted to ask you all about is self-publishing versus working with a traditional publisher, O'Reilly, Pragmatic, whoever. Just to kind of put this in perspective for the listeners who maybe haven't thought a whole lot about it. There's a book that I read quite a while ago from the guys who created Ruby, actually, Ruby on Rails, rather, called Getting Real from 37 Signals. I think you can get it for free now, but at the time, you could read it on the web or your could buy a digital version. They self-published it. Then they wrote some kind of retrospective blog post a year or two later and said, "We did really well with this book. We made 1/2 a million dollars off of this book that we wrote and put online and sold the PDF and and stuff for. But if we'd worked with a traditional publisher, we would have gotten, like, 10%, $50,000." The difference between 1/2 a million and $50,000 seems to me really, really significant, but all the benefits you were all talking about, of, say, having an editor, having the support, this whole success story that they had was predicated upon them having a very large following on their blog and around their company, anyway. I noticed some of you have self-published and some of you have gone through the traditional route. Maybe, Brian, do you want to take that first? Did you think about self-publishing? What are your thoughts on that?

23:59 Brian Okken: I had wanted to write a book in the first place because I had an ebook that I self-published that was, essentially, a collection of blog posts and tutorials that I just put together.

24:12 Michael Kennedy: I remember that.

24:13 Brian Okken: It sold for, like, five bucks apiece. Since a lot of people were buying it for, they could get the content for free, anyway, that's what, maybe want to pursue working with a publisher, but I had heard all of these stories about people not getting, not making very much. I did hold, after talking with a few different publishers, settled with Pragmatic because they're, I think they're extremely fair with their revenue split. It's only been out since September. It's not something I'm getting rich off of, but I don't worry about whether or not I can afford Starbucks anymore. I guess that's the perspective I have on that. I would definitely go again. I'd probably do both. I am looking forward to do both self-publishing and working with a publisher. The benefit of working with a development editor, I think, is enough to offset some of the differences in revenue that you get, my own perspective.

25:17 Michael Kennedy: It also depends on how big your audience is that you can connect with to get the book, right? Stephen King could probably really easily self-publish a book and be fine, but if you've never written a book and you don't run a bunch of podcasts or something like this, it can be a challenge, right?

25:33 Brian Okken: Yeah. But also to put in perspective the 37 Signals book, they had a huge following when they were publishing that. Signals Versus Noise was very large.

25:44 Michael Kennedy: Yep, yep.

25:45 Bruce Eckel: I've had a lot of experience with this. First of all, it's important to understand how the publishing industry works. There's about 10% of the books published kind of break even or make some profit. About 1% of the books published are actual successes. When you get involved with that, if you have a book that's a success, it's got to pay for the 90% of failures. The publishing industry looks at these numbers, and they tend to say, "Well, to get our numbers up, we just have to publish more books." They don't consider should we try and make better books. There are, of course, special cases and things like that where that's not the case, but in general, that's kind of how their numbers work. The other thing that ya have to look at is what kind of commitment are they going to have? For the longest time, I wouldn't take, I wouldn't worry about the advance. Then, after talking to people, I realized, actually, you want to push for the largest advance you can get because you want to put the publisher in financial jeopardy because that's what's going to stimulate them to go out and promote your book. Some publishers will try and promote a book for a few months. Then if it doesn't go gold, then they sort of drop it, and they stop. There's all these pitfalls that you can get into. You don't have control over your book anymore once you sign that contract, unless you rewrite the contract, which they'll tell you that we don't do, but you can. You can always line through the contract and everything. If you self-publish, you are then responsible for, as people have been saying, promoting your own books. Sometimes it works, and sometimes it doesn't. But even when it doesn't work, you'll often get maybe more money than you would have just by taking an advance.

27:57 Michael Kennedy: Right, it's got to be basically, like, 10 times less good to do your self-publishing, or something on that scale, right?

28:04 Bruce Eckel: Something on that scale. There's also the satisfaction of doing it yourself, and I'll point out one more thing, which is that now if you start talking to a publisher, even one that you've published with before, the first thing they'll do is send you this form that's asking you how are you going to promote your book? Do you have a blog, do you have a podcast, do you have all these things? When you look at that and you go, "Well, why am I working with you if I'm going to be promoting my book? What are you bringing to the table?" These days, if they can't promote it, then you can pretty much do all the rest of the stuff yourself. Unless they're wonderful promoters, you should really think seriously about what are you getting from the publisher?

28:52 Michael Kennedy: That's really great advice. Luciano, yours was through O'Reilly. You said that's your only book. Did you consider self-publishing or would you in the future?

29:00 Luciano Ramalho: Oh, yeah, I would. But, really, for me, it's pretty clear that it was different. I don't have a big following. I'm not really good at marketing. It was important for me to author a book with a well-regarded publisher. I also learned a lot from them. I don't regret at all the fact that I worked with O'Reilly. On the contrary, I think I was very lucky to be able to work with them. But in the future, yes, I totally consider self-publishing or a different publisher or whatever, but mostly self-publishing.

29:34 Michael Kennedy: Your book was really popular, so I definitely think it put you on the map after that, so that's really cool. Katharine, yours was through a traditional publisher, right?

29:42 Katharine Jarmul: Yeah. I have a book with O'Reilly and a book with Pact. I have been approached from some other folks, as well, but knowing how much time and energy goes into a book, I'm actually really curious to hear from some of the others that have self-published, how did you go about through the editing process and what platforms did you use? Did you determine pricing beforehand, or was this something you figured out after? This is something I'm very curious about.

30:13 Michael Kennedy: Go ahead, Luciano.

30:14 Luciano Ramalho: No, just to add, I really like the questions that she was asking. But just to add, like, for instance, tech reviewers. That was something that was awesome that. I could have gone after people to do that, but, anyways. Tech reviewers.

30:29 Michael Kennedy: Dan, I'm saving you for last in this round because I know that you did self-publish yours, right?

30:34 Dan Bader: Yeah, I went 100% with the self-published route.

30:38 Michael Kennedy: What was that experience like? Maybe speak to some of Katharine's questions.

30:42 Dan Bader: For me, I think it worked out really well, but I can totally see. There's just different trade offs involved. Where I was starting from, well, one reason was completely personal, where I, the reason I went into self-employment was because I wanted to have 100% control over the projects that I work on and who I work with. I just wanted to have that control over my life. I wasn't going to hand it off to a publisher, and then you'd be like, okay, now I have all this deadlines and all this stuff in my life that I really enjoyed not having. That was one personal reason. Then the other one was, I think Bruce, you mentioned that with how publishers today, especially for a first-time author, they're not really going to go out there and put on a big roadshow and promote your book and pay for ads and whatnot. It's pretty much you're on your own, anyway. You just get a chance to kind of maybe have some of the prestige of that publisher color off on your book. I looked at my situation, and I was like, okay, well, I have this programming blog. I have this Twitter following. I have a bit of an audience that I can work with here. I decided to go the self-publishing route. I think it worked out pretty well. I'm still working on that first 1/2 million or whatever, but in the end, it was worthwhile, doing it that way, for sure.

31:59 Michael Kennedy: That's cool. Tell us some of the tools you used and things like that.

32:03 Dan Bader: In terms of just making it happen, from a technical perspective.

32:07 Michael Kennedy: How did you actually build it?

32:08 Dan Bader: I think as software developers, for anyone who's listening, I think you're in a uniquely great situation right now with, for self-publishing your book. All of the tools are out there, a lot of them are open source. You can just compile all of the ebook formats that you're going to need, or print-ready PDF that you can hand off to an on-demand printer, like CreateSpace. You can find all of that stuff online. It's not super easy to use, but if you can work with a Python or C compiler, you can definitely make that work. That's what I did. I pretty much had a full build pipeline for my Python Tricks book. Well, first of all, I wrote everything in Markdown, which, for those of you who don't know, it's a plain text format that typically compiles to HTML. It's just a little bit nicer for you to insert bold text and headlines and stuff like that. But there's a really great tool called Pandoc. It's a document compiler or conversion tool. You can feed all kinds of formats into it, including Markdown, which is what I did. Then on the other hand, you can output HTML, you can output LaTeX, and then compile that to a PDF. That was a central tool that I used where I could feed in my source files, and then have all the different output formats that I needed generated. I could adjust the typography and page sizes and all of that. The great thing is, because, well, you're just feeding in a bunch of plain text files into this tool. Then what comes out, this sort of LaTeX intermediate stuff, or code, it's all plain text. You can really understand how this all works. You can use other tools, like, for example, a C pre-processor, to actually have little macros and stuff in your input text that I can now use and I can generate five different versions of the book with one little build script. I just hit return, and it will generate the Kindle file or it would generate the print file for Amazon CreateSpace, it will generate the ebook file in all these different formats. Once you've got that set up, hopefully I'm going to be able to carry that over for my next book project.

34:20 Michael Kennedy: That's sounds really, really cool. Could you also maybe tell people how you sold it? I know some people use Gumroad. You can self-publish on Amazon. You could just put a PDF in a Stripe checkout JavaScript thing on your website. How did you actually get it out into the world?

34:38 Dan Bader: For the first version, I actually used Gumroad. I just set up a page on my site that had a Gumroad button. You can embed it, and people can enter their credit card information, and then buy your book and download it right away. That worked okay. Initially, I released it at a really low price. I think the first iteration of the book, it was, I don't know, it had maybe 20 or 30 pages. I think I started selling it at, like, $3.99 or $4.99 or something, a relatively low price for a book like that. Then just over time, as it grew, I got more serious about the delivery mechanism. Now it's actually on Amazon and it's published on Amazon Kindle. It's available as print copies through the Amazon CreateSpace on-demand printing thing. Then I'm also using a company called BookBaby. They're a ebook publisher, but they're not really like a publisher in a traditional sense. You just send them a file, and they will makes sure it gets on all the different ebook stores that are out there, like the iBook store for iPhones and iPads, and also Amazon and Barnes and Noble. They're kind of like a multiplexer for that. You send them one file and pay them 300 bucks, and they put it everywhere. Curious to see how that will play out.

35:57 Michael Kennedy: That's really interesting. One other thing is Bruce really made a great point about you go to the publish, and they're like, "How are you going to promote your book?" I'm sure people are thinking, wait a minute, that's why I'm here talking to you 'cause you have the audience and the reach. But you managed to get your book number one in Python on Amazon, even though you had no publisher, right?

36:18 Dan Bader: That was pretty crazy. It made the whole thing very real all of the sudden. That was great.

36:24 Michael Kennedy: Absolutely.

36:24 Dan Bader: The reason you can, I was able to do that because I had worked on building that following. I started a Python newsletter and started just sharing articles and sharing tips and stuff on my blog and on my Twitter. That gained enough momentum that I was able to say, "Look, I'm going to be launching this book now. You can get it on Amazon." and kind of have this big launch and make a couple of thousand sales on the first day. That really bumped it up. Then you can kind of ride out that wave. But, obviously, you can only do that if you worked on building up that audience first. I can totally understand that that takes a lot of time. That actually probably took a lot more time than writing the book itself. It's not like a magic bullet where you can just go, oh, you tweeted a bunch of times, and then it'll do really well. That's a whole nother project that you'd be working on.

37:20 Michael Kennedy: Tweet a lot. Another topic that I wanted to touch on with you all is there's probably a lot of people out there who would like to write a book, they'd like to put something that they're really passionate and expert about out there in some sort of written form, but maybe they've never considered themselves a good writer. They got a B in literature, and they didn't really enjoy essays and things like that. Maybe we'll start with you, Brian. What would you give people advice for improving their technical writing or sort of getting started like that?

37:54 Brian Okken: Blog, start blogging. Just write. The best way to get better at something is to practice. Do it. I've been blogging for maybe five years or more before I started writing. I don't do it very consistently, and I definitely don't do it very much now because two podcast and all, but the--

38:16 Michael Kennedy: You audio blog.

38:18 Brian Okken: I started podcasting 'cause I thought it would be easier than writing blog posts. Yeah, that's a mistake. That's my advice, is do it and get feedback, and be humble about the feedback and listen to it. I mentioned that in the entrance of the, introduction to the book. Luciano, he was one of the reviewers of my book and was very honest about the direction it was going, and I took it to heart and it made it better, so listen to feedback.

38:46 Michael Kennedy: That sounds really good. Luciano?

38:48 Luciano Ramalho: Blogging, totally. I just recently, I never have been very disciplined with blogs, so recently I just launched a wiki based on DokuWiki that gives me a wiki engine, which is really nice because it's simple. It's called stand up dev. I'm writing slowly there. Well, the advantages for me of having a wiki instead of a blog is that I like to be able to link across, and also not having just time-based scheme of publishing. But I wanted to say one thing that I tweeted actually some time ago. David M. Geary is the author of some famous Java graphics books, and more recently, HTML 5 Canvas book. He wrote, I think, in one of his prefaces a recipe for writing a programming book. It also applies to blog, and it's really good. They have recipes. Called an interesting example illustrating an idea. I think this is the key. I call this the example-driven approach of writing. You think of an interesting example to demonstrate an idea. Then you explain it. The text flows from the example. The text is there to explain the example. The example is there, of course, to convey some idea or some concept. Then you just repeat. I took this idea to heart. I think one of the things that I'm proud of in Fluent Python is I think it has interesting examples. Short, but interesting. I don't like books that have a lot of foobar examples, for instance. Fluent Python has a few foobar examples, but most of them are not foobar examples. It's hard, actually, to come up with good examples, but I think it's totally worth it to make the book interesting. Of course, you can do that--

40:35 Michael Kennedy: I agree. I don't like those fake examples, either. I always feel like they're kind of a cop out.

40:35 Luciano Ramalho: I think it's good to be able to build from something into the book. In my case, I built on lots of presentations because I've been using Python and I've been evangelizing Python since '98. I had a lot of presentations and a lot of course material over the years that were just slides and examples. A lot of that went into the book. I really think the idea of having some prior motivation to develop examples and write, like a blog or courses or podcasts or whatever, is a very good way of building up material to then launch into a book.

41:15 Michael Kennedy: Great. You brought up the example of almost a pattern for writing, a recipe for writing blogs and books. I interviewed A. Jesse Jiryu Davis from MongoDB. He wrote a really great article. I think actually he gave a talk on it and then also wrote an article. He basically classified five different design patterns for blogging. If you know what pattern you're aiming for, it's really much easier to write 'cause you're like, oh, well, that means it goes like this, this, this, and there's some of that, and then it finishes like that.

41:45 Luciano Ramalho: That's nice.

41:46 Michael Kennedy: It was really, really nice. Actually, that was Episode 69 of Talk Python. Katharine, what advice for people getting, who maybe don't write a lot but want to?

41:55 Katharine Jarmul: This is a little bit hard for me because I had a degree in journalism right before I started doing Python.

42:06 Michael Kennedy: The trouble with writing is not a problem?

42:08 Katharine Jarmul: Writing kind of was a job.

42:10 Michael Kennedy: Exactly.

42:13 Katharine Jarmul: When you go to journalism school, or for those of you that might have had writing degrees, you kind of learn to separate writing from the type of writing that most people think and experiment with. This whole concept of you have to be in the mood to write and this, that, if it's your job, you just can't just be like, "Oh, editor, I don't really feel like writing today. I think I'll go home." You kind of have to produce. I compare it to some days, you don't want to write code, but you need to write a few lines, at least. Once you write a few lines, maybe writing a few lines more will feel easier, and the day moves forward. I think that in J school, for me, at least, there was quite a lot of very intense deadline writing. You would have to write whether you wanted to or not if you were going to pass that course. I think this put me in a mind space of, okay, I'm going to sit down. I'm going to maybe brainstorm, make a small outline, do whatever tiny, little steps, putting one or two words together until I have sentences. Then sentences turn into paragraphs and so forth.

43:19 Michael Kennedy: That's really interesting. Did you come into programming through this sort of data-driven journalism side of things?

43:26 Katharine Jarmul: Well, I was actually supposed to be in computer science from far earlier. I was writing C++ when I was in high school. I was hacking and running my own website when I was young, but I dropped out of computer science because I felt really uncomfortable when I went to university because I was one of a very, very small, small number of women in my program. Then I went into statistics, and after that, into journalism, and then found my way back to computers.

43:58 Michael Kennedy: How interesting. I do find it really surprising that journalism and Python and programming actually intersect non-trivially these days, compared to how it used to be, at least.

44:08 Katharine Jarmul: There's more and more resources on just how do we combine this data, journalism and storytelling all together. I feel like data science is a very interesting intersection there because even as a data scientist, you also have to think about how you tell the story, in the sense of how you report it to somebody that might be able to make some sort of actionable choices based on the data that you find.

44:31 Bruce Eckel: I also started in journalism in college. My first year, I was a journalism major. One of the best courses I had was taught by a editor from the LA Times. He had us compose at the typewriter. That was the whole thing. We started with a set of facts and, I don't know, and hour 1/2. Then he kept changing the time and reducing it and reducing it until it was, like, I don't know, 15 or 20 minutes to write the story. It was super useful.

45:02 Michael Kennedy: Wow, that sounds really interesting. Bruce, go ahead and give us your thoughts on also getting into writing, although being a journalism major, maybe you also have not so much of that experience.

45:12 Bruce Eckel: Well, I did it. In high school, I was involved in journalism and studied in the first year, and kind of realized it was just going to be more of the same thing, and so I changed to physics, and then got into physics and engineering, and eventually computer engineering for my master's degree. I kept showing up at the college newspaper and getting involved with there. I guess I always had this impulse to do it. But I would say for people, in fact, at the last PyCon, I held a little open spaces for people who were interested in writing. I'd say a couple of the most important things that came out of that, I think I blogged about it, so the details are in my blog, but probably the most important things that I think people don't get taught is something called active voice, which a lot of people don't know what that means. It means, more or less, you're talking in the immediate tense. It makes your sentences shorter and more direct and more connected to the reader. The other thing, which was huge, someone told me this years ago, is once you think you're done with whatever it is, your blog post or your chapter or whatever, is go back and read it aloud. By reading it aloud, and that's every single word. It takes a long time. But things will jump out at you. It makes you realize that when you're reading quietly, you skip over stuff and you don't notice things. By reading it aloud, it forces you to pay attention to every single word. The amount of rewriting that you will do when you do that process is kind of amazing. Most of my work now, I end up editing myself. When I'm coauthoring the Kotlin book with a woman who's originally Russian. Her English is good, but she has a hard time writing. Originally, I was just going to kind of be the editor and publisher of this book, but now I'm kind of actively writing and rewriting and doing a lot of pretty heavy editing because of that, but that's just the way projects are. They change, they evolve.

47:38 Michael Kennedy: That's really great advice. I like the active voice. Definitely a fan of that style of writing.

47:44 Bruce Eckel: That is the hardest thing to learn. Even when you know what it is, you will fall back to writing in passive voice. Then you'll recover. The hardest thing in the world, I think, is just to understand what it is and to constantly be looking for places where you can change passive to active.

48:03 Michael Kennedy: Nice. Before we move on, I'm just going to give a quick shout out to something I saw on GitHub this week that's related to what Katharine brought up, and you as well Bruce little bit. You're probably familiar with FiveThirtyEight. They write a bunch of data-driven articles and journalism. They have a place where they have every bit of data for every article that they write, all in one GitHub repository. If people are looking to do data-driven writing, there's just this amazing place at github.com/fivethirtyeight/data. Very, very cool out there. Dan, how about you? What are your thoughts on this I'm not much of a writer, but I want to write a book? How do I do that?

48:42 Dan Bader: Man, that's a tough question. I can only speak from personal experience. What it came down to for me was, at some point in my life, I actually considered going to, getting a journalism degree, which is funny because that came up a couple of times from everyone else here in the show. Maybe there's some weird connection there. I'm sort of glad that I didn't go down that road, and went with computer science, but I really enjoyed working on things like research papers and the thesis that I wrote. I actually got a kick out of the writing and just that habit of getting up in the morning, sitting down and putting something in writing, and having the ability to go back and refine it. It wouldn't just disappear. It's not like I'm explaining some idea or something, and I'm just talking to someone, but I can put it down and then tweak it and see how it resonates with people, and go back. I always found that fascinating. I feel like there was some core, some passion just on the written word, I guess. I'm not a native English speaker, so I was always looking for ways to improve. Eventually I just realized you just got to do it. You got to sit down and try and write as much as you can. I set a goal for myself, writing at least, in the beginning, it was 500 words, then a thousand and then 1,500 to 2,000. It was really hard. In the beginning, it was really, really draining me. It was very exhausting. I felt like I could never get even close to writing 2,000 words a day. That made a little bit of sense, actually being able to physically do it. But the funny thing is if you keep at it, and so I made a habit out of getting up in the morning, brushing my teeth, getting a cup of coffee, and sitting down for an hour and just writing. I wrote a lot of crap in those days, but what I also realized that over the course of a week, just sort of magically, by the end of that week, I would have a new draft chapter. It was a different project at the time, but for that project. I think there's something powerful about that, where you just got to believe in that process and just also be okay with that daily grind, and just sit down and do it. Whether that's just free writing, like journaling in the morning or something like that, if you can build that habit, eventually you will get better at it. Eventually, great things will happen from that.

51:00 Michael Kennedy: That's great advice. I really, really like it. All right, everyone, we're pretty much out of time for our episode. I think we're going to wrap it up. I'm going to change the questions just a little bit, the two questions I ask everyone. Keep it short, just because there's a lot of us and we are kind of getting low on time. Instead of asking you what your favorite Python editor is, I'm going to ask you what editor you used to write your book Katharine, let's start with you.

51:23 Katharine Jarmul: Vim.

51:24 Michael Kennedy: Vim, right on. Do you write in Markdown or what?

51:27 Katharine Jarmul: Yeah. There's a few different flavors that some of the publishers like to use, where some things are mixed around. Then when you go back to real Markdown, you're like, oh, wait, why isn't this working? I wrote both the books in Vim.

51:42 Michael Kennedy: Awesome. Brian?

51:43 Brian Okken: I wrote it all in Sublime. It was in Markdown. Some of the Pragmatic stuff was almost like Markdown, so I had a converter to convert Markdown to the format that they needed.

51:57 Michael Kennedy: Beautiful. Luciano?

51:58 Luciano Ramalho: I also used Sublime, and I used AsciiDoc on a recommendation by O'Reilly 'cause they have this tool chain that uses AsciiDoc. I used to be a big proponent of, with the structured texts in the past, but AsciiDoc is much better. I also find it better than Markdown because it's more expressive for book writing. For instance, I'm the kind of author that likes to write footnotes and lots of cross-references and things like that. AsciiDoc is more appropriate. But now, I'm, curiously, I'm starting this draft project that I don't want to talk about, but I'm using LaTeX because it's based on another book that's written in LaTeX. I'm not really enjoying it. AsciiDoc is my favorite option.

52:46 Michael Kennedy: That's cool. Back when I was working on my math PC, I wrote a lot of LaTeX, as well. Bruce, how about you?

52:50 Bruce Eckel: I've done all the camera-ready pages since Thinking in C++ for my books, even the ones that were published through publishers. Because it would do all the indexing and table of contents, I didn't use page layout, I used Word. But I have switched over to using Pandoc-flavored Markdown. I have a whole bunch of tool sets that I produce things from, with that. I use Sublime Text, but for the camera-ready pages, I'll probably go back to Word, just because, I mean, I'll convert from the Markdown source to Word, and then use it for layout because it still has everything in it, and a regular page layout program doesn't do that.

53:40 Michael Kennedy: Cool. Dan?

53:41 Dan Bader: I'm using two editors because I've found that switching between two different environments, it really helps me just look at the text differently. I often use different devices, too. I'll write something on my computer and then read it again by even emailing it to myself on my phone, for example. I just found that other things will jump out at me, but for the actual writing, I use a tool called Ulysses. I think it's MacOS only, but it's really great. It's like a fancy Markdown editor. I use that to do all of my writing for the newsletter and for the web. Then I do all of my editing in Sublime Text, and then publish from there, so I use these two.

54:20 Michael Kennedy: Very cool, very cool. For my Markdown, I use iA Writer, which is a Mac thing, as well, but I don't write any books. Let's go ahead and wrap this up, you guys, and I will give you each a chance for a final call to action. Say, Dan, how about you? Final call to action. People are interested, what do they do?

54:35 Dan Bader: Buy my book. No, I feel like that's too easy. But seriously, please do.

54:43 Michael Kennedy: They should buy, instead of your book, and then they want to write their own.

54:51 Dan Bader: What I would love the most, besides people buying my book. No, okay, got to stop this. I think it would be great if more people went out there and just shared their experience. Please, for everyone listening, don't feel bad about putting something out there that's not perfect. Of course, you're going to get crappy comments, and sometimes a little bit snarky feedback, but who cares? This is the first step. It can only get better from there. You'll be glad when you look back at that, a couple of months or years later, and also what this can do for your software development career. I encourage everyone just to go out there, just put a two, 300 word program example. Put it on your blog or somewhere. It will be a great experience.

55:34 Michael Kennedy: Nice. Bruce?

55:35 Bruce Eckel: And a lot of this is my experience with coauthors. I would say if you're thinking of writing a book or coauthoring a book, really do some deep soul searching, and try and figure out why you want to do it. Because often, in the process of writing the book or coauthoring the book, you'll find out what it really is. If it isn't actually in alignment with finishing the book, or if you're hoping to be famous or make a lot of money. You might want to write a book that promotes your consulting business around a certain topic. That makes sense, but know that that's what you're doing before you dive into this project because if you don't really understand it, what it is that you want, you might be thinking, oh, well, if I write this book, then I will get what I want. The book probably won't let you do that. You may not finish if it's not really in line with what you want.

56:42 Michael Kennedy: Good advice. Luciano?

56:43 Luciano Ramalho: Well, I agree that force yourself or make yourself write or produce content, maybe not in writing, but maybe slides for talks at a local meetup, and teach stuff to people. There's always people willing to learn. If you can connect, for instance, to a local hacker space or maker space or a similar place, a community place, where you can go and teach courses for free, that's going to improve a lot of your communication skills and also give you motivation to develop material. The other thing I want to say is if you are going to publish something on the internet, please don't do it on Medium or Facebook or any of those big platforms that are eating the web. Have your own site. If it's too expensive for you to have your own domain, share it with a few friends. Just put a simple tool. I love DokuWiki, for instance. It's super simple to install. I'm really happy with my two websites that I created with that. Do it, but do it on your own site, and not feeding one of those monsters.

57:49 Michael Kennedy: That's really interesting advice. I generally agree with you, for sure. Katharine?

57:53 Katharine Jarmul: I think there's been a lot of great advice shared. I think particularly if you're a junior person or you're starting to learn, let's say you're self-taught, or if you have some imposter syndrome, you come from a underrepresented group in tech, I think writing can really help reaffirm that you do actually have quite a large grasp on quite a lot of topics. I recently wrote an article, I'll share it so you can put it in the links, about how I hacked my imposter syndrome.

58:24 Michael Kennedy: That's awesome.

58:24 Katharine Jarmul: The person went through. Essentially, every day they would write some sort of problem they were having, debugging with, I believed they work in data science or machine learning. They would end up writing through their mental process, and then what they learned. I think these types of things would have been great blog posts. They show that you're learning and growing as a data scientist. This is something that you can look back on your body of work after a long period of time, whether you want to post it publicly or have it privately, and really just show, wow, I have learned so much and my grasp is so large now after so much time. I think this is a really good practice, even just to do outside of the publishing realm.

59:06 Michael Kennedy: Very nice. Brian?

59:07 Brian Okken: There's a lot of different styles of writing, and I think that's great. People think that just practice is going to make you better, but you also have to learn. Like other art forms, like drawing, take a blog post or an author that you like their writing style, and try to teach something that you know in the style of somebody you admire. Just try out different styles, and see what fits for you. I think that's a good way to start.

59:34 Michael Kennedy: That's great advice. I will leave everyone with one book recommendation that kind of ties some of this stuff together. There's this really interesting book called Hustle: The Life Changing Effects of Constant Motion. It's this book by Jesse Tevelow, who wrote this book about always seizing the moment, always just be working on something. The reason this is relevant is he is writing a book. He's writing a book, it was taking him years. Like, I need some money to survive. I'm going to try to write a book, The Opposite of a Year. He wrote a 192-page book that is pretty well done in, I think, three days, and published it. From the time he opened the editor till the time it was on Amazon was seven days. It's really inspiring, even if you don't care about authoring a book. Just, like, oh, my gosh. What can you do if you really powered through a project? It's pretty cool. People, check that out if you're inspired, you want to create something around text, I guess. All right, everyone. Thank you so much for being on the podcast and sharing your experience. This was really interesting to have you all. I'll talk to you all later.

01:00:32 Bruce Eckel: All right, bye.

01:00:34 Brian Okken: Bye.

01:00:34 Luciano Ramalho: Bye-bye.

01:00:35 Katharine Jarmul: Thanks.

01:00:36 Michael Kennedy: This has been another episode of Talk Python To Me. Our panelists have been Katharine Jarmul, Bruce Eckel, Luciano Ramalho, Dan Bader and Brian Okken. This episode has been brought to you by Linode. Linode is bulletproof hosting for whatever you're building with Python. Get four months free at talkpython.fm./linode. That's L-I-N-O-D-E. Are you or a colleague trying to learn Python? Have you tried books and videos that just left you bored by covering topics point by point? Well, check out my online course, Python Jumpstart by Building 10 Apps at talkpython.fm/course to experience a more engaging way to learn Python. And, if you're looking for something a little more advanced, try my Write Pythonic Code course at talkpython.fm/pythonic. Be sure to subscribe to the show. Open your favorite pod catcher and search for Python. We should be right at the top. You can also find the iTunes feed at /itunes, Google Play feed at /play, and direct RSS feed at /rss on talkpython.fm. This is your host, Michael Kennedy. Thanks so much for listening. I really appreciate it. Now, get out there and write some Python code.