原文作者2012-5-30 12:22 在Twitter上發的一條Tweet：
“在怨天尤人之前，我們應該先自我反省、努力把自身的問題解決了。”
你應該知道那種感覺。我們所有人都曾碰到過這樣的事情：你已經盯著程式碼看了無數遍，但還是沒有發現任何問題。然而，有個故障或者錯誤始終揮之不去。於是你開始懷疑，一定是你開發程式所用的那臺機器出了問題，也可能是作業系統的問題，或者是你使用的工具和庫出了問題。肯定是它們的原因！
然而，無論你多麼絕望，你都不要往那條路上走。沿著那條路下去就是“伏都”計算和靠運氣程式設計。說白了，就是愚蠢。
譯者注：伏都教（voodoo），又譯“巫毒教”，源於非洲西部，是糅合祖先崇拜、萬物有靈論、通靈術的原始宗教。
老是要處理一些困難的、捉摸不透的問題，這是一件令人絕望的事情，但是不要讓絕望領著你誤入歧途。作為一名謙遜的程式設計師，最基本的要求就是要有意識：你寫的程式碼在任何時候出了問題，那一定都是你的錯。這個觀點在《程式設計師修煉之道：從小工到專家》一書中被巧妙地歸結為“select沒有問題”：
譯者注：select是用於I/O多路轉接的一個系統呼叫函式。
在大多數專案中，你所除錯的程式碼裡常常混雜著這些東西：你和專案小組中的其他成員開發的應用程式碼、第三方的產品（資料庫、連結器、圖形庫、特殊的通訊系統或者演算法等）以及平臺環境（作業系統、系統庫和編譯器）。
作業系統、編譯器或者第三方產品出問題的可能性是有的——但是，這絕對不應該是你碰到問題後的第一反應。錯誤出現在正在開發的應用程式碼中的可能性要大得多的多。通常情況下，假定應用程式錯誤地呼叫了庫函式要比假定庫本身有問題更有效益。即便問題出在第三方，你還是必須徹底排除自身程式碼的問題，然後再提交錯誤報告。
我們曾經做過一個專案，專案中的一位高階工程師確信Solaris上的select系統呼叫出了問題。無數次的勸說和邏輯分析都不能改變他的主意（事實上，所有其他的網路應用程式在同樣的機器上都能正常工作，但他仍然固執己見）。他花了好幾個星期來做變通方案，但是因為一些詭異的原因，這些方案似乎都行不通。他最終不得不坐下來，仔細地閱讀關於select的文件。然後，他找到了真正的問題，並且在幾分鐘內就把問題解決了。如今，一旦我們當中有人開始為了一個很可能是我們自己造成的錯誤而責怪系統時，我們會用“select有問題”這個短語作為善意的提醒。
譯者注：Solaris是一個類似於Unix的作業系統，最初由Sun Microsystems公司開發。早期的Solaris主要針對伺服器以及企業應用領域，在Sun的高效能工作站上有廣泛的應用。
程式碼產權的另一面是程式碼責任。無論你的軟體出現什麼樣的問題——甚至最開始出錯的地方根本就不是你的程式碼——你也應該總是假定問題出在你的程式碼裡，並且根據這個假設採取行動。如果你想讓世界人民接受你的軟體，那你就要為它的故障承擔全責。儘管——從嚴格意義上來說——你並不是非這麼做不可。只有這樣，你才能贏得尊敬和信用。如果你不斷地把問題推卸到其他人、其他公司或者其他的源頭上，你是無論如何也得不到尊敬和信用的。
從統計學的角度來說，軟體中的故障或者錯誤一般都是人為的，例外的可能性鳳毛麟角。我想你已經明白了這一點。在《程式碼大全》（《Code Complete》）一書中，Steve McConnell引用了兩個研究來證明這個觀點：
在1973年和1984年進行的兩次研究發現，在所有報告的錯誤中，大約有95%是由程式設計師造成的，2%是由系統軟體（編譯器和作業系統）引起的，2%是由其他軟體引起的，1%是由硬體造成的。跟1970年代和1980年代相比，現在的系統軟體和開發工具的使用人群要大得多，所以我猜想，現如今應該有更高比例的錯誤是由程式設計師的過失造成的。
不管你的軟體出了什麼問題，請你負起責任來吧！從你的程式碼開始，深入進去，逐步向外調查，直到你找到確鑿的證據證明問題之所在。如果問題出在你無法控制的程式碼上，你不但學會了必要的故障排除和診斷技巧，同時還獲得了用來支援你指控別人的審計證據。當然，和你聳聳肩膀簡單地把問題歸責於作業系統、工具或者應用框架相比，這樣花費的工夫要多得多——但是這也會逐步形成信任和尊敬的感覺，而這種感覺是你通過指責他人和逃避不可能得到的。
如果你真的渴望做一名謙遜的程式設計師，在你碰到問題的時候，你就應該很淡定地說：“嘿，這是我的錯——讓我把它弄個水落石出。”