从业二十余年，我逐渐意识到，这个行业的样子既不像当初想象的那样，也不像某些人描述的那样。我们听到的、读到的，大多是关于写代码的——但我在职业生涯中发现，真正重要的事情几乎都在别处。
入门阶段，我把精力放在提升编码速度、优化代码结构、深入学习编程语言上。这些投资是值得的。但今天，AI 已经能以同等甚至更好的水平完成这些工作。真正能产生复利、被委以难题的能力，几乎全部在别处。
软件一旦建成，往往要存在多年。打造这样的软件并不简单。以下是我关于"第二件事"的经验总结——第一件事（写代码）早已不再是瓶颈。
调试，才是工作的主旋律
很长一段时间我才真正理解这一点。
实际情况是，我大部分时间在调试，而不是写新代码。写新代码远比调试容易。调试不仅涉及修复问题，还包括检查代码、查阅日志，用最小改动解决问题。
AI 的不足之处在于，它并不擅长调试工作。它能写出漂亮的代码，但不掌握数据库细节、基础设施或早期的业务决策。它仍然无法独立解决问题，所以我需要亲自介入修复。
如果你还是初级工程师，调试能力是值得关注的方向。我发现很多开发者并不熟悉 IDE 中的调试器和性能分析工具。这正是你的优势所在——要熟练掌握堆栈跟踪、性能分析器、git bisect，以及那些你真正会去读的日志。学会在脑海中定位问题，再动手追踪代码。
而最难学会的，不仅是恢复，还有预防。我见过的优秀工程师从不怕把东西弄坏。压力之下他们保持冷静，找到并修复问题，记录下来，然后继续前进。大多数平庸的工程师则害怕破坏生产系统。
"调试的难度是写代码的两倍。"——Kernighan 定律
代码是负债，不是资产
每一行代码都需要维护、在生产环境运行，这些都是需要付出的代价。代码不便宜，代码很贵。
写代码是我们乐此不疲的事情，也是工作的核心。我们竭尽全力写出最优质的代码——设计模式、优秀实践、算法，能用上的都用上，而且乐在其中。有时候也需要删除代码。但这都不是免费的。新增一个库、一个服务或一层抽象，都有其成本。
这是我《软件工程定律》一书中写到的原则之一，因为它改变了你看代码库的方式。一旦把代码视为负债，问题就不再是"我们应该构建什么"，而是"让这件事跑起来最少需要构建什么"。这样一问，大多数过度工程化就会消失。同样，大多数"只因为看着不顺眼就想重写"的冲动也会消失。
这个原则有一个更小的同类：为了下一个读者而写代码，而非为了编译器。编译器不在乎命名、结构或注释。但下一个读者——通常是大半年后带着更少上下文的你——在乎这三样。有时候那个读者就是你自己。无趣的代码是对那个读者的馈赠。而聪明的代码，是他们不得不偿还的债务。
然而我知道，在大多数项目中说这些并不会受欢迎。每个人都想更快交付更多功能。AI 时代，我们正处于 token 数量最大化的顶端。但维护成本不会因为产量增加而下降。它只会上升。那些在问题账单到来之前就意识到这一点的团队，会比没有意识到的团队走得更远。
超越任务本身：做真正有价值的事
许多工程师看起来很忙，年终 review 时却拿不出像样的成果。典型表现是：按时完成工单，会议里沉默寡言，架构讨论从不参与——"这不是我的活"。一年下来 Jira 记录很漂亮，实际上对业务毫无影响。
真正优秀的工程师会问自己：有哪些问题是我能永久解决而非反复打补丁的？然后确保那件事真正完成，哪怕它不在工单队列里。结果往往是，其他工作反而因为解决了根本问题而加速了。
核心观点： 优秀工程师不只做任务卡上的事，他们能把工作描述成更大的使命。
设计先行：减少返工才是真正的效率
业内有句话：每花一小时做设计，都能节省三小时返工。这条规律不会因为 AI 的出现而改变。
具体做法是：打开编辑器前，先彻底理解问题本身。了解业务决策的背景，把它们写下来让自己真正消化，然后再拆解实现步骤——这套文档会成为后续的参考指南。
早年我也觉得规划、开会都是拖延。但后来想通了：前期把这件事做好，编码阶段会顺利得多。
简单是极难达到的境界
行业内普遍崇拜复杂方案：Kubernetes、微服务……张口就来。
见过最糟糕的代码库，都是过度设计的结果——堆砌了根本用不上的抽象层，为从未出现的场景做通用化。而真正优秀的代码库截然不同：恰好做了需要做的事，代码简洁易读。
然而，让事情变简单比让它变复杂要难得多。这就是为什么大多数代码并不简单。
测试是与"未来的自己"签订的契约
接触过不少低测试覆盖率甚至零测试的代码库，这类项目从一开始就问题重重。上线时只能祈祷一切正常。
我待过的每个团队，"暂时跳过测试"的决定最后都从未补上过。然后 Bug 在周五凌晨两点出现，唯一的问题是：谁来买单、代价有多大。
带方案来，而非只带意见
能清晰陈述问题的人很多，主动提出解决方案的人却很少。
"这个项目/架构/框架/库/团队很差"这种话很容易说，但真正拿出解决方案、甚至动手修复的人凤毛麟角。
这也是为什么更好的设计常常输给更差的设计的原因之一：糟糕设计的推动者能展示下一步是什么；更好的设计，其倡导者只会列举对方哪里会出错。
要成为那个"带着方案来"的人：带上事实、一份简短的提案，以及一个你真正愿意接受的精简版本。
代码赢过争论
这句话很早就听过，但真正理解花了好几年。技术讨论有时根本没有具体结论，有时讨论了很多却做了糟糕的决定。
解决方案是：停止争论，用一小时搭建一个原型，让后续对话围绕真实数据展开。这一小时花在原型上，抵得上几周的讨论。
有了 AI 工具，这条法则的效应更被放大了。现在可以快速搭原型、验证想法是否正确。一旦有了可运行的原型，讨论就不再是抽象概念，理解门槛大幅降低。
如果在技术争论中陷入僵局无法收敛，想办法更早做原型。当现场有东西在跑，争论的质量完全不同。
技术归根结底是人的事
技术人往往觉得技术最有意思，以为知识最渊博的人就是最优秀的。这类人能为框架、架构、语言、系统设计争上几天。但我逐渐发现，这些争论有些确实是在谈工作本身，更多的却是在谈自我。
这类争论没有赢家：你可以步步举证、跑基准测试、写 RFC，对方依然能找到不同意的理由。因为分歧的根源不在技术，而在于谁对谁错。
想在技术领域做得好，需要了解人性规律。在技术里，没有一件事是真的关于技术——一切都是关于人。明白了这一点，很多事会变得更容易。
没有绝对最好的方案，只有双方都能接受的方案。
副项目是最好的工程师成长路径
副项目（Side Project）、自由职业或任何本职工作之外的项目，都能让你接触更多经验——这是工程师成长最有效的途径。
不需要做很出名的项目。一个完成度高、有实际用途、放在公司代码库之外的小项目，就是最好的名片。
职业生涯中，我经常做各种副项目，有时是接私活，有时是自己做。这些经历让我学到了在正式工作中根本接触不到的知识和技能。相比那些只在一家公司只做一个项目的同行，我的经验积累速度要快得多。
我录用过的最优秀的三位工程师，简历上都没有大厂背景。但他们都有一个可以展示的副项目。
自己驱动职业发展，别让他人替你做主
我们常以为上级会负责我们的职业发展。实际上，除了你自己，没有人会真正管理你的职业。
上级有太多事要操心：项目进度、他们的上级、其他团队成员，加上自己的职业规划。他们没有时间深度思考你的处境。晋升往往不会自动跟随好业绩到来，而是需要响亮、具体的争取。先明确自己下一步想要什么，然后告诉真正能给你这个机会的人，最后用实际成果来支撑这个诉求。
我见过一些工程师在同一级别停滞了好几年，他们的能力绝不比晋升的人差。问题在于他们从不主动争取，也不让自己被看见。他们以为只要工作出色，自然会得到认可。经验告诉我，工作成果不会替自己说话，你得替它开口。
冒名顶替综合征永远不会消失
这是行业内每个人都有的感受。我入行二十年，有时仍然会被它困扰。这行太宽太深，总有你不懂的东西，这种感觉会让你觉得自己不够格。而这正是冒名顶替综合征的典型反应。
应对的方法不是让它消失，而是继续做下去。据我观察，那些看起来已经"全搞定"的人，其实也有同样程度的自我怀疑，只不过对外释放的自信信号更强罢了。把这种怀疑当作你还在保持警醒的证明，而不是对你是否适合这份工作的宣判。
评论