How to Read a Research Paper as a Software Developer

Someone on your team drops a link in the chat. An arXiv paper. "This looks like our problem."

You open it. The abstract makes sense. Page two has an equation with four Greek letters and a subscript on the subscript.

You close the tab. You'll get back to it.

You won't.

That's not because you can't read it. It's because nobody told you that you're allowed to read it differently.

A research paper isn't written for you

A paper is written for other researchers, and above all for the reviewers who decide whether it gets published. They want to see that the idea is new, that the math holds and that the experiments are fair. So that's what most of the pages are spent on.

You're asking something else.

Will this make our product better, and what would it take?

That question doesn't need the whole paper. It needs about five things in it, and they're not in the order the paper is written.

Read it like a pull request

You already know how to do this. You do it every week.

When a big pull request lands, you don't start at line one of the first file. You read the description. You look at how much changed. You check the tests. You look for what the author says might break. Only then, if it matters, do you read the code line by line.

A paper has the same parts:

the abstract and the first figure are the description
the results tables are the tests
the limitations section is the list of known issues
the method is the code, and like code, you read it last, once you've decided it's worth your time

Researchers have their own version of this. S. Keshav's short and much-shared How to Read a Paper reads a paper in three passes, each deeper than the last. It's built for reviewing a paper. Here's the version for developers, where the goal is to decide whether it belongs in your code.

Step 1: Write down your question before you open it

One sentence. What would this paper have to show for it to matter to you?

"Can we cut the cost of each answer from our support bot without the answers getting worse?"

It sounds small. It's the whole trick. With a question in hand, you're reading to answer it, and you can stop the moment you have the answer. Without one, every paper is equally interesting and equally impossible to finish.

Step 2: Five minutes on the abstract, the figures and the conclusion

Read the title and the abstract. Skip the introduction for now and look at the pictures: the first figure is often the whole idea drawn as a diagram. Then jump to the conclusion.

Now try to say what they did in one sentence:

"They send the easy questions to a small model and only the hard ones to the big one."

If you can't, read the introduction. If you can, and it has nothing to do with your question, you're done. Close the tab without guilt.

Most papers end here. That's the system working, not failing.

Step 3: Read the results table like a benchmark

This is where developers have an edge. You've read enough benchmark posts to be suspicious of them.

Find the main results table and ask what you'd ask of any benchmark:

Compared to what? The baseline is the thing they beat. Is it what you run today, or something nobody uses anymore?
On what data? A method that shines on a public academic dataset may say little about your logs, your users or your language.
At what cost? Look for model size, hardware, training time and latency. A small gain that needs eight times the compute means something different to you than it does to them.
How big is the win? A fraction of a point on a crowded benchmark is a result for a researcher. It's rarely a reason to change your architecture.

Step 4: Read the limitations before the method

Most good papers have a section, usually near the end, where the authors say where their method falls short. Read it now, before you fall for the idea.

It's the closest thing a paper has to a list of known issues, and often the most honest part of it. It tells you which of your cases are likely to break.

While you're there, look for a link to the code, usually in the abstract or a footnote on the first page. Released code turns trying an idea from weeks of work into an afternoon.

Step 5: Skip the math, for now

You don't need to follow every equation to know whether an idea fits your system. The diagram, the algorithm box and the sentences around the equations usually tell you what it does.

Come back to the math once you've decided to build it. By then you'll have a reason to understand it, and having a reason makes it much easier.

The related-work section can wait too. It's a map of what else was tried, useful later.

Step 6: Read the method with your code open

If the paper survived all that, it has earned a proper read. Do it with your repository next to it.

Read the method asking one thing: where would this go? Which function, which service, which step in your pipeline. What you'd have to change, and what could stay as it is.

That's the difference between understanding a paper and using one.

Step 7: Write five lines, then decide

Before you close it, write down five things:

The problem it tackles
The main idea
The data it was tested on
The key result
Its limits

Five lines is enough for a teammate to decide whether to read it too, enough for you to remember it in three months, and enough to start a conversation about trying it.

Then make the call: not for us, not yet, or let's try it.

If it's a try, try it on your own data, not on their benchmark. That's the only result that counts for your product.

The hard part is finding the paper

Read this way, most papers take ten minutes. The good ones take an afternoon.

The hard part is the step before all of this: knowing which paper to open. Hundreds are published every day, and the one about your problem rarely uses your words for it.

That's what we built iReading Room for. You describe, in plain words, what you're building and where you're trying to get to. Every day, iReading Room reads the new papers against that description and brings you the few that touch it.

Each one comes with a short card holding the same five lines you'd write yourself: the problem, the main idea, the data, the key result and the limits. Every fact on it is checked word for word against the paper's own sentences. So the first four steps often take ten seconds instead of an hour.

And if you work with an AI coding agent like Claude Code or Cursor, it can fetch those papers too, and do Step 6 with you: open your code and show you where the idea would go. We wrote about that loop in Your Code Only Knows Where You've Been.

You don't have to become a researcher

You don't need a PhD to get value from research. You need a question, ten minutes, and the habit of reading the parts that matter to you first.

The researchers already did the hard part. They tried the idea, measured it and wrote down where it breaks.

Read it like a pull request. Then decide if it ships.