Technical Writing

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 tutorial.
• 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?

Writing Issues

• 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.

Generic Issues

• 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 referee?
• 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.)

References

1. Robert A. Day, How to write and publish a scientific paper, 5th edition, Oryx Press, 1998.
2. Joseph Gibaldi and Walter S. Achtert, MLA Handbook for Writers of Research Papers, The Modern Language Association of America, 1988. This is a basic, college textbook.
3. 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%.)
4. 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 bibliography.
5. Alan J. Smith, "The task of the referee," Computer, April 1990.
6. 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!)
7. 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.
8. 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.
9. The IEEE Power Engineering Society has good guidelines for overheads here.