This is what landing on the Hacker News front page does to your usually-dormant site:

In other words, this is what the Windows Subsystem for Linux: The lost potential post caused:

• a ridiculous jump from the usual ~80 visits per day to 6,000 on day one, 9,000 on day two, and 1,000 on day three;
• 200 comments on Hacker News in less than 24 hours and a ripple of discussions in Reddit and OSnews;
• a very insightful chat with a long-term NTFS engineer on general system performance;
• and an incredibly poor conversion rate with only 5 new Twitter followers and 3 new email subscribers.

To summarize: a one-off bump with no long-term engagement effects.

All of these are the perfect excuse to bring back the article you are reading now from the drafts folder where it had been collecting dust since 2017.

I’ve been blogging for a little over 16 years and I have only had a bunch of successful articles. A small part of this is because I have improved my writing skills; a larger part of this is because I sometimes pay attention to what works and what does not; but the biggest part of this is luck, apparently. Writing effort, for example, doesn’t seem to play a role no matter what the content of the post is.

That said, even if luck plays a big role, there are some patterns worth looking into given that some kinds of articles seem to have better chances at getting lucky than others. I want to dive into that analysis here, but before doing so, “what is a successful article?”, you ask? Well, it depends on your perspective. In my case:

I consider that an article has succeeded if it: receives thousands of visits on the first and second days; spurs interesting discussions on popular sites; and/or receives more than the usual handful of likes and reshares on social media.

One consequence from the above is that successful articles should lead to higher conversion rates, with the metrics being new subscribers and followers. Unfortunately, these metrics are disheartening as hinted above and I have not yet found a way to improve them, so I won’t try to discuss them.

Anyhow. Let’s dive in and look at the various types of articles I have published around here and study how they did. I’ll link to a representative subset of past articles in each section and include a little rationale on why I think they performed the way they did—some exceeding expectations, others strongly missing them.

🟥 How-to articles

Let’s start with the least successful articles. How-to articles present, step-by-step, the process to achieve a goal or task, usually technical. These articles are rarely successful at launch because they do not provide incentives for people to share them.

If they are good, however, and if they happen to target the right keywords, they seem to do well in bringing organic traffic over time. Unfortunately, all such traffic is almost worthless from a conversions perspective because the readers won’t stay around: they get the information they were looking for, leave, and never come back again. In other words: the bounce rate is in the 99%.

A few examples:

• How to disable journaling on an HFS+ volumes (2007-04-09)

  Looking at the raw number of visits that this article has received, it’s one of the top posts in this site. But… it has been up for 13 years, so the weekly influx of visitors is actually very small.

• Unused parameters in C and C++ (2015-02-16)

  Similarly to the HFS+ article, this gets a recurrent fair number of visits, but no conversion rates. I find this article a bit better than the previous one because it offers a unique perspective on how to solve a problem, but that doesn’t matter much.

• Get a handle on email subscriptions (2015-06-06)

  This article is a little bit different from the other two in that it talks about a paractical processs and not a technical one. As far as I can tell, this post has gotten almost zero traffic even though it took a lot longer to write than the other two. I’m guessing this might be because of the poor title and the fact that I doubt people research new practices on how to handle large inbound email.

🟧 Product reviews

These are the articles that survey a collection of products or technologies, be them physical or virtual. Similarly to the how-to articles, these seem to work well long-term once they have been indexed by a search engine, but that’s about it: they don’t lead to conversions.

I don’t have a lot of these, but here are a couple:

• Putting a PowerMac G5 to good use (2013-07-15)

  Despite being outdated, this article continues to be one of the most visited posts in this site. But once again, the high visitor volume doesn’t mean much because the visits are spread over many years.

• Rust review series (2018-05-25)

  I’ve played, on and off, with publishing article series in an attempt to get returning visitors, but this hasn’t worked very well. In this specific case, the individual posts of this series attracted some limited attention while they were being published, but that’s about it. Only the final Rust vs. Go article, which touches upon a controversial topic, has done reasonably well over time, but not much.

🟨 Project work stories

These are the articles that explain something I have done at work or on a personal project and that I found interesting enough to share. The format I prefer is to start from a bug report and go all the way to its resolution, often covering some surprising aspect of the affected systems.

These posts work slightly better than the how-to type of articles, but their success relies on how aligned your reader base is with the post’s topic. If you have a lot of followers interested in the topic, the post will do relatively well, but only within that subcommunity. Furthermore, it seems that, even if readers like the content and “like” it, they’ll rarely reshare these posts.

Some very distinct examples:

• Introducing the FreeBSD Test Suite (2013-12-31)

  This is a BSD-related post so I could easily predict who from my followers base would like it and express interest. But it needn’t be this way: I think the topic is interesting enough for wider discussion, but it’s hard to “escape” a subcommunity and make the content amenable to others.

• Darwin’s QoS service classes and performance (2019-03-06)

  An interesting story, I think, because it demystifies some incorrect beliefs on macOS performance. Not a lot of people care about these details though, and of those who do, I don’t think I’ve got many following this blog… so the success results were pretty poor.

• Bazel UI locking (2020-09-01)

  This article combines aspects of the previous two. First, it clearly is about Bazel, so I could know upfront who would like the post. And second, because it’s a bug report describing Bazel internals, there are not that many people that care or know about these. These two combined lead to poor performance.

🟦 Personal stories

These are the articles that explain personal preferences on how to do something, not just the actual, objective process. Things start to get interesting here. These do better in comparison, possibly because they offer a unique perspective on the topic. Unfortunately, they only seem to do better within the circles I’m already part of.

Some examples:

• Task tracking and the Bullet Journal (2014-11-20)

  This article got significant attention, especially from the Bullet Journal community in Google+. It was somewhat unexpected because this was an article “out of the ordinary” for my site as I was covering a topic I had never touched before. As a result, even if the post was “successful”, it didn’t lead to any conversions because the rest of the site talks about unrelated topics.

• Code review culture meets FreeBSD (2014-05-31)

  Similarly to the previous, this did well, but only within the FreeBSD community I was part of. Which is understandable because people outside of the community might not care about the project.

• “Your English is pretty good!”, they said (2015-09-20)

  This is an article I’m quite fond of because of its presentation and content. It is purely a personal story, so it did quite well within my personal circles. And that’s about it.

• Farewell Google; hi Microsoft! (2020-10-19)

  Similarly to the previous, a very well-received article from my direct peers and friends, but not something that is reshareable because it doesn’t make a lot of sense to “outsiders”.

🟩 Opinion pieces

And finally we get to the killer posts, performance-wise. As the title says, these articles present a topic and then go on to describe my personal point of view. It seems that the more polarizing, the better, because they lead to more discussion. I’m not specifically looking to stir controversy with these posts, but voicing an opinion on the Internet is inevitably going to have that consequence.

But there is a big caveat: voicing an opinion, even if controversial, won’t make a post successful. It only increases the chances of the post’s success. I don’t yet know what the magic is that differentiates between the articles that do get popular and those that don’t, but I strongly suspect it’s just luck. Posts need to be shared at the right time and get a sufficient number of votes in a short period of time for them to be boosted to the top of any ranking algorithm.

Here are some of the obvious examples that have worked well:

• Self-interview after leaving the NetBSD Board (2013-06-20)

  This was quite a critical post and a hot topic, for sure. The audience was limited given that NetBSD isn’t that popular, but people love to pile on the “BSD is dying” mantra and will get involved in these posts. If I recall correctly, this article reached the Hacker News front page as well, but its impact in the number of visitors was much less than what I observed over the last few days.

• On Bazel and Open Source (2015-04-14)

  This post raised the few issues I saw back when Bazel was announced regarding its suitability for the open source community. This made the rounds because Bazel itself was—and still is!—a hot topic. And this “gained” me a not-so-pleasant talk with the Bazel lead at the time—although I think it also gave me the necessary brownie points to join the team. 🤷‍♂️

• Compilers in the (BSD) base system (2015-10-23)

  I don’t exactly remember how this post performed at the time, although the metrics I’m looking at right now seem pretty good. The interesting thing about this post is that it’s short and I wrote it very quickly in comparison to others. If you take a look, I suspect it’s the last section that criticises building from source that triggered some readers and sparked the discussions.

• rc.d belongs in libexec, not etc (2020-08-24)

  Similarly to the previous, this post describes a pet peeve of mine that I had never blogged about when I was deeply involved in the relevant communities. In an attempt to flush out some content over the summer, I typed this also rather quickly and let it go live. I didn’t expect anything of it, but it did… pretty well. Again, this triggered some long-held opinions by many, some of which defended this change and others which very much opposed it.

Things that have not worked

Alright, so that’s a good survey of the different types of posts I tried and how they performed.

But… what else have I tried to improve readership rates? A quick search on-line will reveal plenty of advice on how to write top posts. And, of course, I have given those tips a try… but I did not notice a massive benefit. In particular:

• 🗓 A publishing schedule. During 2013, I ran posts a couple of times a week on a predictable schedule, which resulted in the creation of the Series section in this site. Despite the schedule and all the hard work involved in keeping up with it, I did not notice any increase in returning visitors. That might have been because the content was not worth it, or because the presentation was not amenable, or something entirely different. I don’t know.

• 🏙 Images. Adding images to your posts makes them more shareable-friendly because all major social sites will display one of your images along with your post, giving it a more prominent look in their stream. Many of my popular posts from the above lists do not have images, and the ones I added images to did not seem to yield any better results, so your mileage may vary.

• 🔍 Keyword research. Using the tools that Google and Bing offer in this area should help in improving the discoverability of posts. This is probably a good idea for the how-to style of articles but, as described earlier, this kind of posts doesn’t help increase conversions. So… is it worth the bother? It takes effort to research keywords, and if they will only help the articles with the lowest conversion rates, maybe it’s not time well-spent.

• 🛑 Click-bait titles. “Top N ways to blah.”, “My favorite M foobars.”, etc. No thanks. I have tried some of these games when resharing content, but I prefer to steer clear within the posts themselves.

Note that I do believe that these tips are helpful and that they result in better posts and a better site. However, they are necessary, but not sufficient, prerequisites for delivering nicer content. These tips by themselves won’t attract traffic.

So… Is this article going to be successful? I very much doubt it, but you can help change that by engaging with the buttons below!