所以“懒”的精髓用一句老话来描述，那就是磨刀不误砍柴功。如果你不想办法磨亮手中的柴刀，就算一天二十四小时都在砍柴，效果也不如拿把锋利的斧头一天只砍一小时。
从这个角度来说，Google给员工的20%自由时间是完全发挥了“懒”的能动力。为了更好的享受偷懒的乐趣，员工会更加具有创造力的去高效完成自己的任务。
夸张一点来说，懒惰才是人类进步的原动力。
笨 这一点似乎比懒更让人不能接受。在解释这里所说的笨的具体含义之前，我们先看看一个聪明人（或者说认为自己足够聪明）会做什么：
1) 停止学习新的东西
2) 不愿意用批判的眼光去审视自己的工作第1点将使我们很难去接受或者主动的去研究一项新的技术 - 即使新技术能带给他更多工作上的便利。第2点会使我们无法清晰的分析自身工作的问题所在，要对其进行改进或者重构就更加困难。
从这两点来考虑，作为一个程序员太自以为是不见得是件好事情。由于对自身的过于自信，往往无法客观的看待自己和自己的工作。相反的，笨一点（确切的说，谦逊一点）有时候倒有助于开发的顺利进行。举例来说，当程序出现bug的时候，最好尽早承认问题是出在自己编写的代码上面而不是在于编译器（当然除非是字节高低位编码方式之类的问题，这种问题编译器会是错误的根源之一）。如果你太自负的认为自己的程序没有问题而去猜测可能是编译器或者其他的什么外部因素出问题的话，那么十有八九你会在调试过程中走上一长段的弯路。
程序员应该笨一些的更为关键的原因在于，当需要思考问题的最佳解决方案的时候，往往要求我们首先要跳出思维定式。你对系统了解的越多，积累了越多的经验，就越难走出已有的局限，可以尝试的范围就越小。相反的，对于一个什么也不懂的门外汉来说，因为没有任何失败的记忆和潜规则的约束，也就没有什么是“不可能”的，这样的大脑所能迸发出来的在专业人士看起来愚不可及的想法往往正是解决问题所需要的关键点所在。
可能很多程序员都会有类似的经历，在面对别人（尤其是其他部门）对于一个bug的描述的时候，必须把自己摆在一个普通用户而不是程序开发者的角度来分析问题，否则的话可能你永远都想象不到这种错误也会发生。越能让自己变得“笨”起来，越能很快的定位到问题所在。我们先看看这么一段关于web开发问题的程序员和客服人员的对话：
“从昨天开始我们的用户就看不到我们站点上的Logo了。”
“他试过重启浏览器么？” “是的。” “他试过重启电脑么？” “是的。” “他清空过浏览器Cache么？” “是的。” “他的浏览器版本是IE6么？” “是的。” “他确信是真的看不到Logo了么？” “是的。” “他是在电脑显示器屏幕上看我们的站点么？” “什么？” “比如说，它可能是打印出来看不到？” “不。他是在显示器上看的。” “除了站点Logo之外，他是不是其他的图片都看不到？” “什么？哦。我再问问他。”从这段对话来说，估计用户实际上是禁止了浏览器显示图片的功能（或者他儿子干的）。不管怎么样，如果你不是用这种傻瓜式的思维方式去寻找答案的话，可能怎么也找不到问题的根源。
很多时候，问题发现者对于问题的描述往往是非常片面的，并且加上了主观推测的成分在里面。如果你不能透过这些主观的描述去发现问题的实际表象，或者说根本就是你自己根据程序员的经验逻辑来判断问题所在的话，十有八九会在歧途上越走越远。
对于白痴级的问题，只有用白痴的行为方式才能得到答案。
即便同样是程序员，但对于你的程序并不熟悉，也会经常有这样的疑问：“为什么我调用你的代码出错了？”这种问题的答案，很多时候是因为他们的调用方式不对，或者调用了错误的库文件，或者库文件的版本使用不当，或者根本就没有联接到库文件上。当你想让同事帮你检查一下程序中的一个莫名其妙的bug的时候，一般来说希望他对你的系统了解的越少越好，只有这样他才会问一些你自己认为绝对不可能出问题的“笨”问题。
所以“笨”的精髓在于你如何去思考问题：不要假设些什么，把自己假设的太完美或者把别人假设的很聪明都会使你忽视一些很浅显的事实。思考的前提必须是完整的事实表象，思考的过程必须是抛弃成见的问题跟踪。在发现事实之前作太多的主观思考和臆断，倒不如把自己当作白痴一样来行动更好。
当然，不思考的一个极端是不分情况都直接去做，另一个极端是完全脱离事实，用思想办事。一个优秀的程序员应该做好权衡。10次决定里面的1次错误决定不是致命的；只做5次正确的决定而另外5次没有任何决定才更糟糕。
最后是一个蜈蚣的故事。蜈蚣本来用自己的几百只脚走路走的很快很好，但他从来没有花时间去想过为什么。直到有一天，一只臭虫问他：“你是怎么管理好你的几百只脚的？你不觉得这是件很困难的事情吗？”臭虫问完之后就走了。只剩下蜈蚣坐在地上，不停的思考这个问题，却一直想不出个究竟。从此以后，这只蜈蚣再也没办法好好的走路了。
原文地址：