Resisting the urge to rewrite the website

Do you have your own website or blog? Or maybe you have considered starting one but went down the rabbit whole of building your own tooling and giving up before publishing?

Jamie Thingelstad invited us to write about renewal for this month’s IndieWeb Carnival:

The theme of renewal resonated with me because it can apply to so many things. Renewal could happen in a day or a year. It could apply to your relationships, yourself, your digital world, whatever you want. We can point a desire for renewal anywhere we like.

I agree with Jamie’s first observation. I have been bouncing around half a dozen topics I could write about but I decided to write about the often observed dilemma that (especially) we techies often run into: how to resist the urge to rewrite the website every time you start writing a new blog post.

I used to be guilty as charged but as I now write this blog post on the website that is the same site that it’s been since 2018 – at least depending on what’s your stance on Ship of Theseus as everything has been rewritten bit by bit with pretty much no lines of the original 2018 code left – I’ve gotten over the urge and it has enabled me to focus on writing.

Yesterday I had a lunch with a friend where this question popped up again. Inspired partly by this blog, my friend had started to build a blog of his own but were still in the Technical Tinkering Phase™.

Mindset

I guess for us techies especially, the desire to tinker with the site comes from having a deeper interest in writing code than writing prose.

I have found a nice balance for myself over the years. I love writing and the impact it has in helping me meet new people and get into discussions with amazing people from all around the world. But I also love tinkering with my website to learn new things and to make the site and its tooling even better suited for my own needs.

Another aspect is the sparse frequency of posting. When you write a blog post once a year, the old site built a year prior starts to feel old and maybe we start considering that as the reason for why we didn’t write any more posts. These days as I publish blog posts weekly and often multiple times a week, I don’t have time to break the site during development. I need to have the page in a shape that allows me to write and publish any day and we all know how hobby projects end up being abandoned as other parts of life like work or family take over.

I have half-jokingly been entertaining an idea of building a new blog: for every blog post published, you get to add one new feature. The first blog post needs to be written in a plain txt file and deployed as-is to a server. With the second post, you can choose to add something you want: maybe a bit of HTML navigation to be able to have links between the blog posts. The third post could come with Markdown support so your posts are not plain text anymore but rendered into HTML. And so on.

The idea would is that you get to “earn” feature development by writing blog posts. If you want a fancy site with bells and whistles and good tooling, you have to write and publish a lot. That way, you cannot get lost into the rabbit hole of new shiny feature development at the expense of writing.

I know some people do similar things when they are prepping for university entrance exams or writing their thesis where they reward themselves with small treats after every N pages of progress. Here, the treat is that you get to write code.

Technical solutions

There are couple of things I’ve done with my setup that helps me with this problem.

I have separation of content, CMS integration and website engine. I can write and prepare my blog posts for publication in separate branches from any technical changes. I use Notion as my CMS but unlike many others who fetch the posts on build time, I fetch them manually separately. This means my website folder always contains the entire site and can be fully rebuilt and I can make technical changes even if Notion would be down.

An intended side effect of this workflow is that I can develop my website (layout, styling etc), my CMS integration tooling (a series of CLI tools that fetch the content from Notion) and write my content all separate from each other. I don’t have to make backwards compatible changes because I don’t need to refetch old things from CMS. This lowers the threshold for making small, incremental changes to any part of my stack.

I use different tools for writing and coding. With Notion (and previously Ghost) as my CMS, I don’t write in my code editor. I initially did this because I dislike the experience of writing Markdown in code editors but now I like it because it separates writing from coding. I can write my blog posts on my iPad when I’m in the library or local pub and at that time, there’s no way for me to tinker with the tools or the website itself.

I use a pull request workflow as my scheduling tool. When I’m done with a blog post, I fetch it from Notion to my repository into a new Git branch and make a pull request. With my static site, this enables me to separate writing and publishing without too much of a hassle. In the title of my pull request, I write when I plan to publish it and then on the day of publishing, I open GitHub on my mobile and hit merge and it’s all there. I can make the final publication without having access to my full coding enviroment for the site.

With a workflow like this, I don’t tend to get the temptation to do a lot of technical changes when I’m in the writing mood. If during the time when I pull the new post from Notion and prepare it for a pull request I get inspiration for changes, I can implement them in separate branch and deploy them independently of publishing my writing.

All of this encourages small, incremental changes. Even when I’m in the mood for larger implementations or changes, they never disrupt my writing and publishing because I can always do them independently in a different branch. Any changes to layouts and such will automatically then get applied to all the old content and any changes to CMS integration tooling only needs to work with future posts (and I can use the old tool until the new version is fully operational).

While I’ve managed to learn how to resist the urge for big rewrites that disrupt writing process, I still make a lot of improvements to my site and its tooling. One of the reasons I love having my own website is that I’m in full control and can choose to build new things purely based of my own interests and aspirations. Almost every month, I deploy something new to the site or improve my tooling. A lot of them go mostly unnoticed as changes because I’m now able to make small changes continuously rather than having to rewrite the entire thing everytime.

Join us at the Carnival

If you have a blog (or have been thinking about starting one), join our jolly crowd at IndieWeb Carnival. Each month, a volunteer from the community hosts the festival by choosing a theme and writing an introduction post. Then anyone who has a blog can participate by writing a post on that theme, posting it to their blog and sending a link to the host.

At the end of each month, the host gathers together all the entries and write’s a round-up post so you can find new blogs and read others’ thoughts on the topics.

I’ve been participating since the start of 2024 and have been really enjoying it. I have gotten to write about topics that I otherwise would have not spent that much thinking about and I’ve found many interesting new blogs through it.

This post has been syndicated to IndieWeb News.