选择

有些人为了毅然辞职 说走就走 这些特有诱惑力的词儿弄得睡不着觉 但终究迈不开脚步 困扰我们的 并不是选择什么 而是选择之后你会失去什么 这种不舍 就叫权衡利弊

人舍了 于是活的潇洒 人会有无数次选择 没有绝对的对错 只有相对的得失和喜怒哀乐

拼top文章数量的世界

我现在发现，虽然想做比较有impact的东西，但是很多时候没法完成，主要还是归因为
1. 时间不等人 - 这个拼top文章数量的世界，把一个tool做完整，做上一年，你就一年一份paper，不实际。那另一种方法是，阶段行的把成果分成好几份，你也要每一份document 成一份paper, 加上evaluation，加上突破点，这个很耗时。如果是一个团队弄一个system, 可能更容易些 - 但是团队里的每个人有可能会急功近利，没法把system弄得stable。两种体制我看的比较好的，是有人专门做开发，有人专门搞paper;或者是导师会检测system的质量，所以属下的人必须好好地弄。后者会导致属下的人的文章压力，原因是system的质量增加，往往是由于开发时间较长，少些paper的原因。
2. 太专业- 做的东西太专业，想要找别人一起弄，也只有自己领域的人，人数也不多；
3. 突破点费脑费力 - 很多时候fundamentally useful 的东西，idea 简单，别人有做的，但是做的不够好，往往需要一个突破点才能发paper,但是有时这个突破点是最没用最花时间的去思考去做的；
4. 有用不等于能发文章 - 很多有用的tool,学术界都不能发，原因是只有engineering effor。需要突破点 - 和前人做的用了不一样的方法，这个方法（局部性）胜过前人的方法 - 这又回到问题3。
5. 修改paper - 有时paper 如果不中，针对comments 需要从新修改paper要花上一个月的时间。journal 的话更是如此，一次又一次的review，几个月就没了。虽然重要，但是这个太费时间了，有些reviewer的一句话，要花上很多时间来实践，虽然只是为了迎合reviewer，心理知道实际上并不会真正improve文章的质量。

这些是现实原因。当然也有个人原因，下面是一些经验：

1. Minimal Viable Product - 之前碰到好几次，问题都在development完才发现。其实research prototype适合小，证明可行就行，不需要做的太实际。等到证明可行后，才做大型开发。这个是比较好的。

不过这个倒不是很大的问题，出了问题后，再学习下就行, 追求文章数量，不错过任何deadline才是导致impact不高的原因。

当然写paper还是挺好的，因为paper 里其实document这各种想法，让其他人能够有所启发，document过程中自己也会有更多的省思。就是这个追求文章数量的系统不好，导致各种灌水，做无意义的消耗。