「高級工程師」沒用！你應該成爲一名 「成熟的工程師」

想，在咱們這個行業中，有不少經驗知識，特別是關於如何成爲合格的工程師。雖然在管理領域中有不少關於非技術性我的貢獻者的「專家」角色和責任的書籍，但我並無看到多少現代書籍或帖子，直接講述要如何才能成爲一名優秀的高級工程師。一個值得注意的例外固然是 Kate Matsudaira，她最近發佈了不少關於 工程文化方面 的文章，這些文章寫得都至關不錯。

我所知道的有不少成功的工程師，都記得這位導師，他們從這位導師那明白了什麼是「高級」。

不過，我確實徹底贊成我朋友 Theo 在 《網站運維》（Web Operations）（由 O'Reilly 出版）一書中關於成爲「高級」的一章中所說的話：

X 一代（甚至更多的是 Y 一代）是一種即時知足的文化。我曾與衆多工程師共事過，他們認爲，僅憑他們的高智商，「職業道路」應該能讓他們在在 5 年以內躋身工程團隊的最高層。從我親眼目擊的驚人數字來看，這簡直徹底是不可能的。不是每一個人都能成爲高級程序員。若是說，五年後你成了高級工程師，你是否是正處於事業的巔峯呢？那再過五年，你會不會積累更多寶貴的經驗呢？再而後呢？是「超級工程師」嗎？若是又再過五年呢？「超超級工程師」？我把這種痛苦歸咎於咱們管教的年輕人。事實是，在網站運維領域工做十五年的工程師寥若星辰。鑑於咱們這個行業的局勢，許多人選擇轉行到管理職位，或者冒着創業的風險。

他是對的：這個網站運維領域還很年輕。所以，當擁有「高級工程師」頭街的人，表現出不成熟的行爲時，不管是技術性的仍是非技術性的，咱們都不會感到驚訝。若是你還沒讀過 Theo 寫的章節，我建議你去讀一讀。

話雖如此，在這門學科中，「高級」到底意味着什麼呢？固然，對此我也有本身的見解，由於我負責招聘、支持和留住那些被認爲是高級工程師的人。有一種想法，就任業發展而言，有一道門檻須要跨過，能有這種想法是很好的，但我還要補充的是，這些標準存在於一個範圍以內，而不是簡單的複選框列表。你不會有一天認識到，你之因此是「高級」工程師，只是由於你的職位反映了晉升而已。高級工程師並不是什麼都懂。他們的技術知識也並不完美，但他們對此並不介意。

爲了不將職位和模糊的指望相混淆，有時我會提到工程師的 成熟度。

意思就是，我心目中真正的「高級」工程師就是 成熟 的工程師。

我將簡要地介紹一下一名成熟的工程師應該有必定程度的掌握或理解的技術領域的部分（如「網絡」、「文件系統」、「算法」等），相反，我還要強調我的特性，由於在我看來，這些特性代表某人能夠在工程領域對一個組織或企業產生積極的影響。

在 Quora 上，有人曾經問過我：「做爲一名優秀的技術運維副總裁，除了技術能力 / 經驗外，還有哪些特性？」

我在回答中提到的特性列表是基於這樣一種理解，它們就是我本身永恆的追求。本文和我那個回答是類似的。

首先我認爲，Web 開發和運維方面的高級工程師與其餘工程領域（機械、電氣、化學等）的高級工程師具備相同的特色，在這種狀況下，《工程學的潛規則》（The Unwritten Laws of Engineering ）這本書是適用的。再強調一次，若是你尚未讀過這本書，請先讀一讀。這本書最初寫於 1944 年，由 美國機械工程師協會出版（American Society of Mechanical Engineers）。這本書的摘錄可參見：人因工程與網絡工程的交集（Human Factors and Web Engineering’s Intersection）

雖然這本書的結構和文字給人一種過期的感受（如「……不要在工做場合說髒話」或「……男人應該特別注意剃鬚習慣，修剪鬍鬚」之類），但它仍然很好地歸納了工程組織的非技術方面的指望、職責和內部工做，以及管理者和成熟工程師的行爲方式。

成熟工程師必備的精煉特色

全部試圖洞察指望特徵的帖子都必須有豐富的要點，而工程學也有至關一部分的要點。所以，我講給大家講的，有一些是個人，還有一些來自不一樣的來源，其中不少都來自上面提到的《工程學的潛規則》一書。

成熟的工程師會對他們的設計尋求建設性的批評。

我遇到的每一位成熟的工程師，在完成一個設計或者爲一個項目作好準備以後，都會不斷地向他們的同行提出如下相似的問題：

• 「我可能遺漏了什麼嗎？」

• 「這怎麼會不起做用呢？」

• 「請你給個人想法儘量多提意見好嗎？」

• 「即便它在技術上是合理的，但它是否可以足以讓組織的其餘成員進行操做、故障排除和擴展呢？」

這是由於他們知道，他們所作的一切都不會只掌握在本身手中，並且通過良好的同行評審才能作出更好的設計決策。就像其餘地方所說的那樣，他們「乞求獲得壞消息」。

成熟的工程師瞭解如何感知他們的非技術領域。

可以在 Erlang 中編寫 Bloom Filter，或者在睡夢中編寫多線程 C 是不夠的。若是沒有人願意和你合做，這些就都不重要了。成熟的工程師知道，不管他們的設計看上去多麼完善、多麼優雅、多麼優秀，若是沒有人願意和他們一塊兒工做，那也沒有關係，由於他們都是 混蛋。傲慢、輕視、自戀和自負的行爲會把這一信息傳遞給其餘工程師（也許是心領神會地），讓他們遠離。工程師的快樂部分來自於在設計和建造東西的時候享受與你一塊兒工做的同事的陪伴。若是一個工程師很快就把某人稱爲白癡，那麼他註定會阻礙本身的職業生涯。

這也意味着成熟工程師在溝通方面有自我意識。這並非說每一個成熟的工程師都能很好地溝通，只是說他們知道本身在哪些方面能夠作得更好，並不斷要求同事和經理對他們的工做進行檢查。他們的目標是如何表達本身的想法時保持自信，而非被動或咄咄逼人。

我 在別處已經提到 過，但我必須更增強調這一點：其餘人想和你合做的程度直接代表了你在工程師的職業生涯有多成功。成爲人人都想合做的工程師。

這並非說，你應該避免對工程（而不是工程師我的）所產生的 工做 提出建設性的批評，以避免惹惱別人。將某人稱爲白癡，和指出他們的代碼或產品中的錯誤是兩回事。在與 Theo 的一次談話中，他指出了咱們行業中可能成長的另外一個領域：

做爲一個行業，咱們固然須要避免對人性和條件的批評，但也不能迴避對工做產品的批評。咱們須要作到虛懷若谷，拭面容言，從諫如流，切忌諱疾忌醫。混蛋是會有的，應該避開他們。可是，有些人認爲他們寫出來的代碼就像他們的孩子，這種想法應該摒棄。代碼沒有感受，不會發展成複合物，固然也不會表現出最重要的特性（如繁殖能力），也就是你的遺傳品系所攜帶的特性。

另請參閱下面的《無我編程十誡》（The Ten Commandments of Egoless Programming）的第 2 條和第 10 條。

我認爲這是潛規則的必然結果：

當涉及到其餘部門的利益時，在信件、備忘錄等文件的副本上，要注意標註對象。許多惡做劇，都是由年輕人廣播含有害或使人尷尬的言論備忘錄形成的。

固然，對於新手來講，有時候很難識別出這樣一份文檔中的「炸藥」，可是，通常來講，若是它過於冒犯別人，或者暴露了別人的嚴重缺點，就很容易引發麻煩。若是它流傳甚廣，或者涉及到製造或客戶的困難，除非你很是肯定本身的立場，不然最好在它推出以前獲得老闆的批准。

固然，這凸顯了這本書過期的感受，但在現代，我仍然相信主要觀點是正確的。沒有什麼比一條未經深思熟慮的、帶有惡意侮辱的非建設性的推文更能代表你缺少遠見和意識。用 140 個字符來侮辱一項複雜的技術，這是一個初級工程師的錯誤。（譯註：一條推文最多隻能發 140 個字符）

當我遇到這些公開評論時，我固然（就像 Christopher Brown 在 Velocity London 的主題演講中提到的那樣）會注意它們，這樣我就能夠注意到，若是那些人到 Etsy 申請工做，我會從新考慮聘用誰。

成熟的工程師從不迴避做出估計，而且老是試圖在估計方面作得更好。

摘自《工程學的潛規則》：

在有序的企業中，承諾、時間表和估計是必不可少的重要要素。許多工程師並無意識到這一點，或者習慣性地避免做出承諾的煩人責任。你必須根據本身對你所負責的那部分工做的估計做出承諾，同時也要根據各部門對他們所負責的那部分工做的估計做出承諾。不該該容許任何人用舊的公式來回避這個問題。「我不能做出承諾，由於這取決於許多不肯定的因素。」

避免承擔估計責任是另外一種說法，「我尚未準備好去構建基礎設施的關鍵部分。」全部的業務都依賴估計，全部從事項目的工程師都參與到聯合活動中，這意味着他們對他人有責任使本身變得可預測。通常來講，一些非零的不肯定性和風險範圍內對成熟的工程師來講是「溫馨區域」。

成熟的工程師有一種與生俱來的預感，即便他們不知道本身有這種預感。

這段代碼看起來寫得不錯，我爲本身感到驕傲。我已經請其餘人評審了，而且已經聽取了他們的反饋。如今的問題是：這段代碼要多長時間纔會被重寫？一旦投入生產，它的執行將如何影響資源的使用？我指望 CPU/ 內存 / 磁盤 / 網絡增長或減小多少呢？其餘人可以理解這段代碼嗎？我是否應該讓其餘人儘量容易的擴展或者反思這項功能呢？

成熟的工程師明白，並不是全部的項目都充滿了搖滾明星的舞臺工做。

不管你早期的任務看起來多麼瑣碎，多麼微不足道，都要盡你所能去完成。

完成每一件事意味着你要作好你可能不感興趣的事情。不管項目多麼使人興奮或有吸引力，總會有一些無聊的任務、單調乏味的任務、那些不太成熟的工程師可能認爲有損他們尊嚴或職位的任務。個人好朋友 Kellan Elliot-McCrea（Etsy 的首席技術官）對此持這樣的見解：

有時，單調乏味的任務的可取之處在於他們的簡單和成熟，表如今快速完成任務並繼續前進。有時任務之因此單調乏味，是由於他們須要極端的紀律性和可塑的注意廣度（attention span）。這是一個奇怪的現象，最單調乏味的工做，反而只有最資深的工程師才能完成，這也多是最可怕之處。

成熟的工程師會提高周圍人們的技能和專業知識。

他們意識到，在某種程度上，他們的我的貢獻和潛力不能單獨發揮。他們還認識到，一我的可以創造的東西是有限的，世界上最好的工程壯舉是由團隊完成的，而不是才華橫溢、特立獨行的工程師完成的。Tom Limoncelli 在他的 文章《系統管理員何以成爲「高級系統管理員？》（What makes a sysadmin a "senior sysadmin"? ）中很好地闡述了這一點。

在 Etsy，咱們稱之爲「慷慨精神」。慷慨精神是咱們的核心工程價值觀之一，也是咱們員工工程師職位的首要責任，是一個職業級別的職位。這些工程師花時間確保更多不熟悉技術或流程的初級或工程師新手不只瞭解他們在作什麼，並且還要了解他們爲何要這樣作。「授人以漁」是這一級別的必備技能，這須要對組織的其餘部門既有耐心，又要有投資的眼光。

所以，與其說「起開，我來給你作！」，不如說：「好的，讓咱們一塊兒來解決這個問題。我能夠給你看看我是如何寫做 / 故障排除等等。而後，你能夠這樣作，這樣我就能夠確保你知道爲何 / 咱們如何這樣作的，等等。」

成熟的工程師懂得導師制和贊助制之間的區別，並養成後者的習慣。

發現本身工做的知名度正在提升的工程師們認識到，在當地社區（組織內外）施加影響力的基本要素就是發展和保持對機會的認識，以資助周圍的人，讓他們從中受益。科技行業在支持未獲得應有重視和（或）邊緣化羣體方面受到嚴重挑戰，這已經不是什麼祕密了。

養成這種習慣須要付出努力，但好處是多方面的；工程師提升了他們的批判性思惟能力（「哦，咱們在此次會議上討論的內容將是讓 $NAME 爲之工做的最佳機會……」），以及被贊助的工程師獲得機會，不然他們可能就不會。

關於這一話題，Lara Hogan 的文章是必讀之做：《贊助是什麼樣子的？》（What does sponsorship look like?）

當有特權的人開始看到偏見和特權的制度時，他們的第一本能一般是 指導 那些沒有從同一特權中受益的人。這是能夠理解的，他們想要幫助那些被邊緣化的人成長，得到晉升，或成爲更好的工程師，來幫助平衡咱們這個行業廣泛存在的不公平現象。

但從本質上來講，這種指導他人的本能滋長了這樣的一種觀點，那些被邊緣化的人業務不夠熟練，腦子不夠聰明，或者尚未作好承擔更多的責任或領導的準備。

在科技界中，未獲得應有重視的羣體最須要的每每是 機會和知名度，而不是建議。他們必須很是努力地工做，而且很是擅長他們所作的事情，以對抗在咱們工做環境中起做用的系統特權和無心識偏見。儘管這項工做很是出色，但他們在這項工做中，一直沒有獲得充分的提拔，薪水也一直很低。

Lara 接着舉了幾個例子說明這看起來多是什麼樣子的：

這些都是我見過的贊助的真實例子：

· 建議根據他們在這個代碼庫的經驗，肯定一個能夠很好地 領導新項目 的人，解決這類問題，或者根據過去的業績證實，可以按時完成工做。· 建議某人成爲過後調解人，或者成爲另外一種可見會議領導者，在這場會議中其餘人都在學習。· 建議某人能夠爲工程博客撰寫一篇 關於他們最新項目的新博文，解決棘手問題的方法，或者其餘公司能夠借鑑的解決方案。· 建議某人在公司或團隊會議上 發表演講，展現他們的工做。· 將項目的電子郵件摘要轉發給與原始受衆不一樣的人羣，強調爲何它頗有趣，或者你從中學到了什麼。· 詢問某人的經理你是否能夠 分享有關你所目擊的他們傑出工做的反饋。· 在 Slack 中說起或分享 某人的工做，你認爲這些工做有用且有趣。· 向一羣有影響力的人援引你 最近從某人那裏學到的一件有趣的事。

成熟的工程師在做出判斷和決策時，會明確權衡利弊。

他們意識到全部的工程決策、實現和設計都存在於一個範圍內；咱們並非生活在一個二元世界。他們能夠快速指出哪些狀況下一個成功的方法或解決方案可行，哪些狀況下不可行。他們知道一我的不能作到同時既有效率又全面（ETTO 原則），大多數項目工程師所從事的項目都是以 最優化 和 脆弱性 爲軸心的，而且他們所解決的問題是 急性 的或慢性 的。

他們知道他們在理想和非理想的範圍內工做，而且對此沒有意見。他們對此感到很滿意，由於他們努力使設計中的理想和非理想進行明確化。在設計生命週期的後期，當原始設計再也不擴展或須要替換、重寫時，他們將會回顧過去，不是從一個角度來看待那些早期的決定是多麼的短視，而是說，「是的，咱們用它走到了這一步，而且咱們早就知道必須在某個時候對它進行擴展或改變，看來如今是時候了，讓咱們開始吧！」 並不會用偏執的、被動進取 的後見之明和充滿偏見的反事實的評論來回應。（好比，「那些白癡第一次就作得不對！」、「他們在偷工減料！」、「我就告訴過他們這樣行不通的！」等等）

許多精闢的引用都可以說明這種權衡的概念，而成熟的工程師知道任何充滿哲理的引用都是有侷限的（包括我在本文寫的那些）：

• 「過早的優化是萬惡之源。」這是一句被濫用的格言，我 以前 也寫過，由此能夠得出一個推論（可今後文《剖析當今互聯網流量高峯》（Dissecting Today's Internet Traffic Spikes）開始）。「高級工程師和初級工程師的區別在於，前者知道哪些是‘過早’的，哪些不是。」

• 「適合工做的工具」，這是另外一個被濫用的格言。這句話的意圖是合理的：有誰願意使用不合適的工具呢？但有一種罕見的觀點認爲，若是採起極端措施的話，多是有害的。木匠不會用各類各樣的錘子來武裝本身，即便他可能會遇到每一把都能理想地完成錘擊任務的錘子。爲何呢？由於拖着（以及維護）那麼多錘子處處幹活是要付出代價的。所以，在這條軸上做出決策是要進行權衡利弊的。

關於權衡的 要點 就是，每一個人在每一個項目都會偷工減料。不成熟的工程師過後纔會發現，他們對此感到反感。而成熟的工程師在項目開始時就將它們寫出來，接受它們，並將它們視爲優秀工程的一部分。

（相關閱讀：《你的代碼可能很優雅》（Your Code May Be Elegant））

成熟的工程師不會去掩蓋事實。

在這種狀況下，若是有人以禮儀爲藉口而不去了解他的代碼（或基礎設施）如何被系統或業務的其餘部分觸及，那麼這種狀況就是一種失敗的作法。自我保護 傳遞了這麼一個隱含的信息，即你是那種只要你的工做有任何瑕疵的時候就會把別人（多是你團隊裏的，或者你公司裏的，也有多是社區裏的）推下公共汽車的人。而成熟的工程師會勇敢站起來，並接受交給他們的責任。若是他們發現沒有必要的權力來對本身的工做負責，他們會想辦法糾正這個狀況。

掩蓋事實的一個例子就是「這不是個人錯，是他們弄壞了，用錯了。我是按照規格作的，我不能爲他們的錯誤或不合適的規格負責。」

成熟的工程師頗有同理心。

在複雜的項目中，一般有許多利益相關者。在任何項目中，設計師、產品經理、運維工程師、開發人員和業務開發人員都有本身的目標和視角，成熟的工程師會意識到這些目標和視角可能有所不一樣。他們明白這一點，這樣他們就可以有效地駕馭他們所作的工做。從這個意義上來講，同理心意味着有能力從他人的角度來看待這個項目，並在本身的工做中考慮到這一點。

目標衝突是全部工程師工做中都是固有的，抱怨它們（而不是將它們做爲成功的必要條件）是一個不成熟的工程師的標誌。

他們不會空洞地抱怨。

相反，他們會根據經驗證據來表達本身的判斷，並帶着這些判斷選項來解決他們已經肯定的問題。個人一位優秀的經理曾說過，若是沒有至少一個（理想狀況下不止一個）的解決方案建議，就不要向你的老闆抱怨任何事情。即便證實你已經嘗試過本身解決這個問題，但空手而歸，那也比空洞的抱怨要好得多。

成熟的工程師意識到認知誤差。

這並非說每一個成熟的工程師都須要一個心理學學位，但認知偏見會在某種程度上限制工程師的職業發展。即便它們不知道這些偏見是如何出現的，也不知道如何避免這些偏見，但我認識的大多數成熟的工程師都有必定程度的自我意識，至少能認識到他們（像全部人同樣）容易受到這些偏見的影響。

從文化上講，工程師天天都在研究中的經驗證據中工做，基本上就是：給我看數據。認知偏見的問題在於，當咱們用本身的大腦解讀數據時，咱們可能沒有意識到這一點，這些數據有悖於經驗數據，可能對咱們如何完成工做和團隊合做產生意想不到的影響。

關於認知誤差，維基百科 上就有一個很好的列表，但我見過的工程師（包括我本身）就不幸中招：

• 自利性誤差：若是一件事作得不錯，那多是由於我作了什麼或者想到了什麼；若是作壞了，那確定就是別人乾的。

• 基本歸因謬誤：別人從他的工做中獲得的糟糕結果一定與他我的有關（如愚蠢、笨拙、馬虎等等）；而若是我獲得糟糕的結果，那是由於我所處的環境、我所承受的壓力、我所處的狀況等等。

• 後見之明誤差：（聽說這是現代心理學史上研究最多的現象）在發生一次不良事件或負面事件（如一個嚴重的錯誤，一次停機等等）以後，就辯稱：「我一直都知道！」這是一種很是強烈的傾向，以比現實更簡單的方式看待過去。當描述涉及到反事實時，你就能夠看出存在後見之明誤差，好比「他們應該這麼作……」，或者「……他們怎麼會沒看到呢！這也太明顯了吧！」等等。

• 結果誤差：如上所述，這是在一塊兒使人驚訝或者負面事件以後出現的。若是這件事破壞性很大，改正費用昂貴或者很嚴重的話，那麼致使這一事件的決定或行爲就被認爲是很是愚蠢、魯莽或疏忽。這種判斷與事件的嚴重程度成正比。

• 計劃謬誤：（關於在不肯定的狀況下做出估計的觀點，如上所述）預測一個特定項目所需的時間更爲樂觀。

還有不少其餘的認知誤差，我我的對這方面的資料饒有興趣，我能夠爲了解全部的認知誤差而廢寢忘食。若是你有興趣瞭解如何限制本身的效率，我強烈建議閱讀。

無我編程十誡

它很合適，即便年代久遠……我看到它引用自 1971 年寫的《程序開發心理學》（The Psychology of Computer Programming），但實際上我並無在文本上看到過。不管如何，如下是無我編程十誡的內容，能夠在  @wyattdanger 的博客 文章《父親與無我編程十誡》（Dad and the Ten Commandments of Egoless Programming）中找到，這篇博文是從他父親那裏獲得的建議：

1. 人非聖人，孰能無過。理解並接受不完美的本身。 犯錯沒法避免，關鍵是要在錯誤進入生產環境前儘早發現。幸虧除了一小部分須要在 JPL（噴氣推動實驗室）開發火箭制導軟件的程序員外，大部分程序員都不會因錯誤招致生命危險。因此咱們能夠而且應該從錯誤中學習，一笑了之而後向前看。

2. 你和你的代碼是兩回事。 記住，代碼評審的目的是找出問題，問題固然最終必定會被發現。不要由於代碼中被發現問題而對人產生偏見，鬧情緒。

3. 人外有人，天外有天。 三人行必有我師焉。無論你懷揣多少「祕笈」，都不要小覷別人的水平。只要你願意虛心求教，必定會有人教你；當你認爲你不須要的時候，更應該虛心求教。

4. 溝通好再重構。 「修復代碼」和「重寫代碼」之間只有一線之隔。搞清楚其中的區別，並在代碼評審的框架內進行代碼風格的變動，而不是孤軍奮戰。

5. 尊重求教者，並耐心待之。 常常與開發人員打交道的非技術人員幾乎廣泛這樣認爲，這些專業人士充其量不過是一羣自負的人，仍是愛哭的嬌氣包。所以，咱們要用耐心和謙和來消除他們對技術人員的誤解。

6. 世上永恆不變的就是變化。 咱們要作到以風起的日子笑看落花的心態來看待變化。將你的需求、平臺或工具的每一次變動都視做一個新的挑戰，而不是一些須要解決的麻煩。

7. 真正的權威源於知識，而非職位。 知識造就權威，權威帶來尊重，因此若是你想在一個無個人環境中得到尊重，就要先積累知識。

8. 屢敗屢戰，雖敗猶榮。 要明白，有時候你的想法會被否決。即便你是正確的，也不要報復，或者嚷嚷「我早就告訴過你了……」。不要把被推翻的想法看作是犧牲品，也不要把它當成戰敗的哀嚎。

9. 切勿與世隔絕。 不要成爲一個成天在小黑屋寫代碼，只有在買汽水時纔會出來的人。這樣你會失去與外界的聯繫，淡出人們的視線，失去控制。在開放的協做環境裏，你會失去本身的位置。

10. 對「碼」不對人。 要批評的是代碼，而不是批評寫代碼的人。儘量讓評論正面、積極，帶動代碼質量的提高，評論只涉及內部標準、編程規範、性能提高等方面。

新手與專家

如今我通常不太關注知識獲取做爲一個研究課題，但我確實相信，當談論一門學科的進化本質時，很難避開這一課題。一個有趣的細分來自 Stuart Dreyfus 和 Hubert Dreyfus 的一篇名爲《指導性機能習得心理活動的五階段模型》（A Five-Stage Model of the Mental Activities Involved in Directed Skill Acquisition）的論文，該論文闡述了不一樣專業水平的特徵：

• 初學者：

  • 嚴格遵照規則和計劃

  • 不多的情景感知

  • 沒有（或有限的）自由裁決

• 高級初學者：

  • 基於屬性和方面的行動準則，這些準則是平等和獨立的

  • 有限的情景感知

• 合格者：

  • 有意識的審慎規劃

  • 標準化和常規程序

• 精通者：

  • 從總體上而不是從方面來看待問題

  • 感知與正常模式的誤差狀況

  • 使用準則做爲指導，其含義與上下文相關

• 專家：

  • 再也不依賴規則、指導方針或準則

  • 對狀況的直覺掌握

  • 分析方法僅用於新狀況

該論文接着指出：

新手從明確的規則和基於知識的角度進行操做。他們深思熟慮，善於分析，所以他們決定或選擇採起行動的速度較慢。

（這意味着新手深受局部合理性的影響。）

專家從成熟、全面、久經考驗的理解出發，直觀而無需下意識的深思熟慮。這是經驗的做用。他們不會把問題當作一回事，把解決問題的解決方案當作另外一回事，而是採起行動。

（這意味着專家是上下文驅動的。）

我不必定贊同在技能水平之間畫出這樣一條幹線的概念，由於我認爲與上面概述的相比，專業知識還有更多的粒度和方面，但我認爲了解過於簡化的類別仍是有所幫助的。

祕密：成熟的工程師知道人們情緒的重要性（有時是非理性的）。

人們對技術、技術決策和技術方向的見解與關於細節的事實同樣重要（若是不是更重要的話）。成熟的工程師知道這一點，並作出相應的調整。再次強調，同理心能夠幫助你理解團隊中的其餘人對技術決策的感覺，即便它們本身也並不容易表達出爲何會有這種感覺。

人們對軟件、架構或模式的信心在很大程度上會受到過去經驗的影響，並可能會對使用它們產生積極或消極的反應。你之前有沒有用過 mod_perl，發生過不少次神祕故障的那個？這樣你就能理解，即便支持的專業知識和用例徹底不一樣，你也不會對不肯意在另外一家公司使用它而感到驚訝。你只記得這個：mod_perl = 大麻煩，因此在任何上下文中再次使用它時都要當心。

成熟的工程師在使用有負擔的技術時就會理解這種現象，即便這是不合理的。說服一個團隊使用他們不熟悉的工具和模式並非一項簡單的任務。「適合工做的工具」格言還有（有時沒法量化的）溫馨性做爲參數。

「若是你不在意誰獲得榮譽，你就能取得驚人的成就。」

這句話一般被認爲是出自 Harry S. Truman 之口，但看起來它可能首先是由覺得耶穌會牧師以另外一種形式說出來的。不管如何，這是另外一個跡象代表你正在和一個成熟的工程師合做：他們認爲項目的成功遠遠高於他們我的努力而獲得的讚譽。在一個以工程師爲驅動的組織中，讚賞或信任的歸因多是這種機能失調的根源，我認爲這是由於它在很大程度上是無形的。

這種觀念是自由的，一旦被理解並被內化，一個進步和創新思惟的世界就會蓬勃發展，由於工程師並不會過度關注將工做等同於本身職業成功的我的責任。

並不是結束

我如今很幸運能在 Etsy 與許多成熟工程師一塊兒工做，這讓我感到很是榮幸。咱們確實是一個年輕的領域，雖然我認爲，咱們能夠就這個問題從其餘工程領域學到不少東西，但我也認爲咱們也是有優點的。在全球範圍內，Web 與發佈和分享信息的概念密不可分。若是咱們但願將這個領域發展成一個真正的學科，就須要繼續指出「高級」和「成熟」工程師的含義。