If you aren't writing the code you don't understand the problem and can't possibly write the documentation
Most importantly it doesn't tell us what we're not doing here, and why not.
I find myself adding comments to my own code when 6 months after the fact I'm re-discovering why something that looks casual is really important. Why that one "obvious " improvement or optimization is -not- done.
But that's documentation at the lowest level. Most of my documentation time (and I'll admit to writing a lot of docs) is about a bigger picture; hoe is the code used, what problems does it solve, how it interacts with the world and so on.
Documentation is not about writing the obvious "this increments x", its about making the code reusable, making it useful to yourself and your colleagues, my noting that it exists.
It I'd if you like the "search index" into the code.
In theory, this makes perfect sense and is a great way to amplify a more senior developer's impact compared to just coding "the hard stuff." In practice, unfortunately, this leads to a "doc culture" where there's often too much focus on the writing & documents and not enough on the coding & getting shit done.
For example, look at Amazon. Writing is considered a core SDE skill, yet atrocious code (especially from more senior "lifers") and shitty half-solutions are seemingly desirable. Promotion at Amazon is about telling a story of your impact in your promo doc, not about explaining to the powers that be that you're a kick-ass engineer who needs harder problems.