天才的传说
首先我们要澄清一件事情：我们实际上不是体育迷。每次我们的太太们在电视机前为了篮球或者足球比赛欢呼雀跃的时候，我们总会挠挠头皮觉得这有什么好激动的。但不管怎么说，我们毕竟是见证了20世纪90年代初芝加哥公牛队的辉煌（顺便说一句，这是一支篮球队）。我们当时都住在芝加哥，全国媒体在这里聚集了好多年，来报道这支传奇球队。
那么我们在电视和报纸里听到最多的是什么？不是球队本身，而是迈克尔·乔丹，球队的超级巨星。全世界的球员都想成为乔丹那样的明星。我们可以看到他在其他球员周围跳舞转圈圈，在电视广告里也能看到他。他演了一部很傻的电影，在其中他和一群卡通人物一起打球。他是大明星，每个小孩子都会在球场里偷偷练习打篮球，希望将来有一天也能像他一样。
程序员其实也一样，我们也会有自己崇拜的偶像。莱纳斯·托瓦兹、理查德·斯托曼、比尔·盖茨—这些改变了世界的英雄都作出了了不起的贡献。毕竟莱纳斯靠自己就写出了Linux不是吗？
其实莱纳斯只是写了一个可以工作的类UNIX内核的初级版本，然后把它贴到了邮件列表上而已。这并不是一项简单的任务，而且它也的确是一项了不起的成就，但是这真的只是冰山一角而已。Linux的规模是这个的几百倍，有几百名聪明绝顶的程序员参与了开发。莱纳斯真正的成就是领导并协调他们的工作，Linux之所以如此耀眼完全是这些人通力合作的结果（另外，UNIX也是由贝尔实验室里的一小群天才写出来的，并不完全是肯·汤姆森和丹尼斯·里奇的功劳。）
同样的，自由软件基金会的软件都是由斯托曼编写的吗？他编写了第一版Emacs，而bash、GCC，以及所有其他运行在Linux上的软件都是由几百名程序员负责的。史提夫·乔布斯领导的团队开发了麦金塔电脑，还有比尔·盖茨，尽管他为早期的家用电脑编写了BASIC解释器，但其实他更大的贡献是围绕MS-DOS创办了一家成功的软件公司。可是这些集体荣誉都被算在了他们这些领袖的头上。
那么迈克尔·乔丹呢？我们还是一样崇拜他，但事实上他是不可能靠自己一个人就赢得每一场篮球赛的，他真正天才的地方是他和球队一起打球的方式。球队教练菲尔·杰克逊是非常聪明的一个人—他的教练水平是毋庸置疑的：他知道单靠一名球员是无法赢得冠军的，所以他围绕乔丹打造了一支“梦之队”。这支队伍干劲十足，耀眼程度完全不亚于乔丹。
既然如此，我们为什么还是不断地去崇拜这些故事里的主角呢？人们为什么为明星代言的产品掏钱？为什么我们会想要去买米歇尔·奥巴马的裙子和迈克尔·乔丹的球鞋？
明星的号召力是很大的。人类会本能地去寻找领导者和榜样，崇拜他们，然后模仿。我们都需要榜样的激励，编程世界也不例外，“技术英雄”的现象几乎都要被神化了。我们都想要写出像Linux那样改变世界的东西，或是设计一门了不起的程序语言。
从内心深处来讲我们都默默地希望自己是天才。极客的终极梦想就是得到一个激动人心的灵感，然后闭关数周甚至数月将它完美地实现出来，最后向全世界发布自己的作品，名动天下。同行们会折服于你的聪明才智，人们会排着队来买你的软件，名望和财富更是唾手可得。
不好意思先等一下：醒醒吧，你很可能不是什么天才。
当然我们并无恶意，你肯定是一个很聪明的人，但是你知道这个世界有多少真正的天才吗？的确，你能写代码，拥有这种能力已经算是人群里的聪明人了，但问题在于即便你真的是天才也是不够的。天才也会犯错，好点子和高超的技术并不是软件成功的充分条件，你的职业生涯能否成功完全要看你能不能与人合作。
事实上所谓的天才传说只是我们缺乏安全感的一种表象罢了。很多程序员都害怕和别人分享他刚刚开始做的东西，因为这意味着同行会看到他们的错误，从而知道这些代码背后的作者并非天才。这里引用本的博客上某位程序员的留言：
这是程序员这个人群里很普遍的看法，所以最自然的反应就是躲起来不断地努力工作。只要没人看到你犯错，你就还有机会最终一鸣惊人。所以产品完善之前还是先藏拙吧。
不愿献丑的另一个原因是害怕别的程序员会偷走你的创意，然后抢先发布。所以只要保持低调，创意就不会被偷走了。
我们知道你现在可能会想：那又怎么样？难道我们不能按照自己的方式工作吗？
事实上还真的不能。我们可以断定你这样做是不对的，而且错得离谱。让我们来告诉你为什么。
隐瞒是有害的
假如你一直都是单打独斗的话，你其实是增加了自己失败的风险，而且浪费了自己成长的可能性。
首先，你怎么知道自己选的路是对的
假设你是一名狂热的自行车设计师，有一天你想到了一个绝妙的主意，设计出一个具有颠覆性的换挡装置。你订购了零件，然后在车库里泡了好几个星期来制作原型。当你的邻居（他也是自行车爱好者）问你最近在忙什么的时候，你想还是先保密好了。在这个设计完善之前，你不想任何人知道它的存在。几个月以后，你遇到了瓶颈，没有办法令原型正常工作，但由于这个项目是保密的，所以也没办法向你的机械师朋友们寻求帮助。
直到有一天，你的邻居从他的车库里推出一辆自行车，上面有一个全新设计的换挡装置。其实他也一直在建造一个和你的设计类似的东西，只不过他有自行车行的朋友帮他的忙。这时你一定非常窝火吧。你把自己的东西拿给他看，他立刻就指出了你在设计上存在的缺陷—要是你早点拿出来的话，搞不好这些缺陷在一开始就修复了。
这里我们可以得到好几个教训。真正做出产品之前不愿分享好创意实际上是一场很大的赌博，你很容易在一开始就犯下很基本的错误，你有可能是在重新发明轮子。还有你完全丧失了合作的好处。注意到你的邻居和别人合作后进展有多快了吗？这正是为什么人们在跳进泳池前会拿脚趾试试水的原因：你需要确定自己在做的事情是对的，方法也是对的，而且不是重复劳动。一开始就踏错步的概率总是很高的，越早征求意见和反馈，就越能把风险降低。记住这句久经考验的原则—“确保失败尽早发生，尽快发生，经常发生”—我们会在本书稍后详细讨论失败的重要性。
尽早分享不仅仅可以防止一开始就步入歧途和检验创意，它还可以强化所谓的“公车因子”。
公车因子（名词）：一个项目里，需要有多少人被公车撞到才能令其完全瘫痪。
你的项目里知识的分散程度是多少？假如只有你一个人理解原型代码是怎么工作的，那么或许对你的职位的安全程度来说是很高，但要是你被车撞了的话，对项目本身来说就是灭顶之灾了。但如果有一个朋友和你合作的话，公车因子就可以翻倍。要是有一个小组一起设计制作原型的话就更好了—项目不会因为某位成员的消失而完蛋。记住：这里只是比喻，并非真的是被车撞，而是指任何生活中都会发生的意外情况，比如结婚、搬家、离职或是照顾生病的家人等。你若想要确保项目有一个光明的前景，就一定要把公车因子纳入考量。
除了公车因子之外，还有整体进展的速度。人们往往会忘记单独工作通常都是很艰辛的，进展有时会慢得令人难以接受。独自工作能让你学到多少东西？你的进展如何？网络虽然是观点和信息的大熔炉，但是它是替代不了人与人之间真正的交流的。直接和别人一起工作能潜移默化地提升集体智慧。每次遇到事后觉得可笑的障碍时，你浪费了多少时间才走出死胡同？想想如果有同事在旁边帮你一把的话会有什么不同—他们会立刻指出你哪里弄错了，该怎么解决它。这就是软件公司里团队通常都是坐在一起（或是在一起结对编程）的原因：你需要一位旁观者。
再打一个比方。想想你是怎么用编译器的。当你编译一个有一定规模的软件的时候，你会花好几天甚至好几个星期坐在那里写代码，然后在全部写完确保一切完美后才第一次进行编译么？肯定不会啦。你能想象一口气编译50 000行代码会有什么后果么？程序员是最需要不断反馈的：写一个新函数，编译，加了一个测试用例，再编译一下，又重构了一部分代码，再编译一下。这样就能在生成代码的时候尽快地改正笔误和 bug。我们的每一步都离不开编译器，好像僚机一样。有些开发环境甚至能在我们打字的同时进行编译。正是依靠这种方式我们才能保持高质量的代码并确保软件在正确的轨道上演化。
这种快速反馈不仅在代码层面，对整个项目来说也是必不可少的。有抱负的项目都必须快速演化并不断适应环境的变化。项目可能会遇到意料之外的设计瓶颈，或者行政上的阻力，又或者只是发现事与愿违。需求总是在往意想不到的方向变化。你要如何通过反馈来发现自己的计划和设计中需要修改的地方？答案是：团队合作。埃里克·雷蒙说过，“只要有足够多双眼睛，就能发现所有的bug，”而更好的说法是，“足够多双眼睛可以确保你的项目保持正确的方向。”闭门造车的结果往往是当实现最初的创意后，却发现世界已经完全改变，原本的产品已经失去意义了。
因此用一句话来总结就是：本质上，单打独斗比合作风险更高。相比担心自己的创意被偷走或是被人笑话，你更应该担心自己是不是在错误的方向上浪费了大量时间。
令人遗憾的是，这种“创意要保密”的想法并非软件行业独有的，所有领域都普遍存在这个问题。就拿学术界来说，科学原本应该是自由开放、信息共享的。但是“不发表即灭亡”的迫切需求，以及对基金拨款的竞争却造成了反效果。学者们不再乐于分享。他们小心翼翼地保护着自己的想法，秘密地进行研究，把犯过的错误都掩盖起来，使最终发表的论文看起来似乎得来全不费功夫一般。其结果往往都是灾难性的：要么不小心重复了前人的工作，要么在一开始就不知不觉犯下了错误，最糟糕的是创造了一些原本有趣，但现在完全过时无用的东西。其中浪费的时间和精力都是无法估量的。
别再把自己变成上述统计结果的一部分。
团队才是王道
我们到目前为止一直在打磨的观点就是，在编程领域里，真正的独行侠是很罕见的—就算他们真的存在，他们的非凡成就也不是凭空而来的。这些改变世界的成就几乎都是集体智慧努力得来的结晶。
因此建立一支全明星团队才是真正的目标，不过想达成这个目标，难度高得惊人。最好的团队能充分利用好队里的巨星是没错，但是集体的力量一定是大于个体力量之和的。
用一句话来说就是：软件开发是集体项目。
乍看之下这个理念很难让人接受，毕竟这和我们心里的天才程序员幻想是相抵触的，所以先记下来再慢慢理解吧。
一个人躲在自己小黑屋里抖聪明是没用的。光靠自己神神秘秘地搞创造发明是不可能改变世界，令千百万用户受益的。你需要合作，告诉别人你的想法，让别人帮你分担劳力，向别人学习，进而打造一支出色的团队。
现在来做个实验：你能想出几个应用广泛的成功软件是真正由一个人完成的？（有些人可能会提到“LaTeX”，但很难说它是一款“应用广泛”的软件，除非你觉得那些写学术论文的人在所有电脑用户里占有相当大的比例！）
三支柱：谦虚、尊重、信任
放下自负
自负这个东西有很多种解释，就看你怎么理解，但很多时候它都会妨碍你的工作，让你进步缓慢。
好吧，说得更直白一点，就是让某些缺乏谦逊的人收敛一点儿。没人喜欢和总是以自我为中心的人合作。哪怕你真的是会议室里最聪明的那个，你也没必要到处炫耀。例如，你是不是总是觉得自己对于每个话题都要抢先发表意见，或是要作总结性发言？你是不是觉得自己需要在一项议案或是讨论中对每个细节发表评论？或是你总是要知道谁在干什么？
学会批评和接受批评
在职业程序员这个行当里，人身攻击是相当罕见的—批评通常都是为了产品好。其中的诀窍就是要确保你（和你周围的人）认识到对某人的创造性工作提出建设性批评和人身攻击之间的区别。后者是毫无意义的—这种攻击不但显得小气，而且几乎不可能有什么建设性。而前者通常都是有益的，对改进具备指导性。最重要的是，它蕴含着对对方的尊重：只有真正关心对方的人才会提出建设性意见，希望对方在自身或是工作上有所进步。所以学着尊重对方，礼貌地给出建设性批评吧。如果你真的尊重一个人，那你就会自发地选择有技巧有帮助的措辞—这种技巧需要很多练习才能学会。
作为谈话的另一方，你也应该学会接受批评。这不是说你在技术上要谦虚，而是说你要信任对方，相信他是从心底为你好（当然还有你的项目），完全没有把你当傻瓜的念头。编程和所有技能一样，都需要熟能生巧。如果你的同事提出的做法比你现在的好，你会把它当成是对你的性格或是人生价值观的攻击吗？我们真心希望你不会。同样，你的自尊和你的代码不应该有什么联系。换句话说，你和你写的代码是两回事。你应该不断地告诫自己，你和你写的代码是两回事。不但你自己要相信这个观点，还要让你的同事也认同它。
对影响保持开放的态度
你越是容易受影响，你就越能影响别人；你越是示弱，你就越强壮。这两句话看起来有点自相矛盾。但是每个人都碰到过某个同事，固执到叫人恼火。无论怎么试图说服他都没用，越劝越不听。最后怎么样？就我们的经验来讲，大家最后就会自然而然地把他当成障碍物“绕道而行”，再也不会有人听取他们的观点或反驳。没人希望这种事情发生在自己身上吧？所以请记住这一点：接受意见改变自己没什么大不了的。不要随意挑起争斗。不要忘了，要别人听你说话，首先是要学会当一个听众。注意在被影响的时候，如果你要听取意见，一定要在你下定决心或是确定宣布你已经做好决定之前—要是你的主意老是改来改去的，别人会觉得你这个人没什么立场。
说到示弱，初看之下也有点奇怪。如果一个人承认自己对某个东西一无所知，不知道要怎么解决问题，那他还能得到多少团队的信任么？示弱就是暴露弱点，这不是在摧毁自己的自信吗？
其实不是。承认自己犯错或是无知从长远来讲其实能提升你的形象。事实上它蕴含了HRT的全部方面：它对外表示了“谦虚”，这是有责任心、负责的态度，这也是表示“信任”别人意见的态度，同时作为回报，别人也会因为你的诚实和坚强而“尊重”你。所以有时候最好的答案就是：“我不知道。”
写软件的时候就用不着总是抱着防备的心态了—你的同事是合作者，不是竞争者。
若能读到这里，说明你已经在掌握“与人合作”的艺术的征途上跨出了第一步，你已经检视反省了自己的行为。只要能在日常生活中运用这些策略，你就会发现合作将变得更自然，工作效率也能大大提高。
重要的改变要由自己做起，然后慢慢影响其他人。在下一章里，我们要讨论如何在你隶属的团队中培养HRT文化。
本文摘自《极客与团队》
转载于:https://my.oschina.net/cjkall/blog/195835