Henning Schulzrinne Dept of Computer Science Columbia University

Henning Schulzrinne Dept. of Computer Science Columbia University Writing Papers

On writing papers • Good writing is necessary, but not sufficient • In competitive conferences, all accepted papers are wellwritten – during the review process, not afterwards! • Bamboozle reader with obfuscation rarely works – “Must be a great paper since I don’t understand it” • If you didn’t have time or patience to get the writing right, why should I trust the measurements or proof? • If you don’t care about the reader, why should I waste my time with your paper?

Paper structure • A paper tells a story – like a short novel – introduce the characters – describe setting (but not “It was a dark and stormy night”) – make readers care about the setting and characters – has plot: problem, conflict, resolution – wrap up with “moral” • but – it’s not a detective story – readers will not search for clues to find the perp – it’s not magic realism – unlike (German) novels, it mostly has happy ending – PG-rated

Paper structure • • • Fairly typical, but variations possible – keep template Abstract = quick overview, indexing Introduction = one-page extended abstract – why, how come, how good, what’s coming up Related work = how is this different? – can be at end, but uncommon Protocol, algorithm Experimental setup Experiments Evaluation and discussion of results Future work = things I want to do next Summary = what did we learn? Appendix – details that detract from the main story

Paper title • • Important for classification and first impression Should give key idea or motivation if systems paper Often used to assign paper to reviewers Avoid empty words that apply to 90% of papers – “performance evaluation” – “implementation” • Ask: how many other papers would this title apply to? • Sometimes useful to give project title: – “ 7 DS: Extending the Internet to mobile ad-hoc networks” • Other standard patterns: – “Reducing hand-off delays in 802. 11 networks by hypnosis” – what, where, how

Abstract • Used to assign reviews and to index final paper – thus, important to include appropriate buzz words and abbreviations • What is this about? – area, measurement, theory, … • Why should I care? – key result • How did I prove the result? – experiment, analysis, simulation • Use present tense (“we show that”) except for measurements and implementations (“we measured”) • Avoid fluff at all cost – if this could apply to hundreds of papers, omit it • “TCP throughput is important”

Introduction • • • The most important part of the paper – some reviewers won’t read more than that… – like first impressions: accept/reject opinion is often formed after reading introduction – ideally, should be able to stand alone and be an extended abstract No longer than a page Never, ever start with “Recent advances in X”! Don’t repeat abstract verbatim (although it contains some of the same information) Describe problem, approach, solution, key result – describe larger context if sub-problem • where is this relevant? are there other places, too? Concludes with brief overview of paper (“We first summarize related work in Section 2. Section 3 describes our the algorithm. ”)

Related work • • • What makes our work different from others? – better in some measurable way (faster, more secure, cheaper, …) – more general or different applicability – simpler to implement or understand or secure – more robust (fewer critical parameters) Important for review and reader – reviewers: “yet another paper on X” • particularly if only vaguely familiar with area – reviewers get mad if their work isn’t cited – readers use it to do a breadth-first search on area Honesty counts – don’t dismiss some related work because of superficial difference • “uses uppercase message labels”

Experiments and graphs • • • Did you pick the right graph type? – pie charts and multi-bar charts often wrong – don’t connect points that aren’t a function (e. g. , different experiments) scatter plot Scale: should the graph be log-scaled? Graph legends should be largely self-describing, without reference to text body – explain both axes (“speed of robotic mouse as function of time, with cat”) Must be intelligible in black & white Avoid dozens of lines that all look the same Label lines rather than forcing reader to map “square-with-medium thick dot-dash line” to legend Axes must contain units Avoid simple straight lines – can just describe Include margins of error (confidence intervals) Text should explain all interesting features – e. g. , dips, spikes, peaks, non-smoothness, … – avoid just stating the obvious or repeating data points – answer “why? ” question -- theory that explains behavior • e. g. , via approximation

Description • Avoid conflating levels of details – “The Internet consists of routers (some of which use blue LEDs)” • Avoid sounding like a lawyer – “We implemented a router (using the word implement in the sense of building, but not necessarily testing to ISO 9001. Your mileage may vary; past performance is no indication of future results. No animals were harmed in the making of this paper. )” • Make sure to indicate which results, measurements, implementations are yours – Getting into plagiarism and falsification territory

Writing style hints • Limit use of parentheses (since they distract the reader and indicate that you didn’t want to think about how this text relates to the previous part) – also avoid hyphens • Paper should remain meaningful when reading only the first sentence of each paragraph – “topic sentence” • Transitions – don’t just collate paragraphs and sections – e. g. , “The result is then processed by the sniffle engine, [which we describe next. ]” • Avoid passive voice and weak verbs (is, has)

Questions to ask • Why should somebody else care about the results? • Can somebody not familiar with the research understand the paper? • Why is this not yet another minor tweak on problem X? • Is this an anecdote or a theory? • Is the improvement meaningful and does it come at a cost? – 5% rarely matters unless the system is static • e. g. , no additional bandwidth or CPU can ever be added – Does it require tweaking and only happens if the parameters are just right?

Common “mechanical” problems • • Incomplete sentences Spelling and grammar Use of abbreviations without explanation Figures that can’t be read except with a microscope – incomplete legends – work only in color – use GIF or (worse) JPEG • Incomplete and inconsistent references – use Bib. Te. X! – no year, no conference, no institution (for tech reports), …