A very relaxing refactoring

Posted on

After several days of legalese and paperwork, I took a few hours last week to write some code again. I shared a lot of short code snippets on Twitter recently, which are hard to find on there now. Twitter is not a medium made for later reference. To make these tips more useful, I wanted to add them to my own site. On there, I have full control over the presentation and can make them searchable.

With the blog and my newsletters already on there, the fire tip code snippets would feel right at home. Gatsby already takes a bunch of Markdown-files and transforms them to static HTML. Adding another type of content could be as easy as copy and paste with a few small adjustments.

Now, that would not make the code any easier to work with. Copy and paste is rarely the best solution. Instead of taking this “easy” way, I took the long configuration and refactored it. Because of my previous sloppy development, there was a lot of duplication in there. I also wrote this code back when I did not have a clear vision for what I wanted the site to do. I learned a few new tricks since then, which could make the code even easier to work with.

In a few hours, I had applied my new skills to the setup of my site. After this refactoring, my configuration was down to 40% of its original size. It still does exactly the same, but better. Adding a new content type, such as the fire tips, is a bit easier and faster now.

That is the only benefit I got from this. Yes, adding new content types only takes one minute now instead of five. Cool cool cool. While this was a fun exercise, the benefit I got was minor. Instead of messing with the tools, I could have created something that is of real value to my readers.

I made this decision deliberately, knowing it was a low-impact activity. Those are fine to do, as long as we recognize them as such. Doing only things that provide no tangible benefit is dangerous business. Letting bad code decisions from a few months ago pile up is equally disheartening.

The best teams I worked in found a healthy balance between these two. Letting people refactor old code that is difficult to work with can show them how much they have grown. Seeing your own progress through an impressive Git diff can be a powerful motivator. Don’t cheat yourself or your coworkers out of that opportunity for the sake of piling bad code on top of more bad code. The occasional relaxing refactoring is rewarding and costs very little, if done right.

Grid overlay