A Practical Guide to Writing Good Papers

Created in October 02, 2025

A Practical Guide to Writing Good Papers

Submitting a paper is easy, but getting a paper accepted is hard…

Writing a paper is like showing someone a beautiful landscape through a window. The landscape (your ideas and results) defines the true value of the view (the paper), but the window (the paper’s presentation) determines how clearly others can see it. A spotless window won’t make the landscape itself more stunning, but a dirty one can easily ruin it.

In this guide, I (Fred) compile and share practical tips and tricks to help you keep your presentation clean and clear, ensuring your work is appreciated for the strength of its ideas rather than hindered by its presentation.

Table of Contents

  1. Why write a paper in the first place?
  2. Formatting
  3. General language tips
  4. Structure
  5. Figures
  6. References
  7. Final checks before submitting
  8. Rebuttals

Types of papers

Before we talk about good papers, what is a paper?

Before talking about presentation, let’s quickly recap what makes a good paper content-wise. In ML-related fields, most papers fall into one of three main categories (omitting reviews and position papers):

  • Improving the state of the art (SOTA) for a well-known task. This is the most common (and often the easiest) type of paper to write. However, it can easily feel incremental unless your improvement introduces something meaningfully different. For these papers, the focus is on strong and relevant baselines and rigorous benchmarks.
  • Expanding the understanding of existing methods, for example by generalizing a framework, explaining its successes and limitations, identifying new failure cases. Ideally, such insights should be actionable, i.e., they should suggest ways to improve the existing method. These papers are trickier to write, as you must convince reviewers that your findings are both novel and important, and the structure is less clear.
  • Introducing a new benchmark (evaulation) or dataset (training) for an existing task. While other types of paper can also introduce new datasets, such papers place the release of the dataset as a central contribution.
  • Introducing and addressing a whole new task. In this case, you must compare your method against a naive baseline (ideally several).

Whatever the case, don’t start writing until it’s absolutely clear which of these three categories your project belongs to.

Editor

Where to write your paper, and how to collaborate?

We write papers using Latex and we use the collaborative online editor Overleaf. If we decide to write a paper for your project, I (Frédéric) will setup the template and invite your to the project. You can use your ETH credentials for Overleaf, as you have access to a free pro account as a student. If you prefer to work using your private account, send me the corresponding mail address. The typical structure of the project will be:

overleaf project/
├─ author-kit/      # The author-kit that is provided by the conference
│  ├─ style.tex         # The raw code of the formatting instruction (also the blueprint for the paper)
│  ├─ style.pdf         # The compiled formatting instruction. This must be read thoroughly
│  ├─ style.sty         # The style file for the paper
│  ├─ style.bst         # (optional) The style file for the bibliography and citations
│  └─ ...
├─ figures/         # Folder containing all the figures of your paper
│  ├─ fig1.pdf/         # Figures must me imported in pdf format (no png/jpg/svg)
│  ├─ fig2.pdf/
│  └─ ...
├─ main.tex         # Main file (typically a copy of stlye.tex)
└─ references.bib   # File containing all the bibtex entries for your citations.

There are two useful Overleaf features that you (we) will most likely use:

  • Commenting: You can add comment to selected parts of the raw latex code. These comments can be viewed addressed and resolved by the other collaborators. Click on the Review tab at the top right of the webpage to show/hide comments.
  • Reviewing: If you want to propose a change to a specific part of the text, you can turn on the Reviewing mode by clicking over the Editing (small pen) button at the top right of the latex code editor. When this mode is on, every change you make will be marked as temporary, and other collaborators can review them before accepting them. This is typically useful toward the end of the writing.

Finally, you can click on the small page logo at the right of the Compile button to see errors and warnings about your latex code. All erros (red) and warning (orange) must be addressed before submission. These typically include:

  • Broken references
  • Double bibliography entries
  • Figures overflowing in the margin
  • Missing information for a given bibliography.
  • …

Formatting guidelines

How to format your paper?

Each conference/workshop provides an author kit along with submission guidelines. Adhering to these formatting rule is crucial, and any modification typically results in a desk rejection (i.e., a rejection based on form rather than content). Before you write anything, read these instructions thoroughly. Typical mistakes include:

  • Importing a package that modifies the margin such as \include{geometry}.
  • Importing a forbidden package.
  • Changing the font size of the main text.
  • Misplacing the captions of the tables and figures (typically above for Tables, and below for Figures, but this varies).
  • Submitting the appendix along with the main text (sometimes it’s accepted, sometimes not).
  • Exceeding the page limit.
  • Exceeding the limit for references (yes you read correctly, some conferences like ICASSP only allow for a single page of references).
  • …

In addition, while this is not never mentioned explicitely, submitting a paper that does not reach the page limit is a very bad look.

Structure

How to structure your paper?

The general structure of a paper is the following:

  1. Abstract: A concise summary of the problem, method, and main results. It should clearly state what you did, why it matters, and how well it worked.
  2. Introduction: Motivates the problem, highlights its importance, position your approach (just enough to make your contributions clear), and summarizes your key contributions. Make it engaging (maybe use an example) but factual. Typically, the introduction ends with a 3-5 bullet points list of the main contributions. Be careful not to overclaim.
  3. Related work: Positions your paper within existing research in more details. Explain what others have done and how your approach differs or improves on theirs. Strucutre your related work using 2-4 paragraph (i.e., using `\paragraph{}), each covering a topic. For instance, if you introduce a new transformer architecture for NLP, you might have a sectin on transformers, and one on NLP.
  4. Background: Introduces key concepts, notations, or models needed to understand your method. Keep it short and directly relevant.
  5. Method: The technical core. Clearly describe your approach, equations, and design choices so that others could reproduce your results.
  6. Experiments: Explain how you evaluate your method: datasets, baselines, metrics, implementation details, and compute infrastructure (using \paragraphs{}). Justify every choice. In general, we should always have a quantitative and a qualitative evaluation. For instance, we compare tour proposed methods using metrics and using qualitative examples (both good and bad, showing failure modes is usually well appreciated, sometimes even requied.)
  7. Results: Present your findings using tables and figures. Highlight trends and discuss what the results demonstrate, not just the numbers.
  8. Discussion: Interpret the results: why they matter, what insights they reveal, and how they relate to your hypotheses or prior work.
  9. Limitations: Honestly acknowledge weaknesses and open questions. This shows maturity and builds reviewer trust.
  10. Conclusion: Summarize the key takeaways and possible future directions. End with what the reader should remember.

Depending on the size and complexity of the paper, some sections can be merged. The minimal (incompressible) structure is:

  1. Abstract
  2. Introduction
  3. Related Work
  4. Method (merged with background)
  5. Experiments (merges with results)
  6. Discussion (merges with conclusion and limitations)

The section titles are flexible, and the position of the related work section is flexible (see References for more details.)

Writing Heuristics

Okay cool… but how to actually write a good paper?

Writing a clear and engaging paper is challenging, but many practical heuristics can help. I recommend reading this blog post and this summary of writing tips. For a more practical and detailed set of guidelines, you can find below a collection of useful writing tips compiled by my supervisor Roger Wattenhofer.

Click to expand >Here is some advice on how to write a research paper I (Roger) keep repeating to my students: >* Write **short sentences**. Especially if you are not a native speaker. >* Generally write as if writing a **textbook**, i.e. explain everything, make examples, add figures! >* Overleaf and other text editors mark erroneous words with **dashed red lines**. If you have such a marked word, google it! If it is correct (or a technical term) then add the word to your dictionary. This way you are only left with errors, and they are very easy to spot. >* Another good idea is to pass every paragraph through **ChatGPT**, asking for corrections. Asking for improvements could also be insightful. >* Think about names for **variables** and concepts early. The simpler the better. >* Are there difficult parts in your text? Include **figures and examples** early! You are not writing for yourself, you write for an audience (and I always try to read as if I never heard of the subject). >* Forbidden words: "**very**", "extremely", etc. Yes, there are exceptions, such as "The very nature of this study..." >* More forbidden words: "**obvious**", "**trivial**", etc. What is trivial for you may not be trivial for the reader. If it is so obvious, why don't you explain it in one sentence? >* Forbidden expression: "**This follows from the fact that...**" (and similar expressions). This can certainly be shortened, right? >* Forbidden contracted forms: "**don't**", "**can't**", etc. Papers are in formal English, and these short forms surely *aren't* formal. Instead write "do not", "cannot", etc. >* **Pronouns** are problematic, as sometimes *it* is rather ambiguous what *they* stand for. So just write the proper name (node u, process p, edge e, etc.) again (and not "it" or "he"). This may be bad style in colloquial English, but it is superior technical writing. >* Write **"he" or "she"** only if you properly introduce some gendered agents, for instance "Alice" and "Bob". However, even in the case of "Alice" and "Bob" it is often better to just write "Alice" and "Bob" again, instead of "he" and "she". Also, the terms "he" and "she" are dying, being replaced by "they" (singular). So if you did not introduce actual agents, then always write "they". >* Do not use **synonyms** for technical terms, always stick with the same term. If the community already uses different terms to describe the same object you may mention that other term once in the introduction or the model section (so that readers familiar with another term will recognize the subject). >* Simplify **equations**, get rid of notional clutter such as unnecessary brackets, in particular $\log(n)$ -> $\log{n}$. >* Don't do **equation numbers** at equations, unless you refer to them later in the text. >* This is actually the mistake I correct most often: Don't do **footnotes** just before punctuation marks. The same thing holds for punctuation marks and quotes. It looks wrong but this is "correct." (Citations should be before the punctuation mark!) >* **Quotation marks** are weird, and should look like ` `` ... ''` in the source. >* Having several footnotes in a text might make sense, but don't do just a **single footnote** in your whole text. >* Use **upper case** letters to refer to Figure 9, Table 6, or Theorem 3. However, use **lower case** letters if you refer to something without number, e.g. "In the next section we prove our main theorem." >* If a section X has a **subsection** X.1, then it also must have a subsection X.2. >* Do **not copy/paste** text and sentences from anywhere, also not your own previous work. Some of the submission systems check similarity automatically, and once you get a high similarity score with another document, you are going to be rejected, and rightly so. >* We generally write **US English**, not British English. >* Never try to sell your paper in the **abstract**. Use the introduction for the marketing, but keep the abstract plain and simple, telling the educated reader (someone working in the same area) as objectively as possible what the results of the paper are. >* There are various **introduction** styles. Sometimes plain and simple is best, sometimes we need a bit more thunder (and context), sometimes it's even reasonable to talk about the bigger picture first. In any case, it is important to clearly state the contributions (possibly even with bullet points). >* Never start with "**Recently** there have been a lot of papers on my topic". This is a very bad start, because it immediately proves that your paper is just the next one in a long list of papers. >* I am a big fan of having **a picture** explaining the idea of the paper (e.g., a motivating example) already on the first page of the paper. It can almost always be done, and is an attractive bait to read a paper. >* **Never praise yourself**: Never write things like "This paper is very important because ...". Importance should become clear from the context, without explicitly writing it. (It's of course important to explain why a paper is important; you need to think carefully about the best angle to sell your work.) >* I don't like the "This paper is **structured as follows**" paragraph at the end of the introduction. Only use it if it has a message, i.e., if the structure is not standard.

Figures

Section under construction — Fred. <!–

  • Pictures, figures, tables are always great, as even lazy reviewers look at them. Don’t be afraid of writing extensive captions. The best captions explain everything in the picture/figure/table, nobody likes to search the main text for the relevant information regarding a figure.
  • easy reproducibility, modularity
  • long captions
  • color
  • size
  • font
  • example
  • type –>

    Tables

Tables are boring, so focus on making them clean and readable. Here are a few rules:

  • In latex, we use tabularx tables, not tabular.
  • Professional tables do not have vertical lines.
  • The horizontal lines are added using \midrule, \midrule, \midrule or \cmidrule (for partial lines). These come from the booktabs package.
  • The font size should be equal or 1 point smaller than the main text. Do not reduce it more to make it fit.
  • You might use the multirow package to merge cells.
  • Tables should span the text width. Exceptions are:
    • The paper uses a two columns format. In that cases, tables can either span one or two columns.
    • Your table simply does not have enough columns to span the entire paper. In that case you might use \wraptable from wrapfigpackage.

Here is a minimal example:

\documentclass{article}
\usepackage{tabularx}
\usepackage{booktabs}
\usepackage{multirow}

\begin{document}
\begin{table}[h]
\centering
\small % usually 9 points, compared to 10 points for the default article font size
\setlength{\tabcolsep}{3pt} % narrower columns
\renewcommand{\arraystretch}{0.9} % 10% shorter rows
\caption{Famous Datasets.} % Might cbe placed below the table sometimes. Check formatting guidelines.

\begin{tabularx}{0.99\textwidth}{X X p{1cm}} %X equally divides the remaining space (i.e., 0.99\textwidth - 1cm)
\toprule
Dataset       & Description           & Size        \\ \midrule
MNIST         & Handwritten digits    & 70,000      \\
CIFAR-10      & Tiny colored images   & 60,000      \\
ImageNet      & Everything ever       & 14,197,122  \\
IMDB Reviews  & People yelling online & 50,000      \\
Titanic       & Who survived?         & 891         \\
\bottomrule
\end{tabularx}

\end{table}
\end{document}

Citation and References

This is likely the most boring, repetitive, and overlookd aspect of writing a paper, yet it is also one of the most impoartant. A clear positioning of your paper with respect to related work is a sign of academic proficiency. Think of the references as the root of your paper: If they are waek, your paper will not resit the storm of reviews. This section addesses two key aspect: when to cite a paper, and how to do so.

  • What types of papers should you cite.
    • Seminal
    • Related work
      • Comparable: State-of-the-Art, popular
      • Non comparable
    • Methodology and tools
    • Supporting / Theoretical foundations
    • Others (backgound or motivation)
  • Where to place the related work
    • Related work is important! That’s why we spend so many bullet points on it.
    • Describe the main points the related work. Also say what is similar and even more importantly what is different from your work.
    • Even the related work section of your paper should be different from similar previous papers. Try to have a unique angle on how to present things, bring an order into your arguments.
    • Related work can go second (if the paper is based on related work), or to the end (if the paper is not very much related to prior work).
    • Do self-citations without names, as humble and passive as possible.
    • Important and seminal work should possibly be cited with FirstAuthor et al. the first time you cite the paper, very important work should be cited with all author names the first time you cite the paper! (In Machine Learning, the references often already include the name of the first authors. Try to avoid “LastName et al. (Last Name et al., 2020)”.
    • Praise your competitor: You improve some result? Never write “these petty jerks did not even notice that…”. Instead, write that this other work was great, still you were able to improve it. Improving something great makes you even greater!
    • It’s worth to carefully check whether somebody on the program committee has worked on a similar problem. (Just imagine being that reviewer, and you know what I mean.)
    • If your paper has multiple results, bring the best one as early as possible. The page-filler results should be used as that.
    • Theory: Finding a proof is at most half the work, often less! What is the best way to prove your proof? How should you structure it into lemmas? This process of improving a proof is not so different from programming (and refactoring) your initial algorithm.
    • In theory, conclusions are often not necessary. In practice (i.e., conferences on the practical side of the spectrum), some reviewers absolutely expect conclusions, or they will simply reject the paper. In general, be careful about mentioning any “open problems” in the conclusions that reviewers might understand as “should also be done in order to get accepted”. In the camera-ready version you are free to include whatever open problem or conjecture you like, of course.
    • Just summarizing the contributions again at the end of the paper is boring. Find at least a new angle how to sell your work.
    • Please fix the biography so that all citations have the same style. Go check the bibtex entries of our publications for examples. Here is a long article how to do your bibliography. I agree with most of it.
    • You will encounter many lazy (experienced?) reviewers. These reviewers usually read introduction, related work, and all figures/tables and their captions.
  • \cite, \citep and \citet 
@inproceedings{author2025neurips,
  title=,
  author={Author, Alice and Bob, Charlie},
  booktitle=,
  year={2025}
}

@inproceedings{author2025iclr,
  title=,
  author={Author, Alice and Bob, Charlie},
  booktitle=,
  year={2025}
}

@inproceedings{author2025icml,
  title=,
  author={Author, Alice and Bob, Charlie},
  booktitle=,
  year={2025}
}

@inproceedings{author2025aaai,
  title=,
  author={Author, Alice and Bob, Charlie},
  booktitle=,
  year={2025}
}

@inproceedings{author2025ijcai,
  title=,
  author={Author, Alice and Bob, Charlie},
  booktitle=,
  year={2025}
}

@inproceedings{author2025acl,
  title=,
  author={Author, Alice and Bob, Charlie},
  booktitle=,
  year={2025}
}

@inproceedings{author2025emnlp,
  title=,
  author={Author, Alice and Bob, Charlie},
  booktitle=,
  year={2025}
}

@inproceedings{author2025cvpr,
  title=,
  author={Author, Alice and Bob, Charlie},
  booktitle=,
  year={2025}
}

Checklist before submitting

  • Use a grammar correcting tool such as Grammarly.
  • Proofread for grammar and style (you should read through the full paper at least 3 times). This includes:
    • The main text.
    • The title and section titles.
    • The figures and tables.
  • Ensure formatting follows conference guidelines. In particular:
    • Check that you didn’t inadvertantly change the font size, paper margin, style file, etc.
    • Check page and reference limits.
    • Check that you didn’t add any forbidden package.
  • Check that there are no more overleaf warning or error. If yes, address them.
  • Create an account on the submission website (typically OpenReview or Microsoft CMT) to be registered as an author.

Additional ressources:

  • I recommend reading (at least the TL;DR) of Neel Nanda’s blog post.
  • Similar with Jakob N. Foerster’s blog post.