Notes on writing

Fredo Durand, MIT CSAIL

This is clearly a document in progress.

See also my slides How to Write a Bad Paper

http://people.csail.mit.edu/fredo/FredoBadWriting.pdf

Bottom line: Writing is important.

• Our major contribution is to communicate ideas, not only to create them
• It is NOT superficial for a committee to reject an article based on writing alone
• Even if ideas are great, when nobody can understand them, they are useless

Getting accepted is one thing, having impact is another one. I can cite a number of great
contributions that did not have as much impact as they should have because no one
(except maybe the reviewers) was able to understand the paper. And I can cite you a
number of my papers that are confusing and resulted in misunderstanding. My 2002 tone
mapping paper is a good example. Lots of people have found it hard to implement my
method although it's really really simple. But it's not well explained in the paper. And a
negative outcome is that some of the comparisons out there with my technique are not
fair because people did not implement it well.

High level
Assume reviewers/readers don't know much
Figure out your main story. Extract your main contribution(s). It's not that easy. I've
messed that up many times.
Prioritize, organize your contributions and ideas into a hierarchy.
Make clear what's new, what's different about your technique
Favor clarity over style. You can always polish later.
Don't use an English that is too elaborate. Most readers and reviewers are not native
English speakers. Don't introduce two ideas in one sentence. Sure the sentence sounds
better and more elaborate, but cognitive overload will prevent your readers to understand
anything.
Redundancy is good. Say what you're about to say, say it, then summarize what you've
said. Just make sure you layer the levels of detail: the overview of the section says things
at a high level, then you dive into the details, then you recap at a high level.
Sections should start with a small paragraph that gives a high level overview of the key
points. Again, prioritize, draw a hierarchy of ideas.
Justify choices and technical points. Don't just say "our method does this, this, and this".
Provide motivation, say that since you want to achieve this, you need this step, etc.
Start by writing the overview. Personally, I refuse to read technical content before I can
understand the introduction and overview.
Recall that many people do not read a paper linearly. One should be able to understand
your paper by just skimming through it. Also, many times, readers will read a paper in
multiples steps. It has to be easy to catch up with what was read before. Also, sometimes,
I go back to a paper that I read a while back because I want to check a particular point. I
should not have to re-read the whole paper to get the vocabulary and notations.
I find it easier to write once I have the figures. Referring to figures is an easy way to
improve clarity and tighten the writing, especially in graphics.

Where to start?
I advise that you start with a detailed overview, with maybe one or two bullets per
paragraph. This is the right level of detail to make sure you have the story/information
flow right. Then plan and create the figures you need. It’s often easier to write (in
particular to write clearly) when you have the support of illustrations.

It is in my opinion a bad idea to start too early writing equations and pseudocode.

Choices
A technique involves a number of technical choices. Some of them are important, others
are arbitrary. Make this distinction clear. Explain when a choice is pure question of
artistic taste, when a choice is your very contribution, when it's constrained by technical
requirements, when it's just the easiest thing to do but more advanced techniques might
do better, when a parameter has important effect and what values you suggest.
In articles, we must explain the respective importance of choices

See my slides at http://people.csail.mit.edu/fredo/student.html

Choices:
Model
Algorithms
Parameters
User Interface
Problems we choose
Evaluation criteria

Title
A title can be fancy/catchy vs. informative. The former is nice, the latter is more
important.
Make sure your title is not misleading. You might get the wrong reviewers (cf. the whole
billboard clouds debacle).
A good marketing idea is to make sure that part of the title (the method name) can be
used in a sentence that cites your paper. Titles like “light field” are brilliant from this
perspective. A variation of this, if your work is more systemy, is to name the system and
use that in the title.
Abstract
Should be independent from paper. Should be enough to understand what's good in the
paper.
The paper should not need the abstract to be understood. It is expected that paper and
abstract should be redundant. Some people copy-paste from one to the other, it's OK
(although not great).

Intro
The intro might be the most important section of your paper. It sets the expectations, it
convinces (or not) reviewers that your problem is important and gives a high-level hint of
why your solution is smart.

See retreat CFP co-written with Jovan:

"the summary should discuss the following (not necessarily in this order):
(1) high-level description of approach
(2) general motivation for the problem
(3) what are the alternative approaches to this problem
(4) what is different about your approach
(5) what is your silver bullet or a key idea/concept "

It's a good idea to summarize your contributions at the end of the intro, with a bold
"contribution as a paragraph title because it helps reviewers identify and praise your
contributions. Again, contribution summary is different from method summary. Parts of
your method might be well-known previous work.

Previous work
Avoid laundry list, compare, organize.
classify
make distinction between competing and related (orthogonal) previous work.
When previous work is not directly competing, you can further summarize with one
single sentence about the whole category.

Body
When a section just uses well-known techniques and is here just for completeness, say so.

Results
Your results should support your claims. Be critical of your own results before deciding
to include them. Too often, only the authors see why a given result demonstrates that the
technique is good.
Make sure you compare to appropriate previous work.
Try to break down various aspects of your methods for both cost and benefits.
Figures
Especially in graphics, figures are critical. Make sure that one can get the full story just
by looking at the figures and their captions. The captions should be as self-contained as
possible. In particular, make sure that if you how a naïve result or failure case of previous
methods, it's very very clear that it's not your results: a reviewer/reader could get the
wrong idea.

System papers
They're tough!
See How (and How Not) to Write a Good Systems Paper by Roy Levin and David D.
Redell http://gatekeeper.dec.com/pub/DEC/SRC/publications/levin/SOSPhowto.html

Acknowledgments
Don't forget to acknowledge financial support (ask me)
Acknowledge people who provided proofreading, technical advice, 3D models.
Acknowledge urops (undergraduates) who helped.
The borderline between acknowledgments and authorship is a blurry controversial one.

Vocabulary inflation and other pet subjects

Avoid paradigm at all cost
Avoid framework unless it's relevant.
Title: no ?, no :, no towards
Avoid acronyms unless they're really well established (e.g. BSP trees)
Avoid parentheses and footnotes. If something is useful, put it in the main text body. If
it's not, delete it.
Avoid the future tense.
Avoid the passive form. I have been surprised to see that some technical English teachers
advise students to use the passive form. I understand that using "we" all the time is not
the most elegant formulation ever, but it clearly explains that this is what we do. The
passive form makes things really ambiguous: do things "get done" magically or does your
method do it? Take responsibility for what you do !
Avoid words such as "thus", "therefore", and "hence." If an argument does not follow
logically, they won't help and will only highlight the fact that you don't have a good
argument.

Early drafts (e.g. for retreats)

There are bad misconceptions about feedback and the ineterst of presenting your work to
the rest of the lab. I believe that this is because people look for the wrong kind of
feedback at the wrong stage of a project's life.

At the beginning of a project, before it's fully scoped you can get useful help about
technical solutions and scope. Is this a useful problem to solve? Should it be re-scoped to
be easier, harder, more relevant, more general, etc. Does it remind someone of a similar
problem, are there proven solutions that can be adapted? Is the technical approach you
are planning to use well known to be flawed? Are there easier better alternatives?
Such early stages are the ideal moment to give a meeting-meeting talk.
In terms of writing/presubmission, it can be useful to write an introduction+previous
work as well as a short overview of the proposed approach.

When the project is farther along, you are less likely to get as much technical feedback,
because anyway, you have already solved your technical problems. In addition, things
gets very specialized and few people understand the bells and whistles of what you do.
But this is great time to get feedback about the exposition and demonstration of your
contributions. This is the best time to write a presubmission and see if people understand
what you are trying to solve, if they are convinced that it's useful, if your paper is
readable by someone else than you, if you fail to separate your contributions from well-
know methods. Do your demos really showcase your contributions?

The earlier you write the paper, the more important the introduction is. The most useful
feedback you will get is about the scope and motivation. Make sure you provide enough
context.
Do not focus on the low-level technical details.
Do figures early. They will make your high-level ideas clearer.
Speculate about potential benefits and the kind of results you are hoping to show. This
will help reviewers get a sense of your potential contributions.

Links
See http://people.csail.mit.edu/fredo/student.html