Made by AI, Directed by David Stein

Search
Research & Innovation

Reading Research Papers: Getting Started

Half the tools you'll use in two years exist today as a PDF on arXiv. A three-pass method for artists and developers who want to read those papers without a PhD — and how to tell a real result from a rounding error.

4 min read

Gaussian splatting was a SIGGRAPH paper before it was in three.js. Diffusion models were papers for years before anyone typed a prompt. If you work in creative technology, the tools you’ll be using in two years are on arXiv right now, and the gap between reading about them secondhand and reading the source is mostly a matter of method.

You don’t need to follow every equation. You need to work out what the thing does, whether it works, and whether you can run it.

The three-pass method

This approach comes from S. Keshav’s widely used guide, and it’s still the best structure there is. You read the paper up to three times, and most papers should stop after pass one.

Pass 1 (5–10 minutes): is this relevant? Read the title, abstract and introduction. Read the section headings. Look at the figures. Read the conclusion. Skip every equation. At the end, you should be able to say what problem it solves and what the authors claim. Then decide whether to continue. Most of the time, don’t — that’s the method working, not failing.

Pass 2 (about an hour): what did they do? Read the whole thing, still skipping proofs and heavy derivations. Study the figures and tables carefully. Note terms you don’t know and look up only the ones that block understanding. You should now be able to explain the approach to someone else and say what its limits are. For a practitioner, pass 2 is usually enough.

Pass 3 (several hours): could I reproduce this? Work through the method as if you were implementing it. This is for papers you intend to build on.

What to read first, as a creative practitioner

Papers aren’t written to be read front to back. A useful order:

  1. The figures. Graphics and vision papers are mostly judged on results, and the teaser figure on page one is the authors’ best case.
  2. The abstract.
  3. “Limitations.” Almost every good paper has one, usually near the end, and it’s the most honest section in the document. Read it before the results.
  4. The results table.
  5. Related work, when you want the map of the field rather than this one paper.

Telling a real result from a rounding error

This is the skill that separates reading papers from being marketed to.

  • Ask who made the benchmark. If the authors both created the benchmark and won it, that’s a flag. It doesn’t mean the work is bad; it means the number isn’t independent.
  • Learn what the metric’s scale means. In image quality, PSNR gains of 0.2 dB are invisible to the eye; 2 dB is obvious. FID is comparative, not absolute. If you can’t tell whether a difference matters, look at how much the numbers vary between rows in the same table.
  • Check what was held constant. “Better at equal parameter count” is a real claim. “Better” with ten times the compute usually isn’t.
  • Look for the ablation study. It removes one piece of the method at a time to show what each contributes. A paper with a thorough ablation is generally being careful.
  • Read the failure cases. Authors who show them are telling you where the technique will break in your hands.

Finding the code

For a practitioner this is often the whole point.

  • Check the abstract page for a project page link, which usually has video results and code.
  • Papers With Code links papers to implementations.
  • Search the authors’ GitHub. Code often appears weeks after the paper.
  • Check the license before you plan anything around it. Research code is frequently non-commercial, and model weights often carry a different license than the code.
  • “Code coming soon” sometimes means never. Weigh the paper accordingly.

Where to find papers worth reading

  • arXiv, particularly cs.GR (graphics), cs.CV (vision) and cs.SD (sound). Browse the recent listings for your area.
  • Conference programs: SIGGRAPH and SIGGRAPH Asia for graphics, CVPR and ICCV for vision, NeurIPS and ICML for machine learning, ISMIR for music, CHI for interaction.
  • Hugging Face Papers, which surfaces what practitioners are reading now.
  • Follow a handful of researchers in your area rather than trying to track whole fields.

One habit worth forming

Keep a short note on every paper you finish: two sentences on what it does, one on whether the code exists, and one on what you’d use it for. In six months that file is more valuable than your bookmarks, because the reason you cared is the part you’ll forget.

Related Reading