Computer Architecture Today

Informing the broad computing community about current activities, advances and future directions in computer architecture.

Inspired by T. N. Vijaykumar’s recent (and excellent) guidance for program committee members, I wanted to share my thoughts about crafting papers to survive the reviewing process and (more important) in the real world.

A research paper’s task is to convey the insights of your work to your audience — first the reviewers and then your research community.  To get published, your paper must satisfy the program committee.  Once published, it has to hold the interest of other researchers and engineers.  If it fails at either of these tasks, it will not have the impact it should.

Understanding your audience is critical when you are writing a paper.  Fortunately, you know a lot about these kinds of people, because, for the most part, they are people like you, your colleagues, and your advisor.  Unfortunately, they do not always make your task easy.

First, let’s consider the first audience for your paper:  the conference program committee.  Then we’ll take a look at the typical reader of published research and what that means for how you should write.

The Best Case Reviewer

Consider the perfect reviewer — the reviewer you hope is assigned your paper and the reviewer we should all should strive to be:

  • She has ample time.
  • He carefully reads each word.
  • She looks over the cited papers to gather context.
  • He is an expert in the field.
  • She is open-minded.
  • He gives you the benefit of the doubt.
  • She is able and willing to put aside her prejudices and preconceptions about the research area.
  • He takes careful notes.
  • She consults with a local expert if she is unfamiliar with the area.
  • He goes back to review parts of the paper he did not understand.
  • She wants the most interesting, exciting papers for the conference, no exceptions, no compromises.
  • He works hard to identify and understand the ideas you are trying to express and help you, through his reviews, to express them more clearly.

Writing for such a reviewer is easy because she is willing to put in a lot of work to understand what you’ve written.

There are two problems with writing papers targeted at such a reviewer.   First, even the best reviewers do not always meet this standard, and many reviewers never muster the energy and time to write reviews as they should.

Second, while reviewers have signed up to read carefully and produce good reviews, the real audience for your paper — its post-acceptance readers — are under no such obligation.  If your paper demands a lot from them, they will just stop reading.

The Worst Case Reviewer

Rather than a best-case reviewer, write your paper to target a worst-case reviewer, or, collectively, a worst-case program committee.  This is the group of reviewers that will present the greatest obstacles to your paper being understood and accepted.  If you can write a paper that satisfies these reviewers, then you will achieve two things:

  1. Your paper will be a model of clarity and concision.
  2. Your paper will get in.

The Worst Case Reviewer Knows Everything

You should assume that your reviewer has read all the related work, and I mean all of it.  This might seem unreasonable, and it is  — for a single reviewer.  But between all its members, the program committee has read just about everything relevant to your research.

This means you need to be aware of all the related work and cite the work that has bearing on your research.  Related work falls into two categories:

  1. The related related work  These are papers that are directly related to your work.  They describe the underlying ideas you are building on or represent alternative approaches that your work should be compared to.  You need to cite these papers because they provide valuable context for your work and give credit where it’s due for the shoulders you are standing on.
  2. The unrelated related work This is work that appears, at least in the mind of some committee member, to be related to your work even if it isn’t.   You should cite these papers because someone on the program committee will be annoyed if you don’t.

These are both separate from papers whose results you use or refer to in your paper or papers that describe tools you use.  You need to cite those too.

The Worst Case Reviewer Knows Nothing

Collectively, the whole program committee is aware of all the work in your field, but assume that individual reviewers happen to be unaware of the background needed to understand your research and its contributions.  Even worse, they will think they have the background, but, instead, they will misunderstand key points and be mistaken about basic facts (or, at least, facts that seem basic to you).  As a result, you will need to provide the necessary background.  For instance:

  • Does your work rely on a new technology (developed in the last 5 years)?  Explain it.
  • Does your work rely on fine details of a well-known technology? Explain it.
  • Do you use statistics more complex than the mean and standard deviation to analyze your results?  Explain why.
  • Does your work rely on combining technologies in a surprising way?  Explain it.
  • Does your work rely on technology that is not almost universally used or understood? Explain it.

The last one is especially tricky because things that seem obvious to you will be a complete surprise to the worst (or average) case reviewer.  You’ve spent the last many months working on your project.  You are immersed it in.  The details of the technologies you are using are second nature to you, so they must be second nature to everyone else, right?  No!  There are experts in your field who are almost completely unfamiliar with what is second nature to you, and they are reviewing your paper.  You need to educate them.

A good rule of thumb is that your background section should be full of things that are critical to understanding your research but seem so utterly obvious to you that writing them out (not to mention reading them) bores you and seems like a waste of time and space.

The Worst Case Reviewer is Tired and Grumpy

Reviewing papers is a lot of hard work, and it is exhausting.  A typical reviewing load for a top conference might include 15 papers, which amounts to about 180 pages of reading.  Much of that reading is not highly polished because it was written at the last minute before the paper deadline.  A careful review takes at least an hour or two, and usually a good bit longer.  While the ideal reviewer might spread that work out over several weeks to stay fresh, the worst-case reviewer crams it all into a day or two just before the PC meeting.  As a result:

  • He is impatient.
  • She is reading as fast as possible.
  • He jumps to (negative) conclusions.
  • She is tired.
  • He is distracted.
  • She has 14 more papers to read.
  • He is looking for a reason to stop reading and reject your paper.
  • She thinks she understands the area but doesn’t.
  • He has little expertise in the area but was assigned to the review the paper anyway.
  • She does not read the related work.
  • If something isn’t clear, he skips it, assumes the worst, and moves on.

The solution to all these problems is to make the paper as easy to read as possible.  This means a clear organization, good roadmaps, few grammar problems, easy-to-understand graphs, etc. — all the good things about well-written papers.

If you write a paper that a tired, grumpy reviewer can get through and like, it’s a good paper.

Real Readers

The worst case reviewer is a depressing notion, but most reviewers are not the worst case.  So why should you target the worst case reviewer?  There are two reasons.

First, writing for the worst-case reviewer will make your paper better.  All the changes you might make to appease the worst-case reviewer will improve its clarity:  Better organization, sufficient background, nice figures — they are all hallmarks of good papers.  The only real danger is that you’ll cite too much unrelated related work, but you can fix that after the paper’s accepted.

Second, PC members have a duty to try to be best-case reviewers, but normal readers do not.  Once your paper is accepted, it and the ideas it contains must compete with everything else for the readers’ attention.  To compete, your paper needs to be clear and easy to read — just as it does to appease the worst-case reviewer.

Just consider how you read papers.  Which of these scenarios is more familiar:  A) Sitting back with a glass of wine (or beer or whatever) and spend a leisurely evening perusing a research paper, B) frantically skimming a paper in the few minutes before a seminar, or C) trying to get through a big pile of papers as part of a literature review?

Scenarios B or C are much closer to the worst-case reviewer than the best-case — tired, in a rush, and unlikely to struggle through a hard-to-read paper.

Failing to reach readers B and C is actually worse than failing to appease the worst-case reviewer.  If the reviewers don’t like your paper, they will reject it, and you will get a chance to improve it and resubmit.  There no solution to not reaching B and C —  the paper is published, there’s no changing it.

Your excellent work and its deep insights are forever trapped inside a hard-to-read paper, and that will dramatically reduce their potential to have impact.

The Author’s Task

Ultimately, your task as an author is to craft a paper that transmits the insights that your work into the brains of your readers.  Failing at this — with the program committee or (even worse) normal readers — means all your hard work is wasted.  Thinking of and trying to remedy all the things that stand in the way of that transmission will result in better papers with more impact.

About the Author: Steven Swanson is a professor of Computer Science and Engineering at the University of California, San Diego and director of the Non-Volatile Systems Laboratory.