Dan’s been in the tech space for over 20 years – a former CTO, AWS certification instructor, engineering manager, devrel leader, and developer – and he’s been writing from all those different perspectives.

We caught up with him to share his experiences and advice. Over to Dan…

Why did you start blogging – and why do you continue?

I started blogging because I wanted a “place on the internet” where I could write down what I was learning.

I continue blogging because it helps me in a number of ways.

• It helps me understand what I think about something.

• It helps me scale when answering questions. I can write down the answer one time and share it with many people.

• It helps me build my public profile because the things I’ve learned and the wisdom I have gained over the years aren’t locked up inside my head.
  

What has been the most surprising impact of blogging for you?

Surprising things have happened due to blogging, for sure. Once, I was googling around for an answer to a question I had and I stumbled across an old blog post of mine. That was a surprise. Another time, I was in an interview and the interviewer asked me about blog posts I’d written. But the most surprising impact of blogging is different than some of the surprising events that resulted from my blogging.

The most surprising impact of blogging was the doors it opened up. When you don’t just say “oh, I’ve done that” but instead can say “oh, I’ve written about that, let me send you the post,” it’s a very powerful message. Whether that’s short-term contracts, which have happened to me when someone found my blog, or longer-term career options. The years I’ve spent in devrel are, I believe, due to the fact that I had been blogging for over a decade before my first developer relations job. My blog has impacted my career trajectory for the last decade.

What blog post are you most proud of and why?

In 2024, I wrote a post about requesting a change in my role. At my current job, I was very clear that I did not want to manage people. I wrote about that and how I failed to have that difficult conversation with past employers.

This post was more about being professionally vulnerable than it was about technical difficulty. I’m proud of this because it took lessons I learned over my years and coalesced them into a post. I hope that it saves someone else from the anguish I had and the frankly dumb career moves that I made because I was afraid to ask for what I really wanted.

What post was the most difficult to write and how did you tackle it?

It’s hard to pick the most difficult one, but I wrote a post about Terraform and different environments.

This was a tough one for me because of the technical depth and the detail that was needed to make sure this post was correct. And, to be honest, the tediousness of retesting terraform applys over and over again. I tackled this by standing up a GitHub project and sample AWS account and testing the code over and over and over again.

When you are writing deep technical how-tos, testing like this is boring but critical. Even one wrong fact can throw off a reader new to a technology or area.

Any lessons learned that you want to share with the community?

• Don’t over-focus on your tooling. I see a lot of people who focus on finding the perfect static site generation framework or twiddle with their blog’s look and feel or seek the perfect comments plug-in. Those are all excuses to not write! But the whole point of a blog is to take squishy thoughts from your head and put them into precise verbiages. This is why whenever someone asks how to start blogging, I always say “just use WordPress.” The tool doesn’t matter; the time and focus on writing is what matters.

• Make sure that you share your work in communities (that make sense). This means that you have to join and participate in such communities. Otherwise, you are just a drive-by poster and who wants to be that. You can join slacks, you can join discords, you can join more public online communities like Reddit forums or Hacker News. Don’t share only your work. Have conversations and do other work that helps those communities thrive. But if you’ve written something worthwhile, you should share it. Otherwise, it won’t be discovered.

• Take on blogging challenges. This could be doing something like 100 days of blogging or submitting to a topic-focused advent series (these tend to happen towards the end of the year). Find ways to do more with your blogging. Challenges are a fun way to do that.
  

Your advice for people just getting started with blogging?

I wrote a short blog post about this of course, but my advice for people just getting started is: blog for yourself.

If you write a blog to capture your thoughts at a certain moment in time, to illustrate something you’ve learned, or to help your future self, you’ll be thrilled with your blog. If, on the other hand, you write a blog to become famous or to get a job or to make money, you won’t be happy. Picking a goal that’s in your control will make you happier.

A few blogs that you particularly enjoy?

I love the Rands in repose blog, the old new thing blog, and swyx’s blog. These all cover different areas of technical topics (engineering management, windows intricacies, wide-ranging thoughts on AI and devrel), but they all have style and I learn something every time I read one of them.

Anything else you want to add?

I mentioned earlier the importance of showing your work in communities. I’ve been an active member of Hacker News, an online link and comment-sharing community. Whenever I join a community like that, I try to keep sharing my own posts to about 5 or 10% of my interactions. I like to seek out other interesting posts from other communities and friends. I like to share those. Sharing the wealth is a great way to help other people at extremely low cost to yourself. I guarantee you that if you share someone’s post and it trends on Hacker News or gets extra visibility that it wouldn’t otherwise have had, they’ll remember that.

Blogging is a fantastic way to prototype writing a non-fiction book. Anyone who wants to write a book should write 10 titles of blog posts on the topic and then proceed to write those 10 blog posts. If either of those two steps stymy you, then you are probably not interested enough in the topic to write a book.

I took a blog that I started in 2018 and after I wrote a couple of dozen blog posts, I turned into a book proposal. That’s how I would approach any future technical books because it not only lets you gauge your interest, as you share or publicize the blog, it also helps gauge other people’s interest. A book is a titanic endeavor and I would not want to do it unless I was sure that both my own interest and other people’s interest in the book topic made it worth my while.

Cassidy started blogging her first semester in college and has kept at it ever since. Readers get dev tips mixed with musings, both professional and personal. She takes blogging up a notch in December with Blogvent and maintains a steady weekly cadence for her wildly popular newsletter, Rendezvous with Casidoo. Oh, and she does videos too; just see her recently relaunched YouTube channel.

She recently popped into the Overcommitted community (a great group, btw), and we couldn’t resist asking her our usual writerly questions.

Over to Cassidy…

Why did you start blogging – and why do you continue? I think the easiest one-liner response to this is: I like writing! I’ve been blogging on and off for almost 20 years. My current blog doesn’t actually have all of my writing in it (yet?) because sometimes it’s on my own domains, sometimes for companies, sometimes just out in the open. I’ve written a bunch over the years. I get a lot of value from writing things I learn (because I often run into problems over and over again, I’ve run into my own blog posts while debugging something multiple times), and so I try to do it regularly in case it might be able to help someone else, as well. On my newsletter side, I started it in 2017 as a way to more consistently write and share. It’s turned into probably my most important project I’ve taken on in my career, with several thousand subscribers and an issue that comes out every week!

What has been the most surprising impact of blogging for you? Blogging has unlocked so many opportunities. I’ve made friends, joined communities, gotten jobs... it’s wonderful. “Learning in public” and also being vulnerable in a space that I own on the internet has been really valuable.

What blog post are you most proud of and why? You know, that’s really hard to say. I think I like a bunch of posts for different reasons. I like this one about React Children because it’s fairly snarky. I like this one about FFmpeg because it was a really interesting technical problem. I like this one and this one about my birth experiences, because I wish those resources were available to my past self. I like this one about my Micro Journal and this one about a laser cut wooden phone project because the results were physical products I actually use. I can’t pick!!

What post was the most difficult to write and how did you tackle it? I genuinely can’t think of one. I did write about coming up with blog topics recently. I think it depends on my brain space if a post is difficult to write or not.

Any lessons learned that you want to share with the community? AND Your advice for people just getting started with blogging? Just write. You care more about your blog and your content than any other person ever will, so don’t worry about it not being perfect. Just write. Your voice matters, and you’ll only get better the more you write!

A few blogs that you particularly enjoy? Anything else you want to add? My favorite non-coding-oriented blogs I enjoy these days are:

• Eleanor Konik

• Robin Sloan

• Anything Marcin Wichary writes (sometimes on his blog, sometimes on his Shift Happens site)

They are definitely “tech-adjacent” but from a very cool, human lens!

VHDL’s crown jewel;

pattern: non-markety product perspectives

Turns out the difference between VHDL and Verilog is not “just syntax!” VHDL makes sure that events that happen concurrently in a “zero time” window are still simulated in a deterministic way. And determinism is a thing to be vastly appreciated in a hardware debugging world.

When agents have wallets

pattern: non-markety product perspectives

An interesting projection on what the world is going to look like when we start giving AI agents pocket money.

Hypothesis, Antithesis, synthesis

pattern: non-markety product perspectives

Introduction to property testing, along with an open-source multilingual tool to put it in practice.

What happens with open source in the age of AI?

pattern: thoughts on trends

Welcome to March 2026: the month of questioning the Open Source paradigm in the age of AI. This one is quite an optimistic take on the topic, for a change!

How we hacked McKinsey’s AI platform

pattern: bug hunt

Terminator-style white hat hacker story on how an autonomous agentic AI job penetrated McKinsley’s platform and leaked all its data. The future is now.

AI and the Ship of Theseus

pattern: thoughts on trends

A philosophical take on GPL-ish licenses in the era of AI. Free Internet dramas inside!

Nobody ever got fired for using a struct

pattern: lessons learned

Valuable tips for everybody struggling to squeeze a bloated database row into a structure in memory, while not keeping 150 NULL values around at all times.

Never snooze a future

pattern: lessons learned

Words of warning against a novel problem that emerged from async Rust -- cancel safety. Rule of thumb: futures can be implicitly “cancelled” by just not ever polling their status anymore, so it’s important to never leave important (or even worse, temporarily invalid) state hanging in them.

Read more on writethat.blog

That instinct has earned him over a million regular readers, making The Pragmatic Engineer the top newsletter in tech. His focus on long-form analysis, original research, and insider perspectives sets it far apart from all the LLM remixes and Hacker News pandering.

Gergely’s path (engineer> engineering manager> professional writer/publisher/podcaster/conference organizer) is unlike most. So we thought we’d ask him an expanded version of our usual writerly questions.

Over to Gergely…

Why did you start writing – and why do you continue?

I started a blog when I was still in university because a lot of devs I looked up to all had personal blogs. When I got my first job, I wrote down interesting learnings I came across. It did not have many readers - but it helped me reflect on some of my learnings.

After a while, I got annoyed that my blog was a mish-mash of all kinds of posts, and no clear topic. The blog post How To Achieve Ultimate Blog Success In One Easy Step by Jeff Atwood (cofounder of Stack Overflow) suggested that if you want a successful blog: write regularly, for an extended period of time. I took this inspiration, registered the domain “pragmaticengineer.com” and started to write one post per week. I managed to do it for two months, before throwing in the towel.

Note: Jeff also shared his writing experiences here.

What got me back to this blog is one of my early articles got submitted to Hacker News, and got so much traffic that crashed my shared hosting. I realized “huh, something I wrote 5 months ago resonates with people and starts conversations?”

From there on, when I thought I learned something interesting (or observed something interesting) I blogged about it on this blog.

What has been the most surprising impact of writing for you?

A few things:

• Meeting people who think similarly as I do and becoming friends – purely thanks to writing. Charity Majors is one such example. Unbeknown to me, a person sent me and Charity the same question, and we both blogged about it independently. Our views came out… very similar (here’s Charity’s take, and my take on measuring individual developer productivity.) And it’s how we started talking, and later met as well.

• I learned more – whenever I wrote things down! I retain information better when I write about it. This was pretty surprising. I guess it makes sense: when writing about it, I think about it a lot more.
  

What article are you most proud of and why?

Two stand out:

Distributed architecture concepts I learned while building a large payments system. This was the first article where I spent months learning about a topic (I felt pretty lost with distributed systems when I started working at Uber), then another ~1-2 months writing up what I learned, hoping that it would be useful for others.

And it was the first time ever that it felt worth it putting in all this time writing it all up: the response was phenomenal, and developers translated in Japanese and Russian as well, further spreading it (it was also the first-ever article I wrote where I got requests to translate it.)

The Trimodal Nature of Software Engineering Salaries in the Netherlands and Europe. This one article helped hundreds of people get better jobs they were not aware of, and it was the catalyst to have at least a dozen companies I know of increase compensation bands by 10-25% a year after I published it.

What article was the most difficult to write and how did you tackle it?

The Trimodal Nature of Software Engineering Salaries in the Netherlands and Europe – This was the first time ever I did a post with a lot of research. I wasn’t sure that I did research the “right” way, or that people would take it seriously when it came out.

Turns out when there’s zero information on a topic (in this case, Big Tech salaries in the likes of the Netherlands), some information is always better than none!

Any lessons learned that you want to share with the community?

It’s hard to publish the first few blog posts or articles: but it gets easier, over time. If and when you develop a habit, it happens a lot more automatically.

I have a simple system where I take notes when I get an idea about something I could write about. When I feel like writing, I go through these!

Your advice for people just getting started with blogging?

Counter-intuitive, but pay for a basic service where you write your blog on! Paying even $10/month reminds you that you should write something else that money you pay goes nowhere! Honestly, it’s hard to get into the habit of writing regularly, so some external “push” can help.

Also, consider that it feels like blogging is less popular these days: which is why it can be easier to stand out if you do start!

A few blogs that you particularly enjoy?

Simon Willison

Charity Majors

Sean Goedecke

Note: Simon, Charity, and Sean also shared their writing experiences here.

How has the importance of writing shifted since you published “Undervalued Software Engineering Skills: Writing Well” and “Becoming a Better Writer”?

With AI tools, I feel it should be easier to produce writing that looks good. You can also ask AI to edit your work, critique it, and so on.

I’m not sure I see that much more or better tech blogs though - which is strange!

One trend I notice is more longform writing is happening over newsletters (mostly Substack), and on social media (e.g. X articles.) I also see engineering leaders do more opinion pieces on some of these platforms than before.

Writing is still an underrated way to connect with people who either work on similar stuff as you are, or think similar to you do.

You’ve pivoted from engineer to professional writer. What’s similar now and what has changed?

What’s different is I now have strict deadlines to publish: twice a week, for my paying subscribers! Nothing is as motivating to finish an article like a deadline that cannot be moved! My writing cadence is up thanks to this self-imposed constraint.

I now write much less about my own experience (which was the only thing I wrote when I blogged, before The Pragmatic Engineer) and most of my pieces are based on research, interviews or analyzing events.

Personally, I greatly appreciate blogs where someone shares hard-earned experience (something they did over months, sometimes longer.) My nature of writing is that I often get people to talk to me about these, then I write them down to share.

What’s your take on blog writing in Big Tech? Do you think the process is too prohibitive? Any insights into best practices or antipatterns?

Personally, I stayed away from writing for my employer, because of how painful the process was. Also, every time I wrote on a company blog: within 3 years, it got removed/deleted.

I found it easier to write about my own learnings at the company, but omitting business-sensitive details. This is a much easier way to start.

Writing on the company eng blog can give good visibility to you externally, and doing it once can be educational. I would suggest you copy the blog and publish it on your own domain – expect that corporate can and will delete it in a few years’ time!

What are the best and worst aspects of running The Pragmatic Engineer?

The best aspect is talking to far more people than I had access to when I worked fulltime as an engineer. Both in terms of time, but also getting responses from a lot more people.

An aspect that is surprisingly challenging is the pressure to publish both things that are timely, but also well-researched. Good research takes time: but by the time it is done, it can get out-of-date. What is timely – a trend, a technology or framework getting popular etc – on the other hand is hard to go into meaningful details without putting in the time and work to research.

Having too many drafts in progress (researching) can get overwhelming as I feel some of them could get out-of-date by the time research is done. Working only on one timely topic at the same time can make me worry I won’t have any other topic researched in, say a week or two’s time.

Finally, “scaling” The Pragmatic Engineer is surprisingly difficult - and maybe this is why it is as popular as it is? People are surprised to learn that it’s just me working fulltime on it, and Elin part-time. That’s all we are! After four years, I’m now hiring one more tech industry analyst to help with research.

***

Note: Gergely’s work is featured throughout Writing for Developers.

Murat is currently principal research scientist at MongoDB Research, ex-principal applied scientist at AWS, and ex-professor at SUNY Buffalo. He’s known for systems research and algorithmic work across domains like cloud computing, distributed databases, distributed consensus, wireless sensor networks, fault-tolerance, formal methods, and self-stabilization. If you’ve worked with hybrid logical clocks or WPaxos, there’s a good chance you’ve encountered his contributions.

Murat blogs prolifically at https://muratbuffalo.blogspot.com/ (and also on a shiny new newsletter). Although he writes mainly for himself, millions have discovered his blog and faithfully follow it for a steady dose of distributed systems insights.

Let’s learn a bit about Murat’s blogging experiences and advice…

Why did you start blogging – and why do you continue?

In 2010, when I was a professor, one of my colleagues in the department was teaching a cloud computing seminar. I wanted to enter that field coming from theory of distributed systems, and later wireless sensor networks fields. So I attended the seminar. As I read the papers, I started blogging about them. That is how I learn and retain concepts better, by writing about them. Writing things down helps crystalize ideas for me. It lets me understand papers more deeply and build on that understanding. The post on MapReduce, the first paper discussed in the seminar, seems to have opened the floodgates of my blogging streak, which has been going strong for 15 years.

I think a big influence on me has been the EWD documents. I remember the day I came across these as a PhD student. It felt like finding a treasure, a direct gateway into Dijkstra’s brain through his writings. As I wrote in this post, Dijkstra was the original hipster blogger. He was blogging before blogging was cool. “For over four decades, he mailed copies of his consecutively numbered technical notes, trip reports, insightful observations, and pungent commentaries, known collectively as EWDs, to several dozen recipients in academia and industry.” The EWDs go till 1318. I have a total of 799 posts in my blog as of today. I still have about nine more years to catch up with his sheer post count.

Why did I continue blogging? I continued because I like writing. While writing, I become smarter and more creative. One thought leads to another, one question opens a new investigation, and that leads to an insight. I even sound smart (if I may say so) when I read some of my old posts.

Writing is now a deeply ingrained habit. If I go without blogging for a week, I feel bad. It feels like my creativity got clogged. I am not going to compare myself to artists, but I do feel uneasy if I have not exercised my creativity for a while. My blog became a good vessel for creating and sharing ideas, so I can get them out of my system and make room for new ideas.

What has been the most surprising impact of blogging for you?

Around 2016-2017, I started running into people at conferences who followed my blog, and that surprised me. I had very few page views until then, and I never cared about page views. At first, I thought this was a fluke, but it kept happening more frequently. I was not expecting many people to read my blog because I write for myself first, and I had no expectations that others would read it. (I think this is the difference between intrinsic motivation versus extrinsic motivation. I get the reward while writing the post itself and learning through it. Of course, I am very grateful when people read these posts, and very happy when these turned out to be helpful.)

Related to this, I was surprised by how much developers enjoy reading and following my research paper reviews and summaries. Research papers are often not written to be accessible. They are written to satisfy three reviewers. And consequently, in some parts, the papers get overly defensive. In others, they become pompous and oversell to impress. Knowing how the sausage is made, I think I was able to interpret what was going on and cut to the main ideas and contributions better and translate them more clearly. There is still a large gap in translation and exposition, and I hope more people step in to fill it by blogging.

Another big surprise was how often I refer back to my own blog. Referring back to my posts lets me quickly cache the concepts again. Because I strained my brain while writing them in the first place, reading them later refires the same neurons and helps me reconstruct that state of understanding quickly. In that sense, my blog started acting as an external memory.

I also started pointing my PhD students, and later other people, to my blog. It is an easy and fairly reliable way to transfer knowledge because I package these advice posts neatly for consumption. Here is a snapshot from 2020, and I have written many more advice posts since then.

I actually just realized that I already wrote about why I blog, and I can refer people to that post for more insight into my thought process.

What blog post are you most proud of and why?

It is hard to choose. I think I am proud of all of them, simply because I like having written them and put them out there for others to benefit.

I am particularly fond of my advice posts about writing and research. They may sound a bit cheesy as I write them, and I sometimes feel a bit pompous giving advice. Still, they do help people. I occasionally get feedback about how a post meant a lot to someone, and that means a lot to me as well.

Some posts I like come out very easily, often within half an hour, and end up under the misc label. I wrote a short reminiscence about my life after realizing I am getting old and failing to follow new trends. That post became very popular and reached 100K reads. I also wrote a quick post about my time at MIT, which got 40K reads. I wrote a short post about what my cat taught me about communication. That one didn’t get many views, but I still think the world would be a better place if more people practiced what Pasha intrinsically knows.

On the technical side, it is again difficult to choose. It is futile to estimate the impact of a topic in advance, so I write about what I find interesting or what I am working on. Again, one quick post turned out to be especially impactful. This post about anatomical similarities between Paxos and Bitcoin/Nakamoto consensus protocols became the seed for one of our research papers. This was an example of generative writing. I began writing, and the connections became clearer as I went. The blog is a place where I am free to explore and play with wild ideas like this.

I am also proud of my TLA+ posts. I think the examples I modeled have helped many people get started with TLA+ modeling.

Your advice for people just getting started with blogging?

I wrote about how I write here. My approach is to mess up and tidy up later. I clearly separate drafting from editing.

In this other post, I draw inspiration from a legend about a horse and an outlaw. I must be nuts! But the idea is not that crazy. Keep a file where you dump half-ideas and half-written text. Accumulate as much writing as possible as a braindump, and then edit them by organizing/wrangling the text around. When you have something you are happy with, put it out there and forget about it. Let go of expectations about the fruits of your labor.

Finally, follow your curiosity. No niche is too small. Write for yourself and trust that over time, people will find it. Entertain and serve yourself first. Writing itself should feel good. Try to get your dopamine hit from finishing a post and hitting publish. The more you write, the more you can write. Be intrinsically motivated. I am repeating myself, but it is worth repeating: do not hold expectations about people reading your work.

Anything else you want to add?

I am https://x.com/muratdemirbas on twitter, and https://www.linkedin.com/in/murat-demirbas-distributolog-a2233b176/ on LinkedIn. I also have a newsletter now.

Apache Iggy’s migration journey to thread-per-core architecture powered by io_uring

pattern: lessons learned

February longest title award granted! It is quite to the point though. A good set of conclusions and results on how best to apply io_uring and CPU sharding to a large Rust project.

Look ma, no FUSE!

pattern: how we built it

(shameless self-promo, I enjoyed writing this one more than usual though)

Farewell, Rust

pattern: lessons learned

False alarm, the language is still alive, and so is Rust Foundation. What ended is the author’s eagerness to use it for web development, with quite a few valid points.

Catching a caching bug at Readyset

pattern: non-markety product perspectives

Antithesis demonstrates a real scenario of debugging a bug in an SQL cache, through fuzzing, time travel, and exploring multiverses.

How to build a distributed queue in a single JSON file on object storage

pattern: how we built it

Simplest idea wins. A fantastic crash course of how a single JSON file laying around somewhere in an S3 bucket can be a full-fledged distributed queue with optimistic locking on top.

six thoughts on generating c

pattern: lessons learned

A neat package of six patterns to follow when generating C language snippets. The code snippets and practical references help a lot.

Owning a $5M data center

pattern: how we built it

comma.ai’s recipe for running your own datacenter the oldschool way. Tips and tricks on energy and cooling included.

Learning from context is harder than we thought

pattern: benchmarks and test results

An interesting approach to benchmarking large language models. Its main conclusion is that at the time of writing, best models still struggle with real-time learning from latest context -- something that humans tend to excel at.

Read more on writethat.blog

For years, Gwen has been sharing that expertise as a prolific blogger, conference presenter, and co-author of the popular O’Reilly Kafka guide. If you’ve watched her talks or read her writing, you know to expect deep technical experience punctuated with memorable zingers – and perhaps a cat or two along the way. If not, you can catch up here.

Here’s how Gwen responded to the questions we’ve been asking our favorite tech bloggers…

Why did you start blogging – and why do you continue?

I started blogging back in 2007. Almost 20 years ago! Blogging was new and exciting back then. “Web 2.0” started trending. The idea that the web isn’t like a newspaper where authors publish and readers read, but it can be more social and include comments, responses, reactions and interactions. The internet as a place to exchange ideas with smart people all over the world really appealed to me back then, and it is still something that I look for today.

There were people I admired and looked up to who were early bloggers. Tom Kyte (from Oracle’s AskTom fame), Jonathan Lewis and Cary Millsap come to mind. I read their blogs and found them entertaining and educational. Their example inspired me to start my own blog, and also influenced my own writing style to a large extent.

The last bit of motivation was provided by my job. At the time, I was kinda bored with my job and felt that my ideas went unheard. A blog was a great outlet for my ideas. And paradoxically, by forcing myself to blog daily, I had to find interesting things to write about. By actively diving deeper and looking for the interesting bits in my job, my day job became interesting again!

What has been the most surprising impact of blogging for you?

Today, the importance of building a personal brand and networking through social media is very well understood. But back when I started blogging, I couldn’t have predicted that every single job I’ll find will be through my blog.

Blogging connected me to like-minded people, and through this network, I found work I loved. You could say that blogging created my whole career.

What blog post are you most proud of and why?

This is the first blog post I ever published: https://prodlife.wordpress.com/2007/06/15/why-im-still-not-using-asm/

I’m proud of having published it. Even though, in retrospect, it is… less than great. But still, a few folks reacted to it and it encouraged me to keep publishing. I wrote almost every day back then. Soon, I found my voice and my style. I’m actually surprised by how quickly this happened.

My favorite types of posts are:

1. “how to” posts: Sometimes inspired by a tricky issue I encountered, by a new tool that I learned how to use, or just an excuse to dive into system internals.

Here’s my first post of this type: https://prodlife.wordpress.com/2007/07/06/how-high-can-you-go

And a recent one: https://www.thenile.dev/blog/drop-column

2. ”someone is wrong (or right) on the internet” posts: I love interacting with other people’s ideas. Sometimes I agree with them and can share my own examples of how their ideas are helpful. Sometimes I disagree and share my opposing view with my anecdotes or data. Sometimes I argue with a general idea rather than an individual. I love writing “myth busting” posts for this reason.

Here’s an early example of this: https://prodlife.wordpress.com/2007/07/10/data-types-and-cost-based-optimization/

And a recent one: https://www.thenile.dev/blog/pgvector_myth_debunking

Your advice for people just getting started with blogging?

This is a cliche by now, but the best advice I have is: Just write that blog (and publish it). I haven’t regretted a single blog that I published (although I do find some embarrassing). I had blogs that I was scared to publish and clicked “post” anyway. I wrote things that turned out to be wrong, and smart people called me out on it. But in almost 20 years of blogging, nothing bad ever happened as a result of publishing a blog.

The other advice is to be thoughtful about how you connect with people online. The social media climate changed a lot since 2007. Back then, it was all nerds sharing ideas and helping each other. As a nerd myself, it was easy to see myself as part of this group and join the conversation. These days, social media is noisy and competitive. Joining the conversation doesn’t feel like joining a table with 20 friendly nerds. Instead, it feels like trying to be the most popular kid in a school with 10 billion students.

If your goals around blogging are like mine: Connect with like-minded people and form communities where we help each other out. You’ll want to be thoughtful about your own sensibilities and “vibes”. Social platforms like LinkedIn and X can help you “go big” but require an eye toward marketing and a thick skin. Substack and community Discords can be smaller and more supportive. Personally, I’m still looking for my own way to connect with like-minded people in 2026.

A few blogs that you particularly enjoy?

I’ve been following Jeremy Schneider more-or-less since the day I started blogging, and his writing is still one of my favorites. It helps that we both moved from blogging about Oracle to blogging about Postgres!

I met Gunnar Morling through the Kafka community, and I love that his blog ranges through many different technical topics from a software engineering perspective. His writing also tracked my own interests from Kafka and streams to Postgres.

I enjoy reading in-depth distributed systems topics. My favorites are Murat Demirbas and Marc Brooker. Both mix theory and real-world experience in a way that I find both engaging and useful.

Simon Willison posts a lot. Possibly too much for me to keep up with. But he’s a great source of information about AI.

Benn Stancil writes about data analytics and has a unique writing style that I love. It also helps that he posts every Friday, like clockwork.

Netflix and Cloudflare are my favorite “company blogs” with in-depth technical content.

***

Note: Gunnar and Simon also responded to our questions. And Murat’s responses will be featured quite soon.

All that reading/writing leads to lots of blogging lessons learned – and those are nicely shared in the blogging section of his blog.

Here are Robin’s responses to our (now standard) tech bloggerly questions…

Why did you start blogging – and why do you continue?

I was new to the world of Oracle, and learning lots about the tools as I went. One of the things that frustrated me was that the documentation and support knowledge base would just stop at a certain point and you’d have to figure things out for yourself. I benefited from others sharing their knowledge through blogging, and wanted to do the same.

That was over 15 years ago, and I’ve never found it not useful to keep writing and sharing. Writing is a great way to coalesce one’s thoughts and prove out whether one has fully understood something.

This year I’ve enjoyed writing a monthly series called “Interesting Links” which has proved popular, and helped me stay abreast of developments in the data ecosystem. I’ve even experimented with publishing it to Substack!

What has been the most surprising impact of blogging for you?

I got a job at a consultancy firm as a direct result of my blog posts. That was a very nice surprise. Since then, my blog has definitely helped me in my career, but less surprisingly given that I made the move from data engineering into DevRel and hence blogging became one of my core skills that an employer might be interested in :)

What blog post are you most proud of and why?

Can I pick more than one? One technical, one personal.

I wrote a blog post about configuring an aspect of Apache Kafka, called “advertised listeners.” It came up again and again in community spaces like Stack Overflow, and there was never a truly good answer (and lots of bad ones). I’m not a software engineer, so I sat down to understand it for myself by poking at it and reading what I could find, until I finally got my head around it. It took much longer than I’d expected, but the blog post was—and still is—really popular. I’ve had people IRL at conferences thanking me for it, which is nice.

The other blog post I’m particularly proud of is a personal one about the impact of travelling for work on your family. It’s something that’s not always discussed widely, and I realised that if I was struggling with it, perhaps others were too, and sharing it might help. I wrote a couple of follow-up posts too. The responses I got to these posts were very positive. It’s one of the things I love about having my own blog—I can write what I like, about any subject.

What post was the most difficult to write and how did you tackle it?

Probably the personal ones that I describe above. They were difficult partly because I didn’t really know what I wanted to say—or indeed, what I necessarily felt—until I started writing it, as well as the natural inclination as an Englishman to view anything personal as something to keep to oneself and tightly bottled up…

Any lessons learned that you want to share with the community?

Yes, quite a few that I’ve shared in this blog post and talk ;) In short, just start writing! You don’t have to write “War and Peace,” nor do you have to write something that’s novel. Writing your experience of something is totally OK, even if someone else has already written it. Work out what your voice is, and nurture it. Oh, and for the love of everything holy: do NOT use AI to generate your writing. Using it to help (proofreading, bouncing ideas, etc) is totally a good idea. But generating it…hard no.

Your advice for people just getting started with blogging?

Use your own platform. Medium is a cesspit. Any platform that’s not yours could shut down tomorrow, or decide to gate the content, or sell it to the highest bidding AI company for training LLMs. A static site generator like Hugo, hosted on GitHub Pages or Cloudflare, is completely free, and it’s your content forever.

A few blogs that you particularly enjoy?

This makes me nostalgic for blogrolls :)

I love the biting yet eloquent snark in the writing style of Nikhil Suresh, a.k.a. Lucidity.

It was probably Mark Rittman’s writing that inspired me to start writing, and I’ve always enjoyed his easy way of describing how to use a technology.

Jack Vanlightly writes in a way that is mind-blowingly detailed yet clear, and always makes me feel stupid trying to understand it (in a good way).

Two blogs about the non-technical side of work that I really enjoy are Rands in Repose and Kelly Vaughn.

I use RSS to follow blogs, and have a curated list that I maintain through Inoreader, and share the feeds for these here.

Anything else you want to add?

Thank you for asking me; I’m honoured to be in such venerable company as those already on your site :)

Building a movie recommendation agent

pattern: how we built it

Actually practical walkthrough on building an actually helpful agent (specifically two of them, so an “agent orchestrator,” but not of the unhinged gas town quality). Easy to follow and get inspired to build one for your own use case.

Why does SSH send 100 packets per keystroke?

pattern: benchmarks and test results

A machine-enhanced investigation on throughput and latency issues in an SSH game. Quite educational on SSH protocol quirks.

Replacing Protobuf with Rust to go 5 times faster

pattern: we rewrote it in X

A story on rewriting serialization routines to Rust, while keeping the protobuf interface intact. Bonus: interesting take on recursive algorithms and their interaction with CPU caches (the L1/L2/... kind).

ASCII characters are not pixels: a deep dive into ASCII rendering

pattern: how we built it

A must-read. The author decided to spend a fair amount of time creating a comprehensive tutorial on rendering 3D graphics with ASCII characters. With visuals, code snippets, and all. Go read it and find out that ASCII rendering is a branch of science in its own right.

The design & implementation of sprites

pattern: non-markety product perspectives

The article describes a quite novel approach to disposable computers, which is a term lately coined by fly.io. Like sandboxes, but with custom containers replaced with persistence and speed.

Database transactions

pattern: non-markety product perspectives

Practical and interactive summary of what database transactions are. Comes with a complimentary rundown on isolation levels.

Don’t fall into the anti-AI hype

pattern: thoughts on trends

A nice counterweight to all the, well, anti-AI hype.

See it with your lying ears

pattern: how we built it

Extremely educational piece on audio editing, including a 20-line implementation of fast Fourier transform and lots of audio+video samples. Also includes neat tricks on how to make the output more feasible when naïve approaches subtly fail.

Finding and fixing Ghostty’s largest memory Leak

pattern: bug hunt

An investigation of memory leaks in the world’s most hyped terminal emulator’s scrolling implementation. Includes practical debugging techniques like ARM memory tags (TIL).

Databases in 2025: A year in review

pattern: thoughts on trends

Everything you need to know about the state of databases in 2025. Delivered in a uniquely entertaining way.

Swapping two blocks of memory that reside inside a larger block, in constant memory

pattern: lessons learned

The title kind of says it all.

Writing mutexes from scratch in Go

pattern: lessons learned

Another hands-on tutorial on implementing a mutex, through spinlocks, process schedulers, and finally the grand idea of futex. Very nice summary, and the part with using Go explicit coroutine scheduling is a nice touch.

Read more on writethat.blog

Sean writes with a philosophical precision that makes you feel like you’re crawling into his mind for a little bit. His first real “hit” was a late 2024 post on how he thinks about shipping software at large companies. From there, things escalated fast. In 2025, he published 141 posts, 33 of which hit the top of HN. His posts at https://www.seangoedecke.com/ cover topics from AI in software development, to what it’s like being an Aussie in an American company, to where your engineering salary comes from.

So how did he get here? And what lessons has he learned? Over to Sean.

Why did you start blogging – and why do you continue?

I’ve been blogging forever, in one form or another. I had a deeply embarrassing LiveJournal back in the day, and several abortive blogspot blogs about various things. It was an occasional hobby until this post of mine really took off in November 2024. When I realised there was an audience for my opinions on tech, I went from writing a post every few months to writing a post every few days - turns out I had a lot to say, once I started saying it!

The biggest thing that keeps me writing is getting emails and comments from readers. I like it all: positive feedback, people sharing their own experiences, people who disagree and want to argue. We all get such a narrow picture of what it’s like from our own jobs. It’s so cool to open up the aperture and hear from hundreds of other people who’ve had different experiences.

What has been the most surprising impact of blogging for you?

I thought I’d run out of ideas, but the more I write, the more ideas I have. If I don’t write for a few weeks, I feel like I’ve got nothing to say, but as soon as I get a post out, I immediately want to write five more. No idea why!

What blog post are you most proud of and why?

Talking to ChatGPT costs 5ml of water, not 500ml. It’s not the deepest post I ever wrote, but I’m happy that I was able to trace through the chain of references for the “every ChatGPT query costs a bottle of water” claim to find the actual source (which of course didn’t support the claim). This post gets a constant stream of Google traffic and is frequently linked in Reddit or Twitter arguments about AI water usage. There’s a lot of people now who have looked into AI water usage in depth, but in October 2024 it was basically unquestioned that language models used ridiculous amounts of water. I’m proud to have been one of the first voices poking holes in that claim.

What post was the most difficult to write and how did you tackle it?

Everything I know about good system design. I was really worried that it would come off as just a boring summary of some vaguely systems-related topics. I rewrote it a bunch to try and bring out my overall point: that system design is about combining a relatively small “toolbox” of generic components. It was also a challenge to decide how many details to include. I wanted to be concise, but I also knew that people would gleefully point out any edge cases I missed. I’m really happy with how it turned out - and I’ve gotten a lot of positive feedback - but I think I spent more time editing this post than any other post I’ve written.

Any lessons learned that you want to share with the community?

If any of your posts become popular, people are going to be really, really mean about you on the internet. I’ve had Hacker News and Reddit commenters calling me a sociopath, saying that I’m the kind of engineer who ruins companies, that it must be awful to work on the same team as me, and so on. You just have to develop a thick skin about it. I have a hard rule for myself that I don’t engage with the comments on aggregator sites at all. I’d much rather interact with people over email, where we can talk a bit more thoughtfully and nobody’s “playing for the crowd.”

As a matter of practical advice, I’d also suggest setting up a RSS feed before you think you might need one. It’s very easy to do, and if one of your posts does blow up, you’ll be very glad you did it beforehand instead of a day afterwards. I didn’t do this and probably missed out on a few hundred subscribers because of it.

Your advice for people just getting started with blogging?

Try and use it as a tool for figuring out what you really think about things. It’s fine to write several posts about the same topic, even if it feels like you’re repeating yourself. I like to have each post make a single point (and ideally to express that point in the title), but if you prefer a more meandering style, go for it!

I strongly suggest not using AI to make edits to your posts, or to generate content directly. The AI “voice” is really easy to detect, and can turn readers off your blog forever. Worse, AI edits tend to tone down the most interesting and controversial aspects of your writing.

A few blogs that you particularly enjoy?

First, let me shout out my fellow Melbourne tech bloggers Ludicity and thundergolfer.com (who wrote by far the best report on AWS’s recent outage).

Like everyone with a passing interest in AI, I’ve also been loving Simon Willison’s blog. And he hasn’t posted much in a while, but Dan Luu’s blog is excellent and was a big inspiration for my personal style.

Finally, this isn’t about programming, but A Collection of Unmitigated Pedantry is the only blog where I stop what I’m doing to read new posts as they come out.

Anything else you want to add?

If you’re working in tech, I would strongly recommend not trying to monetize your blog. I know it sounds like a good side hustle, but in my view the long-term career benefits of having a popular blog massively outweigh any short-term gains you might get from sticking ads on your site or introducing paid-only posts. It’s also just nicer to put all your posts out there for free, like how blogs worked on the old internet before social networks.

See Sean’s blog for some great reading on writing. Also, watch/listen to this podcast for more writing tips.

In past posts, we’ve shared the mantra “You’re not writing enough” (Bryan Cantrill quoting Pat Helland quoting Jim Gray). Simon, who blogged every day for an entire year, sets a high bar for what’s possible here.

Over to Simon…

Why did you start blogging – and why do you continue?

I started my first blog before I knew it was called a “blog” - I was an enthusiastic online gamer back in 1999, and I ran a competitive league for Team Fortress Classic clans. I decided to build a “news site” about the game using NewsPro, a freeware (not Open Source) Perl script. You can still see it in the Internet Archive!

I started my personal blog a few years later at university in 2002. I was continuing to learn web development and found a huge amount of value in the small cadre of existing blogs about that topic, so I decided to join in.

My previous online activity had been tied to my gamer handle, Skunk. I called my blog “Simon Willison’s Weblog” because I wanted to deliberately start attaching my real name to my writing. This felt quite subversive back in 2002 when most online activity was still pseudonymous!

My blogging back when I started was an extension of my all-consuming message forum habit. I realized that forums were centered around specific interests, but often you find someone who is an interesting writer and who you want to hear from about a wider range of topics.

It also felt like blogging gave me a direct connection to some of the top experts in the world of web development that I was just getting started in, and the idea that they might link back to me was intoxicating.

That was all a long time ago. I took a break from blogging while I was running a startup (and then recovering from that), from around 2010 to 2017. In 2017 I started up again, because I realized that I really missed having a corner of the internet that was all my own.

Then the AI thing started to happen towards the end of 2022 and I found myself as one of the few remaining long-form bloggers who was following that space closely. It turns out having an established blog gives you a surprising amount of influence in a field, so I’ve been leaning into it. The effect is the same as it was for web development back in the early 2000s: I get to meet all sorts of interesting people and learn more effectively thanks to those connections, plus writing and thinking with an audience in mind.

What has been the most surprising impact of blogging for you?

It’s hard to overstate how many opportunities come out of having a well constructed, long term blogging presence.

Most of the jobs I’ve had in my career can be attributed at least partially to my blog. I’ve also been invited to speak at conferences, I’ve had freelancing and consulting opportunities, and most importantly there are a whole lot of people out there with a basic awareness of who I am and what I’m interested in, which can turn into a great conversation any time in the future.

I’m a big believer in the idea of making your own luck - setting things up that increase the chances of a lucky scenario landing on you. Having a blog is a wildly effective way of doing that.

One other significant benefit that’s worth highlighting: blogging is a fantastic way to get better at writing. It’s a free venue for writing for a potential audience as often as you like. Even if nobody reads it you’re still incentivized to think carefully about your words and how you use them, and any conversations about your work will be certain to help you do better next time.

Writing is thinking. Having a blog helps you practice how to think.

What blog post are you most proud of and why?

That’s a really hard one - I’ve published 3,251 long-form and 9,607 short-form posts to my site over the years!

I’m going to cheat and pick several:

Here’s how I use LLMs to help me write code from March 2025 is the most comprehensive piece I’ve written about AI-assisted programming. Most of it still holds up today, though I need to produce an updated version that explores how far into the Claude Code hole I’ve fallen over the past few months.

Coping strategies for the serial project hoarder is an example of a format I really like - an annotated presentation. Every time I give a talk at a conference I later write that up on my blog as slides and very detailed notes, on the basis that a lot of people won’t sit through a video but they may well skim or even read the blog version.

This particular talk is from DjangoCon 2022 and describes how I use large-scale software engineering practices like issue trackers and documentation and automated tests to improve my productivity on my smaller personal projects as well.

2025: The year in LLMs is my 2025 LLM wrap-up. I did one for 2024 and for 2023 as well. These are a lot of work but I’m really pleased with them. I think I do a solid job of capturing the key trends over the previous twelve months of wild development in the space.

What post was the most difficult to write and how did you tackle it?

The hardest posts to write are the ones where I’m trying to make a convincing argument, especially on a potentially controversial topic.

A good (well, bad) example of that is It’s OK to call it Artificial Intelligence from January 2024. I used a clumsy strawman and ended up having to apologize for how poorly I argued my point.

I’ve grown a pretty thick skin over the years though, especially now that I’m frequently writing about a topic which invites extremely sharp opinions from multiple sides.

Any lessons learned that you want to share with the community?

My number one tip for blogging is to lower your standards! Aim to hit publish while you are still actively unhappy with what you have written, because the only alternative is a huge folder full of drafts and never publishing anything at all.

Nobody will ever know how perfect the thing you intended to write would have been. The flaws you see in your writing are invisible to everyone else.

Your advice for people just getting started with blogging?

Just start. It’s so easy to get caught in the trap of obsessing over the design of your blog, and planning for content that you never actually get around to writing. As long as each entry has a date on it and a permanent URL, it counts as a blog. I think adding an Atom or RSS feed is important too, but you can get started without one - don’t treat that as a blocker.

Don’t worry if nobody reads it. People are unlikely to stumble on your blog organically, but what matters is not the quantity but the quality of your readers. If the only person who reads your blog is a hiring manager that you send a link to, and that gets you an interview, your blog has already paid itself off many times over.

I wrote What to blog about describing types of content that are both low friction and high value: TILs (Today I Learned) and writing about your projects, neither of which have any expectations of shining new insights never seen before on the web. I also really enjoy link blogging, and wrote about that in My approach to running a link blog. Posting to a link blog often takes just 15 minutes and is a great way to bring short-form writing to your blog.

Set up an email list as soon as you realize that your blog is going to be an ongoing thing. Way more people want to subscribe via email than via RSS readers. I didn’t realize this until 20 years into my blogging journey and I’ve been kicking myself for not getting email subscribers sooner than that! I use Substack and literally copy and paste my blog into it, which keeps my cost of sending email at zero.

A few blogs that you particularly enjoy?

Interconnected by Matt Webb presents a delightfully eclectic mix of interests.

Daring Fireball has been one of my key blogging inspirations for 20+ years.

Drew Breunig is a recent addition to my feed reader who always feeds me something new to think about.

The Fly Blog remains my favourite example of a company technical blog, with a very distinct voice and a constant stream of high signal articles.

Anything else you want to add?

Use AI thoughtfully. Look for opportunities where AI helps you produce something better than if you had gone without it.

I don’t like letting LLMs write for me, but I also have 20+ years of writing experience to lean on. I still use them to assist my writing: as a thesaurus, as a proofreader and occasionally to check that the argument I’m making does not have any embarrassing holes.

Sophisticated readers can sniff out LLM-generated text, which inevitably hurts your credibility with them. I value my credibility above all else, so I will avoid anything that is likely to hurt that.

***

Note: Simon has shared insights on practically every aspect of writing and publishing. Read more on his blog.

Note: 1) You can read all the past interviews here. 2) We’ll kick off a new round of interviews next week, starting with Simon Willison.

Thorsten Ball

What has helped me the most:

• Setting time limits. I started Register Spill with the idea of using 60min every Sunday to write. Whatever gets written in those 60min gets published. It helped me get over a lot of “but...” in my head.

• Fixed schedule. I never wrote on a fixed schedule and started Register Spill partly in order to see whether I could. Now I know three things. (1) I can, (2) it can be stressful, (3) it helps to get stuff out.

• Keeping drafts on my phone helps. I use Apple Notes and whenever I have an idea for a post, I jot it down, ignoring all spelling, punctuation, and so on. Then, over the course of a day, multiple days, weeks, I keep tweaking that note. On my phone, or on my computer. (I tweaked this very Q&A on my phone for multiple days before now sitting down, in front of my computer, to finish it).

Tanel Poder

One unexpected thing I learned is that it’s not worth distracting yourself from your target audience (which hopefully includes you), even if your planned next post might end up popular. Example: Some years ago, there was a Gmail web UI update and your email reply composing boxes were sized very small. This was not good for techies who sent wide command line tool outputs and code samples in their emails.

So I found a trick for expanding the Gmail reply compose box to full screen that’d be suitable for technical content and blogged about it – hoping that it’d be useful for a much wider audience. Indeed, it did reach a wider audience, but the end result was that my blog’s comments section ended up full of general email, Windows or printer troubleshooting questions from all over the Internet. I took that post down later on.

Also, blog commenting is pretty much in social media now, so you might want to add backlinks to your social media posts about your latest blog to the end of the article. I’ve been too lazy to do this myself though.

And last, I’m happy about my move to static hosting from a managed “CMS” system. The product details don’t really matter, but I moved from Wordpress to Hugo static hosting, where all my blog entries are stored in a GitHub repo. I feel better when treating my blog writings and updates as just code, stored in a repository and rendered to the public-facing HTMLs when needed. Your static page load times will be much better too, especially when a post of yours gets popular.

Sam Rose

Yeah, a few things.

1. I wish I’d found my “thing” earlier. Making use of visuals, interactivity, and vibrant colours to explain boring or scary topics is something I could have been doing years before I started. Take time to think about your own experiences and ambitions. How could you combine 2-3 things you know well, or would happily spend time getting better at, to create something novel and valuable?

2. Listen to all feedback, but be picky about what you act upon. Every one of my post-2023 blog posts has received contradictory feedback. You aren’t going to please everyone, and you shouldn’t try. Work on knowing what’s important to you, and what you want from your work. How do you want people to view you? What do you want people to take from your work?

3. Don’t let the numbers suck the joy out of it. Don’t let the tail wag the dog. Don’t write something just because you want to ride the current hype wave, or because you want to hit the best SEO phrases. Do it because you want to.

To elaborate on the 2nd point, I’ll give you some examples of what’s important to me.

• I want my work to be visually beautiful. I want people to say “oh, wow” when they open it. This is why I use vibrant colours and have developed my own visual style.

• I want my work to be accessible. I put effort into getting better at accessibility with every post. I know I’m not where I want to be with this yet, but it is important to me to keep improving.

• I want my work to help people understand things they didn’t think they could. This is why my work tends to be introductions to topics.

  
  

Phil Eaton

So many lessons, so many suggestions, because I hear so many different reasons people have for not writing or writing but not completing and publishing. However, to summarize it all I would stress that when you speak humbly and in good faith, the internet is incredibly helpful and forgiving, whether you’re an expert or not. So the stakes are just so low and the potential benefits to yourself and others are so great.

And in terms of what to write about, I think you should 1) write about whatever you feel like writing because the first big challenge is your own motivation and 2) focus on what is confusing to you!

Lastly, writing blog posts doesn’t need to be a public thing! It’s immensely useful to you and your team if you publish internal blog posts that the public will never see. If you can publish publicly, that is nice for you and the company. But don’t be under the impression that if your company is particularly secretive, you can’t participate in all the value blogging brings.

Preston Thorpe

You will never please everyone, and the people who are going to overly criticize and critique everything you do are going to do so, no matter what. Focus on the people who appreciate your work and the positive impact you can have, rather than trying to appease every single critic out there.

That being said, with technical content especially, still make sure to be extra thorough when making claims or explaining concepts because someone will call you out on it every time if you get anything wrong.

Also, you will always continue to learn, and blogs are a good metric to go back and look at in a year’s time. You can reflect on how much you have learned since. I know I have gone back to old technical posts and had a good laugh at how naive I was at the time. This is another reason to write, even if you don’t feel like you are reaching any particular audience.

Matt Butcher

We all have different approaches to writing. For me, I have moments where words just seem to flow out of me. In one particularly striking example, I once wrote nine 500-word blog posts in two days, each about a different topic. I published those posts over a three-month period.

At other times, I’ve experienced the opposite. I was so blocked this summer that for three months I couldn’t get past writing the title or opening sentence of a post. I got nothing done. It was a complete dry spell.

Writing is a creative act. When I’m feeling creative, I can easily write a blog post or even two or three or (that one time) nine! When that energy is low, though, writing might be difficult or even impossible.

But what got me out of my dry spell was undertaking activities that got me back into a creative mode. That involved some sketching, some long walks, and (yes) some downtime spent playing my favorite video game (Stardew Valley), which is itself a creative exercise. Somewhere along the line, I found myself getting new ideas or feeling a renewed interest in those blog posts I had started and then put aside.

Jeff Atwood

Just write. Make a habit of writing. It’s like exercise. It’s like anything else…mental health. What are the fundamentals of mental health? Are you eating? Are you sleeping? Are you exercising? Are you having sane interactions with friends and family? These are the fundamentals. And I would add another fundamental to that: Are you writing? Are you formulating a story of why the things that are happening to you are happening to you, and what you can do about that, and what it means? That’s an important part of the formula.

A lot of stuff just randomly happens. But a lot of stuff happens because we chose our own adventure, we chose a certain path, we made a choice. And if you write about that – I made this choice, and it was a good choice, or it was a bad choice, and I learned all these things – you’re not just helping yourself, you’re helping so many other people behind you.

So write regularly, pick a writing schedule that you can live with, and treat it like an exercise regimen. Your blog posts don’t all have to be perfect. Don’t worry; don’t think, “Oh, I can’t write because it’s embarrassing or it’ll be bad.” Everybody’s bad at some level. But you know how you get better? By doing it regularly – not necessarily every day, but on a schedule. That’s how you get better at stuff. That’s how you practice and learn – by doing something regularly, ideally, with feedback.

It’s a lot like my advice to people who are single. How are you going to get into a relationship if you don’t leave the house (before Tinder, at least)? Step one, leave the house. Go to places where other people are present and meet people. Applying that here, just pick some form of writing that works for you, and do it. But I will say, please go beyond chat. Chat is more of an ideation tool. I’m a true believer in writing. Writing is so core. Pick a writing schedule and stick to it.

Gunnar Morling

A common question I see is “What should I write about?” Or, “Everything has been said already, what should I add?” While it’s true that there’s a lot out there already, I think there’s always value in sharing your own personal perspective on things. Nobody will look at a certain topic or question with exactly your background, experience, and context, so there will be a unique angle to that.

There’s a huge demand for entry-level content on all kinds of technologies, so just sharing your own experiences, for instance from learning about a new language, library, or tool, will be useful for the next person in a similar situation. In fact, you might actually be better able to relate to that perspective of other beginners than a person highly experienced with the subject matter!

And don’t forget that you are your own reader too. I can’t count how many times I went back to a blog post I wrote some time ago to read up on some details I had forgotten since then.

Glauber Costa

Even to this day, I am 100% unable to predict which blogs will do well and which blogs will not. Don’t spend too much time trying to figure out whether something is going to work. You will never know. If you have an idea, just write it!

For instance, take the post I wrote on io_uring in 2020. I was actually very reluctant to write that one. ScyllaDB’s CEO [Dor Laor] really pressured me to get some results and share them in a blog, but my initial response was “Why? Nobody really cares about this.” It turns out, that was my best performing article ever. It was a Hacker News hit and it still gets a steady stream of traffic.

Honestly, I see no correlation between what I think will do well and what actually does well – and vice versa. So just write… and some of them will eventually do well.

fasterthanlime

Building your own blogging software is totally fine actually. I’ve been doing it for five years and it’s pretty decent by now. Of course it helps that maybe a third of my content is actually about how I built my own blogging software.

All kidding aside, mhhh: when people tell you to write about things you’re passionate about, it’s not just wishful thinking “if you build it they will come” type of stuff. It’s also that if you build something you really hate (but you think is going to be successful), and they do come, then you’re stuck maintaining that. It’s like how in dating there’s a fine line between projecting a positive image, but also being authentic, to avoid having to keep up a charade if they actually fall for you.

So it’s not like, “following your heart magically makes for a successful business,” it’s more like “the chances it works are slim anyways, might as well do it some way you enjoy.”

Eric Lippert

So many! But let me just pick one. If your blog is successful, it will attract criticism, and that’s a mixed bag. Criticism that genuinely points out ways your post could be more clear, or more accurate, or more complete, or whatever, is gold – even if it is delivered tactlessly. Don’t pass up an opportunity to make improvements or admit it when you’re wrong.

Criticism that is ad hominem, or spammy, or factually wrong, or abusive, you’re allowed to delete that! Joel Spolsky once said something like “Deleting rude comments isn’t censorship any more than cleaning up other people’s garbage off your lawn is censorship.” If someone wants to write their own blog on their own server about how terrible your posts are, that’s their business. You don’t need to provide a site to showcase other people’s low-quality comments.

Charity Majors

It’s impossible to predict what is going to resonate with folks, let alone “go viral,” so please don’t try. Not only is it impossible, but you can smell it when people are trying too hard, and it’s unbelievably offputting. Pull on the threads of whatever is deeply interesting to you, and try to put something out there regularly. If it’s interesting to you, it’s going to be interesting to someone else.

antirez

Try to write posts that are both information-dense AND entertaining. Refuse the magazine-style layout, with posts starting like “When in 1955 Mary Smith started to work at XYZ, she could never have thought that ABC was so 123.” Blogging must be the other possibility of writing, a more honest one.

Aaron Francis

The most important thing is that you press publish. It’s better to publish 12 blog posts a year than spend a year fretting over a single post. You’ll get better as you go and you’ll get better as you publish.

Software engineers should be a little bit cynical

pattern: thoughts on trends

An ideal cynical essay on why cynical approach is an ideal counterweight to idealism.

2025

pattern: lessons learned

Succinct title award for 2025 (in both senses). A blog post on writing blog posts!

Writing a blatant Telegram clone using Qt, QML and Rust. And C++.

pattern: how we built it

A story of writing a Telegram clone, including tiniest details like properly sizing rows of emojis. Impressive meticulousness, as well as the end result!

A disappearing Service Processor

pattern: bug hunt

It’s a bug hunt post with FPGA mentioned at least 7 times. No more recommendation needed.

How a kernel bug froze my machine: debugging an async-profiler deadlock

pattern: bug hunt

December is rife with low-level bug hunts, what a perfect Christmas gift for everyone! This time, it’s a Linux kernel issue plus a nice stuntman trick of reviving a deadlocked kernel with gdb.

Do not optimize away

pattern: lessons learned

An interesting take on using the blackbox trick for microbenchmarks, or actually not using it.

Prediction: AI will make formal verification go mainstream

pattern: thoughts on trends

A prediction that hopefully comes true. Since almost everyone adores TLA+, and yet almost nobody is capable of writing a single correct line of it, perhaps we really need to offload formal verification to AI.

Your intellectual fly is open

pattern: thoughts on trends

A much needed call to stop posting LLM-generated content everywhere, because it shows. AI is great for many things, but not that. Have confidence in your own writing!

Why we built Lightpanda in Zig

pattern: lessons learned

List of reasons for picking Zig over other system languages to build a browser for agents. Quite a standard collection of Zig’s advantages, accompanied by nice short code snippets.

In defense of lock poisoning in Rust

pattern: thoughts on trends

An educational essay on the advantages of poisoning. In this particular case the poison is used in a homeopathy-style therapy, to prevent more serious issues from happening.

Read more on writethat.blog

You can read all the interviews here. We’ll continue the interview series (and maybe publish some book spinoff posts too). But first, we want to pause and compare how the first cohort of interviewees responded to specific questions.

Here’s how everyone answered the question “Your advice for people just getting started with blogging?”

Preston Thorpe

It’s often intimidating to start writing. At first, you will definitely feel like you are writing to no audience. But writing about a specific project you’re working on, or problem you encountered, with a topic you are particularly passionate about — those always tend to be the most enjoyable for others. Even if your posts don’t get a bunch of viral attention, we have all been hunting for unique information and came across someone’s super helpful blog posts about the exact niche subject... Those types of blogs are equally as great and useful as ones which end up getting on the front page of HN.

Sam Rose

In the beginning, don’t think about it too hard. Get something written, on a regular basis, to start developing those muscles. There is a very good chance nobody will read it to begin with, but that’s fine. Write for yourself.

When you’re feeling more confident in your writing, start asking for feedback. Friends are a good start but they can be a double-edged sword. They love you, they want to encourage you, they are less likely to say you’ve made something that sucks. Reach out to writers more established than yourself, writing about similar things, and ask nicely if they’d give you feedback. You’d be surprised how many are happy to do this.

After a few pieces with feedback from other writers, you might start to notice you have your own style of writing. If you can’t see it, dedicate some time to reading other tech writers. Study every word. How do they make use of punctuation, sentences, paragraphs? Is their tone formal or casual? Do they have any favourite words or phrases? Do they write as themselves or have they created a character? Your own style will become more clear as you start to pay attention to the styles of others.

You’ll then have a decision to make: lean into your style, or change it. If you read my older posts (e.g. anything pre-2013) and my newer ones (2018 onwards) you will notice the style has changed a lot. I did this because sprinkling smileys and pop culture references into my posts wasn’t helping the reader learn, and was quite frankly a bit cringe.

My writing today is more… clinical. I remove all words not pulling their weight, I avoid all jargon, and I try to stick to short sentence lengths. It can be constricting, and a bit less fun, but I think it makes for a better end result.

Tanel Poder

Getting started: When writing your first blog entries, document your story. I mean the technical sequence of your actions. How you did something when addressing a real situation, even if there are plenty of similar articles out there. Such personal documentation will be useful as a future reference for yourself (speaking from experience), and sometimes for others too. Unless your goal is to become a random influencer with the most followers, but no substance, do not use AI to write your content.

Medium term: Start adding context of why you chose to do something like you did, given your circumstances and requirements. This is not just “rehashing documentation” that the AI chatbots these days can do very well. The “why” of tradeoffs is a deeper level of understanding that shows both your expertise in the field and helps others understand it better as well.

Long term: Address something unique. A problem that you fixed that didn’t have well-known solutions documented before. Or if you found yourself doing repetitive work and ended up semi-automating it with a simple tool or even just a one-liner script, that’s unique enough to publish!

Gunnar Morling

First, as mentioned before, don’t be afraid of writing about things that might seem not interesting or novel enough. If there’s something which you found interesting, chances are somebody else will find it interesting, too.

Then, and that might be a bit controversial, I’d recommend starting on your own domain from the get go, rather than on a shared place like medium.com. While it can be a bit more hassle to set that up initially, it will help you a lot to build your own, independent brand, and it just creates a more professional perception. It also means you are in control of things, nobody can change how your posts can be accessed, etc. As far as tooling is concerned, I’m a big proponent of static site generators (I am using Hugo for my own blog, published via GitHub Pages). They give me the biggest freedom in terms of layout and formatting and I like the workflow of writing blog posts in source formats such as AsciiDoc and storing them in git. But then, others prefer tools like WordPress with a more WYSIWYG-like experience, so you should try out what suits you best.

Lastly, be patient. Blogging is a long game, you shouldn’t be depressed when not getting too many readers or comments initially. It takes years to build up an audience, and on the way there, it can sometimes feel a bit like shouting into the void. It’s about building up a corpus of interesting posts over a longer period of time. Success will come eventually, and later on it can be very rewarding to see how posts from years ago are still regularly receiving comments or are referenced from other places.

Charity Majors

The advice I will give is the advice I find nearly impossible to take: Keep it short, keep it snappy. Edit twice as much as you write. Short, pithy posts tend to be more memorable, get wider traction, and stick in people’s minds more; they’re also faster and easier to ship. Do NOT write 5000-8000 word monstrosities, like I seem to be unable to keep doing (sigh).

I have a sticky note next to my monitor that reminds me of this, and one of these days, I swear I’m going to try taking my own advice!

Also: I find Twitter or Bluesky threads to be an incredibly effective form of drafting blog posts. It slows you down just enough that you have to think about how to make your point with some pith and punch. It prevents you from being too wordy. I like to go for a walk and draft a thread while I’m getting from point A to point B.

Eric Lippert

People getting started often have many complementary goals: practicing their writing skills, educating users, building an audience and a personal brand. Something that helps with all of these things is frequency. When I started, I was doing many relatively short posts a week. Keeping the cadence high for the first couple years really helped me practice my short-form writing and build an audience. Don’t obsess over wordsmithing the perfect article. Get it out, and you’ll improve as you go.

Aaron Francis

If you publish your posts, then you get to count that as a success. The finish line is pressing publish. It doesn’t matter if it bombs or it does super well. Your job is to publish it. That’s when you get to say, “I did a good job.”

Of course, you can learn from feedback. You can learn from the ones that did well, and you can learn from the ones that did poorly. But internally, I think you need to reframe the finish line as putting it out into the world, not putting it out into the world and having it be a success.

fasterthanlime

I’ve read “write what you wish you could read” a bunch as advice and I think I generally agree with it? It can be hard to get that initial set of eyes to look at your stuff, so maybe try finding a community, a group of people who can give you legitimate feedback. It’s going to be hard to find people who are willing to give honest feedback (less so in Europe), but it’s important.

Me, I’m my own worst critic, but I keep having to remind myself that blog articles are not like software projects. I’m not going to have to keep maintaining articles forever — I spend a finite amount of time on them, do my best, and if I feel like revisiting the topic later, I can do that! Obsessing forever has an opportunity cost: while you’re trying to perfect that one piece, there are so many others you’re not writing. It can be hard to find a balance: setting deadlines for yourself helps — sometimes.

Phil Eaton

So many lessons, so many suggestions, because I hear so many different reasons people have for not writing or writing but not completing and publishing. However, to summarize it all I would stress that when you speak humbly and in good faith, the internet is incredibly helpful and forgiving, whether you’re an expert or not. So the stakes are just so low and the potential benefits to yourself and others are so great.

And in terms of what to write about, I think you should 1) write about whatever you feel like writing because the first big challenge is your own motivation and 2) focus on what is confusing to you!

Lastly, writing blog posts doesn’t need to be a public thing! It’s immensely useful to you and your team if you publish internal blog posts that the public will never see. If you can publish publicly, that is nice for you and the company. But don’t be under the impression that if your company is particularly secretive, you can’t participate in all the value blogging brings.

Glauber Costa

Number one, just do it! But also, keep it short and to the point, focusing on just one thing.

Sometimes your team might try to pressure you into including all sorts of interesting details that are related to that topic. I never liked this approach, and my blogs became a lot more successful when I stopped trying to squeeze in details that weren’t critical to what I was trying to convey.

It’s natural for you to want to tell the whole story, but having a clear focus is important for keeping the reader interested. If you dump everything into the blog post, readers won’t discover the highlights. Nobody cares about you. Really! People have very little time. Just cover the key points, and know that people will seek you out – maybe engage on social media – if they want more details.

So, keep it short, keep it simple, keep it to the point. Find one thing that’s going to be memorable, and focus the article on that. The rest doesn’t matter. Resist the temptation to write everything that’s on your mind.

Matt Butcher

Use the blog as a log for what you are learning. Early on, I wrote about sed because that’s what I was learning. Not too long ago, I wrote a post summarizing what I have learned about software dev. While it may seem less evident, that, too, was an account of something I had learned about myself. For twenty years, I’ve been “learning in public.” And for all that time, I’ve been steadily reading other people’s blogs as they do the same. I think that’s the most helpful view of blogging both as a reader and as a writer: Blogging is a unique way of sharing knowledge “in real time” as we learn.

Thorsten Ball

Anything goes. You can make your blog your own thing. Every post has a single paragraph? Go for it. Every post is super long and you only publish every two months? Sweet, do it.

Don’t worry about “someone else already wrote about it”. The Internet’s a big place and not every bit of writing resonates with everyone. Think of it like this: how many different explanations on the same topic did you have to read until it “clicked”? Depending on the topic, it can be a lot. Because every teacher, every writer — they all have different lives, different point of views, different ways of thinking about things, different metaphors they use, different phrases. And some of it resonates with some people but not with others. You can be another unique combination of experience and point of view and skill and put something out there that resonates with someone.

Send it. Don’t be a perfectionist.

Write about things you know. Don’t pretend to be someone you’re not. It’s bad writing and people can sniff it out.

Cool it with the memes and AI-generated images.

Jeff Atwood

Just write. Make a habit of writing. It’s like exercise. It’s like anything else…mental health. What are the fundamentals of mental health? Are you eating? Are you sleeping? Are you exercising? Are you having sane interactions with friends and family? These are the fundamentals. And I would add another fundamental to that: Are you writing? Are you formulating a story of why the things that are happening to you are happening to you, and what you can do about that, and what it means? That’s an important part of the formula.

A lot of stuff just randomly happens. But a lot of stuff happens because we chose our own adventure, we chose a certain path, we made a choice. And if you write about that – I made this choice, and it was a good choice, or it was a bad choice, and I learned all these things – you’re not just helping yourself, you’re helping so many other people behind you.

So write regularly, pick a writing schedule that you can live with, and treat it like an exercise regimen. Your blog posts don’t all have to be perfect. Don’t worry; don’t think, “Oh, I can’t write because it’s embarrassing or it’ll be bad.” Everybody’s bad at some level. But you know how you get better? By doing it regularly – not necessarily every day, but on a schedule. That’s how you get better at stuff. That’s how you practice and learn – by doing something regularly, ideally, with feedback.

It’s a lot like my advice to people who are single. How are you going to get into a relationship if you don’t leave the house (before Tinder, at least)? Step one, leave the house. Go to places where other people are present and meet people. Applying that here, just pick some form of writing that works for you, and do it. But I will say, please go beyond chat. Chat is more of an ideation tool. I’m a true believer in writing. Writing is so core. Pick a writing schedule and stick to it.

antirez

Don’t lose too much time in setting up the perfect blog environment. Just write about things that in a given moment you care about. Don’t force yourself to find topics.

You can read all the interviews here. We’ll continue the interview series (and maybe publish some book spinoff posts too) in 2026. But first, we want to pause and compare how the first cohort of interviewees responded to specific questions.

Here’s how everyone answered the question “What has been the most surprising impact of blogging?”

antirez

That it is a fundamental carrier for software projects. You can’t have a successful project most of the time without communicating it. Sometimes it happens that developers who don’t communicate do things that are so important that other folks will communicate them, and the projects will still be successful. But in general, I believe that communicating, for developers, is a key asset for their projects, startups, whatever, to have any chance to become popular.

Thorsten Ball

The biggest surprise is probably that, over the years, readers have sent me very personal, very thoughtful emails about how a certain bit of writing has influenced and, believe it or not, helped them.

I mean, sure, yes, when you write and put something on the Internet, you hope that it resonates with someone and chances are — the internet is big — that it will: someone somewhere might think like you on this topic. But, still, it’s a surprise when you receive an email in which someone tells you how you influenced them and possibly changed the trajectory of their career, because they rethought their work after reading something you put out.

Matt Butcher

One day I was trying to write a regular expression. I knew there was a trick to it, but couldn’t remember what that trick was. So I googled it. Lo and behold, the first hit was a blog post I had written many years before that answered my question. I learned an invaluable lesson from that experience.

We like to think of ourselves as always progressing, always getting better. But we discount how quickly we forget things. In the past, I had already solved the problem that was plaguing me. That day, I started to view blogging as teaching “future me” about what “present me” was learning. And that change rippled through my view of writing and even of coding. Yes, I was maturing as a person and as a developer. I was learning, but also forgetting. Writing was a way of being able to capture my learnings externally so that I didn’t need to rely on my memory.

Glauber Costa

It’s been quite surprising to see how well a blog post can reach people who might be interested in using your product. Don’t assume that you need a fancy marketing website. Especially if your audience is developers, what people really want is the pure technical opinions and information. Just capturing that in blogs generates a very large and healthy “inbound funnel” of interest for your product.

Phil Eaton

I was a bit shocked to see two of my posts cited in research papers. One post cited was my survey about parsing techniques in programming languages and the other post cited was a post I wrote about how databases build on top of key-value databases.

When you write about what’s weird or interesting to you, you might end up being one of the few people who have ever written about the topic. Mostly, I think, because relatively few people write at all!

Getting featured in a book about writing for developers was also pretty surprising. :)

fasterthanlime

I certainly didn’t expect my blog posts to be used for internal training at various big companies, but I guess it makes sense! That one’s a little bittersweet because, okay, I get name recognition, but that’s a form of payment my landlord doesn’t allow.

Another that’s more heartwarming is: I’ve been speaking up about my own mental health journey a bunch in articles and videos, and occasionally at conferences people approach me and thank me for talking about it, because it compelled them to seek help. That I’m extremely happy about, and it motivates me to keep talking about depression, medication, etc. — even though it makes me a little less employable each time :)

Aaron Francis

I got an email just the other day about one of the blogs that I wrote. The email said that I had changed this person’s life from one of the posts that I wrote. The post was called “What if you try hard?” and it was basically a call for people to go above and beyond and do more than just the minimum.

This person said that they took that advice to heart and started submitting conference talks and doing open source work – and then, because of that, landed a dream job that they never thought possible. That was probably the most impactful thing that I’ve ever heard from any of my work.

Eric Lippert

Every now and then I’ll get an email from a reader who says that they finally grasped a tricky concept after reading one of my articles on it, or that they were inspired to try a new thing, learn a new language, start a new project. It makes it all worth it to know that you’re connecting with people and helping them solve their problems. I was surprised by how common that was.

Charity Majors

Writing forces you to hold your beliefs up to the light of day and examine them for inconsistencies, lack of evidence, shoddy logic, or even just non-compelling arguments. I was just realizing recently how much my writing has shaped my convictions, at least as much as my convictions have shaped my writing.

Gunnar Morling

Blogging opened up so many opportunities and connections for me over the years. In a way, it really formed the foundation for my career in the Java and data streaming space.

In 2009, I wrote a post about the Bean Validation API for data validation in Java. This caught the attention of the folks working on this project at Red Hat at the time, and they reached out to me to ask whether I’d be interested in writing the documentation for Hibernate Validator, the reference implementation of the Bean Validation specification. So I did that, and I became more and more active as a contributor to that project, which led to landing a job at Red Hat in 2012.

Also later, when moving to Decodable, and just recently to Confluent, my writing played an important role.

Tanel Poder

I think blogging and writing has made me a better problem solver. It has steered me towards trying to generalize and structure whatever solutions I happen to come up with in my work. I won’t just conclude that the “problem was a hang” and “solution was a reboot” and be done with it. I want to understand and dig deeper (that’s the fun research part) and generalize it to cover a wider range of issues. And once I’ve found a simple enough way to explain the whole chain of events, it’s the perfect time to write about it.

This kind of generalization and writing for a wider audience has created a positive feedback loop for my own thinking and work. I’m not just “printing out” the latest steps I had taken, but I fit them into a bigger picture.

As far as other surprises go, some articles from 15 years ago are still useful when dealing with real-life scenarios today. Many of my old articles are about things running on Solaris or HP-UX, but exactly the same problem patterns happen on modern Linuxes too. So, when dealing with a connection storm or a priority inversion issue in a latest Ubuntu Linux container, I can still point people to an old 2010 article about the fundamentally same “chain of events” I had documented before. On different platforms, the tools, naming conventions and terminology are different, but the pathology is the same.

Sam Rose

The first big “wow, this works” moment was getting approached by Google. It was 2013 and I was barely 2 years out of university when I got an email from a Google recruiter inviting me to interview. I ended up working there for 4 years and it was a formative experience, one that had a huge impact on my career trajectory, my understanding of myself, and my worldview.

These days, what surprises me is just how many people I’ve been able to make connections with online through this shared love of creation. People will DM me saying things like “I really love your load balancing post!” and I’ll reply “Thanks! Hey, do you wanna do a video call sometime?” and they almost always say yes.

Alternately, I’ll reach out to people I admire and say “I really loved your post on XYZ, would you be open to a video call about it?” and I think because I have an appreciable following and a body of my own work on show, people are more willing to say yes.

Preston Thorpe

I will never get used to the emails I receive, mostly from younger people like students or people with similar kinds of backgrounds, who reach out to tell me that they were inspired by my story. One of them in particular was from a kid who had read my first blog post a couple years ago. He said that it helped him make a tough career choice to transition into software engineering at the end of his college degree, and that he has since gotten a job in the field.

As much as I love helping people, I wrote the post more to get it off my chest and explain myself to the world. I didn’t imagine that as many people would end up relating to it as much as they have, and that it would actually provide inspiration for others to have similar journeys.

You can read all the interviews here. We’ll continue the interview series (and maybe publish some book spinoff posts too). But first, we want to pause and compare how the first cohort of interviewees responded to specific questions.

Here’s how everyone answered the question “Why did you start blogging – and why do you continue?”

Aaron Francis

I started blogging as a way to get attention for a product that I was working on. And while that product never really worked out, I started getting interest from people that wanted me to come work for them, either as a freelancer or as a full-time employee. And since then, I have realized what a cheat code it is to have a public body of work that people can just passively stumble upon. It’s like having a bunch of people out there advocating for you at all times, even while you’re sleeping.

antirez

I don’t know exactly, but in general, I want to express my interest in things I like, in my passions. It was not some kind of calculation where I said: oh, well, blogging would benefit my career. I just needed to do it.

Charity Majors

I started writing at a big life inflection point -- the brief period after I left Facebook but before I started Honeycomb. I had started giving talks, and found it surprisingly rewarding, but I’m not an extrovert and I’ve always considered myself more of a writer-thinker than a talker-thinker, so I thought I might as well give it a try.

There are very few things in life that I am prouder of than the body of writing I have developed over the past 10 years. I have had a yearly goal of publishing about one longform piece of writing per month. I don’t think I’ve ever actually hit that goal, but some years I have come close! When I look back over things I have written, I feel like I can see myself growing up, my mental health improving, I’m getting better at taking the long view, being more empathetic, being less reactive... I’ve never graduated from anything in my life, so to me, my writing kind of externalizes the progress I’ve made as a human being. It’s meaningful to me.

Eric Lippert

I started my blog, which is now at ericlippert.com, more than 20 years ago. I worked for the Developer Division at Microsoft at the time. As developers working on tools for other developers just like us, we felt a lot of empathy for our customers and were always looking for feedback on what their wants and needs were. But the perception of Microsoft by those customers was that the company was impersonal, secretive, uncommunicative, and uncaring. When blogs started really taking off in the early 2000s, all employees were encouraged to reach out to customers and put a more human, open, and empathetic face on the company, and I really went for that opportunity.

I was on the scripting languages team at the time, and our public-facing documentation was sparse. Our documentation was well-written and accurate, but there was only so much work that our documentation “team” – one writer – could do. I decided to focus my blog on the stuff that was missing from the documentation: odd corners of the language, why we’d made certain design decisions over others, that sort of thing. My tongue-in-cheek name for it was “Fabulous Adventures In Coding.” At its peak, I think it was the second most popular blog on MSDN that was run by an individual rather than a team.

For most of the last decade I’ve been at Facebook, which discourages employees blogging about their work, so my rate of writing dropped off precipitously then. And since leaving Facebook a couple years ago, I haven’t blogged much at all. I do miss it, and I might pick it up again this winter. I really enjoy connecting with an audience.

Editor’s note: He’s now writing a book.

fasterthanlime

I genuinely cannot remember why I started, because I’ve been blogging for about 15 years! That’s just what the internet was like back then? It wasn’t weird for people to have their own website — it was part of maintaining your online identity. We’re starting to see that come back in that post-Twitter era, folks value having their own domain name more, and pick up blogging again.

I can say, though, that in 2019 I started a Patreon to motivate me to take writing more seriously — I’m reluctant to call it “blogging” at this point because some of my longer articles are almost mini-books! Some can take a solid hour to go through. At the time, I was sick of so many articles glossing over particulars: I made it my trademark to go deep into little details, and not to be afraid to ask questions.

Glauber Costa

I started blogging years ago at ScyllaDB. I was initially forced to do it, but I ended up really enjoying it. [This is strikingly similar to Sarna’s “Stockholm Syndrome” story in Chapter 1 of the book].

I’ve always liked teaching people and I saw that technical blogging was a way to do that…at scale. As I was learning new things, often working with previously unexplored technologies and challenges, blogging gave me this opportunity to teach a large audience of people about what I discovered.

I kept doing it because it actually works. It really does reach a lot of people. And it’s very rewarding when you find that your blog is getting people to think differently, maybe even do something differently.

Gunnar Morling

I started blogging for a couple of reasons really. First, it just helps me to take note of things I learned and which I might want to refer to again in the future, like how to prevent ever-growing replication slots in Postgres. I figured, instead of writing things like that down just for myself, I could make these notes available on a blog so others could benefit from them, too. Then, I like to explore and write about technologies such as Java, OpenJDK Flight Recorder, or Apache Kafka. Some posts also distill the experience from many years, for instance discussing how to do code reviews or writing better conference talk abstracts. Oftentimes, folks will add their own thoughts in a comment, from which I can then learn something new again–so it’s a win for everyone.

Another reason for blogging is to spread the word about things I’ve been working on, such as kcctl 🐻, a command-line client for Kafka Connect. Such posts will, for instance, introduce a new release or discuss a particular feature or use case and they help to increase awareness for a project and build a community around it. Or they might announce efforts such as the One Billion Row coding challenge I did last year. Finally, some posts are about making the case for specific ideas, say, continuous performance regression testing, or how Kafka Connect could be reinvisioned in a more Kubernetes-native way.

Overall — and this is why I keep doing it — blogging is a great way for me to express my thoughts, ideas, and learnings, and share them with others. It allows me to get feedback and input on new projects, and it’s an opportunity for helping as well as learning from others.

Jeff Atwood

I love blogging – it’s how I got to where I am. Steve McConnell‘s book Code Complete is what inspired me to start blogging. His voice was just so human. Instead of the traditional chest-thumping about “My algorithm is better than your algorithm,” it was about “Hey, we’re all fallible humans writing software for other fallible humans.” I thought, “Oh my God, this is humanistic computing.” I loved it! I knew I had to write like that too. That’s what launched me on my journey.

Now more than ever, I think it’s important to realize that we’ve given everyone a Gutenberg printing press that reaches every other human on the planet. At first blush, that sounds amazing. Wow, everybody can talk to everybody! But then the terror sets in: Oh, my God. Everybody can talk to everybody – this is a nightmare.

I think blogs are important because it’s a structured form of writing. Sadly, chat tends to dominate now. I want people to articulate their thoughts, to really think about what they’re saying – structure it, have a story with a beginning, a middle, and an end. It doesn’t have to be super long. However, chat breaks everything up into a million pieces. You have these interleaved conversations where people are just typing whatever pops into their brain, sometimes with 10 people doing that at the same time. How do you create a narrative out of this? How do you create a coherent story out of chat?

I think blogging is a better mental exercise. Tell the story of what happened to you, and maybe we can learn from it. Maybe you can learn from your own story, perhaps from the whole rubber ducking aspect of it. As you’re explaining it to yourself, you’re also creating a public artifact that can benefit others who might have the same problem or a related story. And it’s your story – what’s unique about you. I want to hear about you as a person – your unique experience and what you’ve done and what you’ve seen. That’s what makes humanity great. And I think blogs are an excellent medium for that.

There’s certainly a place for video, there’s a place for chat. These tools all have their uses, but use the appropriate tool for the appropriate job. I think blogs are a very, very versatile tool in terms of median length, telling a story, and sharing it with the public.

If you look at the history of humanity, the things that have really changed the world have been in writing – books, novels, opinion pieces, even blogs. The invention of language was important, but the invention of writing was so much bigger. With writing, you didn’t have to depend on one person being alive long enough to tell the story over and over. You could write it down and then it could live on forever.

I encourage everyone to write, even if you write only for yourself. I think it’s better if you write in public because you can get feedback that way. You can learn so much from the feedback – learn that others feel the same way, learn about aspects you didn’t think about, etc. But it’s scary. I get it – people are afraid of putting themselves out there. Write for just you if you want, but write… just write.

Matt Butcher

I first started blogging in earnest back in the early 2000s because I was at university and wanted to share that experience with the rest of my family. Somewhere along the line, I started a second blog to record (mainly for myself) the technologies and tools I was learning.

These early tech blog posts were pretty basic. I’d learn a new sed trick, and write a couple hundred words about it. I’d try a new code editor, take a screenshot, and write my basic impressions. Embarrassingly, sometimes my blog posts were terribly inaccurate. I once wrote one on optimizing tree walking algorithms that was totally wrong. But I just updated it later with a note that said I’d learned more and now realized there were better ways of doing things.

In those early days, I never used any analytics or anything. I had no idea if anyone ever read what I wrote. Then one day, a friend of mine got really into SEO and asked if I would set up Google Analytics and share with him so he could learn a bit. I was utterly shocked by what we learned: My blog had a ton of traffic, and some of the most basic posts (like the one about sed) were perennially popular.

I’ve blogged on and off since then. These days, I mainly post on the Fermyon blog. And those posts are more theoretical than my early how-to focused posts.

Phil Eaton

My shameless goal when I started blogging in 2015 was to become a regular on the front of Hacker News (HN) because I got the sense that it would be good for my career. And I enjoyed the type of posts that made a great fit for HN; posts that were a little crazy yet taught you something useful.

After becoming a manager in 2017, I realized the importance and value of writing for the sake of communicating and my focus on writing shifted from “writing about zany explorations” to “writing as a means for teaching myself a topic, or solidifying my understanding of the topic.”

I started to notice, observing both myself and coworkers, that we developers let so many educational opportunities pass without recording the results. What a waste!

Not only is writing about what you learn good for your own understanding and your team’s understanding and for the internet’s understanding, it’s good marketing for you and the company you work for. Good marketing in the sense that when people see someone write a useful blog post, they think “that person is cool, and the company they work for must also be cool; I want to work with them or work for that company or buy from that company.”

So there’s this confluence of reasons that make blogging so obviously worth the time.

Preston Thorpe

Honestly, I don’t think I made a conscious decision to start blogging. I just remember being involved in open source projects and my story wasn’t really out there yet. And it felt odd that nobody knew my situation.

I didn’t want to just flat out randomly tell people that I’m incarcerated. So I decided that I’d write my story down for anyone to find if they came across my profile. I really did not expect for many people to actually read it, so it was pretty shocking to see it on the front page of HN a couple days after it was published.

I try my best to keep writing, although I don’t write as often as I should. Writing an in-depth technical blog post about a feature built or a problem solved allows me to fully absorb and understand it even better than just implementing it, so this is another reason I feel like I will continue to write. It serves as both personal motivation to more deeply understand something I am working on, as well as a way to share that knowledge with others.

Sam Rose

I started blogging about tech in my final year of university. The earliest posts on http://samwho.dev, the ones from 2011, were written at this time. I’d heard that having an online presence would help me get a job, so I started writing about the things I was learning.

I wrote sporadically for years, most of my posts only getting a trickle of traffic, but I did have a few modestly successful ones. https://samwho.dev/blog/the-birth-and-death-of-a-running-program/ did well and even ended up as part of the Georgia Tech CS2110 resources list. One of the lecturers, who has since retired, emailed me in 2013 asking if he could use it. I was concerned because the post had swearing in it, but he said “swearing is attention getting and helps the reader stay alert.”

The blog posts I’ve become known for, the ones with lots of visual and interactive bits, started in the first half of 2023. I’d long admired the work of https://ciechanow.ski/ and wanted to see if I could apply his style to programming. It’s working well so far!

As for why I continue, I’ve been gainfully employed for a long time now, so my initial motivations for writing are long gone. I think my blog does help when I have conversations with employers, but that’s not the goal anymore.

I have this dream of being a teacher. I’ve dabbled in many forms of teaching: teaching assistant in university for some of my lecturers, mentoring in commercial and personal capacities, moderating learning communities, volunteering at bootcamps and kids’ groups. What if I could just… teach for a living?

I’m trying to make use of the attention these blog posts are getting to see if I can make steps towards doing just that.

Tanel Poder

Over the years, I had accumulated a number of useful scripts and techniques for troubleshooting the common OS & database problems I had encountered. At first, I created the blog (on June 18, 2007) as a lookup table for my future self. I uploaded all my open source tools to my blog and wrote articles about the more interesting troubleshooting scenarios. When I visited a customer to solve a problem, we could just copy & paste relevant scripts and commands from my blog. That way, I didn’t have to show up with a USB stick and try to get it connected to the internal network first.

Why do I continue? There’s so much cool stuff and interesting problems to write about. When writing, you have to do additional research to make sure your understanding is good enough. That’s the fun part. Systems are getting more complex, so you need to find new ways to “stay systematic” when troubleshooting problems and not go with trial & error and guesswork. These kinds of topics are my favorite, how to measure the right things, from the right angle, at the right time – so that even new unforeseen problems would inevitably reveal their causes to you via numbers and metrics, without any magic needed.

What makes me really happy is when people contact me and say that they were able to solve completely different problems that I hadn’t even seen, on their own, with the aid of the tools and systematic troubleshooting advice I have in my blog.

Thorsten Ball

I published my first blog post on thorstenball.com in 2012. It’s this one about implementing autocompletion using Redis. I don’t know exactly why I started the blog, but, looking back, I think the main motivation was to share something I was proud of. It was a cool bit of code, it took me a bit to figure out, I learned a lot in the process, and I wanted to share the excitement.

At that time, I was also a junior software developer, having recently finished my first internship, trying to switch from studying philosophy into being an engineer and, I think, there was also a bit of “my blog can be a CV” aspect to it.

Back then, a friend had told me: you don’t need a degree to get a job as a software engineer, all you need to do is to show that you can do the job, because, trust me, he said, there’s a lot of people who have degrees but can’t do the job.

I figured that having a blog with which I can share what I learned, what I did, well, that’s a way to show that I can do the job. Now, I don’t think a lot of recruiters have read my blog, but I still believe there’s something to it: you’re sharing with the world what you do, what you learned, how you think — that’s a good thing in and of itself, and even if someone only takes a brief look at your blog before they interview you, I think that can help.

But, I also have to admit that I’ve been writing on the internet in one form or another, since the early 2000s, when I was a teenager. I had personal websites and blogs since I was 14 years old. I shared tutorials on web forums. There’s just something in me that makes me want to share stuff on the internet.

Nowadays I mostly write my newsletter, Register Spill, which I see as a different form of blogging, and for that newsletter, I have a few reasons:

• I enjoy the writing. Well, okay, I enjoy having written. But, in general: I’m proud of writing something that’s good.

• I’ve enjoyed tweeting a lot, but in the past few years the social media landscape has become so fractured that I decided to create a place of my own, a place where people can subscribe and follow me, where I can potentially take their emails and send them newsletters even if the platform decides to shut down.

• Writing is thinking. I like sitting down and ordering my thinking in order to write something. The feelings of “I want to write something” and “I want to really think through this topic and share it” are similar for me.

Imgur geo-blocked the UK, so I geo-unblocked my entire network

pattern: how we built it

Beautiful tutorial on how to selectively route only specific websites through VPN, while keeping the rest of your network fast. Especially useful in the age of geo-blocking everything.

Assert in production

pattern: lessons learned

Good conclusions from the Cloudflare unwrap fiasco. tl;dr your production code should crash more, not less, especially if the alternative is running in a defective state. Much better to suffer from a few hours of downtime than chasing your leaked personal data in the darkest corners of the Internet.

Intel is listening, don’t waste your shot

pattern: lessons learned

This article dares you to share brutally honest feedback with hardware vendors, for everyone’s benefit. (And admits it is easier said that done.) Interesting perspective from an author who has been on both sides of those meetings with vendors.

Assertions are not the problem; your verification process is

pattern: thoughts on trends

High quality rant following all the opinions stated online after the Cloudflare fiasco. Read the whole thing if you would like to learn why, quoting, “However, all the arguments are wrong.”

Cloudflare outage on November 18, 2025

pattern: lessons learned

Lesson learned: unwrap() is evil. Jokes aside, the article is a very detailed and prompt post-mortem report from a worldwide crash.

How quake.exe got its TCP/IP stack

pattern: how we built it

Ever-entertaining author of Game Engine Black Books delivers again. This time it’s a history lesson on how Quake gained a networking stack and why third-party companies were involved. Fascinating.

I built a synth for my daughter

pattern: how we built it

A full guide on how to cook your own hardware to your kid’s delight. Includes lots of great resources to start working closer to electrical circuits as well as 3D design and printing. Super strongly recommended (no daughter required, although highly recommended as well).

The write last, read first rule

pattern: non-markety product perspectives

A story of how to make multiple distributed systems consistent by ordering the operations the right way. It also acts as a cautionary tale of what happens if you order the operations the wrong way (don’t).

You should write an agent

pattern: thoughts on trends

A call to write agents, with an embedded mini-tutorial. You should write an agent yourself! Even if just to have more fuel to hate generative AI. Chances are though, that you’ll appreciate the things a deceptively simple loop can do.

Indexing sparse vectors with Turso

pattern: benchmarks and test results

Now that the “vector database” hype is near its end, the world is in the “let’s add vectors as first-class citizens to existing databases” stage. The article explains Turso’s sparse vector indexing implementation and measures how all of its flavors and configurations perform.

Read more on writethat.blog

Preston writes his blog, Inside Thoughts, from “the other Mountain View”: Mountain View Correctional Facility in Charleston, Maine. His posts cover topics ranging from optimizing Turso’s WAL checkpointing with io_uring async I/O, to reflections on programming, to how he started coding professionally while incarcerated.

Note: Last month’s interviewee, Aaron Francis, just shared an in-depth chat with Preston. They discuss redemption, resilience, and rewriting SQLite in Rust.

Over to Preston…

Why did you start blogging – and why do you continue?

Honestly, I don’t think I made a conscious decision to start blogging. I just remember being involved in open source projects and my story wasn’t really out there yet. And it felt odd that nobody knew my situation.

I didn’t want to just flat out randomly tell people that I’m incarcerated. So I decided that I’d write my story down for anyone to find if they came across my profile. I really did not expect for many people to actually read it, so it was pretty shocking to see it on the front page of HN a couple days after it was published.

I try my best to keep writing, although I don’t write as often as I should. Writing an in-depth technical blog post about a feature built or a problem solved allows me to fully absorb and understand it even better than just implementing it, so this is another reason I feel like I will continue to write. It serves as both personal motivation to more deeply understand something I am working on, as well as a way to share that knowledge with others.

What has been the most surprising impact of blogging for you?

I will never get used to the emails I receive, mostly from younger people like students or people with similar kinds of backgrounds, who reach out to tell me that they were inspired by my story. One of them in particular was from a kid who had read my first blog post a couple years ago. He said that it helped him make a tough career choice to transition into software engineering at the end of his college degree, and that he has since gotten a job in the field.

As much as I love helping people, I wrote the post more to get it off my chest and explain myself to the world. I didn’t imagine that as many people would end up relating to it as much as they have, and that it would actually provide inspiration for others to have similar journeys.

What blog post are you most proud of and why?

Probably my first post, “How I got here.” I certainly want to be known for my more technical achievements and I never wanted to strictly classify myself as “the programmer in prison,” but that post really set the stage for everything that came after it. I hope to keep writing more technical posts in the future, and I haven’t had any purely technical posts gain as much attention as that first one yet. I think it will be a while before I can top that one in terms of personal significance.

What post was the most difficult to write and how did you tackle it?

Once again, probably my first post. It was difficult to write because there are a lot of touchy subjects involved and I try to be respectful of everyone’s perspective, even if I don’t personally agree with it. It’s always a balance of explaining your own personal perspective while being sensitive to the fact that other people may have very different experiences. I just tried to be as honest and straightforward as possible, and I think that approach resonated with people.

Any lessons learned that you want to share with the community?

You will never please everyone, and the people who are going to overly criticize and critique everything you do are going to do so, no matter what. Focus on the people who appreciate your work and the positive impact you can have, rather than trying to appease every single critic out there.

That being said, with technical content especially, still make sure to be extra thorough when making claims or explaining concepts because someone will call you out on it every time if you get anything wrong.

Also, you will always continue to learn, and blogs are a good metric to go back and look at in a year’s time. You can reflect on how much you have learned since. I know I have gone back to old technical posts and had a good laugh at how naive I was at the time. This is another reason to write, even if you don’t feel like you are reaching any particular audience.

Your advice for people just getting started with blogging?

It’s often intimidating to start writing. At first, you will definitely feel like you are writing to no audience. But writing about a specific project you’re working on, or problem you encountered, with a topic you are particularly passionate about — those always tend to be the most enjoyable for others. Even if your posts don’t get a bunch of viral attention, we have all been hunting for unique information and came across someone’s super helpful blog posts about the exact niche subject... Those types of blogs are equally as great and useful as ones which end up getting on the front page of HN.

A few blogs that you particularly enjoy?

Miguel Young - https://mcyoung.xyz/

Thorsten Ball - https://thorstenball.com/ and https://registerspill.thorstenball.com/

Matklad - https://matklad.github.io/

Phil Eaton - https://eatonphil.com/

Avinash Sajjanshetty - https://avi.im/blag/

Editor’s note: We’ve already interviewed Thorsten and Phil — and we’re hoping to feature Miguel, Matklad, and Avinash (V) soon!

I’m writing another book!

pattern: thoughts on trends

He’s writing another book!

Zig’s new async I/O

pattern: how we built it

Zig’s interesting take on how to implement I/O asynchrony and concurrency. Also, why the two are distinctly not the same thing, especially in Zig’s implementation.

Corrosion

pattern: lessons learned

Fly.io’s story of building a reliable service discovery system. Contains lots of educational cautionary tales, as well as lots of useful links.

How I reversed Amazon’s Kindle web obfuscation because their app sucked

pattern: how we built it

A beautiful tale of working through layers of DRM absurdity just to read a book in peace. Reverse engineering at its finest.

I am sorry, but everyone is getting syntax highlighting wrong

pattern: thoughts on trends

A philosophical piece on how to implement syntax highlighting in a way that does not hurt human eyes. I also admire a creative way of using the word “diarrhea” as a paragraph header.

How to check for overlapping intervals

pattern: lessons learned

The article starts with an introduction to something every other programmer rediscovered 17 times -- how to simplify the check for overlapping intervals. However, it also extrapolates the idea to two dimensions, which is a very nice pattern to remember.

How we found a bug in Go’s arm64 compiler

pattern: bug hunt

Very informative bug hunt! Dives deep into the intricacies of arm64 architecture, where a deceivingly simple addition is not always encoded as a single opcode...

Tokenization from first principles

pattern: how we built it

As a fellow CS336 “LLMs from Scratch” course hacker, I am deeply biased to like this post more -- it is a very good start for anyone interested in training large language models. On top of a very good introduction to what tokenizing is, the article also sums up one of the novel approaches -- superBPE. Well worth reading.

2x faster hashes on AWS Graviton: NEON → SVE2

pattern: benchmarks and test results

Comparison of various SIMD extensions, performed on Graviton instances. Nice opportunity to catch up on latest ARM improvements.

Cuckoo hashing improves SIMD hash tables (and other hash table tradeoffs)

pattern: benchmarks and test results

A very thorough writeup on cuckoo hashing -- a genius CPU-cache-and-SIMD-friendly approach to hash tables.

Cancelling async Rust

pattern: thoughts on trends

Do not get your hopes up just yet -- async Rust is not cancelled as a whole. The article dissects the asynchronous destructors problem that most async frameworks have, one way or the other. In Rust, there exists a concept of “cancel safety” I was not really aware of. The concrete example of mutating state under a Tokio mutex really helped me grasp the idea!

How we scaled raw GROUP BY to 100 B+ rows in under a second

pattern: how we built it

A longish (but well worth the time) summary of what makes ClickHouse GROUP BY fast. It also explains how to achieve massive parallelism, but still be able to correctly merge the state to return a coherent result. Nice.

Read more on writethat.blog

The book explores seven popular engineering blog post patterns:

• The bug hunt

• We rewrote it in X

• How we built it

• Lessons learned

• Thoughts on trends

• Non-markety product perspectives

• Benchmarks and test results

The “Bug Hunt” blog post pattern is the programming world’s equivalent of a detective story. It has a theme, a main plot, side plots, a protagonist (you), an antagonist (usually also you, having introduced the bug two weeks ago in the first place). It’s captivating, keeps readers in suspense, and ends with a satisfying plot twist, or a tactical cliffhanger. And the best part is…it’s even more fun to write than to read!

8.1 Purpose

Writing a bug hunting article serves a few purposes, depending on the success of the hunt, where the fault ultimately fell, and a few other factors. Let's tackle the potential purposes one by one.

8.1.1 Knowledge dump

The fact that a bug appeared and was fixed is undeniably important. But what's way more important is reducing the chance that it happens again – and knowing what to do if it does. While hunting for a bug, it's likely you encountered the following:

• A few dead ends

• A very convincing red herring

• A tool that looked helpful at first, but ended up being unrelated

• Another tool that proved immensely useful

• Some blog post from 2014 that led you to discover the root cause

All those steps are incredibly useful for the future debugger of another similar issue (likely you again, two weeks older). Awareness of the past dead ends and distractions is especially helpful here. Quick identification of a known red herring can save the future debugger (you) a few hours of unproductive research. You can treat bug hunting blog posts as scrolls of ancient knowledge (two weeks or older), created by your predecessors (you) to pass it on to future generations (also you).

8.1.2 Global bug awareness

It's give-back-to-the-community time! Chances are, the bug that you fixed doesn't uniquely apply to your project. Instead, it was caused by a sneaky pitfall in your language of choice, one of the libraries, or specific hardware. Your article can genuinely inspire others to think "Huh, we do have exactly the same setup – makes me wonder…" It might also motivate the team behind that technology to consider ways to stop others from making the same mistake.

As a result, writing a story about how you fixed an interesting bug may cause a few other bugs of the same category to be fixed worldwide. It's a superpower! This purpose is especially important if the bug is related to:

• Bleeding edge software

• Novel hardware

• A young open-source community

Those tend to develop dynamically and have very little test coverage compared to industry standards simply because they are too young to be implemented in a critical mass of projects. You can think of this purpose as an external version of the previously described "knowledge dump" – it’s a knowledge dump that you write for everyone, not just for yourself or your team.

8.1.3 Bragging

Set aside the negative connotation of the “bragging” word. Tech world bragging – at the right dosage – is good for you and your peers. Bragging about doing something interesting, like hunting and resolving a bug, helps you as well as your readers:

• It's educational. Your audience can presumably learn something by reading how you achieved your goal.

• It broadens your professional network. People intrigued by similar technologies and challenges will likely reach out to you as we outlined in Chapter 1.

• It feels good. There’s no shame in acknowledging that attention is one of the benefits of telling the world that you did something.

• It yields free criticism – hopefully constructive criticism, but valuable either way. The (often illusory) sense of anonymity on the Internet makes it easy to criticize others, so you can count on lots of comments and nitpicks after your article goes public. But after filtering out the vitriol, you can often learn something new, or even revisit your whole approach to the problem.

8.2 Audience

Bug hunting is a technical topic, and the audience for bug hunting blog posts is inherently just as technical. Categories of interested readers include:

• People with a similar background (which means they are potentially susceptible to introducing or suffering from similar bugs in their systems)

• People whose job is finding and fixing production bugs

• People in the midst of a similar bug hunt

• People who might be able to prevent this class of bug from recurring (those behind the technology where the bug occurred or working on defect prevention tools)

• Detective fiction aficionados

• Your colleagues

• Professional Internet critics specialized in unsolicited advice

It's safe to assume that the audience is someone who:

• Already has sufficient professional background to understand the technical terms and idioms you use in the article

• If not, is willing to look them up and learn

• If not, is absolutely fine with just pretending that they understand it

Therefore, it's fine to treat a bug hunting blog post as one addressed to "intermediate level" (or above) readers and not "newcomers." Advanced technical terms are fine because you're not trying to make the article accessible to the wider public. Just expand any arcane acronyms as you see fit and provide hyperlinks as needed.

8.3 Examples

Since bugs can occur anywhere, so can bug hunting blog posts. In the wild, you can find bug hunting posts published across a variety of blogs: Big Tech, unicorn, startup, and personal blogs. In general, bug hunting posts published by large high-profile companies are unsurprisingly less common (and more guarded) than those by startups as well as individual contributors writing about open-source contributions and weekend projects.

Here are some prime examples of blog posts that apply the “Bug Hunt” pattern, along with Piotr’s commentary on each.

8.3.1 Hunting a NUMA Performance Bug

Author: Michał Chojnowski

Source: ScyllaDB Blog (https://www.scylladb.com/2021/09/28/hunting-a-numa-performance-bug/)

Summary

The article describes a performance regression happening on modern hardware with NUMA (Non-Uniform Memory Access) design. The regression seemed to occur randomly on half of the runs, which made it much harder to pinpoint. The article shares a few failed (but nonetheless skillful and impressive) attempts to diagnose the problem. Then, one of the observations leads straight to a breakthrough and a surprisingly small fix – measured with lines of code.

Commentary

This is the pinnacle of bug hunting blog posts. It’s deeply technical, but at the same time simple to follow. The less experienced readers can skip some of the nitty-gritty details and still learn a lot. All of the failed attempts to diagnose the issue are educational, and surely usable in future debugging.

The casual expertise that the author shows while editing executable binaries directly as if they were text files makes the blog post an extremely enjoyable read. The solution to the problem is also very satisfactory, especially to a programmer’s mind: just one seemingly innocent line of code changed, and all the performance regressions are eliminated.

8.3.2 Why Is My Rust Build So Slow?

Author: Amos Wenger

Source: fasterthanlime Blog (https://fasterthanli.me/articles/why-is-my-rust-build-so-slow)

Summary

This extensive blog post investigates compilation time issues for a Rust project. It shows multiple techniques for how to profile the compiler itself, decompose the compilation process into manageable pieces, and measure how long each piece takes and why. It's full of images, code snippets, and descriptions of concrete tools you can use. The article's conclusion is not really any single breakthrough, but rather honest advice to apply all the extensive techniques above if you're unsatisfied with your Rust build times.

Commentary

Compared to an average technical blog post, this one is a hog – in a purely positive sense! It can easily take a skilled reader half an hour to read through it, and it's probably a good idea to digest it in three or four parts, taking breaks from the screen to avoid dizziness and diplopia.

This is a positive trait because it makes the article stand out. Many tech articles try to squeeze as much information as possible into 4 to 6 minutes of reading. And that’s fair, considering the average attention span of a human being raised on smartphones rather than playing outside all day with occasional cartoon breaks. Yet, a long article will appeal to the old school folks who were once capable of reading a book in a single sitting.

The article has a unique style featuring the author's alter ego, Cool Bear, who regularly adds short humorous comments – keeping the reader engaged throughout the (lengthy) reading process.

Figure 8.1 This article highlights insights from the author’s alter ego, Cool Bear – sometimes in dialog with the author’s own interior monologue.

This type of a bug hunting blog post also serves as an encyclopedia of techniques for debugging the Rust compiler. I have it bookmarked, just in case I ever need to refresh my knowledge of how to measure linking times in my projects. The conclusion is also quite unconventional: instead of building tension and finally presenting readers with a surprise solution, it's simply an honest summary with encouragement to reach out.

8.3.3 How a Single Line of Code Made a 24-core Server Slower Than a Laptop

Author: Piotr Kołaczkowski

Source: Piotr Kołaczkowski’s Blog (https://pkolaczk.github.io/server-slower-than-a-laptop/)

Summary

The blog post describes how local benchmarks detected a bottleneck on machines with lots of CPU cores. The author shares a performance analysis, performs some profiling, then offers a few explanations of how modern CPUs work under the hood and how the processor caches manage memory. The suggested fix is a natural consequence of the conclusions reached earlier in the article: minimizing the amount of state shared between processor units eliminates the bottleneck.

Commentary

This is another stellar example of a bug hunting blog post. Its title is a little clickbaity, but still elegant enough to avoid being rejected by the average ad-blocking software. The technical details are much more universally understood than the ones in Chojnowski’s NUMA blog post (described earlier in this section).

The article is sneakily educational, digressing on things like "How many nanoseconds does L3 cache access take on average on Intel Xeon." That's great practice; it leaves those details imprinted in readers' minds without them realizing it. Who knows – maybe one day that tucked-away tip might help fix a performance bug in another project. Overall, the article leaves readers satisfied with the result, and also a tiny bit smarter in the field of CPU architecture and performance.

8.3.4 Lessons from Debugging a Tricky Direct Memory Leak

Author: Sanchay Javeria

Source: Pinterest Engineering Blog (https://medium.com/pinterest-engineering/lessons-from-debugging-a-tricky-direct-memory-leak-f638c722d9f2)

Summary

Pinterest's development team shares their experience hunting a stream processing code memory leak that led to cascading failures in their distributed system. It goes over debugging techniques for the Java environment and then finally pinpoints a bug in application code that caused the memory leak.

Commentary

This is a classic bug hunting article – so much so that it could be used as a blog post template for hunting down almost any issue in Java code. It contains the customary investigation steps, along with screenshots from observability tools. Also following custom, the culmination paragraph is called "The Fix." It explains that the culprit was yet another memory leak issue caused indirectly by garbage collection mechanisms in Java. Hint: It always is!

In this context, the conclusion isn't really an earth-shattering breakthrough, but it definitely meets the readers' expectations. I bet the majority of the readers think "Ah, I knew it from the start" right after learning the root cause.

8.3.5 ZFS Is Mysteriously Eating My CPU

Author: Brendan Gregg

Source: Brendan Gregg’s Blog (https://www.brendangregg.com/blog/2021-09-06/zfs-is-mysteriously-eating-my-cpu.html)

Summary

The blog post describes a hunt for the cause of mysterious higher-than-expected CPU usage. It shows how to narrow the candidates down to a single function call with analysis tools and concludes with a surprising performance bug in ZFS – a file system implementation.

Commentary

The title itself is captivating, but then something in the URL jumps out at you: it's by Brendan Gregg, the flame graph inventor! This is a prime example of why personal brand matters so much. When I see “Brendan Gregg,” I immediately assume that the article is interesting … and I wasn't mistaken in the slightest.

Given Gregg’s expertise, the problem analysis naturally involved flame graphs. The root cause is quite a surprise, and Gregg described it in a very informal and funny manner. The blog post is also very concise: a three-minute read, even if you reserve some time upfront to look at the flame graph screenshots. It clearly shows that you don't need to write thousands of words to squeeze in lots of knowledge, tips, and interesting technical details.

8.4 Characteristics

Bug Hunt blog posts can vary as wildly as the actual bug hunts – but they tend to share the following characteristics:

• They recount the story chronologically, from the moment the evil bug manifested itself, to when it was pronounced dead

• They focus primarily on the thrill (and pain) of the hunt

• They freely share the evidence collected along the hunt so readers can put on their detective hats and play along

• They’re largely geared to experienced developers who know the technologies being discussed (or are ready to learn as they go)

• They offer technical nuggets that could be interesting now, lifesaving later

Let’s examine each in turn.

8.4.1 Crafted chronologically

Bug hunting blog posts often follow a specific structure since they are the technological equivalent of detective stories. (If you want an intro or refresher on the structure of a detective story, generative AI does a decent job here). The introduction paragraph does not reveal too many details and certainly does not provide a spoiler on the solution. Often, they just elaborate on the (properly mysterious) title with a few more words.

Once the problem is defined, the hunt begins, usually with a few failed (but educational) attempts. The tension builds until the author reaches their aha moment, which is followed by the fix description (and that section is customarily titled "The Fix"). After the solution is revealed, the blog post concludes by describing preventive measures to stop this bug from recurring – and often a concise apology to any affected users.

8.4.2 Heavy on the hunt

The meatiest part of the article is the path towards identifying the issue. Spending around 80% of the post explaining the investigation process is a good rule of thumb. For example, here’s how much time each of the example blog posts above spent on the investigation (based on word count):

• Chojnowski: 85% hunt

• Wenger: 83% hunt

• Kołaczkowski: 83% hunt

• Javeria: 82% hunt

• Gregg: 93% hunt

8.4.3 Evidence everywhere

Bug hunt blog posts are usually full of forensic evidence. Readers want to see flame graphs, numbers, charts, scripts, and code samples. This lets them step into your detective shoes and try to figure out the riddle before the big reveal.

For example, here’s some of the evidence shown in the example blog posts:

• Chojnowski: Database monitoring graphs (writes per shard), network and disk performance graphs, CPU stats, flame graphs and instruction-level breakdowns, the CPU’s performance measuring monitoring unit (PMU) events, and a variety of attempted code fixes

• Wenger: Cargo build timings, a timeline of compilation units, CPU usage and concurrency graphs, debug information, flame graphs, tracing through Chromium and Perfetto, attempted code fixes, dependency graphs

• Kołaczkowski: A look at the benchmarking tool’s design, throughput results (on his 4-core laptop vs. a 24-core server), flame graphs

• Javeria: Out-of-memory error details, backpressure tests, and multiple forays into memory monitoring

• Gregg: Flame graphs (of course!), ZFS mount details, arcstats, and all the source code, via a GitHub link

Figure 8.2 Example of an eye-catching flame graph. You can interact with this flame graph at https://scyllabook.sarna.dev/perf/fg-before.svg

Flame graphs are particularly common across bug hunting blog posts. They offer a great way to visualize your debugging and performance profiling process. And they’re interactive – users can zoom in to the interesting parts, filter out only the events that match a particular regular expression, and much more. Flame graphs can be created from the output of popular tools, such as Linux's perf profiler or Rust's cargo flame graph command.

8.4.4 Expert friendly

Bug hunting articles tend to be expert friendly. The author usually assumes that the audience is proficient (or at least familiar) with the technological stack used in the article. Code samples and scripts shared in the article are typically targeted to readers who are familiar with the programming languages used. These types of posts aren’t conducive to basic explanations of core language concepts; if the reader doesn’t “get it,” they might need to soldier through it or just move on.

This is distinctly different than in other blog post patterns, such as “We Rewrote It in X” (discussed in Chapter 9). Blog posts in that pattern are more appropriate for those just getting started with the given technology and often include an “Introduction to the New Language” section.

8.4.5 Educational

Blog posts following this pattern can be quite educational for developers beyond the impacted team. The meaty part, bug identification, is abundant in details about how to inspect similar issues. Even more importantly, these sections are abundant in reproducible details: ones that are likely to be useful for solving all kinds of similar problems that readers might face in the future. The blog post serves its purpose if it leaves the reader equipped with a few more tricks they can apply, just in case they ever encounter a similar bug at some point in their life.

For example, here’s a high-level view of what readers could learn from each of our example blog posts:

• Chojnowski: The kinds of issues you might encounter with complex memory architecture (NUMA), especially with ARM processors

• Wenger: Ways to improve your Rust build times

• Kołaczkowski: How modern CPUs work under the hood and how the processor caches manage memory

• Javeria: Java is evil

• Gregg: How to apply analysis tools like an absolute expert

8.5 Dos and don'ts

The best blog posts are born from the most torturous bug hunts. Driven by the glorious feeling of finally solving the mystery, strike while the iron is hot. Write your impressions before the high of the hunt wears off and help your peers solve their next case faster.

Here are some tips for writing your own Bug Hunt blog post.

8.5.1 Check if anyone (your boss, your boss's lawyers) will be upset by your transparency

This is especially important if you hunted a bug that had a notable impact on users – or if the disclosure of this bug could negatively impact your company’s reputation and/or the all-important stock price. Open-source or source-available projects usually don’t impose any legal considerations (except maybe trying to avoid getting your code infected with one of the GPL licenses and its "copyleft" terms). Not all code is open-source though.

Before you publish code snippets of your heavily guarded corporate secrets, make sure that your boss and any interested parties are fine with it. Even if you skip the code, your superiors still may be averse to making certain information public, especially if the bug was related to security, or ended with an unfortunate data leak. Use this rule of thumb: Ask first, write and publish later.

8.5.2 Do a technical deep dive

Technical details are a must in any, well, technical blog post. If your article lacks details like code samples, specs on the exact technology used, step-by-step instructions, etc., many readers will leave unsatisfied. Even worse, they might doubt your integrity. Perhaps the inconvenient bits were deliberately omitted to make the product look better? If you worry that you might be adding too many technical details, err on the side of more. Readers can always skip over them if they don't find them interesting.

Bug hunting blog posts are especially expected to be loaded with tips, tricks, code, benchmark results, as well as links to open-source repositories and documentation. Otherwise, you rob readers of the fun opportunity to draw their own conclusions from the copious evidence. As noted earlier, it's fine to be expert-friendly here. You can assume that the audience is either already familiar with the technology described, or willing to catch up (with the help of your blog post).

8.5.3 Be brutally honest about all your failures

Your failures and misery provide readers with the cathartic effect that brought them to your blog post in the first place! They also give rise to the most educational aspect of bug hunting articles. After all, it's great to learn from mistakes, but it's even better to learn from somebody else's mistakes first.

Bug hunting blog posts are usually written after the root cause has been identified and the bug fixed. The more pain and suffering are described in the first paragraphs, the better the final breakthrough looks. Readers who struggle with similar issues are going to actively search the Internet for descriptions of similar problems, so all the sorrowful keywords like "broken," "fault," or "FUBAR" serve dual purposes – they're an emotional outlet for the author's frustration, plus they also make the blog post easier to find online.

Don't try to convey a perfect, pristine bug hunt. Dead ends and failed attempts bring in tons of educational value. Programmers (which is of course a synonym for “great minds”) think alike. That means some readers could get stuck in the same dead ends – unless they read your cautionary tale first.

8.5.4 Include numbers, benchmarks, metrics, and flame graphs

Benchmark results, metrics, and all kinds of numbers are the equivalent of clues and proofs from the detective fiction world. Bug hunting blog posts look less legit if they use vague phrasing like "our system is now much faster." Readers will immediately think "Yeah, but how much faster?" followed by "Dear author, if you were really proud of the results, then you would have posted them…" Screenshots from your metrics (or even better, interactive figures like flame graphs) catch readers' eyes, making the article both more credible and more enjoyable to read.

8.5.5 Don't give away too much, too soon – keep the tension building

For most blog posts, we recommend sharing the TL;DR early on so readers can quickly decide if they want to continue. Not here! With bug hunt blog posts, avoid spoilers at all costs! The tension should be patiently built until the aha moment occurs, and the fix is revealed. This is key for allowing readers (those not in a hurry, at least) to vicariously experience the thrill of the hunt, with all its twists and turns. They probably already suspect that the article concludes with a happy ending, because otherwise it wouldn't be published. But aren't most detective stories like that anyway?

8.5.6 Don’t make overeager readers hunt too hard for the fix

That being said, some readers will get impatient. Maybe they drew their own conclusion after just a few paragraphs and want the immediate gratification of confirming that they got it right, right away, unlike silly old you. Maybe this is the twelfth Java bug hunting blog post they’ve come across this month and they want to see if this is yet another one where the garbage collector is ultimately to blame. Be kind and mark “the fix” with a nice prominent heading so they can skip ahead to the smoking gun.

As a bonus, having a clearly labeled fix is also helpful to those who are returning to your blog post because they’re now suffering a similar problem. Back when they were reading this for fun, they enjoyed following along with the thrill of your hunt. But now that the tables have turned, they want to go straight to your fix and see if it will save them in their own moment of despair.

8.5.7 Add breaking points wherever necessary

Bug hunt articles can get long, especially if you’re covering every little twist and turn (as you absolutely should!) If you end up writing a blog post that will take over 20 minutes or so to read, consider adding a few clear breaking points for readers, in case they opt to consume your article in more than one sitting.

For example, you could provide a short recap of the progress of the investigation so far. You might add an explicit note that the steps described above led to a dead end, leading to a new thesis. Or you could simply use subheadings like “Phase 3,” subliminally suggesting to the reader that it's fine to take a short coffee break here without losing context.

8.5.8 Don't suck the life out of it

Readers aren't here to read an official failure report. The captivating bits are the personal story, the struggle, and the final joy of figuring out what was wrong. The best bug hunting blog posts use an informal conversational tone, and anecdotes are very much welcome.

Narrate it from your personal point of view. Don’t hesitate to share what was going through your mind as the mystery unfolded. Also, rants are borderline mandatory and expected – in reasonable doses, of course. Deep down, most humans enjoy reading about other people’s frustrations and feeling the indirect relief that it didn't happen to them (yet).

The “building tension” and “providing full access to clues” approaches detailed above are two fundamental ways to keep readers engaged (yes, they are shamelessly stolen from real detective stories). In addition, you might want to:

• Write in an extremely casual tone, sacrificing “proper” grammar as needed to keep it conversational

• Create a faux dialog with the reader: ask them questions so they’re encouraged to step back and form their own hypotheses (which you will proceed to confirm or disprove)

• Write as if you’re in the thick of the hunt (e.g., “Let’s see if …” vs. “Then we checked if…’’)

• Share exactly what popped into your head (no matter how silly it seems in retrospect) as you encountered each new piece of information

• Explicitly call out critical moments like “plot twist,” “dead end,” and “the aha moment” to ensure readers are in the right mindset at every point

8.5.9 Don't forget to thank those who helped along the hunt

The most important reason for publicly acknowledging your collaborators is pure kindness. Bug hunts are among the most infuriating parts of computer programming, and misery loves company. Your collaborators probably made the pain a bit less excruciating; if you appreciate that at all, do thank them here. For the not-so-empathetic folks, there are also pragmatic (read: selfish) reasons for thanking your collaborators. Your acknowledgment could make them more likely to assist in the next bug hunt. Also, if you name someone in a blog post, you can pretty much guarantee that they will read it – and maybe they will even share it. And perhaps someone they know will be the person to start it trending on Hacker News.

8.5.10 Extrapolate

Feel free to extrapolate from specific errors (e.g., "Our Rust code had a bug") into more general issues (e.g., "Rust standard library makes it easy to deadlock in this particular use case.") Bug hunting blog posts are also opportunities to shine some light on pain points you have with a particular technology. You’ve managed to attract a captive audience, interested in what you have to say. Why not take advantage of that? If you noted something particularly problematic with the language or library you used, bite the bullet and suggest that something should be fixed upstream. Programming language and library maintainers appreciate constructive criticism that helps improve their projects.

8.6 Summary

• Writing a bug hunting article serves to share knowledge, raise awareness about bugs you encountered, and showcase your achievements

• A bug hunting blog post targets a technical audience, from experts to enthusiasts, usually assuming (at least) intermediate knowledge of the terminology

• Bug hunting blog posts are typically heavy on investigative details, showcasing technical evidence in the form of numbers, benchmarks, results, and graphs

• Top tips:

  • Check for transparency issues

  • Do a technical deep dive

  • Be brutally honest

  • Include numbers and benchmarks

  • Avoid spoilers

  • Clearly mark “the fix”

  • Make it personal

  • Thank your collaborators

***

You can preview more of the book on the Manning site (don’t miss the foreword by Bryan Cantrill and afterword by Scott Hanselman). Please note that the words get scrambled at some seemingly arbitrary point beyond our control. Sorry! ¯\_(ツ)_/¯