Do you have a blog? How many articles have you written for it? Do you find it hard to keep writing
or hard to get started doing technical writing? Well, we might be able to help out with that this
week. You're probably aware that blogging is one of the key ways to establish yourself as a thought
leader in the industry. You'll make more connections, open more opportunities, and likely find your work
more rewarding if you share your experiences and expertise through blogging. But it can be
challenging to keep writing or to find the time. That's why I asked A. Jesse Giroudavis from MongoDB
to share his thoughts on writing an excellent programming blog. You'll even learn about Jesse's
five design patterns for blogging that will help you break writer's block. This is Talk Python to Me,
episode 69, recorded Tuesday, July 19th, 2016.
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 Talk Python.
This episode is brought to you by SnapCI and Intel. Thank them both for supporting the show on
Twitter, where they're at snap underscore CI and at Intel software.
Hey, everyone. Before we get to the main interview, I actually have a special little segment for you and a
pretty awesome announcement. I'm here with Matt McKay. Remember him from the Full Stack Guide to
Deployment episode back in episode 26. So Matt and I have a pretty awesome announcement. Matt,
why don't you tell everybody what we're up to?
Sure, Michael. Thanks for having me on. So we're launching a Python for Entrepreneurs co-authored,
co-taught course on Kickstarter.
Yeah, this is a course I've been dreaming of writing for a really long time. So many courses teach you how to build web apps.
There's some courses that will teach you how to build online businesses around it, you know, processing credit cards and things like that, in addition to the core web technology.
This Python for Entrepreneurs course, it's supposed to teach you both. So you can go from zero to online functioning business, taking credit cards with real users right away.
So the overriding goal that we're working from really is to dramatically shorten the time from idea to minimal viable product to running a production and accepting money, shorten that time from months, maybe even a year down to a month or a couple of weeks in some cases.
So Matt, tell us, who did you have in mind when you were working on your part of the course?
Yeah, so I think the ideal student is someone who knows a little bit about programming, maybe is just getting just trying to hack on some programming themselves for a purpose, or someone who has been programming for a long time, but maybe doesn't have the full range of technologies that they would need to build an online business.
So really, that's the target audience for this, and someone who wants to build a non-trivial product.
So I think, for example, if you want to break out of your mold of your regular company job and launch, you know, an Airbnb competitor for your local market, you could use this course and it would be a good place to start.
Of course, that would be a huge challenge to launch an Airbnb competitor, but you have a general idea of who we have in mind.
You know, a lot of people who listen to the show, they, of course, know Python, but in case your Python's a little sketchy and not ready to jump straight into web development, on the Kickstarter, we set up a Python Foundation Plus Entrepreneur Reward.
And that basically gives you access to my Python Jumpstart course as well as an entrepreneur course at almost just the price for the one.
So that's really awesome.
And everybody, go and check this out at talkpython.fm/launch.
We really hope you love this class.
We hope you back the Kickstarter and we hope this makes a really big difference in the business that you've been dreaming of launching.
Matt, thanks for being here.
Thanks, Michael.
Yeah, I'm excited to see where this goes.
All right, let's get on to the interview with Jesse.
I'm not going to ask you how you got into programming in Python because I already asked you that.
You can start from, you've been up to the last year.
That sounds great.
Last year when we talked, I had just begun to transition from being a full-time Python programmer to being mainly a full-time C++.
programmer.
And that was a bumpy ride.
But we've kind of achieved stable flight now where I feel basically competent in C.
And the project that I'm leading, the MongoDB C driver, which is what C application developers use to talk to MongoDB.
The project has now gone through a number of releases with me and we've fixed a ton of bugs and it's pretty stable.
And this summer I have a colleague and two interns working with me on it.
And that's freed me up to not quite have my head down in C code as much as I did over the last year.
Give me sort of a contrasting experience.
You've been doing Python for a long time.
You're deeply involved in the community.
And then you go over and do C code.
And I'm sure you knew C before.
But what was it like to sort of come back to C?
Well, I knew enough C to be able to read and write the syntax of the language.
But after 10 plus years as a professional Python programmer, I knew the difference between knowing a language versus actually being a professional programmer in it.
And so I knew I knew the C language, but I also knew that I wasn't a professional C programmer.
And so I would have to learn how to use all of the tooling like Valgrind and GDB, how to maintain API and ABI compatibility, how to manage an open source project, how to package a C shared library for Linux in the proper way, both for Red Hat and Debian.
And I knew I didn't know all of that.
And I knew that that was going to be the bulk of professional C programming.
And therefore, that's most of what I've been spending the last year doing things like being able to figure out from a core dump what happened on a customer's machine or figuring out how to give customers a way out of a poorly chosen API while at the same time not breaking backwards.
Yeah.
For those who are already using it.
Yeah, that's a big challenge if you're supporting customers and they say, we think the driver crashed or something we did in the driver crashed our app.
Because if that happens in Python or Ruby or .NET, you get a nice stack trace.
And there's tools that you can turn against.
It's much harder to just, you know, get up.
Like you said, a core dump.
That's a lot of work to look into, right?
Yeah.
The proportion of scary bugs causing sleepless nights in Python is much, much lower than in C.
I'm sure it is.
That's awesome.
So you said you have some people helping out on this project so that you can turn your attention a little broader to the community and supporting MongoDB in other ways.
And so you said you've been doing a lot of writing, right?
Yeah.
So in the last year, the scope of my writing has grown enormously.
I started writing my blog when I started working for MongoDB about five years ago on EmptySquare.net.
And I'm still publishing a lot there.
But in the last year, MongoDB itself has started up a tech blog.
And naturally, I've been doing a lot of writing and editing for that.
So I listen for interesting stories among my colleagues, problems they encountered, ideas they had, management or software engineering practices they tried that failed or succeeded.
And I've been soliciting articles and helping people to shape their experiences into tight-knit stories that are crisp and compelling and then helping them to write and edit those stories and publish them.
That's really cool.
I mean, you're taking these guys and girls who are mostly programmers, not writers, and you're helping them tell these stories, right?
So you probably help them come along as writers a little bit, help them break through things like writer's block and write well-structured, compelling blog posts, right?
Yeah.
And it's a very different kind of challenge.
I'm really struck by how much of a problem for people who are not professional writers, writers' block and procrastination are.
I was thinking the other day how if you assigned a programmer to implement a feature and three weeks later there was no progress whatsoever, no evidence of any effort whatsoever, that would be a serious problem.
You wouldn't see that very often.
And you would think about whether this programmer should continue to work for your company for much longer.
Whereas with a programmer who is writing, you might easily see three weeks of procrastination.
And you need to break through it, but it's also sort of not as surprising.
We procrastinate about writing in a way that we don't procrastinate about almost anything else.
Yeah, I think it takes a lot of practice to write well, and you almost have to make it a habit.
Yeah, that's true.
And maybe also to treat it as not certain to be perfect and not as intimate as it feels.
We need to treat it a little more like code, like do your best, read it over, do your best to make something that's correct and compelling, and then just publish it.
In the same way that we treat our code, where we know that it will never be bug-free or lightning fast, but we publish anyway because it's better than not.
Yeah, it's better than not doing anything.
Yeah, that's true with code.
I think it's true with blogging.
I mean, it's true with podcasting.
It pains me going to go back and listen to our original interview, not because anything we talked about, but just the experience that I have these days versus then.
I felt really a little unsure of myself and so on.
And the way you get better is by doing it, right?
So like writing code, blogging as well.
So you also write a little for the PSF blog.
Is that true?
Yeah, there was this unfortunate moment last year where the PSF's main blogger, Marianne Sushinsky, had, I think she fell off her bike and she hurt her wrist.
So she was one-handed.
And then wonderfully, Diana Clark, who heads the PSF, had a baby, but that effectively made her one-handed as well because she was holding her baby in one arm and typing with the other.
So unfortunately, two people with one arm each don't write as well as one person with two arms.
So Diana asked me if I could step in and write some articles for the PSF.
And I've been doing that since.
And the main thing that I do is I write profiles of people who've won PSF Community Service Awards.
And that's been super exciting because I can make contact with people who are prominent in our community, interview them about what they're most passionate about, about what makes their work stand out, and then communicate that to all of the PSF members and readers.
Yeah, that's a great service and a great opportunity for you, right?
I think one of the things that's interesting that sort of comes out of that is writing and blogging and these types of things, they open up opportunities that you otherwise might not have had, right?
That you might not have expected to have come out, but there they are, right?
Yeah, that's right.
And I really feel that difference when I went to PyCon in Portland this year compared to last year.
Because this year I had already had long phone calls with the two Community Service Award winners whom I profiled, Jackie Kazel and Damian George, and various people that they knew whom I talked to about their achievements.
So I had this built-in community and these conversations that I had already started having, and it made it really easy to continue to be connected with people when I met them in person in Portland.
Yeah, that's excellent.
So speaking of Portland, PyCon, it was a great conference.
Let's talk about your session that you did there.
You did one.
It was entitled Writing an Excellent Programming Blog, right?
Yeah, that's right.
So was this sort of motivated by your experience with working with all the developers at MongoDB and trying to synchronize them into a coherent set of articles and a machine that would create all these great stories from MongoDB and your blog?
Or where did it come from?
Yeah, that's right.
It came from both my personal experience of how much writing had benefited me, and also my experience of a community coming together and talking to itself and communicating its values to other people by writing.
So I had this sense that people who come to PyCon want to contribute code to each other, and they admire people who write great code, but that they were often unaware of what huge value we can achieve for ourselves and for each other by publishing our writing.
And I also felt like people who wanted to write didn't quite have the professional approach to it that they do to their coding, and so they weren't being very productive when they did decide to write.
Yeah, I feel like a lot of people blog with guilt.
You know, they are like, oh, I know I should have a blog, so I'll create a blog, and they'll write for a while, and then they'll kind of let it drop.
And then, you know, it's not good when you see a post that says, I'm planning on writing some more soon, you know, and it's like five, six months old.
But it is hard.
And so I think one of the interesting things that your talk does, and of course I'll link to the video.
It's recorded on YouTube so people can watch it, and I recommend they do, is you kind of broke it out into almost like a set of design patterns for successful developer blogs.
And you contrasted what it means for a developer to blog versus what it means to be like a tech crunch writer versus what it means to be a BuzzFeed article top 10 list writer, right?
You have different goals, different timelines, and so on.
That's right.
I think people think of a blog as something that needs to be updated regularly because they're used to the old model where people blog and expect repeat readers and think of a blog as something that makes money from page views.
But there's really not very many of those in the world, and they're nothing like what you and I and our listeners write about.
So what open source Python developers will write about is our individual specialties.
And we will write infrequently when we're inspired by some new piece of information or new project that we're working on within our extremely narrow specialty.
And we'll probably be speaking to a very small number of fellow specialists who are looking for this kind of deep expert knowledge about our topic.
So it's not going to be the news of the day.
Certainly not going to be anything like TechCrunch.
We don't do industry reporting.
We don't guess whether a company is going to IPO or whether it's going to be more profitable this quarter.
We're writing articles of deep significance and lasting value, and therefore we don't write very often.
And I think that that's completely appropriate.
But we really need to understand what sort of articles we write that are valuable in order to understand why it's okay that we write them infrequently.
Right.
But then understand the patterns and the styles that we can sort of fit our ideas into to best match as well.
You know, when you're talking, I was thinking this sounds a little bit more like an academic person, like a professor writing an academic paper more than it does, you know, a newspaper journalist.
Yeah, that's exactly right.
And that's why I encourage people not to think of themselves as writing blog posts, because the things that we publish about open source software development are not posts to a web blog.
They're articles about topics.
And so I think we should start calling what we do articles and essays, because that will put us in the right frame of mind to write well-wrought, deeply thought pieces of writing.
Yeah, that's excellent.
So you started out going through in your session talking about a couple of things.
And one of the things you talked about is there's a couple of reasons that we start writing.
I thought they were interesting.
You sort of touched on some of them.
Share your experience and expertise.
Meet your fellow experts, kind of like you did with going to PyCon.
You had exposure to these folks, and it was really great.
But another one that I found that resonated with me is you said, writing is thinking superpowered.
Can you expand on that?
Yeah.
I think that explaining a topic, we know this, that it's only when you try to explain something to somebody else that you are really certain about how deeply you understand it.
And I think it's even more so when you're writing it down and rereading what you've written, reinforcing your understanding, and looking up things where you realize that you have gaps.
One case where I did this, I very often do this when I start working on a bug, is I start writing the story of how I diagnosed and fixed the bug.
And I start writing the story before the story is complete.
So a few years ago, I was diagnosing this bug.
It had come up via a PyMongo bug report.
And what it looked like to me was that assigning to a thread local is not thread safe in Python 2.6, that you need to lock around that assignment.
And that is, if true, obviously a bug in Python.
And so intricate and deep and mind-blowing that I really didn't think that I would be smart enough to diagnose it.
Yeah.
Threading is hard.
Thread local concepts are hard.
And then if there's a bug down in CPython itself around it, like, okay, this is intense, right?
So I find it really interesting that you started writing before you actually had the answer.
It was like an exploration almost, right?
Yeah.
And writing down the story of how I diagnosed the bug was how I diagnosed the bug.
So I wrote down at each stage, this is how far I got.
This is what I was thinking.
And by then reading that back to myself, I could really entrench my understanding and also test it.
I would see, if I were somebody reading this, would this make sense to me?
What would I think the author had missed?
What haven't I thought of yet?
Am I certain of my conclusions so far?
And that allowed me to proceed step by step and diagnose a previously unreported bug in Python 2.6's threading implementation, which to this day, I think, is sort of astonishing.
That really is amazing, considering how much usage that version got.
Can you just sum up what the bug was in, like, a sentence or two?
Yeah, there is a way that one thread could interrupt another in the midst of updating thread local state that would leave something that had been in a thread local storage unreferenced and leaked.
And this caused a socket leak in PyMongo that would eventually lead it to run out of file descriptors.
Yeah, that's not good.
No, it was catastrophic.
But it's extremely hard to find, and it takes a long, long time for it to actually crash, right?
So not good.
Yeah, that's really cool.
SnapCI is a continuous delivery tool from ThoughtWorks that lets you reliably test and deploy your code through multi-stage pipelines in the cloud without the hassle of managing hardware.
Automate and visualize your deployments with ease and make pushing to production an effortless item on your to-do list.
Snap also supports Docker and M browser debugging, and they integrate with AWS and Heroku.
Thanks, SnapCI, for sponsoring this episode by trying them with no obligation for 30 days by going to snap.ci slash Talk Python.
So the next thing you talked about was almost like a design pattern, a set of design patterns that you see over and over in these technical writings that you talked about that are not academic papers, not BuzzFeed articles, but sort of this middle ground where we as developers often operate.
Can you maybe talk about those a little?
Yeah.
Among the stories that I really admired and found most valuable, it seemed like they were five-ish structures, which are stories, opinions, how-to guides, explanations of how something works, and then reviews.
And the structure of each of these is very simple, and you can reuse it like a template.
So a story just tells a sequence of events, and it's always got some moral like a fable.
You learned something, or you learned not to do something, or you discovered some fact that you wouldn't have otherwise.
One of the things I liked about it when you talked about these is each one of these sort of patterns, if you will, is accompanied with a concrete article from someone often in our community.
Right.
So, for example, you told the story of, I think you called it, it was called Unyielding by Glyph, and a problem around threading that has to do with the story.
Is that right?
Yeah, that's right.
Glyph's article titled Unyielding about a bug that he had in multi-threaded Java and how he fixed it by re-implementing his entire stack in asynchronous, twisted Python code.
It's a great story.
It's funny.
It's about this text adventure game he had where, due to a threading bug, a brass cockroach item in the game would multiply indefinitely and fill the entire world and make it unplayable.
So, it's hilarious and it makes really memorable his underlying point, the lesson of the story, which is that async code is less prone to race conditions than multi-threaded code is.
Yeah.
Very cool.
And then I interrupted you on the next one, which is opinions.
So, opinions, the structure is what we learned in high school.
You state a thesis, you back it up with three points of evidence or more, and you anticipate and respond to the reader's likely objections, and then you just conclude by restating your thesis.
And the example of that that I cite is an article by Julia Evans where she argues that we shouldn't feel guilty about not contributing to open source.
And her argument there is super interesting because she says that we often feel obliged to be always submitting pull requests, but sometimes open source software just works for you the way it is.
There isn't a missing feature or a bug that's getting in your way.
And if you make guilt contributions in that state, they won't actually be the right thing because they're not scratching your own itch.
They won't actually be that beneficial to the project.
So, when you're in that phase where you're just working with open source and it works for you like it is, it's okay not to contribute and you shouldn't feel guilty.
So, she's not attacking anybody there.
And that's really important.
I think that in the software community, especially open source, there's a lot of thoughtless and damaging aggression.
And we should stop saying, oh, that thing sucks.
That thing's a piece of trash.
That's not a useful opinion.
A useful opinion is insightful and interesting and...
No, it's definitely not useful.
...goes out of its way to be constructive.
All right, Jesse.
So, the next one is how to.
Yeah, that's right.
So, how to is probably mostly what we all write, where you just explain how to do something.
And it always begins by motivating it.
It says, if you want to accomplish a given thing, you'll need to know how to do X.
So, that lets the reader decide whether to read the article and also makes a promise of what the value of the article will be if they do finish it.
Right.
There's usually some kind of constraint, like under these circumstances or under these conditions, it makes sense for you to use, I don't know, object data model mapper for Mongo versus straight PyMongo.
Who knows, right?
But something like this.
Exactly.
And the example that I really enjoy for that is an article by Kenneth Reitz about growing open source seeds, where he...
Kenneth Reitz is the maintainer and inventor of requests, which is one of the most successful Python packages.
And so, he's got a lot of expertise about creating a package that's very popular and then maintaining it without burning out.
And that's what his growing open source seeds article is about.
But he begins by motivating you with a counterexample of a library that Facebook open sourced and then abandoned, which made everybody mad at them.
So, his promise is, if you don't want to end up like they did, like that project did, then you should read How to Do My Thing.
And therefore, if that's not a priority for you right now, you can skip it.
But if that does seem like a fate that you're in danger of and you want to learn how to avoid it, then you should read Kenneth's article.
Yeah.
Yeah, that's excellent.
I think we end up do writing...
We do end up writing a lot of how-tos, right?
I think that's sort of the engineering side of us saying, okay, I need to understand all the steps and the building blocks, the Lego pieces of programming or the Lego pieces of community building.
But there's also sort of the just understanding the concepts.
You know, how does something work?
Kind of like a scientist cares, you know, why atoms bond together, not just, you know, what do I do to make them come apart?
Yeah, that's exactly right.
I think we all have those two sides to us in some proportion.
So we also want to write how things work type articles where the motivation is not about actually doing anything, but simply understanding something.
And the article that I cite for that is by Allison Kaptor, who has for a long time been a facilitator at the Recurse Center.
And she wrote an article about syntax warnings.
So it turns out that if you do from module import star, if you write that line within a function definition in Python, you'll get a exception called a syntax warning,
which most of us have never seen because we didn't make that particular mistake when we were just starting out.
And one of Allison's students, though, tried that out and hit that error.
So there's no need to write how to avoid that.
You simply move the from module import star statement to the top of the file and you're good.
But Allison was really interested in where that syntax warning came from and why that statement was not allowed.
It might be a reasonable thing to do as a beginner because you can do those local imports if you preserve the namespace, right?
Like import OS would be OK, right?
Yeah, that's exactly right.
So it may not be very useful to know why that doesn't work, but it's awfully interesting.
So she dove in and she found out a lot about how the Python compiler works and its symbol table and wrote an article about it that is fascinating purely for the curious scientist within us.
Yeah, that's awesome.
And then so that was the fourth one.
The last one you said that maybe this is the easiest.
I think either the how to or this one, the review, might be the easiest if you just want to kind of write another article.
You've got something.
You're like, I kind of take this Saturday morning to write something.
A review could be a good choice, right?
That's right, because it can be any length and there's always something new to review.
You've always seen a movie or finished a book or tried out an open source project.
And if you just want to keep your blog alive or keep your writing muscles toned, write a review.
But the main thing to keep in mind is that simply rating things, saying whether the movie or book or a software project is good or bad, is not very useful to your audience.
And it's not very good as writing practice either.
It's much more important to describe what the thing is and what it's good for.
So this movie is good for relaxing on a summer matinee.
Or this project is useful if you want an easy-to-use debugger that doesn't have all the bells and whistles.
And by writing your review that way, that makes the most valuable description of that thing for your reader.
Yeah, that's excellent.
So these five things come together as these almost design patterns for our technical articles, if you will.
And I think they're really helpful.
How do you see them helping with writer's block?
So you can use it in two ways.
And this is what I do, is that if I've got a topic that I want to write about, but I can't seem to get started.
I don't know what the structure will be.
And so I don't know how to begin, how to write the first paragraph.
A great way to start is to ask myself, am I writing a story about this topic, or do I have an opinion that I want to argue for, or any of the other of the five structures?
And that narrows my scope.
I can choose one, and then I just plug in the blanks in the template.
And by the time that I've chosen a structure and filled in the blanks, I'm already halfway done to a first draft.
The other way that I can use this is if I don't know what to write about next at all, I can ask myself whether I have one of these five kinds of stories.
Do I have a story to tell, an opinion to share?
Do I want to explain how to do something or how something works?
Or is there something I've experienced recently that I want to review?
And that can help me to generate ideas and realize that I have thoughts that I want to write about that I hadn't been noticing before.
Yeah, that's really cool.
I think that's super helpful.
And I can certainly see myself going down this checklist if I've got just a blank WordPress, you know, new post, what's the title, and just an empty field for the content, right?
Like, well, what am I going to do now?
I think this is excellent.
So when you think about the target audience, one of the things people really care about is getting their blog to be popular.
And you said you kind of discourage people from being too overtly focused on things like SEO and content marketing and so on for your personal blog, at least.
What was your thinking there?
SEO is a set of techniques for competing for a mass audience with other authors who are writing about the same topic.
And that is the total opposite of the kind of writing that we're talking about now.
We're writing about specialties, and we're virtually the only people writing about them.
And that means that when our fellow specialists want to read about our topics, they'll be searching for keywords that only we are using.
So our fellow specialists will find us, and we really don't need to worry about it.
And we're not targeting a mass audience because we're not getting paid for page views.
All we're doing is communicating with people who are into the same stuff that we are.
So the number of page views and the number of clicks, it just doesn't matter.
Right. It's about making the connections and building the catalog of ideas and so on, right?
Yeah. And making sure that your fellow specialists know that you are one of the people whom they should talk to about these ideas.
Now, these specialized communities do have ways of sharing blog posts with each other.
There's Planet Python, which thousands and thousands of Python programmers read.
And it has a list of feeds that it aggregates on GitHub.
So you just go there and submit a pull request, and pretty quickly, one of the administrators will add you.
And if you are mainly interested in connecting with other Python programmers, that's good enough.
You're done.
If you're also writing about other topics, there are planets and aggregators for them.
And then there are also a number of these weekly emails like PyCoders Weekly and Python Weekly.
Their editors have big ears, and they generally hear about anything that they want to republish without your having to make any effort.
But if you do want to make sure, you can always write to their editors and mention whenever you write something that you think that they would be interested in.
And that's really good enough.
Google is designed to bring people who are interested in your topic to your site.
Yeah, I agree with you on that.
I certainly think communicating with the guys who write the weekly newsletters, there's Python Weekly, PyCoders Weekly, Import Python.
Those three seem like the big ones to me.
I'm probably missing some.
And if I am, sorry.
But, you know, you can get in contact with those guys pretty easily.
And I find it makes a big difference.
If something gets featured there, people usually talk about it.
Yeah, that's right.
Yeah, cool.
Also, maybe a little bit of social media.
Like, I find Twitter is a really good place for sharing your new ideas.
Because unlike a lot of social media, you sort of follow people because of their common interests and common ideas.
So maybe throw that one in there as well.
Yeah.
We all love Python for its tremendous productivity benefits.
But getting the best performance takes some work.
What if you could get out of the box, easy access to high performance Python?
Intel Distribution for Python Developers delivers just that.
Get close to 100 times better performance for certain functions when using NumPy, SciPy, Scikit-learn, linked with optimized native libraries like Intel Math Kernel Library, Access Efficient Multithreading, and Python projects like Numba and Scithon.
Try the Intel Distribution for Python and experience performance today at talkpython.fm/intel.
And profile your Python and native C++ applications for performance hotspots with Intel VTune amplifier.
With Intel, it's all about performance.
You did talk a little bit about how to get started if you're not a good writer or maybe you just don't have very much experience.
And you had some advice for those folks.
That was good.
So the main thing that makes us better writers is to read and read a lot.
And I think that a lot of community-minded open source developers do read a ton of blogs.
But we want to read them as writers.
And most importantly, that means reading articles to the end.
I would love to see a chart of this.
Or maybe I would hate to see a chart of this.
But I think that the first few sentences of most articles are probably read a hundred times as often as the last few sentences are.
People generally give up or skim.
So reading as a writer means actually reading the entire article.
And not just skimming it, but reading all the way to the end and then asking ourselves,
did this article communicate well or not?
And regardless of whether it was effective or not, how would we improve it if this were our article?
And that's the best way to improve is to read critically like this.
The other thing I would suggest is to get an editor.
And that can just be a programmer friend of yours or a non-programmer friend who's a good writer.
Find out who gives good, useful, critical feedback on early drafts.
And then you'll start to lean on those friends.
And you can swap drafts with them and help each other improve that way.
Yeah, that's good advice.
How do you feel about having like a writing group, like three or four people who are into blogging and maybe meet on Skype once a month to exchange ideas and share articles and whatnot?
I think that sounds wonderful.
I want you to invite me.
Yeah, absolutely.
Yeah, I think it sounds wonderful too.
All right.
So that's for if you don't have a lot of experience.
I think this idea of reading articles with this critical eye is really powerful.
And the world is working against us on this.
You know, with things like Flipboard and Zite and the apps that encourage you to read the first paragraph and then flip on to the next.
It means we do this less and I think we get in the habit of doing less.
But I think it is really a good way.
It's almost like, you know, learning to code well by reading open source software that is well respected.
This is the writer version of it, right?
Yeah, that's right.
Cool.
So that's the getting some experience story.
But if, you know, maybe I'm a fine writer, but I'm just really busy.
I have no time.
You also had some advice for those guys.
Yeah.
The first is just to remember that it's okay to write in frequently.
If you are occasionally inspired by a really powerful idea that you're so excited about that you just can't do anything until you've communicated it, then that's the time to write.
And the rest of the time, maybe not.
But if you do just want to practice your muscle a little more, I think that writing reviews and setting yourself a time limit is a really good way to just stay in shape.
So promise yourself after every book you finish or after every movie you see to set a timer for an hour, write three paragraphs, describe the thing, and you're out.
And with that muscle kept in shape this way, writing more frequently and writing longer and more valuable articles will come more naturally.
Right.
I definitely see that as a natural consequence.
You hear about lots of the really prolific authors.
They didn't spend that much time writing.
They'd get up at like eight and write to noon daily.
Or they'd sit down every day and they say, I'm going to write three pages a day.
And that's it.
And they've written hundreds of books just by going like that.
So this do a little bit actually adds up really quickly, I think.
So what's the takeaway from this talk that you gave?
The takeaway is to write together if you have the opportunity.
So if your company has a tech blog, then submitting articles to it is the best way to make yourself visible both to your company and to your larger community.
And if your company does not yet have a tech blog and you're somebody who's passionate about writing, then this is a huge professional opportunity for you.
You should be the one who starts your company's tech blog and helps your company communicate about its engineering culture to the wider world.
And besides companies, there are lots of open source projects and foundations that need to get the word out to their community, but don't have anybody writing for them right now.
So blogging for and about these kinds of projects is a way to make a connection and create something of lasting value.
Besides this, just remember that even though you may feel like if you're not coding, you're not producing anything worthwhile.
It's not true.
Writing is one of the most generous things you can do for yourself and for me, because I want to read about your specialty and for your community at large.
So use these five structures to overcome writer's block.
Get yourself inspired by whatever it is that you're working on right now and publish your thoughts.
Yeah.
Great advice.
You talked about writing together and you also talked about in some sense, if you write it, they will come right.
If you write enough specific, important articles, people will come.
But if you're just getting started and you really have nobody, you know, your brand new blog, nobody subscribes, nobody cares, that can be challenging and it can be discouraging.
And getting feedback is valuable.
So what do you think about like guest posting?
Like if you want to write an article, you think it fits with someone else's blog.
Does it make sense to reach out to them and say, hey, I'd write a post for you if you're open to that sort of thing?
I think it would.
It's not very prevalent in the open source community.
We tend to stand up our siloed blogs and occasionally link to each other.
But it can be a good way to get the word out.
And big sites like dzone.com and similar large sites that have lots of bloggers.
Reach out to them and ask them if they would like to republish you.
I found that to be very effective for me where an article that I publish on my own site might get a few hundred hits.
But if it's something that Dzone likes and they republish it, it will get thousands of hits instead.
When you do that, if you do care about bringing people back to your own blog, then arrange to have many links to related articles that you've already written on your own blog.
In the article that you've guest posted on somebody else's blog so that you can connect with your readers over the long haul.
Yeah, that's good advice.
And Dzone has a most valuable blogger program where you can get sort of reviewed by them and approved.
And once you're in, they'll sort of pull and review and possibly repost your articles automatically.
So if that sounds cool, then check that out.
So you wrote all this up in sort of links and examples and everything at bit.ly slash excellent-blog, right?
Yeah, that's right.
Excellent-blog is super meta because it's an article based on a talk about writing about programming.
And now we are discussing it on a podcast.
It's quite meta.
It's maybe meta-meta.
A couple levels.
But if you can stand the sense of vertigo, reading it is helpful because it's a written-up version of my PyCon talk.
And it has links out to all of my favorite articles as well as lots of other resources that will help you to improve your writing and also to get the word out and reach an audience for your writing.
Yeah, cool.
That's a very good resource, and I'll be sure to link to it.
Another thing that you did recently that I found to be pretty awesome was you wrote a chapter.
I'll call it a chapter.
I guess it's a chapter.
For a book that got published called 500 Lines or Less.
You co-authored that with Guido Van Rossum, right?
Yeah, that's right.
It's within the architecture of open source applications book series.
And the 500 Lines or Less book has articles where programmers solve very advanced, scary-sounding problems with very short code examples.
So Allison Kaptor wrote a Python interpreter.
And Ned Batchelder wrote a template engine.
And there's all sorts of intricate topics in there.
Guido and I wrote essentially a version of AsyncIO with a web crawler and asynchronous coroutines that fits within 500 lines.
And then used it to write an explanation of how AsyncIO works, how coroutines work, how the yield from statement works, and also how you can use queues and other thread-like structures within an Async program to make your AsyncIO code manage its control flow.
Yeah, and I thought that was a very nice piece of writing.
That was about 25-ish pages or so.
And you start from, let's just write the most naive, straightforward way.
Well, maybe the natural way to make this do more at once is to throw threads at it, but there's all these problems.
And you slowly build up to this final kind of understanding of AsyncIO.
It's really amazing if you work at it, how simply some of these ideas can be expressed, especially in Python.
But any time that you throw away error handling and throw away all of the historical baggage and just really focus on the technique that you want to express, just a little bit of code can often do it.
And if you read this book, you'll find that things with really scary names are often quite approachable if you read one of these really focused implementations of it.
Yeah, that's cool.
It's not all Python, is it?
It's a mix.
But it seems to have a lot of Python in it.
Is that right?
Yeah, that's right.
It may be that if you want to get something done in 500 lines, you're likely to choose Python.
But there are a lot of other programming languages represented there, too.
Okay, excellent.
Yeah, I definitely recommend people check out that book.
I find it, I found it to be pretty fascinating.
Originally, and I had you on show number two, we were talking about Python and MongoDB.
You're still at MongoDB.
We talked about kind of what you're up to there.
But, you know, what's the latest news from Mongo in the last year?
Yeah, so at MongoDB World last month, our annual conference, we announced a bunch of exciting new features.
The rightly headline grabbing one was Atlas, which is MongoDB as a service.
You just tell us how much Mongo you want, what kind of Mongo you want.
And we set it all up for you.
Currently in EC2, but we're going to add new cloud providers in the future.
And it's this extremely focused UI that will just get you from zero to a distributed, fault-tolerant, backed-up cluster of MongoDB in as few steps as possible.
Oh, that sounds really exciting.
I'm sure that'll help, especially newcomers, but it'll help everybody.
That's cool.
We've also got a lot of great news for Python developers specifically coming up.
One of them is that Motor, which is my async MongoDB driver for Python, it supports Tornado and AsyncIO already.
And I'm going to be developing, finally, Motor 1.0 this fall, which will use the latest version of PyMongo under the hood.
That means, among other things, that it will perform much better, especially when it connects to very large replica sets with a large number of servers in them.
And that it's going to be stable and give you an API that you can rely on for years to come.
That's awesome.
Congratulations.
Thank you.
The other big news is that Anna Hurley and I are working on a NumPy BSON codec.
So this is going to go directly from NumPy, which is what Python statisticians use for large data sets.
And it will translate directly to and from BSON, which is the binary JSON data format that MongoDB uses internally.
So in the past, whenever you wanted to move data back and forth, you had to have some intermediate structure, usually a Python dictionary.
And that slowed down that transcoding to a crawl.
But now, if you want to load up a bunch of numbers into MongoDB, use MongoDB to store it or to query it, and then load it back into NumPy arrays in order to do statistics on it, that pipeline is now going to be very streamlined and extremely high throughput.
Oh, that's awesome.
How much of your C work contributed to that?
Any?
This is really only possible now because I know C well enough, and so does Anna, that we can tackle it because it's essentially a C project.
And that's why it's going to be fast.
Right.
Oh, that's awesome.
Yeah.
Okay.
Well, that's really good news to hear what you guys are up to.
It continues to be exciting over there.
So, Jesse, we're getting close to the end of the show.
I always ask people when they're writing Python code, you know, what's their favorite editor?
Well, my favorite editor is PyCharm.
I feel very strongly that people hobble themselves when they use Vim or Emacs.
They need a real debugger, an editor that understands the structure of their project, and it has a built-in profiler.
It's got all sorts of amazing features, and it's really worth the time investment to learn it.
Awesome.
Okay.
What's your favorite PyPI package?
Right now, I'm really enjoying Lector, which is Armin Roeneker's project.
It's a static site generator.
It's written in Python, and it's what I use now to generate my own blog.
And then I upload it to a hosting service called Netlify.
But Lector can publish to lots of different places, including GitHub pages.
David Baumgold now has joined the project and is one of the chief maintainers along with Armin.
It's a very flexible, fun project.
It's new.
It's got an active community.
And if you want a static site generator that's written in Python, you can get in there and hack it up a little bit.
Lector is treating me very well.
Okay.
That's cool.
I haven't played with Lector.
I'll definitely check it out.
All right.
Jesse, any final call to action for our listeners out there?
Maybe we're maybe thinking about blogging or have a blog, but it has updates in the last decade.
Yeah.
Get out there and get writing.
Don't worry about what platform you're going to use.
Don't mess around with your visual design for too long.
Just write down what you're really excited about so that I can read it.
I want to second that thought as well.
Jesse, thanks for coming on the show.
It's great to share these blogging ideas and everything else you're up to.
Thanks a lot.
Yep.
See you later.
This has been another episode of Talk Python to Me.
Today's guest has been A. Jesse Giroux Davis, and this episode has been sponsored by SnapCI
and Intel.
Thank you both for supporting the show.
SnapCI is modern, continuous integration and delivery.
Build, test, and deploy your code directly from GitHub, all in your browser with debugging,
Docker, and parallels included.
Try them for free at snap.ci slash talkpython.
The Intel distribution for Python delivers the high-performance Intel C libraries built right
into Python.
Get close to 100 times better performance for certain functions when using NumPy, SciPy,
and Scikit-learn.
Check them out at talkpython.fm/intel.
I'm so excited to finally be able to unveil my Python for Entrepreneurs course that I told
you about at the top of the show.
If you want to learn Python web development and launch an online business, you owe it to
yourself to check out the Kickstarter at talkpython.fm/launch.
I hope we can build something amazing together.
You can find the links from this episode at talkpython.fm/episodes slash show slash
69.
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.
Our theme music is Developers, Developers, Developers by Corey Smith, who goes by Smix.
Corey just recently started selling his tracks on iTunes, so I recommend you check it out
at talkpython.fm/music.
You can browse his tracks he has for sale on iTunes and listen to the full-length version
of the theme song.
This is your host, Michael Kennedy.
Thanks so much for listening.
I really appreciate it.
Smix, let's get out of here.
Outro Music
Thank you.