Gant Software Systems

How To Write A Blog Post Quickly

I know this is a bit outside the normal content for this blog, but since I get asked frequently, I figured I would share my method. It usually takes me an hour or two in total to build a blog post, although some of the longer ones might take as much as three hours. I do sometimes get interrupted, but for the most part, I’m able to write the whole thing without too many problems. I’ve refined the method over time to help improve my speed as well.

First, I’ll explain why I do this the way I do it. The way I’ve set things up allows extreme focus on only a single task at a time, which allows me do things as quickly and cleanly as possible. The work is broken into several phases, each of which has only a single variable (or as close to that as I’m able to get) controlling how quickly I get it done. When I’m brainstorming, I’m only focused on coming up with ideas, not grammar, spelling, or flow. Later phases are speed bound by my organizational skills, typing speed, reading/editing speed, and occasionally by creativity level. But the salient point is that I try to limit a particular phase so that I only have to optimize a single variable (enterprise software developers might see something familiar in this approach – it’s just like what you’re probably thinking). Finally, doing things in this manner allows me to build blog posts in batches, which is often helpful if one’s schedule is chaotic, as you can do several instances of the same task more quickly than you can do a similar-sized number of disparate tasks.

The first step in my workflow is coming up with topics. This was a little harder when I first started blogging, as it takes some time to get used to appropriately capturing ideas as they come up. Now, however, I’ve made sure that I always have some way of getting ideas down as soon as they occur to me. I usually do this using Evernote by simply adding a note in a special notebook for blog post ideas. I can add details as needed to the note, but the most important part is simply capturing the ideas as they hit my mind. Don’t judge the idea as it hits your brain; simply capture and move on. You do NOT want to stop the creative juices from flowing, so ignore your inner monologue and simply capture the idea. You can always judge the idea later and delete it if it is crap, but you’ll often find that you get several good ideas in a row if you don’t get judgmental about them as they come in. The only variable binding this step is your ability to come up with ideas. They don’t have to be good ones – I’ve got a couple of real stinkers that camped out in my evernote folder for months before I discarded them.

When the time comes to brainstorm (best done a day before or more), go to your notebook and grab an idea about which you feel comfortable pontificating. Don’t be alarmed if the ideas you have all stink, sometimes they can still spur better ones. After some practice, I’ve found that the right idea tends to jump out at me, but I struggled in the early phases, especially when I didn’t have a good-sized pile of potential ideas to write about. Whatever you do, don’t write about an idea that you don’t feel like doing; part of the reason we’re brainstorming a day or more before the actual writing is to give yourself some time to mull over ideas. This phase is only bound by your desire to write on a particular topic.

Once you are ready to brainstorm, I would suggest banging out a short outline. I usually start out with 4-10 talking points, which I put into a mindmap. I don’t try to organize anything at this level, instead preferring to get my points out. Once those points are in determined, add 1-5 small notes under each for detail. I usually organize my stuff in XMind. This is a transient document and is not part of the final product. Like the initial idea phase, you only want the speed at which you get through this part to be determined by your ability to break the work down into chunks. Don’t worry about grammar or spelling errors, just collect the points. At the end, you might have something like this, which is my outline for this blog post:

Mind map for this blog post
!A blog post mind map(/content/images/Writing-a-blog-post.png)

Once you’ve got your ideas in place, sort them in such a way that they make sense to you. XMind is nice in this regard, because you can drag and drop. In the right-hand pane, the points are sorted in a clockwise fashion (from 12:00). You can drag them around until the general layout of the topic looks sane to you. Pay particular attention to topics that are too small or too large compared to others, as these might indicate either excessive or inadequate detail. Once this is done, if you have the time, it’s best to let it sit for a day or so, then come back and look at it and make sure it still makes sense before writing. The speed at which you get this phase done is only dependent on your ability to organize.

The next phase is the actual production of content. Before actually writing the meat of the text, write an introduction leading people gently into the topic at hand. Next, go ahead and build your conclusion as well. You’ll notice I didn’t tell you to write the middle yet. That’s because that part is really another step altogether. In this phase you need to make sure that you are accurately summarizing your content and that it fits with the points you wrote out before. It’s a lot easier to do when you have the two side by side.

With that completed, you’ll move on to actually writing the middle of the post. For each top level topic item, write 1-3 paragraphs based on your outlined points. This is usually pretty easy to do. The one thing I would caution you about here is to make absolutely sure that you do not correct grammar, punctuation, and spelling as you go. This is hard to do, particularly for those of us who are fairly pedantic with grammar, but attending to those items while attempting to write will quickly break your momentum. You don’t want to do that. Instead, just write the material. Ideally, you want the speed at which you complete this phase to only be bound by how quickly you can type and how many times you are interrupted. Done properly, this phase can actually be fairly quick, and not be particularly difficult to complete, but it gets ugly when you have to write, edit, organize your thoughts, and brainstorm at the same time. That’s like trying to optimize a set of distributed processes for consistency, availability, and partition tolerance at the same time. There will always be trade offs to such a thing, but here (unlike in distributed systems), they are totally unnecessary.

Once the writing is done, take a break for a few minutes (or a few days if you have the time, nobody says you can’t build posts weeks in advance, but I don’t), it’s time to sit down and actually edit the text. First, to hit the high points, copy the text from whatever blog editor you are using and put it in Word (or OpenOffice). You don’t want to write posts in word, but it does an excellent job of finding misspellings and bad grammar. Look at anything highlighted as being suspicious and fix it in your blog editor. Once the obvious problems are handled, read your blog post. I usually do so out loud, as it helps me catch awkward wording that is not necessarily incorrect from a semantic point of view, but is hard to read (like the previous sentence, left intentionally to prove the point). Once you’ve gone end to end, think back and make sure the layout actually makes sense. Do your talking points naturally lead towards your conclusion and give further detail to your introduction? They probably do since you were organized, but this is a good time for a sanity check. Your speed at getting through these steps will depend largely on how quickly you can read through the text and apply your edits.

Finally, with that done, you need to actually publish the blog post. I don’t directly publish mine, as the best time for writing is seldom the best time for reading. I currently publish blog posts at 2:00PM central time on Tuesday afternoons. but you may need to experiment to find the optimal time. Most blogging tools (WordPress included) have the ability to schedule a post to come out at a particular time and date. This can also help if you are a little nervous about your posts, as I frequently am, because you can schedule a post to publish and do one last read-through an hour or two before it comes out. If it gets rid of the anxiety, go for it.

With that done, you now need to handle the web side of your blog post. This means setting up appropriate categories and keywords, both for your own website and for search engine traffic. You’ll also need to choose an appropriate title for the post, and set up appropriate titles, descriptions, and keywords for various social media sites (you ARE sharing to social media, aren’t you?). I use the All In One SEO Pack for both tasks and it seems to work well enough for my purposes. If you are actually scheduling when blog posts are shared to different social media sites, you’ll also need to schedule those shares. I don’t currently do this, but I’ve been looking into getting a Buffer account specifically for this purpose, as I would like to tweak the release times on different platforms in order to optimize (I find Facebook traffic and LinkedIn traffic don’t tend to happen at the same time).

In conclusion, it’s actually fairly quick to write blog posts, even those approaching 2000 words in an hour or two, provided that you have a repeatable process that is only constrained by a single variable per step (or as close as you can get), where you are only sharply focusing on a single aspect of the post at a time, and where you have built in some gaps in time to help make better creative and editing decisions. Writing blog posts without having a good process is like writing a big program without abstraction. It can be done, but it hurts because you have to think about too many things at once.