碰到问题的时候，如果你真的渴望做一名谦逊的顺序员。就应该很淡定地，但还是没有发现任何问题然而应该知道那种感觉。所有人都曾碰到过这样的事情：已经盯着代码看了无数遍。有个故障或者错误始终挥之不去。于是开始怀疑，一定是开发顺序所用的那台机器出了问题，也可能是操作系统的问题，或者是使用的工具和库出了问题。

假定应用顺序错误地调用了库函数要比假定库自身有问题更有效益。即便问题出在第三方，操作系统、编译器或者第三方产品出问题的可能性是有的但是这绝对不应该是碰到问题后的第一反应。错误呈现在正在开发的应用代码中的可能性要 大得多的多。通常情况下。还是必需完全排除自身代码的问题，然后再 提交错误演讲。项目中的一位高级工程师确信Solari上的select系统调用出了问题。无数次的劝说和逻辑分析都不能改变他主意 事实上，曾经做过一个项目。所有其他网络应用顺序在同样的机器上都能正常工作，但他仍然固执己见）花了好几个星期来做变通方案，但是因为一些诡异的原因，这些方案似 乎都行不通。最终不得不坐下来，仔细地阅读关于select文档。然后，找到真正的问题，并且在几分钟内就把问题解决了如今，一旦我当中有人 开始为了一个很可能是自己造成的错误而责怪系统时，会用“select有问题”这个短语作为善意的提醒。

无论你多么绝望，然而都不要往那条路上走。沿着那条路下去就是伏都”计算和靠运气编程。说白了就是愚蠢，糅合祖先崇敬、万物有灵论、通灵术的原始宗教。这是一件令人绝望的事情，老是要处置一些困难的捉摸不透的问题，但是不要让绝望领着你误入歧途。作为一名谦逊的顺序员，最基本的要求就是要有意识：写的代码在任何时候出了问题，那一定都是错。这个观点在顺序员修炼之道：从小工到专家》一书中被巧妙地归结为“select没有问题”，所调试的代码里经常混杂着这些东西：和项目小组中的其他成员开发的应用代码、第三方的产品（数据库、链接器、图形库、特殊的通信系统或者算法等）以及平台环境（操作系统、系统库和编译器）大多数项目中。

最初由SunMicrosystem公司开发，早期的Solari主要针对服务器以及企业应用领域，Solari一个类似于Unix操作系统。Sun高性能工作站上有广泛的应用。并且根据这个假设采取行动。如果你想让世界人民接受你软件，代码产权的另一面是代码责任。无论你软件出现什么样的问题—甚至最开始出错的地方根本就不是代码—也应该总是假定问题出在代码里。那你就要为它故障承担全责。尽管—从严格意义上来说—并不是非这么做不可。只有这 样，才干赢得尊敬和信用。如果你不时地把问题推卸到其他人、其他公司或者其他源头上，无论如何也得不到尊敬和信用的

软件中的故障或者错误一般都是人为的例外的可能性凤毛麟角。想你已经明白了这一点。代码大全》CodeComplet一书中，从统计学的角度来说。SteveMcConnel引用了两个研究来证明这个观点：所有演讲的错误中，1973年和1984年进行的两次研究发现。大约有95%由顺序员造成的2%由系统软件（编译器和操作系统）引起 2%由其他软件引起的1%由硬件造成的跟1970年代和1980年代相比，现在系统软件和开发工具的使用人群要大得多，所以我猜测，现如今 应该有更高比例的错误是由程序员的过失造成的

请你负起责任来吧！从你代码开始，不论你软件出了什么问题。深入进去，逐步向外调查，直到找到确凿的证据证明问题之所在如果问题出在无法 控制的代码上，不但学会了必要的故障排除和诊断技巧，同时还获得了用来支持你指控他人的审计证据。当然，和你耸耸肩膀简单地把问题归责于操作系统、工具或者应用框架相比，这样花费的工夫要多得多—但是这也会逐步形成信任和尊敬的感觉，而这种感觉是通过指责他人和逃避不可能得到