Documentation is about keeping/sharing information in any form that is not executable to help collaborators understand the software. I would argue that code can be self documenting and documentation is unnecessary, but that's a topic for another day. The following are the forms of documentation, ranked from best to worst.

• Filename/Directory structure is equivalent to good class/method/variable name but often ignored, especially in heavily collaborative repo.

• Diagram is great at illustrating complex system. And since it restricts the amount of text allowed, only the critical information are preserved, thus is less likely to be stale since it doesn't carry all the implementation details. It is for sure time consuming (expensive) to make good diagram, but the benefit/cost ratio is pretty good. I had a great experience creating a diagram for a data pipeline using UML.

• Design doc is great at communicating design specs and easy for modern SEO, or to correct/update.

• Meeting is usually what engineers hate. I personally like meeting (since I don't really have too many), because it is interactive and always up to date, and I can learn exactly what I need to learn in less time than using google/SE. The problem of meeting is that it is expensive and ephemeral, a meeting with 10 engineer involved is costing $1000/hr. So I think there should be a function that limits the duration of meeting based on the number of participants.

• Video recording is relatively cheap and long-lasting, but it is bad. It is almost impossible to edit if information is stale and can't be used with SE, making information retrieval long and inefficient.

• Comment is the worst enemy of software development IMO. It gives people an excuse to write bad code, messes with code search, and leads to a rabbit hole that makes life miserable (at which point cost is irrelevant). We don't code in binary anymore, don't write comment.