Documentation has a difficult job. It needs to be complete enough to answer real questions, but clear enough that a reader can find the part that matters to them.
I have opened many guides that begin with a long history of the project before telling me how to use it. Background can be valuable, but the reader often arrives with a question already in mind. Help them get oriented, then let them choose how deep to go.
Put the useful path first
A good starting point says what the thing does and shows the shortest route to a working result. After that, explain the options, edge cases, and reasons behind the design.
This order respects different readers. Someone evaluating a tool can try it quickly. Someone integrating it can continue into the details. A person who needs the background can find it without making every other reader pass through it first.
Examples should earn their space
An example is more than decoration. It should answer a likely question and work as written. If it leaves out a required setting or uses a made-up value without saying so, it creates another puzzle for the reader.
I find a small, complete example more useful than a page of fragments. It gives me something to adapt and a way to tell whether I understood the instructions.
Write for the moment of use
People read documentation while they are trying to do something. They may be new to the project, short on time, or trying to diagnose a failure. Clear headings, direct language, and examples reduce the effort between a question and an answer.
The best documentation leaves room for the reader to explore. It gives them a clear entrance, then gets out of the way.