Writing something out is an immensely valuable mental exercise. I find it clarifies thought, reveals areas of ignorance, and exposes assumptions.

But writing something for someone else? For a total stranger? That is both much more work and a very different kind of work. 

----
jml started a good series with some documentation themes earlier today; I figured I'd contribute another few ideas. The most immediate one comes up as a further point to the reposted card: your documentation should be based on _where the other person begins_

To clarify that a bit: find the crossover between implicit and necessary knowledge. "Setting up a vhost", for instance, presumes knowing what a vhost is

(this can be catered to the so-called target market consumers of the thing you're documenting)

----
Explain the motivation/reasoning. Understanding _why_ a thing is the way it is becomes a powerful stepping stone to using it better

----
Something to aim for is to impart *knowledge*, not *information*.

The latter is best found in reference manuals. The former is the thing that will allow a person to use your tool/product/whatever.

----
"Documentation is where information goes to die", to steal a quote from [jerith](https://twitter.com/firxen).

Make sure that you revisit what you write in documentation as often as you revisit the thing you're changing.