Linux内核管理风格 (Linux kernel management style) (zt)

第一次转贴文章. 英文原文在http://lwn.net/Articles/105375/, 汉语翻译来自Harmony GC的主要作者Xiao-Feng Li。所有版权归原作/译者所有。转贴在此不代表本人赞成或反对其观点，只是觉得原文和翻译都很赞...嘿嘿。

(zt from Xiao-Feng Li's blog )

Linux内核管理风格 (Linux kernel management style)

（中文翻译：Xiao-Feng Li）

这个短文档介绍了Linux内核所偏爱的（或“造作的”--看你问谁了）管理风格。目的是与文档《CodingStyle》的内容在某种程度上相呼应，主要是为了避免一遍又一遍地回答[1]同样（或类似）的问题。

管理风格非常个人化，很难量化，比几条简单的关于编码风格的规定要难多了，因此这个文档与实际可能有联系，也可能没有联系。开始写时只是闹着玩的，不过也不能说它完全没用。这个只能由你自己决定了。

顺便说一句，当提到“内核管理者”时，指的是技术带头人，而不是公司里的那些传统的管理人员。如果你在你们公司里要签单、或者对你们部门的预算有点儿概念的话，那你基本上可以肯定不是内核管理者。因此这里的建议可能不一定对你有用。

首先，我建议你买一本《高度成功人士的七个习惯》，_不_要读它。烧掉它，这是一个很重要的象征性姿态。

[1] 本文档并没有真地回答什么问题，而是要让提问题的人不得不明白：我们并不知道答案是什么。

好吧，下面开讲：

第一章：决定

大家都以为是管理者在做决定，而且以为做决定很重要。以为决定越大、越难，管理者就一定越高层。这看起来很深刻也很明显，其实不一定正确。

问题的诀窍在于_避免_做决定。特别是当有人对你说“请选择(a)或(b)，我们真地需要你做出决定”时，你作为一个管理者就有麻烦了。因为你管理的人应该比你知道更多的细节，如果他们需要你来做出技术决定，你一定麻烦大了。显然你没有能力替他们做出决定。

（推论：如果你的手下不比你了解更多的细节，你一样死定了，尽管死的原因与前面完全不同。这种情况下，看起来你不适合这个管理工作，应该是_他们_来管理你的才华才对。）

因此问题的诀窍是_避免_做决定，至少避免做大的、难的决定。可以做一些小的、没有什么后果的决定，这会让你看起来象是知道你自己在做什么。所以内核管理者要做的就是把大的、难的决定转变成没人在意的小问题。

需 要明白的是，大决定和小决定之间的真正区别在于：你是否可以在后来修正你的决定。任何决定都可以变成一个小决定，只要你能确保下面这条：即在你可能错了的 时候（你_一定_会错的），你总能回过头将其影响消除。这样，突然之间，你变得具有两倍的管理才能：你做出了_两个_没有后果的决定--一个错误的_和_ 一个正确的。

而且人们甚至会认为这是真正的领袖素质（咳，狗屁，咳）。

这样，避免做决定的关键就变成了如何避免做任何不能挽回的事情。不要被堵在一个无处逃生的死胡同。死胡同里的耗子会很危险--而一个死胡同里的管理者就太可怜了。

实 践证明，由于_在任何情况下_都没有人会蠢到真得让内核管理者去承担巨大的财政责任，因此Linux内核中的决定通常是很容易挽回的。既然你没有机会糟蹋 掉一大笔你还不起的钱，你需要挽回的也就是一个技术决定而已；而对技术决定来说，挽回措施也相当容易：只需要告诉别人你是一个手生的笨蛋，说你很抱歉，然 后去除那些你让大家在过去的一年里做的没用的东西。立刻，你一年前所做的决定就根本不是一个大决定了，因为它的影响可以被轻易地消除。

实践证明有些人对这个方法不是很适应，由于下面的两个原因：
- 承认自己是个白痴比想像的要难。我们都要维护自己的形象，到大庭广众之下说自己错了有时候的确非常困难。
- 对那些可怜的底层工程师来说，要别人告诉他们去年做的东西完全没用会有些难度。尽管实际的_工作_本身可以简单地删除掉，你却可能不可挽回地失去那个工程师的信任。记住：“不可挽回”是我们首要竭力避免的，因此你的决定最终还是成了一个大决定。

比 较愉快的是，这两个问题的难度都可以被有效地降低：只要你实现承认自己不是特别明白；并在实施之前告诉大家，你的决定很初步，很有可能是错的。你应该一直 保留改变主意的权利，并让大家非常_清楚_这一点。其实，在你还没有做蠢事之前承认自己愚蠢，要比做了之后要容易的多。

这样，当最终被证明是件蠢事时，人们最多也就转转眼睛，说“唉，他又犯傻了”。

这种事先承认没有把握的做法，也会让那些真正干活的人好好想想是否值得做这件事。千万记住，如果连_他们_都不能肯定，你一定不要用许诺的方法来鼓励他们，即承诺他们的工作会被加到Linux内核中。还是要让他们在启动一项大任务之前深思熟虑一下。

记住：他们会比你知道更多的细节，而且他们通常认为他们对一切相关问题都已了然于胸。这个时候，管理者最好不要再去给他们吃定心丸了，而是给他们一剂用挑剔的眼光审视任务的苦口良药。

顺便提一句，另一种避免做决定的办法是简单地嗔怪道：“我们不能两个都做吗？”并做出一副可怜相。相信我，这的确有效。如果还不清楚到底那个方法更好，他们最终一定会搞清楚的。很可能的结果是，两个小组都对结论感到失望并就此放弃。

放弃听起来似乎是个失败，但这通常是一个信号，表明两个项目都有问题，而两个小组的成员都不能下决定的原因可能就是因为他们都错了。这样你最后倒成了香饽饽，而且你还避免了又一个可能让你死菜的决定。

第二章：人

大多数人是白痴，做为管理者，你必须面对现实、和他们周旋。或许更重要的是，_他们_必须要和_你_周旋。

事实证明，虽然消除技术错误很容易，消除人性的混乱却不容易。你必须与别人的个性共处--以及与你自己的个性共处。

不过，要准备成为一个内核管理者，你最好记着不要断了自己的后路、殃及无辜、或与太多的内核开发者作对。事实证明，与人闹翻很容易，可再想和好就不容易了。因此“闹翻”立刻可以归类为“不可挽回”的行为；按照第一章，绝对应该避免。

有几条简单的规则：
(1) 不要称呼别人“蠢货” （至少不要在公开场合）
(2) 当你忘了(1)时，就学会道歉

(1)的问题是它太容易违反了。你可以有一万种不同的方式骂别人“蠢货”[2]，有时候你甚至都没有意识到，而且哪一次你都是不可抑制地义愤填膺。

而且你越是相信你是对的（面对现实吧，你其实可以称呼_任何人_“蠢货”，而且你总_会_是对的），事后道歉对你来说会越难。

要解决这个问题，你只有两个选择：
- 成为道歉高手
- 把你的“爱”均匀播洒，让大家觉得你的出手是公平的。你得有点儿创意，这样他们有时候可能还会觉得挺好玩儿的。

希望靠着礼貌把一切摆平是不可能的。没有人会信任一个明显隐藏自己真实性情的人。

[2]保罗西蒙过去唱《失去爱人方法五十种》，那是因为很明白，《告诉一个开发者是蠢货的方法一万种》听起来没有前者那么有韵味。不过我相信他考虑过后者。

第三章：人 II - 好的那类

既然事实表明大多数人都是白痴，那结论自然很可悲：你也是一位。另外，即使我们都暗自觉得自己高于普通人（承认吧，没有人认为自己是普通人甚至不如普通人），我们也要承认我们不是那只最锋利的刀子，总有人没有你那么白痴。

有些人容不下聪明人。有些人则会利用他们。

作为一个内核的维护者，你要确保你属于第二种。你要紧随聪明人，因为他们能让你的工作变得容易。特别是，他们能替你做决定。这就是问题所在。

因 此，如果你发现有人比你聪明，那就顺水推舟吧。之后你的管理任务就变成诸如“听起来不错--去搞吧”，或者“这个听起来挺好，不过那个xxx怎么样？”。 特别是第二种说法，你要么能跟着学点儿“xxx”的东西，要么能显示_额外_的管理才干，因为你指出了一些聪明人没有想过的东西。不管是哪种情况，你都是 赢家。

值得提出的是，你要明白，在一个领域的牛人在另一个领域就不一定了。因此尽管你可能在几个不同的方向上给与引导激励，需要承认的 是，他们可能只在他们自己的领域是专家，而在其它领域一无是处。值得庆幸的是，人们会自然地象被引力吸引一样被拉回他们擅长的领域。因此，只要你不是激励 的太厉害，那么即使你真地在其它方向上引导了他们，也不至于造成不可挽回的后果。

第四章：责任追究

任何事情都回出错，因此人们需要找个人来承担责任。不好意思，你就是这个人。

承担责任其实并不困难，特别是当人们明白并不全是你的错。这给我们提醒了一种最好的承担责任的方式：承担他人的责任。你会因为替人受过而感觉高尚，他也会因为免于责任而感觉不错。那个由于你的过错而丢失了36GB收藏的家伙也不得不承认，你至少没有试图逃避责任。

然后你要_私下里_让那个真正把事情搞砸的人（如果你能找出他来）知道，是他把事情搞砸了。并不是说他因此就可以避免以后再出问题，而是因此他知道他欠你一个人情。而且，也许更重要的是，他很可能也是那个能修正问题的人；因为，我们得承认，那个人肯定不是你。

承担责任也是你能成为管理者的首要原因。这是别人愿意信任你、并给你可能的荣誉的部分原因，因为正是你能站出来说“是我搞砸了”。如果你已经遵循了前面的规则，现在说这句话对你来说应该很容易了。


第五章：需要避免的东西

有一件事比骂人“蠢货”更让人不能接受，那就是用假惺惺的口气叫人“蠢货”。 前者还可以道歉，后者则没有机会。别人不会再听你的了，即使在你做的很漂亮的时候。

我们每个人都认为自己比别人强，当别人在充大个时，我们会错误地觉得自己_真地_被看扁了。因此，也许你在道德或智力上的确高于他人，但不要太显摆了，除非你是有意要惹恼某个人[3]。

同样，也不要太礼貌或太微妙了。礼貌很容易过度从而掩盖真正的问题，而且正如人们所说：“在互联网上，没人能听出来你的微妙”。因此，还是要大张旗鼓地摆明你的观点，不能寄望人们能揣摩出你的意思。

加点儿幽默能中和你的鲁直和说教。如果你过分到显得荒谬，反倒可以达到你的目的，且不会让接受者感到不爽，他只会觉得你傻的可爱。因此幽默可以帮助克服人性的障碍，而这个障碍这是我们在对待批评时所共有的。

[3]提示：互联网上那些与你的工作无直接关系的讨论组是发泄对他人不满的好地方。每隔一阵儿，带着嘲弄发些讨厌的帖子加入一场论战，会让你感到神清气爽。只是别把垃圾甩在自家门口了。

第六章：为什么是我？

既然你的主要任务是替人受过，并且还要痛苦地让所有的人看出来你是个生手，那么一个显然的问题是：当初干嘛要干这个？

本 质上说，尽管可能不会有十来岁的小姑娘（或小男孩，这里我们不需要提出甄别或扮演性别主义者）尖叫着追到你的更衣室外敲门，你也_必将_由于是“负责人” 而获得巨大的个人成就感。尽管你的所谓领导其实就是竭力追上别人并在其后尽力飞奔，你就不要太在意这些了，因为所有的人仍然会认为你就是负责人。

如果你能把这个问题搞定，那将是一项伟大的成就。

=======================================================================
Original from http://lwn.net/Articles/105375/
[Posted October 6, 2004 by corbet]

Linux kernel management style

This is a short document describing the preferred (or made up, depending on who you ask) management style for the linux kernel. It's meant to mirror the CodingStyle document to some degree, and mainly written to avoid answering (*) the same (or similar) questions over and over again.

Management style is very personal and much harder to quantify than simple coding style rules, so this document may or may not have anything to do with reality. It started as a lark, but that doesn't mean that it might not actually be true. You'll have to decide for yourself.

Btw, when talking about "kernel manager", it's all about the technical lead persons, not the people who do traditional management inside companies. If you sign purchase orders or you have any clue about the budget of your group, you're almost certainly not a kernel manager. These suggestions may or may not apply to you.

First off, I'd suggest buying "Seven Habits of Highly Successful People", and NOT read it. Burn it, it's a great symbolic gesture.

(*) This document does so not so much by answering the question, but by making it painfully obvious to the questioner that we don't have a clue to what the answer is.

Anyway, here goes:


Chapter 1: Decisions

Everybody thinks managers make decisions, and that decision-making is important. The bigger and more painful the decision, the bigger the manager must be to make it. That's very deep and obvious, but it's not actually true.

The name of the game is to _avoid_ having to make a decision. In particular, if somebody tells you "choose (a) or (b), we really need you to decide on this", you're in trouble as a manager. The people you manage had better know the details better than you, so if they come to you for a technical decision, you're screwed. You're clearly not competent to make that decision for them.

(Corollary:if the people you manage don't know the details better than you, you're also screwed, although for a totally different reason. Namely that you are in the wrong job, and that _they_ should be managing your brilliance instead).

So the name of the game is to _avoid_ decisions, at least the big and painful ones. Making small and non-consequential decisions is fine, and makes you look like you know what you're doing, so what a kernel manager needs to do is to turn the big and painful ones into small things where nobody really cares.

It helps to realize that the key difference between a big decision and a small one is whether you can fix your decision afterwards. Any decision can be made small by just always making sure that if you were wrong (and you _will_ be wrong), you can always undo the damage later by backtracking. Suddenly, you get to be doubly managerial for making _two_ inconsequential decisions - the wrong one _and_ the right one.

And people will even see that as true leadership (*cough* bullshit *cough*).

Thus the key to avoiding big decisions becomes to just avoiding to do things that can't be undone. Don't get ushered into a corner from which you cannot escape. A cornered rat may be dangerous - a cornered manager is just pitiful.

It turns out that since nobody would be stupid enough to ever really let a kernel manager have huge fiscal responsibility _anyway_, it's usually fairly easy to backtrack. Since you're not going to be able to waste huge amounts of money that you might not be able to repay, the only thing you can backtrack on is a technical decision, and there back-tracking is very easy: just tell everybody that you were an incompetent nincompoop, say you're sorry, and undo all the worthless work you had people work on for the last year. Suddenly the decision you made a year ago wasn't a big decision after all, since it could be easily undone.

It turns out that some people have trouble with this approach, for two reasons:
- admitting you were an idiot is harder than it looks. We all like to maintain appearances, and coming out in public to say that you were wrong is sometimes very hard indeed.
- having somebody tell you that what you worked on for the last year wasn't worthwhile after all can be hard on the poor lowly engineers too, and while the actual _work_ was easy enough to undo by just deleting it, you may have irrevocably lost the trust of that engineer. And remember: "irrevocable" was what we tried to avoid in the first place, and your decision ended up being a big one after all.

Happily, both of these reasons can be mitigated effectively by just admitting up-front that you don't have a friggin' clue, and telling people ahead of the fact that your decision is purely preliminary, and might be the wrong thing. You should always reserve the right to change your mind, and make people very _aware_ of that. And it's much easier to admit that you are stupid when you haven't _yet_ done the really stupid thing.

Then, when it really does turn out to be stupid, people just roll their eyes and say "Oops, he did it again".

This preemptive admission of incompetence might also make the people who actually do the work also think twice about whether it's worth doing or not. After all, if _they_ aren't certain whether it's a good idea, you sure as hell shouldn't encourage them by promising them that what they work on will be included. Make them at least think twice before they embark on a big endeavor.

Remember: they'd better know more about the details than you do, and they usually already think they have the answer to everything. The best thing you can do as a manager is not to instill confidence, but rather a healthy dose of critical thinking on what they do.

Btw, another way to avoid a decision is to plaintively just whine "can't we just do both?" and look pitiful. Trust me, it works. If it's not clear which approach is better, they'll eventually figure it out. The answer may end up being that both teams get so frustrated by the situation that they just give up.

That may sound like a failure, but it's usually a sign that there was something wrong with both projects, and the reason the people involved couldn't decide was that they were both wrong. You end up coming up smelling like roses, and you avoided yet another decision that you could have screwed up on.


Chapter 2: People

Most people are idiots, and being a manager means you'll have to deal with it, and perhaps more importantly, that _they_ have to deal with _you_.

It turns out that while it's easy to undo technical mistakes, it's not as easy to undo personality disorders. You just have to live with theirs - and yours.

However, in order to prepare yourself as a kernel manager, it's best to remember not to burn any bridges, bomb any innocent villagers, or alienate too many kernel developers. It turns out that alienating people is fairly easy, and un-alienating them is hard. Thus "alienating" immediately falls under the heading of "not reversible", and becomes a no-no according to Chapter 1.

There's just a few simple rules here:
(1) don't call people d*ckheads (at least not in public)
(2) learn how to apologize when you forgot rule (1)

The problem with #1 is that it's very easy to do, since you can say "you're a d*ckhead" in millions of different ways (*), sometimes without even realizing it, and almost always with a white-hot conviction that you are right.

And the more convinced you are that you are right (and let's face it, you can call just about _anybody_ a d*ckhead, and you often _will_ be right), the harder it ends up being to apologize afterwards.

To solve this problem, you really only have two options:
- get really good at apologies
- spread the "love" out so evenly that nobody really ends up feeling like they get unfairly targeted. Make it inventive enough, and they might even be amused.

The option of being unfailingly polite really doesn't exist. Nobody will trust somebody who is so clearly hiding his true character.

(*) Paul Simon sang "Fifty Ways to Lose Your Lover", because quite frankly, "A Million Ways to Tell a Developer He Is a D*ckhead" doesn't scan nearly as well. But I'm sure he thought about it.


Chapter 3: People II - the Good Kind

While it turns out that most people are idiots, the corollary to that is sadly that you are one too, and that while we can all bask in the secure knowledge that we're better than the average person (let's face it, nobody ever believes that they're average or below-average), we should also admit that we're not the sharpest knife around, and there will be other people that are less of an idiot that you are.

Some people react badly to smart people. Others take advantage of them.

Make sure that you, as a kernel maintainer, are in the second group. Suck up to them, because they are the people who will make your job easier. In particular, they'll be able to make your decisions for you, which is what the game is all about.

So when you find somebody smarter than you are, just coast along. Your management responsibilities largely become ones of saying "Sounds like a good idea - go wild", or "That sounds good, but what about xxx?". The second version in particular is a great way to either learn something new about "xxx" or seem _extra_ managerial by pointing out something the smarter person hadn't thought about. In either case, you win.

One thing to look out for is to realize that greatness in one area does not necessarily translate to other areas. So you might prod people in specific directions, but let's face it, they might be good at what they do, and suck at everything else. The good news is that people tend to naturally gravitate back to what they are good at, so it's not like you are doing something irreversible when you _do_ prod them in some
direction, just don't push too hard.


Chapter 4: Placing blame

Things will go wrong, and people want somebody to blame. Tag, you're it.

It's not actually that hard to accept the blame, especially if people kind of realize that it wasn't _all_ your fault. Which brings us to the best way of taking the blame: do it for another guy. You'll feel good for taking the fall, he'll feel good about not getting blamed, and the guy who lost his whole 36GB porn-collection because of your incompetence will grudgingly admit that you at least didn't try to weasel out of it.

Then make the developer who really screwed up (if you can find him) know _in_private_ that he screwed up. Not just so he can avoid it in the future, but so that he knows he owes you one. And, perhaps even more importantly, he's also likely the person who can fix it. Because, let's face it, it sure ain't you.

Taking the blame is also why you get to be manager in the first place. It's part of what makes people trust you, and allow you the potential glory, because you're the one who gets to say "I screwed up". And if you've followed the previous rules, you'll be pretty good at saying that by now.


Chapter 5: Things to avoid

There's one thing people hate even more than being called "d*ckhead", and that is being called a "d*ckhead" in a sanctimonious voice. The first you can apologize for, the second one you won't really get the chance. They likely will no longer be listening even if you otherwise do a good job.

We all think we're better than anybody else, which means that when somebody else puts on airs, it _really_ rubs us the wrong way. You may be morally and intellectually superior to everybody around you, but don't try to make it too obvious unless you really _intend_ to irritate somebody (*).

Similarly, don't be too polite or subtle about things. Politeness easily ends up going overboard and hiding the problem, and as they say, "On the internet, nobody can hear you being subtle". Use a big blunt object to hammer the point in, because you can't really depend on people getting your point otherwise.

Some humor can help pad both the bluntness and the moralizing. Going overboard to the point of being ridiculous can drive a point home without making it painful to the recipient, who just thinks you're being silly. It can thus help get through the personal mental block we all have about criticism.

(*) Hint: internet newsgroups that are not directly related to your work are great ways to take out your frustrations at other people. Write insulting posts with a sneer just to get into a good flame every once in a while, and you'll feel cleansed. Just don't crap too close to home.


Chapter 6: Why me?

Since your main responsibility seems to be to take the blame for other peoples mistakes, and make it painfully obvious to everybody else that you're incompetent, the obvious question becomes one of why do it in the first place?

First off, while you may or may not get screaming teenage girls (or boys, let's not be judgmental or sexist here) knocking on your dressing room door, you _will_ get an immense feeling of personal accomplishment for being "in charge". Never mind the fact that you're really leading by trying to keep up with everybody else and running after them as fast as you can. Everybody will still think you're the person in charge.

It's a great job if you can hack it.