Writing a tech blog people want to read

 My blog has gotten a lot of traffic in the last few months1. Here’s what I think I’ve been doing that’s working, and a few things that have been surprising to me. It’s a bit self-indulgent to write a meta post like this, but that’s what blogs are for.

What I write about and why

By far the most popular things I write about are my thoughts on how to ship projects, what makes an engineer strong (or weak), how to navigate company politics, and so on. In general, I think the recipe for a popular post is to have a clear opinion about working in tech that many people disagree with. That means that people might learn something from the article (or at least that discussion about it will be lively and interesting).

https://hackmd.io/@alexaa34/Bko3ogX0-x

https://medium.com/@alexharris59600/writing-a-tech-blog-people-want-to-read-eef1b11d23eb

I don’t think people want to read opinions that aren’t controversial (e.g. “unit testing is good”). I’d also avoid topics that have been rehashed a thousand times, unless you’ve got something new to say about them (e.g. “dynamic vs static types”). If you’re just writing posts to get things clearer in your head, of course write about what you want. This is just my sense of which topics people are interested in.

I suppose you could try to exploit this by pretending to have maximally controversial opinions. But I don’t think that would be very fun or very worthwhile. Tech blogs don’t make any money, so there’s no real value in just driving up the number of eyeballs. The real value of a technical blog is to express my own opinions as clearly and widely as possible, so either:

• I can read feedback from people who might cause me to change my mind, or
• I can encounter people who share my mindset who I can talk to/work with/etc

For me, having an actual tech job that I take seriously is essential. I get most of my ideas for blog posts by just writing down the things I’m already thinking about as a part of regular work. I don’t sit in an armchair and think “what does it mean to be a strong engineer”, I encounter strong engineers in my regular work and (naturally) think about what they’re doing differently.

I touch on the same themes fairly regularly - the importance of being agentic and tactical, how companies value results, what makes engineers strong or weak - but I think that’s fine. Coming at the same ideas from different angles typically yields new insights, and from reading comments on my posts people take a very wide array of things from them. If I ever start seeing comments like “didn’t I read this post before” I’ll probably change it up.

Tone and style

I try to be as clear and casual as possible. This is largely influenced by grad school in analytic philosophy, which aims to be much more straightforward in tone than other liberal arts fields. In terms of technical writing, Dan Luu and Paul Graham’s blog are more or less the kind of style I aim for. I don’t know if this is particularly good or bad - I’ve seen many successful tech blogs with a more colourful style - but it works for me.

One thing I explicitly do differently from philosophical writing is I try not to include too many caveats. For instance, I’ll say “companies reward pragmatic engineers” instead of saying “in my experience, I’ve seen companies reward pragmatic engineers, but every company operates differently so it’s hard to say anything for sure”. If you include no caveats, you’ll sound too dictatorial, but including caveats all the time makes articles too awkward to read and buries your actual point. Sensible readers will know that of course you’re speaking from your own experience, and other readers won’t pay attention to the caveats anyway.

As part of that, I try to be as upfront as possible about the quantity and nature of my actual experience. I link my resume up the top of the blog, and I try to be concrete when I talk about years of experience or the size of a codebase. This is sometimes painful. Every popular post gets a handful of Hacker News comments being explicitly critical about the details of my career path. But since I’m writing in a fairly caveat-free style, I think it’s important to not mislead people into thinking I’ve had 30 years of experience in all FAANG companies (instead of 10 years of experience across two big-but-not-quite-FAANG companies).