Some best practices for technical documentation
Begin with the end in mind. The object of the game is always to save time and reduce frustration for the person reading the documentation. In everything you do, think about how well you are accomplishing that goal.
Test drive the documentation. When you write instructions, follow your own steps to verify them. You'll discover details that you might have left out, and you'll occasionally spot a bug in the software.
Remember that you know too much. The most common error is to leave something out because of the assumption that everyone else knows. Shortly after you begin to work on a product, you have internalized concepts and architectural details that customers have forgotten or never knew. Another obstacle for developers is that the people who use the software may not have the same background as the team that made it. Similarly for technical writers, it's easy to assume that all developers know how to do everything. Before you tell customers to do something that you think is simple – like generate public and private keys or unpack a tarball – ask yourself whether an example might help some people. If you're a developer and you really struggle with this one, ask some people who are technically savvy but unfamiliar with the project to do a test drive for you, so they can tell you if they get stuck.
Answer the "so what" question. Sometimes people need to know why you're bothering to share the information. Usually this means explaining when and why a feature would be useful for them (or an attribute in the case of an API).
Use a two-review system. First, ask someone from the development team to answer questions and then review the documentation. Second, ask a QA engineer to verify that the docs are functionally correct.