When I first started Code it Pretty, I searched for a guide to running an all-tutorial blog. I found generic advice about how to write a good tutorial, but nothing about the day-to-day experience of running a tutorial blog — the type of blog that's going to get an avalanche of questions, most of which really need answers.
Over the 3 years since I started, I realized why I couldn't find that guide; there is no one true way to run an all-tutorial blog. The process that works for me is very personal and came from a lot of trial and error.
But, that doesn't mean that there's nothing to be said about how it's done. Though this is not — and can't be — the definitive "tutorial blog handbook" I was looking for, I'm sharing some lessons I've learned and strategies I've developed to keep my blog going strong without stressing myself out.
Inbox Zero Ain't Happening
When I put a tutorial out into the world, I know I'm going to get questions. In fact, I hope I do — if I don't, nobody's reading!
At the beginning, I tried to answer every comment and email. It wasn't possible to keep that up over time, so I came up with limits and policies to help me manage all the questions I get without getting seriously overwhelmed.
Set limits. I set firm limits for myself about when I respond to questions. I have a set window of time for answering questions on weekdays. After that time is over, I stop reading/answering questions for the day. On the weekends, I don't answer questions at all. That boundary is a big help in keeping me from burning out.
I try to answer as many questions in my tutorials' comment threads as I can, but sometimes I just can't keep up. When I'm too busy, I'll skip over some comments without beating myself up over it. Vague comments (like "this doesn't work for me" with no other details), and questions from people who clearly haven't read the entire tutorial are just begging to get skipped, so they're the first ones I'll let slide.
Create policies and make them known. I have one set-in-stone policy about how I answer tutorial questions — I only answer them in the comment thread for the tutorial. That way, when another reader has the same question, my answer is right there on the same page as the tutorial.
I'm super up-front about this policy. It's on my Ask page twice. The Ask page is the only place I list my email address, so if a reader is emailing me, they've definitely had the chance to read my policy.
Since I put that policy in place, the email I get with tutorial questions has decreased significantly. I still get a handful every month, but they get the lowest priority in my inbox (and I don't stress about it). When I get around to answering I send a form letter that gently repeats my policy and points back to the comment thread.
Put together a file of "ready made" responses. Having some form letters and pre-written bits really helps me answer questions faster. At first I kept a Google Docs file of all my pre-written stuff. Now I use TextExpander, a Mac app that lets me type in my saved responses with just a few keystrokes.
Always. Be. Revising.
I think of my tutorials as living documents. I've never written a tutorial that was permanently finished on its first day of publication. I tweak, correct, and revise all the time.
Update your tutorials as soon as you can when something changes. I write about technical stuff, so change is constant — blogging platforms get updated, the tech I write about changes, and my own skills evolve. I make many small revisions throughout my blog every month. Sometimes, I'll completely rewrite and republish an old tutorial to bring it up to date.
If you have to repeat yourself often, figure out why and revise. When I write answers to questions, I pay close attention to when I'm repeating myself. Sometimes, it's unavoidable — I know I'll always have to ask questions that start with "Can you be more specific..." and "Can you link me to where you're using the code...". That's when my pre-written responses file really comes in handy.
But, when I find myself repeating the same exact detail about a tutorial in my answers, I know there's a problem with the tutorial and I need to make a revision. Either something is missing from my instructions, I haven't explained it well enough, or I need to use a visual cue to keep readers from skipping over something important.
Kill Your Darlings
William Faulkner said, "In writing, you must kill all your darlings". I wouldn't go as far as old William there, but sometimes a tutorial I love a whole lot still has to die.
I've deleted posts that I put a ton of time, effort, and care into. In most cases it was because they were about things that don't exist anymore. But, in two particularly painful cases, I simply failed at teaching something complicated, and I couldn't revise my way out of it. It's a bummer to dump hard work, but trying to support obsolete or ridiculously difficult tutorials is worse.
When I do kill a "darling", I redirect the post's URL to another relevant page on my blog so anyone following a link to the old post won't end up on my 404 page. If there's nothing else like the deleted post, I redirect to the home page or my "Tutorials by Topic" page so the reader isn't completely lost.
Background image in title card from (affiliate link) Creative Market
