Here are a list of suggestions that may help you with technical writing.
I have gleaned these from many sources. See the reference list
for expanded coverage.
Categorization of Your Paper
Ask yourself: "Why am I writing this paper?" Classify your paper according
to one of the following categories and write the paper according the particular
rules for that category: research, experience, or
Research papers describe work that advances the technology area. Such
papers must contain new and original work. The ideas must be presented with
evidence and analysis, not just be conjectures.
Experience papers present the results of new experiments or data to
support or contradict other results. Such papers should provide positive
or negative evidence, future research directions, and new insights.
Tutorial papers. Submit these to journals and conferences that invite
such papers. Identify your audience; are you addressing people that are new
to the field or experienced professionals?
Use fully grammatical sentences. Spoken communication has much more leeway
and flexibility than written communication.
Use simple sentence structures. These may appear "simplistic," but they are
much more likely to convey exactly what you mean. Your paper may be later
edited by a writing specialist who is not a specialist in your particular
technical field. A series of short sentences can be combined by an editor
and then convey the correct meaning; a long, complex sentence may be ambiguous,
and it may be impossible for an editor who is not a technical specialist to
fix the writing.
Avoid informal language, such as: slang, contractions, jocularity. That type
of writing is difficult for authors who have English as their first language.
It can be disastrous for authors who are not English native speakers.
Is your work ready to be made public in the particular forum you have chosen?
Or should you wait until you have determined the answers to several of its
questions? Is it results or only conjectures and opinions?
Have you rigorously established the results you claim in your paper? Have
you presented the proofs in convincing ways for the program committee or
Your paper will be related to other papers in the field, and your field is
a part of a more general field. Make sure you know the related work,
refer to it, and connect to it.
Present your work to your colleagues before you submit it to a journal or
conference. Ask them to read early versions of your papers. Give informal
seminars to a friendly audience.
Professional and Ethical Issues
We all understand that we should not the works of others and claim them as
our own; similarly, we must not plagiarize our own work. Do not submit a paper
that is essentially the same as a paper you have previously published. Extensive
quotations and paraphrasing of your previous work should be treated the
same as if your were using material from other people's work. Carefully describe
the relationship between your new present paper and your previous ones.
Do not submit the same paper to more than one organization simultaneously.
(If you think you have good reasons to violate this rule, discuss it
with the journal editor or the conference chairman.)
Robert A. Day,
How to write and publish a scientific paper, 5th edition,
Oryx Press, 1998.
Joseph Gibaldi and Walter S. Achtert, MLA Handbook for Writers of Research
Papers, The Modern Language Association of America, 1988. This is a basic,
Ralph E. Johnson, et al., "How to get a paper accepted at OOPSLA," in OOPSLA
1993 Conference Proceedings, ACM Sigplan Notices, vol. 28, no. 10,
Oct. 1993. (This is a panel discussion in which each panelist discusses specific
issues: theoretical papers, experience papers, methods, programming language
papers [this conference is devoted to object oriented programming systems
and the languages that support it], the paper-writing process. Although this
is targeted for a particular conference and topic area, the suggestions are
general and applicable to most papers in computing. The paper acceptance
rate at this conference was only 9%.)
Linda Levine, Linda H. Pesante, and Susan B. Dunkle, Technical Writing
for Software Engineers, Curriculum Module SEI-CM-23, Carnegie-Mellon
University, November, 1991. This 75 page document is available through Research
Access, Inc., 800 Vinial Street, Pittsburgh, PA 15212. The principal audience
for this is teachers of technical writing for software engineering students.
Almost half of this document consists of an excellent, annotated
Alan J. Smith, "The task of the referee," Computer, April 1990.
Alan Snyder, "How to get your paper accepted a OOPSLA," in OOPSLA 1991 Conference
Proceedings, ACM Sigplan Notices, vol. 26, no. 11, Nov. 1991. (Alan
Snyder was the program chairman for this conference. He discusses the paper
acceptance criteria and tells why many of the submitted papers were rejected.
I highly recommend this paper!)
William Strunk, Jr. and E. B. White, The Elements of Style, Macmillan
Publishing Co., New York, 1979. This short book is the principal book on
writing that I recommend to my own students.
Mark N. Wegman, "What it's like to be a POPL referee, or how to write an
extended abstract so that it is more likely to be accepted," ACM Sigplan
Notices, vol. 21, no. 5, May 1986.
The IEEE Power Engineering Society has good guidelines for overheads