kalo pilato

How to Stop Stalling and Ship Your Personal Blog

8 October 20205 minute read
A chalkboard displaying the message "subject to technical issues" in capital lettersA chalkboard displaying the message "subject to technical issues" in capital letters
Image by Andrew Martin from Pixabay

This blog very nearly wasn't. I've built the blog platform twice before, both times to ~90% completion, but could never seem to commit to publishing. Why? I have years of experience developing complex web applications so why couldn't I ship a simple blog app? It's clearly not for lack of technical ability, nor lack of content ideas for that matter. The perfectionist in me would claim that I never shipped because the platform wasn't quite finished (the styling's off, there's no search, SEO, ... ad nauseam), but I'm used to iterating on production applications in my professional life so that can't be the reason. On reflection the real reason was fear. Imposter syndrome. I was using technical barriers as proxies for non-technical barriers. If this sounds familiar to you then read on and I'll step you through how to remove these technical barriers and ship your personal blog.

Why Blog?

First of all, let's ignore the reason we haven't shipped our blog and focus on why we want to blog. There's no shortage of blog posts exploring why blogging is good for developers, including this great post by Flavio Copes, but what do you want from your blog? In my case I have a few main motivations:

  • Knowledge sharing. I have benefited greatly from the blogs and knowledge sharing of others; I hope that my knowledge and experience can help others too.
  • Deeper learning. It can be easy to solve a technical problem, then move on to the next without giving much thought to the how. Writing encourages a deeper understanding so that you can more clearly articulate the problem/solution space.
  • Cataloguing solutions and ideas. Sometimes I'll solve a problem, then not encounter that problem again for a long time, at which point I've forgotten the context. The odds of remembering the solution are better if you have written about it and can refer back to the article. It's also much easier to refer colleagues to a blog post than to explain the solution multiple times.

Notice how none of those motivations explicitly require platform features like styling/search/SEO? Sure, those are all good things, but based on my motivations it's clear that my main focus should be on the content, not the platform. Yours may differ. If, for example, your motivations include showcasing your mad CSS skills to prospective employers then your requirements will likely include top notch styling. In my case content is king. Yes, we're talking about a blog site and that should've been obvious. No, it wasn't obvious because I distracted myself with technical concerns. But let's use this discovery to make a plan.

NOTE: At this point, knowing that we're all about the content, you could easily make a case for using an existing blogging platform. There are a lot of reasons to do so (e.g. SEO, existing audience, no setup time, platform isn't your problem) but I have my reasons to roll my own (e.g. owning my content, control of the platform, conquering my 'non-shipping' demons).

Let's make a plan

As I've proven in past attempts, when it comes to personal projects I'm prone to "productive procrastination", distracting myself by building features that are good but that I don't immediately need. I'll still want a lot of those features in future, but they're not necessary for "go live". For example: I'd like to have search functionality at some point, but I'm going to ship with one or two posts, not enough to warrant building search first. Besides, search will give me something else to blog about right? On the blog that I've actually shipped. OK, so with the goal of shipping a basic platform for publishing technical content, let's hone in on the minimum requirements to make it happen:

  • Static site. Our blog should be snappy, lightweight and easily indexed.
  • Basic styling. The bar is intentionally low here. Unless you're a CSS whizz (I am not) styling can be a time vortex so nothing fancy, just make it easily legible and not a responsive train wreck.
  • Markdown blog posts. I like markdown. It's familiar, portable, and has a wide range of tooling available.
  • Dynamic routing. We don't want to make any functional code changes to publish a post, just write and publish.
  • Code syntax highlighting. This is a developer blog after all, code needs to be easy on the eyes.
  • Ship it! Deployed to the web.

I'd call that a fairly short list of requirements. Sure, there's a bit of work to do, but it's a lot less work than I've put into previous attempts. By shrinking the technical requirements we've lowered the hurdles, and as long as we maintain focus on these requirements we can more easily keep perfectionism and productive procrastination at bay.

Next Steps

Now that we've given ourselves a relatively easy path to achieve our goal we can start building! I'll even show you how in my next post: How To Build and Deploy Your Personal Blog With Next.js.