笔记 01｜注重实效的哲学：为自己的职业负责

一、核心观点

第一章立的是全书的底色：注重实效（pragmatic）不是一种技术，而是一种负责的态度。

1. 我的源码让猫给吃了。作者用"小猫挠坏磁盘"这个荒诞借口开篇，讽刺把失败推给外部环境的心态。真正的从业者面对失误时，第一反应是"怎样补救"，而不是"这不是我的问题"。责任意味着：把 git commit、备份、测试都当作自己的事，而不是"流程应该保证"。
2. 软件的熵。系统像物理世界一样自发走向混乱，一块没整理的代码、一句随意的注释，会把"破窗"传递给下一个人。不要容忍破窗，发现就修，哪怕只是贴一张 TODO 而非长期放任。
3. 石头汤与煮青蛙。石头汤说的是如何用"最小的可行方案"撬动他人加入；煮青蛙说的是为何温水里的项目会无声死亡。前者是催化改变的策略，后者是警惕指标缓慢恶化的警钟。
4. 够好的软件。质量不是绝对的，要和用户一起定义"够好"在什么边界上。追求交付一个 95% 的方案，好过永远交付 100% 才上线的幻想。
5. 你的知识组合与交流。知识会像投资组合一样贬值，需要持续投入；而所有技术决策最终都要落到"能不能讲清楚"上。

二、原文摘录

"务必为你的职业生涯负责。"

"不要容忍破窗——一旦有破窗出现，就要立刻修好它。"

"如果河边的青蛙被人慢慢加热，它是察觉不到危险的。"

三、个人思考

这章最打动我的是"软件的熵"与"知识组合"的内在一致性：两者都在说长期主义需要日常的微小维护。团队里最昂贵的成本往往不是技术债本身，而是"大家都觉得该修但没人动手"的默契沉默。作者给出的解法很务实：先做一个石头汤的贡献者，用一次小改进创造可见价值，再让别人愿意跟进。

另一个反思是关于"够好的软件"——我过去常把"打磨"当作负责，其实按时交付、让用户开始反馈，往往才是更高阶的负责。

四、行动清单

本周在负责的模块里找一扇"破窗"，用 30 分钟内能完成的方式修复，并在周报里记录。
建立知识组合盘点表：每季度记录一次掌握的技术、当前热度与投入计划。
提案时先写一页"最小石头汤方案"，而不是完整架构文档。
遇到问题时，先说补救方案，再说原因。