Is your new year’s resolution to start a tech blog? But do you worry that every subject you’ll write about has been covered a million times before? You’re right, it probably has, but that isn’t a reason not to write about it (for example: the message of this blog post has been covered many times before!). I always write my blog posts for an audience of one: myself in the future. I use blog posts to record my knowledge or opinions on a subject first so that I have a record of it in the future. If anyone else reads the post and gets value out of it then this a bonus!

Is there a technology or library you work with everyday and could use it blindfolded? This is prime material for a blog post.

For example, I changed my job last year to work with a React codebase which uses styled-components. Great! But this means that I’m forgetting everything I know about Sass that I learnt in my previous job, because I’m no longer actively using it. There’s always a chance I’ll end up working on another project that uses Sass in the future, or it might be the best tech choice for a new project. At that point I will wish I had a personal cheat sheet on Sass. Examples and best practices of how I wrote and used Sass would jog my memory and save me time. Formatting it into a blog post would make it easier to digest compared to a page of notes.

As a developer, your role and responsibilities can change rapidly as you move teams and projects. Before you know it, you’re no longer using that framework/library/tool you were once so comfortable with. I encourage you to record this knowledge now: your future self will thank you for it. If you publish it on the internet then it may help other people too!

And even if you don’t use the blog post as a reference yourself, it can be interesting to measure how your skills have progressed since you wrote it.