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, but the lessons are applicable to all many kinds of writing. Writing a thesis takes a lot of endurance and strong writing ability, as you have to keep the reader interested and informed for thousands upon thousands of words encompassing complex topics and formed scientific opinion. While many online education sources do indeed offer some great tips on compiling a good thesis paper, it is best to take a look into face to face courses as well as you can ask questions of the teacher and other students and involve yourself verbally as it plays out.
The training I attended 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
Tags: background, communicating, Dot, offtopic, promotion, Science