← #805

「写代码从来不是难的那部分」是对所有程序员的侮辱

文章摘要

Senko Rašić 这篇文章直接冲着一句近来到处流传的话去：「LLM 也许很会写代码，但写代码从来就不是难的那部分」「编码很容易，难的是搞清楚要写什么」。他的态度很明确——这是对全世界程序员的一记侮辱。

文章的主体结构是连珠炮式的反问。如果写代码很容易：为什么程序员多年来供不应求、拿着高薪（早在零利率时代之前就是如此）？为什么在 AI 开始吐 5000 行 PR 之前，这行就已经充满压力、超时工作和倦怠？为什么公司要找「10x 忍者摇滚明星程序员」，还要拿 leetcode 面他们——既然这么容易，刚毕业的初级工程师随手也能搞定才对？为什么会有《Clean Code》《程序员修炼之道》这种大部头？《计算机程序设计艺术》是消夏读物吗？SICP 是茶几摆件吗？为什么要有训练营甚至整个大学专业？如果写代码很容易，Carmack 只是运气好站对了位置？为什么我们认为 Fabrice Bellard 是天才？如果写代码很容易，为什么大家会因为 AI（或任何人）抄自己的代码而愤怒？为什么他们的反应像是往一件如此微不足道的东西里倾注了汗水、灵魂和大量时间？如果写代码很容易，为什么现在这么多人感到自己的身份认同和职业价值正在被剥夺？如果写代码很容易，为什么软件这么该死地充满 bug？

如果决定做什么才是难的那部分：为什么那么多产品经理看起来一无所知？为什么没有针对他们的严苛十轮面试？为什么他们拿得没有开发多？为什么市场研究员、可用性专家、乃至客户成功不被当成软件公司里的摇滚明星？如果「理解客户」更难，为什么业务分析师被当成打杂的？如果实现容易而找需求更难，为什么销售为了成单向客户承诺一个新功能时程序员会炸毛——他们明明找到了真实的、有人愿意付钱的需求啊！

「没有中位数程序员」这一节，他反驳另一句陈词滥调——「软件开发的大部分工作是跟利益相关方沟通、理解客户需求、厘清优先级」。他说自己见过的程序员里，很少有人想跟利益相关方说话，更别说客户（自由职业者和创始人除外）；而所谓「厘清优先级」在实践中就是「你直接告诉我干什么，别每两天变一次」。有些开发者会说「我不写代码，我解决客户的问题」，但转头就开始高谈 monad、内存安全和 DRY 原则，而他们对客户的全部理解就是一个编造出来的「用户画像」。另一些人则说「软件开发是理论构建」、程序其实是数学证明、每个 commit 都应该讲一个故事、用 FTP 传一个 PHP 文件去解决客户问题是弥天大罪。（作者后来加了个后记，承认这一节里「同时深爱手艺和共情客户的人可能需要看看人格分裂」那句玩笑开过头了。）

那什么才重要？作者的答案是「为什么不能两者都要」。跟用户交谈、理解他们的体验、共情、解决客户问题、让所有人对齐，这些对项目成功至关重要；同时，写出好代码是一门需要技巧、耐心、细致、经验和智慧的手艺，未来依然有价值。他认为无论是大声宣称「代码很容易」，还是站在对立面说「代码是艺术、是无法自动化的人类创造性表达」，都是把头埋进沙子——都是自我安慰（cope），而你要的不是自我安慰，是活得好。

他随后区分了什么不变、什么在变。不变的：软件只会更复杂；软件永远需要维护，bit-rot 和熵都是事实；抽象的高塔越垒越高；用户永远想要更多、付得更少，永远不知道怎么表达需求，甚至不知道自己到底想要什么；付钱的客户和真正使用的用户之间的断层依旧；卖蛇油的人永远不缺。在变的：程序员一直在颠覆自己这个行业——没人用打孔卡了，很少有人需要写汇编或 COBOL 了；那些在 C/C++ 里跟内存 bug 搏斗留下的伤疤，在 Rust、Go、Python、JavaScript 的时代一文不值。他自嘲还记得 valgrind 和 PHP4 时代的 mysql_real_escape_string()，这些东西他这辈子不会再用到了。

怎么才能活得好？接受变化发生；对新事物既保持好奇也保持批判；意识到炒作很多，学会分辨热空气和真正有用的东西，并且警惕不断移动的球门柱——退后一步，看看过去一年或五年，评估技术、经济、社会变化的真实速度。角色和职责都在变，愿意投入时间理解相邻的领域。如果你是资深开发，别只满足于把专长挖得更深，去学用户体验、客户访谈、所在行业的商业策略。如果你刚入行，就往深里理解软件是怎么工作的——指针、递归、内存层级，即使你写 JavaScript 也有用；网络协议和 HTTP 的原理，即使你写 WordPress 插件也有用；即使不需要也去刷 leetcode、学算法和数据结构；不要害怕追问「为什么」和「究竟怎么做到的」。文末列了一串书单，从 SICP、《人月神话》到《设计心理学》《Don’t Make Me Think》《The Mom Test》。

最后一句是全文的落点：无论你是谁，别把你的理解力、判断力、共情和品味外包给 AI。别放弃你的责任。别当人肉代理。

HN 评论精华

这条帖子拿到 940 分、588 条评论。讨论迅速分裂成三派：认为「写代码确实是难的部分」的、认为「作者混淆了 coding 和 programming」的，以及跳出来讲「薪水高低跟难度无关」的。

bob1029 的评论引发了本帖最长的讨论串。他的立场是：程序员被迫戴着一堆看不见的额外帽子，而正是这些帽子让代码得以存在。「写代码不难，写正确的代码才难。而在有付费客户的场景里，知道什么是正确的通常需要跟客户互动。」他认为最能干的员工拿高薪不是因为会写代码，而是因为有本事把客户盘问到吐出真实需求。
这条下面反驳如潮。dofm 直接说：写正确的代码就是整个过程，如果你定义「编码」时不考虑正确性，那当然可以把它排除在难的部分之外。hakunin 打了个比方：这就像说「造车不难，造一辆真能开又能过法规的车才难」——换句话说，在任何合理的语境里写代码都是难的。jasonlotito 用一个模板句式解构了这类说法：「写散文不难，写好散文才难。做饭不难，做好菜才难。」bdangubic 用 30 年经验直接否认：他认识的最好的程序员从来没跟客户说过话，「我干了 30 多年，拿着离谱的薪水，不戴任何额外帽子，也不跟任何客户说话」。relaxing 补充说，盘问客户拿需求在老年间是管理层的活（他们也拿高薪）。
zem 给出了具体的反例清单：他做过很多项目，满足需求的方法根本不是挑战，写代码本身才是真难——需要维护不变量的复杂数据结构、共享内存的分布式访问、各种形式的容错，以及最要命的、让复杂算法跑到可接受的速度。「还有架构问题，它的杀伤力不在代码刚写完的时候，而在几个月后你要加一个大功能、却发现早期决策把你卡死了的时候。」
Jach 从方法论角度反驳：很多评论者似乎忘了瀑布模型失败的原因之一，就是你没法靠内省或盘问客户拿到需求——为了揭示真实准确的需求，你往往必须先写代码。几十年的创业实践支持迭代法，成功者学会了写更少承诺的代码、迭代式地发现需求。而这本身很难做到——太多公司倒闭或输给对手，就是因为代码写得不够快、改得不够快。
mrkeen 提供了另一个流行框架：用 Lamport 的说法，coding 不等于 programming。把想法编码成编程语言很容易，意识到你的想法很糟糕才难。他列了一串现实：不能信任时钟、CAP 三选二、恰好一次投递不可能、代码要不停机改和发布、黑客会为了乐趣和利益攻击你、而你的经理不想让你浪费时间把这些做对。但 varjag 一句话怼回去：不对，编码仍然是难的那部分——失败的程序员都往架构师和产品管理跑，从没见过反方向的。
threethirtytwo 给出了本帖最有杀伤力的一条心理学解读：这句话根本不是管理层和高管说的，是程序员自己说的。「它仍然是侮辱，是对自己的侮辱。这是所有程序员——包括我——在现实往脸上侮辱我们时对自己撒的谎。编码曾经就是难的那部分。那正是我们擅长的东西。现在我们的技能正在被自动化碾压。怎么面对现实往我们脸上拉屎？我们撒谎。我们编造一个更容易接受的现实。」
Waterluvian 提供了一个更平和的、和职业阶段相关的视角：在他的职业生涯里，头几年代码就是难的部分；越过那个坎之后，工作里其他所有东西都更难了；今天代码是最容易也最无趣的部分。但他补充说，自己 13 年只经历了专业编程世界的大概 2%——如果明天让他去做内核优化、改进 Postgres、或者给某个 PLC 逆向出一个模拟器，他会立刻回到「代码是难的部分」的那片土地上。
HarHarVeryFunny 类比得很妙：编码之于软件开发，就像切开之于心脏直视手术——它是 99% 的决策和经验应用都完成之后的最后一步。仍然有手艺和「手术技巧」，但难的部分显然是之前的一切。他猜测，包括很多在 AI 公司工作的人在内，有些人以为软件开发的工作主要就是「编码」。
kstenerud 的解读最务实：他一直把这句话理解为「编码是开发者工作里最容易的部分」——这不代表它本身容易，而是说它是最容易被自动化的部分。他补充了实际观察：现代 LLM 在几千行代码以内完全有能力维持不错的代码质量和架构（只要你要求它），但超过之后，如果你不设计好文档、不亲手掌着架构的舵，它会飞快地失去线索。
woopah 提醒大家注意一个逻辑漏洞：人们天然假设薪水高低和工作难度相关，但这不成立。一个岗位的市场价值还取决于供需和资金来源。程序员能要到高薪，部分原因只是需求爆炸得比供给快。
LAC-Tech 给出了本帖最直白的怀疑论：「我还是没看到。我看到很多大声嚷嚷的人、很多产出的代码行、很多人愤怒地指着自己的业余项目——但在我们这个泡泡之外没有大规模影响。记住现在是 2026 年，我们进入这波炒作五年了，模型比以往任何时候都强，而我们周围用的所有软件基本上就是把 2021 年的技术往前投影五年的样子（『2026 年会有……又一个后端 JS 运行时！』）。」他自嘲这大概会被说成「自我安慰」，但「也许，只是也许，很多人就是真的很喜欢跟聊天机器人说话」。
neya 从另一个角度看这场叙事之争：「写代码从来不是难的部分」是设计师、MBA 和产品经理强推的叙事。他观察到的讽刺是：在这群人里，被大规模替换的恰恰不是程序员——整个产品团队、设计师在被替换，好的写代码的人依然抢手，因为得有人去修 vibe coding 弄出来的烂摊子。他给的理由是：设计没有好坏的参照系，你要么喜欢要么不喜欢；而代码要么能跑要么不能。
作者 senko 本人在评论区回应了 qwe516 的质疑（「先发一通迎合硬核程序员的牢骚，然后叫他们适应；他还是个 AI 顾问」）：「你说得对，我只想补充一句，那『其他身份』包括从九十年代就开始当程序员 :)」他还澄清，比起「适应（adapt）」（那暗示「拥抱 AI」，而他并没这么说），他的本意更接近「保持可适应性（be adaptable）」。