Lightning Talks Day 2
Published November 17, 2018
This video features Andrew Pinkham, Buddy Lindsey Jr., Mark Lavin, Peter Baumgartner, Rikki Endsley and Tracy Osborn at DjangoCon US 2015 in Austin, Texas, USA.
Django Authors Panel by Mark Lavin, Andrew Pinkham, Buddy Lindsey, Peter Baumgartner, Rikki Endsley and Tracy Osborn
This will be a moderated Q&A with a panel of Django authors. Questions will be collected in advance from community suggestions. There will also be time for some questions from the audience.
The panel will include:
Andrew Pinkham - author of "Django Unleashed" Mark Lavin - co-author of "Lightweight Django" Tracy Osborn - author of "Hello Web App" Peter Baumgartner - co-author of "High Performance Django"
Help us caption & translate this video!
The panelists describe how they came to Django and turned their experience into books, screencasts, and tutorials for audiences ranging from beginners to advanced professionals. They explain their publishing workflows—from Markdown, Sphinx, AsciiDoc, LaTeX, and Leanpub to custom screen-recording and captioning tools—and how they outline, test, revise, and collaborate on material. They discuss international access, translation, licensing, copyright, pricing, and the balance between earning a living and sharing knowledge in an open-source community. They argue that paid content complements rather than replaces Django’s documentation: the official docs explain what Django does, while books and videos provide opinions, context, examples, and guidance on how to use it.
Summarised automatically from the transcript.
Automatically transcribed, so expect mistakes in names and technical terms.
Speaker 1: Okay, I'm going to do quick introductions and then I'll ask some questions and I will try to save some time at the end so that we can take some questions from you all also. So on the panel we have Mark Lavin. Am I pronouncing that right? Yeah. Okay. One of the co-authors of Lightweight Django and the technical director of Cactus Group. Andrew Pinkham , freelance software consultant and author of Django Unleashed, scheduled for publication in 2015 by Pearson. Andrew specializes in web and mobile products and is also passionate about security and distributed systems. I feel like I'm doing a game show. This is awesome. Buddy Lindsay creates Screencast on gojo. com, helping those who have the basics of Django and want to take it to the next level.
Speaker 1: Peter Baumgartner. Peter is the founder of Lincoln Loop, one of the first agencies to provide professional Django support back in twenty oh two thousand seven. Peter is the author of High Performance Django and a frequent speaker at DjangoCon and has given talks at PyCon and SALTConf as well. Tracy Osborne, the author of Hello Web App. I got my autograph copy last night. Which walks, yes, you can too. Which walks beginners through creating their first web app with Django as well as the, and she's also the founder of Wedding Lovely. Okay, so in this first part, I'm going to talk about what you all do as writing. So I'd like all of you to answer this question, this first one, and then some others, you can decide which ones you would like to answer.
Speaker 1: So uh tell us about how and uh when you got involved with Django and why don't we just start down here by you and microphone? Um, I thought you all had it already. I'm sorry, try that.
Speaker 2: Can you hear me? I guess so?
Speaker 1: Yes.
Speaker 2: Uh so I started in doing Django actually I don't remember the year, I think four years ago, um doing uh helping with uh Mozilla Developer Network. That was my first introduction into it and I really liked it. I started an ASP. net, did some Rails and then saw this Django thing and it was kind of a hybrid between the two in a few areas and I really liked it and so I just kind of stuck with it and then From there on the Gojango side, like a couple months after I started, I was like, you know, I really wish somebody was doing screencasts for these, so why don't I do them? Because no one else is. And so I started doing those. And that really took my learning up to the next level. And that's kinda it's kind of the dirty secret of Gojango is I didn't know what I was doing, but I was teaching everyone else how to do it too.
Speaker 2: So everyone was learning with me and there still are.
Speaker 3: Yeah, that's my dirty secret as well. Uh yeah, if you want to come an expert in something, write a book on it or do screencasts I I was a um friend developer and designer. I started learning Django four years ago, four or five years ago, because I wanted to launch my startup and everyone said you had to go find a co-founder. And I tried that and it was horrible, so I decided just to learn how to program and do it myself. So I've been working on startup ever since then, but as I was growing my startup and becoming a better developer I kept thinking back to those original tutorials I used and being like, oh, there could be such a better way to teach this, especially as someone who is like me with a front-end and design background. Uh so that's I decided to, as a feeling like a beginner, I decided to jump full into uh writing my own book on how I wish that Django was taught.
Speaker 4: Uh my path was uh I was a ski bum and I wanted to make more money, so I uh became a Computer technician uh and then uh started hosting email for people because nobody had good email servers and then they started asking me to build websites for them. So I started doing PHP and WordPress and um then uh people asked for more complex websites and I tried to build that stuff in PHP and WordPress and it was painful. So I uh moved to Django and uh yeah, I've been working with Django since I think the 0. 96 version uh and uh it's been good.
Speaker 5: Yeah, I started learning Python on my own. Um I wanted to use it for work. I was working in finance at the time and um never really caught on at work, but I really enjoyed what I was doing and then I wanted to build a little website for myself, so I started to learn Django. I I watched some Show Me Do screencasts back in the day and they were all on uh 9-6, uh, but 1-0 is out and bunch of weird errors trying to wa watch the screencast. Um and yeah, eventually I decided to move out of finance and I thought Man, I really like building things with Django or what I've been learning. Maybe someone will pay me to do this. And turns out like
Speaker 5: by a stroke of complete luck I ended up at Cactus Group and Um just as snowballed from there. Um yeah.
Speaker 6: Thanks. Uh I started working on in the startup scene in 2011, and after a couple jobs where I was working in PHP or Rails or JavaScript, I discovered that I really, really didn't like any of those tools and ended up on a project with Python and Django and said, this is it. I I don't want to deal with those those other tools for any of the other websites and just kind of stuck with it.
Speaker 1: All right, thank you. Good answers. Um, okay, so Uh one thing that we have to be mindful, um well and all the publications I've worked on actually have all been for international audiences. And so um In opensource dot com for example we have uh we have a huge editorial well lack of focus, I guess. If anything under open source will fit in our um in our site. So when you're thinking about your audience and who you wrote for, I'm curious, um, you know, what are you picturing as your audience? Is it um primarily uh a North American? Are you um concerned about having your works translated? Is are you picturing this being used uh at a university level or um in a professional setting or is this something for somebody who's self-taught and doing this at home for fun? So um tell us a little bit about the audience you have in mind for how you're creating content.
Speaker 1: I'll let you all pick who decides since the
Speaker 3: As a self-publisher, because I self-publish, I don't have a publisher. I have to think about all those things myself. Um and a lot of it has to be like I kind of like I trying to I try to exp uh make it as accessible as possible. Um I'm selling on three different platforms, which is kind of weird for a lot of people who do self-publishing because most people choose either a pro a thing like Gumroad where you're owning uh the sales and payment yourself versus Amazon, which is kind of universal. Um but I kinda did Amazon because it is it does sell internationally really well Uh but I'm running into a problem. I kind of try to maximize it as much as possible. Uh but I'm working on a second book. In the second book I'm using Stripe, and Stripe isn't Exist internationally, which has been an issue, 'cause I talked to some people in Budapest and they're like, Well we can't use Stripe, so that's gonna be useless.
Speaker 3: Um So the long answer is that personally I tried to like make it so anyone, for me, because I'm a working beginner audience, anyone who's totally new can use my book. And beginners, you will use multiple tutorials, and I understand that. But I have been running into some internationalization problems. Don't have an answer for it just yet though.
Speaker 4: My audience would be probably professionals or people who want to be professionals using it and are kind of in the trenches. I would love to have it internationalized, but I haven't had any requests for it yet, and it seems like a monumental task as a self-publisher. So, you know, I'm I'm in the same boat that we sell on, you know, Gumroad and Amazon and and uh a couple other platforms. So we do get some international sales. I uh unfortunately I think English right now is sort of the de facto technical language, um which I uh you I'm sure it isolates some people, but uh Right now it would I think it would just be too big of an undertaking to try to translate.
Speaker 5: I think there was some effort to translate our book, but that wasn't really a concern we had when we were writing it. Um Our audience, uh Julie and I, we wanted to address questions that we felt were coming from the community. Ours is definitely that like intermediate to advance. uh user of person, uh people that's starting to feel constrained by the framework and we wanted to show them those constraints only exist in their mind and that like there are ways to use Django in you might not have done before or n have seen solid examples on. Uh Julia, my co-author, would probably uh be mad at me for saying this, but uh
Speaker 5: I wrote the book for the haters. I wrote I wrote the book for the people that hate Django. That want to use Flask instead, that want to use Node instead, I wrote it for them.
Speaker 6: Do you hear from them often?
Speaker 5: Um it's for them.
Speaker 6: It it's for them. Um I spent a lot of time thinking uh about the difficulty level and the the sort of um how much knowledge people had when they were going to be reading my book. And I tried to write for two audiences. I tried to write for an audience of people who didn't know how websites worked, didn't understand how web frameworks worked, and needed that extra knowledge before they could come in and look at the Django documentation and the web API. Because An API is great as long as you understand the problem that it's you're using, the problem that you need to solve using that API, and then how all that API fits together. So that was the first audience. And the second audience in the second two-thirds of the book were people who were familiar with the problem and the solution and who wanted an example of
Speaker 6: some of the lesser-known parts of the Django framework. I'm lucky because I uh wrote this with Pearson, and Pearson handles international uh um internationalization rather. So it was not something I had to actively think about because if they believe there is a market, and unfortunately I have no say in that, please email them directly if you think there is. they will then go ahead and translate it for that market. So it was not not a real concern of mine.
Speaker 1: I'm going to tweak the question for you a bit, buddy. Okay, so uh I mine 's two part for you. So who what audience did you have in mind? And then are you able to get demographics since you're you're doing video, are you able to see who's actually watching the video? And I'd be curious if you had any surprises there or you know Who's uh watching your videos?
Speaker 2: Yeah, so to to jump back to the original original question, my first thought was Um you're supposed to take all that into mind? I mean that was a lot. I had never thought about almost any of that. Like, oh wow. Um so I I first started Go Django for me as an opportunity for me to learn and let other people know what uh what I've learned. And From there it's kind of evolved. I have a kind of a more dynamic situation than books because as I produce more content, I get more audience and it varies. And so uh uh as that's happened it it's changed. I've watched, you know, in f with uh Google Analytics
Speaker 2: the demographic information and and it's very normal tech industry, twenty to forty male, eighty percent uh male, twenty percent women. And so like It is the exact representation of what the tech industry is. Um so but in all honesty, I haven't really kind of focused much on that. My my actual target is more skill level is where I try to produce um put it at at the beginner mediate to intermediate. So You've done the polls tutorial, you've maybe done the the PyLadies tutorial, the Hello Web app, and you're ready to go that one next step. That's kind of where I try to target. uh what I'm doing and recently I've started um backfilling um
Speaker 2: with uh subtitles and or closed captioning. Um so I found a service that can do that that's not prohibitively expensive So I can offer um uh the tutorials to like hearing impaired. Um that also gets to the next level if somebody wants to come in and translate. They now have timings to more easily translate it. Um I just I can't afford to translate anything. But there's opportunity there for translation to international languages. Plus it actually helps. I've had a couple people email me and say, hey, I would like closed captioning because I can read English really well and I can't hear I can't listen very fast, but I can follow along with what you're doing and read at the same time So I I get the benefits of there. So as time has progressed, I've gone like, you know, who's actually watching
Speaker 2: and how can I help, you know, international specifically. And again, hearing impaired as well. So
Speaker 1: thank you. Can you hand it down to Peter and Okay, so the next question is about the tools you use for writing, particularly open source tools. What do you use for writing and recording video text editors or If you're doing any of your own layout, you know, or any of your self-publishing or whatever, we'd be interested to hear what tools that you like or ones that you've tried that you don't like that or and why you didn't like them.
Speaker 4: Uh yeah, I I used Sphinx and I didn't like it. It was uh it it was pretty painful, but honestly I don't really know of um much better option. Uh Some of the things that Sphinx does well, like footnotes and uh code samples and all this stuff, uh really came in handy. And when I started to research other options, I always kind of found issues that that they didn't cover So yeah, and then uh layout is uh using LaTeX, which um is I don't like even more. Uh and I had the bright idea, I you know, I was like I don't want to deal with this. I had somebody kind of do a style guide and then I pitched it over to this guy who is a LaTeX expert
Speaker 4: and um to to do all the typesetting and he got like 80% of the way done and sort of disappeared. So I had to figure it out kind of last minute, uh under the gun on a deadline. uh which was mostly like googling and pasting in things and finding out what didn't work and then googling again and pasting something else in. So It's really horrible. I did not enjoy that part of the process. But in the end, like you know, we I we got something that's pretty close to what we wanted it to look like. So yeah.
Speaker 3: I uh write in Markdown and I'm using right now Lean Pub platform because HelloWeb App is also published through Lean Pub Lean Pub and by writing in Markdown using, yeah. I s save on Dropbox. I use MacVim personally just to do my writing. So it gives me a little bit of highlighting and stuff. Uh but Lean Pub will generate the mobile the movie files and EPUB files for me. So I skipped the I heard a lot of horror stories, well, LaTeX or LaTeX, whatever it is. I heard a lot of horror stories about it. And I was like, I do not want to do that. And luckily for my book, all this all my code stuff is actually really um simple So in Markdown, LeanPub, because they do technical books, translates it into the digital versions for me, and I can sell those digital versions through Amazon. And then um I have a background design, so then I'm also able to import Markdown into InDesign and I could do the formatting myself, but I do everything in Markdown.
Speaker 5: Uh we actually didn't have to make that choice, thankfully. Uh uh That's one of the joys of not self-publishing. We were working with a publisher, they had a lot of documentation. We used ASCII doc uh which is very similar to restructured text except it compiles to docbook XML rather than HTML and um very similar format It's really nice. I like ASCII Doc and I would use it again, though I have no idea how to compile it. That's all done by their platform. We would just clone to git repo, we put our ASCII doc files in, we push them up, and then they had a platform we press a button and they'd build a PDF and put it on S3 and we download it. It was It was magic.
Speaker 5: So um I don't know how hard that process of converting ASCII doc into uh PDF or Mobi formats actually is, uh but I like the process of just writing in an ASCII doc, that was really easy.
Speaker 6: Um so Pearson doesn't have that. They probably should should be talking to O'Reilly about that. Because there was no documentation. I was sort of told, go and do whatever you want. The problem is that I wrote an a thousand -page book, and that's a lot of code. And I anytime I tweaked it or changed it based on feedback, I didn't want to have to go in and copy the code back in every single time. So I started writing in Markdown and wrote a script that would take the code from GitHub and put it in the Markdown. Except Markdown doesn't have references or sort of any intelligent formatting. So then I extended the markdown using my own scripts, made it compatible with Pandoc markdown, compile it into LaTeX, and then compile the LaTeX.
Speaker 6: I'm sorry I've horrified you. And I tried to do the ASCII Doc thing. I really did. Um and it was simply too rigid given given the what I was trying to do with it. So um I'm so sorry.
Speaker 2: You are a software developer. So my my tool chain is uh When I first started, I used a $5 screen recording app on the App Store, absolutely hated it, but it got the job done. And then I Ryan Bates had some conversion scripts on his repo for Railscast, so I copied and pasted those onto my computer And that's how I got started now. It's a little more sophisticated. I use ISHOUHD for screen screen recording I use Audacity for audio uh audio recording and then I mix the two together in Final Cut Pro. I have a couple of uh custom scripts that do um my post-production stuff and then uh
Speaker 2: I have uh more custom scripts that actually upload everything and uh set all the show notes and and also send it off to get the uh the transcripts and uh closed captioning done as well automatically So a lot of custom stuff that I've done.
Speaker 1: Thank you. We pass it down to Mark and we'll have him start with the next question. Okay, so when I when I write, if it's something I'm excited about writing and and I have a vision for it, it's all written in my head before I start writing Um and if it's something I need to write or have to write, um it's where you'll see me doing an outline and all of that. And so I'm curious about what your processes are and how you decided to wr, you know, the start writing or recording. Do you um like recording do you have a script in mind first or do you you know, uh wing it and then with writing the book, did you do an outline? Uh I'd like to hear how your how you do that.
Speaker 5: We had an outline as part of the pitch, you know, to to say this is the book that we want to write and that was the the rough guide of of what the chapters would be and what the subject matter would be. And then from there, a lot of it stemmed from the thing that we wanted to create, that we wanted to walk the user through the creation of a project. And so we'd start by building the project from nothing and write it and test it and play with it. And then we would go through it and build it all again from scratch. Um and see if we built it the same way the second time. and then explain how we built it step by step.
Speaker 5: That was sort of the process. And working together, we also would sort of swap out who would do the first draft of a chapter and um so I would build out chapter one and Julia would build out a different chapter and then we would swap and do the second pass and I write I write really fast and terrible and so like I would just produce just loads and loads of pages of garbage and then like Julia would refine it and um That's that was our process. So she did the garbage collection.
Speaker 5: Like uh I mean it's It's nice to have a co-author. You had a co-author as well, right? It's nice to have another set of eyes. Um and that was that was definitely part of my process is sort of knowing someone's got my back before it went to the editor or a technical reviewer like someone had my back before it got to that point Um
Speaker 6: I I had the I had actually started teaching this as a class and actually had intended for a lot of this material to to actually be screencasts first. Um and it was at sort of a a test viewing of the screencast that someone said, you know, this would This would be much better as a book. And so I started off with actually a a whole bunch of uh slides and uh a small repo uh and that I was used to going through and explaining. And so when I when I was structuring the book, it was very much from the standpoint of a class. It turns out I had to I had to seriously expand on that once we expanded on the book. The book was originally intended just to be this 300-page thing, and then my editor at PyCon 2014 said you know, we really like what you've got. Can you give us more of it? And I made the mistake of saying
Speaker 6: yes. Um so at that point I expanded the repo and it became a a question of sort of scanning through through multiple times where I would build the code out and then write about it and see what was working, what wasn't working, send it off to um people and say, How do you feel about these explanations? And then scan back through the code as slowly, slowly build it out. And that's sort of how I tackled the problem. For
Speaker 4: for me, uh the book actually started as uh kind of like a wrap-up letter for a consulting engagement I had uh and like a recomm list of recommendations for uh this client we were working with. And I was like, I could write more on this and this would probably be helpful for other people. And like the first five or ten thousand words like happened really fast. I was like, oh, this is gonna be no problem. And then uh And then so I from there I kind of like, you know, I wrote out a bunch of stuff that was all kind of stream of consciousness, and then it was outlining like, okay, where are the gaps here? What am I missing? And then my co-author who had some knowledge Yan Malay um he uh was able to fill in some of the gaps where his expertise was you know considerably more than mine
Speaker 4: And then it was sort of, yeah, just kind of combing over that again and again and refining it and filling in gaps and you know uh reading and seeing what we missed and all that. I'll go back to Twitter. Okay.
Speaker 2: So uh basically take their process and that's kind of what I do. Um a mix of all of that. But for idea generation Um that's I think a little different for me. I I take what I call the long-term blogging approach. Um since I try to release three videos a month, um I have to think very long term and so I like to Uh get f get ideas that can last two months or a month or at least two weeks and then I'll spend um ten to thirty hours coding out over and over several times to make sure I could make a video on it and and basically doing everything that everyone else talked about. But I idea generation comes from what do I ro what do I want to learn? What's interesting to me?
Speaker 2: What has someone asked for? I do a lot of that. And uh also what do I see on like Reddit or Stack Overflow that people are asking about consistently. Um and then what is somebody complaining to me about? Uh so stuff like this. So that's kind of where I start getting ideas for mine. Uh
Speaker 3: the process of outlining for my two books, the this one and the new one that's being funded on Kickstarter right now. Um this book uh is kind of I started out with the idea of like what kind of what's the basic project, the MVP project would that someone want to build. And then I worked backwards to build chapters in terms of those steps because this book is very much go from here to here in one um one flow. Uh and that was all done in Google Docs, because I like Google Docs because it's pretty easy to share. So I was able to take the flow, I just listed out in bullet points, um, each chapter, and then I had notes on each chapter, and I kind of sent to a few people to make sure that I wasn't missing any bits Uh but the book number two, the chapters are individual, they're individual exercises. Um and so that's also on Google Docs. And I like just because it's really easy to share. Uh
Speaker 3: In terms of idea generation there, uh I guess I'm still finalizing the last chapters of whatnot, but a lot of it's just again in kind of what I wished what this book existed. Um so the second book, which is intermediate concepts, uh has all these like intermediate exercises I have had to taught myself there wasn't any um documentation on online, like one of the chapters when we saw us in Bootstrap, and I knew that something that kind of doesn't exist right now. So knowing that there was a hole there, I was able to throw a chapter in, and that's kind of how I built up the second book.
Speaker 1: Okay, let's um start with Andrew on this one. Um and um you might not have an answer for this andrew since um as you said you have a publisher and so I'm curious about um licensing. How do you pick how to license your material or is it chosen for you and um if you did get to pick um what made you decide on the license that you decided on?
Speaker 6: So I did I did not get to pick and it was not a question I realized I could ask. Um I got into a really interesting conversation with Harry Percival who published his all of his material online under a Creative Common license. I had been led to believe when I signed the contract with Pearson that I had no say in the matter, and it later turns out that they do allow for some flexibility and O'Reilly allows for some some flexibility. But so when I signed the contract, I was told this is this is the only contract you will sign. It is non-negotiable. And that was that was it.
Speaker 1: So if if you got to pick, do you have one in i a favorite in mind? Um
Speaker 6: I probably would look at the Creative Commons options, honestly. at DjangoCon 2013 with the dual purpose of trying to learn more Django, but also to meet people in the community. I at that point had not signed a contract with Pearson, but had begun the conversation with them and I wasn't going to write a book For uh a group of people that I didn't like. Um so I showed up and I loved the community and I said, yes, I will write this book. And so given that I wrote a book for the community It seems really silly not to just give a lot of that away. On the other hand, I'd also like to make money off of this, so I'm not sure that's the right answer. So I honestly haven't thought a whole lot about it.
Speaker 2: I I'm in the same boat. Um I really I mean I gotta have the ultimate choice considering I own all of it, but I never really thought about it and haven't because you know I I just want to create content for people and it's available on my site. A bunch of it's free, a bunch of it's not. Um and so yeah, and I want to make money. So I I might think about it somewhere, but at the moment I just retain the full copyright and I just go about my day on that, just creating content. That's really what I want to do
Speaker 3: Yeah, it's a little awkward for me being a beginner tutorial. Um, because that there's an excellent Django Girls tutorial, and I encourage people to do both, but they're free and I'm not, and that's makes me feel awkward sometimes. I feel like I should release it for free Um but I'm trying to make this into my my day job and that would be so awesome if I was doing this in my day job. And ergo I need to charge at some point. Um so I do retain copyright and I try to release some things for free And it's made some conversations awkward, but everyone's been super supportive that I haven't I've been charging for beginner content.
Speaker 4: Yeah, uh our book is you know copyright, all rights reserved. Um we're in the same boat. I mean it's a tremendous amount of work to put a book out there. Uh I wouldn't do it uh if there weren't some uh you know other upside. Uh And we do like we post on our blog and when I'm interested in a topic, I'll write about it on our blog. Honestly, there's nothing in this book and my guess is, you know uh probably most of the other people's that you couldn't find if you dug enough online. Um the the point of the book is it's kind of you have it all in one place and instead of spending weeks digging around you have it You know, all right there. So um yeah, it's it's it is a little strange in an open source environment to release, you know, copyrighted pay for
Speaker 4: material. But I think if it weren't for that, it just wouldn't get done. Uh you you wouldn't have high quality books uh available if if they were all kind of free and open source.
Speaker 5: I just have a small thing to add and and this wasn't really a big discussion that we had though I did talk to Harry as well. about the the process of him open sourcing all of his content. And I think that's um I think that's great. um that it's available for free. But I feel like even though it's available for free and it is available on GitHub, it's not truly open source. Like people aren't collaborating on this book together. This book is our vision and like we're not gonna accept pull requests on like unless it's a typo like you're not gonna change the book for us. Um so I don't know.
Speaker 5: I I guess we can make it open like so that people could download it and try to build it themselves, though it would never happen. Like it would never work But it's not really open source in that sense.
Speaker 3: I just remember there's actually a chapter that's my installation instructions there on GitHub. And I originally put it up there because I knew that installation stuff would change fast and I didn't want my book to go out of um to uh be old information too fast. And I put it on GitHub and I was talking about the book and people actually have um I mean little things like finding typos. Someone gave me a whole thing for how to install on Linux, like some things I hadn't filled out. I have a page on there with extra resources. And it was really cool seeing people come in and uh help out with this, because I put the information on this repository. It was kind of cool. So it's like a tiny little open source area that people have helped me out with.
Speaker 1: Um well I that wasn't a trick question because I've worked under many licenses with the different publications I worked on and um and they d uh and I was honestly curious because people have different um things that they found work for them, you know, or different re motivations for writing. And I remember um at Linux Pro, which is not an inexpensive magazine, it's about a hundred dollars a year very low ad count though and we counted on subscribers and m you know, m a occasionally people would say information wants to be free and my response was, Well, I don't work for free, you know? And I expect to get paid for writing and editing and so someone's gonna have to pay me, you know, and so But there are many different models that work for different people, obviously. So we we'll have about 10 minutes. I have more questions I can ask, but I want to make sure that everyone here gets a chance. So let's uh take audience questions
Speaker 1: And there's a mic over here. And then if we have time, I will ask more at the end. So I don't think we'll have time for my questions, though.
Speaker 7: Long time ago I wrote a Drupal book. Um so from that experience I ask, how did you maintain your sense of wellness while doing the work? I mean that's a serious question because you're kind of working all the time. How do you maintain health, balance?
Speaker 5: This question is predicated on the fact that we did. Yeah, no, I mean again I don't know how y'all that don't have a co-author did it by yourself. It's insane. Uh I did it by being carried by Julia at times and I carried Julia when she needed me. Um it was not I'm not good at work life balance. I work like all the time and then I work on the book and then I go run and then I sleep and that's you know everything that I do and every single day like um But I don't know. It's like we did it for the challenge. Um
Speaker 5: I yeah, I would say how did we find how did I find a balance? I didn't find a balance
Speaker 3: I have a startup, so when I get burnt out on my startup, I I go to writing. And when I get burnt out on writing, I'll go back to my startup. And I'm lucky to have that flexibility to do that with my hours. I end up working 24-7 on one or the other. But it it does help me to context switch and it allowed me to work on this without like feeling like it was like a terrible, terrible job.
Speaker 2: I set very strict deadlines um from Uh basically when I leave in the morning at at 6 a. m. and basically till I get home around uh uh four, like that's my full-time job and I don't do my full-time job outside of that. And then I do family stuff until about six and then from six to nine, I uh three days a week, I do Go Django stuff. And so I have to make sure my process is extremely streamlined to make sure I fit it in there. And then I'll do Saturday morning before noon sometimes uh to get stuff in. I just and my wife reminds me if I start deviating out of that. We should probably go to the next session.
Speaker 8: So I just have a question about kind of the process. So I did a three-hour tutorial here at DjangoCon and I felt so overwhelmed. And that's, you know, one tenth of the amount of content. And I found when I would go in to try and do something, I would just kind of get lost in all that there was. And it's like, oh, there's a reference here that goes there. How do you kind of think about like taking a small amount of work. It's like I'm just gonna work on this chapter or like how do you like deal with the breadth of information that you have and actually just focus on where you need to be working Do you have that? Um
Speaker 6: divide and conquer is sort of the short answer. No, seriously. Um I because I was so focused on demonstrating code I made sure that uh all of the the code was heavily annotated in GitHub and all of the I knew which commit was in which chapter. Any commands that I had run at that point were in the GitHub notes. And I was I was writing notes as I went and that way anytime I was writing about that I could simply look at the list of commits, see which ones were relevant to that chapter, and then begin looking through the notes that I had written to myself while I was building it and then add two notes that I had written to myself on the side in a text editor and try and pick that up. But there is uh substantial amount of information.
Speaker 5: Um I uh yeah just to add, I think you really have to know your audience and focus on your audience. Uh your book can't be everything to everyone or your content can't be everything to everyone, so it's constantly like, can I cut this? Like It you know, your tutorial was about writing documentation. Like, do they really need to know this? Do they really care about this? You know, having a a focus, just saying like This can be covered by another book. Like we didn't really cover testing, which is not great, but there's other great books about testing. And our book can be about what it's about and then go buy Harry's book instead
Speaker 1: Okay, we have about five more minutes. So and I think everybody would probably be happy to talk um in the hallway track around breaks later. So let's go and let Jacob ask a question.
Speaker 8: Yay. Uh first off, thanks y'all so much. This has been really fantastic. Um so uh many years ago I had a uh a publisher, someone who worked with a publisher tell me that they didn't want to do Django books because um the the the the quality of the documentation meant that there was no market for paid Django content. And I think you've all like proven that wrong. Um but I'm interested in what your relationship is with the documentation. I mean is the is the existence of all this great content a sign that the doc quality has slipped? Are we covering different areas? Where can you talk a little bit about how you see yourself versus what's in the official docs?
Speaker 4: For me, um the the Django docs uh kind of need to be non-opinionated. Um you know they shouldn't be having favorites on and our book is a lot about the tooling that goes around Django. So um I felt like there was an opportunity to say, you know, sure there's other stuff out there, but this is probably what you should be using or this is a this is a good starting point. Um I think uh there are some easy kind of performance gotchas in Django that I don't know how well they're they're documented maybe. Um uh but I don't know if that's Django's job either. You know that The ORM can hide the fact that you're doing a bazillion queries and like that might be a problem or you're counting a table with millions of rows.
Speaker 4: Um So yeah, I I I I think the Django documentation is great, and I think most of the content in in my book wouldn't belong in the Django documentation.
Speaker 3: I tried using polls way back in the day and it didn't work. Uh and I ended up teaching myself Django using Kenneth Love's Getting to Hero Django video series. But yes, it was because of Django polls that I wrote this.
Speaker 2: My real quick comment is uh the Django docs cover what to do, we cover how to do it.
Speaker 1: We have time for another question.
Speaker 8: Thank you for this nice panel. My question is what tools do you recommend for your viewers in case of screencasts and readers in case of books for your students and what is their uh text editors versus IDs trade-off for novice programmers from your perspective
Speaker 5: I don't think we have a lot of opinions about that. Uh I like dead tree copies. I like physical books. I also like And I was talking with someone else about this before. I I like not being able to copy and paste the code. I like having to type it out myself. I think there's something very That's part of my learning process. I don't know if that's true of everyone else. So I like having print editions and having to type and understand the code. Regardless of what the editor is, not being able to copy and paste is like a that's a feature to me.
Speaker 6: I don't I don't have a real opinion. Um so
Speaker 2: I I purposely don't have full projects on GitHub like other people do because of exactly that I have just enough code in my show notes to show you exactly what I typed. Most of the time you can't copy and paste and make it work. I uh I purposely did that because I'm I'm that way. I I uh I have to do it myself for me to learn. And often I it when I was when I experimented with giving full examples, people would email me asking how stuff worked without watching the videos. And so it's like Uh uh I explained it in this five-minute video that I spent 30 hours producing. Um why do I need to spend the next thirty minutes talking to you and the re-explaining it? So
Speaker 1: Okay. Al, did you have a quick question? Because we have about one minute.
Speaker 6: Yeah, I'm sure everyone's heard of Khan Academy and Code Academy. and just using technology as a way of teaching new things, especially programming languages and Django. Do you feel that books as a medium have a much longer future for for learning different technologies or are they going to eventually be uh surpassed by screencasts or even interactive tutorials? or or something else even.
Speaker 3: And so if you release a book and then Django changes, uh then things go out of date. So that's the problem with with say books over say tutorials and whatnot, it's harder to update.
Speaker 6: But you could you could make the argument that even if you're putting together screencasts, you're still locked into a version. I've had actually uh so I I teach Django classes, um, startups, corporate, and I've had a lot of uh people in in startups who say, oh, well I learned Python in Code Academy. And Code Academy uh has a specific limitation where it puts all the code in a little box and then it doesn't let you out of that box. And so one of the things about a lot of the the I'm not saying this is a limitation of the medium, but one of the things that you see on almost all of these sites is that they they've locked you in, and that turns out to be a real problem Whereas I don't think books or other mediums allow you to do that, right?
Speaker 6: That they give you all of the freedom without putting you in this box. And they In some ways it's less great because they force you to go out and figure out the install and they they put this overhead right away. Um sorry
Speaker 1: So that's a great way to end though because long live print is the takeaway there. Thank you all.
The panelists target different groups: beginners building their first web app, intermediate users who want to go further, professionals, and developers frustrated with Django’s alternatives. They also discuss international readers, translation, accessibility, and the difficulty of supporting those audiences as self-publishers.
Discussed at 6:51The main strategy is to divide the work into focused chapters and keep only material relevant to the intended audience. Detailed code annotations, Git commits, notes, and links to other books help readers and authors handle the breadth without trying to cover everything in one resource.
Discussed at 36:11The official documentation needs to remain broadly useful and non-opinionated, while books can provide opinions, recommended tools, practical workflows, and performance advice. One panelist summarizes the distinction as: the Django docs explain what to do, while books explain how to do it.
Discussed at 38:26The panelists do not prescribe a specific editor or IDE. They emphasize learning by typing and understanding the code rather than relying on copy-and-paste, so some authors intentionally provide only enough code to accompany an explanation instead of complete ready-to-run projects.
Discussed at 40:05Note: We understand that names change, people change, and bodies change. We respect each individual's journey and privacy. If you have any concerns about a video or need us to remove content, please don't hesitate to contact us. We will handle your request with care and promptly address any issues.
Published November 17, 2018
Published November 3, 2017
Published September 8, 2017
Published September 8, 2017
Published September 7, 2017
Published November 3, 2017
Published September 19, 2014
Published September 12, 2014
Published October 23, 2025
Published November 3, 2022
Published October 25, 2019
Published November 3, 2017
Published November 3, 2017
Published September 7, 2017
Published August 10, 2016
Published July 15, 2026
Published July 15, 2026
Published July 15, 2026
Published July 15, 2026
Published July 15, 2026
Published July 14, 2026