作者在Twitter上发的一条短讯：
“在怨天尤人之前，我们应该先自我反省、努力把自身的问题解决了。”
12:22 PM –2012-5-30
你应该知道那种感觉。我们所有人都曾碰到过这样的事情：你已经盯着代码看了无数遍，但还是没有发现任何问题。然而，有个故障或者错误始终挥之不去。 于是你开始怀疑，一定是你开发程序所用的那台机器出了问题，也可能是操作系统的问题，或者是你使用的工具和库出了问题。肯定是它们的原因！
然而，无论你多么绝望，你都不要往那条路上走。沿着那条路下去就是“伏都”计算和靠运气编程。说白了，就是愚蠢。
译者注：伏都教（voodoo），又译“巫毒教”，源于非洲西部，是糅合祖先崇拜、万物有灵论、通灵术的原始宗教。
老是要处理一些困难的、捉摸不透的问题，这是一件令人绝望的事情，但是不要让绝望领着你误入歧途。作为一名谦逊的程序员，最基本的要求就是要有意识：你写的代码在任何时候出了问题，那一定都是你的错。这个观点在《程序员修炼之道：从小工到专家》一书中被巧妙地归结为“select没有问题”：
译者注：select是用于I/O多路转接的一个系统调用函数。
在大多数项目中，你所调试的代码里常常混杂着这些东西：你和项目小组中的其他成员开发的应用代码、第三方的产品（数据库、链接器、图形库、特殊的通信系统或者算法等）以及平台环境（操作系统、系统库和编译器）。
操作系统、编译器或者第三方产品出问题的可能性是有的——但是，这绝对不应该是你碰到问题后的***反应。错误出现在正在开发的应用代码中的可能性要 大得多的多。通常情况下，假定应用程序错误地调用了库函数要比假定库本身有问题更有效益。即便问题出在第三方，你还是必须彻底排除自身代码的问题，然后再 提交错误报告。
我们曾经做过一个项目，项目中的一位高级工程师确信Solaris上的select系统调用出了问题。无数次的劝说和逻辑分析都不能改变他的主意 （事实上，所有其他的网络应用程序在同样的机器上都能正常工作，但他仍然固执己见）。他花了好几个星期来做变通方案，但是因为一些诡异的原因，这些方案似 乎都行不通。他最终不得不坐下来，仔细地阅读关于select的文档。然后，他找到了真正的问题，并且在几分钟内就把问题解决了。如今，一旦我们当中有人 开始为了一个很可能是我们自己造成的错误而责怪系统时，我们会用“select有问题”这个短语作为善意的提醒。
译者注：Solaris是一个类似于Unix的操作系统，最初由Sun Microsystems公司开发。早期的Solaris主要针对服务器以及企业应用领域，在Sun的高性能工作站上有广泛的应用。
代码产权的另一面是代码责任。无论你的软件出现什么样的问题——甚至最开始出错的地方根本就不是你的代码——你也应该总是假定问题出在你的代码里， 并且根据这个假设采取行动。如果你想让世界人民接受你的软件，那你就要为它的故障承担全责。尽管——从严格意义上来说——你并不是非这么做不可。只有这 样，你才能赢得尊敬和信用。如果你不断地把问题推卸到其他人、其他公司或者其他的源头上，你是无论如何也得不到尊敬和信用的。
从统计学的角度来说，软件中的故障或者错误一般都是人为的，例外的可能性凤毛麟角。我想你已经明白了这一点。在《代码大全》（《CodeComplete》）一书中，Steve McConnell引用了两个研究来证明这个观点：
在1973年和1984年进行的两次研究发现，在所有报告的错误中，大约有95%是由程序员造成的，2%是由系统软件（编译器和操作系统）引起 的，2%是由其他软件引起的，1%是由硬件造成的。跟1970年代和1980年代相比，现在的系统软件和开发工具的使用人群要大得多，所以我猜想，现如今 应该有更高比例的错误是由程序员的过失造成的。
不管你的软件出了什么问题，请你负起责任来吧！从你的代码开始，深入进去，逐步向外调查，直到你找到确凿的证据证明问题之所在。如果问题出在你无法 控制的代码上，你不但学会了必要的故障排除和诊断技巧，同时还获得了用来支持你指控别人的审计证据。当然，和你耸耸肩膀简单地把问题归责于操作系统、工具 或者应用框架相比，这样花费的工夫要多得多——但是这也会逐步形成信任和尊敬的感觉，而这种感觉是你通过指责他人和逃避不可能得到的。
如果你真的渴望做一名谦逊的程序员，在你碰到问题的时候，你就应该很淡定地说：“嘿，这是我的错——让我把它弄个水落石出。”
原文链接：http://www.codinghorror.com/blog/2008/03/the-first-rule-of-programming-its-always-your-fault.html
译文链接：http://blog.csdn.net/happydeer/article/details/18815345
