优秀程序员的两大要素：懒 + 笨

　当然，对于一个程序员来说，光光具备懒惰这个要素还是不够的。在享受懒惰之前，他必须以最大的热情和最高的效率去研究解放自己的途径，比如：找到最有助于开发的工具，最能体现“一次编写，多次复用”精神的代码架构的设计。只有在这些必要的工作之后，才可能真正享受轻松编程的乐趣。

　　所以“懒”的精髓用一句老话来描述，那就是磨刀不误砍柴功。如果你不想办法磨亮手中的柴刀，就算一天二十四小时都在砍柴，效果也不如拿把锋利的斧头一天只砍一小时。

　　从这个角度来说，Google给员工的20%自由时间是完全发挥了“懒”的能动力。为了更好的享受偷懒的乐趣，员工会更加具有创造力的去高效完成自己的任务。

　　夸张一点来说，懒惰才是人类进步的原动力。

　　笨 这一点似乎比懒更让人不能接受。在解释这里所说的笨的具体含义之前，我们先看看一个聪明人（或者说认为自己足够聪明）会做什么：

　　1) 停止学习新的东西 　　2) 不愿意用批判的眼光去审视自己的工作

　　第1点将使我们很难去接受或者主动的去研究一项新的技术 - 即使新技术能带给他更多工作上的便利。第2点会使我们无法清晰的分析自身工作的问题所在，要对其进行改进或者重构就更加困难。

　　从这两点来考虑，作为一个程序员太自以为是不见得是件好事情。由于对自身的过于自信，往往无法客观的看待自己和自己的工作。相反的，笨一点（确切的说，

　　程序员应该笨一些的更为关键的原因在于，当需要思考问题的最佳解决方案的时候，往往要求我们首先要跳出思维定式。你对系统了解的越多，积累了越多的经验，就越难走出已有的局限，可以尝试的范围就越小。相反的，对于一个什么也不懂的门外汉来说，因为没有任何失败的记忆和潜规则的约束，也就没有什么是“不可能”的，这样的大脑所能迸发出来的在专业人士看起来愚不可及的想法往往正是解决问题所需要的关键点所在。

　　可能很多程序员都会有类似的经历，在面对别人（尤其是其他部门）对于一个bug的描述的时候，必须把自己摆在一个普通用户而不是程序开发者的角度来分析问题，否则的话可能你永远都想象不到这种错误也会发生。越能让自己变得“笨”起来，越能很快的定位到问题所在。我们先看看这么一段关于web开发问题的程序员和客服人员的对话：

　　“从昨天开始我们的用户就看不到我们站点上的Logo了。” 　　“他试过重启浏览器么？” 　　“是的。” 　　“他试过重启电脑么？” 　　“是的。” 　　“他清空过浏览器Cache么？” 　　“是的。” 　　“他的浏览器版本是IE6么？” 　　“是的。” 　　“他确信是真的看不到Logo了么？” 　　“是的。” 　　“他是在电脑显示器屏幕上看我们的站点么？” 　　“什么？” 　　“比如说，

　　从这段对话来说，估计用户实际上是禁止了浏览器显示图片的功能（或者他儿子干的）。不管怎么样，如果你不是用这种傻瓜式的思维方式去寻找答案的话，可能怎么也找不到问题的根源。

很多时候，问题发现者对于问题的描述往往是非常片面的，并且加上了主观推测的成分在里面。如果你不能透过这些主观的描述去发现问题的实际表象，或者说根本就是你自己根据程序员的经验逻辑来判断问题所在的话，十有八九会在歧途上越走越远。

　　对于白痴级的问题，只有用白痴的行为方式才能得到答案。

　　即便同样是程序员，但对于你的程序并不熟悉，也会经常有这样的疑问：“为什么我调用你的代码出错了？”这种问题的答案，很多时候是因为他们的调用方式不对，或者调用了错误的库文件，或者库文件的版本使用不当，或者根本就没有联接到库文件上。当你想让同事帮你检查一下程序中的一个莫名其妙的bug的时候，一般来说希望他对你的系统了解的越少越好，只有这样他才会问一些你自己认为绝对不可能出问题的“笨”问题。

　　所以“笨”的精髓在于你如何去思考问题：不要假设些什么，把自己假设的太完美或者把别人假设的很聪明都会使你忽视一些很浅显的事实。思考的前提必须是完整的事实表象，

　　当然，不思考的一个极端是不分情况都直接去做，另一个极端是完全脱离事实，用思想办事。一个优秀的程序员应该做好权衡。10次决定里面的1次错误决定不是致命的；只做5次正确的决定而另外5次没有任何决定才更糟糕。

　　最后是一个蜈蚣的故事。蜈蚣本来用自己的几百只脚走路走的很快很好，但他从来没有花时间去想过为什么。直到有一天，一只臭虫问他：“你是怎么管理好你的几百只脚的？你不觉得这是件很困难的事情吗？”臭虫问完之后就走了。只剩下蜈蚣坐在地上，不停的思考这个问题，却一直想不出个究竟。从此以后，这只蜈蚣再也没办法好好的走路了。