关于这篇文章(http://kb.cnblogs.com/page/106952/)，本人很赞同。原打算直接转载过来，警示自己。但觉得，还可以加点什么。

      2个小时的效率或许高过8个小时，这个遵循二八原则。如何利用二八原则却是难点。在原文中提倡在疲劳的时候，先通过各种方式恢复精力。待精力充足后继续工作。但这种方式只能阻止程序员低效工作，这是在进入危险状态之后的理智选择。如果能够避免走入危险区那样会更有意义.

      笔者认为程序员走入危险区是有原因的。例如让一个程序员一天八小时都在做九九乘法表，相信他整个工作日都是高效的。但实际工作不可能都是如此简单的。 例如:过程总比想象中的要复杂，结果难以预料，常常遇到这样那样的问题。因此程序员不得不把精力放在如何解决问题之上。开发的过程成了解决问题的过程, 项目的进展等同于解决问题的速度。如果开发过程进入类似的状态，程序员便成了骡子，项目被陷阱的泥潭中。骡子的力气会被很快耗尽. 接下来只能停止前进（编程）。 

      前文提到程序员如果都在做九九乘法表，进入危险区的风险会降低许多。因此如何让工作都像做九九乘法表才是关键。举个例子 , 如何计算13954043 * 3954805 的结果。 在不用计算器的情况下，你会用到九九乘法表，加减法表。求解的过程相当轻松。如果把工作看作是解决这道算术题，你要做的便是了解那些口决。在掌握这些之后，工作自然变得高效。而这整个过程得益于成功的分解了复杂的问题。

      因此笔者倡导，多思考，少编码。 思考的过程便是分解复杂问题的过程，便是降低风险的过程，便是高效的过程. 编码只是思考的结果.如果不知道如何思考，可以对自己或者别人说:"我要做什么？我应该怎样做?"