| I should very much like to see a text editing program with a
built-in facility to tell you that you have just repeated a phrase
which you have already used in the last few lines. (And the longer the
phrase, the greater the gap allowed between one occurrence and the
next.) Given the speed of the search engines over terabytes of data, it
couldn't be that difficult to flag repeats within the scope of a single
document. (If anyone knows of a word-processing program that does this,
please let me know!)
I think this would be a special help to people whose first language
is not English, or who are relatively unfamiliar with writing technical
papers, because there is a huge temptation to repeat material to ensure
that you have got it across. Unfortunately, this hammering away soon
starts to annoy the reader; after a bit he or she becomes convinced
that you have nothing fresh to say. And, even if you do have something
new to say, it's difficult to fit it in if all the space has been taken
up with repetitions.
Replacing a repeated word or phrase with an alternative (sometimes
called 'elegant variation') is not usually the right solution in
technical writing. Repeated material needs to be removed, and here are
some ideas about how to spot it. | |
|
| Technical papers are full of phrases which are
really symbols for more complicated referents. For instance, authors
sometimes think of a phrase that describes their technique, such as "a
data-intensive approach to function mapping, that is applicable to
complex conjugates" (yes, this example is gibberish) and then they
repeat the whole thing again and again. That's really annoying, and a
waste of space. |
| Frequently used concepts need a simple
'symbols', which can be used after the first occurrence of the concept.
So this technique (if it made sense) it might be described
"data-intensive mapping", and you could also use a generic phrase such
as "our approach" a lot of the time. This doesn't just apply to a
description of your own technique: any long phrase which you find
yourself repeating again and again probably needs the same
treatment. |
|
|
| It is awfully tempting to try to bring your
reader 'up to speed' at intervals throughout your paper by explaining
what has already happened. So you might quite naturally start a
section headed "Three-dimensional applications" with something like "In
the last section, we saw how data-intensive mapping could be used in
two dimensions...". But the reader was just told about the 2D stuff:
only an amnesiac could have forgotten already. |
| It may somethimes be necessary to look
back, but only in some exceptional circumstance: |
| * | If you
want to recall something that hasn't been mentioned for a few
pages. |
| * | If you
need to show how several things fit together (in a non-obvious
way). |
| * | If you
need to make a 'static' summary of the situation after some processes
that have been described 'dynamically' (i.e. in terms of their working,
and not their results). |
| Text that is developing your argument can be
kept. Text with nothing new to say should be shown the
door. |
|
|
| You may have been told that it is necessary to
'motivate' your reader, and it is easy to assume that this means
keeping him or her informed about what is going to happen. But in
practice that is often demotivating: readers want information, not
information about information. |
| So, if you are tempted to write phrases like
"In this Section, we will show how data-intensive mapping can be
applied in three-dimensions", don't. By the time anyone gets to the
central part of your paper, it is likely that he or she will have
looked at the Abstract, the Introduction, all the Figures, the
References (to see if their own work has been cited) and possibly also
the Conclusions. They probably have a good idea of where the paper is
going and telling them what is about to happen is almost always
redundant. |
| Ban these 'signposts' from your text, but
compensate by making sure that your headings are
descriptive. |
Some people (You know who you are!)
have been taught to end the Introduction of their paper with a little
paragraph that starts like this: "In Section 2, we will develop
the theoretical basis for our work. In Section 3, we will...", and
so on.
| This would be fine, if your paper were 100
pages long. But, if it was 100 pages long, it would be a book, and it
would have have a contents list. In fact, this little paragraph at the
end of the Introduction is really (as Clausewitz so nearly said) a
contents list by other means. But a technical paper doesn't need a
contents list. People can flip through it before they start reading: in
fact, they almost always do. And even if they don't, they know that
most technical papers go something like, theory, implementation,
results. In my view, a description of the layout of a paper can
only be justified if that layout is really
unusual. |
| |