程式設計師的思維修煉：開發認知潛能的九堂課
如喜歡本書，請購買正版。
鐵文整理，轉載請註明。
譯者序
這是一本教你如何對大腦“程式設計”的書！
運用一門程式設計語言程式設計對大多數普通程式設計師來說是“小菜一碟”，那麼如何更上一層樓成為一名專家級的軟體開發者呢？本書給出了答案——優秀的學習能力和思考能力。作者從軟體開發領域的角度，闡述了每一名程式設計師提升“內力”所需要的各種軟性知識：從新手到專家的5個層次、人類大腦的執行機制、直覺和理性的利與弊、學習方法和實踐經驗的重要性、控制注意力的技巧，等等，可謂是一本程式設計師“素質教育”的微型百科全書。我非常支援一個白話版的“素質”定義：除了書本知識、硬性記憶以外的東西，捫心自問，包括我自己在內的大多數程式設計師除了固化的程式設計知識以外，又有多少“素質”拿得出手呢？IT
在翻譯本書時，我切實地感受到，雖然它文字不多、篇幅不大，但卻內容豐富、引經據典，可見作者知識的淵博和寫作的認真。我建議讀者在閱讀本書時，不要急於求成，要仔細地閱讀各個章節，結合自己的日常經驗體會文字背後的含義。對每一節中的“實踐單元”，要立刻應用到日常工作中，觀察和比較實踐的前後效果，找出適合自己的行動指南！
千里之行始於足下。請翻開本書的下一頁，或許可以改變你的一生
對本書的讚譽
本書將推動你擁抱美好未來。
——Patrick Elder，敏捷開發人員
遵循Andy推薦的具體步驟，你能夠使自己最寶貴的財富（大腦）更具效率，更有創造力。請閱讀本書，並按照Andy說的去做。你的思維會比以前更敏捷，工作會更出色，同時也會比以前學到更多。
——Bert Bates, Head First系列書的合著者
我一直在尋覓能夠幫助我提高學習能力的東西，但我還沒找到可以與本書媲美的。本書提供了最好的方法，幫助你成為專家級學習者，提高你的技能，指導你如何通過快速易行的學習提高工作效率。
——Oscar Del Ben,
我喜歡談論與情境相關的書籍。本書就是這樣做的，而且幫助你理解為什麼情境如此重要。從德雷福斯（Dreyfus）模型（讓我頓悟很多事情）到解釋為何體驗性培訓效果顯著（書中的攀巖例子），Andy以其幽默和老練的寫作風格，讓讀者在閱讀中有所收穫，並提高思考和學習的能力。
——Johanna Rothman, 顧問，作家和演說家
我非常喜歡Andy的著作，其內容嚴謹且實用。
——Patricia Benner博士，舊金山加利福尼亞大學社會與行為科學系教授、系主任
昨晚讀完了本書的beta版。我非常喜歡NFJS研討會上的有關討論（賽馬一節），非常希望它能成書，真的太棒了。本書的所有內容實際上改變了我的人生！
——Matt McKnight, 軟體開發人員
這本書太有趣了，我受益匪淺。這對我來說足夠了。
——LindaRising, 國際演說家、顧問和麵向物件領域專家
獻給我的太太和孩子。
獻給那些夢想成真的人。
第1章緒論
歡迎大家！
感謝選擇這本書。我們將共同經歷一次有關認知科學、神經學、學習和行為理論的旅程。你將看到人類大腦令人驚奇的工作機制，並研究如何克服這一系統的侷限來提高自己的學習和思考技能。
我們將開始重構你的“溼件”——對大腦進行“重新設計”和“重新連線”，使你更高效地工作。不論你是程式設計師、管理者、“知識工人”、技術奇人還是思想家，或者你只是想讓你的大腦聰明一點，這本書對你都會有所幫助。
我是一名程式設計師，所以我的例子和言論都離不開軟體開發領域。但是，如果你不是開發人員，也不必擔心，實際上程式設計與使用神祕、深奧的程式語言編寫軟體沒有多大關係（儘管我們總是習慣性地認為它們很相關）。
程式設計其實就是解決問題，它需要發明、創造和靈感。不論你從事什麼職業，可能都需要創造性地去解決問題。然而，對於程式設計師來說，既要受到數字計算機系統的嚴格約束，又要展開豐富而靈活的人類思考，這就會展示二者的強大力量，又會深深地暴露二者的缺陷。
無論你是一名程式設計師，還是一位心灰意冷的使用者，可能都曾認為軟體開發是人類可以想象和遇到的最艱難的工作，它的複雜性耗盡了我們的全部智慧，而一旦失敗則後果是可怕的，且往往極具新聞價值。我們曾經讓宇宙飛船偏離了軌道，撞向遙遠的星球；讓昂貴的火箭爆炸，蒙受無法彌補的實驗損失；給消費者寄去索要零美元的催款信，搞得人家莫名其妙；時不時還讓航空旅客滯留在機場。
適才我們發現：這完全是我們自己的錯誤造成的。我們自身往往增加了程式設計的難度。隨著軟體行業的不斷髮展，我們似乎失去了作為一名軟體開發人員所必需的最基礎、最重要的技能。
不過好在，我們此時此地就能改正這個錯誤。本書將告訴你如何去做。
過去40年中，程式設計師引入到程式中的缺陷的數量已經基本保持不變。儘管程式設計語言、技術、專案方法論等都在不斷改進，但缺陷發生的頻率仍然保持在同一水平，沒能得到改善（引自Bob Binder，基於Capers Jones的研究成果）。
也許這是因為我們一直關注著錯誤的事情。儘管技術上有了很多顯著的改變，但有一樣東西卻始終沒變：我們自己——作為開發人員的人。
軟體並不是在整合開發環境（IDE）或其他工具上設計出來的，它是在我們的大腦中想象和創造出來的。
軟體是在頭腦中建立的。Software is created in your head。
思想和概念是需要在團隊（也包括付錢讓我們開發軟體的人）中分享和交流的。我們已經在改進基礎技術——程式設計語言、工具、方法上花費了很多時間，當然這也是十分必要的，但現在是我們更進一步的時候了。
現在我們需要研究的真正難題是團隊內部和團隊間的交流，甚至更困難的問題是完全陳舊的思想。沒有任何專案是孤島，軟體不可能孤立地建立或者執行。
Frederick Brooks在他的里程碑式的文章《沒有銀彈》[Brk86]中提出：“軟體產品處於應用、使用者、規則和硬體（也就是平臺）的合力之下。這些因素總是在不斷變化，迫使軟體產品也隨之改變。”
Brooks的言論把我們推向了社會漩渦的中心。考慮到社會中各個相關團體的複雜互動影響和社會的持續變化，在我看來當前最重要的兩項技能就是：
□ 溝通能力；
□ 學習和思考能力。
軟體行業正在逐步提高溝通能力。特別是敏捷方法（見註解欄），強調了團隊成員之間、最終客戶和開發團隊之間的溝通交流，類似《演說之禪：職場必知的幻燈片祕技》[Rey08]這樣的大眾圖書突然熱賣，表明越來越多的人意識到簡單、有效的溝通非常重要，這是個好的開始。
不過，提高學習和思考能力要更難一些。
程式設計師需要不斷地學習——不僅僅是學習新技術，還包括應用的問題域、使用者社群的奇思妙想、同事的古怪習慣、行業的八卦新聞和專案演進的重要特徵，我們必須學習學習再學習，持續不斷地學習，然後把學習成果應用到解決日常遇到的一切新舊問題上。
也許，這些聽起來都相當容易，但學習能力、批判性的思考能力和創造力——所有這些擴充套件思維的能力，都取決於你自己。沒有人教你這些東西，你必須自己學習。我們往往錯誤地看待老師和學生的關係：不光是老師在教，學生也要學，學習完全取決於你自己。
我希望本書能夠幫你獲得又快又強的學習能力和更實用的思考能力。
什麼是敏捷方法
“敏捷方法”這個詞最早出現在2001年2月的一次峰會上，與會的17個人都是軟體開發行業領軍人物，他們建立了各種開發方法，如極限程式設計、Scrum、Crystal，當然也包括我們的注重實效的程式設計。
敏捷方法在很多重要的方面都與傳統的基於計劃的方法不同，最顯著的就是擺脫了死板的規則，丟棄了陳舊的日程表，注重實時的反饋。
我在本書中會經常提到敏捷方法，因為很多敏捷思想和實踐都是與良好的認知習慣相融合的。
1.1 再提“實用”
從最初的《程式設計師修煉之道：從小工到專家》[HT00]到現在的Pragmatic系列圖書，你會注意到我們一直在冠以實用（pragmatic）這個詞。實用主義（pragmatism）的本質就是做對你有用的事情。
在開始討論之前，請牢記：每個人都是不同的。雖然我引用的很多研究成果都已經被大部分人所沿用，但也有一些還未廣為使用。我會運用大量不同的材料，既有通過對大腦的功能性核磁共振掃描證實的科學事實，又有一般概念性理論，既有荒誕故事，也有“嘿，Fred做了嘗試，這對他管用”的日常生活中的例子。
在很多情況下，尤其是在討論大腦時，根本的科學依據是未知的或不可知的。但你不必為此擔心：如果某種方法是有效的，那麼它就是實用的，我就會寫入書中，供你思考。我希望這些方法中的大多數對你都有用。
切忌隨波逐流。Only dead fish go with the flow。
不過，總有些人與眾不同，你可能就是其中一員。這也沒關係，不要盲目地聽從任何建議，包括我的建議。你可以用開放的思維來閱讀本書，嘗試執行一些建議，再判斷哪些對你有用。
什麼是溼件
wet·ware | wet，we(e)r | 詞源：wet+software
名詞，諧語。指大腦細胞或思維過程，與計算機系統相對應。
也就是說，利用計算機模型類比人類的思維過程。
隨著不斷成長和適應，人們需要改變自己的習慣和方法。生命中沒有什麼是恆久不變的，只有死魚才隨波逐流，嘗試改變自己，請把本書當作改變的開始。
我將會分享在我的經歷中發現的實用思想和方法，剩下的就看你的了！
1.2 關注情境
萬事萬物都是相互聯絡的：自然界、社會系統、你內心的想法、計算機的邏輯——所有事物構成了一個龐大的相互聯絡的現實世界。沒有什麼事物是孤立存在的，一切都是系統和更大的情境的一部分。
由於現實世界的相關性，小的事物可能會有意想不到的巨大影響。這種不成比例的影響作用是非線性系統的標誌，也許你並未注意到，現實世界毫無疑問是非線性的。
當我們試圖將某個事物單獨挑出來時，我們發現它與宇宙中的其他事物是息息相關的。
——約翰·謬爾（美國作家），1911年，《山間夏日》
在本書中，你會發現一些活動只有不起眼的差異，看不出它們之間能有什麼區別。比如，冥想與大聲說出你的想法，或者在紙上寫一句話與在計算機編輯器中輸入這句話。抽象地講，這些事情應當是完全等價的。
然而，事實並非如此。
這些活動使用了大腦中完全不同的思維路徑，這些思維路徑深受人類思想和思考方式的影響。思想並沒有與大腦或身體的其他部分切斷，它們相互間是密切相連的。這只是一個例子（在本書的後面章節將會討論更多關於大腦的話題），但它有助於說明理解這些相互作用的系統的重要性。
一切都是互相聯絡的。Everything is interconnected。
在《第五項修煉》[Sen90]一書中，Peter Senge推廣了系統思維（systems thinking）這
個詞語，描述了另外一種觀察世界的方法。在系統思維中，人們試圖將一個事物看作幾個系統的連線點，而不是一個獨立的個體。
例如，你可能把一棵樹看作一個單獨、離散的物件，立在地面。但事實上，一棵樹至少是兩個主要系統的連線點：樹葉和空氣的處理迴圈與根和泥土的處理迴圈。樹不是靜止的，也不是孤立的。更有趣的是，幾乎沒有人只是系統的一個觀察者，不論你是否意識到，很可能你就是這個系統的一部分（來源於Heisenberg的測不準原理，更一般性的觀察者效應（obscrver effect）認為人必須通過改變系統來認識它）。
訣竅1：始終關注情境。
將這句話寫下來貼在你的牆上、書桌上、會議室裡、白板上，甚至任何你獨立思考或與他人共同思考的地方。我們將會在本書後面討論這個主題。
1.3 所有人都關注這些技能
在我構思如何寫這本書的時候，我發現很多不同領域的人都在談論這些我感興趣的話題。這些領域包括：
□ MBA和高階管理人員的培訓；
□ 認知科學研究；
□ 學習理論；
□ 護理、衛生保健、航空以及其他行業；
□ 瑜伽和冥想；
□ 程式設計、抽象和問題解決；
□ 人工智慧研究。
有些東西是基礎的、各領域相通的。There's something fundamental here。
當你從以上各個領域發現事物雖有不同的表象卻有著相通之處，這其實是一個訊號。在如此眾多的不同情境下卻擁有類似的思想，那麼必然存在某些根本和重要的東西。
瑜伽和冥想訓練近來相當流行，卻似乎想不出有什麼明確的原因。大約2005年10月前後，我曾經在飛機上看到雜誌上的標題醒目地寫著“公司提供瑜伽和冥想訓練以減少不斷增加的保健成本”。
大公司以前從沒有提供過類似活動，但是醫療費用的急速增長迫使它們去尋找一切解決辦法。很顯然，它們相信瑜伽和冥想的練習者會比普通人擁有更強健的體魄。在本書中，我們更關心這些方法與認知相關的地方，當然如果能獲得全面健康那也是很不錯的收穫。
我也注意到MBA和高階管理人員的很多教程都在提倡各種思考性的、創造性的、直覺性的技能，這些東西都是當前已有的研究成果，不過還沒有普及到奮戰在第一線的員工，包括我們這些知識型工作者。
但是不要擔心，我會在本書中討論這些話題，非MBA也能享受這些成果。
1.4 本書結構
每一次美好的旅程都由一幅地圖開始，我們的地圖就在本節。儘管本書的章節是按順序依次排列的，但這些章節卻是相互關聯的。
畢竟一切事物都是相互聯絡的，但是當你面對一本順序寫成的書時，卻不容易領悟到這個觀點。你也許無法通過書中各章節中無數個“又見”的提示，去體會到這種關聯性，那麼通過本節內容，我希望你能稍微明白一些各主題之間的聯絡。
請記住，以下的主題就是本書的方向，雖然討論中我們還會說些別的話題。
1.4.1 從新手到專家的歷程
在本書的第一部分，我們將研究一下大腦為何如此運轉，一開始就引入一個流行的專業模型。
技能獲取領域的德雷福斯模型（Dreyfus model）是研究如何超越新手層次、如何不斷精通技術的有效方法。我們將會探討德雷福斯模型，並特別關注成為一名專家的關鍵要素：應用你自己的實踐經驗、理解情境和利用直覺。
1.4.2 認識你的大腦
當然，在軟體開發中最重要的工具就是你自己的大腦。我們將會討論一些認知科學和神經系統科學的基本知識，因為它們與軟體開發人員的興趣密切相關，比如把大腦模型可以類比成雙CPU、共享匯流排設計，以及如何對你自己的大腦作“手術”。
1.4.3 正確使用大腦
一旦對大腦有了更深的認識，我們將想方設法提高創造力和問題解決能力，以及更有效地獲取經驗。
我們還將探討直覺從何而來。直覺是專家的基本特徵，事實上難以駕馭。你需要它，依賴它，但或許也莫名其妙地反對經常使用它。你可能總會懷疑自己或其他人的直覺，錯誤地認為它是“非科學的”。
我們將探討如何轉變這種思想，給直覺更大的活動空間。
1.4.4 除錯你的大腦
直覺是非常奇妙的技能，當然直覺出錯時除外。在人類思考中存在著許多“已知的缺陷”：個人認知偏見、時代及同代人的影響、固有的個性，甚至是大腦底層的生物性缺陷。
這些缺陷經常會誤導人們做出錯誤的判斷，甚至走向災難性的深淵。
瞭解這些常見缺陷是消除其影響的第一步。
1.4.5 積極學習
既然我們對大腦的工作方式有了深入瞭解，那麼接著我們開始研究如何利用這個系統，引入有關學習的話題。
請注意，這裡我所說的學習具有廣泛的含義，不僅指對新的技術、程式設計語言之類的學習，也包括對所在團隊的變化、所開發軟體的重要新功能等內容的學習，在當今時代，我們必須不斷地學習。
但是我們絕大部分人並沒有學習過如何去學習，只是憑自我感覺。我將告訴你一些具體的技巧來幫助你改進學習能力。我們將探討做計劃的技能、思維導圖、閱讀技巧（SQ3R），以及教學和寫作的認知重要性。擁有了這些技能後，你將會更快、更容易地吸收新的資訊，獲得更強的洞察力，更好地融會貫通新的知識。
1.4.6 積累經驗
積累經驗是學習和成長的關鍵——實踐出真知。但單純的“實踐”並不是成功的保證，你需要從實踐中學習其中的價值，而一些常見障礙會讓這個過程很艱難。
但你也不要刻意地拼命實踐，過猶不及，我們將研究如何利用反饋、樂趣和失敗來創造更有效的學習環境，關注設定最後期限的危害，並體會如何通過自我引導積累經驗。
1.4.7 控制注意力
控制注意力是此次旅程的關鍵下一步。我將分享一些技巧，幫助你管理需要學習和實踐的大量知識、資訊和見解。我們生活在資訊豐富的時代，而且日常工作很容易搞得你焦頭爛額，你沒有機會推進自己的職業生涯。讓我們共同解決這個問題，加強你的注意力。
我們將研究如何優化你當前的情境，如何更好地處理煩人的打擾，並看一看打擾為何有害。我們還將探討為何需要分散一些注意力，以便更好地聚焦于思維浸泡之中，並以更積極的方式管理你的知識。
1.4.8 超越專家
最後，我們將快速討論一下為何改變自己比想象中的困難，並且我會提供一個你可以立即付諸行動的建議。
我將分享專家之上還有什麼層次，並告訴你如何達到。
現在，請坐下，端起你的可口飲料，讓我們揭開本書的神祕面紗。
1.4.9 實踐單元
在本書中，我會設立一個“實踐單元”，可以讓你加深印象並真正掌握所學內容。這部分會包括練習、實驗或者培養習慣。我使用多選框標記，這樣當你完成一項後，可以畫個勾，就像下面這樣。
□ 認真思考一下你的專案的當前問題。你能指出它所涉及的不同系統嗎？這些系統是在何處互動的？這些互動點是否與你當前的問題相關呢？
□ 找出情境中導致你的問題出現的三個因素。
□ 在你的顯示器周圍的某個地方，貼上一個標籤“關注情境”。
關於插圖
你可能注意到本書中的插圖並不像通常採用Adobe Illustrator或類似軟體製作出來的精緻圖片那樣，這是我故意的。
從Forrest M. Mims的電子書，到敏捷開發人員所鍾愛的小紙片上的設計文件，手繪插圖具有獨特的作用，我們會在本書後面的內容中看到。
1.5 致謝
非常感謝Ellie Hunt向我介紹了德雷福斯模型以及相關的護理方面的知識，幫助修改我不通順的文字，確保了本書的進度，同時打理著我們的公司。編輯的工作通常非常艱苦且不討好，僅僅在前言中表示感謝遠遠不夠。集編輯、母親和管理者的角色於一身，她展示了高超的技巧和極大的耐心。
感謝在Pragmatic Wetware郵件列表中的朋友們及審閱人，包括Bert Bates、Don Gray、Ron Green、Shawn Hartstock、Dierk Koenig、Niclas Nilsson、Paul Oakes、Jared Richardson、Linda Rising、Johanna Rothman、Jeremy Sydik、Steph Thompsont，以及所有分享過他們的想法、經驗和文章的人們。這些經驗的碰撞極其寶貴。
特別感謝June Kim對整本書的眾多貢獻，他告訴了我許多研究線索和他本人學習與思考的經驗，並且他在本書孕育的各個階段均做出了積極反饋。
同樣要特別感謝Patricia Benner博士，她將德雷福斯模型引入到護理行業中，感謝她的支援，允許我引用她的研究成果，還感謝她對學習能力研究的巨大熱情。
感謝Betty Edwards博士，她是開展大腦半球研究的實際應用的急先鋒，感謝她的支援，允許我引用她的研究成果。
感謝Sara Lynn Eastler為本書做索引，感謝Kim Wimpsett為本書校正單詞和語法，感謝Steve Peter為本書做了精美排版。
最後，感謝你購買了本書，並和我一起開始這個旅程。
讓我們的事業沿著正確的方向不斷前進，運用我們的經驗和直覺，創造適合學習的新環境。
第2章從新手到專家的歷程
製造問題的思維方式無法用來解決問題。
——阿爾伯特·愛因斯坦
難道你不想成為專家嗎？不想憑直覺就知道問題的正確答案嗎？這是我們一起探索旅程的第一步。在本章中，我們將看一看什麼是新手，什麼是專家，以及從新手變成專家需要經歷的各個階段。讓我們出發吧。
從前，有兩名研究人員（兄弟倆）想要推動人工智慧的技術發展水平，準備編寫一個能夠像人類一樣學習和獲取技能的軟體（或者證明這根本不可行）。為了實現這個目標，他們首先得研究人類是如何學習的。
他們提出了德雷福斯技能獲取模型（出自Mind Over Machine: The Power of Human Intuition and Expertise in the Era cf the Computer[DD86]），概括了從新手到專家必須經歷的5個階段。這個模型已經被證實是行之有效的，接下來我們將深入探討它。
讓我們回到20世紀80年代初，當時美國的護理專業人員使用德雷福斯模型糾正她們的工作方法，幫助她們提高專業技能。那時，護士們面對的問題與我們如今在軟體開發領域面對的許多問題都是相同的，她們現在已經取得了巨大的進步，而我們還要繼續努力。
事件理論與構建理論
德雷福斯模型是所謂的構建理論。理論分兩種：事件理論和構建理論（參見 Tools of Critical Thinking：Metathoughts for Psychology[Lev97]）。這兩種理論都用於解釋我們觀察到的現象。
事件理論可以被測量，這類理論可以被驗證或證明，你能夠判斷某個事件理論的準確性。
構建理論是無形的抽象，無法被證明。構建理論是通過它的用處來衡量的。你無法判斷某個構建理論準確與否。它是客觀存在和抽象的結合體。就像蘋果是存在的，蘋果是事物，存在則是抽象。
例如，我可以使用簡單的電流或者複雜的醫學成像裝置來證明大腦的所有部件，但是我無法證明你有思維，思維是一種抽象，事實上沒有這種客觀事物，只是一種概念，但是它是一種非常有用的概念。
Dreyfus模型是一種構建理論，是一種抽象。我們隨後將看到，它非常有用。
下面列舉了一些人們觀察到的現象，適用於護理和軟體開發，也可能適用於其他行業。
□ 實際工作中，專家級職員並不總被認為是專家，也沒有拿到相稱的薪水。
□ 不是所有專家級職員都想成為管理者。
□ 職員的能力存在巨大的差異。
□ 管理者的能力存在巨大的差異。
□ 任何團隊的成員在技術水平上可能各不相同，無法看作一個同質的可替代資源集合。
除了更好、更聰明、更快，技術水平還有更多的內涵。德雷福斯模型描述了我們的能力、態度、素質和視角在不同的技術水平下是如何變化的，以及為什麼會有變化。
這有助於解釋為什麼過去許多改進軟體開發的辦法會失敗。德雷福斯模型建議我們採取一系列行動，切實改進軟體開發行為——無論是為了個人還是為了整個行業。
下面讓我們來看一看。
2.1 新手與專家
你如何稱呼一名專家級軟體開發人員呢？巫師。當我們遇到魔數，十六進位制資料、殭屍程序和複雜的指令（比如tar -xzvf plugh.tgz或者sudo gem install --include-dependencies rails）時，他就會出現。
有了他，我們甚至可以轉換成其他使用者身份，或者切換到root使用者——Unix世界最高權力的化身（見圖2-1）。巫師們處理這些棘手的事情看起來易如反掌。眯起雙眼，指尖一縷塵埃，口唸咒語，“噗”的一聲，一切問題解決了。雖然帶有神祕的色彩，但是我們印象中特定領域的專家都是這種形象（他們是如此地神祕，帶給我們的印象是如此地深刻）。
圖2-1 Unix巫師（略）
使工作看起來很輕鬆
曾經有一次，我有機會面試專業的風琴演奏者。對於試音環節，我選擇了法國作曲家Charies-Marie Widor的Toccata片段（出自第5交響樂F小調，第42曲第一章），節奏非常快，我比較業餘，感覺這節比較難。
一位候選者演奏得很好——兩腳踏板，飛快轉動，雙手躍動，十指模糊，雙眉緊鎖，嚴肅專注。最後，她滿頭大汗。演奏太出色了，我被打動了。
但是隨後真正的專家出現了。她彈得更好一些，更快一些，在她的雙手和雙腳靈活地演奏時，她一直微笑著與我們交談。
她使演奏看起來很輕鬆，最終她得到了這價工作。
例如就專家級大廚來說，他們徜徉於麵粉和香料的繚繞之中，不必關心越堆越高的髒盤子（這些都留給實習生清洗），大廚只要努力琢磨、清楚表達如何做好這道菜。“來一點這個，那個少點——不要太多，然後開始烹飪直到完成。”
廚師長克勞德這樣說不是故意賣關子，他知道“烹飪直到完成”的含義。他知道“剛好夠”和“太多”之間的細微區別依賴於溼度、肉的來源以及蔬菜的新鮮程度。
專家通常很難把他們的行為恰如其分地解釋清楚，他們的很多行為是如此地熟練以至於已經變成無意識的了。他們的大量經驗都是通過大腦的非語言、無意識區域儲存的，這讓我們難以觀察，而專家則難以表述。
清晰表達專業技能十分困難。It's hard to articulate expertise。
當專家在做事時，我們其他人覺得十分神奇。神祕的魔法看起來似乎無處可尋，當我們甚至還不完全認識問題的時候，專家就已經憑藉一種不可思議的能力知道了正確的答案。
當然，這不是魔法，只是他們認識世界的方式、解決問題的方法、運用的思維模型等都和普通人顯著不同。
而一個新廚師在辛苦工作一天回到家裡後，可能不會關心溼度和原料方面的細微差別。他只想知道食譜中到底需要放入多少藏紅花（不僅僅只考慮藏紅花特別昂貴這個因素）。
他想知道的是，如果已知肉的重量，如何精確設定烤肉箱的定時器時間，等等。這並不是說他迂腐或者愚蠢，只是他需要明確的、與情境無關的指令，便於參照執行。而如果專家被強制遵從那些規則操作，他們的工作就會變得效率低下。
新手和專家有著根本區別，他們看待世界的方式不同，反應也不同。讓我們看看細節。
2.2 德雷福斯模型的5個階段
早在20世紀70年代，德雷福斯兄弟（休伯恃和斯圖爾特）就開始研究人類如何獲取和掌握技能。
德雷福斯模型針對每項技能。Dreyfus is applicable per skill。
德雷福斯兄弟考察了行業技術能手，包括商用客機飛行員和世界著名國際象棋大師（出自From Novice to Expert: Excellence and Power in Clinical Nursing Practice [Ben01]）。他們的研究表明，從新手到專家要經歷巨大的變化。在這個過程中，人們不只是“知道更多”或者獲得了技術，而且還在如何認識世界，如何解決問題以及如何形成使用的思維模型等方面體驗到根本性的區別。人們獲取新技術的方式發生了變化，影響（促進或阻礙）人們工作業績的外部因素也發生了變化。
不同於對整個人進行劃分的其他模型或評估體系，德雷福斯模型具體針對每項技能。換言之，這是一個情境模型，而不是個性或能力模型。
對於所有的事情，你既不是“專家”也不是“新手”，你只是處於某個特定技能領域中的某個水平階段，雖然你可能只是烹飪新手，但卻可能是跳傘專家。大多數非殘障成人在直立行走方面都是專家——無需計劃或者思考。這已經變成了本能。大多數人在稅務規劃方面都是新手。如果提供足夠多的明確指令，我們就能夠完成它，但是事實上我們不知道那是怎麼回事（不明白為什麼這些規則如此神奇）。
讓我們來看一看從新手到專家所經歷的5個階段。
2.2.1 階段1：新手
由定義可知，新手在該技能領域經驗很少或者根本沒有經驗。這裡提到的經驗，指的是通過實施這項技術促進了思維的改變。舉個反例，可能一個開發人員聲稱擁有十年的經驗，但實際上只是一年的經驗重複了九次，那麼這就不算是經驗。
新手非常在乎他們能否成功。沒有太多經驗指導他們，他們不知道自己的行為是對是錯。新手不是特別想要學習，他們只是想實現一個立竿見影的目標。他們不知道如何應付錯誤，所以出錯的時候，他們非常容易慌亂。
但是，如果給新手提供與情境無關的規則去參照，他們就會變得能幹起來。也就是說，需要這種形式的規則：“當X發生時，執行Y。”換言之，需要一份指令清單。
圖2-2 玉米餅食譜，不過你知道需要烹飪多長時間嗎（略）
這就是呼叫中心的工作原理。你可以僱用一大批對當前技術沒有很多經驗的人，然後讓他們按照一個決策樹按部就班地執行下去。
新手需要指令清單。Nevices need recipes。
一個大型計算機硬體公司可能使用下面這樣的規則列表。
1. 詢問使用者計算機是否接上了電源。
2. 如果是，詢問是否已供電。
3. 如果否，請使用者接電源，然後等待。
4. ……
類似於上面這種乏味卻固定的規則可以衡量新手的能力。當然，新手所面臨的問題是，對於某種情境，不知道哪條規則是最相關的。當一些意想不到的事情發生時，他們就會不知所措。
和大多數人一樣，我對於納稅申報一直知之甚少。我沒有太多經驗，儘管我已經填寫申報檔案超過25年了，我還是沒有學到任何東西，也沒有改變思維方式。我也不想學習，我只想實現目標——處理完今年的稅務問題。我不知道如何面對錯誤。當國稅局給我寄來簡短且冷冰冰的表格時，我通常不知道表中各專案是什麼意思，也不知道怎麼處理它（我總是希望把它和一張支票交給我的會計師來處理，他才是這方面的行家）。
當然，總有解決辦法。可以求助於一個與情境無關的規則！類似於下面列出的步驟。
填寫你去年賺的金額。
□ 寄給政府。
□ 簡單而清楚。
指令清單（包含情境無關的規則）的問題在於你不能一五一十地將所有事情解釋清楚。例如，玉米餅食譜中提到烹飪“大約20分鐘”，那麼我什麼時候需要延長或者縮短時間？我如何知道已經做好了？你可以設立更多的規則去解釋，然後再用更多的規則去解釋剛設立的規則，沒有一個實際的界限約定你需要說得多明白。這種現象被稱為無限遞迴（infinite regression）。因此，你必須明確中止反覆解釋。
規則只能讓你啟程，不會讓你走得更遠。
2.2.2 階段2：高階新手
一旦經過新手的歷練，人們開始以高階新手的角度看待問題。高階新手能夠開始多多少少地擺脫固定的規則。他們可以獨自嘗試任務，但仍難以解決問題。
他們想要快速獲取資訊。例如，當學習一門新語言或API時，你可能會感覺到這點，你發現自己會快速瀏覽文件以尋找一個方法定義或引數列表。你不想在此刻尋根究底，或者重新溫習一遍基礎知識。
高階新手能夠根據過去的經驗，逐步在正確的情境中採納建議，但比較吃力。同時，他們能夠開始形成一些總體原則，但不是“全貌”。他們沒有全面的理解，而且的確不想有。如果你試圖把一個更大的情境強加給高階新手，他們可能會認為該情境與那些原則不相關而忽略掉。
高階新手不想要全域性思維。Advanced beginners don't want the big picture。
當公司CEO舉行全體會議並展示銷售預測圖表和資料時，你可能會看到這樣的反應。許多在這方面經驗較少的員工對這些會不加理會，以為這與他們自己的工作不相關。
當然，其實這是非常相關的，它可以幫助你判斷明年你在這家公司是否還能繼續幹下去。但是，你看不到這種聯絡，因為你層次還不夠，只處於較低的技能水平。
2.2.3 階段3：勝任者
在第三階段，從業者現在能夠建立問題域的概念模型，並有效地使用它們。他們可以獨立解決自己遇到的問題，並開始考慮如何解決新的問題——那些他們之前沒有遇到的問題。他們開始尋求和運用專家的意見，並有效利用。
與更高水平者追隨下意識反應不同，勝任者會探尋和解決問題，他們的工作更多是基於謹慎的計劃和過去的經驗。如果沒有更多的經驗，在解決問題時，他們將難以確定關注哪些細節。
勝任者能夠解決問題。Competents can troubleshoot。
你可能會看到，處於這一水平的人通常被認為有“主動性”和“足智多謀”。他們往往在團隊中發揮領導作用（無論是否有正式的頭銜）（參見Teaching and Learning Generic Skills for the Workplace [SMLR90]）。他們是團隊裡的好人，既可以指導新手，也不會經常騷擾專家。
在軟體開發領域，我們達到了這個水平，但是即便在這一水平，人們仍然無法按照我們希望的方式來應用敏捷方法——大家還沒有足夠的能力反思和自我糾正。為此，我們需要取得突破，達到一個新的水平：精通。
2.2.4 階段4：精通者
精通水平的從業者需要全域性思維。他們將圍繞這個技術，尋找並想了解更大的概念框架。對於過於簡單化的資訊，他們會非常沮喪。
例如，處於精通階段的人撥打計算機的技術支援熱線電話，被詢問是否插上了電源的時候，不會作出良好反應。（比如我在這種情況下就會想順著電話線摸到那一頭，狠狠地懲罰那個說話的人。）
精通這能夠自我糾正。Proficient practitioners can self-correct。
但是，在德雷福斯模型中，處於精通水平的從業人員有一項重大突破：他們能夠糾正以往不好的工作表現。他們會反思以前是如何做的，並修改其做法，期望下一次表現得更好。到這個階段，自我改進才會出現。
同時，他們會學習他人的經驗。作為精通者，他能夠閱讀案例研究，傾聽有關失敗專案的流言蜚語，觀察別人怎麼做，從故事中認真學習，即使他沒有親自參與。
伴隨向他人學習的能力而來的，是理解和運用格言經驗之談（maxim）的能力，這些經驗之談猶如諺言或格言，是可以應用於當前情境的基本原理（參見Personal Knowledge [Pol5S]）。經驗之談不是指令清單，它們必須在一定的情境下使用。
務實的祕訣
當Dave Thomas和我剛開始寫《程式設計師修煉之道》時，我們試圖傳達給讀者一些與我們的專業最相關的建議。
這些訣竅（經獫之談）凝結了我們多年來的專業經驗。從每年自我拓展學習一門新語言到“不要重複自己”和“不要打碎窗戶”的原則，類似的經驗之談是傳授專業技能的關鍵。
舉例來說，一個眾所周知的極限程式設計方法的經驗之談是“測試一切可能出錯的東西”。
對於新手來說，這只是一個指令清單。測試什麼？是所有的setter和getter方法，還只是列印語句？他們最終會測試所有無關的東西。
但是，處於精通水平的人員知道什麼地方有可能出錯，或者更確切地說，什麼地方非常有可能出錯。他們具有經驗和判斷力，能夠理解這句格言在情境中意味著什麼。事實證明，理解情境是成為專家的關鍵。
精通者有足夠的經驗，他們知道下一步會發生什麼，如果沒有發生又需要改變什麼。他們非常明確哪些計劃需要取消，而應該採取什麼行動。
同樣，處於精通水平的人可以有效地運用軟體模式（《設計模式：可複用面向物件的軟體》[GHJV95]一書提出的），但是這不是較低技能水平所必須掌握的。
現在我們已經到達了一個層次。精通者可以充分利用思考和反饋，這些都是敏捷方法的核心。相對早期階段，這是一次巨大的飛躍。處於精通階段的人更像是初級專家，而不是高階勝任者。
誤用的模式和脆弱的方法
現在你可能認識到，軟體開發領域的一些最激動人心的新動向是面向處於精通和專家級水平的開發人員的。
敏捷開發依賴反饋。事實上，我在《高效程式設計師的45個習慣》中對敏捷開發的定義是：敏捷開發就是在一個高度協作的環境中，不斷地使用反饋進行自我調整和完善。但是基於以往表現進行自我叫正，只在較高的技能水平上才能實現。
高階新手和勝任者經常會把指令清單和軟體設計模式混淆，有時這會導致災難性的後果。就我知道曾經有一位開發人員剛看了GoF的書，並熱情地想開始使用設計模式。所有模式，一次用盡，在一小段平凡的程式碼裡。
他設法把23個設計模式中的17個用在他那段不幸的程式碼片斷中，終於被人發現。
2.2.5 階段5：專家
終於，我們來到了第5個也是最後一個階段：專家。
專家是各個領域知識和資訊的主要來源。他們總是不斷地尋找更好的方法和方式去做事。他們有豐富的經驗，可以在恰當的情境中選取和應用這些經驗，他們著書、寫文章、做巡迴演講。他們是當代的巫師。
根據統計，專家的數量很少，大概佔總人數的1%~5%（參見Standards for Online Communication [HS97]）。
專家憑直接工作。Experts work from intuition。
專家根據直覺工作，而不需要理由。這帶來一些非常有趣的影響，並提出了一些重大問題——到底什麼是直覺？（在整本書中，我們會深入詳細地探討直覺）。
雖然專家們非常有直覺——這一點對我們其他人來說非常神奇，他們可能會對如何得到結論完全說不清楚。他們的確不知道，只是“覺得是正確的”。
例如，醫生給病人看病，乍一看，醫生說：“我認為，這病人得了Blosen-Platt綜合症，最好做一些深入檢査。”病人做了檢查，結果證明醫生是正確的。嗯，你可能要問，醫生是怎麼知道的？但醫生很可能會回答：“他看上去不太舒服。”
事實上，病人只是看起來“不太舒服”。不知怎的，在醫生大腦裡面的各種各樣的經驗，判斷、記憶，以及所有其他的意識的幫助下，醫生把病人身上的微妙線索結合在一起，就得出了診斷結論。也許，只是因為病人面板蒼白，或是病人躺下時的姿勢說明了問題，誰知道呢？
不過，這位專家知道。專家知道哪些是無關緊要的細節，哪些是非常重要的細節。也許不是有意識的，但是專家知道應該關注哪些細節，可以放心地忽略哪些細節。專家非常擅長做有針對性的特徵匹配。
2.3 現實中的德雷福斯模型：賽馬和賽羊
現在，讓我們仔細研究一下德雷福斯模型，看看如何在現實中應用這個模型。至少在軟體開發領域，我們應用得非常糟糕。
專家們並非完人。他們會像其他任何人一樣犯錯誤，會有同樣的認知偏見和其他種種偏見（我們會在第5章中看到），同一領域的專家之間也會有意見分歧。
但是更糟糕的是，誤解德雷福斯模型會埋沒專家的專業技能。事實上，專家的名聲和業績很容易遭到破壞。最後你只是在強迫他們遵循規則。
不知道自己不知道
當你在某領域不是很擅長時，你更可能認為自己是這方面的專家。
在文章“Unskilled and Unaware of It: How Difficulties in Recognizing One's Own Incompetence Lead to Inflated Self-Assessmentsfr”[KD99]中，心理學家Kruger和Dunning講述了一個自以為是的小諭，他在光天化日之下搶劫銀行。他不相信自已這麼快就被捕了，因為他以為在瞼上塗滿檸檬汁，攝像頭就監視不到他。
“檸檬汁人”從來沒有懷疑他自己的假設。缺少準確的自我評估被稱為二階不勝任（second-order incompetence），也就是說，不知道自己不知道。
這種情況在軟體開發領域是個大問題，因為很多程式設計師和經理都意識不到有更好的方法和實踐存在。我已經見過很多年輕的程式設計師（1〜5年經驗）從來沒有做過一個成功的專案。他們已經徹底繳械投降了，認為平常的專案就應該是痛苦和失敗的。
達爾文說過：“無知往往來自於自信而不是知識。”
反過來似乎也是對的。一旦你真的成為了一名專家，你會痛苦地意識到你知道的是多麼少。
在德雷福斯的一項研究中，研究人員就是這樣做的。他們邀請經驗豐富的飛行員做實驗，請他們給新手製定一套規則，要求代表他們的最佳實踐做法。他們照做了，新手基於這些規則的確能夠提高自己的業績。
規則斷送專家。Rules ruin experts。
然後，研究人員要求專家遵循自己制定的規則。
結果專家的表現明顯不如以往（引自The Scope, Limits, and Training implicatiom of Three Models of Aircraft Pilot Emergency Response Behavior[DD79]）。
這對軟體的開發也會產生影響。考慮一下，任何對開發指定嚴格規則的方法或企業文化，會對團隊裡的專家產生什麼影響呢？這將拖累其業績表現下降到新手的水平。公司失去了他們所擅長的所有競爭優勢。
但是，整個行業一直在試圖通過這種方式“毀滅”專家。你可能會說，我們正試圖訓練賽馬。但這不是獲得良好的投資回報的辦法，你需要讓賽馬自己去跑（當然是指純種良馬，而不是野馬）。
直覺是專家的工具，但公司往往輕視它，因為他們錯誤地認為，直覺“不科學”或者“不可重複”。因此，我們往往本末倒置，不傾聽薪酬高昂的專家們的意見。
相反，我們也往往喜歡使用新手，把他們扔在發展水平等級的最底層，讓他們覺得未來遙不可及。在這種情況下你可能會說，我們正在試圖賽羊。同樣，這不是一個使用新手的有效方法。他們需要“被駕馭”，也就是說，明確方向，快速成功，等等。敏捷開發是非常有效的工具，但它不適用於一個完全由新手和高階新手組成的團隊。
怠工
在某些行業或者情況下，如果不容許全面罷工，那麼放緩工作通常是一種示威的手段。
這通常被稱為消極怠工或者惡意服從，也就是說，員工只做他們工作範圍內的事情——不多也不少，嚴格按照規矩辦事。
其結果是大量的延誤和混亂，還有有效的勞工示威。沒有一個具有專門技能的人在現實世界中完全按照規矩做事，這樣做顯然效率低下。
根振Benner（在 From Novice to Expert: Excellence and Power in Clinical Nursing Practice[Ben01]中）提到的：“實踐無法被完全客觀化或者正說化，因為它們必須在特定關係和特定時間中完成。”
但是，來自企業的壓力從兩個方面阻礙了我們。被誤導了的政策公平思維要求我們同等對待所有開發人員，不論能力大小。這傷害了新手和專家（因為忽視了這樣一個事實：根據不同的研究成果，開發人員之間存在20:1～40:1的生產力差異）（在1968年，根據Exploratory Experimental Studies Comparing Online and Offline [Sac63]，當時的程式設計師生產力差異已經達到了10:1。自那時起，這種差距不斷擴大）。
訣竅2：新手使用規則，專家使用直覺。
當然，從新手到專家的過程涉及的不僅僅是規則和直覺。在你提升技能水平的過程中，有許多方面會發生改變。最重要的三個變化（出自From Novice to Expert: Excellence and Power in Clinical Nursing Practice [Ben01]）如下。
□ 從依賴規則向依賴直覺轉變。
□ 觀念的改變，問題已不再是一個相關度等同的所有單元的集合體，而是一個完整和獨特的整體，其中只有某些單元是相關的。
□ 最後，從問題的旁觀者轉變為問題涉及的系統本身的一部分。
這是從新手到專家的轉變，脫離獨立和絕對化的規則，進入直覺的境界並（記得系統思考嗎？）最終成為系統本身的一部分（參見圖2-3）。
圖2-3 技能獲取的德雷福斯模型
技能分佈的糟糕事實
現在，你可能認為絕大多數人都處於中等位置——德雷福斯模型符合標準分佈，典型的鐘形曲線。
其實不是。
可悲的是，研究似乎表明，大多數人的大多數技能，在他們生命的大多數時間裡，從來沒有高於第二階段高階新手，“執行他們需要做的任務並根據需求學習新任務，但是從來沒有對任務環境獲得更廣泛的、概念上的理解。”（出自Standards for Online Communication [HS97]）更準確的分佈參見圖2-4。
圖2-4 技能分佈
大多數人都是高階新手。Most people are advanced beginners。
這種現象的證據比比皆是，從複製-貼上式程式設計的興起（現在把Google作為IDE的一部分），到設計模式的普遍誤用。
此外，元認知（metacognitive）能力，或者自我認知的能力，往往在較高的技能層次中才會具有。不幸的是，這意味著處於較低技能層次的從業者會明顯高估他們自己的能力——有研究表明高出50%。根據一項研究（見Unskilled and Unaware of It: How Diffic