I’m a blogging-geek. Having read and written them for many years, I remain excited by blogging and social media as a whole because they have removed barriers to publishing and democratised access to speach and information. I’ve previousy shared why I blog. Here’s a post about how I blog.

Inspiration

Writing can be daunting. I don’t sit down with a blank page and the desire to write a post. I have lots of options floating around in the background. Some are undeveloped, others are well-developed. I capture inspiration when it strikes so I’ve got a bunch of options at all times.

Professional challenges, product problems, leadership challenges, and interesting new ideas are always swirling around in the back of my mind but it’s hard to do something with them at work. The size and complexity of the organisation I work in and the pervasive communication tumbling through Slack means that I switch context many times a day.This makes reflective thinking difficult. To counter this I walk to work at least once a week (ideally a couple of times a week).

I live in Homerton and work in St James Park so the walk takes around 90 minutes. I’m normally listening to music but am otherwise undistracted, enjoying the walk itself. A weird thing happens most days: as I walk along Fleet Street and approach the Royal Courts of Justice on the strand, an idea will pop into my head. A problem I’ve been thinking on for a while will resolve itself. A couple of previously unconnected trains of thought will usefully converge. It’s very cool. Turns out that the most productive tool might be walking. I then switch to a more traditional productivity tool and make a note of the idea in Google Keep.

Alternatively, I sometimes read books on commute to work. The concepts are often familiar or I may be rereading something so I can often skim for useful points rather than reading slowly for depth of understanding. Perfect for public transport. If an idea or concept is particularly useful then I take a photo with my phone and save it in Google Photos.

Inspiration can strike anywhere. The above examples list the two most common ways that I get and capture ideas but it can also happen after a chat with peers, challenge or success at work, or interesting insights from others.

Periodically an idea will become clear enough to expand. Brief notes in Google Keep and photos in Google Photos will be explored further in a Google Doc. These Google Docs sometimes become the bones of a post, funcitioning as a drafting process.

I typically have at least 10-20 ideas swimming around in the pool of my Google Apps. Many of them have been incubated for weeks, sometimes months. They’ve all been refined at least once or twice and several of them have been discussed a few times. All of this helps to figure out the angle that makes them intersting, and to remove the angst from writing.

Choosing a topic

Choosing a topic has been easier since I’ve had my pool of ideas. I simply wait until a topic is particularly interesting to me - or until it’s useful for solving a problem at work - or a specific opportunity crops-up to write for someone else.

In the past I assumed that every idea I had necessitated a blog post. The list of titles became a ‘to do’ list and so writing became a stressful chore. This approach isn’t fun. I’ve changed in the last few years and removed the anxiety. Now I view blog posts how I view products, prioritising the posts that are most valuable, useful, and feasible. The most useful lesson I’ve learned is to let things go. Thinking about something can be a reward in its own right and there’s no need to write a post. This leaves space to write only what is most useful and most fun.

Writing the post

A decade into writing blog posts and I’ve got a pretty consistent process:

  • open up my laptop and start listening to a Spotify playlist on my earphones.
  • coffee can help to focus on the task at hand, particularly when the idea is pretty well-developed.
  • posts are written in GitHub. GitHub is marketed as a tool for software developers. However, at its heart is a text editor with version control that’s great for drafting blog posts. I write in GitHub via my browser*, hitting F11 to maximise the editor to fill the screen so as to remove the distraction of the search bar and all the website that sit behind it.
  • write using Markdown, a way of using simple tags to tell browsers how to format my post when it’s published to the web. Tom Preston-Werner’s post explaining why he created Markdown is still online, called blogging like a hacker and is a great read. I love how publishing has been revolutionised by the world wide web
  • write until happy with the post, normally a single sitting of 30 minutes up to a couple of hours
  • for simple posts I pause, take a break, then check that the words make sense and review for spelling, punctuation and grammer
  • for complicated posts I’ll use Hemingway Editor to see what improvements I could make (thanks to Nabeeha for the recommendation).

I don’t agonise over the post. They’re normally written for me to figure something out. I’m writing about niche topics of interest to a relatively small audience so don’t need to worry about writing great literature. My goal is to get it out quickly, improving once it’s published.

Note: *I don’t use a text editor like Atom. I used to but I’ve natually tended towards editing using GitHub in the browser. Most of my posts are text-only and Markdown only. I like having to check spelling manually as it reminds me how to spell :) I use GitHub Desktop when writing posts that need images. You can see this post in GitHub here.

Publishing the post

I publish posts directly from GitHub using GitHub Pages and have done since 2016.

WordPress was my blogging platform of choice for years. After a while I wanted the ability to back-up my posts, something that was not always simple in WordPress. Three years ago I moved from a self-hosted WordPress website to GitHub for reasons outlined in this post and have not looked back.

GitHub Pages are powered by Jekyll which turns plain text into simple, static websites. This simplicity is what made them easier for me to backup, unlike the database-driven blogs I had on WordPress. Jekyll does the hard work, turning my simple Markdown files into a simple but effective blog published by GitHub Pages.

GitHub Pages is free. I used to spend £50-£100 per year on hosting but now get that for free. I run a simple blog on a niche topic read by hundreds of people a month, not thousands (or more) so don’t need to handle many concurrent users. I pay for my own domain but that only costs a few quid a year.

Originally I built my own website through which to view the blog, using HTML and CSS. GitHub Pages has moved-on since 2016 and now offers themes. I switched to a theme called Minima earlier in the year and no longer need to engage with code more complicated than Markdown.

Publicising the post

I keep publicity simple, using a Tweet on Twitter and a status update on LinkedIn to publicise my posts. My goal is a small number of engaged readers. My Twitter and LinkedIn accounts are carefully curated formed from people I have worked with or am working with (for the most part), people I trust and respect.

So what?

I’ve got Google Analytics monitoring my blog and can see that it’s been accessed by 1,617 unique browsers in 2019. Unique views is a proxy measure at best, a vanity metric at worst.

The act of writing a post is normally a reward in itself, as it’s helped me to figure something out. Folks who’ve read my posts are often kind enough to mention so, either through real world conversation or when chatting over email. This is the feedback I’m looking for. The kind people who take the time to mention that they’ve read a post helps to validate the contents of the post, particularly when it leads to a conversation that challenges or develops my understanding further.