“写论文一定要快，首先把初稿拿出来，甭管烂到什么程度”[1]。
这句话我实在是深有体会，博主从小学到大学到研究生，写作文水平比较菜，很少体会到才思泉涌，行云流水的感觉，思路很容易停滞，注意力也很容易分散。很多时候写代码也是差不多的状态，不过写代码的阻碍主要是因为记不住很多API。我希望能通过写博客的过程稍微提升一些自己写作(或者写代码)的速度和效率。
写文章/代码
· 快，不管多烂
我们很多时候会期待“完美”的表述，从而纠结在局部的表达上，然而往往会陷入很多细节问题导致写作往前推进的速度大大降低，很多时候的得不偿失，提升一些有可能无关紧要的细节，却付出了不能迅速看清整体的代价。
· 图片，最后再放上去
不要害怕遗忘，要相信自己最后能够看到没有做好的图片。思路如果经常被打断，效率就会低，最重要的是，在没有对整体的清晰认识之前，有时无法判断很多细节是否真有必要花很多时间去做。
· 未知API或步骤，最后再放上去
先整体再局部是写文章或代码的基本思路，并不是说局部不重要，局部和整体是分不开的。然而如果频繁打断写作整体思路，注意力容易分散，也容易因为陷入细节而遗忘一些重要步骤。
· key point list
在文章中或者草稿纸上写出关键点列表的目的是让自己有一个大概的写作计划，如果快速完成文章雏形可以让自己迅速对整体有清晰的认识，那么关键点列表就可以更快让自己对整体有模糊的认识，从而更流畅地构建文章或者代码，主要是减少自己写文章的过程中遗漏一些重要的点。
· Review多次
初稿必然是漏洞百出的，特别是快速构建的初稿（这里的初稿也可以是代码），需要评审代码是否有错误的地方，是否有考虑不周全的地方，增添遗漏的细节，删除冗余细节。由于是自己刚刚写好的初稿，评审起来也会比较容易，评审的过程也可以加深对文章理解。
读文章/代码
· 尽可能搞清楚每个名词/API
这是保证准确的基础，虽然它们确实会耗费很多时间，但是局部和整体是分不开的，很多关键的细节搞不清楚也就搞不清楚整体。我们在细节和快速理解整体之间达到权衡。
· question list
有时候现在暂时想不清楚多的问题，随着时间的推移，就会变得越来越清晰。有时可以不纠结于当前问题，但是应当做一个记录。
2015年12月11日更新：
一鼓作气写代码有一个前提，那就是对特定领域的知识已经有了“足够”的了解。笔者认为编程语言是很重要的，各种细节知识的理解和记忆始终是一个问题，比如说API，并不是说等到真的需要的时候再去记忆。如果总是等到需要的时候临时拼凑出各种代码，造成的结果可能就是程序员对每个知识点可能都只能有个印象，却缺乏判断力。笔者认为，对于高级别的工程师而言，只有记住的知识点尽可能多，构建代码才能够快，出BUG的概率才能尽可能小。
我很赞同厚积薄发，学习一定是一个很长的过程，很多时候需要闻一知十，掌握的知识确实可能是没有用处的，但是有一些是有用处的，这就总比什么都不能掌握要好。在“适当”的时候，就尽可能一鼓作气用不中断的方式编写代码，出错了再一起纠正，就能有更深的印象。
“适当”的时候是什么时候呢？这个得看情况了。
[1]http://blog.sciencenet.cn/blog-202041-400825.html