Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
Simon Peyton Jones: How to write a great research paper (microsoft.com)
52 points by mace on Sept 11, 2009 | hide | past | favorite | 13 comments


An okay discussion, but it falls entirely flat on its face in a very important place: related work.

What is the point of related work? Notionally twofold: to argue that there are people that care about what you're doing (because they're asking similar questions), and to argue that people haven't done the work yet.

But in reality there's a third reason: to help tell the story.

Writing a paper is telling a story. The story of an interesting problem, and how you went about solving it.

Simon thinks that related work should go at the end of the paper. Reading his slides makes it clear to me that really the issue is that he doesn't know what to do with related work; it seems to be an anachronism to him that he has to put somewhere so it might as well stick it at the end where no one will notice. He also seems to have missed that related work helps answer the "It's an interesting problem" and "It's an unsolved problem" sections of his story -- both of which he's got thrown up in the "Conveying the idea" slide. This tells me that he's likely not written a good related work section.

Related work is motivation. It's part of the story. It should be relatively up front. The story should go like this:

- Introduction: Here is a problem

- Related Work: Other people have gone after this problem and have failed to figure it out, or danced around it. People care about it.

- Approach: Here is how I solve the problem

- Details: Here is what I did

- Discussion: Here is what the results were

- Conclusions and Further Work: Here's what I'm going to do next.


Related work is motivation. It's part of the story.

It depends on the paper -- in many cases, I think that a paper can be adequately motivated in the introduction, without explicitly enumerating all the potential related work. Given that most people stop reading quite early into a paper, I think there's a lot to be said for getting to the "Good Stuff" quickly -- and the related work is rarely the "Good Stuff".

Perhaps related work is more important for incremental, technical results: "problem A is important, B and C tried to solve it but their solutions were imperfect for reasons D and E, and therefore we propose F." But when you're, say, describing a new piece of systems software, the related work is less likely to be an essential part of the motivation for the paper.


John Cochrane (economist) has some excellent tips on writing for PhD students:

http://faculty.chicagobooth.edu/john.cochrane/research/Paper...


They should require every first year graduate student to read this or something similar. The ratio of well to poorly written papers is far too low.



How is this different from clicking on the PDF link above (and not the auto-inserted, value-free scribd link) ??


It is more convenient; there is no need to download the PDF and it can be viewed directly in the browser.


I'm using Konqueror on KDE on SuSE and it comes up fine in the browser directly. Your link appears to me to add an extra layer. Maybe I'm missing something.

Not important, just confused. Situation normal ...


Congratulations, you're happily using one of the few browsers with flawless built-in PDF support (the other being Safari on OS X).

The vast majority are not nearly as fortunate.


Hmm. Also works fine on Firefox 1.5.3 on KDE on SuSE. I guess I'm just lucky to have two of the few.

Oh, no, hang on, it works in IE7 as well. Hmm. I have three of the few.

What are you using?


Same behaviour for firefox on OS X: http://code.google.com/p/firefox-mac-pdf/


I don't like my PDFs in the browser. Just downloading the PDF is fine for me, it will display in evince.


One of those rare sets of slides that are both readable and highly informative as well as pleasing to the eye.




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

Search: