How to Write a Technical Paper Engineers Actually Read
A technical paper competes for the scarcest resource a specialist has: attention. Reviewers skim dozens of submissions, engineers triage papers between meetings, and researchers decide within ninety seconds whether yours is worth the next thirty minutes. Strong technical writing is what converts that skim into a read, and the read into a citation. The craft is not decoration on top of good work; it is the interface through which the work becomes usable to anyone but you.
This guide treats paper-writing as an engineering problem with known constraints and repeatable patterns. We will cover what distinguishes a technical paper from an essay, the IMRaD skeleton that most venues expect, how to write an abstract that survives triage, and how to present data, code, and citations so a stranger can trust and reproduce your claims. If you are newer to the discipline, start with our beginner's guide to technical writing for the underlying fundamentals.
What Separates a Technical Paper From an Essay
An essay persuades through voice and argument; a technical paper persuades through evidence and structure. The reader is not looking to be charmed, they are looking to answer three questions quickly: what problem did you solve, how do I know your solution works, and can I build on it. Every sentence should move one of those questions forward. Anything that does not is padding, and experienced reviewers spot padding instantly.
The second difference is falsifiability. An essay can rest on interpretation, but a technical claim must be stated precisely enough that someone could prove it wrong. "Our method is faster" is an essay sentence; "our method reduces median query latency by 38% on the TPC-H benchmark at scale factor 100" is a technical one. Precision is not pedantry here, it is the entire point, because a claim a reader cannot test is a claim they cannot cite. For a broader look at how precision plays out across formats, see our piece on real-world technical writing examples.
The IMRaD Structure and When to Break It
Most empirical papers follow IMRaD: Introduction, Methods, Results, and Discussion, usually bracketed by an abstract and a conclusion. The structure works because it mirrors how a reader reasons: why should I care, what exactly did you do, what happened, and what does it mean. Introduction establishes the gap and states your contribution in plain terms, ideally as a numbered list so a reviewer can check each claim against your results. Methods must be detailed enough to reproduce; Results report what you measured without interpreting it; Discussion is where interpretation, limitations, and future work belong.
Knowing when to break IMRaD matters as much as following it. Systems papers, position papers, and experience reports often merge Results and Discussion, or lead with an architecture section instead of formal methods. Venues like the ones catalogued by Write the Docs and most conference calls-for-papers publish explicit expectations, so read three recently accepted papers from your target venue before you draft. Match their rhythm, then earn the right to deviate.
Writing an Abstract That Earns the Read
The abstract is the most-read and least-carefully-written part of most papers. It is a self-contained miniature of the whole work, typically 150 to 250 words, and it is what appears in search results, indexes, and recommendation feeds. A reliable template is five moves: context (one sentence), problem (one sentence), approach (one to two sentences), result (one to two sentences with a number), and significance (one sentence). If a reader stops after the abstract, they should still know your single most important finding and why it matters.
Write the abstract last, after the paper exists, then cut it by a third. Remove citations, undefined acronyms, and hedging language like "we attempt to explore." State what you did in the past tense and what your result is in the present. The abstract is a promise; the body is the proof. If they disagree, reviewers notice, and trust evaporates.
Presenting Data, Figures, and Code
Figures carry more evidentiary weight than prose because they are harder to fake and faster to absorb. Every figure needs a caption that stands alone, axes with units, and a clear reason to exist. A common failure is the "data dump" table with twenty columns; instead, show the comparison that supports your claim and move the rest to an appendix or supplementary repository. Prefer plots over tables when you want the reader to see a trend, and tables when exact values matter.
Code and configuration deserve the same discipline. Inline only the snippet that illustrates a point, keep it under roughly fifteen lines, and use consistent formatting. For anything larger, link to a versioned repository with a commit hash so the artifact you describe is the artifact readers get. Treating your paper's assets like software, tracked and versioned, is the same docs-as-code mindset we cover in our technical writing best practices guide.
Citations, Reproducibility, and Peer Review
Citations do two jobs: they credit prior work and they position yours. Cite the foundational paper for a concept, the most recent competitive baseline, and any dataset or tool you rely on. Under-citing reads as ignorance of the field; over-citing to pad a bibliography reads as insecurity. Use a reference manager such as Zotero or BibTeX so formatting is consistent and mechanical, freeing your attention for substance.
Reproducibility is now a first-class review criterion at most serious venues. State your hardware, software versions, hyperparameters, and random seeds. Provide a repository, a container image, or at minimum a requirements file. Reviewers increasingly reward artifacts they can actually run, and many conferences award artifact badges that meaningfully raise a paper's long-term impact. Anticipate the reviewer who wants to break your claim, and hand them the evidence before they ask.
Revision: From Draft to Submission
A first draft is a thinking tool, not a submission. Revision happens in passes, each with one goal: structure first (does every section earn its place), then argument (does each claim have evidence), then sentence-level clarity, then formatting and references. Attempting all four at once is why so many drafts stall. Read the paper aloud to catch tangled sentences, and hand it to a colleague outside your subfield to catch unexamined jargon.
Build a submission checklist and run it every time: abstract matches results, every figure is referenced in text, every claim in the introduction is supported later, references are complete, and the paper conforms to the venue's format. Darlo Technical Writing's Technical Paper Writing course walks through this full pipeline with annotated real submissions and reviewer responses, and our downloadable submission-readiness checklist turns this final pass into a repeatable ritual. Explore both at /courses. For evolving reproducibility norms, the ACM artifact review guidelines are worth bookmarking.
Technical Paper Submission-Readiness Checklist
A one-page pre-submission checklist covering abstract-to-results consistency, figure references, reproducibility artifacts, citation completeness, and venue formatting so nothing slips before you hit submit.
How long should a technical paper be?
Length is set by your venue, not by you. Conference papers typically run 8 to 12 pages in a two-column format, journal papers 20 to 40 pages, and workshop or short papers 4 to 6. Write to the contribution, then trim to the limit; padding to reach a maximum weakens the paper more than falling slightly short.
Should I write the introduction or the methods first?
Draft methods and results first, because they are factual and you already know them. Write the introduction and abstract last, once you know exactly what you are claiming. This prevents the common mismatch where the introduction promises something the results never deliver.
How do I handle reviewer feedback I disagree with?
Treat every comment as evidence that a reader was confused, even if the reviewer's proposed fix is wrong. Often the real issue is unclear writing rather than flawed work. Respond point by point in a revision letter, make the changes you can defend, and explain politely and with evidence where you have chosen not to.