原章：The Hardest Problem
Safari 推出後，Ken 一度因管理職調整感到失落，甚至考慮離開 Apple 去 Google。這時 Scott Forstall 給他一個新挑戰：利用 WebKit 讓 Mac Mail 可以直接編輯以 HTML 組成的「豐富郵件」。Ken 成為這項工作的 DRI（直接負責人）。
表面上，任務只是把瀏覽網頁的技術變成可以編輯網頁內容的技術；真正做下去後，一個看似最普通的介面元素——閃爍的插入點——卻成為 Ken 職涯中最難解的程式問題。
Ken 很快做出初步插入點 Demo，但接下來近一年，他一直遭遇難以穩定重現的錯誤：插入點會消失、卡住、跳過字元或突然移到奇怪位置。Ken 花了大量時間理解 HTML 與資料結構，以為只要把底層資料想得更清楚，問題就會解開。
最後他承認自己卡住了，向 Don Melton 求助。Don 建議他找 Darin Adler 與 Trey Matteson。Ken 在白板上完整說明問題後，兩人約半小時就指出核心：Ken 太專注資料結構，卻沒有一個權威的程式元件對「使用者最後應該看到什麼」負責。
| 故事節點 | Ken 原本的思路 | 同事看到的問題 | 轉折 |
|---|---|---|---|
| HTML 編輯 | 深入理解資料與標記結構 | 技術細節愈多，視覺結果反而愈難保證 | 把使用者可見結果重新放到中心 |
| 插入點錯誤 | 到處加特殊案例與修補程式 | 沒有單一元件真正擁有完整行為 | 整理成更一致的 VisiblePosition 架構 |
| 向同事求助 | 長期自己解題 | 新視角快速看見結構問題 | 承認卡住成為真正進展的起點 |
| 後續合作 | 原本只是一次求救 | Ken 持續用程式修改與 Demo 回應建議 | Darin 與 Trey 也逐漸對成果產生共同投入 |
工程文化很容易獎勵「自己把難題解掉」的英雄敘事。Ken 也承認，如果更早被指出問題，他可能因自尊而防衛；直到真的無路可走，他才完全打開自己接受批評。
所以這章的核心不是某個 C++ 技巧，而是：能力很強的人，什麼時候願意承認自己的視角已經變成限制？
Ken 不只照同事建議整理程式碼，還在後續 code review、Demo 與午餐對話中持續讓 Darin、Trey 看見建議如何改變結果。這使他們不再只是「給過一次建議的人」，而逐漸變成共同關心問題的人。
插入點問題開始穩定改善，WebKit 編輯功能最終成功出貨。Ken 回頭看時得到的結論非常直接：People matter more than programming。 他幾乎寫了所有真正出貨的程式碼，但仍認為不能把成功說成一個人的作品。
最困難的技術問題也可能同時是社會問題。信任、求助方式、回饋氣氛與人際歷史，都會決定專業知識能不能真正流動。