How to write a great research paper

Download 18,81 Kb.
Date conversion30.01.2017
Size18,81 Kb.

How to write a great research paper

  • Simon Peyton Jones
  • Microsoft Research, Cambridge

Writing papers is a skill

  • Many papers are badly written
  • Good writing is a skill you can learn
  • It’s a skill that is worth learning:
    • You will get more brownie points (more papers accepted etc)
    • Your ideas will have more impact
    • You will have better ideas
  • Increasing importance

Writing papers: model 1

  • Idea
  • Write paper

Writing papers: model 2

  • Idea
  • Do research
  • Write paper
  • Idea
  • Write paper
  • Do research
  • Forces us to be clear, focused
  • Crystallises what we don’t understand
  • Opens the way to dialogue with others: reality check, critique, and collaboration

Do not be intimidated

  • Write a paper, and give a talk, about any idea, no matter how weedy and insignificant it may seem to you
  • Fallacy You need to have a fantastic idea before you can write a paper. (Everyone else seems to.)

Do not be intimidated

  • Write a paper, and give a talk, about any idea, no matter how insignificant it may seem to you
  • Writing the paper is how you develop the idea in the first place
  • It usually turns out to be more interesting and challenging that it seemed at first

The purpose of your paper

Why bother?

  • Good papers and talks are a fundamental part of research excellence
  • Fallacy
  • we write papers and give talks mainly to impress others, gain recognition, and get promoted

Papers communicate ideas

  • Your goal: to infect the mind of your reader with your idea, like a virus
  • Papers are far more durable than programs (think Mozart)
  • The greatest ideas are (literally) worthless if you keep them to yourself

The Idea

  • Figure out what your idea is
  • Make certain that the reader is in no doubt what the idea is. Be 100% explicit:
    • “The main idea of this paper is....”
    • “In this section we present the main contributions of the paper.”
  • Many papers contain good ideas, but do not distil what they are.
  • Idea
  • A re-usable insight,
  • useful to the reader

One ping

  • Your paper should have just one “ping”: one clear, sharp idea
  • Read your paper again: can you hear the “ping”?
  • You may not know exactly what the ping is when you start writing; but you must know when you finish
  • If you have lots of ideas, write lots of papers
  • Thanks to Joe Touch for “one ping”

The purpose of your paper is not...

  • To describe the WizWoz system
  • Your reader does not have a WizWoz
  • She is primarily interested in re-usable brain-stuff, not executable artefacts

Your narrative flow

  • Here is a problem
  • It’s an interesting problem
  • It’s an unsolved problem
  • Here is my idea
  • My idea works (details, data)
  • Here’s how my idea compares to other people’s approaches
  • I wish I knew how to solve that!
  • I see how that works. Ingenious!

Structure (conference paper)

  • Title (1000 readers)
  • Abstract (4 sentences, 100 readers)
  • Introduction (1 page, 100 readers)
  • The problem (1 page, 10 readers)
  • My idea (2 pages, 10 readers)
  • The details (5 pages, 3 readers)
  • Related work (1-2 pages, 10 readers)
  • Conclusions and further work (0.5 pages)

The abstract

  • I usually write the abstract last
  • Used by program committee members to decide which papers to read
  • Four sentences [Kent Beck]
    • State the problem
    • Say why it’s an interesting problem
    • Say what your solution achieves
    • Say what follows from your solution


  • Many papers are badly written and hard to understand
  • This is a pity, because their good ideas may go unappreciated
  • Following simple guidelines can dramatically improve the quality of your papers
  • Your work will be used more, and the feedback you get from others will in turn improve your research


  • Abstract (4 sentences)
  • Introduction (1 page)
  • The problem (1 page)
  • My idea (2 pages)
  • The details (5 pages)
  • Related work (1-2 pages)
  • Conclusions and further work (0.5 pages)

The introduction (1 page)

Describe the problem

  • Use an example to introduce the problem

State your contributions

  • Write the list of contributions first
  • The list of contributions drives the entire paper: the paper substantiates the claims you have made
  • Reader thinks “gosh, if they can really deliver this, that’s be exciting; I’d better read on”

State your contributions

  • Do not leave the reader to guess what your contributions are!

Contributions should be refutable

  • NO!
  • YES!
  • We describe the WizWoz system. It is really cool.
  • We give the syntax and semantics of a language that supports concurrent processes (Section 3). Its innovative features are...
  • We study its properties
  • We prove that the type system is sound, and that type checking is decidable (Section 4)
  • We have used WizWoz in practice
  • We have built a GUI toolkit in WizWoz, and used it to implement a text editor (Section 5). The result is half the length of the Java version.

No “rest of this paper is...”

  • Not:
  • Instead, use forward references from the narrative in the introduction. The introduction (including the contributions) should survey the whole paper, and therefore forward reference every important part.
  • “The rest of this paper is structured as follows. Section 2 introduces the problem. Section 3 ... Finally, Section 8 concludes”.


  • Abstract (4 sentences)
  • Introduction (1 page)
  • Related work
  • The problem (1 page)
  • My idea (2 pages)
  • The details (5 pages)
  • Related work (1-2 pages)
  • Conclusions and further work (0.5 pages)

No related work yet!

  • Related work
  • Your reader
  • Your idea
  • We adopt the notion of transaction from Brown [1], as modified for distributed systems by White [2], using the four-phase interpolation algorithm of Green [3]. Our work differs from White in our advanced revocation protocol, which deals with the case of priority inversion as described by Yellow [4].

No related work yet

  • Problem 1: the reader knows nothing about the problem yet; so your (carefully trimmed) description of various technical tradeoffs is absolutely incomprehensible
  • Problem 2: describing alternative approaches gets between the reader and your idea
  • I feel tired
  • I feel stupid


  • Abstract (4 sentences)
  • Introduction (1 page)
  • The problem (1 page)
  • My idea (2 pages)
  • The details (5 pages)
  • Related work (1-2 pages)
  • Conclusions and further work (0.5 pages)

Presenting the idea

  • 3. The idea
  • Consider a bifircuated semi-lattice D, over a hyper-modulated signature S. Suppose pi is an element of D. Then we know for every such pi there is an epi-modulus j, such that pj < pi.
  • Sounds impressive...but
  • Sends readers to sleep
  • In a paper you MUST provide the details, but FIRST convey the idea

Presenting the idea

  • Explain it as if you were speaking to someone using a whiteboard
  • Conveying the intuition is primary, not secondary
  • Once your reader has the intuition, she can follow the details (but not vice versa)
  • Even if she skips the details, she still takes away something valuable

Putting the reader first

  • Do not recapitulate your personal journey of discovery. This route may be soaked with your blood, but that is not interesting to the reader.
  • Instead, choose the most direct route to the idea.

The payload of your paper

  • Introduce the problem, and your idea, using
  • and only then present the general case

Using examples

  • Example right away
  • The Simon PJ question: is there any typewriter font?

The details: evidence

  • Your introduction makes claims
  • The body of the paper provides evidence to support each claim
  • Check each claim in the introduction, identify the evidence, and forward-reference it from the claim
  • Evidence can be: analysis and comparison, theorems, measurements, case studies


  • Abstract (4 sentences)
  • Introduction (1 page)
  • The problem (1 page)
  • My idea (2 pages)
  • The details (5 pages)
  • Related work (1-2 pages)
  • Conclusions and further work (0.5 pages)

Related work

  • Fallacy To make my work look good, I have to make other people’s work look bad

The truth: credit is not like money

  • Giving credit to others does not diminish the credit you get from your paper
  • Warmly acknowledge people who have helped you
  • Be generous to the competition. “In his inspiring paper [Foo98] Foogle shows.... We develop his foundation in the following ways...”
  • Acknowledge weaknesses in your approach

Credit is not like money

  • Failing to give credit to others can kill your paper
  • If you imply that an idea is yours, and the referee knows it is not, then either
    • You don’t know that it’s an old idea (bad)
    • You do know, but are pretending it’s yours (very bad)


  • Abstract (4 sentences)
  • Introduction (1 page)
  • The problem (1 page)
  • My idea (2 pages)
  • The details (5 pages)
  • Related work (1-2 pages)
  • Conclusions and further work (0.5 pages)

Conclusions and further work

  • Be brief.

The process of writing

The process

  • Start early. Very early.
    • Hastily-written papers get rejected.
    • Papers are like wine: they need time to mature
  • Collaborate
  • Use CVS to support collaboration

Getting help

  • Experts are good
  • Non-experts are also very good
  • Each reader can only read your paper for the first time once! So use them carefully
  • Explain carefully what you want (“I got lost here” is much more important than “Jarva is mis-spelt”.)
  • Get your paper read by as many friendly guinea pigs as possible

Getting expert help

  • A good plan: when you think you are done, send the draft to the competition saying “could you help me ensure that I describe your work fairly?”.
  • Often they will respond with helpful critique (they are interested in the area)
  • They are likely to be your referees anyway, so getting their comments or criticism up front is Jolly Good.

Listening to your reviewers

  • Treat every review like gold dust
  • Be (truly) grateful for criticism as well as praise
  • This is really, really, really hard
  • But it’s really, really, really, really, really, really, really, really, really, really important

Listening to your reviewers

  • Read every criticism as a positive suggestion for something you could explain more clearly
  • DO NOT respond “you stupid person, I meant X”. Fix the paper so that X is apparent even to the stupidest reader.
  • Thank them warmly. They have given up their time for you.

Language and style

Basic stuff

  • Submit by the deadline
  • Keep to the length restrictions
    • Do not narrow the margins
    • Do not use 6pt font
    • On occasion, supply supporting evidence (e.g. experimental data, or a written-out proof) in an appendix
  • Always use a spell checker

Visual structure

  • Give strong visual structure to your paper using
  • Find out how to draw pictures, and use them

Visual structure

Use the active voice

  • NO
  • YES
  • It can be seen that...
  • We can see that...
  • 34 tests were run
  • We ran 34 tests
  • These properties were thought desirable
  • We wanted to retain these properties
  • It might be thought that this would be a type error
  • You might think this would be a type error
  • The passive voice is “respectable” but it DEADENS your paper. Avoid it at all costs.
  • “We” = the authors
  • “You” = the reader

Use simple, direct language

  • NO
  • YES
  • The object under study was displaced horizontally
  • The ball moved sideways
  • On an annual basis
  • Yearly
  • Endeavour to ascertain
  • Find out
  • It could be considered that the speed of storage reclamation left something to be desired
  • The garbage collector was really slow


  • If you remember nothing else:
  • Identify your key idea
  • Make your contributions explicit
  • Use examples
  • A good starting point:
  • “Advice on Research and Writing”
  • mleone/web/how-to.html

The database is protected by copyright © 2016
send message

    Main page