我以前有一个很大的误区。
总觉得自己工作了十几年，经验应该已经很多了。
做过很多项目。
踩过很多坑。
解决过很多问题。
也经历过一些别人没有经历过的事情。
这些东西，应该已经成为了我的能力。
但有一天，我突然发现：
很多经验其实并没有真正留下来。
它们只是存在我的脑子里。
存在聊天记录里。
存在某个已经结束的项目里。
甚至存在某个我已经记不清名字的会议里。
如果有一天我离开现在的工作环境，这些东西可能就跟着一起消失了。
那一刻我开始意识到：
经验不等于资产。
只有被记录、被整理、被复用的经验，才真正开始成为自己的资产。
我曾经以为，工作经验就是“知道得多”
做程序员久了，很容易产生一种错觉。
工作时间越长。
处理过的问题越多。
自然就越有经验。
但后来我发现：
真正拉开差距的，不是“经历过多少事情”。
而是：
你有没有把经历转化成自己的知识系统。
比如我曾经解决过一个很复杂的线上问题。
当时花了两天时间排查。
日志看了很多。
代码改了很多。
最后终于定位到原因。
问题解决之后，我松了一口气。
然后就结束了。
几个月以后，类似的问题再次出现。
我又重新排查了一遍。
后来我才发现：
我并不是解决过这个问题。
我只是经历过一次这个问题。
两者完全不同。
经历，如果没有沉淀，很容易失传。
程序员为什么特别需要自己的“技术文档”
公司有技术文档。
项目有架构文档。
接口有 API 文档。
系统有运维手册。
为什么？
因为我们知道：
不能把系统运行所需要的知识全部放在某一个人的脑子里。
否则这个人一离开，系统就会出现“知识孤岛”。
我突然觉得：
一个人的职业生涯，其实也是一个复杂系统。
那么，我是不是也应该给自己建立一份文档？
不是写给公司看的。
不是写给领导看的。
也不是为了绩效考核。
而是写给未来的自己。
我把它叫做：
个人技术文档。
它记录的不是“我做过什么”。
而是：
我从这些事情里，真正学到了什么。
第一层：记录“我遇到过什么问题”
最开始其实很简单。
每当遇到一个值得记录的问题，我就留下一个条目。
比如：
为什么这个项目最后延期了？
为什么这个需求反复修改？
为什么一个看起来很简单的系统，最后变得越来越复杂？
为什么一个团队明明技术能力不错，项目却推进得很慢？
为什么某些方案在技术上很好，最后却没有被采用？
这些问题表面上是项目问题。
但如果认真分析，会发现里面往往隐藏着很多规律。
技术只是其中一部分。
还有组织。
沟通。
利益。
资源。
决策。
人的行为。
这些东西，才是工作十几年以后越来越重要的经验。
第二层：记录“我是怎么解决的”
仅仅记录问题还不够。
还要记录自己的解决过程。
当时有哪些判断？
排除了哪些可能性？
用了什么方法？
为什么最后选择这个方案？
哪些尝试失败了？
哪些东西其实是走了弯路？
以前我特别容易只记录最终答案。
现在我越来越重视过程。
因为未来真正需要复用的，往往不是答案。
而是：
当我再次遇到类似问题时，我应该如何思考。
这其实就是经验真正有价值的地方。
第三层：记录“我现在知道什么”
这一层开始变得有意思。
我会把某个问题进一步抽象。
比如：
一次项目延期。
可能最终不是因为“开发效率低”。
而是需求没有稳定输入。
一次团队冲突。
可能不是某个人“不配合”。
而是双方的目标函数不一致。
一次技术方案被否决。
可能不是方案不好。
而是方案没有解决决策者真正关心的问题。
当我开始这样整理的时候，我发现：
经验开始从案例变成模型。
案例只能告诉我：
“那一次发生了什么。”
模型则可以告诉我：
“下一次可能还会发生什么。”
这两者的价值完全不同。
第四层：记录“我的判断原则”
再往下，我开始记录一些更抽象的东西。
比如：
什么情况下，我不会再继续堆技术方案？
什么情况下，我会选择先做小实验？
什么情况下，我会接受一个不完美的方案？
什么情况下，我会拒绝一个需求？
什么情况下，我会选择离开一个项目？
这些东西以前都是凭感觉。
现在我开始尝试把它们写下来。
因为我越来越发现：
真正决定一个人长期表现的，往往不是知识，而是判断。
知识告诉你“有哪些选择”。
判断告诉你“什么时候应该选哪一个”。
而判断，本身也是可以沉淀的。
个人技术文档，不应该变成“知识垃圾场”
一开始建立个人文档，很容易走向另一个极端。
什么都记。
看到一篇文章记下来。
看到一个工具记下来。
看到一句话记下来。
收藏一个网页。
保存一个视频。
最后整个系统变成一个巨大的资料仓库。
看起来知识很多。
实际上越来越难用。
后来我给自己定了一个原则：
只记录那些改变过我判断的东西。
一个知识，如果只是“知道了”。
不一定值得长期保存。
但如果它让我：
改变了一次决策。
解决了一个问题。
避免了一次错误。
形成了一个新的方法。
那么它就值得留下来。
这时候，个人文档就不再是“收藏夹”。
而开始变成：
个人经验数据库。
我越来越喜欢记录“失败”
以前写文档，我习惯记录成功方案。
最后用了什么技术。
最后采用什么架构。
最后怎么解决问题。
但现在，我反而越来越重视失败。
因为成功往往有偶然性。
而失败通常会暴露系统里的真实问题。
为什么这个项目没有做成？
为什么我当时判断错了？
为什么我明明知道问题，却没有行动？
为什么一个看起来正确的决定，最后结果并不好？
这些东西如果不记录，很容易被时间抹掉。
几年之后，我只记得：
“当时挺难的。”
但已经想不起：
我到底在哪里判断错了。
所以现在，我会给自己留下一个简单的“事故复盘”。
不是为了责备自己。
而是为了让未来的自己少交一次学费。
最重要的是，让文档可以“反向服务于未来”
个人技术文档最有价值的时刻，不是写完的时候。
而是下一次遇到类似问题的时候。
比如：
遇到一个新的项目。
搜索一下过去的经验。
遇到一个新的职业选择。
看看过去类似的判断。
准备做一个副业。
看看以前做项目时踩过的坑。
准备学习一个新领域。
看看过去自己的学习方式为什么有效或者无效。
这时候，文档开始产生复利。
过去的一次经历。
经过记录。
经过抽象。
经过复盘。
最终变成下一次决策的输入。
经验开始被重复使用。
这才是真正的知识资产。
十几年以后，我真正想留下来的是什么？
我以前想过很多次：
如果十年以后，我离开程序员这个职业，我还能留下些什么？
代码可能没了。
项目可能没了。
公司可能没了。
甚至曾经使用过的技术，也可能已经过时。
但我希望留下来的，是另外一些东西：
我解决复杂问题的方法。
我判断事情的方式。
我踩过的坑。
我对人的理解。
我对工作的理解。
我对自己的理解。
这些东西不依赖某家公司。
也不依赖某一种技术。
它们才是真正属于我的东西。
所以我现在越来越觉得：
一个程序员真正应该维护的，不只是代码仓库。
还应该有一个属于自己的：
人生知识仓库。
写在最后
40岁以后，我开始重新理解“积累”这两个字。
以前我以为：
积累就是工作年限越来越长。
后来发现不是。
如果十年的经验只是重复了一年十次。
那也未必是真正的积累。
真正的积累应该是：
经历一次。
记录下来。
复盘一次。
抽象一次。
下一次遇到类似问题时，能够更快地做出判断。
然后再把新的经验写回系统。
于是：
经历 → 记录 → 复盘 → 抽象 → 复用 → 再迭代
慢慢形成一个闭环。
这时候，一个人的职业生涯才开始产生复利。
我现在也在尝试给自己建立这样一份“个人技术文档”。
它可能不漂亮。
甚至一开始很凌乱。
但我希望几十年以后回头看，它不是一堆笔记。
而是一本真正属于自己的：
人生运行手册。
记录我怎么工作。
怎么思考。
怎么做决定。
怎么犯错。
怎么重新开始。
也记录一个40岁程序员，是怎样一点一点，把过去的经验，重新编译成未来可以使用的能力。
因为我越来越相信：
人生最可惜的事情，不是犯过错。
而是：
同一个错误，人生重复运行了很多次。
所以，从现在开始。
把经验留下来。
让它不要只活在记忆里。
让它成为下一次人生迭代时，可以调用的代码。# 如何设计一份属于自己的“个人技术文档”，让经验不会失传
我以前有一个很大的误区。
总觉得自己工作了十几年，经验应该已经很多了。
做过很多项目。
踩过很多坑。
解决过很多问题。
也经历过一些别人没有经历过的事情。
这些东西，应该已经成为了我的能力。
但有一天，我突然发现：
很多经验其实并没有真正留下来。
它们只是存在我的脑子里。
存在聊天记录里。
存在某个已经结束的项目里。
甚至存在某个我已经记不清名字的会议里。
如果有一天我离开现在的工作环境，这些东西可能就跟着一起消失了。
那一刻我开始意识到：
经验不等于资产。
只有被记录、被整理、被复用的经验，才真正开始成为自己的资产。
我曾经以为，工作经验就是“知道得多”
做程序员久了，很容易产生一种错觉。
工作时间越长。
处理过的问题越多。
自然就越有经验。
但后来我发现：
真正拉开差距的，不是“经历过多少事情”。
而是：
你有没有把经历转化成自己的知识系统。
比如我曾经解决过一个很复杂的线上问题。
当时花了两天时间排查。
日志看了很多。
代码改了很多。
最后终于定位到原因。
问题解决之后，我松了一口气。
然后就结束了。
几个月以后，类似的问题再次出现。
我又重新排查了一遍。
后来我才发现：
我并不是解决过这个问题。
我只是经历过一次这个问题。
两者完全不同。
经历，如果没有沉淀，很容易失传。
程序员为什么特别需要自己的“技术文档”
公司有技术文档。
项目有架构文档。
接口有 API 文档。
系统有运维手册。
为什么？
因为我们知道：
不能把系统运行所需要的知识全部放在某一个人的脑子里。
否则这个人一离开，系统就会出现“知识孤岛”。
我突然觉得：
一个人的职业生涯，其实也是一个复杂系统。
那么，我是不是也应该给自己建立一份文档？
不是写给公司看的。
不是写给领导看的。
也不是为了绩效考核。
而是写给未来的自己。
我把它叫做：
个人技术文档。
它记录的不是“我做过什么”。
而是：
我从这些事情里，真正学到了什么。
第一层：记录“我遇到过什么问题”
最开始其实很简单。
每当遇到一个值得记录的问题，我就留下一个条目。
比如：
为什么这个项目最后延期了？
为什么这个需求反复修改？
为什么一个看起来很简单的系统，最后变得越来越复杂？
为什么一个团队明明技术能力不错，项目却推进得很慢？
为什么某些方案在技术上很好，最后却没有被采用？
这些问题表面上是项目问题。
但如果认真分析，会发现里面往往隐藏着很多规律。
技术只是其中一部分。
还有组织。
沟通。
利益。
资源。
决策。
人的行为。
这些东西，才是工作十几年以后越来越重要的经验。
第二层：记录“我是怎么解决的”
仅仅记录问题还不够。
还要记录自己的解决过程。
当时有哪些判断？
排除了哪些可能性？
用了什么方法？
为什么最后选择这个方案？
哪些尝试失败了？
哪些东西其实是走了弯路？
以前我特别容易只记录最终答案。
现在我越来越重视过程。
因为未来真正需要复用的，往往不是答案。
而是：
当我再次遇到类似问题时，我应该如何思考。
这其实就是经验真正有价值的地方。
第三层：记录“我现在知道什么”
这一层开始变得有意思。
我会把某个问题进一步抽象。
比如：
一次项目延期。
可能最终不是因为“开发效率低”。
而是需求没有稳定输入。
一次团队冲突。
可能不是某个人“不配合”。
而是双方的目标函数不一致。
一次技术方案被否决。
可能不是方案不好。
而是方案没有解决决策者真正关心的问题。
当我开始这样整理的时候，我发现：
经验开始从案例变成模型。
案例只能告诉我：
“那一次发生了什么。”
模型则可以告诉我：
“下一次可能还会发生什么。”
这两者的价值完全不同。
第四层：记录“我的判断原则”
再往下，我开始记录一些更抽象的东西。
比如：
什么情况下，我不会再继续堆技术方案？
什么情况下，我会选择先做小实验？
什么情况下，我会接受一个不完美的方案？
什么情况下，我会拒绝一个需求？
什么情况下，我会选择离开一个项目？
这些东西以前都是凭感觉。
现在我开始尝试把它们写下来。
因为我越来越发现：
真正决定一个人长期表现的，往往不是知识，而是判断。
知识告诉你“有哪些选择”。
判断告诉你“什么时候应该选哪一个”。
而判断，本身也是可以沉淀的。
个人技术文档，不应该变成“知识垃圾场”
一开始建立个人文档，很容易走向另一个极端。
什么都记。
看到一篇文章记下来。
看到一个工具记下来。
看到一句话记下来。
收藏一个网页。
保存一个视频。
最后整个系统变成一个巨大的资料仓库。
看起来知识很多。
实际上越来越难用。
后来我给自己定了一个原则：
只记录那些改变过我判断的东西。
一个知识，如果只是“知道了”。
不一定值得长期保存。
但如果它让我：
改变了一次决策。
解决了一个问题。
避免了一次错误。
形成了一个新的方法。
那么它就值得留下来。
这时候，个人文档就不再是“收藏夹”。
而开始变成：
个人经验数据库。
我越来越喜欢记录“失败”
以前写文档，我习惯记录成功方案。
最后用了什么技术。
最后采用什么架构。
最后怎么解决问题。
但现在，我反而越来越重视失败。
因为成功往往有偶然性。
而失败通常会暴露系统里的真实问题。
为什么这个项目没有做成？
为什么我当时判断错了？
为什么我明明知道问题，却没有行动？
为什么一个看起来正确的决定，最后结果并不好？
这些东西如果不记录，很容易被时间抹掉。
几年之后，我只记得：
“当时挺难的。”
但已经想不起：
我到底在哪里判断错了。
所以现在，我会给自己留下一个简单的“事故复盘”。
不是为了责备自己。
而是为了让未来的自己少交一次学费。
最重要的是，让文档可以“反向服务于未来”
个人技术文档最有价值的时刻，不是写完的时候。
而是下一次遇到类似问题的时候。
比如：
遇到一个新的项目。
搜索一下过去的经验。
遇到一个新的职业选择。
看看过去类似的判断。
准备做一个副业。
看看以前做项目时踩过的坑。
准备学习一个新领域。
看看过去自己的学习方式为什么有效或者无效。
这时候，文档开始产生复利。
过去的一次经历。
经过记录。
经过抽象。
经过复盘。
最终变成下一次决策的输入。
经验开始被重复使用。
这才是真正的知识资产。
十几年以后，我真正想留下来的是什么？
我以前想过很多次：
如果十年以后，我离开程序员这个职业，我还能留下些什么？
代码可能没了。
项目可能没了。
公司可能没了。
甚至曾经使用过的技术，也可能已经过时。
但我希望留下来的，是另外一些东西：
我解决复杂问题的方法。
我判断事情的方式。
我踩过的坑。
我对人的理解。
我对工作的理解。
我对自己的理解。
这些东西不依赖某家公司。
也不依赖某一种技术。
它们才是真正属于我的东西。
所以我现在越来越觉得：
一个程序员真正应该维护的，不只是代码仓库。
还应该有一个属于自己的：
人生知识仓库。
写在最后
40岁以后，我开始重新理解“积累”这两个字。
以前我以为：
积累就是工作年限越来越长。
后来发现不是。
如果十年的经验只是重复了一年十次。
那也未必是真正的积累。
真正的积累应该是：
经历一次。
记录下来。
复盘一次。
抽象一次。
下一次遇到类似问题时，能够更快地做出判断。
然后再把新的经验写回系统。
于是：
经历 → 记录 → 复盘 → 抽象 → 复用 → 再迭代
慢慢形成一个闭环。
这时候，一个人的职业生涯才开始产生复利。
我现在也在尝试给自己建立这样一份“个人技术文档”。
它可能不漂亮。
甚至一开始很凌乱。
但我希望几十年以后回头看，它不是一堆笔记。
而是一本真正属于自己的：
人生运行手册。
记录我怎么工作。
怎么思考。
怎么做决定。
怎么犯错。
怎么重新开始。
也记录一个40岁程序员，是怎样一点一点，把过去的经验，重新编译成未来可以使用的能力。
因为我越来越相信：
人生最可惜的事情，不是犯过错。
而是：
同一个错误，人生重复运行了很多次。
所以，从现在开始。
把经验留下来。
让它不要只活在记忆里。
让它成为下一次人生迭代时，可以调用的代码。