/
Resources for Writing Good Research Papers

Resources for Writing Good Research Papers

Owned by Viveka Kudaligama
Last updated: Nov 03, 2014

~ Contributed by CS Faculty for CS 591 PHD - Fall 2014 ~

These are some tips and resourcesthat CS faculty shared on writing good research papers.

Brian Bailey:
"Writing Research Papers" (Brian Bailey)

Sariel Har-Peled:
Turing original paper – "Computing Machinery and Intelligence" (1950)

Bill Gropp:
Like:

  1. A good paper tells a story. There is an engaging opening, the background is carefully done, and the facts support the tale. This seems obvious, but many papers don’t accomplish this.
  2. A good paper provides enough details to reproduce the work. This is regrettably difficult for conference papers, but it still a requirement of a good paper. (Some of our qual papers were good for the qual precisely because they failed this test)

Dislike:

  1. Scientific flaws that result from imprecise language. I’m rejecting, and I am publicly encouraging others to reject, papers that claim to compare ideas/models A and B but really compare one implementation of A with one implementation of B. (In my case, it is usually MPI vs parallel-programming-idea-of-the-moment, but I see this in many other areas).
  2. Misuse of terms, or inventing new terms, that mislead the reader. For example, “timestep” where “iterate” is intended.
  3. All of the misuse of graphics that Tufte notes. E.g., the use of a graph or bar chart to show 3 data values. Scaling that obscures values.
  4. Lack of scholarship: failure to cite relevant work; citing the most recent work (or even worse, work by the author’s friends) over the primary sources.

Carl Gunter:
Review the qualifying exams reading lists

John Hart:
"How to get your SIGGRAPH paper rejected" by Jim Kajiya
The advice I give to new students is that writing a research paper is journalism, not storytelling.

Darko Marinov:
"How to Read an Engineering Research Paper" by William G. Griswold
"Writing Good Software Engineering Research Papers" by Mary Shaw (ICSE 2003)
There're a few more meta-papers on "How to write papers", and I highly recommend to the students to read the one for their area.

Hari Sundaram:
The PowerPoint “15 pieces of advice that my advisor had given me” by Jim Kurose (a well-known systems researcher at U Mass) offers advice to PhD students. While the Kurose ppt covers writing and speaking, what I like about it is that it covers a lot of ground quickly; he asks students to think broadly about their work—focus on generalizations, not point solutions. Almost any paper by Jon Kleinberg is a joy to read. While his papers have economy of language, what is striking is how well he tells a story: there is excellent motivation, every idea is developed slowly but not laboriously; the ideas build on top of one another; the proofs when used are elegant and clear. Just as a parenthetical note, the Leskovec paper received a best paper award at KDD 2005.

Other resources with writing advice:
Dave Patterson’s Writing Advice
"How to Have Your Abstract Rejected" by Mary-Claire van Leunen and Richard Lipton
"How to write a Good Article" by Frédo Durand

Tandy Warnow:
I think there are different kinds of badly written papers. One kind is common -- poor grammar, spelling, etc. These are easy to find. But another kind is harder to spot (though also very common), and needs some context to understand why they are not well written. Here are some ways in which papers that involve experiments (often on simulated data) can be written badly:

  1. Not providing sufficient information about the methods used to perform an analysis, so that the analysis could be repeated. This is very common, across all journals.
  2. Interpreting data incorrectly, or failing to distinguish between statistical significance and impact (e.g., a difference in a result that is clearly not due to chance but where the difference is so small that it would not impact any downstream decision). This is also very common.
  3. Presenting a new method (developed by the authors) without any comparison to existing methods (when good existing methods exist), or comparing to an existing method but selecting a poor method rather than a good method to compare to. This is somewhat less common than (1) and (2), but still quite frequent.
  4. Selecting datasets to use to evaluate your method, and only showing the ones in which your method did well. (Harder to detect but can be detected.)
  5. Fall 2014 CS 591 PHD 3
  6. Changing the parameters of your method for each dataset or model condition, so that the method does well. (Easier to detect, and less frequent than the ones above, but does happen.)

Tao Xie:
Personal slides on paper writing or technical writing:
http://web.engr.illinois.edu/~taoxie/publications/writepapers.pdf
http://web.engr.illinois.edu/~taoxie/publications/writeissues.pdf
Other materials from personal advice portal:
http://web.engr.illinois.edu/~taoxie/advice/

Craig Zilles:
“Three sins of authors in Computer Science and math”