[30-12-2007] Some time ago I posted some advice on writing to ACCU General, and several people asked if they could reproduce it, so I thought I'd make it available here...
I do quite a lot of writing - both technical for work, and for my non-tech weekly newsletter, Winding Down. There are a number of basic 'technical' things that help, regardless of the 'style' of your writing.
0. Understand your subject thoroughly.
1. Do the initial draft in an ordinary editor - I use my programmer's editor. That way you don't have to wrestle with the likes of Word doing things you don't want while you are getting stuff out of your brain and on to paper.
2. The first draft you just wrote is a brain dump. The biggest problem is that people don't realise that, and therefore don't take steps to make it understandable to other people.
3. Do a preliminary pass with a spell checker - don't under any circumstances use a grammar checker, unless you are entering a competition to see who can produce the most turgid prose!
4. Print it out. Take a ruler - preferably an opaque one - and use it to read each line, one line at a time. Doing this will make it possible to spot the jumps and holes where your brain thought faster than your fingers moved. Mark the text as you read through, and at the end transfer the corrections you marked back into the computer copy.
5. Print out another copy of the revised text. Take the copy and read it for clarity. The biggest single problem is usually overly long sentences, and paragraphs, together with missing punctuation.
Also are there any bits where you've gone into a digression from the main thrust of the argument? (I'm particularly bad at this.) If so, be ruthless and prune it. Is it in a logical order? Would it be better if you swapped some of it around? The fact that you can do this is one of the most wonderful things about computer editors!
6. OK, so you now have something that makes sense to you. Now get someone else to read it through to see if they understand it. A member of the intended audience would be best, but failing that, grab someone whose documents you find easy to understand. Take their comments on board, but don't let them impose their own style on you, and revise the document again.
7. Run it through the spelling checker again.
8. Read it again to make sure that the alterations you made didn't screw anything up.
9. Locate the office pedant and ask them to read it over for spelling, punctuation and bad grammar. You may need to buy them a pint, but it's well worth it - just make sure they don't have the drink till after they've read the document! You can probably ignore any wingeing about split infinitives :)
10. OK we now have the makings of a good document. The next step is to copy and paste the document into the appropriate template for your company's documents. Make sure you keep the text copy in case Word screws things up the first time you try it!
Ta-Da! Your masterpiece (or mistresspiece) is ready for distribution - it may not exactly be on a par with that of Shakespeare, but there's a good chance that people will understand what you are trying to tell them...
This may seem like a lot of hassle, but failing to do it is the writing equivalent to checking in untested and uncompiled code when you are programming. And you wouldn't do that, now, would you?
0. Understand your subject thoroughly.
1. Do the initial draft in an ordinary editor - I use my programmer's editor. That way you don't have to wrestle with the likes of Word doing things you don't want while you are getting stuff out of your brain and on to paper.
2. The first draft you just wrote is a brain dump. The biggest problem is that people don't realise that, and therefore don't take steps to make it understandable to other people.
3. Do a preliminary pass with a spell checker - don't under any circumstances use a grammar checker, unless you are entering a competition to see who can produce the most turgid prose!
4. Print it out. Take a ruler - preferably an opaque one - and use it to read each line, one line at a time. Doing this will make it possible to spot the jumps and holes where your brain thought faster than your fingers moved. Mark the text as you read through, and at the end transfer the corrections you marked back into the computer copy.
5. Print out another copy of the revised text. Take the copy and read it for clarity. The biggest single problem is usually overly long sentences, and paragraphs, together with missing punctuation.
Also are there any bits where you've gone into a digression from the main thrust of the argument? (I'm particularly bad at this.) If so, be ruthless and prune it. Is it in a logical order? Would it be better if you swapped some of it around? The fact that you can do this is one of the most wonderful things about computer editors!
6. OK, so you now have something that makes sense to you. Now get someone else to read it through to see if they understand it. A member of the intended audience would be best, but failing that, grab someone whose documents you find easy to understand. Take their comments on board, but don't let them impose their own style on you, and revise the document again.
7. Run it through the spelling checker again.
8. Read it again to make sure that the alterations you made didn't screw anything up.
9. Locate the office pedant and ask them to read it over for spelling, punctuation and bad grammar. You may need to buy them a pint, but it's well worth it - just make sure they don't have the drink till after they've read the document! You can probably ignore any wingeing about split infinitives :)
10. OK we now have the makings of a good document. The next step is to copy and paste the document into the appropriate template for your company's documents. Make sure you keep the text copy in case Word screws things up the first time you try it!
Ta-Da! Your masterpiece (or mistresspiece) is ready for distribution - it may not exactly be on a par with that of Shakespeare, but there's a good chance that people will understand what you are trying to tell them...
This may seem like a lot of hassle, but failing to do it is the writing equivalent to checking in untested and uncompiled code when you are programming. And you wouldn't do that, now, would you?