Technical Writing and Documentation

Technical writing's primary enemy is the Curse of Knowledge: the assumption that your reader knows as much as you do. To combat this, you must identify Jargon—specialized language used by a particular profession—and translate it into 'Plain English.' This isn't 'dumbing down' the content; it is optimizing for Cognitive Load. If a reader spends $80\%$ of their mental energy deciphering words, they only have $20\%$ left to follow the instructions. Use the 'Newbie Test': if a person outside the field cannot define the term, replace it with a functional description. For example, instead of 'initialize the peripheral,' use 'turn on the printer.'

Effective instructions follow a strict Sequential Logic. Each step should contain exactly one action. When you bundle multiple actions into one step, you increase the likelihood of user error. Furthermore, always use the Imperative Mood (command verbs). Instead of writing 'The user should then press the button,' write 'Press the button.' This creates a direct link between the text and the user's hand. Think of your instructions as a mathematical function where $Input (Text) \rightarrow Output (Action)$. If the input is cluttered, the output will be flawed.

In technical documentation, Formatting is a tool for navigation, not just aesthetics. White Space—the empty areas around text—prevents the reader from feeling overwhelmed. Use Visual Cues like bolding for UI elements (e.g., 'Click Submit') and italics for emphasis. Visual aids like diagrams should follow the Spatial Contiguity Principle: keep the text labels as close to the relevant part of the image as possible. If a user has to look back and forth between a legend and a diagram, their short-term memory is taxed, leading to a higher error rate $E$ where $E \propto Complexity$.