整理自Edmond Lau的《The Effective Engineer》。

作者在寫書的過程中，為了了解那些***程序員和 普通程序 員的區別，采訪了很多硅谷***科技公司的***軟件工程師。他發現這些給世界帶來巨大影響的的工程師們至少有以下5個共同的思維模式：

1. 勇于去研究你不懂的代碼

一般人都不愿意去研究自己不曾接觸過的代碼，很多人都沒有嘗試就放棄了。如果你經常去研究你沒有接觸過的代碼，你就會越來越熟悉不同的代碼結構和設計模式?，F在人們很容易就接觸到優秀的開源代碼資源，你可以很方便的就下載下來做一些改動或者調試，去研究為什么代碼可以這么寫。

除了代碼之外，很多人對于陌生的工作內容也會感到恐懼。每次換工作的時候，你可能都會遇到新公司的工作內容和以前工作的內容不一樣的情況，以至于剛開始的時候工作效率沒有以前那么高。很多人甚至覺得，他們是不是騙了面試官。

其實，大家都是在學習的過程中。在一個陌生的領域，沒有人從一開始就是大神。如果你想變得越來越好，無論是寫代碼，與人溝通或者其它的技能，都是需要投入時間去學習的。

2. 精通代碼調試(debug)

很多人在寫代碼的過程中，經常會有的一個問題就是：為什么我寫出來的代碼不能運行？為什么運行的結果不是我想要的？

幾乎所有的程序員寫代碼都不是一遍就能寫好的。但是***的程序員非常快的就明白自己代碼的問題可能是什么。這是一個很重要的能力，但是偏偏學校里不教，面試的時候考官也不經常提及。

那么怎么去調試代碼呢？其實核心就是以下幾個方法：

• 不妨先猜測一下到底發生了什么。
• 假設你的猜測是對的，想想你的猜測會導致程序有什么結果。
• 試著觀察這些結果有沒有異常的地方。
• 如果你沒有發現異樣，那么說明你的猜測就是對的。
• 如果你發現了異樣，那么說明你的猜測是錯的，接下來換一個猜測試試。

對于***程序員來說，這個過程在腦海中就是電光火石的一瞬間。只要你解決的問題足夠多，你做出來的猜測就會越準確。

至于如何發現異樣？你就需要有一套自己的工具或者方法論了。最簡單的就是在代碼里輸出日志來判斷。但是這是比較笨的辦法，你需要去接觸一些高級的工具或者直接帶有Debug功能的編輯器。

3. 重視能夠節約時間的工具

最近打敗人類的AlphaGo每天可以進行上百萬局的下棋訓練，我們人類一萬個小時的訓練卻需要10年之久。也就是說，電腦運行幾分鐘，可能就等于人類工作好幾年。

曾經在Facebook擔任技術總監的Bobby Johnson描述過，高效率的程序員都把時間花在制作工具上。

很多人也認為工具是很重要的，但是他們并沒有花時間去制作、整合自己的工具。但是，Jonson團隊最出色的員工耗費了他們1/3的時間在工具制作上，這些工具可以用來發布代碼，監控系統，以及能讓他們花更少的時間去做更多事情。

總之，不要花時間去做機器可以代替你去做的事情。

4. 優化你的迭代速度

假設你要花12秒鐘去搜索某個函數是在哪里定義的。再假設你每天做這個動作60次，那么你每天就要花12分鐘去搜索函數定義。

如果你用一個好一點的編輯器，每次找到函數定義只要2秒鐘，那么你每天就會節約10分鐘。每年你就可以節約40個小時。

如果你能找到3個這樣的場景去優化一下，那么你每年可以節約一個月的時間。想想這一個月你可以做多少有意義的事情。

再假如你在調試一個App的bug的時候，改完一次代碼都需要重啟一下App，然后點擊4、5次才能看到bug有沒有改好。那么你是不是可以先花幾分鐘設置以下，讓App一啟動就轉到顯示Bug的頁面呢？

千萬不要小看這些瑣碎的細節，改善它們的回報是巨大。

5. 系統性的思考方式

當你在寫代碼的時候，你很容易就認為只要你按照需求實現了指定的功能，你的代碼就寫完了。但是這其實只是 冰山一角 。任何沒有發布到生產環境的代碼都不會產生任何價值。

如果想寫出真正有影響力的代碼，你需要從整個系統去理解你的工作：

• 你的代碼和其他人寫的代碼在功能上是什么關系？
• 你有沒有好好測試你的代碼？或者其他人是否很容易測試你的代碼？
• 為了部署你的代碼，線上生產環境的代碼是不是需要改動？
• 新的代碼會不會影響到已經運行的代碼？
• 在新的功能下，你的目標用戶的行為是不是你期望的？
• 你的代碼有沒有產生商業上的影響？

這些問題都不是很容易就能回答的，但是在寫代碼的時候，你需要明白你的代碼***會不會得到***的結果。