An often overlooked benefit of writing documentation (regardless of whether anyone will read it) is that it forces you to explain everything in a structured way and discover things that can be improved or simplified.
> "We've just made an offer to a new writer", [Chris Espinosa] told [me (Andy Hertzfeld)], "someone who I think will do a much better job on the technical side of things, since she used to be a programmer. Her name is Caroline Rose. I'm going to assign her to the window manager documentation and see what you think."
> The next week I sat down to meet with Caroline for the first time, and she couldn't have been more different than the previous writer. As soon as I began to explain the first routine, she started bombarding me with questions. She didn't mind admitting it when she didn't understand something, and she wouldn't stop badgering me until she comprehended every nuance. She began to ask me questions that I didn't know the answers to, like what happened when certain parameters were invalid. I had to keep the source code open on the screen of my Lisa when I met with her, so I could figure out the answers to her questions while she was there.
> Pretty soon, I figured out that if Caroline had trouble understanding something, it probably meant that the design was flawed. On a number of occasions, I told her to come back tomorrow after she asked a penetrating question, and revised the API to fix the flaw that she had pointed out. I began to imagine her questions when I was coding something new, which made me work harder to get things clearer before I went over them with her.
When I write documentation. I'm often at a point where I ask myself: do I document this small inconsistency/inconvenience, or do I just remove/fix it?
Often enough it's easier to make things more consistent than both documenting the inconsistency and getting people to read the docs and stop asking about it.
I remember well one time long ago when I did that.
I had done the firmware for a piece of hardware that had some DIP switches to configure. I was having trouble doing the documentation for what each switch did and when you would want to configure it a particular way. Finally I realized it was because the switches weren't laid out logically, so I wrote the documentation the way I thought it should work then changed the code to match the documentation. Win-win, easier documentation and easier to use hardware.
This is similar to what I've found, in that writing documentation for a product before I've written any code actually makes the product turn out better. When in design / development mode, I tend to think of all kinds of "cool" features to put in, but since using them requires knowledge of my state of mind at the time I designed them, it gets very difficult to document these features.
So I end up writing the end-user documentation, then build a specification from there (functional requirements), then work on the technical design while prototyping various elements. Stringing together the prototypes often then ends up in a finished product.
Sounds similar to teaching a subject, or making a presentation about it. You will be forced to learn it very thoroughly yourself. "best way to learn something is to teach it to someone else".
I've only posted about 1/3 of the Stack Overflow questions I've written. Forcing myself to break the problem down into a clearly explained question often brings a solution to mind or at least gives me a few new paths to go down, which often leads to an answer.
Same principle as rubber duck debugging.