11. Technical Paper Writing

Chapter 11 of 18 · 15 min

KEY INSIGHT

A technical paper is a communication artifact, not a proof of work. The goal is helping readers understand what you built, why it matters, and how to evaluate it—efficiently. Writing for technical venues requires balancing precision with accessibility. Researchers reviewing your paper have limited time and many submissions to evaluate. Structure your writing so the core contribution is visible within the first two pages. ### Writing Principles for Systems Papers **Lead with the problem, not the solution.** Readers need to understand why anyone should care before investing time in understanding your approach. Start with a concrete pain point that practitioners face. **Quantify claims whenever possible.** "Our system is faster" is weak. "Our system processes queries at 2.3× the throughput of the baseline while maintaining equivalent accuracy" is strong. Specific numbers enable direct comparison. **Name your contributions explicitly.** Use numbered contributions: "We make the following contributions: (1) A novel approach to X that achieves Y... (2) An open-source implementation..." Reviewers look for this section first. ### Handling Uncertainty AI systems involve inherent variability. Write about performance honestly: ```python # Don't write: "Our system achieves top-performing performance." # Write: "Our system achieves 94.2% accuracy on the benchmark (baseline: 91.8%, std dev across 5 runs: ±0.6%). The improvement is statistically significant (p < 0.01, paired t-test)." # Don't write: "Our approach works well for most cases." # Write: "Our approach succeeds on 89% of test cases. The remaining 11% typically involve edge cases involving [specific characteristics]. We discuss limitations in Section 5." ``` ### Common Weaknesses in Systems Papers **Missing baselines** makes claims uninterpretable. Always compare against the current best approach and at least one simple alternative. **Missing ablation studies** makes it unclear which components matter. If you claim component X is essential, show performance without it. **Missing error analysis** wastes the opportunity to learn. Show specific examples where your system fails and analyze why. **Missing reproducibility information** frustrates readers and reviewers. Include model sizes, training durations, hyperparameters, and compute requirements. ### Revision Workflow Technical writing improves through iteration: 1. **First draft**: Get everything down, focus on content over polish 2. **Structure review**: Ensure logical flow, each section has clear purpose 3. **Sentence-level editing**: Cut unnecessary words, clarify ambiguous phrasing 4. **Technical review**: Verify all claims match experiments 5. **External review**: Have someone unfamiliar with the work read it

EXERCISE

Write a one-page summary of your research system covering: the problem addressed, your approach (in one paragraph), key results with specific numbers, and one limitation. Show it to a colleague unfamiliar with your work and ask them to explain back what you built. Note where they struggled or misunderstood.