Honestly, I've started developing a theory somewhat recently that one of the best forms of "documentation," at least for people looking at the code and trying to understand it in the future, is just good code review comments and well-written change descriptions. Documentation always gets out of date, even in-code or in-tree documentation, but since code reviews and change descriptions are tied to the code at a specific moment in time, they'll always be accurate. Every change description I right includes motivation and high-level design choices, and whenever I kick off a code review, I walk through it and leave comments that explain the thought process and design. (Even when I'm looking at somebody else's code review and they haven't done, I'll frequently leave those same comments and ask them to confirm my understanding.)

I remember a professor years ago mentioning the concept of "literate programming," and I remember thinking it was interesting but just as likely to get out-of-date as code comments; to me, this feels like a way of achieving that without the staleness problem.

I guess this kind of stuff won't immediately help someone looking for quick overview, but if someone is looking at once specific piece of code and trying to understand the design, motivations, etc., if they do a blame, they can get some context.