Traps and Pitfalls in
Academic Writing

Yanyan Jiang


Beware of the deadlines!

  • A2 (research proposal draft): Nov 11
  • A3 (presentation video): Nov 25

Traps and pitfalls in academic writing

  • Before doing any research
  • Before writing anything
  • When you are writing

Advices are from Tao Xie and Michael Ernst.

Before Doing Any Research...

Academic Integrity

“Research” means always setting the highest bar.

No fake

  • Everything should be a truth

Don't hide

  • Show the strengths of your technique
  • But also show equally its weaknesses and limitations
    • This is integrity

Too bad that we all became academic salesman in the involution


What is plagiarism

  • Plagiarism occurs when you use another’s words, ideas, assertions, data, or figures and do not acknowledge that you have done so.
  • If you use the words, ideas, or phrasing of another person or from published material, you must
    • Use quotation marks around the words and cite the source, or paraphrase or summarize acceptably and cite the source.
  • If you use charts, graphs, data sets, or numerical information obtained from another person or from published material, you must also cite the source.
  • You must always acknowledge your sources by citing them. In this way, you have the right to use another’s creative output by giving that person credit for the work s/he has done.

Benchmarking Crimes

Benchmarking crimes

  • selective benchmarking
  • improper handling of benchmark results
  • using the wrong benchmarks
  • improper comparison of benchmark results
  • missing information

Before Writing Anything...

What's Your Research Contribution?

How to evaluate a research work's contributions

  • Problem?
  • Significance and novelty?
  • Evidences?
    • Badly: we submit too many useless “toilet papers”

Evaluation criteria (SE conferences)

  • Soundness
  • Significance
  • Novelty
  • Verifiability
  • Presentation

Take Good Care of Your Reviewers

  1. Outsiders
    • Knows nothing about your specific research
    • But carries with their own logics
  2. Expert reviewers
    • Everything is trivial in their perspectives
  3. Nitpick reviewers
    • Comes with an SMT solver that negates all your claims
    • No clarification → accept it's counterpart
      • Don't argue for significance → insignificant


Start writing early!

  • Writing is a hard time for everyone (also the case for your advisors)
  • I start early.

My mechanism to ensure early writing

  • Create a shared repo on Overleaf
    • Paid $180/yr for premium features!
  • Watch over the progress

Understanding Research Contributions

How to Claim Your Contributions?

From an existing problem (incremental work)

  • → Improvements bring real practical benefits
  • → Harmful if the problem is not solved

From a new and important problem

  • → This is the first work to ...

And defend your claim of contributions

  • Common traps
    • Insignificant research (quit PhD asap)
    • Lacks a story
    • Broken logic
    • Insufficient evidences

Example: EXPLODE (OSDI'06; Best Paper)

Story and problem

  • Storage systems ... have a simple, basic contract: you give them data, they do not lose or corrupt it. Often they store the only copy, making its irrevocable loss almost arbitrarily bad. Unfortunately, their code is exceptionally hard to get right, ...
  • This paper describes EXPLODE, a system that makes it easy to systematically check real storage systems for errors.


  • It found serious bugs in a broad range of real storage systems (without requiring source code): ... We found bugs in every system we checked, 36 bugs in total, typically with little effort.

For Software Engineering Papers

Useful in improving software quality or productivity

Think of your work

  • Whom are you serving?
  • To what extent have you changed their software engineering practices?
  • Why must they care about your work?
    • The “programmer test”
  • How to validate your claim by experiments?

Think of a one-minute introduction of your work to big bosses


Don’t make readers a hard time in reading your papers!

Your technical content is already hard enough.

Concise and Precise

The bad practice: write an essay (at least 120 words)

  • Your writings are usually verbose (meet the requirements) rather than precise and concise (convince the others)

Vigorous writing is concise. A sentence should contain no unnecessary words, a paragraph no unnecessary sentences, for the same reason that a drawing should have no unnecessary lines and a machine no unnecessary parts. This requires not that the writer make all his sentences short, or that he avoid all detail and treat his subject only in outline, but that every word tell.

—— The Elements of Style

Improving Your Logic Flow

A “least surprise” paper

  • Introduction is the expansion of abstract
  • Paper is the expansion of introduction
  • Paragraph is the expansion of topic sentences
  • Every sentence connects its contexts
    • Readers can quickly verify your paper's soundness with minimal effort

Two Approaches to Writing

Top-down approach

  • Abstract → introduction → full paper
  • Pros: helps you quickly finish the paper
  • Cons: the abstract/intro may be suboptimal

Bottom-up approach

  • Technical parts and evaluation (plan) → introduction → abstract
  • Pros: better paper
  • Cons: wastes time on polishing technical parts

Zoom In: Sentences

Principle (1): No Grammatical Mistakes

First, no spelling mistakes!

  • Don't insult your expert readers.

Eliminating grammatical mistakes are challenging for non-native speakers

  • Tenses (sometimes we have conventions, e.g., present simple in describing your experiments)
  • A v.s. the
  • That v.s. which?
  • ...

Principles (2): Keep Logic Flowing

(Majumdar and Niksic; POPL'18)

(1) [Topic Sentence] Large-scale distributed systems are difficult to build and test. (2) On top of the non-determinism arising out of concurrent exchange of messages, these systems must account for partial failures, where components or communication can fail along the way and produce incomplete results. (3) Fault-tolerant components are difficult to design and reason about, ...

distributed systems → basic ideas → the hard part

  • Long sentence (2), but the logic is easy to follow.

Zoom In: Words

Principle (1): Be Precise

Each word has its distributed representation (embedding)

  • Software (emphasizes that it is a product)
    • software engineering
  • Program (the most general and neutral term)
    • program synthesis, program synthesis
  • Code (usually a subject to be analyzed)
    • code generation, code completion

Principle (2): Be Consistent

Use words consistently across your paper

  • Example: software, program, and code are sometimes interchangeable
    • but don't switch between them to indicate a same thing

Common Anti-patterns

Vague/offensive/subjective words

  • Very well → satisfactory, ... (still not satisfactory)

Informal writing

  • It's → it is; can't → cannot

Other minor issues

  • Since → because (components may become coupled since the adaptation introduces dependency)

Zoom In: Punctuation

(Just a few examples)

Parentheses and Brackets

Which one is correct?

  • Please read the analysis. (You'll be amazed.)
  • Please read the analysis (you'll be amazed.)
  • Please read the analysis (you'll be amazed).

Which one is correct?

  • In EXPLODE[1], ...
  • In EXPLODE [1], ...

Starcraft players usually cannot see the difference.

Oxford Comma

Quotation Marks

Be careful!

  • I wrote “fixing a mistake.” That's correct in US grammar. Or, “fixing a mistake,” if it were followed by a comma.
  • Not in the UK: you'd write “fixing a mistake”.

The one exception we agree on: If the quote is around a symbol. For instance:

  • We denote this situation with the label “O”.
  • Colons: be careful!



Learn from native speaker's papers

  • Read sufficiently many papers
  • Find the style you loved
  • Practice

Find useful resources

  • (QDT) Grammar Girl's Quick and Dirty Tips
  • (EOS) The Elements of Style
  • (CMOS) The Chicago Manual of Style