读者须知

本文虽然打了“经验分享”的 Tag，但更像是个人体会的记录。读者了解了在常见投稿困难下，我的取舍带来的结果，可能会有一定感触。

前言

本文的定位是”投稿“分享，所以将关注以下在投稿特有的问题：如何在有限时间保证一次完整的投稿。

我也有自己没有做好的事情，例如：我给出的draft基本上只能涵盖必要信息，而没能组织成论文该有的水准；最后关头往往只能保证最重要的 evaluation，但距离尽善尽美的实现还有距离等等。这里就不展开了。

最后我会记录一下从 5 个 Reviews 中学到的东西。

如何在有限时间保证一次完整的投稿

Writing workflow

虽然一直说成熟的 researcher 会提前开始写作，甚至利用写作 polish 工作本身 How to Write a Great Research Paper (bilibili)，但初学者如我更可能面对的是最后几周赶稿。

workflow 涉及了合作者之间修改的顺序、某些内容需要讨论的时候要迅速 call for meeting 并达成共识、某段落以及某合作者须在什么时间之前完成等等。

为了能更好的写作，还需要尽早明确各种写法，包括：给 idea 和各个常用的部分选择称呼和简写、每个人的修改如何用各自的颜色或者签名标记、互相审阅完成如何标记等等。

安排实验时间

  • 在安排实验的时候，要预留容错时间，我一般自认为 1h 完成的工作，会安排 1.5h，这样往往刚刚好，在投稿前可以减轻焦虑心理
  • 自己构思出最高效的实验参数（最少的实验、最多面的信息量），立刻与合作者/导师商量，达成一致再操作
  • 如果可以通过修改代码使得跑实验的流程更高效，这种前序工作是值得的（例如把测试脚本写得更好，比手动一个一个实验慢慢跑，要省心很多）。

Reviews 收获

需要多方面做实验验证

  • 重要参量的敏感度分析（避免 ad-hoc）
  • synthetic / old traces 之外最好有强有力的 killer traces
    • 比如 workload 只有新旧之分的时候，最开始就应该选择新的
    • workload 的来源不同的时候，要按需选择。比如，caching 有 in-memory traces, block io traces 等等
  • 仅仅口头说明好处不够有说服力，应该精心选择实现&实验，在有限的篇幅内展示效果
  • 不要害怕做出不好的结果，这可能是好结果的前提

Reviews 的不可替代性

我曾经有一个观点是：“至少我自己确认准备好了，才能去投稿；而如果我不确定项目好不好，那可能这不是一次成熟的投稿。”

但这次投稿后，我发现很多视角（还有背景工作）可能是我自己不会想到的，再给我几个月可能也不会，反而我可能会滑向“闭门造车”。所以，在追求自己的完美目标和适时投稿之间，我相信存在一个极大值点。