How to Write a Technical Paper [pdf]

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.

Examples:

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.

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...

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...

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.

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.

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

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

https://storage.googleapis.com/pub-tools-public-publication-...

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.

s/formated/formatted

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

Very meta.