我們生產力最低的時候，就是在寫程式（coding） https://codemanship.wordpress.com/2026/01/30/coding-is-when-were-least-productive/
文章主張，在「AI 時代」又浮現一個老迷思：把生產力等同於程式碼產量。作者以自己早年接案經驗說明「程式碼的價值不等於數量」：他在協助大型零售商升級 POS（Point Of Sale，銷售點系統）時卡在某個需求情境，原因是從未看過既有系統實際怎麼被店員使用。於是他直接走到分店出示識別證，請求旁聽流程；對方甚至帶他到樓上用於教育訓練與測試更新的「模型辦公室（model office）」實機演練。理解一打通，他回到辦公室只改了約三行程式碼，卻避免促銷折扣被套用錯誤，進一步可能替全國 250 家分店省下金錢與形象成本；若用「改了多少行」衡量，那天反而會被當成不夠努力。
這段經驗讓作者早早體會：有些程式碼值上百萬英鎊，有些一大坨卻一文不值；因此「寫程式」與「創造淨價值」不是同一件事。他甚至把 coding 視為一種「中斷」：你埋頭在 IntelliJ（JetBrains 的 IDE，整合式開發環境）敲鍵盤時，看不到現場、問不到人、也學不到問題本質，而且 IDE 並沒有任何快捷鍵能告訴你「正在寫錯的程式碼」。真正的生產力，發生在學習與回饋迴圈：走出座位去觀察、對話、釐清目標，或用快速釋出把使用者回饋拉回來驗證；若寫程式速度快過驗證速度，就會把一層層假設疊上去，越寫越偏。
在 Hacker News 的討論裡，不少人呼應「成果輸出」常只是思考後的落筆：有人形容 coding 是「一小時思考換來五分鐘輸入」，也有人追問「思考算不算 coding 的一部分」，指出很多工程師其實會透過寫出多個版本來探索解法。高票留言用一個腦洞實驗強化作者觀點：如果週末硬碟壞掉、最近寫的程式碼全被擦掉，你需要多久能重寫回來？那才是你一週真正花在「純輸入程式碼」的時間，其餘多半是在把自己「轉換成能寫出那段程式碼的人」；並拿做椅子的工匠對比，實體製造被毀後仍得投入不可避免的工時重做，凸顯軟體工作中「理解與學習」的比重。
同時也有質疑與延伸：有人表示從未見過主管以程式碼量逼產能，認為這是稻草人；也有人引用「用程式碼行數衡量進度，就像用重量衡量造飛機進度」的名言，但被糾正常見誤傳（留言認為較接近 Bill Gates，而非 Dijkstra）。工具派則補充，輸入文字確實只占很小一部分，但像 vim（文字編輯器）的模式設計與快速跳轉能幫你更快「逛」程式碼、維持專注，並不只是炫技。談到 AI 與 LLM（大型語言模型，Large Language Model）時，有人認為大眾把 LLM 的輸出稱作「思考／推理」助長了「AI 會完全取代工程師」的誤解；也有人樂觀覺得 AI 輔助寫程式會讓人更看清多層企業架構的冗贅，甚至可能動搖部分框架（如 Spring、Angular）的必要性，因為像「加上記錄（logging）」這類橫向需求成本被壓到很低，但也有人提醒：人類仍可能繼續發明更複雜、更玄學的架構。另有討論提到 Claude Code（Anthropic 的 AI 程式助理）若加上護欄與回饋，或許能像資深工程師一樣快速定位問題，但也可能在複雜舊系統語意混亂時陷入鬼打牆；而手寫與長期維護所累積的「對系統的直覺」仍是難以被輕易替代的價值。
https://news.ycombinator.com/item?id=46832625
文章主張，在「AI 時代」又浮現一個老迷思：把生產力等同於程式碼產量。作者以自己早年接案經驗說明「程式碼的價值不等於數量」：他在協助大型零售商升級 POS（Point Of Sale，銷售點系統）時卡在某個需求情境，原因是從未看過既有系統實際怎麼被店員使用。於是他直接走到分店出示識別證，請求旁聽流程；對方甚至帶他到樓上用於教育訓練與測試更新的「模型辦公室（model office）」實機演練。理解一打通，他回到辦公室只改了約三行程式碼，卻避免促銷折扣被套用錯誤，進一步可能替全國 250 家分店省下金錢與形象成本；若用「改了多少行」衡量，那天反而會被當成不夠努力。
這段經驗讓作者早早體會：有些程式碼值上百萬英鎊，有些一大坨卻一文不值；因此「寫程式」與「創造淨價值」不是同一件事。他甚至把 coding 視為一種「中斷」：你埋頭在 IntelliJ（JetBrains 的 IDE，整合式開發環境）敲鍵盤時，看不到現場、問不到人、也學不到問題本質，而且 IDE 並沒有任何快捷鍵能告訴你「正在寫錯的程式碼」。真正的生產力，發生在學習與回饋迴圈：走出座位去觀察、對話、釐清目標，或用快速釋出把使用者回饋拉回來驗證；若寫程式速度快過驗證速度，就會把一層層假設疊上去，越寫越偏。
在 Hacker News 的討論裡，不少人呼應「成果輸出」常只是思考後的落筆：有人形容 coding 是「一小時思考換來五分鐘輸入」，也有人追問「思考算不算 coding 的一部分」，指出很多工程師其實會透過寫出多個版本來探索解法。高票留言用一個腦洞實驗強化作者觀點：如果週末硬碟壞掉、最近寫的程式碼全被擦掉，你需要多久能重寫回來？那才是你一週真正花在「純輸入程式碼」的時間，其餘多半是在把自己「轉換成能寫出那段程式碼的人」；並拿做椅子的工匠對比，實體製造被毀後仍得投入不可避免的工時重做，凸顯軟體工作中「理解與學習」的比重。
同時也有質疑與延伸：有人表示從未見過主管以程式碼量逼產能，認為這是稻草人；也有人引用「用程式碼行數衡量進度，就像用重量衡量造飛機進度」的名言，但被糾正常見誤傳（留言認為較接近 Bill Gates，而非 Dijkstra）。工具派則補充，輸入文字確實只占很小一部分，但像 vim（文字編輯器）的模式設計與快速跳轉能幫你更快「逛」程式碼、維持專注，並不只是炫技。談到 AI 與 LLM（大型語言模型，Large Language Model）時，有人認為大眾把 LLM 的輸出稱作「思考／推理」助長了「AI 會完全取代工程師」的誤解；也有人樂觀覺得 AI 輔助寫程式會讓人更看清多層企業架構的冗贅，甚至可能動搖部分框架（如 Spring、Angular）的必要性，因為像「加上記錄（logging）」這類橫向需求成本被壓到很低，但也有人提醒：人類仍可能繼續發明更複雜、更玄學的架構。另有討論提到 Claude Code（Anthropic 的 AI 程式助理）若加上護欄與回饋，或許能像資深工程師一樣快速定位問題，但也可能在複雜舊系統語意混亂時陷入鬼打牆；而手寫與長期維護所累積的「對系統的直覺」仍是難以被輕易替代的價值。
https://news.ycombinator.com/item?id=46832625
