If you don't have a clear characterization of the problem, for example, you're unlikely to develop a clean solution. Learning how to document software is hard, and it requires mature engineering judgment. It's vital to document only the right things. The documentation is no help to anyone if its length discourages people from actually reading it. Novices are often tempted to focus their efforts on the easy issues, since these are easier to document.
Novices also tend to be reluctant to document problems.
You'll spare the reader time puzzling over something that appears to be wrong, you'll remember where to look yourself if you run into problems, and you'll end up with a more honest and useful document. Another issue is when to document. Although it sometimes makes sense to postpone documentation while performing experiments, experienced developers tend to document systematically even temporary code, initial problem analyses, and draft designs. They find that this makes experimentation more productive. Furthermore, since they've established habits of documentation, it feels natural to document as they go along.