先想壹想自己的假設和其他人的假設。來自不同供應商的工具可能內置不同的假設，即便是相同的供應商對於不同的工具，其假設也可能不同。
當其他人正在報告壹個妳不能重復的問題的時候，去看看他們在做什麽。他們可能會做壹些妳從來沒有想到過的事情，或者他們的做事順序與妳的截然不同。
我個人的原則是，如果我有壹個不能確定的錯誤，那麽我會先考慮是不是編譯器的問題，然後再去檢查堆棧是否損壞。特別是當添加跟蹤代碼會使得問題移動的話就更要這麽做了。多線程問題是 bug 的另壹個來源，有時候令人焦躁得簡直想拔光頭發，或者直接想摔電腦。當系統是多線程的時候，最好傾向於簡單的代碼。我們不能依賴調試和單元測試來發現任何壹致性的 bug，所以設計的簡單性是最重要的。
所以，在妳不分青紅皂白地去責怪編譯器之前，先想壹想福爾摩斯的這條建議，“壹旦妳排除了種種不可能，剩下的不管有多麽難以置信，壹定就是真相”。
2. 不斷學習
我們生活在壹個有趣的時代。隨著軟件開發逐漸遍布全球各地，妳會發現有很多人都可以幹妳的工作。所以妳需要不斷學習以保持競爭力。否則，妳就會落伍，停滯不前，直到有壹天，這份工作不再需要妳，或外包給壹些更廉價的勞動力。
那麽我們能做些什麽？有些雇主很慷慨，會提供培訓以拓寬妳的技能。也有的人會說我沒時間或者沒這個資金去接受任何培訓。所以，關鍵是要擺正心態，學習是對自己的負責。
這裏有壹些學習的方法。而且許多資源都可以在互聯網上免費獲取：
閱讀書籍、雜誌、博客、Twitter feeds 和網站。如果妳想更深入地了解對象，可以考慮添加到郵件列表或新聞組。點擊這裏通過郵件訂閱《快樂碼農》雜誌 如果妳真的很想學習某壹種技術，那麽就親自動手寫代碼。 盡量與導師壹起工作。雖然妳從任何人身上都可以學到壹些東西，但是從那些比妳更聰明或更有經驗的人身上，妳能學到的更多。如果妳實在找不到這樣的良師益友，那麽請繼續往下看。 使用虛擬導師。在網絡上找妳真正喜歡的作者和開發人員，閱讀他們寫的內容。訂閱他們的博客。 了解妳使用的框架和庫。知道事物的工作原理，有助於妳更好地應用它們。如果妳使用的是開源資源，那麽妳真的很幸運。使用調試器單步執行代碼，以查看內部究竟是怎麽回事。妳也可以去看看那些確實比妳聰明的人是如何編寫和審查代碼的。 當妳犯了錯誤，修復 bug，或者遇到問題的時候，試著去真正理解發生了什麽事情。很有可能其他人已經遇到過同樣的問題，並且發布在了網上。谷歌搜索真的很有用。 學習東西還有壹個好方法就是所謂的“教學相長”。當別人在傾聽妳的言語，並問妳問題的同時，妳也會學到東西。可以建立用戶組或本地會議。 為自己感興趣語言和技術加入或啟動壹個研究小組（模式社區），也可以創建本地的用戶組。 參加會議。如果去不了的話，也可以在網上看，許多會議會將其談話免費發布到網上。 收聽播客。 曾經對代碼庫運行過靜態分析工具，又或者查看下妳的 IDE 警告？了解它們報告了什麽，以及其原因。當然如果妳有《黑客帝國》中 Neo 那樣的超能力，自然這壹切對妳而言不過是小菜壹碟。但很可惜，我們都是普通人，我們需要時間和精力，以及不斷的努力才能促使自己不斷的學習。不過，妳不必成天學習。只要妳能有意識地花點時間去學習就可以了，哪怕每天壹小時，有總比沒有好。人活著不是為了工作，妳還應該有自己的生活。
3. 不要害怕破壞東西
每個具備行業經驗的程序員肯定參與過代碼庫岌岌可危的項目。系統很糟糕，並且改變這邊總是會破壞另壹邊不相關的功能。每次添加模塊，程序員只能想著盡可能少地改變代碼，每次發布都膽戰心驚。這座軟件的摩天大樓隨時有坍塌的可能。之所以改動代碼會如此傷腦筋是因為系統太糟糕了。但是即使妳知道系統出了問題，卻又因為投鼠忌器，而不得不聽之任之。任何壹個外科醫生都懂得，傷口要想愈合就必須得切除腐肉。雖然手術會帶來痛苦，但絕對比任傷口發炎潰爛要好。
不要害怕妳的代碼。沒有人會在乎當妳搗鼓代碼的時候有沒有暫時破壞了什麽東西。只要妳做的改變不會讓項目重新回到開始狀態，就不會令人崩潰。投入時間重構，能讓妳受益於項目整個生命周期。這樣做還有壹個額外的好處是，由於妳有過這種處理病危系統的經驗，所以妳對它應該如何工作非常內行。要善於應用這些知識，千萬不要反感這些寶貴的財富。重新定義內部接口，重構模塊，重構復制粘貼代碼，並通過減少依賴來簡化設計。妳可以通過消除特殊情況顯著降低代碼的復雜性，因為特殊情況往往是因為錯誤的耦合特點導致的。慢慢地從舊結構過渡到新結構，測試壹路同行。如果妳想要壹下子完成壹個大的重構，那麽往往會因為各種頻出的問題而考慮中途放棄。
4. 專業程序員
專業程序員的壹個最重要的特點是有責任心。專業程序員會為他們的職業生涯、預算、日程安排承諾、錯誤、技能技巧負責。壹個專業的程序員不會將責任推卸給別人。
如果妳是專業的，那麽妳就需要為自己的職業生涯負責。妳有責任去閱讀和學習。妳有責任去時刻關註最新的產業和技術。但是許多程序員覺得這應該是他們雇主的工作。NO，大錯特錯。想壹想醫生？想壹想律師？他們都是靠自己來培養和訓練自己的。他們的下班時間多用在了閱讀雜誌報刊上。他們時刻關註著最新的資訊動態。所以，我們也應該如此。妳和妳雇主之間的關系，已經在雇用合同上作了詳細的說明，簡而言之就是：妳的雇主承諾支付妳薪酬，而妳承諾做好工作。
專業程序員會為他們編寫的代碼負責。除非他們知道這些代碼是有效的，否則就不會發布代碼。現在，好好思考這個問題：如果是妳，妳會不會在不透徹了解代碼的情況下就直接發布代碼？專業程序員不希望 QA 找到任何 bug，因為這些代碼都是經過他測試之後才發布的。當然，QA 依然會發現壹些問題，因為沒有壹個人是完美的。但作為專業程序員，我們的態度應該是讓 QA 找不到任何缺陷。
專業程序員也是好的團隊成員。他們負責地對待整個團隊的輸出，而不是只顧自己的工作。他們樂於助人，善於向彼此學習，在需要的時候甚至會鼎力相助，為了項目前仆後繼。
5. 充分利用代碼分析工具
測試的價值是編程早期階段就灌輸給軟件開發者的壹個理念。近年來，單元測試，測試驅動開發和敏捷方法的興起，證實了我們開始註重於在開發周期的各個階段進行測試。但是，測試只是妳可以用來提高代碼質量的許多工具之壹。
回過頭去看，當C語言還是壹個新事物的時候，CPU 時間和任何類型的存儲都是非常寶貴的。第壹個C語言編譯器註意到了這壹點，所以選擇了通過去掉壹些語義分析，來減少代碼之間的傳遞次數。這意味著，在編譯時，編譯器檢查到的可能只是可被檢測到的 bug 中的壹小部分。為了彌補這個缺陷，Stephen Johnson 寫了壹個名為 lint 的工具——它將從妳的代碼中刪除壹些沒有價值的東西——從而實現壹些已被它的兄弟C語言編譯器撤掉的靜態分析功能。然而，靜態分析工具卻因為可以給出大範圍的誤報警告和壹些沒有必要遵循的靜態文體慣例的警告而倍受贊譽。
現在的語言、編譯器和靜態分析工具的設計和以前已經大不相同。由於內存和 CPU 時間變得相對比較便宜，因此負擔得起編譯器檢查更多的錯誤。幾乎每壹種語言都擁有至少壹個工具，用來檢查風格指南的違規行為、常見問題以及壹些狡猾的有時候可能很難捕捉到的錯誤，如潛在取消引用空指針。更高級的工具，如C的 Splint，以及 Python 的 pylint，是可配置的，這意味著妳可以通過命令行開關或在 IDE 中，使用配置文件來讓工具選擇放過其中的哪些錯誤和警告。Splint 甚至還能讓妳在註釋中註解妳的代碼，以便於更好地提示妳的程序是如何工作的。
6. 關心代碼
優秀程序員能寫出好代碼，這是毋庸置疑的。壞程序員……則不能（他們能寫出好代碼，就不是壞程序員了，哈哈）。他們總是在生產其他人不得不消滅的怪獸。妳的目標是寫出好代碼，對不？那麽妳應該成為好程序員。
好的代碼並不是憑空而來的，也不能靠運氣然後恰巧讓妳瞎貓碰到死老鼠。為了獲得良好的代碼，妳必須努力的改進。過程是艱難的。但是如果妳確實關心代碼的話，那麽妳壹定能收獲好代碼。
僅靠技術並不能成就好的編程。我碰到過壹些非常聰明的程序員，他們能夠產出令人印象深刻的算法，能夠熟記語言標準，但卻寫出了最可怕的代碼。這種代碼，閱讀起來很痛苦，使用起來很痛苦，修改起來更是令人痛不欲生。我也碰到過壹些非常謙遜的程序員，因為堅持簡單的代碼，所以寫出來的程序更優雅，更易於表達他的意思，和他們工作非常愉快。
基於我多年的軟件生產經驗，我得出的結論是，差強人意的程序員和偉大的程序員之間的真正區別是：態度。好的編程在於專業的方法，以及壹種竭盡全力希望寫出最好軟件的期望。
要成為壹個優秀的程序員，妳必須對自己的代碼負責，真正關心代碼——養成積極向上的心態。偉大的代碼是由大師精心雕琢的，而不是由那些馬虎的程序員胡亂寫出來的。