原章：The Black Slab
決定採用 Konqueror 後，真正困難的工作才開始。原始程式不是為 Mac 寫的，團隊必須把大量程式碼、編譯錯誤、平台差異與授權限制一點一點處理掉。這不是能靠一個漂亮 Demo 掩蓋的階段，而是大量枯燥、重複、需要耐性的工程工作。
Ken 比較過規模後，Konqueror 與瀏覽器相關的程式碼遠小於 Mozilla，但「比較小」不代表「很小」。團隊仍預期要花約兩個月才能真正把它帶到 Mac。
他們採用很務實的移植方式：讓編譯器一次暴露一批問題，修完再跑，暫時無法處理的地方就留下 FIXME 標記。很多天過去，外觀看不出任何成果。
直到某天，他們嘗試載入 Yahoo。畫面沒有正常網頁，也沒有漂亮排版，只出現一個黑色長方形。對任何旁觀者而言，這幾乎像失敗；但 Ken 把它形容成重要的「Black Slab Encounter」——因為這表示資料、版面與繪製鏈路終於有一部分真的接上了。
| 故事節點 | 表面看起來 | 實際代表 | 對工作的影響 |
|---|---|---|---|
| 長時間移植 | 沒有可展示產品 | 大量底層相依正在被逐一處理 | 勤勉與工藝比新奇點子更重要 |
| FIXME 標記 | 像在留下未完成工作 | 把未知與欠債明確標記 | 允許先前進，再回頭補足 |
| Yahoo 黑色方塊 | 不是一個可用瀏覽器 | 第一次看見核心路徑真的工作 | 團隊獲得技術與心理上的方向感 |
| 之後的節奏 | 仍有大量細節要完成 | 但團隊知道每次進展都能往可見結果靠近 | 不再讓數週工作完全沒有外部可見證據 |
大部分真正困難的產品工作，在最初很長一段時間都不會產生「令人驚艷」的畫面。這會造成一個管理與心理問題：團隊怎麼知道自己不是只是在更深地挖一個洞？
Ken 把黑色方塊當成一個轉折。之後他更重視建立可見的中間成果，而不是讓工程工作長時間停留在只有程式碼作者才理解的狀態。
作者也把這一章連到 Thomas Edison 的故事：發明不是等待靈光，而是大量試錯、細節與持續工作。即使偶爾有 Eureka 時刻，前面仍然堆著大量看似平凡的苦工。
瀏覽器當然離 Safari 還很遠，但從這個小小的可視成果開始，團隊可以更有節奏地把後續工作變成一連串可檢查、可修正的前進。
真正的進展不一定長得像「大成果」。有時一個很醜、很小、只有團隊自己知道價值的訊號，正是讓所有後續工作從抽象變成實在的第一步。