我现在发现，虽然想做比较有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过程中自己也会有更多的省思。就是这个追求文章数量的系统不好，导致各种灌水，做无意义的消耗。
