home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: misc.writing
- Path: sparky!uunet!zaphod.mps.ohio-state.edu!sdd.hp.com!sgiblab!pacbell.com!att-out!cbfsb!cbnewsg.cb.att.com!djd
- From: djd@cbnewsg.cb.att.com (david.j.daulton)
- Subject: Rules of Thumb
- Message-ID: <1993Jan23.052009.13460@cbfsb.cb.att.com>
- Sender: news@cbfsb.cb.att.com
- Organization: AT&T
- References: <1jnfejINNkg3@usenet.INS.CWRU.Edu> <1993Jan22.231853.34535@datamark.co.nz>
- Date: Sat, 23 Jan 1993 05:20:09 GMT
- Lines: 34
-
- As a technical writer I have a few of my own rules of thumb. In no
- special order...
-
- 1. Use "for example" a lot.
-
- 2. Use the product. Writing from engineers' explanations is fiction.
- Writing from project requirements is fantasy.
-
- 3. When you inherit a new project, "grep" for "that" and "which" and correct
- them.
-
- 4. Read Strunk and White once a year.
-
- 5. Keep returning to your sources until you understand. If you don't understand
- something, there is vanishing little chance you can explain it.
-
- 6. Cut the crap. Does the reader NEED this word? No? Cut it. Does the
- reader NEED this sentence? No? Cut it. This chapter? This manual?
- Cut, slash, chop. Information buried is information lost.
-
- 7. Think of your reader continually, and talk to him or her through what you
- write.
-
- 8. Use personal pronouns, active voice, and try to rewrite "being" verbs out
- of your sentences.
-
- 9. End sentences with prepositions, split infinitives, and so on, as needed
- in order to sound natural. This requires you to know grammar well enough so
- that when an engineer changes "use" to "utilize", or whatever, you can
- politely (and with good humor) explain that he is full of ....
-
- 10. Remember that you are really an ANTI-technical writer.
-
- 11. NEVER rewrite. No, wait, where'd that come from? Heinlein who?
-