大多數情況下，如果你正在做的事情無法在互聯網上找到答案，那么這通常意味著這個問題很難或者很重要，或者兩者都是

盡可能多地刪除代碼

語法糖通常是不好的

簡單往往是最難的

擁有各種各樣的工具，并知道該用哪些工具來完成工作

了解最常用的工具的內部結構，如 git 和 bash

為重復的工作流程構建自己專用的工具

從最好的資料中進行學習（這里 Matt 舉例稱他在學習 Go 時閱讀了標準庫）

如果代碼看起來很丑，那很可能是一個嚴重的錯誤

如果必須編寫不是文檔字符串 （docstring） 的注釋，則應該考慮對這段代碼進行重構

如果不了解所編寫的程序是如何在生產環境中運行的，那就說明不了解程序本身。優秀的工程師知道他們的程序在各種環境中是如何運行的

上面這條經驗對于構建管道也適用

謹慎使用他人的代碼

互聯網上找到的代碼大多數都很糟糕，有時候自己寫一個更好的版本會更容易

永遠不要直接依賴自己可以輕松重寫的小型庫，或本應很小的大型庫

知道什么時候該打破規則。對于“不要重復自己”這種規則，有時候重復比使用依賴要好

將代碼組織成模塊、包和函數很重要。了解 API 的邊界位置是一門藝術

大多數情況下應選擇最有效的工具，但也要選擇自己所知道的。Arch Linux 是現代開發者最高效的操作系統嗎？對我來說，是的，但對大多數人來說，可能不是

避免圈復雜度 （Cyclomatic complexity）

避免多層嵌套條件

正確命名變量，這也是一門藝術

雖然很少見，但有時報錯可能確實是編譯器的問題

謹慎使用深奧的語言特性，但在應該使用的時候還是要使用

技術的傳播并不均衡對等。例如，前端開發者可以從負責底層技術的工程師那里學到許多東西，云工程師可從 JavaScript 開發者身上學到用戶體驗和可用性方面的知識。但反過來卻未必成立

因此，不同類型的工程師看待世界的方式是不同的

部分程序員的效率是其他程序員的 10 倍

成為 10 倍程序員與 10 倍員工這兩者之間沒有相關性（或許是負相關）

好的 API 易于使用且難以誤用

配置七邊形（Matt 自創的術語）從硬編碼值開始，到環境變量、CLI Flag、配置文件、模板化配置文件、DSL、通用 bash 腳本，再到硬編碼值。開發者應了解這個七邊形中的各個位置。

責任編輯：haq