MUST and MUST NOT; On Writing Documentation Revise documentation, many times, and on separate days to catch confusing parts.
Beware of ambiguities, e.g. X may not do Y. Refer to definitions, e.g. RFC 2119 .
Put yourself into different roles, e.g. the person just looking for samples, the person who wants to read up on every nook and crany, the person who has no technical background etc....
Choose your content. Some material not worth the effort. Learning comes from repetition, but sometimes you just don’t care whether you’ll remember what you’ve read.
But even if you don’t remember the specifics, the effect on your model of the world persists. As your mental model evolves, re-reading books is beneficial because the material compiles differently.
When reading, annotate connections from previous knowledge, unanswered questions and unjustified assumptions. Make flashcards of facts/quotes that you wish to analyze....
You need to develop a broad spectrum of style and then be able to move from one end of the spectrum to the other as occasion demands. You’ll develop a basic style but inability to diversify is being like a baller with a drive but no jump shot. Questions to ask: What am I writing about? Who will read what I’ve written? Why did I write it? I’m writing about topics that I want to know more about....
00. An Introduction to Writing;
02. The Subject;
03. Classification and Order;
04. Beginning and Ending;
Writing for Software Development;
The New Strategy of Style [Weathers, Winston];
[Orwell] Politics and the English Language;