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 Katherine Jarmul, Bruce Eccle,
Luciano Romalo, Dan Vader, and Brian Okken. This is Talk Python to Me, episode 148, recorded
January 26, 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 at 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've worked with some of these IDEs like
PyCharm, you know there's so much going on. There are so many features and those can actually
be a little bit hard to discover and use. So I created this eight-hour course to give you
a grand tour of PyCharm. And 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. So 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 Romalo, Brian Aachen, Bruce Eccle, Dan Bader, Catherine Jarmul, and me of course, Michael,
your host. And 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. It's 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? And people know you well, but we'll go around the table real quick. Start with you,
Catherine. Maybe just quickly tell people who you are and what you do day to day.
Hi, yeah. Thanks. I'm Catherine. You might know me by Kjam, and I run a data science company here in
Berlin, Germany called Kjamistem. And I mainly work on data science and machine learning, but I also have
kind of a focus on in production and deployment and systems. So I've been doing more security work
recently, but those are the things I'm passionate about. Yeah, very cool. Luciano, how about yourself?
I'm the author of Fluid Python, and I currently work for ThoughtWorks, this 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.
And I've been diving into the wonderful world of e-learning and books and those kinds of systems
to pick one for us to use. Yeah, that sounds really, really fun. Bruce, how about yourself?
So I'm Bruce Eccle. Apparently, what I do is study programming languages in hindsight,
because 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, and that as concurrency always has been deeper, whole than I
expected. And there's all kinds of interesting other possibilities. And in the meantime, I got sucked
into a project which we've been working on for almost a year now called Atomic Kotlin. So 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. Because there's plenty that do, right? 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. And now I'm
realizing I should have created a better sandbox. But oh well, hindsight.
Yeah, well, 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.
Yeah, my name is Brian Okken. I wrote Python testing with pytest. And my day job, I guess I do coast a couple podcasts. And then also, I'm a lead engineer for lead engineer slash software manager, test manager for a small team as part of a communication test system for Roden Schwartz.
Okay, excellent. And Dan, how are you?
Hey, I'm good. Thanks for inviting me back on your awesome show. And I feel like I'm in amazing company this time. So yeah, my name is Dan Bader. I recently published a book called Python Tricks, a buffet of awesome Python features. And I also do some Python consulting and then also run a couple of Python related websites, realpython.com, nerdlettering.com and my own personal website at debater.org.
So it's almost like 100% Python that I spend my time with every day.
That's really awesome. All right. Well, thanks for that, everyone. Now people kind of know where we're all coming from. So 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. So 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.
Python as well. Brian, you have pytest, which we talk about a lot on the podcast. Catherine, tell us a bit about some of your authorship.
Yeah, so I co-authored Data Wrangling with Python, which is an introduction to Python for people that perhaps are starting to want to work with data. And then I have a few O'Reilly video trainings. And I also helped create the second edition of Web Scraping with Python or Python Web Scraping, migrating into Python 3 last year.
Yeah, that's really interesting. I feel like there's a lot of people coming into Python through the data science angle. And 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. Let's say if I'm reading like web code or something.
Yes. When we start thinking about the popular data science libraries, they're often heavily complemented with either Cython, for example, if we're using NumPy.
Or, you know, Wes, creator of Pandas, he was an R person first and then wrote Pandas. So 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. And like, 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.
So it's this weird world where there's a lot of people working on libraries, and they may not be Python first. And for that reason, it has some different quirks, if you will.
Can I jump in?
Yeah, please go ahead.
I totally agree with what Karen just said. But 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, right?
And so this is kind of a fundamental shift in thinking. And I won't remember the name of the book now, but I have a really good reference, a book by a French author, but 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.
Yeah, 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 them that are notable?
Well, probably most people know me for thinking in C++ and thinking in Java. But yes, I've written a bunch more. And then there have been a number of attempts that haven't worked out.
And I seem to also do a lot of co-authoring, even though I keep saying I'm not going to do that anymore, because it can be very hard.
But yeah, I started out 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, and self-publishing was a little more challenging at the time.
You were a real rebel doing that.
A little bit, yeah. It was called Computer Interfacing with Pascal and C. And then I got involved in C++, and 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.
It's really different, yeah.
It is. I wrote several books on C++ and then kind of moved over to Java. And then I've, let's see, I co-authored a book on Flex.
I tried co-authoring one a couple of times on C#. And then Atomic Scala. And now I'm working on Atomic Kotlin.
And I keep trying to write a book on Python. And yeah, I mean, like people ask, well, are you ever going to write a book like Thinking in Java for Python?
But I would say Luciano's book would be that book. So that's not, it makes no sense for me to try and do that.
But this concurrency project is, I don't know if anybody has like looked at Julia, but that's kind of thrown me because I'm going, well, maybe the answer is not to use Python.
So anyway, it's, it's, concurrency is, it's probably been my biggest struggle in my career.
Okay.
Yeah. So thank you. So that's, there's a lot of interesting stuff happening around Python concurrency right now.
You know, the whole async and 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. So yeah, very cool.
It is, but I'm just starting to wonder if the answer isn't to kind of step outside of, of the mainstream Python world and, and connect to Python rather than try and do it in Python. I don't know yet.
I think it somewhat depends on whether it's computational or it's IO bound, like you're waiting on web services and databases.
Sure. Parallel versus async. Yeah.
Yes, exactly. So, but that sounds interesting to explore in a book. So I'm looking forward to checking that out when, when you finally wrangle that topic.
All right. So let's dig into this concept that you touched on there a little bit about co-authoring.
Co-authoring to me sounds both fun and really hard. And I guess it depends how you do it. If you write different chapters and stuff, I've certainly co-authored online courses, but no books.
So who out there has, I know Bruce, you said you've done it some, anyone else done any co-authoring or considered it and why, why not?
I have only co-authored books at this point in time.
So.
Oh, how interesting. How was your experience? So why did you go down that path?
The initial book that I wrote with Jackie Kazel, she actually was writing it on her own first and then reached out to me because, yeah, the deadline, you know, she wanted to reach deadlines and two heads are better than one sometimes for that.
And I think that if you're not really organized about exactly what is expected, I mean, it's the same thing as like, for example, if you were building a project with a friend on, 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.
So there's some element of personal connection.
You need to be really clear about, you know, 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.
And this is extremely hard to do, even with bright folks by your side.
But, yeah, I would say organization and really trying to use something as if you would almost do an issue tracker to really say, OK, are you going to be doing the introduction to generators here or should I do it in a later chapter and so forth?
Yeah, I use an organic process, which is much harder.
I guess it's not harder if it's working, but I mean, it's interesting because I see this division between when people talk about book authoring and there's the OK, you have to have a lot of structure.
Some people say you have to write from X hours to X hours every single day.
And 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.
And so I don't write when I'm not inspired.
And if I'm working with somebody, I can't manage them.
I can't like 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 co-authored most of his books.
And he had several guidelines for co-authoring.
And the first one was everybody works on every chapter.
The second, I think, was you never sign a contract until the book is done.
And 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.
And I've never been able to successfully do that.
But I feel like that is a way to keep you out of trouble.
Because the times that I've gotten into trouble is when, for example, you do a contract first.
And then the other person might or might not feel like, well, you know, 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.
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 and just do that until I'm done.
I'm one of these people who, if I get inspired, I can be like 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.
And I can see how it's a tough balance with a co-author.
Well, the one thing I wanted to point out was that I often see the people who say, oh, you have to do, you know, you have to work from 8 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.
So people who are wanting to write books think that the first way is the only way to do it.
Right, right.
Makes sense.
Brian, did you consider trying to co-author yours?
How long did your book take you to write?
Like about twice as long as I thought it would take.
But no, I worked on it for probably almost a year.
But with my lifestyle and a busy work schedule, I guess like everybody else, I don't think I could have co-authored with somebody because 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.
And she isn't a co-author, but may as well have been very much appreciated input.
And then also, you know, 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.
So even though I didn't co-author at all or consider it, I did pull an input from lots of places.
Yeah, 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?
So I didn't work with a co-author.
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 know 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, then as always, it can be really awesome, but it can
also be like your downfall where maybe one person is less committed than the other one,
and then it becomes tricky to actually ship the final product.
So yeah, didn't do it for my book, but I was very happy that I got Marietta Waiya's input
on the book and also she wrote the foreword for the book.
So that was great support for me.
Yeah, that's nice.
Luciano, have you co-authored any books?
No, I haven't.
But I liked 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.
Actually, I started actually three other books in the last 20 years that I never finished,
and Fluid Pattern was the only one that I managed to finish.
I never had a co-author 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,
and I was self-employed at the time.
So I decided to, you know, just that in this case, failure was not going to be an option.
And I did it, I wrote about part-time for about nine months.
And then my editor at O'Reilly, Megan Blanchett, who is just completely awesome,
and she's now working for Pragmatic Programmers.
I really recommend, if you want to work with a publisher,
one of the greatest benefits is having a great editor, and she is one great editor.
Anyway, Megan started talking to me that, you know,
it was likely that I wasn't going to make the deadline and so on.
The rhythm wasn't as fast as she expected.
And 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.
So I just quit my other part-time work and worked full-time on the book for the next nine months.
So in about a year and a half, I finished it.
And 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.
Yeah, I was going to say, that's a real commitment to taking that much time effectively off work.
I mean, obviously you're working, but you don't get paid very much as you complete chapters, right?
It's not until the book is done that you actually, you see the benefit.
I ate into my savings.
I can tether that.
Yeah.
That's pretty intense.
And this is a big bet, right?
Every one of you has written the book.
You know, you said nine months.
Brian said a year.
Like, that is a big project.
And you don't really get that much feedback until you ship it.
Catherine, you want to speak to that?
Like, how did you think about that and handle it?
For me, you know, both of the times that I was co-authoring 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.
And yeah, it was definitely something that was more of like a passion time.
I mean, it hasn't been said here yet, but like, don't expect, even if your book is popular, to make any decent amount of living wage off of a book.
So 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 a 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.
And for me, this worked well in terms of not having it take over my entire life.
Yeah, 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.
And 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.
So 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.
And I think you can get it for free now, but at the time you could read it on the web or you could buy a digital version and they self-published it.
And 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 a half a million dollars off of this book that we wrote and put online and sold the PDF and Mubi and stuff for.
But if we'd worked with a traditional publisher, we would have gotten like 10%, $50,000.
And the difference between half a million and $50,000 seems to me really, really significant.
But all the benefits of you, you are 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 sort of company or anyway.
So I know 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?
I wanted to write a book in the first place because I had an e-book that I self-published that was essentially a collection of blog posts and tutorials that I just put together.
Yeah, I remember that.
It sold for like five bucks a piece.
And since a lot of people were buying it, they could get the content for free anyway.
That's what made me want to pursue working with a publisher.
But I had heard all of these stories about people not making very much.
And so I did hold, after talking with a few different publishers, settled with Pragmatic because I think they're extremely fair with their revenue split.
So the, it still isn't something, I mean, 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.
But the, I would definitely go again.
I'd probably do both.
I'm 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, by our perspective.
Yeah, and it also depends on how big your audience is that you can connect with to get the book, right?
Like if, 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?
Yeah, and then also to put in perspective the 37 Signals book, I mean, they had a huge following when they were publishing that.
Signals versus noise was very large.
And so.
Yep, yep.
I've had a lot of experience with this.
And, I mean, first of all, it's important to understand how the publishing industry works.
And there's about 10% of the books published kind of break even or make some profit.
And about 1% of the books published are actual successes.
So 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.
So, and 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?
And 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.
And so the other thing that you have to look at is, you know, what kind of commitment are they going to have?
For the longest time, I wouldn't take, I wouldn't worry about the advance.
And then, you know, 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.
And some publishers will try and promote a book for a few months.
And then if it doesn't, you know, go gold, then they sort of drop it and they stop.
There's all these pitfalls that you can get into.
And you don't have control of your book anymore once you sign that contract unless you rewrite the contract, which they'll tell you that we know we don't do.
But you can.
You can always line through the contract and everything.
So if you self-publish, you are then responsible for, as people have been saying, promoting your own books.
And 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 in advance.
Right.
It's got to be basically like 10 times less good to do your self-publishing or something on that scale, right?
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?
And when you look at that and you go, well, why am I working with you if I'm going to be promoting my book?
You know, what are you bringing to the table?
And these days, if they can't promote it, then you can pretty much do all the rest of the stuff yourself.
And so unless they're wonderful promoters, you should really think seriously about what are you getting from the publisher.
Yeah, 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?
Oh, yeah, I would.
But really, for me, it's pretty clear that it was since I don't have a big following and I'm not really good at marketing,
it was important for me to author a book with a well-regarded publisher.
And I also learned a lot from them.
So 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.
Yeah, your book was really popular.
So I definitely think it put you on the map after that.
So that's really cool.
Catherine, yours was through a traditional publisher, right?
Yeah.
So I have a book with O'Reilly and a book with Pact.
And, yeah, 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.
Go ahead, Luciana.
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 already – well, I could have gone after people to do that.
But anyway, tech reviewers.
Yeah.
Dan, I'm saving you for last in this round because I know that you did self-publish yours, right?
Yeah, I went 100% with the self-published route.
What was that experience like?
Maybe speak to some of Catherine's questions.
I mean, for me, I think it worked out really well.
But I can totally see, you know, there's just different tradeoffs involved, right?
So where I was starting from – well, one reason was completely personal.
Where I – the reason I went, you know, into self-employment was because I wanted to have 100% control over the projects that I work on and sort of, you know, who I work with.
I just wanted to have that control over my life.
And so I wasn't going to hand it off, you know, to a publisher and just be like, okay, you know, now I have all these deadlines and all this stuff in my life that I really enjoyed not having.
So that was one personal reason.
And 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, like, put on a big, like, roadshow and promote your book and, you know, pay for ads and whatnot.
It's pretty much like 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.
And so I looked at my situation.
I was like, okay, well, I have this programming blog.
I have this Twitter following.
And I have a bit of an audience that I can work with here, right?
And so I decided to go the self-publishing route.
And I think it worked out pretty well.
I mean, I'm still working on that first half million or whatever.
But, you know, in the end, it was worthwhile doing it that way for sure.
Yeah, that's cool.
Maybe tell us what some of the tools you used and things like that.
Oh, yeah, in terms of just making it happen from a technical perspective.
Yeah, yeah.
Like, how did you actually build it?
I think I'll ask software developers, for anyone who's listening, I think you're in a uniquely great situation right now for self-publishing your book.
Because, I mean, all of the tools are out there.
A lot of them are open source.
And you can just, you know, compile all of the e-book formats that you're going to need or a print-ready PDF that you can hand off to,
an on-demand printer like CreateSpace.
And you can all find all of that stuff online.
It's not super easy to use.
But, you know, if you can work with Python or C compiler, you can definitely make that work.
And so that's what I did.
So I pretty much had, like, a full, like, build pipeline for my Python tricks book.
So I used a tool.
Well, first of all, I wrote everything in Markdown, which, for those of you who don't know, it's like a plain text format that typically compiles to HTML.
And it's just a little bit nicer, you know, for you to insert bold text and headlines and stuff like that.
But there's a really great tool called Pandoc.
And it's a document compiler or conversion tool.
So you can feed all kinds of formats into it, including Markdown, which is what I did.
And then on the other hand, you can output HTML.
You can output LaTeX and then compile that to a PDF.
So that was, like, 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.
And I could adjust sort of the typography and, you know, page sizes and all of that.
And the great thing is because, well, you're just feeding in, like, a bunch of plain text files into this tool.
And then what comes out in this sort of LaTeX intermediate stuff or code, it's all plain text, right?
So you can really understand how this all works and you can use other tools like, for example, a C preprocessor to actually have little macros and stuff in your input text that I can now use.
And I can generate, you know, five different versions of the book with one little build script.
So I just hit return and it will generate the Kindle file.
It will generate the print file for Amazon CreateSpace.
It will generate the e-book file and all these different formats.
And once you've got that set up, like, hopefully I'm going to be able to carry that over for my next book project.
Wow, that sounds really, really cool.
Could you also maybe tell people, like, 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.
Like, how did you actually get it out to the world?
Yeah, so for the first version, I actually used Gumroad.
And 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 buy your book and download it right away.
And that worked okay.
And initially, I released it at, you know, a really low price.
I think the first iteration of the book, it was, I don't know, it had maybe like 20 or 30 pages.
And I think I started selling it at $3.99 or $4.99 or something.
A relatively low price for a book like that.
And then just over time, as it grew, I got more serious about the delivery mechanism.
Awesome.
And now it's actually on Amazon.
And it's published on Amazon Kindle.
And it's available as print copies through the Amazon CreateSpace on-demand printing thing.
And then I'm also using a company called BookBaby.
And they're like an e-book publisher.
But they're not really like a publisher in a traditional sense.
But you just send them a file.
And they will make sure it gets on all the different e-book stores that are out there.
Like the iBook store for iPhones and iPads.
And also Amazon and Barnes & Noble.
And they're kind of like a multiplexer for that.
You know, you sent them one file and paid them $300.
And they put it everywhere.
So curious to see how that will play out.
That's really interesting.
And one other thing is, you know, Bruce really made a great point about you go to the publisher.
And they're like, how are you going to promote your book?
Right?
Like, I'm sure people are thinking, wait a minute.
That's why I'm here talking to you.
Because you have the audience and the reach.
But you managed to get your book, like, number one in Python on Amazon.
Even though you had no publisher, right?
Yeah, that was pretty crazy.
And it made the whole thing, like, very real all of a sudden.
So, yeah, that was great.
Yeah, yeah, absolutely.
The reason, you know, you can...
Like, I was able to do that because I had worked on building that following.
And building, like, I started a Python newsletter.
And started just sharing articles and sharing tips and stuff on my blog.
And on my Twitter.
And that gained enough momentum that I was able to say, look, like, I'm going to be launching this book now.
You can get it on Amazon and kind of have this...
Yeah, just have this big launch and send...
You know, make a couple of, like, thousand sales on the first day.
And that really bumped it up.
And then you can kind of ride out that wave.
But obviously, that's...
You know, you can only do that if you worked on building up that audience first.
And I can totally understand that.
You know, that takes a lot of time.
Like, that actually probably took a lot more time than writing the book itself.
And so, I think that's...
You know, it's not like a magic bullet where you can just go like, oh, you tweeted a bunch of times.
And then it'll do really well.
It'll be fine.
It's just a whole nother project that you'd be working on.
Yeah.
Tweet a lot.
Yeah.
So, 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.
Like, they got a B in literature and they didn't really enjoy essays and things like that.
So, like, maybe we'll start with you, Brian.
Like, what would you give people advice for, like, improving their technical writing or, you know, sort of getting started like that?
Blog.
Start blogging.
Just write.
I mean, the best way to get better at something is to practice.
So, do it.
I was...
I've been blogging for maybe five years or more before I started writing.
And I don't do it very consistently.
And I definitely don't do it very much now because, like, you know, two podcasts and all.
But the...
You audio blog.
Well, yeah.
And I started podcasting because I thought it would be easier than writing blog posts.
And, yeah, that's a mistake.
That's my advice is just do it and get feedback and be humble about the feedback and listen to it.
You know, I mentioned that in the entrance of the introduction to the book of 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.
Yeah.
It sounds really good.
Luciano?
Yeah.
Blogging, totally.
I just recently...
I never have been very disciplined with blogs.
So, recently, I just launched a wiki based on DocuWiki, the PHP wiki engine, which is really nice because it's simple.
And it's called Stand Up Dev.
I'm writing slowly there.
One of 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 this time-based scheme of publishing.
But I wanted to say one thing that I actually tweeted some time ago.
David M. Geary is the author of some famous Java graphics books and, more recently, an HTML5 canvas book.
And he wrote, I think, in one of his prefaces, a recipe for writing a programming book.
It also applies to blog, but it's really good.
The recipe is, code is an interesting example illustrating an idea.
And I think this is the key, right?
I call this the example-driven approach of writing.
So, you think of an interesting example that demonstrates an idea.
Then you explain it.
So, the text flows from the example.
The text is there to explain the example.
And the example is there, of course, to convey some ideas, some concepts.
And then you just repeat.
And I took this idea to heart.
And I think one of the things that I'm proud of in Flint Python is I think it has interesting examples.
Short but interesting.
I don't like books that have a lot of full-bar examples, for instance.
Flint Python has a few full-bar examples, but most of them are not full-bar examples.
And it's hard, actually, to come up with good examples.
But I think it's totally worth it to make the book interesting.
And, of course, you can do that.
Yeah, I agree.
I don't like those fake examples either.
I always feel like they're kind of a cop-out.
I think it's good to be able to build from something into the book.
So, in my case, I built on lots of presentations because I've been using Python and I've been evangelizing Python since 1998.
So, I had a lot of presentations and a lot of course material over the years that were just slides and examples.
So, a lot of that went into the book.
So, 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.
Great advice.
And you brought up the example of sort of almost a pattern for writing, a recipe for writing blogs and books.
I interviewed a Jesse Giroudavis 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.
And if you know what pattern you're aiming for, it's really much easier to write because 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.
That's nice.
Yeah, it was really, really nice.
Actually, that was episode 69 of Talk Python.
Catherine, what advice for people who maybe don't write a lot but want to?
Yeah, I mean, this is a little bit hard for me because, yeah, I had a degree in journalism right before I started doing Python.
So, trouble with writing is not a problem?
Writing kind of was a job.
Yeah, exactly.
Well, when you, so 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.
So, like this whole concept of, like, you have to be in the mood to write and this, that.
Like, 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.
So, you kind of have to produce.
So, I compare it to some days, like, you don't want to write code, but you need to write a few lines at least.
And once you write a few lines, maybe writing a few lines more will feel easier and the day moves forward.
And I think that in J school, for me, at least, there was quite a lot of very intense deadline writing.
And you would have to write whether you wanted to or not if you were going to pass that course.
So, I think this put me in the mind space of, like, okay, I'm going to sit down.
I'm going to, you know, maybe brainstorm, make a small outline, do whatever tiny little steps, putting one or two words together until I have sentences.
And then sentences turn into paragraphs and so forth.
That's really interesting.
Did you come into programming through this sort of, like, data-driven journalism side of things?
Well, I was actually supposed to be in computer science from far earlier.
So, I was, you know, writing C++ when I was in high school and I was packing 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 the, one of very, very small, small number of women in my program.
And so, then I went into statistics and after that into journalism and then found my way back to computers.
Yeah, how interesting.
And 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.
There's more and more resources on just how do we combine this data journalism and storytelling all together.
And 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.
I also started in journalism in college.
My first year, I was a journalism major and one of the best courses I had was taught by an editor from the LA Times.
And he had us compose at the typewriter.
That was his, that was the whole thing.
And we started with, you know, a set of facts and I don't know, an hour and a half.
And then he kept changing the time and reducing it, reducing it until it was like, I don't know, 15 or 20 minutes to write the story.
And it was, it was super useful.
Oh, 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.
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 got into physics and engineering and eventually computer engineering for my master's degree.
But I kept being like, I kept showing up at the college newspaper and getting involved with there.
So 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 are interested in writing.
And I'd say the, like a couple of the most important things that came out of that, I think I blogged about it.
So the details are in the, in my blog, but probably the most important things that I think people like don't get taught are 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.
And it makes your sentences shorter and more direct and more connected to the reader.
And the other thing, which was huge, someone told me this years ago, is once you think you're done with whatever it is, you know, your blog post or your chapter or whatever, is go back and read it aloud.
And by reading it aloud, and that's every single word, and it takes a long time, but things will jump out at you.
And it makes you realize that when you're reading quietly, you skip over stuff and you don't notice things.
And by reading it aloud, it forces you to pay attention to every single word and the amount of rewriting that you will do when you do that process is kind of amazing.
So most of my work now, I end up editing myself or like when I'm co-authoring the Kotlin book with a woman who's originally Russian and she speaks.
Her English is good, but she has a hard time writing.
And so 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, you know, that's just the way projects are.
They change.
They evolve.
Yeah, that's really great advice.
I like the active voice.
Definitely a fan of that style of writing.
That is the hardest thing to learn.
And even when you know what it is, you will fall back to writing in passive voice and 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.
Yeah, 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 Catherine brought up and used well, Bruce, a little bit.
You're probably familiar with 538.
They write a bunch of sort of data-driven articles in journalism.
They have a place where they have every bit of data for every article that they write all in one GitHub repository.
So if people are looking to do like data-driven writing, there's just this amazing place at github.com/538.
Words, not numbers.
Slash data.
Very, very cool out there.
So, Dan, how about you?
What are your thoughts on this?
Like, I'm not much of a writer, but I want to write a book.
How do I do that?
Man, that's a tough question.
You know, I can only speak from personal experience.
And what it came down to for me was at some point in my life, I actually considered going to, you know, getting a journalism degree, which is funny because that came up a couple of times, you know, from everyone else here in the show.
So 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 just, you know, I really enjoyed working on things like research papers and then, you know, the thesis that I wrote.
And just I actually got a kick out of the writing and just that habit of, you know, getting up in the morning, sitting down and putting something in writing and having the ability to go back and like refine it.
And it wouldn't just disappear.
Right.
Like, 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.
And I always found that fascinating.
Right.
So I feel like there was some core, like some passion just on the written word, I guess.
And I'm not a native English speaker.
So, you know, I was always looking for ways to improve.
And eventually I just realized, OK, you just got to do it.
Right.
You got to sit down and try and write as much as you can.
So I set a goal for myself writing at least in the beginning, it was 500 words and a thousand and then like 1500 to 2000.
And it was really hard.
You know, in the beginning, it was like really, really draining me.
And it was very exhausting.
And I just couldn't I felt I could never get even close to writing 2000 words a day.
That that made a little bit of sense.
And, you know, actually being able to physically do it.
But the funny thing is, if you if you keep at it.
And so, you know, 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.
And I mean, 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 for it was a different project at the time.
But, you know, for that project.
And I think there's something powerful about that where you just you know, you've got to believe in that process and just also be OK with that daily grind and just sit down and do it.
And whether that's just, you know, free writing, like journaling in the morning or something like that.
Like if you can build that habit, eventually you will get better at it.
And eventually great things will happen from that.
That's great advice.
Really, really like it.
All right, everyone.
We're pretty much out of time for our episode.
So I think we're going to wrap it up and I'm going to change the questions just a little bit.
The two questions I ask everyone and keep it short just because there's a lot of us and we are kind of getting low on time.
So instead of asking you what your favorite Python editor is, I'm going to ask you what editor used to write your book.
Catherine, let's start with you.
Them.
Right on.
And do you write in like Markdown or what?
Yeah, there's a few different flavors that some of the publishers like to use where some things are mixed around.
So then when you go back to a real Markdown, you're like, oh, wait, why isn't this working?
But yeah, I wrote both the books in them.
Oh, awesome.
Brian.
I wrote it all in Sublime and it was in Markdown.
And some of the pragmatic stuff was almost like Markdown.
So I had a converter to convert Markdown to the format that they needed.
Beautiful.
Luciano.
I also use Sublime and I used ASCII doc on a recommendation by O'Reilly because they have this tool chain that uses ASCII doc.
And I used to be a big proponent of restructured texts in the past.
But ASCII doc is much better.
And 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.
So ASCII doc 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.
And I'm not really enjoying it.
ASCII doc is my favorite option.
That's cool.
Back when I was working on my math PhD, I wrote a lot of Latex as well.
Bruce, how about you?
I've done all the camera-ready pages since Thinking and C++ for my books, even the ones that were published through publishers.
And 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.
And I have a whole bunch of tools sets that I produce things from with that.
And 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 kind of everything in it.
And a regular page layout program doesn't do that.
All right.
Cool.
Dan?
I'm using two editors because I found that switching between two different environments, it really helps me just look at the text differently.
And I often use different devices too.
So I'll write something on my computer and then, you know, read it again by emailing it to myself on my phone, for example.
And 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.
And I use that to do all of my writing for the newsletter and for the web.
And then I do all of my editing in Sublime Text and then, yeah, publish from there.
So I use these two.
Very cool.
For my Markdown, I use IA Writer, which is a Mac thing as well.
But I don't write any books.
So, all right.
So 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?
Buy my book.
No, I feel like that's too easy.
But seriously, please do.
They should buy and study your book.
And then they want to write their own.
Yeah.
No, like I feel like the.
Okay.
So what would I would love the most besides people buying my book?
No, I got to stop this.
I think it would be great if more people went out there and just shared their experience.
And, you know, please, for everyone listening, like don't feel bad about putting something out there that's not perfect.
I mean, of course, you're going to get crappy comments and sometimes a little bit snarky feedback.
But who cares?
You know, it's that this is the first step and it can only get better from there.
And you'll be glad when you look back at that, you know, a couple of months or years later and also what this can do for your software development career.
So I encourage everyone just to go out there, you know, just put like a two or three hundred word program example.
Put it on your blog or somewhere.
It will be a great experience.
Yeah.
Nice.
Bruce.
And a lot of this is my experience with co-authors.
I would say if you're thinking of writing a book or co-authoring a book, really do some deep, you know, soul searching and try and figure out why you want to do it.
Because often in the process of writing the book or co-authoring the book, you'll find out what it really is.
And if it isn't actually in alignment with finishing the book or if you're hoping to be famous or, you know, make a lot of money or and it doesn't mean that like you might want to write a book that promotes your consulting business around a certain topic.
And 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 what it is that you want, you might be thinking, oh, well, if I write this book, then I will get what I want.
And the book probably won't let you do that.
You may not finish if if it's if it's not really in line with what you want.
Yeah.
Good advice.
Luciano.
Well, I agree that force yourself or make yourself write or produce content, maybe not in writing, but like maybe slides for talks at a local meetup and teach stuff to people.
There's always people willing to learn.
So if you can connect, for instance, to a local hackerspace or makerspace or a similar place, a community place where you can go and teach courses for free, that's going to improve a lot your communication skills and also give you motivation to develop material.
And the other thing I want to say is if you're going to publish something on the internet, please don't do it on Medium or Facebook or, you know, 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, you know, and just put a simple tool.
I love DocuWiki, for instance, it's super simple to install.
And I'm really happy with my two websites that I created with that.
So do it, but do it on your own site and not, you know, feeding one of those monsters.
That's really interesting advice.
And I generally agree with you for sure.
Catherine?
I think there's been a lot of great advice shared.
I think particularly like 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 an 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.
And I recently read an article, I'll share it so you can put it in the links, about how I hacked my imposter syndrome.
That's awesome.
And the person went through and essentially every day they would write, you know, some sort of problem they were having debugging with, I believe they work in data science or machine learning.
And they would end up writing through their mental process and then what they learned.
And I think these types of things would be great blog posts.
They show that you're learning and growing as a data scientist.
And this is something that, you know, 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.
Yeah, very nice.
Brian?
There's a lot of different styles of writing, and I think that's great.
And people think that just practice is going to make you better, but you also have to learn.
So 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 and just try out different styles and see what fits for you.
I think that's a good way to start.
Yeah, that's great advice.
So I'll 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.
And it's this book by Jesse Tevilove, who wrote this book about just like always seizing the moment and always just be working on something.
And the reason this is relevant is he is writing a book.
Writing a book 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.
And so 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.
And 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 like powered through a project?
It's pretty cool.
So 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.
And I'll talk to you all later.
All right.
Bye.
Thanks, Mike.
Bye-bye.
Thanks.
This has been another episode of Talk Python to Me.
Our panelists have been Catherine Jarmul, Bruce Eccle, Luciano Romalo, Dan Bader, and Brian Okken.
And 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 podcatcher 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.
I really appreciate it.