Documentation writers tend to rise from two distinct places. Either they are the folks who developed the software, and now feel the need to explain it, or they are users of the software who have gained a certain expertise and wish to share it with others.

Each of these groups has different challenges in writing the documentation. The developers of the software tend be too close to the product, and since everything is immediately obvious to them, they will overlook telling you about the things that you very well might most need to know. The experienced users, on the other hand, know only what they see in using the product, and so may miss some important hidden feature that the developers would know about.

Both groups tend to share a common failing. Because they are so familiar with the product, albeit in different ways, they are somewhat out of touch with the end-user who is trying to understand the product without any previous knowledge. The experienced users, because they learned things the hard way, by experimentation and hard work, and the developers, because they created it, have different perspectives, but a similar limitation.

At the heart of this failing is a lack of understanding of the users, and their needs.

Whichever one of these groups you come from, your primary goal as a documenter is to understand your audience, and provide them with the information that they're looking for. Anything you write without this understanding will be better than nothing at all, but won't be as good as it could be.

There are several ways to achieve this understanding.

* Use the software
* Participate in the mailing lists
* Participate in the IRC channel
* Read the bugs database, paying particular attention to the bugs that get marked as 'invalid'