Is the suggestion of putting "related work" at the end non-standard? As an occasional reader of CS papers I generally remember this part appearing after the introduction, and feeling quite sapped once I'd got through it and the references.
I've always seen "related work" appearing immediately following the introduction. The layout I see most often is:
* Abstract: This is why you should read this paper.
* Introduction: What the problem is that we're trying to solve and a claim to having solved it better.
* Related work: How other people have solved the same problem (and why we don't like their solutions).
* One or more sections go here here describing how we solved the problem.
* Experimental results: Look at the awesome results our solution provides. (Not always applicable depending on the paper.)
* Future work: Here's some ideas we haven't worked out fully -- they may appear in future papers but we're putting them here so we can claim to have published them first if someone else writes a paper about them before we do.
* Conclusions: Everything in the Introduction, except written in the past tense.
* References: Everything your potential referees have written which might conceivably be relevant.
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.
I have seen both ways (in computer science/systems). I buy the reasons SPJ says in the talk, but if the problem you are working on is too crowded that the first thing that comes to a reader's mind is -- "How is this different from the N other proposals I've read in the past?" -- the related work helps set the context.
It's a little non-standard, and some would argue that it deviates from the philosophy of "standing on the shoulders of giants", but I think it's acceptable.
Note that you should still "cite relevant work in passing".
It's probably non-standard, but I totally buy SPJ's suggestion. Often when I read the related work section at the beginning I'm confused: I don't understand the paper I'm reading yet, let alone any other related work.
Comments
Is the suggestion of putting "related work" at the end non-standard? As an occasional reader of CS papers I generally remember this part appearing after the introduction, and feeling quite sapped once I'd got through it and the references.
I've always seen "related work" appearing immediately following the introduction. The layout I see most often is:
* Abstract: This is why you should read this paper.
* Introduction: What the problem is that we're trying to solve and a claim to having solved it better.
* Related work: How other people have solved the same problem (and why we don't like their solutions).
* One or more sections go here here describing how we solved the problem.
* Experimental results: Look at the awesome results our solution provides. (Not always applicable depending on the paper.)
* Future work: Here's some ideas we haven't worked out fully -- they may appear in future papers but we're putting them here so we can claim to have published them first if someone else writes a paper about them before we do.
* Conclusions: Everything in the Introduction, except written in the past tense.
* References: Everything your potential referees have written which might conceivably be relevant.
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.
I have seen both ways (in computer science/systems). I buy the reasons SPJ says in the talk, but if the problem you are working on is too crowded that the first thing that comes to a reader's mind is -- "How is this different from the N other proposals I've read in the past?" -- the related work helps set the context.
It's a little non-standard, and some would argue that it deviates from the philosophy of "standing on the shoulders of giants", but I think it's acceptable.
Note that you should still "cite relevant work in passing".
It's probably non-standard, but I totally buy SPJ's suggestion. Often when I read the related work section at the beginning I'm confused: I don't understand the paper I'm reading yet, let alone any other related work.
He specifically explains why he suggests this different structure on page 24.
Basically, if you put a huge discussion of related work at the beginning you'll either make your reader feel tired or stupid or both.