In a recent HN thread I came across the following comment:

For tech-heavy programming/operations how-to or bugfix content, Stack Overflow killed those for me.

– shireboy

I can absolutely relate to this. There are many things I didn’t write about because a complete SO answer, with several alternatives, already existed.

But I’ve realized that there is room for technical content that describes solutions based on experience with tools or with a very specific use-case.

This type of content is not for the same target audience as SO. It’s for a more experienced dev who is looking to solve a very specific issue. The more experienced dev is less likely to post the question in the first place and more likely to hack a solution of their own.

It would also be too niche for Stack Overflow because it takes a lot of time to research and is often dependant on context.

Here are some examples.

Solutions that are pieced together to fit a very specific use-case

There are often situations where Stack Overflow answers offer only individual pieces of the solution and you must then piece them together to fit your use-case.

With experience, you’re better able to put those pieces together.

For example, my blog has had thousands of hits on a 5+ year old post describing how to set up Active Directory and database login in parallel on Rails. When I wrote it there were several answers on Stack Overflow on how to set up LDAP login but none of them covered my entire use case.

Solutions or things you learned because you’re able to read the source or the docs

Reading the docs and the source code are learned skills. If you’re able to do that, and you come up with solutions, or learn interesting things, then that’s worth writing about.

For example, I copied the compatibility list for mysql2 gem versions and MySQL server that was only found on the bottom of the rdoc page of the mysql gem in point list form that I had missed at least three times previously.

Solutions you came up with because you are skilled enough to override or extend part of a library

With experience, you can come up with solutions that modify libraries. This is helpful because it means not having to handle each case individually in your code. Instead, the library would be able to consistently handle them.

In some cases, you might even be able to contribute to the original library.

For example, I wrote about overriding preform for carrierwave_backgrounder gem.

Quirks that you discovered while using tools

While getting more experienced with tools you’re bound to discover things that are less obvious. They might be documented but have side effects or aren’t entirely intuitive. Others might not be aware of these things and might think there’s something else wrong with their code. A classic (but well known) example of this is JavaScript’s atob and btoa.

For instance, I found out that MySQL cannot parse yyyy-ww date format without a day and at the time that was not explicitly mentioned in the docs. Even though the docs do mention that now I still get occasional hits on that post.

Better tutorials for new things

When new tools are released, tutorials for beginners often aren’t all that fleshed out. So, if you’re into experimenting with new things, you can also write better tutorials for them. This might be full-fledged tutorials or just specific pieces.

For instance, when I experimented with Flutter, the tutorials for accessing shared preferences and message passing were not very clear. They combined several different topics into one tutorial and missed some common edge cases. So, I wrote simple guides on accessing shared preferences in Flutter and native code and message passing. Over the past two years they’ve had thousands of views.

Your own notes on how to do things

If you keep forgetting something simple, chance are others are too. So, there is value in writing down things for your reference.

One of my first posts was how to add a swap partition to Ubuntu 14.0 and while it might not be the most popular of posts it was still very valuable to me because I always knew what to refer to.

Patterns or best practices that have worked for you

As you get more experienced, you’ll come up with your own ways of doing things that might not be the accepted best practice but work for you.

My examples of this are putting rails scopes nearer to where they’re used instead of on top and the “actor model” pattern.

So, write

So, if you would like to write, there’s plenty of content you can create based on your experience. Writing about very specific situations might mean that a question never even ends up being posted if you got there first.

Interesting comments from Hacker News discussion

dspillett pointed out that another good use of blogging is as practice for communicating more clearly.

LandR said:

I write technical stuff to convince myself that I understand a topic. I’ll write a tutorial for myself on it, and during this, ask questions that someone who doesn’t know it at all would ask, sometimes I don’t know the answer so I need to research more.

e: Local tech

Another useful thing to write about is tech that’s very local and that might not end up on StackOverflow. The technical details of integrating with APIs of local companies or government services immediately comes to mind. For instance, I wrote about a Malaysia payment processor.