How Writing a Blog is Like Writing Code

One of the things I hear from people is that they’ve got an idea for an article they want to write but aren’t sure how to go about it. This is a slightly meta post (blogging about blogging), on how that process looks for me and how similar it is to writing a technical feature.

Assuming I’ve had an idea for something I’d like to build, I’ll start by thinking about what I want the end result to be. I’d like to write something about X, that will be useful for people who are thinking about X. Or I’d like to build something to do Y, as there’s a need for our app to do Y.

After framing the problem, I’ll then go and do something else. It’s not as strategic as it sounds. Normally it’s me pushing that task into the future as I don’t yet know exactly how to go about doing it.

While I’m elsewhere I’ll tend to jump to thinking about the blog or feature sporadically. I’ll have ideas about certain parts, how to break the problem down or exact points I want to get across. When this starts to happen more and more frequently I start to feel like it should be done already. And that frustration kicks me into starting.

Next I’ll sit down and set up the things needed to start. Creating a document, writing the title and then putting down the purpose of why I’m writing and the audience. With the feature, I’ll create an issue for that feature on github. With both, I’ll write a list breaking down the points I want to cover and parts I’ll need to build.

Then I’ll write version one. It’s a draft, I’m not editing my work as I go along, I’m just trying to get down the ideas and flow of what I want to do. This way I end up with something which conveys my ideas in a messy way. The function I write will be something that works but parts may be named quickly, bits will be repeated, I know I’ll tweak it on the second run through.

Once that’s done, I’ll go away and do something else before I re-read it. Sometimes I’ve got the balance wrong here, I’ll get a major piece of work that needs to be done to a deadline and completely forget about my own project. It means when I come back to it, the editing feels like a chore. Other times, I don’t leave enough time and can’t see how to make it better as I’ve been focusing on it for too long.

I’ll then go back through, step by step and start condensing. I’ll alter wording so it fits the tone, cut things that don’t add anything overall, choose better variable names, and generally refactor (rewrite) what’s there so it gets the same objective in a more concise and coherent way.

And then it’s knowing where to stop. Sometimes I’ll publish too soon, re-read it and wish I had spent more time on the phrasing. Other times I’ll spend much too long focusing on phrasing. I aim for good enough, not perfect, but it’s hard to know when the time spent starts to outweigh the benefit.

So sit down and give it a go.