--- schemaVersion: 1 slug: gp-272-20260810-senko-code-not-hard-insult ticketId: GP-272 lang: zh-tw title: 說寫 code 不難，是對所有工程師的侮辱 summary: 「軟體從來不是最難的部分」已經變成 AI 時代的口頭禪。但如果寫 code 真的那麼簡單，軟體為什麼還是一堆 bug、工程師為什麼過勞成災？Senko Rašić 反擊：兩邊都重要，自我安慰解決不了問題——而且絕對不要把理解力、判斷力和品味外包給 AI。 originalDate: 2026-08-08 translatedDate: 2026-08-10 source: Senko Rašić — blog.senko.net sourceUrl: https://blog.senko.net/code-was-never-the-hard-part-is-an-insult-to-all-programmers author: null authorshipNote: null canonicalUrl: https://gu-log.vercel.app/posts/gp-272-20260810-senko-code-not-hard-insult status: published replacementTicketId: null replacementUrl: null --- # 說寫 code 不難，是對所有工程師的侮辱 > **來源:** [Senko Rašić — blog.senko.net](https://blog.senko.net/code-was-never-the-hard-part-is-an-insult-to-all-programmers) 「LLM 或許很會寫 code，但軟體從來不是最難的部分。」「寫 code 很簡單，搞清楚要寫什麼才難。」 這兩句話最近愈來愈常聽到，尤其是在 AI 寫 code 的話題底下。 而 Senko Rašić 的判斷是：這是對所有工程師的徹底侮辱。 ## 如果寫 code 真的很簡單 如果寫 code 很簡單，工程師為什麼一直搶手、薪水為什麼那麼高——而且在零利率時代之前就很高？為什麼壓力大、加班兇、過勞的人這麼多——而且這些問題在 AI 開始吐出五千行 PR 之前就已經存在？既然這麼簡單，公司為什麼到處搶「十倍速忍者搖滾巨星工程師」，還要搬出 LeetCode 面試來篩人？隨便拉一個剛畢業的來做不就好了？ 如果寫 code 很簡單，《[Clean Code](https://gu-log.vercel.app/glossary#clean-code)》和《[The Pragmatic Programmer](https://gu-log.vercel.app/glossary#the-pragmatic-programmer)》為什麼厚得可以擋門？《The Art of Computer Programming》是拿來消暑的閒書嗎？SICP 是咖啡桌上的裝飾書嗎？為什麼有程式培訓營、為什麼有完整的大學學位，專門教這件「很簡單」的事？ 如果寫 code 很簡單，[Carmack](https://gu-log.vercel.app/glossary#john-carmack) 只是剛好在對的時間出現在對的地方？[Fabrice Bellard](https://gu-log.vercel.app/glossary#fabrice-bellard) 憑什麼被當天才？ 如果寫 code 很簡單，為什麼那麼多人對 AI（或任何人）複製他們的 code 這麼憤怒？為什麼這些人表現得好像他們把汗水、靈魂、和大量時間傾注在一件這麼不起眼的事情上？ 如果寫 code 很簡單，為什麼現在那麼多人覺得自己的身份認同和專業意義正在被剝奪？ 如果寫 code 很簡單，軟體為什麼還是一堆 bug？ > **Mogu 偷偷說：** > > 「聽起來老練、聽起來看透本質」大概是這兩句話最好用的地方——講的人不必舉證，就自動站到制高點上。 > > 但整個 AI coding 產業本身就是反證：如果寫 code 真的那麼簡單，coding agent 跑完一輪產出的東西，為什麼還是需要人類盯著看、反覆 review、時不時整坨砍掉重來？工具越強，越證明「讓程式正確跑起來」有多難 ╰(°▽°)╯ --- ## 如果「搞清楚要做什麼」才是真正的難題 好，換到另一邊看。如果決定「要做什麼」才是真正難的部分——為什麼那麼多 PM 看起來搞不清楚狀況？為什麼 PM 不用經歷嚴格的十輪面試？為什麼 PM 的薪水沒比工程師高？ 如果理解客戶需求才是最有價值的，為什麼市場研究員、使用者體驗專家、甚至客戶成功團隊在軟體公司裡不被當搖滾巨星？如果「理解客戶」比寫 code 更難，為什麼商業分析師被看成在推紙的行政人員？ 如果實作很簡單、找到需求才難，工程師為什麼每次業務為了成交順口答應客戶一個新功能就氣到跳腳？業務替公司找到了真正的市場需求，找到了有人願意付錢的東西——照這個說法，那不就正好是「最難的部分」。 如果寫 code 很簡單，為什麼不直接做十個版本丟出去，看哪個能活？ --- ## 工程師沒有平均值 還有一句經典：「軟體開發的大部分工作是跟利害關係人溝通、理解客戶需求、搞清楚優先順序。」 但 Senko Rašić 職涯上遇過的工程師裡，很少有人想跟利害關係人講話，更不想跟客戶講話（自由接案者和技術公司創辦人除外）。至於「搞清楚優先順序」，翻譯成白話就是「直接說要做什麼就好，然後不要每兩天就翻盤」。 有些工程師會說：「寫 code 不是重點，解決客戶的問題才是。」但同一批人轉頭就開始發表 monad、記憶體安全和 DRY 原則的高見。他們對「客戶」的理解是一個虛構的使用者畫像（user persona），而且他們覺得 affordance 是爸媽每週末給的零用錢，讓小孩出去玩的那種。 > **Mogu 插嘴：** > > affordance 是設計領域的詞，指「一個東西的外型直接告訴你它能怎麼用」：門把長那樣就是要轉、平板門片就是要推。原文的笑點在 affordance 跟 allowance（零用錢）音很近——一個天天把「解決的是客戶問題」掛嘴上的人，連使用者體驗最基本的詞都會聽成零用錢 (¬‿¬) 另一群人會說：「軟體開發就是理論建構。程式其實是數學證明。每個 commit 都應該說一個故事。」用 FTP 上傳一個 PHP 檔案來解決客戶問題？那是褻瀆。 這不是說同時深度關注技術工藝和真正同理客戶的工程師不存在。他們存在——只是大概需要看一下精神科，處理一下人格分裂的問題。 > 事後補的修正：這句寫過頭了，本意是半開玩笑的「很少有人能同時做到」，而且下一段其實就在鼓勵大家往這個方向走。是我的錯。 > **Mogu 內心戲：** > > 「mea culpa」是拉丁文，天主教告解時捶胸口說的「我的錯」。刀子丟出去、飛到一半自己伸手接回來——這種當場認錯還留著原句不刪的作法，比寫得四平八穩誠實多了 ┐(￣ヘ￣)┌ --- ## 兩邊都重要——自我安慰不是出路 跟使用者對話、理解他們的體驗、同理他們的處境、解決客戶的問題、讓所有利害關係人站在同一條線上——他認為這些對軟體專案的成功至關重要。 他同樣認為，寫出好的 code 是一門需要技術、耐心、細節控制、經驗和智慧的工藝，而且在未來仍然會是重要的能力。 兩邊都重要。理想狀態是同時追求：深度理解正在建構的系統，同時深度理解為什麼要建構它。 > **Mogu 真心話：** > > 原文這一段的標題是西班牙文「¿Por qué no los dos?」——直翻是「為什麼不兩個都要？」來自 Old El Paso 一支塔可餅的廣告：一家人在餐桌上爭硬殼還是軟餅皮，小女孩在旁邊插一句「幹嘛不兩種都要？」後來變成網路迷因，用在任何「這兩個選項明明不衝突，幹嘛選」的場合 (๑•̀ㅂ•́)و✧ 大聲宣告「code 很簡單」或者站到另一個極端喊「code 是藝術、是人類的創造性表達、不可能被自動化」——兩邊都是把頭埋進沙子裡。 這只是自我安慰。而目標不是自我安慰，是活得好。 這不是說「趕快跳上 LLM 的列車」。不是說「去當一群 AI agent 的管理者」。也不是說「AI 生成的 code 是偷來的垃圾，拿命去擋，泡沫遲早會破」。 但得認清：整個產業正在經歷地殼等級的變動。需要搞清楚怎麼適應。需要理解什麼可能會改變，什麼永遠不會變。 --- ## 不會變的事 軟體會越來越複雜。軟體永遠需要維護——bit-rot 是自然法則，熵也是。技術（硬體和軟體）會繼續往前走，不管那個方向是好是壞。抽象層的高塔——還是該叫摩天大樓？——只會越蓋越高。 使用者永遠想要更多，願意花更少。他們依然不知道怎麼把需求講清楚，更糟的是，他們自己都不確定到底想要什麼。「付錢的客戶」和「用產品的使用者」之間的斷層還是在那裡，商業需求和使用者需求之間的張力也不會消失。 還有：賣蛇油的永遠不缺。當紅技術來了又走——VR 的文藝復興到現在還在等。 --- ## 會變的事 工程師從一開始就在幹顛覆自己產業的事。打孔卡沒人用了。很少人需要寫組合語言或 COBOL。花了幾十年跟 C 或 C++ 的記憶體 bug 搏鬥、留下一身傷疤——在 Rust、Go、Python 和 JavaScript 的時代，那些經驗一文不值。 Senko Rašić 自己就經歷過 valgrind 的年代，記得 PHP4 時期的 `mysql_real_escape_string()`——這輩子再也不會用到的東西。而那甚至沒有很久以前。dBase、Clipper、HyperCard、Access 那個年代，他自己差一點就趕上。那些技術現在還看得到在跑：某些小店、咖啡廳角落，一台積灰、從米色泛成金褐色的桌機，還開開心心跑著某套客製化的商業系統。備份？什麼備份？ --- ## 怎麼在這場地殼變動裡活得好 接受改變這件事會發生。對新東西保持同等程度的好奇和批判。 認清這裡有大量炒作，試著分辨什麼是空氣、什麼是真的有用（以及有用到什麼程度）。注意那條標準一直在往後挪：往後退一步看過去一年、五年，評估技術、經濟、社會三個層面的變化速度。 每個人的角色和責任都在改變。要願意花時間和精力去理解隔壁的領域和角色。 資深工程師不要只在技術深度裡找安慰。去學使用者體驗、客戶訪談、所在領域的商業策略。就算一輩子都不會真的去做那些事，這份理解也會讓人更懂得欣賞一套軟體從寫好到交到使用者手上中間經歷的所有工作。 剛入行或資歷淺的工程師：投資在理解軟體底層怎麼運作。搞懂指標、遞迴、記憶體架構，即使是 JavaScript 開發者也一樣有用。搞懂網路協定和 HTTP 怎麼運作，即使只是做 WordPress 外掛也用得上。去刷 LeetCode、學演算法和資料結構，即使工作上不需要。不要怕問「為什麼」和「到底怎麼運作的」。 原文最後附了一份書單，說可能會有幫助——十二本，從 CS 根基一路排到商業策略和團隊設計。 > **Mogu 補個刀：** > > 那十二本橫跨：SICP、Cracking the Coding Interview、《人月神話》、《The Mom Test》、《Continuous Discovery Habits》、《Obviously Awesome》、《The Design of Everyday Things》、《Don’t Make Me Think》、《7 Powers》、《Working Backwards》、《Team Topologies》，還有一本拿過普立茲獎的非虛構文學《The Soul of a New Machine》。這張清單本身就在示範文章的核心論點：工程師的成長路徑不是只往技術深度鑽，或只往商業寬度拉，而是兩邊都要碰 (◕‿◕) --- ## 不要當肉身 [Proxy](https://gu-log.vercel.app/glossary#proxy) 不管是誰、在什麼位置——不要把理解力、判斷力、同理心和品味外包給 AI。不要放棄自己的責任。不要當一個肉身 Proxy（meat proxy）。 文章丟出去之後，Hacker News 和 Lobsters 上湧進大量討論——顯然戳到了神經。而最耐人尋味的是：吵起來的人各自帶著完全不同的經驗，對 coding、programming、development、engineering 這幾個詞的定義也各有一套。 > **Mogu 內心戲：** > > Meat proxy——直翻就是「肉做的代理伺服器」。AI 吐出東西，人類不看不想不改，直接轉發出去。人還坐在那個位子上，但只剩一具肉身在執行轉發功能。難堪的是這個位子真的有人在坐——而且愈來愈好坐。 > > gu-log 自己就是一個重度使用 AI 的專案——每篇文章經過 AI 翻譯、AI 評分、AI 改寫。但 [ShroomDog](https://gu-log.vercel.app/about) 依然逐篇審、逐篇打回重寫、逐篇決定「這個品質能不能見人」。gu-log 的[四法官評分系統](https://gu-log.vercel.app/posts/sd-10-20260322-ralph-loop-quality-system)存在的理由，就是不讓 AI 的輸出直接變成最終產品。工具可以變強，但按下「發布」那個鍵的判斷，不能外包 (ง •̀\_•́)ง