现代管理学的精髓，就是让每个人（包括老板本人）都变得可替代。如果你觉得自己不可替代，要么是你的错觉，要么是你在一家管理非常原始的、摇摇欲坠马上要完蛋的公司。

怎样让程序员变得可替代？三个字：写文档。不愿意写文档的程序员，应该立刻马上毫不犹豫地开掉。程序员工作创造的价值，至少一半是通过文档体现出来才对。“一个项目换一个人就要让项目大地震一下、解决 bug 换一个人就不行因为只有老人知道要改哪一行的哪个关键字”，这不说明这个项目所涉及的技术有多复杂、不说明这个老人是什么技术大牛，而只说明这个项目的项目经理是蠢货因为这个项目已经失控了。

**======== 下面展开一点谈文档和技术驱动 ========**

给正在 code 的自己看、给几个月后已经忘记这个模块当初是怎么开发的自己看、给要接手自己工作的新人看、给周边有关联开发任务的同事看、给领导等有关人员看、产品出 bug 的时候用来和别人怼的武器。如果没有文档，这些工作量都会成倍增长。

上面这一段话，就是你要写的文档，这个文档的读者主要是你，在你的模块出问题之前，别人通常不会读这个文档（不排除你的领导会要求看你这个文档）。如果你既不需要时序图又不需要类图又没什么协议需要明确，那么，你就可以不写这个文档。另外，如果这个文档写得好，你的代码是不需要任何注释的。

接着上面的“三个 bug”继续：另外两个 bug，是概率发生且发生概率很低。这个时候如果工期比较赶，**公司会想办法绕过去这两个 bug，比如定时重启服务器、定时清理缓存等（这些方法通常可以绕开低概率 bug），不会给你“潜心研究三个月然后把 bug 解决”的机会的。**什么时候才有可能让你继续研究这两个 bug 呢？和第一个 bug 一样，只有在后续继续开发，才**有可能**让你继续跟进。

现在，请各位再重新品味一下“技术驱动”这个词。到底什么是技术驱动？其实这个词真正的含义就是：我们公司效益很好能养活 nb 的技术团队所以产品能不断迭代演进开发，随着产品的不断迭代，技术人员**有可能**会遇到一些其他公司遇不到的问题。所以，如果一家新成立的小公司说自己是技术驱动的……连 1.0 版本的产品都没有就敢说自己是技术驱动？你信吗？不管你信不信，反正我不信。

简而言之，“技术驱动”的同义词就是“我们公司很有钱”+“我们公司不是炒股炒房而是做产品的公司”。至于为什么不直接这么说呢？这是因为这种说法不容易被十年寒窗苦读潜心研究技术的同学接受……被“技术驱动”迷惑的同学，其实就是读书读傻了，什么叫“读书读傻了”？就是把社会和学校等同成同样的东西……

“很有钱的做 IT 产品的公司”，这个世界上当然是有的，但是这样的公司，根本不会用“技术驱动”这种词来忽悠新人。