Sounds like typical Microsoft documentation to me. Explains in great detail what .NET is, where you can download it from, then jumps straight to the advanced topic they’re covering without any of the intermediate knowledge covered or even linked to (but perhaps referred to only vaguely in passing as an acronym, again with no link, this time no link to what “TLA” is actually short for, so you’re searching for it is fruitless as well).

I taught basic computer literacy. I am a software developer. It’s tough to reframe my own knowledge so drastically, but the new perspective also makes me question why so many things are wrong with current tech (particularly UI/UX).

I just want a friendly user :(

I think the issue is that you need to understand who your users actually are. Documentation for a library intended to be used by a reasonably competent software engineer is going to have different requirements vs documentation for a cli utility aimed at Arch btw Linux users vs documentation for a program to help Grandma organize family photos.

If you throw a terminal command at Grandma she’s going to panic and call her grandchild. If you put instructions for extracting a tarball in your library docs the programmer is going to get bored and skip ahead.

Every front-end guide, despite modern HTML/CSS3/ES6+ being completely viable for building an entire web application without dependencies: “first, install npm and npx and npy and npppp2 and then run ‘npz create-huge-boilerplate-folder’. Now go edit arbitrarily_named_file.yaml to add requirements a, b, and banana. Now you can edit path/to/hidden/entrypoint.jsx to return ‘Hello, World!’ and then run ‘npz bloated-dev-http-server’ and navigate to http://127.0.0.1:9001/index to view it! Simple!”

I mean, as it says at the end, this blog post is in good fun. It most definitely expresses frustration, but it also recognizes that perfect is the enemy of good, and that you already put in more effort than one can expect by writing a tutorial to begin with.

I guess, my main takeaway is that you really don’t need to bother writing up your life story. It will fly over the head of your readers, for sure. (Although a bit of context may still be important.)
And you should probably spend a few more words, describing the actual steps, no matter how obvious those may seem to you.

There’s amazing and terrible manuals everywhere. One of the key things is defining target audience. From there you define experience and knowledge.

If a manual is intended to be for a broad audience interacting with something new, then you use the lowest level reading level that still makes your point. From there you work on flow because there’s a 1000 ways to skin a cat.

If LEGO manuals were only written step by step instructions, at a college reading level, then they miss a key demographic. Yet, people would still walk around like “That’s a perfectly cromulent instruction manual!” Technically they would be correct but it misses the point.

Is “prerequisite knowledge” a foreign concept to people these days?

Apparently so.

RTFM means that you should use the available resources to learn

Except the manuals are written like this, and don’t cover pre-requisite knowledge at all - don’t even link to it!

There’s a whole internet full of them

Microsoft doco “now add TLA to it”, don’t say what TLA is, don’t link to what TLA is, searching for TLA doesn’t tell you what it is. There most certainly is a whole internet full of blogs about “TLA”, but I don’t even have any keywords, and can’t find any of the “TLA” that Microsoft is talking about. The documentation is literally useless to anyone who doesn’t already know what “TLA” is.

There are no shortcuts to understanding

There are no shortcuts to writing good documentation

you can’t expect every task-oriented guide to explain how to write a main().

But you can certainly expect them to link to resources about pre-requisite knowledge, like I did in Creating MAUI UI’s in C#.

Actually!

I went to the comments expecting some more jokes but found multiple dissertations instead wtf.

“That said, people can put it in “recipe” format - a set of steps to be blindly followed without understanding - but even there you have some minimal foundational knowlegde required”

Something that’s quite interesting is that apparently one of the core components of how Latin and Greek used to be taught in fancy public schools (especially in like, Isaac Newton’s era) was that students would be made to copy out sections from classical literature (such as the Odyssey). Obviously this would be happening alongside lessons involving basic grammar, but I’ve seen some scholars suggest that this kind of blind repetition was a key component to the language learning, and that it may even be useful for learning languages in a modern context.

It would be pretty insane to in a tutorial for something at a higher level of expertise, include all the foundational knowledge to get to that level of expertise

You don’t need to include it all. You just need to mention it as pre-requisite knowledge, and link to resources about it for those who don’t have that knowledge. See Creating MAUI UI’s in C#

I get the impression that most people who go to the trouble of writting about how to do something prefere to do explanations rather than recipes

Good documentation includes both. i.e. step-by-step guide, with explanations. See above.

so either seek recipes with an even lower base level

All documentation should cater to all levels. See above.

I Prefer a playbook to a recipe card. The playbook should spell out the goal and the 'why’s of the steps. Because if the process throws an error due to upgraded code etc, then you can be stuck at step one with no path forward. With some playbook annotation you at least know expected out come and why you are running a command etc.

When I have gone to docker hub I always view multiple images and see what their writeup is like. Some just assume you 100% know all dockers subtleties, some have a one liner, but there will be a helpfull soul who spells out what steps to do, and what the best options to set etc. Like a mini tutorial.

I find the mini tutorial to be widely beneficial, because it removes the blackbox nature, and gives new onboarding users a chance to grasp the concepts docker works with.

It’s like the difference between going to a mechanic that has you sit by the coffee machine in the office while they change your brakes and they come back and say “I swapped the new pads in”, vs them pulling up a chair in the shop and explaining the process “here I’m wirebrushing the back of the wheel and the hub, to make sure when it goes back on there is no corrosion debris stopping a parallel fit…now I’m applying high temp grease so that the hub and wheel don’t sieze together from corrosion and make next removal easy”

The info is probably useless to a seasoned mechanic that had a broken hand so had somebody else do their brake work, but highly useful to the next gen of person that can absorb it and know whats and whys.

Imagine a chemistry lab tutorial aimed at 9th grade students getting “as a non-chemist, this reads as gibberish” comments from first graders. Nobody would blame the tutorial authors

I tutor Maths. I have a Year 12 student who has forgotten things they were taught in Year 8, and the teacher has done no revision of it in class. Now guess why this student needs a tutor 😂

People need to start putting in the effort.

The people writing the documentation, yes. They need to say what the prerequisite knowledge is, and include links to it for those who don’t know it (or remember it). Only takes a few minutes to do that. See Creating MAUI UI’s in C#

The amount of time and skill it takes to write excellent and accessible documentation is just not reasonable for most developers, unless you have dedicated technical writers or it’s a personal project without true deadlines.