工程師，世界上最偉大卻也最辛苦的職業。在外界看來，工程師是一個神秘的群體......

毋庸置疑，工程師在互聯網科技的歷史上扮演著極其重要的角色，如創立微軟的程序員比爾·蓋茨、依靠搜索算法創建 Google 的佩奇和布林、構建 Facebook 社交網絡的黑客馬克·扎克伯格，無數大名鼎鼎互聯網公司都是由工程師所創立。

對于技術人員來說，到底有沒有自己特定的文化？什么才是真正的工程師文化？

今天，我想在這里再談一下工程師文化，一方面是因為我又有了一些想法和體會；另一方面，因為我也正走在創業的路上。

我認為，建立一個有濃重的工程師文化的團隊或公司，有必要把自己的想法形成白底黑字的“字據”，以供以后打自己的臉：

“要是未來沒有做到，這篇文章就打我未來的臉” 或者 “這篇文章太幼稚了，未來的我會打我現在的臉”。當然，如果非要打臉，我希望是前者。

為什么要工程師文化？

看看最近二十年來社會的發展，計算機和互聯網已經滲透到了這個社會的每一個角落，各式各樣的計算機技術成為了整個世界發展的強大引擎。

無論是業務創新還是技術創新，都依托于技術的快速演進，技術成了解放生產力、提高社會運作效率的中堅力量。

今天，每個從事計算機行業的技術人員都應該感到幸運，因為，我們不但選對了行業，也出生在了正確的時代，可以感受到前所未有的刺激和變化。

此時我們只需要思考一個問題，那就是，我們是否處在正確的地方并用正確的方式做事？

在我看來，這個世界上有三種類型的商業公司：

運營或銷售驅動型公司

這類的公司以運營和營銷見長，技術對于它們來說更多的只是為了支持大規模的營銷活動，以及成本上的控制，所以，基本上來說不太需要技術創新。這類公司非常缺乏安全感。

產品驅動型公司

這類公司以產品見長，創造能提升用戶生活體驗的產品，技術對于它們來說，除了支持大規模的在線用戶之外，更重要的是增強用戶體驗，提高整個業務流程效率的技術創新，比如在 UI 交互和業務流程方面。

這類公司最大的問題，就是容易被別人模仿和抄襲。

技術驅動型公司

這類的公司相信技術能改變世界，它們更多的是用強大的工程技術來創造顛覆性的產品，用各種自動化的技術取代人類工作。

比如：近代蒸汽機技術取代了大量的人工勞動，數字技術取代了大量信息傳遞的人工勞動，未來它們還希望通過人工智能來代替人類做更多的決定。這類公司最大的問題就是可能做出叫好不叫座的產品。

這三種公司都可能成功，也都有問題，但是，無一例外，他們都需要強大的技術支撐，只不過，他們把技術所放在的位置不一樣。

無論你有多么的看不起技術人員，你都無法否認，你今天的生活相當的依賴這幫工程師，沒有他們，你恐怕都不知道怎么生活了。

***幾十年前就說過——“科學技術是第一生產力” ，無論什么樣的科學技術的理論要落地都會依賴于工程技術有多先進。

所以，在今天，作為一個 IT 或互聯網公司，“工程師文化”不是一個問題，而是一個常識！

工程師文化的“兩大法寶”

簡單來說，我把這么多的工程師文化總結成兩大類：“自由” 和 “效率”。

本來還應該有個“創新”，但我個人認為，創新的前提是——在自由的環境下對提高效率的癡迷，就一定會發生創新。

創新不是憑空出現新的東西，其實，觀察一下人類的發展史不難發現，幾乎所有的創新基本上是“跳出原來的思維模式用新的思維模式對原有問題的效率進行質的提升”。

比如：通信、交通、醫療、教育、生活……幾乎全都是在優化效率。

所以，如果精神不自由，就很難跳出老的思維模式，如果不是對效率的提升，這個創新可能會不接地氣。因此，我認為，工程師文化就是自由加效率！

以上列舉的這些特征，來源于：Google 的《重新定義公司》（How Google Works）、我在 Amazon 的工作經歷、37Signals 的"Rework"、Quora 上的" What Makes Good Engineering Culture? "、 Slideshare 上的 “What Makes Good Engineering Culture”，以及我最近這半年來的一些實踐。

由前 Google CEO 施密特編寫的《重新定義公司》（How Google Works）一書

自由

工程師文化首先意味著創新文化。因為工程師都是有創新沖動的人，而創新的源泉來源于精神的解放，精神自由才會引發各式各樣的奇思怪想。

因此他們才會有常人覺得不可能的瘋狂想法和想象力，而這些想法和想象力導致了創新。

精神上的自由具體表現在以下六個方面：

1. 自我驅動。自己管理自己是最好的管理，最失敗的管理是家長和保姆式的管理，從興趣出發的工作才可能迸發出真正的動力。

2. 靈活的工作時間和地點。工程師們的工作更多的是腦力工作，而不是體力工作，工作上時間和地點的自由安排可以讓工程師們的腦力工作更有效。

Remote（遠程辦公）是一個很不錯的工作方式，開源社區基本上都是使用這鐘方式。

3. 信息平等。這意味著，全體員工得到的是原始信息，而不是被管理者們層層加工消化后的信息，信息的屏蔽很容易造成誤解和完全錯誤的行為。

信息的平等，既包括戰略、方向、目標、財務等大信息，也包括文檔、代碼和知識的共享等小信息。

同樣，平等也表現在意見表達上，任何人都有表達自己的意見和建議的平等機會，這樣才會激發出更多的思路和思辯，從而才會有更多更好的思路出現。

在 Google，除了代碼全員共享，還有 Thanks God, It’s Friday 的文化，每周五高管們會和員工在一起，面對面回答員工提出的各種尖銳問題；在 Amazon，代碼和文檔基本上對全員開放，包括財務報表也對員工開放。

另外，亞馬遜所有最牛的 Principle SDE（資深技術專家）隔三岔五都會有一個 Principle Talk（有很多 Talk 相當令人開腦洞）。

還有 Amazon 內部每年會選出一批公司最聰明最有想法的人開會，討論公司下一步的發展戰略，并可以把相應的 KPI 直接傳遞給 Senior VP。

4. 不害怕錯誤。處理錯誤的正確姿勢是分析和總結教訓，而不是懲罰犯錯人。前者讓人改善進步，后者讓人萎縮不前。工程師最大的錯誤就是不敢犯錯，最大的問題就是不敢直面問題。

5. 寬松的審批系統甚至沒有審批系統。

審批通常暗示著三件事：

對人的不完全信任

繁瑣的流程

思維上的束縛

這些都是創新和想象力的天敵。一個公司的監管、審批、流程越重，這個公司的活力也就越差。

6. 20% 的自由時間。這是 Google 提出來的，員工有 20% 自由的時間做自己想做的項目，Gmail 就是這么誕生的。

效率

工程師天生是追求效率的。有人說認為程序員花大量的時間做自動化的工具，還不如人肉的效率高。

比如寫自動化的腳本花 5 個小時，而重復做這件事 200 次只花 3 個小時。有這樣的理解的人根本不懂工程師和工程。

一方面，這個工具可以共享重復使用，更多的人可以從中受益。更重要的是，這是一種提高效率的文化，它會鼓勵和激發出更多這樣的事情發生。

如果公司管理者因為一個程序員花大量的時間開發自動化的工具，而認為這個程序員沒有效率，并且對他批評甚至懲罰的話，那么這個管理者就完全扼殺了提高效率的文化。

人類之所以比別的動物聰明就是會使用和發明工具，而古語也有云：“工欲善其事，必先利其器”。

看看美軍的裝備你就知道戰爭工具的好壞有多重要了，一個公司的強大之處在執行力，而執行力的強大之處在于你有什么樣的支持工具。這些，已經不是工程師文化，而是人類發展的文化。

對于工程師文化來說，尤其是在軟件工程領域，提升工程效率具體表現在如下七個方面：

1. 簡化。簡化不是簡陋，簡單的東西通常意味著用戶更好理解，也意味著更容易的維護和運維。

就像阿里推行的“小而美”、喬布期推崇的“沒有產品手冊簡單易用的產品”、Amazon 推行的 Working Backwards 里說的那樣。

一個新的產品或功能，產品經理需要寫三個文檔：媒體公關文、用戶手冊、常見問題，三個文檔總共加起來不超過兩頁 A4 紙，且不準用任何圖片說明，目的就是為了讓產品簡化和容易使用。

2. 殘酷無情的推行自動化。編寫程序的最本質的目的就是自動化，對于自動化來說，不僅僅只是消除人肉的重復勞動，更重要的是，很多事情人的力量完全比不上機器。

比如：增加一臺機器，程序運算在秒級就可以完成，而人是永遠不可能達到這樣的速度。

再比如：電商中用程序管理數量巨大的訂單自動化系統，增加再多的人都不可能像機器那樣完成的又好又快。

自動化需要大力開發提高生產力的工具，比如：持續集成，持續部署，自動化運維，基礎自動化運維，甚至自動化的運營工具。

3.避免無效率的組織架構和無效率的管理。

這體現在以下這些方面：

扁平化的組織架構。

努力用自動化工具取代支持型的工作。

不超過 10 個人的全棧小團隊。

不按人員的技能分工而是按其負責的產品或功能分工。

開會不是解決問題，開會是表決提案。

通過產品的目標或信條來減少溝通和決策過程。

比如，Amazon 里的每個部門、每個團隊、每個產品都有自己的信條，這個信條標明了要什么不要什么，這樣可以避免很多扯皮和難纏的選擇。

我們來看看 AWS 的幾個信條：運維是最高優級的——這意味著只要是會讓運維變得復雜的需求都可能被工程團隊拒掉。

Throughput & Latency（吞吐量和延遲）不能更差——這意味著功能要為性能讓路，因為性能變差了，用戶就要購買更多的資源。

4.正確的組件抽象。抽象是簡化的一部份，最重要的是，抽象意味著技術能力的輸出，無論是內部的其他團隊還是外部的團隊。

比如：Google 的 MapReduce/BigTable/ProtoBuffer，FaceBook 的 Thrift，還有 Amazon 內部的 Web Service 框架 Coral Service、處理日志監控的 Timber，以及全線 AWS 產品都用到的 Amazon Lock Framework（一個分布式鎖框架）……

5.開發高質量的產品。因為高質量的代碼，不但可以易于修改和維護，還可以因為較少處理線上故障，從而有更多的時間去為未來做更多創造性的工作。

這意味著需要有非常嚴謹的 Design Review，Code Review，以及測試。

6.不斷的提高標準以及招聘最好的人。如果一個公司或一個團隊想變得越來越好、越來越強大的話，就必須要不斷提高自己的工作標準。

提高工作標準意味著要不斷地培養和招聘更好的人才。在 Amazon 和 Google 的招聘系統中都有一個叫 Bar Rasier 的職位，這個職位就是為了提高招聘標準而設立的。

7.創建一個持續改善的文化。一個好的組織和團隊，需要全體員工一起不斷反思前進。

在微觀層面上，在項目做完后需要有一個總結會分析項目中的得失，在故障出現后，需要有故障分析會。

在 Amazon，嚴重的故障需要寫一個 COE（Correction of Errors）的文檔，其中有一節叫“Ask 5 Whys”，讓你問自己關于這個故障至少 5 個為什么。

在宏觀層面上，一家公司每年都應該做一定的工作數據分析或是員工調查。比如，是否招聘到了不錯的人、工作的投入產出比、員工在哪些地方花費時間等等，然后不斷的用技術手段來改善。

Amazon 每年的工程師員工調查表是我見過的最細的調查表了， 表中的問題除了針對公司、管理層、文化等方面。

還包括日常工作、開發環境、持續集成、測試自動化、產品質量、軟件架構、軟件維護、線上問題處理、年度計劃、數據倉庫建設、通用工具投票……這個員工調查直接導致公司對工程的投資方向。

工程師文化如何落地？

如果你要讓一種企業文化在公司內得到執行，有下面幾個手段可以選擇：

“政治”手段

招聘、績效考核和升職。比如，你要落地工程師文化中的簡化和自動化，那你在招聘的時候，需要把懂簡化和喜歡自動化的人招進來。

然后在績效考核和升職的地方設置上一條硬性指標——你今年簡化了什么？自動化了什么？如果沒有，不但不能升職，績效還可能不達標。

“經濟”手段

讓不做這件事的成本 > 要做這件事的成本。然后，正常的人類都會選擇成本低的方案。

比如，如果你要推行 Design/Code Review/UT 以提高質量，你就把 QA 和 Ops團隊全挪到一邊去，讓 Dev 團隊自己測試，自己負責。

這樣等這些 Dev 重復多次手動測試，處理多次線上的弱智故障，他們就會自然而然的寫自動化測試和做 Code Review 了。

而 QA 和 Ops團隊只是幫 Dev 你做工具罷了，而測試和運維的事全是你 Dev的 Ownership，出了故障也是 Dev 自己負責。

于是，他們就會發現，不做 Code Review 和 UT 的成本遠遠大于做 Code Review/UT 的成本，他們就會去做成本低的事了。

最后，工程師文化要落地，還有幾個小條件：

團隊要小，Ownership 很重要，Eat Your Own Dog Food。 沒有人幫你擦屁股，自己的屎自己吃，沒有痛苦，不會產生想進步的動力。

熱愛學習和嘗試。學習嘗試新的技術，開拓眼界，學習嘗試新的思維方式。否則，原有的思維方式只會讓你在原地打轉。

老板更多的相信技術而不是管理。相信技術會用技術來解決問題，而只相信管理，那就只會用制度、流程和價值觀來解決問題。

其他

以上這些是我這么多年經歷過或看到的工程師文化，最后說說我的幾個觀點。

996 和加班這件事，對于工程師來說從來都不是問題。在解決技術問題或是創造的時候，工程師是個很自覺的群體，基本不需要他人驅動。

我相信幾乎對于所有走上編程這條道路的工程師，基本上都是興趣所至，他們覺得編程很有趣。

但很多工程師卻被一些公司的 996 搞得對編程毫無興趣，為什么？這些公司就是通過考試/KPI/996這些東西把工程師的興趣一點一點的磨滅掉、對學習和工作產生了厭倦和討厭。

另外，文章中我說的這些文化，并不是什么理想主義，而是已經被很多成功的公司使用了很多年。

還有人說，因為中國國情不同所以這些方法并不實用，這更讓我費解。中國有全世界數一數二的互聯網用戶，也有全世界數一數二的市場，不再是以前那個一窮二白的年代，中國的國情到底有哪些不同呢？

我不知道各位工程師為什么而活著？但我覺得，我們選擇了一個刺激的職業，也趕上了這個行業大發展的時代。

我們不妨捫心自問一下，你是否愿意讓自己的能力、青春和熱情就這樣被磨滅掉？