Comment by 01HNNWZ0MV43FF
18 hours ago
I've also found these guidelines helpful:
1. In general, do whatever Wikipedia does. e.g., start with a one-sentence definition, then a couple paragraphs of summary, then go into short specified sections, and keep links to the "Citations" at the end. It's been refined for 25 years, it's older than most of your engineers, it's 50+% correct by default.
2. Keep every section to one screenful. If your reader can't see a headline, they get lost.
3. Put a funny picture at the top of the page. Or at least something off Wikimedia Commons.
4. Don't spend a lot of time writing anything. And don't use AI. The AI doesn't know what's inside your head. You yourself have an inkling. The longer you write, the further you'll get. Just write one short thing at a time and refactor aggressively later. Never throw shit over a fence blind. Nobody reads shit that's been flung over a fence.
Steven King said writing is telepathy. All mediated communication sits on a Pareto trade-off with face-to-face communication. Media is always less interactive with slower iterations. You need to figure out exactly what your audience needs, right when they're reading, and write just that, knock 'em dead, and leave. Don't add detail. They'll ask if they need detail.
> start with a one-sentence definition, then a couple paragraphs of summary, then go into short specified sections, and keep links to the "Citations" at the end. It's been refined for 25 years, it's older than most of your engineers, it's 50+% correct by default.
I went to a documentation workshop at Pycon UK by Daniele, and this was actually quite similar to his approach for writing front pages for documentation. He'd give the same questionnaire to a few teams, with prompts like "in one sentence, what is this product?", "What can a user accomplish with this product?", "Who are the primary users of this product?" Once everyone's aligned on answers, the page writes itself.