Writing Better with 'Results-Based Writing'

by Stu

Tuesday, April 06, 2010 at 06:55 AM EDT

This is possibly a little offtopic for many KDE peeps, but relevant to the stuff I do with KDE. It may be relevant to you if you write articles, announcements, press releases – or even blogs

I spent the last couple of days attending a “results-based writing” course hosted by my university. The main aim was to learn some things about writing concisely for scientific papers and finding a good structure for my thesis. However, the lessons are applicable to all many kinds of writing.

The training was provided by Cognitrix and was excellent. These are key points that I took away from the course:

• Know your audience
• Identify the concepts and how they link
• Don’t try and hide uncertainty with vague language
• See the opposite point of view
• Cut the waffle
• If you can’t say a sentence in one go then it is too long

They maight seem obvious, but many scientific papers fail on a lot of them. More detail on each follows below.

Know your audience

What jargon can you include? What explanation is necessary? On the Dot I insert hyperlinks to applications, jargon or concepts that I think might not be widely known, but mostly base that on what I understand.

Identify the concepts and how they link

We took a science paper, wrote its concepts out on paper and drew arrows to link them. Those with the most outgoing links are probably good starting points; those with mostly incoming links conclusions. Some items were not linked at all (these were mostly irrelevant and could be removed). Others had few links coming in and needed more background.

Don’t try and hide uncertainty with vague language

I know I’ve tried this in the past when I haven’t quite understood something. Not on the Dot, because there are far too many knowledgeable people reading and I’d get found out If you can’t explain something well then you probably don’t understand it properly yourself.

Try and imagine the opposite point of view

Particularly useful for science. Scrutinize statements like “it is obvious” to see whether they are true. Do you need to provide justification?

Cut the waffle

Some of us (I am guilty) can be a bit verbose. Being brutal with every word, we cut a sentence from 50 to 19 words with no loss of information.

If you can’t say a sentence in one go then it is too long

If you can’t remember at the end of a sentence how it started then the information is hard to take in. A good test is whether you can say the sentence aloud without pausing for breath.

Summary

Applying some of the above, I just cut the length of this post by 21%. I’m going to be trying to apply these lessons not just in my dayjob but also in my work with KDE. So you should read a bit less from me

This article originally appeared on Stuart Jarvis.