Technical Writing 

No one sets out to become a technical writer. If a writer has the urge to teach, however, technical writing has its rewards.

At its most fundamental level, technical writing is the teaching of technical subjects on paper. As we recall from school, our best teachers were engaged, clear, and well-prepared. To prepare to teach, you must know how to sequence the presentation. What do the students know? What do they fail to understand? And what do they want out of the presentation? Each element of the presentation must logically flow from the previous. It is even more important in technical writing, as the reader cannot raise a hand to ask a question.

Additionally, he isn't very attentive. When do technical books get opened? When the reader can't figure out a specific problem that prevents him from reaching a specific goal.

To Help a Reader Find an Answer:

1. Be consistent in terminology. The natural tendency to vary language doesn't help in technical writing. Terms used in Chapter 1 should be applied to the same things in Chapter 22.

2. Format like a programmer. When reading, the eye processes so much more than subject, verb, and object. Organize the document so that similar types of information are always placed in the same formatting. The best technical writing is formatted and reads like code.

3. Write lean. Get to the point, and make examples as specific as possible. If the reader could speak, he would ask, "Just give me the answer."

4. Be a completist. If the product is lacking critical elements as you're writing, note it. If there is an outstanding question, write it. If a more thorough explanation is available elsewhere in the documentation, cross-reference it. But whatever you do, don't repeat materials.

5. Be persistent. Don't take personally rejections and blow-offs from production resources. The tech writer is probably #15 on the priority list. Patiently ask questions until answers are provided or time is set aside to provide them. Product managers want good documentation, too.

6. Think ahead. As you're writing and distributing drafts, think about the end user and also the people who will review the documents. What do they need to know about how you developed the document? The state of it? What seems weak or perhaps extraneous? Like the end user, your editor is probably getting into the documentation at the end of a long day. So help him out.

7. Bring a clear mind. The trick to organizing and developing documentation is ignorance about the product. Some may argue that a technical writer should know his subject inside and out, but if the writer approaches the subject with a blank slate and knows how to fill it, the writing process ensures that little is omitted and inspires the output.

And an inspired teacher is bound to do a better job.