tech-articlelisted

# Tech Article — write a post that doesn't read like AI ## The one rule A technical article is **a story that contains technique**, not technique that tells a story. Open on the human problem (the bug, the outage, the bad call), tell what actually happened, then slide the technique inside. If the reader wants to know what happens next, you have won. If they bounce at the first code block, you lost on line one. ## Structure - **Hook (no heading)** — in medias res. A vivid, real moment. "The program had been running for three days. Memory was creeping up." Never "In this article we'll see...". - **Body — 4 to 6 H2 sections**, each 1-4 short paragraphs and, when it earns it, one code block. H2s are fragments, not questions: "The four leaks that always bite", "Why the stdlib was enough". The pattern that works: bad code (✗) then fixed code (✓), back to back. - **Conclusion (H2)** — short. NOT a recap. A meta-observation or the surprising lesson. "The value wasn't in writing the code. It was in the third security review." ## Voice - Direct, lightly ironic, self-deprecating about your own mistakes. - Talk to the reader as a peer engineer, not a beginner to lecture. - Sharp opinions, never hedged: "this is better because X", not "one might consider...". - Concrete: real numbers, real tool names, a lived situation. Never invent a stat or an incident. - Contrast of rhythm: short sentences to hit, medium ones to carry an argument. Read it aloud. If you stumble, cut. If it stutter