編寫程式碼時我們生產力最低

背景

這篇來自 Codemanship 的文章指出，當工程師埋頭寫程式（Coding）時，往往是生產力最低下的時刻。作者認為真正的價值產出於理解問題、與客戶溝通以及設計方案的過程，而實際在鍵盤上敲擊代碼只是將既定計畫轉化為文字的機械性勞動。此觀點在 Hacker News 引發了熱烈討論，開發者們針對「開發」與「編碼」的本質差異展開了深層辯論。

社群觀點

許多開發者對此觀點表示強烈共鳴，認為編碼本質上只是「打字」。一位資深教育者分享他總是告訴學生，程式開發最困難的部分在於理解與規劃，這些過程幾乎不在鍵盤前發生；如果開發者在打字時感到困惑或反覆打轉，通常代表規劃階段尚未完成。這種觀點將編碼視為思考後的產物，正如一位評論者所言，五分鐘的編碼成果往往背後隱藏著一小時的深度思考。

然而，並非所有人都認同將思考與編碼完全切離。有反對意見指出，計畫往往在接觸現實（即實際編碼）時崩潰，開發是一個不斷迭代的過程。許多工程師透過編碼來探索演算法的不同版本，藉由實作來驗證想法是否可行，這種「邊做邊想」的模式讓編碼成為思考的延伸，而非單純的結果輸出。針對 Vim 等高效編輯工具的爭論也由此而生：有人認為打字速度不重要，因為那只佔開發時間的一小部分；但支持者反駁，流暢的工具能減少大腦與機器間的摩擦，讓開發者在進入「心流」狀態時不被瑣碎的操作中斷，從而維持高層次的思考連貫性。

關於管理層的誤解也是討論焦點。社群普遍認為，非技術背景的管理者往往將代碼產量與生產力掛鉤，這導致了過度工程化與無謂的架構複雜性。一位留言者犀利地指出，AI 生成代碼的興起反而揭露了許多企業級架構的荒謬——那些為了顯得專業而設計的五層架構，本質上是無用的冗餘，只是為了讓開發者顯得聰明或增加諮詢價值。真正的藝術在於用最少的代碼解決問題，因為代碼本質上是一種「負債」而非資產，越精簡的系統通常越健壯且易於維護。

最後，社群提出了一個有趣的類比：軟體開發與木工製作的差異。如果木匠做的椅子毀了，他必須投入同樣的勞力重新製作；但如果工程師的代碼丟失了，只要他已經完成了思考與理解的過程，重建代碼的速度會遠快於初次開發。這說明了開發工作的核心在於「將開發者轉化為具備解決方案知識的人」，而最終產出的代碼僅僅是這個知識轉化過程的副產品。

延伸閱讀

• Claude Code: 留言中提到的 AI 工具，被討論於其在理解遺留代碼與自動除錯方面的潛力。
• E.W. Dijkstra 的名言: 討論中引用了關於「用代碼行數衡量進度如同用重量衡量飛機建造進度」的經典觀點（雖然亦有留言指出此語可能出自比爾蓋茲）。
• Use of Weapons (Iain M. Banks): 留言中提到的科幻小說背景，用以類比物質稀缺性消失後，設計價值將遠超製造價值的概念。