> ## Content Index > Fetch the complete content index at: https://debugly.dev/llms.txt > Use this file to discover other available public pages before exploring further. # One Hundred Posts About Things Breaking - URL: https://debugly.dev/one-hundred-posts-about-things-breaking/ - Published: 2026-10-09T12:58:00.000Z - Updated: 2026-10-17T05:56:36.000Z - Description: What I learned writing a hundred debugging writeups, including which ones people actually read and what that says about technical content. - Author: Rohit Bhadani - Tags: Engineering Culture, Debugging, Opinion This is the hundredth post on Debugly. It seems worth stopping to look at what came out of it. I started this because of an asymmetry I found frustrating: enormous amounts of writing about how to build things, very little honest writing about how they break. A year and a hundred posts later I have some evidence about whether that gap was worth filling. ## What people actually read The distribution surprised me, and it was not what I would have predicted when I started. **Error autopsies dominate on volume.** Posts titled with an exact error string get steady traffic indefinitely. Somebody pastes `exec format error` into a search box at eleven at night and arrives. These are not the posts I most enjoyed writing and they are the ones that help the most people. The pattern that works is unglamorous: the fix at the top, the mechanism underneath, then a ranked list of every other cause of the same message. That last section, the one enumerating causes I hit that were not the main one, generates a disproportionate share of the useful email I get. **Bug hunts get shared but not searched.** The narrative posts about a single investigation get discussed and linked, and almost no search traffic. They have a spike and then nothing, which is the opposite shape to the autopsies. I would still write them, because the links they attract make everything else more findable, and because they are the posts where I learn the most from writing. **Opinion posts get the most argument and the least agreement.** [Print debugging is underrated](https://debugly.dev/print-debugging-is-underrated/) produced more disagreement than anything else, most of it thoughtful, some of it correct. ## What I got wrong **I was too confident about several things.** I wrote [a whole post about positions I had been wrong about](https://debugly.dev/five-things-i-was-confidently-wrong-about/) and I have since found more. The pattern is consistent: I take a heuristic that is correct in one context and apply it as a rule everywhere. **I underestimated how much infrastructure knowledge transfers.** Moving from Shopify themes to microVMs felt like a complete change of domain. The debugging method transferred almost entirely. The tools changed from Chrome DevTools and Liquid render times to kernel traces and conntrack tables, and the reasoning did not change at all. That has become one of the more useful things I believe: the transferable part of this skill is the reasoning, not the tooling, which is why [teaching it is so hard](https://debugly.dev/teaching-someone-to-debug/). **I assumed AI would make debugging content less relevant.** The opposite happened. Generation got cheap, verification did not, and verification is debugging. Writing about how to determine whether something works turned out to be more useful in 2026 than in 2025, not less. ## The patterns across a hundred bugs Reading back through them, a few things recur enough to be worth stating. **Most hard bugs are one false assumption, and it is load bearing.** You cannot reason about the system without assuming most things are true, so your attention slides over exactly the belief that is wrong. **The population beats the instance.** For anything intermittent, aggregating the failures answers the question faster than examining one. [The Tuesday bug](https://debugly.dev/the-bug-that-only-happened-on-tuesdays/) is the clearest example and I have hit the same lesson repeatedly since. **The shape of a symptom carries a lot of information.** p99 up with p50 flat, CPU flat with latency up, worse under throttling, worse under CPU load. Each of those rules out most of the search space in one observation. **A loud bug is frequently the visible edge of a quiet one.** Several investigations found a second, worse problem that had been running silently for longer. The guard that produced the error was the only reason anything was noticed. **Silence is ambiguous and dangerous.** Backups that succeed and produce unrestorable archives. Jobs that stopped firing. [Analytics that were quietly wrong for three months](https://debugly.dev/timezone-bug-corrupted-analytics/) because the numbers looked plausible. Wrong-but-believable survives far longer than obviously broken. **Most incidents follow a change, and scoping "what changed" too narrowly costs hours.** I have made this exact mistake more than once. ## What I would tell someone starting a technical blog **Write about what you actually hit.** The posts that took the longest to write are the ones with real numbers, real version strings, and real dead ends. They are also the only ones anybody remembers. **Include the wrong turns.** Every instinct in technical writing pushes you to present a clean path from problem to solution. The false leads are where the method lives, and removing them turns a lesson into a fact. **State versions.** Not pedantry. A post without them wastes the reader's time when the behaviour has changed. **Answer the question in the first paragraph.** If somebody arrived from a search engine with an error in their clipboard, they do not want context. Put the fix at the top and the explanation below. **Be specific enough to be wrong.** Vague writing cannot be corrected, which sounds safe and means it also cannot be useful. The corrections I have received have improved posts more than anything I did on my own. ## What is next More of the same, with the balance shifting. My work has moved down the stack, so more of what I hit now is kernels, networking, and isolation rather than browsers and Liquid. That will show up here. The Shopify material will keep going because four years of it does not evaporate and the problems are still interesting. The AI tooling posts will continue, because the failure modes are still changing month to month and [most of what is written about them is either promotional or dismissive](https://debugly.dev/ai-development-tools-i-actually-use/). And the error autopsies, because they are the ones that help somebody at eleven at night, which was the point of starting. Thanks for reading. If a post here saved you an afternoon, that is the entire objective, and if one was wrong I would genuinely like to know. --- Published on [debugly.dev](https://debugly.dev/) by [Rohit Bhadani](https://debugly.dev/about/) | Founder of [Krova Cloud](https://krova.cloud/?ref=debugly.dev)