69
The Grand Unified Theory of Documentation (AKA: Your project needs all 4 types or you have bad documentation)
(documentation.divio.com)
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Follow the wormhole through a path of communities !webdev@programming.dev
Tutorials
Tutorials are lessons that take the reader by the hand through a series of steps to complete a project of some kind. They are what your project needs in order to show a beginner that they can achieve something with it.
They are wholly learning-oriented, and specifically, they are oriented towards learning how rather than learning that.
How-to guides
How-to guides take the reader through the steps required to solve a real-world problem.
They are recipes, directions to achieve a specific end - for example: how to create a web form; how to plot a three-dimensional data-set; how to enable LDAP authentication.
They are wholly goal-oriented.
Reference guides
Reference guides are technical descriptions of the machinery and how to operate it.
Reference guides have one job only: to describe. They are code-determined, because ultimately that’s what they describe: key classes, functions, APIs, and so they should list things like functions, fields, attributes and methods, and set out how to use them.
Reference material is information-oriented.
Explanation
Explanation, or discussions, clarify and illuminate a particular topic. They broaden the documentation’s coverage of a topic.
They are understanding-oriented.
tutorials and how-to guides are both concerned with describing practical steps
how-to guides and technical reference are both what we need when we are at work, coding
reference guides and explanation are both concerned with theoretical knowledge
tutorials and explanation are both most useful when we are studying, rather than actually working
I've had that article saved for years, it's still the best way to break down documentation imo.
Another key point for code documentation is that the closer it is to the code it's describing, the more likely it is to be read and maintained. The book "A philosophy of software design" has a section on it.
I agree with this point and it's one I've always had problems with as a lot of developers seem to dislike code comments. I agree that comments shouldn't become a crutch of bad code but good, well formatted documentation on a class or group of functions which explains their usage in relation to the product or feature they support are extremely useful and much more likely to be read by engineers than some documentation written on a notion page somewhere.