What would I call it? Where would I host it? What domain would I use? What would I write about? How often would I post? Should I try to monetize it?
All these questions and many other small things put a stop to my “efforts” every time. But I guess it just wasn’t the right time.
But now it is.
The Occasion
I recently found myself in need of a tool to list the contents of nested archive files. (More on this in another post soon.)
After a first attempt in Python, I soon restarted the project in Kotlin. I worked my way through the initial features to an MVP (minimum viable product), all the while relearning old stuff and learning new stuff about Kotlin and its ecosystem. As I went along, I noticed some really cool things, and some rather annoying ones.
A few days into this, I realized that this might actually be worthwhile material to share with other people. The things I had noticed about the Kotlin ecosystem and the code project itself would serve well for opinion pieces and mini tutorials, respectively.
Coincidentally, I had some spare time on my hands.
And so I got to work.
The Method
In all my previous attempts at starting a blog, the larger and smaller questions mentioned above had put a stop to my efforts at some point. Therefore, I decided to take a more methodical approach this time. As in agile software development, I am tackling this blog in an incremental way.
First, you define an MVP, a minimum viable product. This first iteration of any product or project must have the two titular properties: it must be viable, but should have minimal scope to achieve this. Viability means that the product must be able to achieve its core task.
Once the MVP “hits the market,” as it were, you can iterate on it and improve things over time. Ideally, the product remains both available and viable while you implement and deploy these changes.
So what did I define as my MVP?
The core task for this project is: it must enable me to publish blog posts for other people to read.
Based on this, I worked out the following features that I wanted to have at launch:
- Most important: Content. I need at least two posts to be available at launch.
- The blog needs to be hosted somewhere on the internet (i.e. I need a hosting provider).
- Since I don’t want to manually write plain HTML, I need some sort of blogging engine. (This could be a full CMS, a site-builder, a static generator etc.)
- The blogging engine must let me write content in markdown, and it must support syntax highlighting for source code.
I also didn’t want the readers to see only a white page with black text in the browser’s default font, hosted on some deep URL. So I stretched the “minimum” of MVP a bit and added the following features to the list:
- I need a custom domain for the blog, to make it easier for people to remember where they can find it. (The blog’s URL would also be annoying to change if—against expectations—I should get some incoming links.)
- The blog needs a basic theme with a simple and clean reading experience.
- The blog needs a preliminary name, to be used in the page header and
<title>element.
Consequently, several things are left to be adjusted and improved with time, such as:
- A final name (and possibly a logo or wordmark).
- Theme and design customizations, adding branding and improving usability, legibility, and accessibility.
- Customizations to the blogging engine and tweaks to the workflow.
- An “About Me” page and similar bells and whistles.
As you know, content is king. But what is actually most interesting to a nerd like me? The itty-bitty, nitty-gritty technical details of DNS configuration, editor setup, theme and blogging engine customizations, and so on.
So, good thing I wrote down what needs to happen first and what needs to wait. Otherwise, I’d still be fiddling around in some config file instead of writing these lines.
Curious what technologies and platforms I ended up choosing? Find out now in the next post!