夜雨聆风Dr Milan Milanović 这篇文章的标题很直接：代码只是工作中很小的一部分。作者做了 20 多年软件工程后发现，行业里最常谈的是 coding，但真正让一个工程师被信任、能处理难题的能力，更多在别处。
这不是贬低写代码。写代码仍然重要，只是 AI 让代码生成变得更便宜后，长期价值会更明显地转向调试、判断、计划、测试、沟通和记录。原文列了 13 条经验，下面按几个主题来读。
工作大多是调试
作者说，自己很久以后才明白，日常很多时间并不在写新代码，而是在理解系统为什么没有按预期工作。
调试不只是修 bug。它包括看代码、查日志、读 stack trace、用 profiler、定位数据库和基础设施问题，然后做最小改动。AI 可以生成看起来不错的代码，但它通常不知道你们数据库的历史、基础设施细节和过去的业务决策。
对初级工程师来说，调试是很值得投入的能力。原文特别提到 stack traces、profilers、git bisect 和真实会看的日志。能在脑子里先把问题切小，再去代码里验证，是很实用的差距。
作者还提到一个更难的部分：恢复能力。优秀工程师并不因为生产问题而慌乱，他们会找到问题、修复、记录，然后继续推进。
代码是成本
原文第二条很有冲击力：code is a liability。每一行代码都要维护、运行、理解和修改。
一旦把代码看成成本，问题就会变成：为了让这件事工作，最少需要写什么？这个问题能挡掉很多过度设计，也能挡掉一些“看不顺眼所以想重写”的冲动。
作者还提醒，代码应该写给下一个读者。编译器不关心命名、结构和注释，但半年后的你会关心。朴素、可读、无惊喜的代码，是给后续维护者的礼物。
AI 会让代码数量更容易膨胀，但维护成本不会因为代码来得更快而消失。越容易生成，越要克制新增抽象、库和服务。
要解决真正的问题
作者见过很多人一直很忙，年度回顾时却说不出具体影响。他们按时完成自己的 ticket，会议里不参与架构讨论，一年下来 Jira 历史很干净，但系统没有因为他们变好。
更有价值的工程师会问：如果可以永久移除一个问题，我会修什么？这类工作不一定正好长得像一个 ticket，但它可能让后续很多任务都变简单。
所以不要只看“分配给我的事”。更好的问题是：当前系统最值得修的阻塞点在哪里，我能不能把它往前推一步？
开始写之前先想
作者有一句经验：每一小时设计，可以省下三小时重构。AI 没有改变这一点。
在打开编辑器之前，他会先理解问题，读背景，梳理业务决策，把自己的理解写下来，再列出实现步骤。这些内容后面会自然变成文档。
很多人早期会把计划和会议看成拖延。等项目复杂度上来后才会发现，如果问题理解得好，编码会顺很多。AI 也更适合在清楚的计划下工作。
简单很难
行业里常常欣赏复杂方案。Kubernetes、microservices、各种模式都很有吸引力。作者见过不少糟糕代码库，问题就在于有人为了未来可能出现的变化加了很多抽象。
真正好的代码库往往显得有点无聊：做了需要做的事，结构清楚，读起来没有额外负担。
这很难。增加通常比删除容易，展示复杂也比守住简单容易。能坚持简单，是经验和判断的结果。
测试是给未来的契约
作者说，跳过测试的团队通常不会在以后补上。然后某个周五凌晨两点，bug 会找上门。
测试的价值不只在当前功能。它是在告诉未来的你：这里的行为应该保持这样。没有测试时，部署更像祈祷；有测试时，至少能知道自己有没有破坏已有承诺。
这条在 AI 时代更重要。AI 可以很快写出改动，也可能很快写出看不出来的回归。测试是最基本的刹车。
带方案来讨论
指出项目烂、架构烂、框架烂并不难。难的是拿出下一步。
作者建议，讨论时带事实、简短 proposal 和一个缩小版设计。哪怕别人不同意，也有具体对象可以讨论。
类似地，代码能结束很多抽象争论。做一个最小可运行原型，往往比开几周会更有效。现在有 AI 辅助，原型成本更低，很多争论可以更早变成事实检验。
工程也是人的工作
原文第九条说，技术争论里有很多内容其实和人有关。有人可以拿 benchmark、RFC 和证明过程来支持方案，但对方仍然能找到理由不同意，因为争论有时关乎谁能被证明是对的。
这并不意味着事实没用。它提醒我们，技术工作也需要理解人的动机、关系和可接受范围。好方案需要能被团队接住。
作者还提到，能见度、关系和“别人愿不愿意与你共事”会影响结果。很多工程师低估了这一点。
写下来
作者把写下来称作自己的超能力。他曾经遇到过一个场景：有人重新提出几年前已经否掉的库，但他想不起当时的细节，只能花两天重建记忆。
后来他在每个项目里保留 decisions/ 文件夹。每个重要决策写一个 Markdown：选择了什么，拒绝了什么，为什么这么做，什么条件下会重新讨论。
这个习惯很朴素，但价值很大。系统越复杂，越不能只靠人的记忆保存上下文。
职业也要自己推
作者提醒，经理通常很忙，也要处理项目、团队和自己的职业。你的成长不会自动被别人安排好。
如果想要下一个机会，要先弄清楚自己想要什么，告诉能影响结果的人，然后做出能支撑这个请求的工作。
他观察到，很多停在同一层级多年的工程师并非能力差，而是没有提出清晰请求，也没有让自己的工作被看见。
怀疑感不会消失
第 13 条是 imposter syndrome。作者说自己已经做了 20 年，偶尔仍会怀疑自己。
软件行业很宽也很深，总有大量不知道的东西。关键是带着这种感觉继续工作。怀疑也可以被当作一种提醒：你仍然在认真看待问题。
结语
这 13 条经验可以压成一句话：代码很重要，但软件工程的难点很少只在键盘上。
AI 会继续让生成代码变快。也正因为如此，能调试复杂系统、少写无用代码、提前计划、守住简单、补上测试、记录决策、推动真实问题的人，会更容易体现长期价值。
参考
• Code was the smallest part of the job: https://newsletter.techworld-with-milan.com/p/code-was-the-smallest-part-of-the
• Kernighan's Law: https://lawsofsoftwareengineering.com/laws/kernighans-law/
• Laws of Software Engineering: https://lawsofsoftwareengineering.com/book/
