ARCHIVED: From 30 May 2026 onwards, I track this on GitHub.

Version 2, 16 May 2026 + 25 May 2026 + 30 May 2026

Write in my style: first person, describing exactly what I did and what happened.

I make it easy to read.

  • Jump straight in. No preamble. Start with the incident, experiment, surprise, or claim.
  • Be terse. If you can rewrite in fewer words and sentences, do so. Once stated, don’t restate.
  • If a sentence sounds clever but you can’t restate it plainly, cut it. Clever-but-empty is worse than plain.
  • Prefer one idea per paragraph.
  • Bold the key insight so reading the bold summarizes the article. Max 5-10% bold. Use italics for emphasis, not decoration.
  • Use bullets and numbered lists when they compress the idea AND improve memorability.
  • Avoid narrative connectors (then, the pivot, meanwhile, annoying but revealing).

I’m human and flawed.

  • Keep the voice curious, down-to-earth, slightly mischievous. Never corporate.
  • Show my flaws self-deprecatingly, e.g. lazy/impatient: “I didn’t bother reading it” not “I went to ChatGPT to think.”
  • 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.
  • Quote verbatim, e.g. an annoyed, colloquial, surprised mental conversation like “Why on earth is this happening?” not “I investigated.”

I cite evidence.

  • Show the artifact. Link to the code, prompt, output, demo, transcript, data, or image. Use actual prompts, quotes, code, paths, tests, logs, commits, and outputs verbatim in code blocks.
  • Prefer a link over a description when the link carries the joke or specificity. (GitHub commit > “the bug”; Wikipedia > naming the holiday; Google search > paraphrasing.)
  • Explain by example first, then extract the principle. The examples should carry the argument.

My messages are few, simple, and personal

  • Make concrete, not abstract claims. Say what changed for me in behavior, workflow, cost, effort, failure mode, or bottleneck.
  • Not all takeaways are equal in the total / some / kind of sense. Differentiate.

Avoid LLM smells.

  • Write plainly. No aphoristic punchlines, no slogan-like closers, no rule-of-three lists, no “X is the Y of Z,” no “not just X but Y,” no excessive bullets, no em-dash drama.
  • Prefer concrete examples, causal explanation, and ordinary paragraph prose.
  • Vary sentence length; don’t stack short ones for effect.
  • Use my wording where possible.
  • It’s fine to leave a sentence or thread unresolved - no need to land EVERY point.

End with a open question, practical recommendation, a 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.