测试小姐姐: 这个地方显示有问题，兼容性不好！

程序猿哥哥: 我的浏览器怎么没有？你用Chrome吧!

测试小姐姐: 刚刚这个按钮点击没响应！

程序猿哥哥: 服务端没有请求日志，你再点一下？

测试小姐姐: 这个导出功能无法导出数据，还会超时！

程序猿哥哥: 咦，OOM了，应该导出的数据太多了，你少导点就没问题了！

程序员第一法则：都是你的错！不用怀疑！！！

每个程序员都知道这种感受，因为我们都曾经遇到过这种情况：反复看了无数遍代码，仍然没有找出问题的原因。程序员总会遇到一些BUG或者错误，可能是代码的问题，可能是你写代码的机器的问题，或者运行的操作系统的问题，甚至是正在使用的工具或者类库的问题！

一次又一次对抗有难度的，很隐蔽的BUG是很令人沮丧的，但是不要让绝望让你误入歧途。 作为一个谦虚的，优秀的程序员的一个重要部分就是意识到：只要是你编写的代码就会出问题，而且都是你的错！

在许多项目中，你正在DEBUG的代码可能混合了你写的代码，项目组其他人写的代码，第三方产品（例如数据库，工具类库，通信方式&算法等），平台环境（操作系统，系统库，编译器等）。

这样一来，BUG可能在操作系统中，也可能在编译器中，也可能在第三方产品中，但是这不是你首先需要思考的。你更应该思考的是在开发环境中，应用的BUG是否存在。通常我们更应该假设应用代码以错误的方式调用了第三方库，而不是假设第三方库本身的问题。即使问题真的存在第三方库中，在提交BUG前，我们应该想办法修改自己的代码来规避它。

我们参与过一个项目，一个高级工程师确信在Solaris操作系统上的select系统调用被破坏了，任何劝说都改变不了它的想法（事实上在这个环境上其他应用运行良好）。它花了一周时间写解决方法，但是这些方法似乎并不能修复这个问题。

当最终聚焦在select的文档上时，他发现了问题，并且只花了几分钟就纠正了这个问题。现在当任何人开始把错误的原因归咎在系统上，而不是找自己的问题，我们就会用"select is broken"这个短语作为一个善意的提醒。

代码所有权的另一面是代码责任。无论你的软件出了什么问题–可能甚至都不是你的代码–你一定要假设问题就出在你的代码中，承担所有出现的问题的责任，即使某些责任你不必承担。这就是你赢得尊重和信任的方式，通过甩锅给其他人，其他公司是肯定无法赢得尊重和信任的。

统计表明，你负责的软件程序中任何BUG或者错误不是你造成的概率是极低的（换句话说，你的程序出错基本上都是你造成的！）。Steve McConnell引用两个研究来证明这一点：

在1973年和1984年两次研究表明，所有的报告的错误中，大概有95%是程序员造成的，2%是系统软件（编译器或者操作系统）引起的，2%是其他软件引起的，只有1%是硬件造成的。

今天使用系统软件和开发工具的人远比70年代和80年代多的多，因此我大胆的猜测，今天的错误，程序员造成的概率比以前（95%）要更高。（操作系统和开发工具用的人越多，发现的问题越多，从而会让它们越来越完善，出错的概率也越来越低）。

所以，你的软件无论出现什么问题，首先检查你的代码，然后慢慢向外排查，直到你能非常明确的证明问题所在。如果问题出现在一些你不能控制的代码中，你不仅学习到了必要的故障排除和诊断技能，而且得到证据支撑你的申明（这个锅确实不是我的锅）。

这个过程肯定是痛苦的，需要你付出巨大的努力，远不是轻易的下个定论说操作系统，工具，或者框架有问题那么轻松。但是它会产生一种信任感和尊重，这些东西是不可能通过妄下定论或者逃避能获得的。

如果你真的渴望成为一个谦虚的，优秀的程序员，你应当毫不犹豫的说：这是我的问题，我会找出原因。

摘录一些有趣的回复：

always your fault

always your fault

always your fault

always your fault

always your fault