How to Write a Research Paper — From Blank Page to Camera-Ready.

You've done the research. The experiments are run. The results are interesting. Now you have to write the paper. And suddenly, the blank page feels harder than the research itself.

This is Part 2 of a two-part series. Part 1 covered reading. This part covers writing — specifically, how to write a research paper that a reviewer will accept, a reader will understand, and your future self won't be embarrassed by.

The advice here is distilled from Henning Schulzrinne's comprehensive guide on writing technical articles, Simon Peyton Jones' talks on research skills, and Timothy Roscoe's reviewer-side perspective. I've added my own lessons from writing dozens of paper breakdowns on this blog — because explaining someone else's research teaches you what clear writing looks like (and what it doesn't).

The order you should write a paper in.

Here's the counterintuitive part: don't write the paper in the order people will read it. The reading order and the writing order are completely different.

Schulzrinne recommends this sequence:

1. Results and approach — the core of the paper. Write this first because it's what you know best. The experiments, the architecture, the evaluation.
2. Problem statement — now that you've written the solution, you know exactly what problem you were solving.
3. Conclusion — summarize what you found. This is easier once the body exists.
4. Introduction — write this second-to-last. The intro needs to preview the conclusion, so you can't write it until the conclusion exists.
5. Abstract — write this dead last. It's a miniature version of the entire paper. You can't compress what you haven't written.
6. Title — last. Now you know what the paper is actually about (which may be different from what you thought it was about).

The anatomy of a paper.

Every research paper in CS follows roughly the same skeleton. Deviate at your peril. Reviewers expect this structure, and fighting it wastes cognitive budget that should be spent on your ideas.

Title.

Avoid generic words like "novel," "performance evaluation," or "architecture." Almost every paper does a performance evaluation of some architecture, and it better be novel. Nobody useful searches for those terms.

Use specific, descriptive adjectives: reliable, scalable, low-complexity, hardware-aware. If your method has a name, put it in the title. Make the title searchable — it's the only thing most people will ever read.

Abstract (100–150 words).

The abstract is not a teaser. It's a standalone summary. It must contain:

• The problem
• Your approach (one sentence)
• The key result (with a number if possible)

Rules:

• No references. The abstract may be displayed without the rest of the paper (on indexing sites, in proceedings lists). It must stand alone.
• No "in this paper." What other paper would you be talking about?
• No general motivation. Don't explain why the Internet is important. Everyone knows.
• Include the name of your system/method. Search engines index the abstract. Make sure your key terms are in it.
• Highlight results, not just the problem. Many people read the abstract and then decide whether to continue. Give them a reason to.

Introduction.

The introduction has four jobs:

1. Motivate the problem. Why should the reader care? One concrete example is worth a paragraph of abstract motivation.
2. State what's been tried before and why it's insufficient. This is not the full related-work section — just enough context to set up your contribution.
3. State your contribution. Explicitly. "We introduce X, which achieves Y." The first sentence of this paragraph should say what the contribution is.
4. Preview the results. Gloss the numbers. "Our system reduces latency by 40% while maintaining accuracy." Give the reader a reason to keep going.

The last paragraph is the roadmap: "The remainder of the paper is organized as follows. Section 2 introduces…" This paragraph is formulaic and boring. Write it anyway. Reviewers look for it.

Don't repeat the abstract. The abstract and intro serve different functions. The abstract stands alone. The intro sets up the paper's narrative arc.

Related work.

Related work can go after the introduction or before the conclusion. Both are common; the choice depends on whether the reader needs context to understand your approach (put it early) or whether your approach is understandable on its own (put it late).

Don't just list papers. For each cited work, explain what it does, how it relates to yours, and why yours is different or better. A related-work section that reads like a bibliography with prose connectors is useless.

Pro tip from Schulzrinne: cite the PC chairs and as many program committee members as are "remotely plausible." This isn't gaming — it's acknowledging the community your paper lives in. A reviewer who sees their own work cited knows you've done your homework.

The body: problem, approach, architecture, results.

The body should contain:

• Sufficient motivation — at least one example scenario, preferably two, with figures.
• A clear problem statement. Generic enough to be useful beyond your specific implementation.
• Architecture/approach. More generic than your particular implementation. Describe the system that anyone would build, then explain the choices you made.
• Implementation details. Language, platform, dependencies, resource requirements. Keep it brief unless something non-obvious happened.
• Evaluation. Real or simulated performance metrics. End-user studies if applicable. This section must convince a skeptical reader that your system actually works.

The goal: ensure the next person who builds something like yours doesn't make the same mistakes and can take advantage of your best solutions. Discuss the hard problems and the non-obvious mistakes.

Evaluation: making your numbers convincing.

The evaluation section breaks or makes papers. Reviewers spend disproportionate time here. Rules:

• Provide enough detail to reproduce. All parameters, sample sizes, initial conditions. If a reader can't replicate your results, they can't trust them.
• Include statistical confidence. Confidence intervals, standard errors, significance tests. Results without uncertainty bounds are opinions, not science.
• Explain anomalies. If there's a strange dip or spike in your graph, either explain it or prove it's statistical noise (by gathering more samples).
• Make figures self-contained. A reader should understand a figure from its caption alone, without referring to the body text. Label everything. Define abbreviations in the caption.
• Don't just describe the obvious. "Latency increases with load" — the reader can see that from the graph. Instead, explain how it increases. Is it linear? Exponential? Does it match a known queueing model?

Conclusion.

The conclusion is not a summary of the paper. It's a statement of what you proved and what it means. Restate the main result. Discuss implications. Mention limitations honestly. Sketch future work — but be specific. "Future work includes improving performance" is meaningless. "We plan to extend the algorithm to handle dynamic graph topologies" is useful.

The craft of clear sentences.

Structure gets you organized. But readers experience your paper one sentence at a time. Bad sentences kill good papers.

Write short sentences.

If a sentence has more than 25 words, split it. If you need a semicolon, you probably need a period. Academic writing isn't formal because it's complex — it's complex because academics write formally. Stop. Use simple words. Use active voice.

Use active voice.

"The algorithm was implemented" — by whom? Passive voice hides the actor. "We implemented the algorithm" is clearer, shorter, and more honest. Passive voice has its place (when the actor genuinely doesn't matter), but it's overused in academic writing by a factor of 10.

Define terms before you use them.

Every symbol, every abbreviation, every term of art — define it on first use. Don't make readers flip back to figure out what $\mathcal{L}$ means. A notation table helps, but inline definitions are essential.

One idea per paragraph.

Each paragraph should have a topic sentence (first sentence states the point), supporting evidence, and a transition to the next paragraph. If you're making two points, use two paragraphs.

Figures: the highest-bandwidth channel.

A good figure communicates in 3 seconds what text takes 3 paragraphs to explain. Most papers don't have enough figures. The ones they have are usually too small, too cluttered, or too cryptic.

Rules:

• At least one architecture diagram. If your paper proposes a system, show it. Boxes and arrows. Data flow. The reader should see the shape of your solution before reading about it.
• Self-contained captions. "Fig. 3: Results" is useless. "Fig. 3: End-to-end latency vs. request rate for 3 configurations on a 4-node cluster (95th percentile, 10K requests per point)" is useful.
• Legible at print size. If your labels disappear when the figure is 3 inches wide, they're too small.
• Choose wisely. You can't show the entire parameter space. Pick the dimensions that reveal insight. Flat lines and linear relationships that match expectations teach nothing.

The bibliography: details matter.

A sloppy bibliography signals a sloppy researcher. Reviewers notice.

• Avoid "et al." unless there are five or more authors. The person you subsume into "et al." might be your reviewer.
• For conference papers, cite the full conference name, location, month, and year. Not just an abbreviation.
• Check for updated versions. Internet Drafts expire after 6 months. Pre-prints get published. RFCs supersede drafts. Cite the final version.
• Leave a space between initials. "J. P. Doe," not "J.P.Doe."
• URLs break. For papers, cite DOIs or stable references. Use URLs only for software, data, and non-archival material.

Things to avoid.

Schulzrinne maintains a list of common mistakes. The worst offenders:

• Too much motivation. Three reasons are enough, described briefly. If your problem needs five paragraphs of motivation, either the problem isn't important or you're overselling it.
• Describing the obvious. Any result that a competent graduate student would suggest as a solution to your problem is obvious. Don't explain it — it wastes the reader's time and insults their intelligence.
• Unnecessary details. If omitting a detail doesn't harm the reader's understanding of the novel contribution, omit it.
• Spelling errors. Spell checkers exist. If you didn't run one, why should a reviewer trust your technical diligence?
• "Recent advances in XYZ." Stock phrase. Meaningless. Delete it.
• Arial in body text. Sans-serif fonts are for slides and posters. Body text uses serif fonts (Times, Palatino). This is not aesthetic preference — it's readability research.

The reviewer's perspective.

Understanding what reviewers look for transforms your writing. Roscoe's guide makes this explicit:

A reviewer is answering three meta-questions:

1. Is this problem real and significant?
2. Is this solution non-obvious and correct?
3. Is the evaluation convincing?

If any answer is "no" or "I can't tell," the paper gets rejected. Your job as a writer is to make every "yes" easy and obvious.

The review process at major conferences works roughly like this: the paper goes to a TPC (technical program committee) member, who either reviews it personally or farms it out to 2–3 external reviewers (often including grad students — these reviews tend to be the most detailed). The TPC collects scores, the top third gets accepted, the bottom third rejected, and the middle third gets discussed in a meeting. Papers with wildly divergent scores or only two reviews get extra scrutiny.

What this means for you:

• Make the contribution crystal clear. A tired reviewer scanning 20 papers will miss a buried contribution.
• Front-load the good stuff. If your best result is in Section 6, some reviewers will never see it.
• Be honest about limitations. A paper that acknowledges its weaknesses looks more trustworthy than one that pretends they don't exist.
• Help the reviewer help you. Even for rejected papers, a good review provides direction. Make your paper easy to review and you'll get better feedback.

The engineering mindset for writing.

A MarkusQ comment on Slashdot (yes, really) nailed it. Good writing uses the same mental tools as good engineering:

• Top-down design. Start with an outline. Expand from structure to detail — same as software architecture.
• Failure mode analysis. For each sentence, ask: could it be misread? How? Fix it.
• Dependency analysis. Are ideas presented in an order where each point can be understood from the reader's prior knowledge plus what came before?
• Optimization. Are there unnecessary parts? Does the structure require the reader to remember too many details before connecting them?
• Structured testing. Read what you wrote assuming only the knowledge the reader has. Does each part work as intended? Read it aloud. Does it flow?

This isn't a metaphor. Writing is engineering. You're building a structure that transmits ideas from your brain to someone else's. Every unclear sentence is a bug. Every missing definition is an unhandled error. Every buried result is a UX failure.

Peyton Jones' golden rules.

Simon Peyton Jones gives perhaps the best advice on research writing. His key principles:

• The paper is the research. Don't think of writing as something you do after the research is done. The paper is the research artifact. An idea that exists only in your head doesn't exist.
• Identify your key idea. Every paper should have exactly one clear, sharp idea. If you can't state it in one sentence, you haven't found it yet. If you have two ideas, write two papers.
• Tell a story. The paper is a narrative. It should have a beginning (here's a problem), a middle (here's my approach), and an end (here's what happened). The reader should feel tension and resolution.
• Nail your contributions early. By the end of page 1, the reader should know exactly what this paper contributes. Use a bulleted list if necessary.
• Related work is not the enemy. Don't diminish others' work to make yours look better. Be generous and precise. Explain the difference clearly. "Smith et al. solve X but not Y; we address both" is better than "Smith et al. fail to solve Y."

My process: how I write paper breakdowns for this blog.

I don't write traditional research papers (yet), but writing 40+ paper breakdowns has taught me more about clear technical writing than any guide. Here's what I've learned:

Start with the one-sentence hook.

Before writing anything, I force myself to complete this sentence: "This paper shows that ___." If I can't fill in the blank, I don't understand the paper well enough to write about it. The blank becomes the post's thesis.

Explain the problem before the solution.

I spend at least 20% of every post on the problem. Why does this matter? What was broken before? What does the world look like without this paper? If the reader doesn't feel the problem, the solution is just noise.

Draw before you write.

For every post, I draw at least one diagram before writing the body. The diagram forces me to understand the architecture spatially — how data flows, where the bottleneck is, what the key transformation looks like. If I can't draw it, I don't understand it.

Cut ruthlessly.

My first drafts are always 40% too long. I cut anything that doesn't serve the one-sentence hook. Background the reader already knows? Cut. Tangent about a related technique? Save it for another post. Paragraph that repeats the previous one in different words? Delete. Every sentence must earn its place.

Cheat sheet: paper structure at a glance.

Section	Length	Purpose	Write it…
Title	~10 words	Searchable, specific, no fluff	Last
Abstract	100–150 words	Standalone summary with results	Second to last
Introduction	1–1.5 pages	Problem + contribution + preview	After conclusion
Related work	1–2 pages	Position your work in the field	Any time
Body	4–8 pages	Problem → approach → results	First
Conclusion	0.5–1 page	What you proved + what it means	After body

The writing checklist.

Before you submit, run through this:

• ☐ Can a reader state your contribution after reading only the abstract?
• ☐ Is the contribution explicitly stated by the end of page 1?
• ☐ Does every figure have a self-contained caption?
• ☐ Are all symbols defined before first use?
• ☐ Do your evaluation results include confidence intervals or significance tests?
• ☐ Does the related-work section explain how your work differs, not just that it differs?
• ☐ Have you spell-checked the entire document?
• ☐ Has at least one non-author read the paper and confirmed they can follow it?
• ☐ Are all references complete (full conference name, location, year)?
• ☐ Is the paper within the page limit?

References.

• H. Schulzrinne, "Writing Technical Articles," Columbia University. Link
• S. Peyton Jones, "How to Write a Great Research Paper," Microsoft Research. Video
• S. Keshav, "How to Read a Paper," ACM SIGCOMM CCR, July 2007. PDF
• T. Roscoe, "Writing Reviews for Systems Conferences," ETH Zurich. PDF
• W. Strunk Jr. and E.B. White, The Elements of Style, Macmillan, 1979.

This concludes the two-part series. Go back to Part 1 — How to Read a Research Paper.