当然，你仍旧会花很多时间在实现你的想法上，也就是说，你还会编写很多代码。因为这并不是学术上独有的工作，所以我不会在此详谈，但还是有几点我想提一下。

公开你的代码。虽然你可能会感到惊讶，但是你确实可以不发表论文也不公开代码。同时，你有很多动机将自己的代码藏起来：写代码会花费许多时间（研究项目的代码看起来像是意大利面，因为它的迭代非常快，所以你需要经常进行清理）；同时，光是想到别人可能会对你的代码评头论足，就已经足够吓人了，维护代码以及回答别人（永远会有）的问题是非常痛苦的，你甚至会担心别人可能会发现代码中的错误，从而减弱了研究的可信度。然而，这正是你应该发表代码的原因之一：为了避免尴尬的情况发生，你会不断采用更好的编码习惯（而这最终会帮你节省时间！）；你会被迫使学习更好的工程实践；你会被迫使对自己的代码更加严格要求（例如，编写单元测试以最小化错误出现的可能性），这一切都将让你的研究受到更多关注（并由此带来更多的引用次数），并且很自然地，你的研究也将对之后的研究更加有用。当你真的准备发表代码的时候，我建议你好好利用 docker containers（https://www.docker.com/）；它会减少人们发邮件来问你要附件（和它们的各种版本），从而减轻你的烦恼。

为将来的你着想。为了你自己的便捷，务必将自己的所有代码妥善记录，我保证几个月之后你会回来看你的代码（例如，为即将发表的论文再做几个实验），那时，你会一头雾水。我已经养成了为（自己的）每一个版本编写非常详尽的 readme.txt 文件的习惯，以便未来的自己能够明白代码的原理和使用方法等等。

做演讲

现在，你的论文成功发表了！你需要就这篇论文向许多观众进行几分钟的演讲——它应该是什么样的？

演讲的目的。首先，一个常有的误解是，演讲的目的是向听众介绍你在论文中做了什么。这是错误的，这一目的最多也只能排在第二或第三位。你的演讲应应该：1）使听众对你研究的问题产生浓厚兴趣（如果大家对问题本身没兴趣，他们也不会在乎你的解决方法的！）2）教些东西给听众（理想的情况是在让大家体验你的思考 / 解决方案的时候，不要害怕在别人的相关工作上花时间）以及 3）有趣（否则很多人会开始刷 Facebook）。理想情况下，在演讲结束之后。你的听众中应该有人在想这几件事情：「哇，我要换个研究方向」，「我一定要看看这篇论文」，以及「作者本人对整个领域的理解非常出众。」

一些可以做的事情：有些特征会让演讲更上一层楼，例如，要：有许多图片。人们喜欢图片。录像和动画应该更少一些，因为它们容易让人分心。要让演讲内容高度可执行——将一些人们在听到之后可以马上动手去做的东西。要：如果可能的话给一个 demo，它会让你的演讲更容易被记住。要发展一个你的研究涉及到更广泛的领域。要讲成一个故事（人们喜欢故事）。要引用，引用，引用——很多应用！加入引用不会占用你的幻灯片多大的空间，而你的同行们会因此感到高兴，并且认为你是一个十分谦虚的人，因为你意识到自己的贡献是建立在他人的许多成果之上的。你甚至可以引用在同一个会议发表的文章，并为之做简短的推荐。要进行练习！先自己练习，然后向同事 / 朋友展示。这常常会帮你发现许多叙述和流程中的重要问题。

不要加很多文字。不要让文字挤满你的幻灯片。你应该少用甚至不用重点标识——演讲者们有时会使用重点标识来提醒自己要讲些什么，但是幻灯片不是给你自己看的，而是给观众看的。重点标识应该出现在你的演讲笔记中。于此类似地，尽可能地避免使用复杂的图表——你的听众是有固定带宽的，并且我保证那些在你看来十分熟悉且「简单」的图表，对于那些第一次看到的人来说，就不是这么好理解了。

注意，结果表：不要使用信息十分密集的表格来展示你的方法有多么优秀。既然你已经写了篇论文出来了，我相信你的结果至少是可靠的。我一致认为这一部分是非常无聊和无用的，除非数字能够表明一些（与证明你的论文无关的）十分有趣的东西，或者数字所表明的差距确实非常巨大。如果你真的要展示结果或图表，请循序渐进地将它们展示出来，而不是把所有东西扔到页面上，然后在一页幻灯片上花上三分钟。