Writing Research Papers
— 779 words — 4 min
These are my notes after reading Common Problems with Conference/Journal Papers by Peter Gutmann. I recommend reading it top to bottom, but my TL;DR is below.
Summarize Background And Related Work
- Summarize the background and related work. It lets the reader know what you’re familiar with, what already exists and whether your work is original or not.
- Check whether the idea already exists. Also BG (before google); do a thorough background search.
Approaching The Problem
- “A problem well stated is a problem half solved.”
- Provide raw data. Enables repeatability so others can prove you were correct, otherwise the next paper might just invalidate your ideas.
- Level of detail. Enough to reproduce the paper, not too much to overwhelm the reader.
- State your assumptions in advance.
For example, in security and cryptography: What is the thread model and what are you defending against?
A good example is in the paper “Tor: The Second-Generation Onion Router” by Dingledine, Mathewson, Syverson:
A hard-to-use system has fewer users, and because anonymity systems hide users among users, a system with fewer users provides less anonymity. Usability is thus not only a convenience: it is a security requirement
- Unrealistic models tend towards “design a cool algorithm, invent an artificial problem for it to solve”. Using some model is better than none at all, but make sure it’s a realistic one.
- Perform a real-world evaluation if interaction with humans is required by your proposed solution. If it turns out that it doesn’t work, then it’s at least a realistic approach with a “why XYZ does not work” solution (though papers with negative results are harder to publish than with positive results).
Analyse The Results
“Much data, little analysis” is bad.
- Provide an analysis whether the observed results are good or bad. Don’t just state the obvious. Explain anomalies. Do they require further investigation?
- What was actually measured? (be aware of caching, buffering, …) Provide measurements of a default operating mode if it exists. What’s different in your measurements? What are the used parameters, variants, modes in ciphers, and so on? What are side effects that might have influenced the measurements? For example, overhead of clock sampling, other network traffic, CPU load, …
- Provide analysis, not just data. (much data, little analysis is bad) When you use statistical methods, explain what you’re doing. Be aware of who your audience is. If it’s just network/* experts on a conference then that might be okay, but usually it’s not.
Diagrams And Tables
- Avoid inappropriate scales, bad labeling, bad choice of units
- Graphs represent trends. Otherwise use a table or put less than 5 values in the text.
- Don’t have huge whitespace nor data crammed into one corner of the graph.
- Show confidence intervals in the graph if measurements require it, e.g. if multiple measurements contain differences.
- Label the axes properly with units.
- Referring to colored lines in the text is not helpful when the paper is printed in black and white.
Recommendation: Stephen Few’s Show Me the Numbers: Designing Tables and Graphs to Enlighten.
Problems vs. Solutions
- In a general paper, the contribution is the solution, it’s not enough to just present the problem.
- If the paper is a AES-breaking paper (that sort of impact), then it is enough to explain and demonstrate what the problem is, because fixing it will be somebody else’s.
Formatting
- Check published papers in the journal you want to publish your work in to check whether it’s a good fit.
- Expand acronyms the first time they’re used. Expand them again if the last use was a few pages back. Don’t make the reader backtrack through several pages to find its initial definition.
- If the acronym is not common, briefly explain what it actually is (Illudium Explosive Space Modulator).
- Check whether author names need to be submitted at your selected journal to select unbiased reviewers. Some require this to avoid that a colleague of the author is assigned for reviewing; some expect anonymous submissions.
- Stay within the page count; or have a extremely good reason not to.
Misc
- Use a spell checker.
- Consistent reference style.
- If you submit source code, make sure it compiles. If it’s not supposed to compile (pseudocode), make sure it’s obvious.
- Publish-Or-Perish is a problem. Think about whether you’re actually advancing research in your field. Read Stop the Numbers Game by David Parnas.
- Take referee feedback seriously—they’re likely representative for the whole of your audience. If they don’t understand the paper, it’s likely that the audience will not either.
Articles from blogs I follow around the net
tweet
17 conversations in Jakarta, Indonesia: https://sive.rs/met/at-14
via Derek Sivers July 3, 2026Post-Quantum Certificates
A summary of post-quantum certificates and the TLS / web-PKI ecosystem as of June 2026.
via Signs of Triviality June 27, 2026Status update, February 2026
Hi all! Lars has contributed an implementation independent test suite for the scfg configuration file format. This is quite nice for implementors, they get a base test suite for free. I’ve added support for it for libscfg, the C implementation. I’ve spent some…
via emersion February 22, 2026Generated by openring