Yes, I didn't intend that there was a contradiction, just that "jargon" and technical words are actually used more in technical writing than in other kinds of writing, and it can be tricky to understand where the line is, how to introduce these terms such that the reader is not confused by the unusual term (or by a common word used in an unusual way, like how in programming contexts the word "string" refers to a sequence of characters).
Anyway, it's not that none of these principles apply, it's just that there are almost certainly many tweaks here and there and additional tips for people writing technical documentation - for example, almost no one sits down and reads the documentation for a library from "front to back", it is usually used in segments, which has implications about what you can expect your reader to know, and about how important navigation and organization of the document are.
These are just some things that I've noticed as a consumer and producer of documentation, and I don't know that I even have good answers to most of them.
(I hate to make it seem like I'm arguing the point that these more general writing guides are not good, I just want to clarify the kind of thing I'm looking to improve, for myself.)
Anyway, it's not that none of these principles apply, it's just that there are almost certainly many tweaks here and there and additional tips for people writing technical documentation - for example, almost no one sits down and reads the documentation for a library from "front to back", it is usually used in segments, which has implications about what you can expect your reader to know, and about how important navigation and organization of the document are.
These are just some things that I've noticed as a consumer and producer of documentation, and I don't know that I even have good answers to most of them.
(I hate to make it seem like I'm arguing the point that these more general writing guides are not good, I just want to clarify the kind of thing I'm looking to improve, for myself.)