When I come across bad documentation (which is often), by far the most common problem I find is that the information I needed just plain isn't present.
Articles like this one really aren't helping. If you wrote a piece of software I'm using that doesn't make you my teacher. It makes you someone offering a contract, and what I need to know is what that contract says.
The first duty of your documentation is to be complete and correct. Unless you've got that sorted, no amount of "putting yourself in the student's place" is going to give adequate results.
There's another more thorough version from the same author, for what it's worth. Just moved on from that company but the overall points are the same https://diataxis.fr/
It is explained well in the video, well worth watching.
Tutorials are teaching a method, like which ends of the pliers you grab. They do not assume a lot of domain knowledge.
HowTos pick the user up where she stands with a concrete problem and walks you through a possible solution of that specific problem. Like how to use pliers to twist a wire just firmly enough to hold two things together.
Right! The good old days when the software used to come in a box with several varied width books containing all these Four, and one named Getting Started.
This same set could be easily "transposed" to the contemporary world of web. With all the proper indexing. Why is this "art" "lost" for most of the software :-( ...
BTW, one Excellent incarnation of this documentation art is on the front page right now:
> Why is this "art" "lost" for most of the software.
Before the internet, the printed book was all you really got. That meant the company distributing the software had to hire technical writers who'd work with the software devs to create all of this, send it to an editor, and ultimately get published.
We no longer live in an era where tech companies hire tech writers. Software documentation lacking is something that can and limp along with jira cases and support services sold rather than trying to put in the upfront effort to fix everything.
Now, for open source software, hate to say it but the docs have always been pretty crap. Certainly some stands out (usually when the business model was around providing services on top of open source software), but nobody is really paying anyone and few people really want to do that sort of free labor.
The downside to all that was software releases happened once every year (or longer). Which, was it actually all that bad, but let’s not be completely wooed by the green looking grass on the other side. There were long delays between new features or bug fixes.
I suspect all many documented projects died because people couldn't figure out how to use them. By natural selection, anything that survived the good old days is either obvious or well documented. The C programming language, for example.
> By natural selection, anything that survived the good old days is either obvious or well documented
Or so much better than the competition that people use it in spite of poor documentation. Many things like that also grow a cottage industry of people making documentation and teaching (see React or Rails).
The docs are there. The information is there, but finding it, is so difficult, that I have often just said "bugger this for a lark," and written my own implementation.
There's two types of docs: The teaching kind, as the article mentions, and the reference kind, for helping folks that already have a start, to find what they need.
I generally do the second. It can be fairly easily generated from inline headerdoc comments, these days, but we still have the issue of indexing, and I still have my work cut out for me, there.
I actually like re-writing documentation, but if I can not reorganize the documentation too I am discouraged from re-writing. I believe a lot of contextual information is lost when people use confluence as a dumping ground and don't plan the structure of the documents.
I've emotionally moved to git for documentation, but I can not get people to follow or transition to better documentation methods once someone is emotionally tied to tribal knowledge and communication.
I agree that this article isn't doing something for me.
It barely covers the important points of what _should_ be done, and spends a lot of time lampooning bad approaches to documentation.
I also found the metaphor of "the black triangle" obscured the main point of that part of the argument, which to me was "have some foolproof basic starter setup to get a user up and running quickly".
The article is quite a bit smarter (if a bit long) than this comment. "The first duty of your documentation is to be complete and correct". The source code satisfies this demand. It is complete and it truly describes the product in all its details. But now we are stuck in 'act 1' of the article. So maybe we need some more helpful hints. O wait, there is an article called 'Teach, Don't Tell' that provides these helpful hints.
Also, it's much harder to parse multiple files than one doc. Been there, done that, aplenty. Yes, I can find the answer, but that isn't sufficiently going to make it easier. Plus, if one admits the docs are bad because "the source answers that type of in-depth question", then are the docs not still bad?
The bad documentation I come across often shows every sign of having taken the advice from this article (and others like it) to heart.
The trouble is that the advice doesn't include ways to make sure your documentation actually covers everything it has to.
What this article says is that you should have « "API documentation" for every user-facing part of your project. »
That commonly leads to "reference" pages which are very little better than the autogenerated documentation the author dismisses. The main problems tend to be that behaviour that isn't controlled by a specific command or function or configuration setting doesn't get documented at all, and that commands with complex behaviour get described using terms that themselves need further definition which isn't provided anywhere.
My experience is that the main problem with online documentation is that it doesn't include links to separate tutorials, but has plenty of links to more documentation, leading you to wander from page to page without destination trying to find that one page that actually explains what you're trying to do or infer it from fragments of information scattered around the documentation.
For example, in Qt you have a view class, a model class, and a selection model class, and none of their pages tell you how to actually select something programmatically. You have to guess or ask ChatGPT these days.
I love good docs like everybody else here. But I also have to admit that my own documentation is sub-par. For example the various internal git repos I own and share, do not provided up to date documentation on how to build, deploy etc. Things are moving fast and updating the docs ends up taking the back seat.
However, I have started using AI to update the README.md lately, and it does a really good job. I review what it creates/updates based on my changes and if looks correct, I check it in. This allows me to focus on stuff the AI cannot do. Yet.
I have the opposite opinion. Most often, I'm looking for documentation that gets to the point. Just give me a straight answer so I can minimize time I spend reading docs and maximize time I spend using the thing. Tutorials tend to be annoying to read because there's a lot of information unrelated to the topic (setup, advice for beginner programmers) and important information that is missing because the tutorial inevitably chooses one use case and ignores the others.
If I had to pick, I'd rather a dev tell instead of teach. Other people will inevitably write their "how to do x in y" medium articles anyway. These days you can even get an LLM to write it for you, if there's docs that "tell".
I know the thread is about good docs, but the title caught my eye. I have been trying to teach my coworkers new tools and techniques for some time. Instead of telling them. It is very very hard. Not everybody is open to being taught. People get married to old ways of doing things and are very very resistant to change.
I have a colleague who prioritizes maintaining control over teaching others. He tries to force a particular perspective, emphasizing the importance of his role while fostering dependency rather than sharing knowledge. This seems driven by a fear of losing his job.
My primary focus is backend development, where I assist developers and solve infrastructure challenges. However, I’m so effective in this role that I often end up boxed into it. I’ve been making an effort to expand into frontend development to broaden my expertise, but this colleague operates in that space and isn't the only one who has made it difficult for others to gain traction.
I agree with another commenter that this doesn't tell the entire story, but it tells almost all of it. Nowadays, I discover some new piece of software, visit the Documentation section of its website, and the first thing I see is `How to build SuperMung on the Whizzbang 47 using Mark Williams C'. I have no idea what SuperMung is for, how to use it, what errors I might make, and how to install it on Debian. Similarly, I go to the website for a new programming language, see some examples that give me little insight into what it is for, and find not even an incomplete language specification.
Proper documentation leads me by the hand, starting on what the software is for, what platforms it runs on, some examples of its use (including examples that show how it is useful for solving real-life problems), a thorough tutorial on how to use it, and finally a complete and properly indexed/searchable reference.
Back in the 1980s, I got myself in trouble: I promised a 100-page manual for a software system I had written, and I decided to do it in the then-new TeX. But this was before The TeXBook was published. So I learned TeX by reading the literate source for the code. The manual was duly ready on time, and served the literally thousands of students who relied on it for the next few years.
But when I finally got a copy of The TeXBook, I was astonished by how little I had actually known about using TeX. I had presumably been mostly using it to answer questions such as “why doesn't this work?”, and a lot of the overall principles had simply not been apparent to me. Once I had learned TeX properly, I learned a great deal about how it all worked by going back and reading the literate source. Knuth is a brilliant (if highly idiosyncratic) programmer.
My point here is to emphasize that when someone releases software, their job is not done unless people can learn to use it. That doesn't just mean completeness and accuracy, but a through-line, apparent to the reader, from learning what it does all the way to mastering it, along with the kind of reference information needed when using it.
This article is primarily about making documentation more effective for learning, not about replacing technical completeness. The best approach combines both perspectives rather than treating them as an either/or proposition.
Signals And Threads (a Jane Street podcast) had an interesting discussion about documentation [0]. There was also an interesting reference to literate documentation (I think similar to Jupyter notebooks but as documentation).
Good docs are rare like unicorns with a glowing horn.
It doesn't seem to move the needle like a shipped feature does, requires guessing other peoples' perspectives, involves devoted time and effort (that could, you know, be spent on actually useful things) and the effects of not doing it are invisible (but real: user rage, frustration and wasted time).
Only when the importance of good docs is understood will any effort be invested into it. It should be important if the goal is to have more people using something.
When I come across bad documentation (which is often), by far the most common problem I find is that the information I needed just plain isn't present.
Articles like this one really aren't helping. If you wrote a piece of software I'm using that doesn't make you my teacher. It makes you someone offering a contract, and what I need to know is what that contract says.
The first duty of your documentation is to be complete and correct. Unless you've got that sorted, no amount of "putting yourself in the student's place" is going to give adequate results.
There are 3 types of documentation:
1. Why/what 2. API spec 3. Tutorial
You need all 3. They are distinct, use different styles, and exist for different purposes and audiences.
You actually need four https://docs.divio.com/documentation-system/
Explanation (why, what)
reference (API spec)
tutorials
How to guides
There's another more thorough version from the same author, for what it's worth. Just moved on from that company but the overall points are the same https://diataxis.fr/
Would have been great if they organized this document exactly as they propose. But they don’t? Which is a bit weird to be honest.
What is the difference between "Tutorials" and "How to guides"?
It is explained well in the video, well worth watching.
Tutorials are teaching a method, like which ends of the pliers you grab. They do not assume a lot of domain knowledge.
HowTos pick the user up where she stands with a concrete problem and walks you through a possible solution of that specific problem. Like how to use pliers to twist a wire just firmly enough to hold two things together.
I like the concept. I will note the same thing I said further down though:
Why don’t they use their proposed system to explain their own system?
It seems like a wasted opportunity. So odd. Or am I missing something?
Right! The good old days when the software used to come in a box with several varied width books containing all these Four, and one named Getting Started.
This same set could be easily "transposed" to the contemporary world of web. With all the proper indexing. Why is this "art" "lost" for most of the software :-( ...
BTW, one Excellent incarnation of this documentation art is on the front page right now:
https://news.ycombinator.com/item?id=43381627
> Why is this "art" "lost" for most of the software.
Before the internet, the printed book was all you really got. That meant the company distributing the software had to hire technical writers who'd work with the software devs to create all of this, send it to an editor, and ultimately get published.
We no longer live in an era where tech companies hire tech writers. Software documentation lacking is something that can and limp along with jira cases and support services sold rather than trying to put in the upfront effort to fix everything.
Now, for open source software, hate to say it but the docs have always been pretty crap. Certainly some stands out (usually when the business model was around providing services on top of open source software), but nobody is really paying anyone and few people really want to do that sort of free labor.
The downside to all that was software releases happened once every year (or longer). Which, was it actually all that bad, but let’s not be completely wooed by the green looking grass on the other side. There were long delays between new features or bug fixes.
I suspect all many documented projects died because people couldn't figure out how to use them. By natural selection, anything that survived the good old days is either obvious or well documented. The C programming language, for example.
> By natural selection, anything that survived the good old days is either obvious or well documented
Or so much better than the competition that people use it in spite of poor documentation. Many things like that also grow a cottage industry of people making documentation and teaching (see React or Rails).
Thanks! Knew I was missing something. I guess in my mind tutorials and howtos merged :D
Making these 3 from static websites generated from docstrings is a multi-billion dollar industry called LLMs.
A docstring won't contain the necessary context for "why", and is something I see coding assistants get consistently wrong without human data.
OTOH doctrines at least have a slight chance of being updated along with the code.
My biggest peeve, is bad indexing.
The docs are there. The information is there, but finding it, is so difficult, that I have often just said "bugger this for a lark," and written my own implementation.
There's two types of docs: The teaching kind, as the article mentions, and the reference kind, for helping folks that already have a start, to find what they need.
I generally do the second. It can be fairly easily generated from inline headerdoc comments, these days, but we still have the issue of indexing, and I still have my work cut out for me, there.
Here's some stuff I wrote about my approach to documentation: https://littlegreenviper.com/leaving-a-legacy/
Absolutely this! If I have to use a search box to find docs and not the navigation pane you know you're doing something wrong with your docs.
I actually like re-writing documentation, but if I can not reorganize the documentation too I am discouraged from re-writing. I believe a lot of contextual information is lost when people use confluence as a dumping ground and don't plan the structure of the documents.
I've emotionally moved to git for documentation, but I can not get people to follow or transition to better documentation methods once someone is emotionally tied to tribal knowledge and communication.
I agree that this article isn't doing something for me.
It barely covers the important points of what _should_ be done, and spends a lot of time lampooning bad approaches to documentation.
I also found the metaphor of "the black triangle" obscured the main point of that part of the argument, which to me was "have some foolproof basic starter setup to get a user up and running quickly".
The article is quite a bit smarter (if a bit long) than this comment. "The first duty of your documentation is to be complete and correct". The source code satisfies this demand. It is complete and it truly describes the product in all its details. But now we are stuck in 'act 1' of the article. So maybe we need some more helpful hints. O wait, there is an article called 'Teach, Don't Tell' that provides these helpful hints.
> The source code satisfies this demand.
If it's available...
Also, it's much harder to parse multiple files than one doc. Been there, done that, aplenty. Yes, I can find the answer, but that isn't sufficiently going to make it easier. Plus, if one admits the docs are bad because "the source answers that type of in-depth question", then are the docs not still bad?
The bad documentation I come across often shows every sign of having taken the advice from this article (and others like it) to heart.
The trouble is that the advice doesn't include ways to make sure your documentation actually covers everything it has to.
What this article says is that you should have « "API documentation" for every user-facing part of your project. »
That commonly leads to "reference" pages which are very little better than the autogenerated documentation the author dismisses. The main problems tend to be that behaviour that isn't controlled by a specific command or function or configuration setting doesn't get documented at all, and that commands with complex behaviour get described using terms that themselves need further definition which isn't provided anywhere.
My experience is that the main problem with online documentation is that it doesn't include links to separate tutorials, but has plenty of links to more documentation, leading you to wander from page to page without destination trying to find that one page that actually explains what you're trying to do or infer it from fragments of information scattered around the documentation.
For example, in Qt you have a view class, a model class, and a selection model class, and none of their pages tell you how to actually select something programmatically. You have to guess or ask ChatGPT these days.
I love good docs like everybody else here. But I also have to admit that my own documentation is sub-par. For example the various internal git repos I own and share, do not provided up to date documentation on how to build, deploy etc. Things are moving fast and updating the docs ends up taking the back seat.
However, I have started using AI to update the README.md lately, and it does a really good job. I review what it creates/updates based on my changes and if looks correct, I check it in. This allows me to focus on stuff the AI cannot do. Yet.
I have the opposite opinion. Most often, I'm looking for documentation that gets to the point. Just give me a straight answer so I can minimize time I spend reading docs and maximize time I spend using the thing. Tutorials tend to be annoying to read because there's a lot of information unrelated to the topic (setup, advice for beginner programmers) and important information that is missing because the tutorial inevitably chooses one use case and ignores the others.
If I had to pick, I'd rather a dev tell instead of teach. Other people will inevitably write their "how to do x in y" medium articles anyway. These days you can even get an LLM to write it for you, if there's docs that "tell".
I know the thread is about good docs, but the title caught my eye. I have been trying to teach my coworkers new tools and techniques for some time. Instead of telling them. It is very very hard. Not everybody is open to being taught. People get married to old ways of doing things and are very very resistant to change.
I have a colleague who prioritizes maintaining control over teaching others. He tries to force a particular perspective, emphasizing the importance of his role while fostering dependency rather than sharing knowledge. This seems driven by a fear of losing his job.
My primary focus is backend development, where I assist developers and solve infrastructure challenges. However, I’m so effective in this role that I often end up boxed into it. I’ve been making an effort to expand into frontend development to broaden my expertise, but this colleague operates in that space and isn't the only one who has made it difficult for others to gain traction.
I agree with another commenter that this doesn't tell the entire story, but it tells almost all of it. Nowadays, I discover some new piece of software, visit the Documentation section of its website, and the first thing I see is `How to build SuperMung on the Whizzbang 47 using Mark Williams C'. I have no idea what SuperMung is for, how to use it, what errors I might make, and how to install it on Debian. Similarly, I go to the website for a new programming language, see some examples that give me little insight into what it is for, and find not even an incomplete language specification.
Proper documentation leads me by the hand, starting on what the software is for, what platforms it runs on, some examples of its use (including examples that show how it is useful for solving real-life problems), a thorough tutorial on how to use it, and finally a complete and properly indexed/searchable reference.
Back in the 1980s, I got myself in trouble: I promised a 100-page manual for a software system I had written, and I decided to do it in the then-new TeX. But this was before The TeXBook was published. So I learned TeX by reading the literate source for the code. The manual was duly ready on time, and served the literally thousands of students who relied on it for the next few years.
But when I finally got a copy of The TeXBook, I was astonished by how little I had actually known about using TeX. I had presumably been mostly using it to answer questions such as “why doesn't this work?”, and a lot of the overall principles had simply not been apparent to me. Once I had learned TeX properly, I learned a great deal about how it all worked by going back and reading the literate source. Knuth is a brilliant (if highly idiosyncratic) programmer.
My point here is to emphasize that when someone releases software, their job is not done unless people can learn to use it. That doesn't just mean completeness and accuracy, but a through-line, apparent to the reader, from learning what it does all the way to mastering it, along with the kind of reference information needed when using it.
This article is primarily about making documentation more effective for learning, not about replacing technical completeness. The best approach combines both perspectives rather than treating them as an either/or proposition.
compare https://docs.divio.com/documentation-system/
Signals And Threads (a Jane Street podcast) had an interesting discussion about documentation [0]. There was also an interesting reference to literate documentation (I think similar to Jupyter notebooks but as documentation).
[0] https://signalsandthreads.com/writing-technically/
Good docs are rare like unicorns with a glowing horn.
It doesn't seem to move the needle like a shipped feature does, requires guessing other peoples' perspectives, involves devoted time and effort (that could, you know, be spent on actually useful things) and the effects of not doing it are invisible (but real: user rage, frustration and wasted time).
Only when the importance of good docs is understood will any effort be invested into it. It should be important if the goal is to have more people using something.