Write Right, or Embracing failure

I switch-hit between technical writing and programming (did both today, for instance: a bunch of application development, some prep work for Visual Studio Magazine, and some instructional design work for another client). I think that's comfortable for me because programmers and technical writers share a common life of failure.

Programmers live in failure: A programmer works on code only when the code isn't working. Once the code works, a programmer does one of two things: either moves on to some other piece of code that isn't working or enhances the current code (at which point it stops working).

Technical writers live with words that they know are one rewrite away from being better. And not one rewrite from being perfect, just being better. I tell new writers that they should assume that their first draft is junk--excellence will be added through rewriting.

After writers gain some experience, they come to realize the full truth: Every rewrite makes the document better. You don't stop rewriting because the document is perfect. Instead, you stop for one of three reasons: the deadline has arrived, you're so sick of the document that the thought of spending even one more minute on it makes you puke, or there's something else more important that you have to work on.

To quote my friend Cate McCoy: You're done because it's due.


But it's always wrong.

Reading or read

• Nadirs by Herta Mülle
• A Tree Grows in Brooklyn (CD) by Betty Smith