Would it help if, as someone on the other side that for the most part only plans as the feature is discussed on their head and then jumps into code, I say that the code is where I "document" my plans as types, comments, tests, and stubs, which I progressively expand into implementations?
On the same vein, I'd add that some languages greatly facilitate this process, while others make it more of a pain.
The "why" is pretty much the only reason to write comments!
Overviews of the problem are more in the realm of spec rather than implementation planning and is another issue altogether. Of course you need to know what you're solving, but it is my point that I don't need to write a detailed document on how I'm going to solve most everyday problems when I can jump into the code and progressively work from there using the tools provided by the language.
Most everyday problems don't need a doc to explain what you're going to do.
At my work though, if you're going to adopt a major framework or service, you need a doc explaining why you chose that one. It's a big decision that will last years.
