Linus Trovalds谈Linux内核开发管理风格
英文原文：Linus on kernel management style
译者注：本文号称是 Linux 它爹 Linus Trovalds 亲笔写的关于项目管理的文章。Linus Trovalds 在业界素以脾气火爆，语出惊人而闻名，谁要是让他不爽，他就直接伸出中指来F**k，本文也秉承了他这一贯的风格。尽管没有中国人推崇的谦虚的美德，但是 Linus 在软件领域方面的很多观点是相当有价值和值得分享的，这也是翻译本文的最初动机之一。
在翻译本文的时候，译者诚惶诚恐，生怕理解不到或者误解了大神的观点。限于能力，译者不敢保证翻译一定到位，因此还请各位读者不吝赐教。
关于文中的粗口部分，原文是”d*ckheads“，出于和谐的因素，译者就直接用大家喜闻乐见的”SB”来代替了。其实英文直译的意思要比 SB 重口味得多，感兴趣的读者可以自己查字典。
以下为译文。
这篇短文是描述了一种“理想的”（当然也可以说是“自以为是的”，各种看法因人而异）Linux 内核开发管理风格。这篇文章从某种意义上来说就和编码规范文档差不多，有了这篇文档，就可以避免总是重复地回答同样（或者类似）的相关问题。
管理风格其实是因人而异的，而且很难像编码风格一样，单纯用数量来衡量。因此这篇文档无法保证一定具有实际的参考价值。关于这一点，我们有言在先。你可以根据自己的情况来决定是否接受。
顺便提一下，我们所说的“内核经理”，明确地指（负责内核开发的）技术经理，而不是传统意义上公司内部负责行政的经理。如果你平时的工作涉及到采购或者是制定公司预算，那你基本上就不属于我们讨论的内核经理的范畴。如果是这样的话，本文就不适合你。
首先，我建议读者去买《成功人士的七个好习惯》这本书，然后千万不要读这本书，而是烧掉它。这种行为可以表明一种对所谓成功学的蔑视态度。
本文绝对不会用来回答各种提问，而是要向那些提问者们阐述一个非常痛苦而且明显的事实：你们问的问题我们根本就不知道怎么回答。
废话少说，我们开始：
第 1 章：决策
我们都觉得：经理的主要职责是做决策，而且做决策这件事情是很重要的。决策越大就愈发棘手，就需要职位更高的决策者来决定。这种说法看上去真的是又明显又有道理，但事实并非真的如此。
让我们来做一个叫做“不要做决策”的游戏吧。尤其是，当你被人要求”在A和B中选出一个”的时候，如果你是技术经理，对不起，那你的麻烦就来 了。你手下管的人其实比你更明白各种事情的细节，如果他们都需要让你来做一个选择，那你算是彻底失败了。很明显，你的下属比你更有资格去做正确的决策。
（由同样的逻辑我们可以知道：作为技术经理，如果你手下管的人对技术细节的了解程度还不如你，那你又败了，不管是什么原因。这种局面只能说明：你不适合做技术经理的工作，相反你的下属反而比你更适合这个职位）
所以说，技术经理要“避免做决策”，至少那种又大又难的决策不要轻易做。那种规模较小，影响不大的小决策倒是可以做，并且可以让你看上去称职，所以技术经理要做的事情就是把又大又难的决策拆分成很多无关紧要的小事情，小事情是没有人会真拿它当回事儿的。
这还可以帮助我们认清“大决策”和“小决定”的区别，其主要区别就在于：你是否在事后有机会去纠正错误。如果你要把大事化小，那你一定要确保自 己总是有机会去看看是不是做错了（或者会不会做错），如果错了，你可以浪子回头，避免损失。这样一来，突然你就可以做不同的决定了，正确的决定和错误的决 定，就像灵活而善变的企业管理人员一样。
人们还真把这个当成是“领导才能”的象征（放屁）
其实“避免做大决策”的要义在于“不要做你无法挽回的事情”。不要把自己逼到没有退路。要记住，狗急了能跳墙，兔子急了会咬人，技术经理被逼到走投无路的时候，只会挂掉。
”可挽回“的原则相当清晰明了，就算再荒唐再没大脑，也不会让技术经理去承担主要财务责任。因为花出去的钱就是泼出去的水，无法挽回，唯一能够 挽回的是“技术性决策”，技术性决策的挽回是很简单的：把你手下的弟兄骂到半死，然后再跟所有人说抱歉，然后把去年搞砸的工作从头再来一遍。这样一来，你 去年做的决策就不再是什么大决策了，因为这个决策失败的后果是可以挽回的。
不过有些人可能没法采纳上述的方法，理由有如下两点：
- 承认自己是白痴很难，能这么做更难。我们都要面子，公开场合说谁谁错了这种事情多数时候是不那么容易的。
- 要让别人告诉你，你去年做的工作完全就没有意义，这很毕竟不容易做到。对那些级别很低微的程序员来说也是如此。如果所谓的“重做”就是把他们原来 的工作不分青红皂白地删掉从零开始，这样你很可能就会不可挽回地失去他们的信任。要记住：“不可挽回”是我们要竭尽全力避免的，一开始就是如此，我们要避 免让我们的决策成为一个“大决策”。
- 幸运的是，上面所说的两个理由可以想办法缓解，我们不如一开始就放开心态，大大方方地承认自己其实没有什么好办法，告诉大家现在所做的决定全都是 非常初步的，很有可能出错。你要一直做好改变的准备，并且让大家也都知道你是这么想的。这样就会在你犯错的时候，让自己更加勇于面对和承认自己的愚蠢决 定。
如果你心态开放，那你犯错的时候，人们也只是轻描淡写地说：“瞧，他又错了”。
这种主动放低姿态的方式还会让大家在工作的时候养成三思而后行的好习惯，不管这个工作是不是真的需要那么谨慎。毕竟，如果大家在不是”非常确认 这是个好主意“的情况下，你就不应该承诺说一定让大家的代码纳入到最终产品中。这样你就确保了他们在木已成舟之前充分地进行思考。
记住：你的属下最好比你知道更多的技术细节，并且他们通常觉得自己是万能的。作为内核技术经理，你要做的就是不要去干涉这种自负的情绪，而是要对他们的能力和作为做更深刻的思考。
另外一种“避免做决策”的好办法就是卖萌，技术经理可以可怜兮兮地问：“我们能不能以两个方面都兼顾呢？”。相信我，这招绝对好使。如果两种方 案之间并无明显的优劣之分，你这么一问，你的下属们就会自己去解决问题。最后，分别支持两种方案的双方会各自放弃原来坚持的方案，并且都会非常不爽（但是 能达成妥协性的一致）
也许你觉得这样的做法很失败，但是实际的情况是，很可能两种方案都存在问题，人们之所以无法做出决定，是因为他们都是错的。你的做法，实际上是 中止了双输的局面，虽然会有人不爽，但也是长痛不如短痛，况且，你还成功地避免让自己做一个差劲的选择，如果你不这么做，很可能你就搞砸了。
第 2 章：人
我们身边的人基本上以白痴居多，作为技术经理，就意味着你必须要和这些白痴打交道，这么说还不太确切，确切地说，是他们必须要和你折腾。
技术上犯了错误，我们还可以挽回，但是人如果发神经，那真是不好办。所以你必须要学会处理这些人的神经病，当然，也要学会处理你自己发神经的情况。
然而，为了让你成为一个称职的内核技术经理，你一定要记住：“留得青山在，不怕没柴烧”，对你手下的内核开发人员要学会宽容。很显然，得罪人容易道歉难。因此“得罪”这个词语很立刻地就被归结到“不可挽回”的范畴中去了，这个在我们第一章所说的内容里是严格被禁止的。
那么，为了不得罪人，你应该遵守下面两条规矩：
- 不要用“SB”这种词语问候他人（至少在公开场合不要这么做）
- 如果你违反了第一条，那么要学会怎么给别人道歉
第一点所说的内容是很不容易做到的，因为骂人的办法实在太多了，就算你不用“SB”，还是能找到很多其他同样效果的词语，甚至有的时候，你出口成脏，自己都没有意识，而且往往伴随着极端的狂妄和自负。
你越自以为是（让我们面对事实吧，人人都想随意骂人 SB，并且多数时候你都认为自己是对的），你就越不可能在事后跟人道歉
为了解决这个问题，你只有两个选择：
- 真心诚意给人道歉
- 把爱洒向人间，让每一个人都沐浴在你爱的阳光里，这样就没有人会感受到你的敌意。变得极富创意的幽默，让大家天天笑口常开。
其实后面那种超级好人的做法是不存在的。因为一看就是装出来的，没有人会信任这种人。
保罗.西蒙斯唱过《Fifty Ways to Lose Your Lover》，说实在话，“告诉开发者他们是 SB 的 100 万种方法”这种主题好像和原来那首歌完全不搭调，但是我想西蒙斯也可能会考虑要不要唱一下。
第 3 章：人 II – 如何做好人
如果周围的人都是白痴，很遗憾，你自己也是白痴的一员。在我们躺在自己创造的“周围的人都不如我”的意淫中（说实话，很少有人承认自己水平一般 或者是不行）的时候，我们也该考虑一下承认现实，我们并不敢说自己是独一无二地优秀，身边总是有些人要稍微优秀一些的，而我们自己很可能真的就是个白痴。
“愚者怒，智者用”
作为一个内核的维护者，面对比你更聪明的人，确保你自己是智者。尽情地和他们套近乎吧，因为他们帮你干活，让你的工作更轻松。尤其是，他们甚至还要帮你去做决策，这个行业不就是这么玩儿的么。
所以，当你发现有些人比你聪明的时候，你就“袖手旁观”就对了。你的管理责任多数时候就变成了两种不同的问话：“听上去不错，整吧”，或者“听 上去不错，不过那个 xxx 你觉得怎么样？”。后面那个问法很管用，如果你想了解 xxx 是怎么回事，或者你想委婉地向一个比你更聪明的人表达不同意见的时候，你就可以这么做。不论是哪种情况，你都是最后的赢家。
还有一个事情必须指出，人非圣贤，不可能面面俱到。你想要鞭策你的下属努力向前，但是要认清楚，他们在你要求的方面也许没那么优秀，也许是做什 么错什么。关于这个问题，好的一面是，人类一般都会自觉地回到他们擅长的领域中，所以说不是你自己破釜沉舟，他们就真的能跟你一起破釜沉舟。所以不要逼得 太狠了。
第 4 章：学会处理批评
事情可能会出岔子，而且肯定有人会为此遭受批评。没准这个人就是你。
实际上，被批对任何人来说都是不愉快的，尤其是大家都认为“又不都是我的错”的时候。这样就造就了我们面对批评的最好心态：“替别人承担责 任”。如果你是帮别人承担批评，那一种荣誉感就油然而生，真正该被批评的那个人也因为没有被骂而很高兴，那个因为你们的工作失误而损失了 36 个G的爱情动作片的倒霉客户，虽然非常不爽，但是至少也会对团队敢做敢当的风格表示一下赞许。
接下来，就是找到那个真正惹了麻烦的开发者（如果你真的能找到他的话），私下里跟他说：你搞砸了。这样做的目的一方面是他以后不会将错就错地抵 赖说是你惹的事儿，另一方面是你要让他知道他欠你个人情。接下来，也是很重要的就是，他应该做点儿什么去弥补错误了。实事求是吧，是你搞砸的，又不是我， 总不会让我去弥补吧。
承担批评和责备也是你作为技术经理最重要的职能之一。你的兄弟会因为你敢做敢当而信任你，打心眼儿里佩服你，因为你是那个真正敢把“我们搞砸了”这句话说出口的人。如果你一直是这样的人，那么我相信你现在已经对这个问题处理得如鱼得水了。
第 5 章：该回避的就回避
有一样东西是比直接骂人 SB 更可恨的，就是假装仁义道德地用关心的口吻骂人 SB（“某某某，我这是为你好，我当你们是我的孩子一样，我这是锻炼你……”，耳熟不？ —— 译者注）。骂人 SB 事后还可以道歉，第二种的话真是连道歉的余地都没有了。采用第二种做法，基本上就是自绝于人民，就算你有什么观点是对的，人家也都不再听你的了。
当然，我们每个人都认为自己比别人更优秀，这都可以理解，但是你要是装 13，那就完全是另外一回事了。你或许认为自己很有节操，或者在智力上超群，比你周围的人都优秀，但是不要做得太明显，除非你想刻意激怒别人。
同样的道理，不要刻意强调礼貌，也不要敏感得不得了。礼貌这种东西要么就会让人得寸进尺，要么就暴露不出问题，同样，人们也会说：“在互联网上面，你敏感个头啊，谁会理你？”。如果你要想表达什么观点，那就老老实实地讲给人家听，因此除此之外，没有别的办法能让人明确你到底是什么意思了。
当然，在表达观点的时候讲一点幽默，无论是从人际关系上还是从效果上，都会有所帮助。把观点夸张到极致，甚至是到荒唐的程度，反而可以降低别人对你观点的敌意，哪怕人家一开始认为你简直就是白痴。同样，这种做法还有助于让人与人之间解开心理防备，我们多多少少都有一些这样的问题，不是吗。
提示：有的时候，去那些和你的工作不直接相关的社交媒体上骂一骂口水战，是很有利于你转移对工作的负面情绪的。在这些地方飚一些语言尖锐，冷嘲 热讽的帖子出去，几乎每次都可以让你的情绪得到发泄，然后你的心态就会恢复平静一阵子。但是注意，别去那些人家认识你的地方，以免被人发现。
第 6 章：为什么选我？
作为技术经理，你又要帮别人承担责任和过错，又要在众人面前显示出自己的弱点，那么你一定要问的一个问题就是：“我是做了什么孽？为什么一开始要干这个？”
首先，也许你家里处于青春期狂躁的少女（或者少男，这里我可不想对男女生青春期谁更狂躁做讨论，更不想涉及性别歧视的问题）狂敲你屋子的门对你 大吵大闹，你是不是会感觉到强烈的“责任感”，并且伴随一定的“成就感”？ 其实不要在意你是不是真的跟得上所有人的节奏，也不要在意你能不能赶上其他人的速度。反正在大家的眼里，你就是负责人。
只要能把事情搞定，你就牛了！