工程師不用夠聰明，只要能在困局中把思路想清楚

你有沒有遇過那種平時反應飛快、一眼看穿問題的同事，一旦碰到卡關的難題，整個人就開始語無倫次、東抓一個解法西試一個方案，最後連自己都說不出到底在解決什麼？我見過不少這樣的場景，而且說實話，這種人往往是團隊裡「最聰明」的那一個。這件事本身就很反直覺：為什麼腦袋轉得快的人，反而在真正卡住的時候表現得比別人差？

這其實是软體工程圈裡一個常被忽略的現象。原文作者 Sean Goedecke 觀察到，聰明的工程師習慣靠直覺瞬間看穿問題，一旦遇到那種「不會馬上看出訣竅」的狀況，反而容易慌張。而這個問題甚至不需要多難，只是剛好那次直覺沒有立刻命中而已。真正的差異不在智商，而在於一個人能不能在腦袋沒有靈光一閃的時候，依然穩住陣腳、慢慢往前推。

聰明和「扛得住」是兩件事

作者把工程師分成兩種：「聰明」的工程師和「強」的工程師。聰明的工程師習慣問題被直覺瞬間解開，一旦碰上沒辦法立刻看穿的狀況,就開始手忙腳亂，急著想找回那種靈光一閃的感覺；強的工程師則有一套方法，可以在沒有靈感的情況下,一步一步機械式地往前推進，不靠天賦,靠流程。

這個差異在團隊裡其實很容易觀察。跟一個第一次碰到真正硬骨頭問題的聰明工程師合作，經驗上往往很難受。因為當他們沒有「硬扛下去」的肌肉記憶時，就會忍不住把任何一個看起來勉強成立的方案當成正確答案。於是你會看到一種越來越慌亂的循環：他們指著一個又一個其實不太對的解法，語氣卻愈來愈心虛。這不難理解，畢竟很多聰明工程師的職業自我認同,就是建立在「我一看就懂」這件事上，一旦這個能力失效，等於整個自我形象跟著動搖。

我自己合作過類似的人，那種焦慮感是會傳染的。他們不是不努力，而是缺一套「即使沒有答案也能繼續前進」的方法。這跟聰明與否無關，是完全不同的一種能力。

講白一點，這件事到底在幹嘛？

把這個比喻拉到生活場景會更清楚。想像你在騎車，晴天時你可以憑感覺過彎、憑感覺剎車，速度快也沒問題，因為路況簡單、視野清楚。但下大雨、路面積水、視線模糊的時候呢?靠感覺騎車反而危險，你需要的是放慢速度、一步一步確認路況、確認剎車距離,才能安全通過。

聰明的工程師像是一台只在乾燥賽道上表現優異的賽車:速度極快，但輪胎和剎車系統只在特定條件下才有效,一旦路況變差(問題變得不透明、沒辦法一眼看穿)，這台車反而比一台普通家用車更難操控。強的工程師則像是一台普通汽車,雖然極速不如賽車,但無論是晴天雨天、市區塞車、山路彎道,都能穩穩地開,因為它的系統本來就是為各種路況設計的,不是只為了在單一理想條件下衝到最快。

原文用的正是這個比喻:F1賽車速度快,但你不能把它開進市區車流裡,因為輪胎和剎車根本不是為一般速度設計的。這正是「聰明」和「思路清楚」的差別——聰明是能在高速下想清楚，思路清楚是任何速度下都能想清楚,即使頂速沒那麼快。

抓住不會變的東西:所謂「不變量」

作者在更早一篇文章《Thinking clearly about software》裡提過一個關鍵方法:專注在「不變量」上——也就是你對這個系統,百分之百確定為真的信念。當你卡在一個怪異的情況裡,通常是因為你做的某個假設其實是錯的。如果你能先找出那些「不可能為假」的假設(舉例來說,如果你正在收到某個服務回傳的錯誤訊息,那至少可以確定這個服務有在處理你的請求),你就有了一塊可以站穩的地基,再去逐一檢驗那些不太可靠的假設。

這聽起來很像除錯的基本功,但真正難的地方是,在慌亂的時候要記得回頭去做這件枯燥的事。大部分人在壓力下的本能反應,是想跳過這一步,直接猜答案。

快思考和慢思考,本質是不同的活動

快速思考是把盡可能多的資料塞進腦袋,然後讓直覺一躍而出,直接跳到結論(或者,最糟的情況是先跳出一連串錯誤結論,但你能立刻判斷它們是錯的,直到抓到對的那個)。這種跳躍式思考帶來的滿足感很真實,大腦喜歡這種「啊哈,我懂了」的瞬間。相反地,坐在一堆原始資料前,什麼跳躍都不做,老老實實一條一條看,這種過程令人不舒服。大部分人是討厭做這件事的。

但這正是重點:如果你能逼自己去做一件大家都討厭做的事,通常背後藏著大量沒被開發的價值。思路清楚這件事也是一樣的道理。能在不確定的狀態下依然保持清晰思考的工程師,往往非常有效率,不管他們本身是不是那種能做出驚人直覺跳躍的人。

這篇文章發表後,有讀者留言指出,作者描述的狀態其實很接近濟慈(Keats)提出的概念「negative capability」,意思是「一個人有能力身處不確定、神祕、疑惑之中,而不會急著去抓住某個事實或理由」。這個說法蠻精準地補了一刀:原文說的「慢慢想清楚」,其實就是能忍受不確定,不急著給自己一個假答案來安撫焦慮。

文章後來也被貼上Hacker News討論,引來一些回應。其中一則留言反駁說,解決難題的關鍵不是「慢慢想」,但那位留言者接著描述的內容,其實正是作者所說的「慢思考」在做的事——這種爭論本身也蠻有意思,說明「慢思考」這個詞容易被誤解成單純的速度慢,而不是一種可以持續運作的思考方式。

放到亞洲工程團隊的現場來看

這套觀察放進台灣、香港、新加坡的工程團隊裡,其實特別有感。亞洲的科技產業普遍偏好「快」——快速交付、快速上線、快速解bug,尤其在中小型新創或外包導向的團隊裡,「聰明」常常被當成招募和晉升的唯一指標,面試題目也偏向考驗瞬間反應和演算法直覺。這種文化很容易把「思路清楚但速度普通」的工程師篩掉,因為他們在白板題面試裡不見得表現亮眼。

但真正進入生產環境,面對的往往是龐大、歷史悠久、文件不全的系統——尤其是在銀行、電信、政府數位服務這類長年迭代的產業裡,問題常常不是「這題有沒有巧妙解法」,而是「這個系統到底哪裡壞了,而且沒有人完全搞懂它」。這種時候,能不能耐住性子找出不變量、一步步排除錯誤假設,遠比誰腦筋轉得快更重要。我自己在跟一些東南亞的維運團隊合作時就發現,真正頂尖的資深工程師,往往不是那種面試時秒殺演算法題的人,而是那種在半夜三點系統當機、資料混亂的時候,還能冷靜地一條線一條線去追的人。這種能力目前在亞洲的招募和培訓體系裡,普遍被低估。

慢下來,才是真正的競爭力

如果你正在帶團隊,或者正在觀察自己該往哪個方向成長,這篇文章給的提示其實很直接:別再把「反應快」當成唯一的能力指標。真正能撐起一個系統、撐過一次真正的線上事故的人,往往是那個在沒有靈感、沒有直覺提示的情況下,依然能坐下來,一條一條檢查假設、一步一步往前推的人。

我自己的看法是,這種「慢思考的耐受力」是可以練的,不是天生的性格。方法很土——就是每次卡住的時候,強迫自己先寫下「我現在確定為真的是什麼」,再去檢查那些不確定的部分。不優雅,也不會讓你在面試裡看起來很聰明,但長期下來,這才是讓一個工程師在真正困難的問題面前不崩潰的東西。值得問自己的問題是:當你下一次真的卡住、直覺完全沒反應的時候,你有沒有一套方法,還是只能靠慌張硬撐?