Writing Documentation: Teach, Don't Tell 211
Programmer Steve Losh has written a lengthy explanation of what separates good documentation from bad, and how to go about planning and writing documentation that will actually help people. His overarching point is that documentation should be used to teach, not to dump excessive amounts of unstructured information onto a user. Losh takes many of the common documentation tropes — "read the source," "look at the tests," "read the docstrings" — and makes analogies with learning everyday skills to show how silly they can be. "This is your driving teacher, Ms. Smith. ... If you have any questions about a part of the car while you’re driving, you can ask her and she’ll tell you all about that piece. Here are the keys, good luck!" He has a similar opinion of API strings: "API documentation is like the user’s manual of a car. When something goes wrong and you need to replace a tire it’s a godsend. But if you’re learning to drive it’s not going to help you because people don’t learn by reading alphabetized lists of disconnected information." Losh's advice for wikis is simple and straightforward: "They are bad and terrible. Do not use them."
Documentation vs Tutorial (Score:1, Insightful)
But for those of us who already know the basics of driving, a quick reference is much more useful than a didactically structured text. Documentation isn't supposed to be a tutorial.
Obviously documentation that tells you to read the code is useless, though.
Um, no (Score:3, Insightful)
From TFA: The purpose of technical documentation is to take someone who has never seen your project, teach them to be an expert user of it, and support them once they become an expert.
No. Experts in their field shouldn't need to be taught how to understand your system; that's part of being an expert ( or indeed, even a professional ). All documentation should be doing is explaining the sticky bits and providing details and/or examples ( whichever is relevant ).
Just my opinion of course. But having stepped in to countless networks/codebases, I can tell you that I just get annoyed when the documentation gets in the way of the information I need to complete my job.
Re:Source code (Score:5, Insightful)
Do you really want to read the source code for ssh every time you forget whether it's -p or -P to specify the port? (It's one for ssh and another for rsync...)
I don't get it :p (Score:1, Insightful)
API documentation is like the user’s manual of a car. When something goes wrong and you need to replace a tire it’s a godsend.
Great! That's exactly what API documentation is for.
But if you’re learning to drive it’s not going to help you because people don’t learn by reading alphabetized lists of disconnected information
If you want to learn to program you want to read tutorials not the API documentation...
The web and hyper text are a challenge (Score:5, Insightful)
As an author of three successful dead-tree programming books, I have a few observations.
1) I use the electronic versions myself because of easy search (better than an index) and copy/paste.
2) In book format, it's possible to lead a reader through topics in a sensible order that builds on prior topics.
3) The challenge with electronic/on-line documentation is that there is no expectation that readers will approach the material in any particular order. Readers type a search term into google and up pops a page or two of documentation. How can the author make safe assumptions about the definitions of terms and prior conceptual knowledge the reader will have? Adding links to the definitions of terms and links to chapter oriented conceptual documentation doesn't usually help because readers are impatient, and there is no good place in the middle of the documentation to start.
4) Many readers don't know the terms to type into google and therefore aren't lead to the relevant conceptual documentation even if they would have read it had they known.
A common language (Score:4, Insightful)
The article misses something critial - the use of common language.
The biggests example of this is HIS use of "user". A "user" for all my time in this business is the person sitting in front of the computer using the software to preform a business funtion... not programming a business function.
This leads to second issue a developer is person that uses an embedded function written by another developer - generally with a higher skill or at least akill peaked before the new developerl. That developer is trying to come up to speed about cause and effect of using a given piece of code and trusting the original developer actual did his job right.
How can you trust a person that says what documentation is to be, that cannot teach it following his own rules? The first rule of any teaching is placing terms that you are going to be using, to teach the others what you mean. You see this legal documents to prevent confussion of common terms being used in a more defined or limited manor.
Re:Stack Overflow (Score:5, Insightful)
Re:Docs vs tutorial (Score:5, Insightful)
WHile the difference between a textbook and a reference manual should be obvious to all, TFA still has a point: good documentation should include both.
Most docstrings I see are worthless: they add nothing to the code right below them. OTOH, a bit of tutorial-style documentation with examples can be golden. Often that makes well-written unit tests the best docs, or at the very least, if you're going to provide examples, they should also be unit tests - another test is always nice, plus you know your examples actually work.
Re:Driver's Manual (Score:4, Insightful)
My last owner's manual was about 400 pages; but contained only about 10 pages of useful information.
10 pages of useful information to you maybe. Other people will find some other 10 pages useful.
My mathematics textbook is 600 pages but there is only 1 page with the information that I need to solve a problem. Doesn't mean the book has only 1 page of useful information.
Re:Stack Overflow (Score:4, Insightful)
Re:Stack Overflow (Score:3, Insightful)
Same thing happens here. This is how your previous post got modded up.
Re:Um, no (Score:5, Insightful)
No. An expert may be an expert in an area, but until he's familiar with your code, he's not an expert in your system. I've spent way to much time deciphering code where a single sentence explaining what the hell the code was doing would have saved time. If you had enough time to write the system, you have enough time to document it. And if it's hard to document, that's a hint that it's a crappy system.
Re:Wikis are not magical, but they are not bad (Score:4, Insightful)
With regard to technical documentation, wikis are where knowledge goes to die a horrible and lingering death.
Re:Docs vs tutorial (Score:5, Insightful)
Actually, no there isn't. A tutorial is one type of documentation. Tutorials are documentation for processes. Non-process subjects require other approaches. It is important to write the right types of documentation based on the likely audience and the subject matter.
I disagree with many things in this article, not because the points are invalid, but because they conflate misuse of tools with low quality of tools. For example:
Wikis are great tools for writing documentation. They make it easy for people to fix minor errors when they notice them. They make it easy to collaborate on documentation without having to deal with the relatively high overhead of source code version control systems (which are particularly awful when merging structured content like XML and HTML).
What the author is complaining about is not the wiki, but rather the fact that those projects have no one who is responsible for maintaining the documentation. If no one is responsible for writing the docs and ensuring their completeness, the documentation will inevitably be half-finished, whether they use a wiki or some other mechanism. The wiki is not an alternative to writing documentation, but rather is a tool for creating documentation.
Doc generation software is great for writing reference documentation. By placing the content into the source code, it becomes the responsibility of the programmer to update any behavior changes when they modify the behavior of a function. It also means that the documentation for the function is easily readable right there in the source code when you're trying to understand a function. By producing the generated documentation, you then have a convenient reference for all your functions, methods, classes, data types, etc. that is readily searchable, indexable, and (perhaps most importantly) is viewed in a separate app or window from your source code so it doesn't force you out of your coding flow when you need to look something up.
Once again, what the author is complaining about is not the doc generation tool, but rather the fact that those projects have no one who is responsible for writing the documentation. When used properly, the output of doc generation tools is every bit as good as documentation produced by hand. However, it takes exactly as long to write that documentation in the source code as it does to write it in a word processor. It is not a tool for saving time, but rather a tool to aid in maintaining consistency between behavior and documentation.
To do software-generated documentation correctly, you need to add comments that explain every field in every data structure, every class, every function or method, and for particularly complex functions, even documentation for many of the local variables. You should write code in your build system to warn about undocumented methods and data structure fields. For example, in one project I regularly work on, there are almost 17,000 lines of documentation comments out of just shy of 59,000 total lines of code—a whopping 28.8% of the total code volume. The result is that it is fairly easy to learn what each piece does in the context of the code while you're looking at it, and the automatically generated documentation is pretty thoroughly fleshed out reference documentation for the project. One particularly complex class by itself produces a whopping 72 pages of reference documentation.
The problem that folks run into is that they usually don't put in any doc comments at all, or at best don't actually take the time to write the thorough comments that are needed to make the output from automatic reference documentation tools be useful. As a result, when you build the reference docs, you end up with an empty skeleton that isn't of much value at all. This is not a flaw in the tool; it is a flaw in the development team. They didn't take the time to write the documentation.
And so on.
Re:Stack Overflow (Score:4, Insightful)
The blind leading the blind. People who can't tell good answers from bad upvote bad answers. Try searching for some topic that you know a lot about and see what I mean.
I've seen a lot of things said about Stack Overflow, but this has been something that's consistently said that I've never been able to substantiate. I've seen questions with no good answers where some of the poor ones have received some upvotes, but where there's an actual good answer — something that you can check for yourself because a good answer will be one that includes a description of what to do — it tends to attract upvotes over time. (Which answer is accepted is more variable, as that's the gift of the person asking the question.) While there's a bit of cult following going on (i.e., voting someone up because of who they are) it is relatively rare because most of the highly rated people are that because they tend to give good answers.
Typically, where a question has what you think are bad answers receiving upvotes, that's either because you've misunderstood the question (duh!) or because the question itself was poorly asked. Which sucks a lot but happens. If you think you can provide a better answer than the ones that already exist, then write that answer and don't whine about it! (Bear in mind that good answers can pull in reputational increases over a number of years; one of my answers from 3 years ago pulled in a vote yesterday. It's a long-haul game.)
Re:Source code (Score:5, Insightful)