How to Read a paper

How To Read a Paper

As part of the The Daily I pull in a set of arXiv papers from CS and frankly I have trouble reading them. I’ve adding this document as a guide to “How to Read” these.

The single most useful thing here is the three-pass method, from S. Keshav’s one-page classic How to Read a Paper — worth a 5-minute read, and it genuinely changes how a lot of engineers approach this.

The three passes

• Pass 1 — 5–10 min, always. Title → abstract → intro → section headings → conclusion → glance at figures. That’s it. You now know: what problem, do I care, did it work. Most papers should end here, and that’s correct — even researchers bail after pass 1 on the majority.

• Pass 2 — ~1 hr, only if it grabbed you. Read the body, but skip the proofs and the math. Study the figures and the results table — often the entire story is in Figure 1 and one table. Read the prose around every equation; the idea is always stated in words nearby. The notation is a precision language for specialists, and you almost never need it to get the point.

• Pass 3 — re-derive everything. For people reimplementing the work. You will essentially never need this. Give yourself permission to skip it forever.

For the non-PhD reader

• Interrogate every paper with the same six builder’s questions:

  1. What problem are they solving?
  2. Why does it matter?
  3. What’s the one-sentence key idea?
  4. How did they test it, and on what?
  5. What’s the limitation — what would break this?
  6. What can I, who ships software, take away?

  If you can answer those, you’ve understood the paper at the level that’s useful to you. The math is implementation detail.

• Read figures and tables first. Authors put their best result in Figure 1. Start there, then read backward to understand it.

• Start in your wheelhouse. Read cs.SE / empirical-software-engineering papers first — they’re near your actual expertise, so you can judge them, which builds the confidence and vocabulary you carry into denser areas. Don’t start with ML theory.

• Use Claude as a reading tutor, not a replacement. Paste an abstract or a gnarly paragraph and ask:

  • “Explain this to a senior software engineer with no ML background.”
  • “What does this notation mean?”
  • “What would a skeptic say about this result?”

  This is the highest-leverage move available, and it compounds — you learn the vocabulary by having it explained in context, repeatedly. (There’s a version of this we could wire into /daily: an opt-in “explain like I build software” expander on arXiv cards. It’d reintroduce an LLM call, so it’s a separate decision from the deterministic pipeline — but it’s a natural fit for exactly this problem.)

(move below to another note, above is generic, below is specific to ML)

Learn ~12 recurring terms once

Once these click, the fog lifts a lot: