--- title: Anand Blog Style date: 2026-05-11T21:18:41+08:00 lastmod: 2026-05-16T13:45:00+08:00 description: I codified my personal blogging style to prioritize first-person narratives, terse sentences, and immediate starts. I emphasize showing artifacts like verbatim code and prompts while documenting failures, awkward edge cases, and concrete implementation details over abstract framing. keywords: [technical writing, blogging, style guide, first-person narrative, minimalism, prose style] --- ## Version 2, 16 May 2026 - Write in first person, describing exactly what I did and what happened. - Jump straight in. No preamble. Start with the incident, experiment, surprise, or claim. - Be terse: short sentences, short paragraphs. Prefer one idea per paragraph. - Use a conversational, technical voice. Curious, practical, slightly mischievous. Never corporate. - Show the artifact. Link to the code, prompt, output, demo, transcript, data, or image. Use actual prompts, quotes, code, logs, and outputs verbatim in code blocks. - Explain by example first, then extract the principle. The examples should carry the argument. - **Bold the key insight** when it helps scanning. Use italics for emphasis, not decoration. - Use bullets and numbered lists when they compress the idea. Keep them punchy. - Use `---` to separate turns in the story or shifts in the argument. - Include the awkward bits: what failed, what surprised me, where I cut corners, where the tool behaved strangely, what I misunderstood. Parenthetical asides are welcome. Dry humor is welcome. - Prefer concrete claims over abstract framing. Say what changed in behavior, workflow, cost, effort, failure mode, or bottleneck. - When writing about AI, focus less on magic and more on the new bottleneck: verification, context, taste, integration, responsibility, or adoption. - When writing about tools, name the boring implementation details: file formats, commands, paths, tests, commits, edge cases, and failure reports. - End with a punchy takeaway, practical recommendation, or self-aware observation. Do not over-explain the ending. ### Spoken cadence My talks often use live examples, then a plain-language reframe: - "So, I tried this..." - "This is what happened." - "The weird thing is..." - "So, what that means is..." I use sharp claims, then immediately soften or ground them with examples. I am comfortable saying "I don't know" and then sharing what I'm learning. In talk-to-blog conversions, I keep the spoken energy, surprise, example, punchline, and implication, but remove fillers. ## Version 1, 11 May 2026 Write in first person, describing exactly what you did and what happened. Be terse: short sentences, short paragraphs. Jump straight in -- no preamble. Show actual prompts, quotes, code, ... verbatim in code blocks. **Bold the key insight** in each point. End with a punchy one-line takeaway or self-aware observation. Include the awkward bits (what failed, what surprised you, where you cut corners). Parenthetical asides for dry humor. No padding. Use --- for section breaks.