Observations of a Paper Reviewer

I just had the chance to be a reviewer for a compiler conference. Instead of writing a paper and praying, I had to actually figure out what makes a good paper. Who knew I was qualified! While I've only written one, it seems to me that difference isn't necessarily about the idea presented in the paper. Instead, it's all about marketing. Here are a few observations and hints I've had that may help you go from a good to great paper.


Start early! Like really early. Two weeks isn't enough. Neither is three. I think you need at least a month if you are writing mostly solo. Maybe three weeks is enough is you have lots of experienced people writing together, but even that hasn't seemed to work. The problem with lots of authors is that everyone has a different voice and the paper no longer has a cohesive feel. Why do you need that much time? The time isn't necessarily YOU writing and proofreading. The time lag comes from the other people proofreading.

Proofread, proofread, and when you think you're done, proofread again! The feedback loop after the initial draft is MUCH slower. It takes one to two days for someone to read a paper. This means in between you're waiting. You as the author can't do anything, but time is still ticking and the deadline inches closer and closer.

Slowly add more proofreaders to the mix. A person can only read a paper for the first time once. Your reviewers are only going to read your paper once. Make sure people understand everything the first time. How does this work? Ask someone to proofread your initial draft, get their feedback, fix what they didn't understand. If someone doesn't understand something, it's your fault. Period. Once you have the second draft, send it to another new person who hasn't read your paper yet. Rinse repeat. How do you know when to stop? Well if the deadline hasn't stopped you, when two people who have yet to read your paper reach the "I get it" thought without any major issues, I think its good to go.

Stop using redundant language! Things like, "In other words" really serve no purpose. Why do you need "in other words"? It means your initial explanation wasn't good enough so go fix your initial explanation. Other dangerous words: "basically" and "in conclusion".

Don't try to impress with crazy language. Unclear language tells me you don't really know what you're talking about or are trying to hide something. If your paper is informative, it will impress. Clarity is informative.

Slowly explain your research with examples. Remember back in college when you were given examples, and teachers slowly built upon the same example? DO THAT!! Take the approach of a teacher - assume your audience has limited knowledge. An example is much easier to understand than an abstract concept. 

Give me your background information. I should be able to understand most aspects of your paper without reading other papers. Don't ever do something like: "We use the model proposed in [10]". I don't want to read another reference to understand your work. Instead give me a brief overview of what this model is. 

Have a checklist in the intro that clearly states what you are contributing. This way I can see if I'm interested enough to keep going.

Finally, how awesome are your pictures? Sure computer scientists aren't the best artists which is perfectly fine. However, if I look at your picture, can I easily understand it? Does it have too much going on? A picture should only explain one concept. Remember, marketing is a big part of your paper and pictures do a lot of the heavy lifting.

On that note, here are a few links by more knowledgeable people than I:
Good luck with paper writing!