4 ms·

Just to make sure I got it - you advisor is asking you to repeat important stuff in different section even it feels redundant?

scott_s 5y ago
Not exactly. My advisor, an experienced researcher who already knew what I was writing about, missed an important thing that I said. That meant I failed to communicate something to a very sympathetic reader. That's a big miss. From that, I learned that if something is important, find multiple ways to say it in multiple places. I only really know academic computer science papers, and even then, papers that tend to have a systems component. Your most important claims, conclusions and results should be stated in your abstract and introduction. Some things are fundamental enough to repeat in your design/analysis and results, and some others will only end up in one of those sections. Don't use the same literal sentence, over-and-over, but reinforce important sentiments. If restating something all over your paper doesn't feel right, then it may not be as important as you think it is. Academic papers are not novels, and they certainly are not mysteries. Don't hold out on a reveal until the end: say the most important stuff upfront. People often will not read your paper end-to-end, and usually only some of the sections. It's not possible to make your sections truly self-contained, but it's worth repeating fundamental things. If your experimental results are confirming your theoretical analysis, restate that theoretical result in your experimental results as context. If your experimental results demonstrate that a particular design decision you made in your system truly does provide better performance, restate that design decision.
- iamcreasy 5y ago
  Interesting. Thanks for the explanation. Do you have any paper that demonstrates this approach?
  - scott_s 5y ago
    This is the approach I take when I write, so this is how I try to write. I hope it is reflected in my first-author papers. Three papers from the past several years: https://www.scott-a-s.com/files/middleware2016_loadbalancing.pdf https://www.scott-a-s.com/files/middleware2016_loadbalancing..., https://www.scott-a-s.com/files/pldi2017_lf_elastic_scheduling.pdf https://www.scott-a-s.com/files/pldi2017_lf_elastic_scheduli..., https://arxiv.org/pdf/2006.00064.pdf https://arxiv.org/pdf/2006.00064.pdf.

scott_s 5y ago

Not exactly. My advisor, an experienced researcher who already knew what I was writing about, missed an important thing that I said. That meant I failed to communicate something to a very sympathetic reader. That's a big miss. From that, I learned that if something is important, find multiple ways to say it in multiple places. I only really know academic computer science papers, and even then, papers that tend to have a systems component. Your most important claims, conclusions and results should be stated in your abstract and introduction. Some things are fundamental enough to repeat in your design/analysis and results, and some others will only end up in one of those sections. Don't use the same literal sentence, over-and-over, but reinforce important sentiments. If restating something all over your paper doesn't feel right, then it may not be as important as you think it is. Academic papers are not novels, and they certainly are not mysteries. Don't hold out on a reveal until the end: say the most important stuff upfront. People often will not read your paper end-to-end, and usually only some of the sections. It's not possible to make your sections truly self-contained, but it's worth repeating fundamental things. If your experimental results are confirming your theoretical analysis, restate that theoretical result in your experimental results as context. If your experimental results demonstrate that a particular design decision you made in your system truly does provide better performance, restate that design decision.

iamcreasy 5y ago
Interesting. Thanks for the explanation. Do you have any paper that demonstrates this approach?
- scott_s 5y ago
  This is the approach I take when I write, so this is how I try to write. I hope it is reflected in my first-author papers. Three papers from the past several years: https://www.scott-a-s.com/files/middleware2016_loadbalancing.pdf https://www.scott-a-s.com/files/middleware2016_loadbalancing..., https://www.scott-a-s.com/files/pldi2017_lf_elastic_scheduling.pdf https://www.scott-a-s.com/files/pldi2017_lf_elastic_scheduli..., https://arxiv.org/pdf/2006.00064.pdf https://arxiv.org/pdf/2006.00064.pdf.