成为优秀的程序员（02）：管理的目的

如果需要查看系列中的其它文章，请使用 tag 跳转到文章目录界面：#becoming-an-brilliant-programmer。

感谢 MD-20880 的催更，这一次更新就来继续写这个系列吧。

其实我这篇文章已经写了好几个月了，但是需要工作的时候，精力被占用得真的很严重。这导致我每次有空续写的时候都和上一次间隔一两个礼拜以上，即使已经提前写好了大纲，还是要花很多时间重新读一次以前写的内容才能和过去的自己接续起来。

痛定思痛，在好几个月都没办法出一篇更新的情况下，我决定把这篇文章拆成几篇更短的文章来发。这样一方面我手里能有更多的存货，另一方面也可以给内容分一个章节，方便快速回忆起之前写了什么。

第一篇文章，先讲讲为什么我会选择“管理”作为这几篇文章的主题。

为什么要聊管理

在一个主题是“程序员”的系列中，第二篇文章就讲到“管理”这个话题，乍看是蛮奇怪的。但我认为，对于一个优秀的程序员来说，管理是终其一生的职业生涯中始终无法避开的话题。

作为一个坦诚的人，我也不得不说，这么早讲到管理，也有一些我个人的私心在里面。有看了最近几篇文章的读者可能发现了，我最近刚刚换了一个新工作，从原先被迫担任的管理岗切换到了一个类似于 IC 的岗位。

意料之外的是，即使在这样一个看似和管理无关的岗位上，原先管理岗的经验也给了我很大帮助；另一方面，因为不再实际进行管理工作，我其实很担心几年之后，我会将之前的这些经验逐渐淡忘。

所以我希望把自己的经验尽早分享出来，这样也能作为一个给自己的大纲，在今后随时回顾。

逃不开的管理

大部分“普通”的程序员，职业路径基本都是走向管理岗，带领一个几十、几百甚至几千人的团队，这也是最世俗的躲避 35 岁危机的方式。虽然我自己并没有选择这条路，但是我并不认为这是一种不好的选择， 反而是适合更多人的选择。

而部分程序员，则可能会选择 IC 路线。IC 即 Individual Contributer，通常在大一些的公司里，总能在附近的几个组找到一些 IC。简单来说，可以认为 IC 是有很强技术能力、能独立负责一些大型的项目，但是又不负责人员实际管理的一种更技术的方向。

选择了 IC 路线，并不意味着要和管理完全隔绝。诚然，IC 通常在公司中有着更高的自由度，负责的工作也更贴近技术。但是一个只知道写代码的 IC，通常不太可能是一个最优秀的 IC。

事实上，绝大部分的软件项目，最终都还是为了产品目标服务的。这也是上一篇文章 中将软件行业描述得如此摇摇欲坠，但软件行业依旧稳定存在的原因：只要能完成主要的产品目标，一切屎山都是可以被容忍的（直到产品目标都完不成了为止，也就是屎山崩塌的那一刻）。所以，当一个人完全不了解组织是如何运转的时候，他也就很难参与到这个组织的工作中；同时，了解产品的最好途径就是每一个已经了解这个产品的人。与世隔绝的 IC 或许可以独立完成一个不错的项目，但是绝对没有办法解决超出个人资源极限的问题。

更进一步，如果我不仅仅满足于当一个 IC，而是希望做一个独立程序员，自己开发自己的软件，我是不是就能摆脱管理的困境，完全随心所欲地开发了呢？

事实上，我认为任何一个独立程序员，都需要比在公司打工的程序员更懂得管理。一方面，独立程序员意味着你要自己完成原先公司中可能十几个岗位合作完成的工作，和人打交道是不可避免的。另一方面，即使仅仅限于软件上，任何一个独立开发过软件项目的人大概都能感受到，一个人写代码更容易写出难以维护的东西。如果要避免这个问题，那么你就必须先学会如何自己管理自己，而这其实是比在公司里管理一个小组更进阶的工作。

当然，或许每个程序员都听说过一些“上古神犇”的传说，在这些传说里他们一个人开发了一整套软件，完成了一个团队都无法完成的工作。

诚然，这样的程序员是存在的。但我们也不得不承认，这样的人凤毛麟角，而他们写出的软件，通常也都有着大众视角中各种各样的“缺点”——正因为他们在开发过程中能够决定过多的事情，这些软件与其说是一些工具，不如说是这些大师的艺术作品。

因为这一系列文章的受众毕竟还是和我一样普通甚至刚入行的程序员，参考这些大师的例子是没有必要的。我相信他们在我这个年龄的时候，甚至更年轻的时候，也不需要我这样的浅薄建议。我们不妨放下身段，以更世俗的眼光审慎地看一看自己真正需要的东西是什么。

管理带来了什么

看到这里，或许你认同了管理能力对于程序员是必须的，亦或你还不认同这个观点。

没有关系，我们可以换一个角度考虑：管理究竟给软件开发带来了什么？

事实上，这个问题在上一篇文章已经得到了一些解答：

好消息是，程序员（以及所有相关的职业，恕后文不一一列举）学会了通过抽象来隔离理解成本。

说起管理，包括我在内的绝大多数程序员脑海中想象到的一定是当老板，带团队。但为什么我们需要“团队”，它是为什么产生的？

当软件的规模发展到一定程度的时候，他一定会超出个人的开发和维护能力上限。这可能是因为软件功能过多，来不及全部完成；也可能是因为软件开发的时长拖得过久，以至于一些早期的代码和设计已经被忘记；说到底还是时间的问题。

人类就是这样，一辈子都在和时间做斗争，但是最终还是会带着不甘输给时间。

而解决这些问题的方式，正如上一篇文章所讲，就是合理的抽象。但当我们做出了抽象设计以后，下一个问题就随之出现，也是上一篇文章着重提到过的事情：

一方面清楚地知道进一步抽象会导致程序员们越来越少地理解其它抽象层，一方面又期望程序员们更多地理解其它抽象层——这就是今天软件行业的困境。

对，就是“理解”。对系统进行抽象之后，我们将问题从理解整个系统转化为了理解抽象。这减少了“理解”本身的成本，但是带来了“如何理解”的额外成本。

说到底，管理本身就是一种维护“如何理解抽象”的工作。让每个人精确地理解自己最需要理解的那部分抽象，才能让这个系统运转得更高效和顺畅。

下集预告

在下一篇文章中，我会介绍以多年的个人经验总结出的两种管理模式，以及它们的异同。

不过我最近其实刚刚接受了一个采访，但是最终出的稿件实在是有点不知所云，和我想表达的内容完全没有关联，这让我有点想把采访时的回答整理一下发出来。在更新下一篇这个系列之前，我可能会插入一篇或者几篇这个采访中的内容总结出来的文章。

又或者，马上到十一假期了，这个假期我会和几个朋友一起去青甘环线走一圈（Exun：6），所以下一次的更新可能是旅游日记也说不定？