Hacker News new | comments | show | ask | jobs | submit login
How to Write a Technical Paper [pdf] (semanticscholar.org)
362 points by boricensis 29 days ago | hide | past | web | favorite | 25 comments

Many years ago I picked up a nice idea on how to write abstracts that efficiently convey the idea of a paper. Unfortunately, I don't remember where I read it, so I can't give proper credit.

The idea is that you should write your (first version of the) abstract using only four sentences:

Sentence 1: State the problem

Sentence 2: State the consequences of the problem

Sentence 3: State your solution

Sentence 4: State the consequences of the solution

This makes a very to-the-point abstract. Sometimes these work right away and sometimes they have to be refined through multiple iterations. If they need further iterations, the four-sentence abstract is a great starting point.


Most hamburgers are larger than what can be held with one hand. This makes them hard to eat. We present a new type of hamburger, called the Hand Burger, that is small enough to hold in one hand. Experimental results show that the Hand Burger increases eating speed by up to 150%.

The node_modules directory of Node JS applications often contain multiple copies of the exact same file. This increases the size of the node_modules directory and decreases application startup speed. We have developed a caching scheme for Node JS modules that maintains a single copy of each unique file. This mechanism reduces the size of the node_modules directory by 75% for the most commonly used Node JS applications and increases startup speed by 25% on average.

Horse-drawn carriages have a hard time moving on land because of vegetation. This makes travel slow, or outright impossible. We present a novel concept that we call roads. Our measurements show that roads decrease travel time from years to days to reach the 20 most popular destinations throughout the Roman Empire.

That seem to be excellent advice. It touches on one of my pet peeves when reading articles. Why is it so hard for authors to provide examples? Many times they describe elaborate algorithms but do not describe how they would operate on real data so you have to try and decipher that. If you hadn't added the three examples to illustrate your point, I wouldn't have understood it. But since you added them I understood it perfectly!

I don't think this is limited to articles! I'll often read the documentation for some library or tool and I'll encounter a weird flag or option where I end up wondering: what is this for? When you're not incredibly familiarized with a problem domain it can be hard to figure out the purpose of a lot of things.

By providing real examples you also help the reader build up a mental index in case they ever have to deal with a similar problem.

Too many people write an abstract as if it's a preamble to the paper. If a person has to inspect your paper in-depth to see what results you got, reconsider your abstract.

>> has to inspect your paper in-depth

That depends on the goal of your writing. Technical writer like to think they are above such things, but often the goal is less to convey information and more to keep eyeballs on an article. Sometimes you want to give the customer what they need as efficiently as possible. Other times the goal is to hold their attention as long as possible. You have to adjust you writing to both the audience and the desires of your publication medium.

Oh yeah ok. I'm talking about academic writing. I'm sure some academics' work will always be read, whether because they're well known, do good work, are active in communities etc. However when a large chunk of publications are never even cited, it's not a good idea (imo) to make your papers read like a mystery novel. "I can't wait to get to the end to see how many fractions of a % they increased precision by!"

I'm gonna need a link to this Hand Burger paper, sounds very interesting.

(Jokes aside, this is a great post, thank you for sharing)

I have found the following articles quite useful in this regard:

* Konrad P Kording, Brett Mensh, "Ten simple rules for structuring papers", https://www.biorxiv.org/content/early/2017/05/23/088278

* Ian T Baldwin, "The Baldwin Formula for scientific writing: writing papers and reviews", https://www.ice.mpg.de/ext/fileadmin/extranet/dept_itb/The_B...

* O’Connor Timothy R. and Holmquist Gerald P., “Algorithm for writing a scientific manuscript,”, https://iubmb.onlinelibrary.wiley.com/doi/full/10.1002/bmb.2...

I have been trying to rediscover "10 simple rules" since mid-2016. _thank you_.

I basically try to combine Baldwin's formula and the concise table from Kording's paper when I write.

Semantic Scholar is developed at the Allen Institute for Artificial Intelligence. Just a remark that seems timely tonight.

Also relevant: How to Read a Paper from Keshav Srinivasan from my uni (UWaterloo) [1]

[1] http://blizzard.cs.uwaterloo.ca/keshav/home/Papers/data/07/p...

A few years ago i found a great version of a similar piece that proposed something like a 'sandwich' model for each section, and the work as a whole. A sandwich layer was a hook (something interesting), the meat (what you actually did), and a summary.

I failed to save it and i haven't been able to dig it up again, but I liked the idea. The paper was written in the style it described, as well.

5 paragraph essay? https://en.wikipedia.org/wiki/Five-paragraph_essay

> The five-paragraph essay is a format of essay having five paragraphs: one introductory paragraph, three body paragraphs with support and development, and one concluding paragraph. Because of this structure, it is also known as a hamburger essay, one three one, or a three-tier essay.

The digraph presented in the OP really is a great approach, IMHO:

## Introduction

## Related Work, System Model, Problem Statement

## Your Solution

## Analysis

## Simulation, Experimentation

## Conclusion

... "Elements of the scientific method" https://en.wikipedia.org/wiki/Scientific_method#Elements_of_...

no, it was on arxiv somewhere. It was written as a journal article.

edit: AH! it was linked upthread on bioarxiv.

See also "How to write a great research paper" [0] by the great Simon Peyton Jones.

[0] https://www.microsoft.com/en-us/research/academic-program/wr...

I've always been pointed towards Whitesides[0] for this, but found the advice overly specific for chemistry.

[0]: https://intra.ece.ucr.edu/~rlake/Whitesides_writing_res_pape...

EDIT: reading @adtac's reference, it also recommends "Writing Technical Articles"[1] as an additional reference (the URL in the paper is not copy-pasteable because of a unicode tilde)

[1]: http://www.cs.columbia.edu/~hgs/etc/writing-style.html

Back in the day, as I was beginning my career as a research scientist (https://scholar.google.com/citations?user=5DdrMc8AAAAJ&hl=en), I had a revelation: write the paper first, and the abstract becomes trivial. Since any serious research aims to end not just with an abstract for presentation at a specialty meeting but also a published scientific paper, such an approach is far more efficient and makes one much more productive as a working scientist. Granted, it's far harder to write a paper than an abstract, but once you've bitten the bullet and done so, the ease and pleasure of pulling a sentence or two out of each part of the manuscript's Introduction/Methods/Results/Conclusion, packaging them neatly into a single paragraph, then submitting the product to an upcoming meeting, is sublime. Plus, this completely eliminates the tendency to stop with an abstract because the wall of the complete paper seems too high and formidable. So many of my fellow department members seemed to produce abstracts that never went any further because of the degree of difficulty of producing complete papers. Bonus: tenure committees reward published papers, not abstracts.

I just finished reading about Macaroons and found it to be an exemplary technical paper:


Check [0] as well. It describes very well what questions the introduction should answer.

[0] https://cs.stanford.edu/people/widom/paper-writing.html [2006]

Very good read but I'm starting to wonder about formatting. Is the standard 2 column format still preferred when most reading is done on a screen? I frequently find myself scrolling up and down a single page when I zoom into something.

A paper on how to write good papers should not start the abstract with a complex and wordy sentence. Indeed, the entire first paragraph of the abstract could be put more directly.


Thought I should point that out in a paper that serves as a guideline on how to write papers well :-/

Very meta.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact