Systems papers are written to be defensible, not to be read linearly. Starting at the abstract and grinding to the references is the slowest possible route, and it usually ends somewhere in the evaluation section with the tab still open a week later.
First pass: is this for me?
Five to ten minutes. Title, abstract, introduction, section headings, and conclusion. You are answering one question: what problem does this claim to solve, and do I care? Most papers stop here, and that is the point — the pass exists to let you put things down.
Second pass: what is the idea?
An hour or so. Read the body, skip the proofs, and study every figure. Be strict about axes and units: a graph whose y-axis starts at ninety percent is telling a different story than it appears to. By the end you should be able to explain the mechanism to someone else without the paper in front of you.
- What does the system assume about failures, workload, and hardware?
- What does it give up to get the property it advertises?
- What is it compared against, and is that comparison fair?
Third pass: could I rebuild it?
Several hours, and only for papers that earned it. Reconstruct the work as if you were the author: make the same assumptions, then check whether you would have reached the same design. This is where unstated assumptions surface, and where you find the experiment the authors did not run.
The evaluation section tells you what the authors chose to measure. The gap between that and what you would measure is usually the most interesting part of the paper.
Keeping notes that stay useful
A note written for your future self needs five things: the problem in your own words, the core idea in two sentences, the evidence offered, the limitation that worries you most, and one question you would ask the authors. Anything longer tends not to get re-read, and anything shorter tends not to be worth re-reading.