Hacker News new | comments | show | ask | jobs | submit login

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.




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)




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

Search: