points by jrmg 2 days ago | 0 comments
Yeah, this feels like one of those ‘explainers’ that feel like they are great to someone who already knows how the system works, but don’t actually work for newbies because they tacitly assume knowledge of the shape of the system that seems ‘obvious’ to someone steeped in it.
[–] 4L3XV33 2 days ago
Instructive feedback - been on both sides of that experience but never heard that problem so clearly defined before.
[–] ex-aws-dude 2 days ago
That's why its better for the person who just learned something to write the docs (checked by the expert though obvs)
[–] ozim 2 days ago
For me this one looks like someone prompted: “I want to have a cool looking explainer in form of a website and make it about hot topic”.
I don’t like people pointing out AI slop but one looks like something that should be called out. Maybe it helps the author for self learning that’s cool, but it doesn’t look like something for sharing with people as it really only wastes time.
[–] bityard 2 days ago
[–] Geezus_42 2 days ago
[–] dspillett 2 days ago
Most documentation is reference documentation, which as you find it not very useful for just starting out (it assumes at least a small base of knowledge about what it is documenting).
> _Good_ documentation should also teach the user how to use the thing
Good documentation usually comes in at least two parts: guide/introduction and reference. This is how some of the better ORA books were written, back when dead trees on shelves were a key source of learning for programmers - three sections: a small one for absolute basics (what you need to know before starting, many could skip this), the second an introduction to the concepts of the new thing (language, library, server, etc.) and what differentiates it from similar/related things, typically with worked examples, and at least the last half of the pages being reference material (split into meaningful subdivisions where that is useful). Sometimes they would split this in two and there would be explicit introduction and reference works (under the banner “complete reference”, though these would have a little introductory text in them too) for the same subject, but not always.
When you try to merge the two (guide and reference) too closely it all too often ends up either too basic or irritatingly long-winded for the experienced readers, while still being too opaque for those who are starting from scratch.
Sometimes a single good README is all that is needed for the guide part these days, sometimes you need that with branches (links) off to longer introductions to specific parts, it depends on the size of the project.
[–] ep103 2 days ago
Engineers rarely consider either, and doing both requires significant work
[–] SOLAR_FIELDS 2 days ago
[–] adolph 2 days ago
[–] palata 1 day ago
For an article explaining a concept, it's a balance to find, and it depends on the target public. If every physics publication started by teaching physics to the reader, it just wouldn't work, would it?
Regarding documentation: we probably all agree that a code repository should NOT explain how programming works: if you don't understand C++, then a C++ codebase is not for you.
But should the README explain how to, e.g. run CMake? I would agree it shouldn't. Just like it shouldn't explain how to clone the git repository, or start the computer.
This said, I find this particular explainer about MCP... convoluted.
[–] dawnerd 2 days ago
[–] dspillett 2 days ago
No MS, I don't want to ask co-pilot. Why don't you get co-pilot to draft some good documentation, that you then review and edit to make sure it is accurate, instead of expecting every individual to ask an AI for every question they have? That would be a lot more efficient in terms of energy use, I expect.