The Do’s and Don’ts in

Technical Writing

Nidhal Bouaynaya
Department of Electrical and Computer Engineering
Henry M. Rowan College of Engineering
Rowan University
 How to Turn a Messy Bunch Of
“Academic Stuff” Into a Research
Article?
 But before writing …
make sure you are not
reinventing the wheel
 Perform an extensive literature review.
 Carefully understand the problem: why is it a problem in the first
place? Why should others care? Why is there is a need to do
something “more” and “better” than what has been already done?
 If indeed a state-of-the-art problem, come up with an idea that is
“substantially” different and “better” from what has been done.
 Perform simulations or experiments to prove it.
 Must compare with current literature and show “tangible”
improvement.
Now it is time to write.
Keep in mind:
You do not write a paper
for yourself. You write a
paper for the reviewer
(critical reader).

This means that the arrangement of ideas may

not be in the chronological order of the work.
Components of a Research Article

 Abstract
 Introduction
 Methods/Theory/Experimental Procdure
 Results
 Discussion and Conclusions
 Acknowledgements
 References
 Appendix
 Abstract –
Full paper in a paragraph
Limited to one paragraph, usually 200 words or less, the abstract is a short
summary of the technical work that is completed, and hence the content of the
document. It should include, in one or two sentences each, the motivation / goal
for the work done (why have you done the work? - “I need to submit this paper
to get promoted” is not a motivation), the specific nature of the work (what have
you done?), and results you have obtained (what did you find out?).

• Aim (“This paper explores / We address the problem of …”)

• Main argument (“In this paper we argue that …”)
• Method (“We used … / We derived …”)
• What is new? (“This paper shows that …”)
• Simulation and experimental results (“Our simulation/experimental
results show that …”)
A clear abstract will strongly influence whether or not your
work is further considered …
 Introduction
This section, usually limited to 15-20% of the total content of the paper, provides
the background information, expands on the motivation and importance of the
work (and in most technical documents) relevant references of the work done by
others that relate to the current work (also called literature survey).

• Background and Motivation: what is the problem under

investigation? Why should the reader care? Why is it worthwhile?
Why isn’t the problem already solved?
• Literature Review: What has been already done? Cite specific
current works and briefly discuss their methodologies.
• Critique of Literature: what is missing? What has not been already
done? What are the weaknesses or disadvantages of current
approaches?
• Introduce your Idea: How are you planning to fill in the gap? To
remedy these weaknesses and disadvantages? Show how your idea
is different from recent work.
 Introduction -
Do not do this
• “The problem of X has attracted considerable interest in the research
community.” (unless you are writing for sociologists studying the
community.)

• “Computer graphics has made great strides in photorealistic

rendering. However, an alternative approach has emerged, called
Non-Photorealistic Rendering (NPR)…” (don’t just copy the same
paragraph that appears in 100 papers by now… say something
relevant to the paper)
 Introduction -
Manage your expectations
• Sell your work but do not lie
- All claims should be supported with citations, experiments, proofs,
etc.
- Avoid grandiosity (“we propose a framework…”, “Our method is
superior to all previous approaches”)
- Unfulfilled promises are the kiss of death

• State your assumptions!

“We assume that all image blur can be modeled as a single convolution,
i.e., there is no significant parallax; any image-plane rotation of the
camera is small, and no parts of the scene are moving relative to one
another during the exposure.”
 Introduction -
Related Work
• Acknowledge your debt
• Explain precisely how your work is different
• Outline your perspective on the field (esp. if your paper is
countering an orthodoxy)
DO
• Point out both advantages and disadvantages of related
work (provide context; defuse objections; be honest)
• Discuss all references that you cite
DO NOT
• Write a laundry list
• Bash (put down) the references
• Include irrelevant references
• Write a paragraph about a very peripheral work
Provide context to convince readers that you clearly know why your work
is important and challenging.
Discuss the related literature: contributions and disadvantages.
 Methods/Theory/Experimental
Procedure

This is the main section of any technical document, and describes the actual
work that is done. It should, in general, include all the details that someone with
a reasonable background related to the topical area, should be able to recreate /
replicate the work. Hence all the relevant theory, equations, materials used, etc.
should be described in detail. In most documents that describe a specific
algorithm, it is also customary to include a pseudocode of the algorithm.

• Hypothesis, main findings, assumptions, detailed algorithm and

analysis
• Unexpected findings
• Tables, figures, charts
 Body
• Organize the paper with a logical flow

• Provide sufficient signposting to explain where you are going and to

dive in

• Provide experiments and demonstrations to justify all of your main

claims

• Compare with all relevant existing methods (and obvious, trivial

extensions)
 Reproducibility
• Practictioners (e.g., skilled grad student) should be able
to reproduce your work from the descriptions, down to the
level of tuning parameters (if possible)
- Don’t assume some steps are obvious

• Release your code and data online (a delay is acceptable

if you want to do follow-up work)
- It doesn’t have to be production-quality

• I know from experience: these things make a difference!

Detail the Theoretical/experimental analysis
 Results
• This is the section where you report your
results. What have you found? The
results, in most technical documents, are
given in the forms of tables, figures,
charts, etc. with a short explanation on
the main points the reader should be
observing in these tables, figures, etc.
The discussion or interpretation of these
results are *not* discussed in this
section.

• Allow others to reproduce your results

precisely (list all user parameters, etc.)

• Captions and legends must be detailed

enough to make figures and tables self
explanatory.
 Discussion – evaluation, comparison
• This is where the interpretation of the results should take
place, along with concluding remarks. The interpretation
should include a discussion whether the observed results
are expected or surprising (and why?).

• What can you say about the work that you couldn’t
before? What are the broader implications of the work?
• Don’t just repeat the introduction/abstract
• If you cannot think of anything to say, just skip it (or keep
it brief).
Discussion – evaluation, comparison
 Conclusion
• Summarize the main
approach (algorithm,
method, experimental
procedure).

• Summarize the main

findings of the paper.

• Discuss the limitations

and generalizations of
the work.

• Outline future
research directions, if
possible.
 Acknowledgement
If you need to acknowledge assistance (technical or experimental assistance by
someone, or financial support that directly funded the work provided by a
company or agency), this is the place to do so. Acknowledgement should only
include those people and entities that directly affected the work; this is not an
Oscar ceremony – you need not thank your parents, spouse, best friends, your
professor, etc.
 Appendix
Any additional relevant information you think would be of interest to the reader of
this technical document should be included in an appendix. In technical
documents, the appendix may include proofs of certain theorems, additional
results, figures, terminology / glossary, nomenclature, code listings, etc.
 References
If you have referenced the work done by someone else (typically in the
introduction section), you should include citations of those works in this section.
You should follow the style guidelines of the publication for listing the references
Language: why is language
important?

Save the reviewers and the

editor the trouble of guessing
what you mean.
 Language: why is language
important?
• It is the authors’ responsibilities to make sure their paper is in its best
possible form when submitted for review and later on for publication.

• Clear writing requires clear thinking; muddled writing is a sign of

muddled thought.

• Break down complex sentences. Refactor sentences for clarity and

flow. Convert passive into active voice “Hammamet is a town that
attracts visitors because of its beautiful beaches.”
 The Importance of Editing

• I'm not a very good writer, but I'm an excellent rewriter. ~James
Michener

• The beautiful part of writing is that you don't have to get it right the
first time, unlike, say, a brain surgeon. ~ Robert Cormier

• The time to begin writing an article is when you have finished it to

your satisfaction. By that time you begin to clearly and logically
perceive what it is you really want to say. ~Mark Twain\

• Proofreading is an art and a craft. ~ The Chicago Manual of Style,

14th ed.
 Writing Style – Passive
versus Active
• Passive:
- “The algorithm is poor at sorting.”
- “the results seen in Figure 1 were generated by the algorithm, when
run with the alpha parameter set to 0.75”
Anything with is, was, will be, has been, etc.
• Active:
- “This algorithm performs poorly at sorting.”
- “with the alpha parameter set to 0.75, the algorithm produced the
performance curve shown in Figure 1.”
• Active sentences are clearer and more direct; passive are more
indirect.
• Avoid passive writing when possible without sacrificing clarity.
• “We” is acceptable as a way of avoiding passive voice – … but don’t
do this: “We then sort the vertices by height…” (unless you are
manually doing the sorting yourself, and not the algorithm)
 Writing Style – Avoid first
person
• Avoid using first person singular pronouns in a technical document. For
example, “…I set the alpha parameter to 0.75, because my previous
experiments gave the best results with this number…” is not a proper
sentence (not formal enough). A better usage would be “ …the alpha
parameter was set to 0.75, based on prior experience”.

• While first person singular is usually not accepted, first person plural is
acceptable, particularly if the document has multiple authors. For the first
example above, you could say “ …based on prior experience, we set the
alpha parameter to 0.75.”

• Avoid giving instructions to your reader. This is a paper, not a user’s manual,
certainly not a recipe book. For example, instead of “to compute the total
response, you simply compute the individual responses, and then you can
add them”, you should write “the total response can be computed by adding
the individual responses.”
 Writing Style – Avoid story
telling
• Story telling occurs when you write a series of sentences that follow each
other, typically in a chronological order, as if you are actually telling your
thought process or experience to someone. For example “…we first tried 𝛼 =
0.05, which did not give good results. Then we tried 𝛼 = 0.3, which also did
not work. After several attempts with many numbers, we finally picked α =
0.75.”

• To fix this sentence, first ask yourself whether all the information is really
important. Is it important that the readers know that 𝛼 = 0.05 and 0.3 did not
work? If not, do not provide unnecessary information just for the sake of
reporting. You do not need to give the details that do not directly contribute to
your conclusions. In such a case, “ …based on prior experience, we set the 𝛼
𝛼 parameter to 0.75.” would suffice.

• There are, however, cases where the unsuccessful trials are very relevant
and must be reported. If this is such a case, then the above sentence can be
corrected as follows: “An 𝛼 value of 0.75 was finally chosen, after several
trials with the values of 0.05.0.3, …, did not provide the desired outcome.”
 Writing Style – Abbreviations
and acronyms

• Define abbreviations and acronyms the first time they are

used in the text, even after they have been defined in the
abstract.

• Do not use abbreviations in the title or heads unless they

are unavoidable.
 Few Common Mistakes
• The word “data” is plural, not singular.
• Do not use the word “essentially” to mean “approximately”.
• Be aware of the different meanings of the homophones “affect” and “effect”,
“complement” and “compliment”, “discreet” and “discrete”, “principal” and
“principle”.
• Do not confuse “imply” and “infer”.
• The Latin abbreviation “et al.” means “and others,” “i.e.” means “that is”, and
the abbreviation “e.g.” means “for example.” Note that there is no period after
the “et” in the abbreviation “et al.”
• Avoid starting a sentence with nondescript demonstratives, such as “this,
these, those, etc.” If you must (and do so only occasionally), you must follow
it with a noun. For example, in the sentence: “…we then implemented radix-3
version of the FFT in Matlab. This worked much faster…,” it is not clear what
the demonstrative “This” refers to. Always, follow the demonstrative with an
appropriate noun: “…we then implemented radix-3 version of the FFT in
Matlab. This implementation worked much faster….”
 False Elegance
False elegance also happens when using phrases that are unnecessary, wordy or
cliché. A few examples are given in Table 1 below.
 Label!!!

• Graphs with unlabeled axes, or labeled axes without units. Definite no

no!

• Figures and table captions must be self-sufficient and self-explanatory.

• This one is worth repeating: Make sure that all figures and equations are
crisp. Do not copy and paste from others’ work, most certainly do not
crop and copy from PDF files. Not only is that plagiarism, it also looks
fuzzy. Create your own equations and figures
 A rejection (may be)

Actually, the paper is much better

after all those revisions!