Skip to content

Comment on How to write a great research paper [pdf]parent

Comments

In PL and systems, related work almost always comes at the end. HCI is the only field I know where related work is front loaded. Pandering to the PC in related work is also bad form.

That said, a quick glance over the PC/ERC to ensure you cite-and-compare is a good idea. It's always easier to answer questions in your paper than the rebuttal. Or next year's submission.

That is an incredibly biased way of handling related work. Doing it right means being blind wrt the PC, if the conference isn't run by dysfunctional egoists and you cover related work in good faith, the reviewer won't dock too many points for missing something and they'll fill in your missing information in the review.

In AI, related work is usually at the beginning, but sometimes at the end. A common form is to set up the problem in the intro (section 1), then use the related-work section (section 2) to survey existing solutions to the problem and explain 1) whether you build on any of them, and 2) what's still left to do. It's sort of like an extended motivation: the intro motivates the problem, and the related-work section motivates your choice of jumping-off point.

We have to mention previous work in the intro and body of the paper to establish context, but the related work at the end is more of comprehensive since the paper has already been fully stated. If your paper is low on context, the reviewer might flip to related work after the intro to fill in the gaps, but you are in negative points territory at that point.

Interesting. Most of the papers I read are mathematics.

AboutSource Built by g1lg1l

Hackerly is an independent reader for Hacker News, built on the public HN API. Not affiliated with Y Combinator.