想法

离开代码时要让它比你发现时更好。即使只是小改进，持续的积累会让代码库越来越健康，而不是越来越腐化。

随着经验增长，会越发意识到掌控对象完整生命周期的重要性。从创建到销毁，理解全貌才能写出更健壮的代码。

这是 Fail-Fast 与 Let it Crash 的编程哲学：与其用 try-catch 层层包裹去掩盖异常，不如让模块在遇到非法状态或契约违反时立即崩溃抛出。这样错误能在源头暴露，而非带着污染数据静默传播到系统深处——一次明确的崩溃远比隐蔽的逻辑腐败更容易定位和修复。

探索问题时很容易被细枝末节带偏，越挖越深却忘记初衷。保持对目标的清醒，适时抽身，避免无意义的深度钻牛角尖。

如无必要，勿增实体。面对多个解释时，最简单的那个往往是正确的。避免过度设计，保持解决方案的简洁。

知识应该以原子化的方式组织，每个概念独立且完整，然后通过链接建立关联。这样既便于复用，又能形成知识网络。

不可变数据消除了状态变更带来的心智负担，让代码更容易理解和预测。虽然可能有性能代价，但带来的可维护性通常是值得的。

80% 的结果来自 20% 的努力。识别那关键的 20%，把精力集中在真正能产生价值的事情上，而不是平均用力。

目标会随时间失效，但一套好的个人知识系统可以持续产生复利。关注系统建设而非单一目标的达成。

重大决策需要深度思考，但日常琐事依赖直觉更高效。关键是培养在两者间切换的能力，不要把精力浪费在不重要的细节上。

考虑极端情况能帮助发现系统的边界和漏洞。假设最坏的情况发生，才能设计出真正健壮的解决方案。

完美主义看起来很美，让你觉得自己仿佛在工作，但是大部分时间下，只是给自己虚幻的安全感，实际上60分的产品永远比80分的idea更好，毕竟后者只是空中楼阁。
所以我们说完美主义者要认识到行动比计划更重要，在这个期间有各种方法论可以执行，比如时间拳击法： 给任务设死线，用时间节点倒逼产出，而非等"状态好"再开始
但是同样的，不要用战术上的行动掩盖战略上的懒惰，快速行动不代表不做任何思考，而是面对现实，谨慎思考，迅速修正。

回到事物最基本的真理，从头开始推理，而不是依赖类比或传统。剥去表象，找到问题的本质再构建解决方案。

简单往往比复杂更难做到，但带来的价值更大。减少不必要的部分，专注于核心，系统会更清晰、更可靠。