Writing for engineers

Great post and debate on Slashdot about teaching engineers to write. A particular highlight is the recommendation, in a comment to the main post, that teachers “present writing as an engineering problem.”

• Top down design: Starting with an outline and working out the details is the normal way of tackling an engineering problem.
• Checking your facts: Engineers should be used to checking anything that is even remotely doubtful before committing to it. So should writers.
• Failure mode analysis: For each sentence ask yourself, could it be misread? How? What is the best way to fix it?
• Dependency analysis: Are the ideas presented in an order that assures that each point can be understood on the basis of the readers assumed knowledge and the information provided by preceding points?
• Optimization: Are there any unnecessary parts? Does the structure require the reader to remember to many details at once, before linking them?
• Structured testing: If you read what you have written assuming only the knowledge that the reader can be expected to have, does each part work the way you intended? If you read it aloud, does it sound the way you intended?

This is both good advice in itself and very nicely put for the target readership. The whole thread and discussion is worth reading.

Related posts:

1. When writing, optimise the algorithm not the code
2. Geeks: how to write for a non-technical audience
3. Writing to Deadline in ten minutes
4. Rules of thumb for writing
5. Writing for the web is not the same as writing for print