如果把软件学习拆成技能清单，很容易得到一串熟悉的词：语言、框架、数据库、部署。真正过了几年以后，我更愿意留下几种不太像技能的能力。它们没有统一的教程，却会在项目失控时决定事情能不能继续。
第一种是保存现场。遇到报错时，我以前习惯直接改代码，直到页面恢复正常。后来发现，很多问题在被修好以后就失去了证据。现在会先保留日志、请求参数、依赖版本和复现步骤，再开始尝试。现场越完整，越不需要靠“我记得刚才好像是这样”来猜。
第二种是把边界写出来。一个接口接收什么、拒绝什么，数据库里允许出现哪些空值，任务重复执行会不会产生副作用，这些问题如果不写在代码和文档里，就会变成每个人自己的想象。边界写清楚以后，讨论会慢一点，返工却少很多。
第三种是承认维护成本。新项目的第一版通常很漂亮，依赖最新、界面干净、功能列表也短。真正使用几个月以后，升级、备份、日志、权限和回滚会一件件找上门。选择一个方案时，我开始把“以后谁来照看”放进问题里，哪怕照看的人只有未来的自己。
第四种是让结果可以被别人复查。代码能运行还不够，说明里应该告诉下一位使用者需要什么环境，数据从哪里来，哪些结论只是一次实验。公开仓库里的 README、提交信息和 issue，很多时候比一张演示截图更能说明项目的状态。
第五种是把“知道”拆成不同等级。读过一篇文章只说明看见过，跟着示例运行说明能复现，改动输入并解释失败才接近理解，能够在新约束下做取舍才算真正用过。以前我会把这些都写成“掌握”，现在会在笔记里标记证据，避免把熟悉术语误当成能力。
第六种是知道什么时候停下来。有些想法适合做成完整产品，有些旧仓库则已经完成了练习任务。给它们留下范围和缺口说明，再把时间还给新的问题，停止就有了依据，也更像一次完整交付。
这些能力还让我重新看待协作。交接时最有用的是当前版本、已知问题、下一步和回滚位置，而不是一句“这里已经好了”。哪怕项目只有两个人，写下这些信息也能减少重复解释。软件工作里的很多摩擦来自上下文没有被留下，技术难度反倒只是其中一部分。
这几种能力都不保证项目成功。它们更像一套让失败变得不那么昂贵的办法。代码会过期，服务会下线，工具也会被新的工具替代，但保存现场、写清边界、承担维护和诚实描述结果，仍然可以带到下一次工作里。