本书旨在帮助程序员改进理解他人、与人沟通，以及与人合作的能力，进而使其在编写软件的过程中变得更有效率。
隐瞒是有害的。
尽早分享不仅仅可以防止一开始就步入歧途和检验创意，它还可以强化所谓的“公车因子”。
公车因子（名词）：一个项目里，需要有多少人被公车撞到才能令其完全瘫痪。
在职业程序员这个行当里，人身攻击是相当罕见的——批评通常都是为了产品好。其中的诀窍就是要确保你（和你周围的人）认识到对某人的创造性工作提出建设性批评和人身攻击之间的区别。后者是毫无意义的——这种攻击不但显得小气，而且几乎不可能有什么建设性。而前者通常都是有益的，对改进具备指导性。最重要的是，它蕴含着对对方的尊重：只有真正关心对方的人才会提出建设性意见，希望对方在自身或是工作上有所进步。所以学着尊重对方，礼貌地给出建设性批评吧。如果你真的尊重一个人，那你就会自发地选择有技巧有帮助的措辞——这种技巧需要很多练习才能学会。
作为谈话的另一方，你也应该学会接受批评。这不是说你在技术上要谦虚，而是说你要信任对方，相信他是从心底为你好（当然还有你的项目），完全没有把你当傻瓜的念头。编程和所有技能一样，都需要熟能生巧。如果你的同事提出的做法比你现在的好，你会把它当成是对你的性格或是人生价值观的攻击吗？我们真心希望你不会。同样，你的自尊和你的代码不应该有什么联系。换句话说，你和你写的代码是两回事。你应该不断地告诫自己，你和你写的代码是两回事。不但你自己要相信这个观点，还要让你的同事也认同它。
我们俩都在Google工作，而我们最喜欢的Google的格言之一就是“失败是可以接受的”。广泛的认识是如果没有经历过失败的话，就说明你的创新还不够，或者你承担的风险还太小。失败是更上一层楼的绝佳机会。事实上，托马斯·爱迪生曾经说过：“即便我找到了一万种行不通的办法，也不代表我失败了。我并不会因此而泄气，因为每次试错都是在前进。”
大多数工程师都会犯的第一个错误是假设建设团队文化是负责人的事。这种想法再离谱不过了：尽管创始人和负责人通常会关注团队文化的健康情况，但其实每位成员都是团队文化的一部分，都要为定义、维护和保护它作出贡献。每当有新人加入时，她并不只是从团队负责人那里了解团队文化，而是从一起工作的每个成员身上学习。例如，你在仔细检查新同事的代码的时候，会向她解释为什么你的团队是按照某种方式写代码的，这样她很快就会明白团队重视的是代码里的哪些部分。她还会通过观察团队的工作、交流，以及解决冲突的方式来学习团队文化。
团队文化有意思的地方就在于如果你清楚地定义好它，它是会进行自我选择的。在开源世界里，那些构建在HRT之上，专注于编写干净、优雅、可维护代码的项目会神奇地吸引拥有相同价值观（即尊重信任他人，并且致力于编写干净、优雅和可维护的代码）的工程师加入。然而，如果你的团队文化是侵略性的、欺凌性的，或者是感情用事地进行人身攻击的话，那最终吸引过来的也只能是这样的人罢了。
在自顶向下的管理模式中，首席工程师就是团队主管，其他工程师则被雇为团队成员。这是因为这些团队成员的成本比较低，也比较容易指挥。但是你很难在这样的团队里找到优秀的工程师，毕竟，要是能在另一家公司里主导开发的话，她何苦屈尊在这里听指挥呢？但是在共识驱动管理之下，整个团队都能参与到决策中来。
基于共识决策的团队。所谓的“共识”，是指每个人都对产品的成功抱有强烈的主人翁精神和责任感，同时团队的领袖也真的愿意倾听团队的意见（即HRT中“尊重”的部分）。
攻击性性格的人（通常）也能够适应比较平和安静的环境，但是比较内向的人却很少能在激烈的环境里生存（或者开心地工作）——这样的环境下，他们的声音不但很容易被杂音盖过，而且会逐渐影响他们参与的积极性。如果你想找一个能让大多数人高效工作的环境，那还不如自己去建立一个谦虚、尊重和信任的文化氛围呢！
沟通的指导原则之一就是在同步沟通的时候（比如开会），人越少越好。而在异步沟通的时候（比如E-mail），涉及的听众越多越好。
虽然当整个团队坐在一个办公室里的时候，邮件列表并非是进行讨论的最佳选择，不过用它来发布会议议程、会议记录、决策、设计文档，以及任何相关的文字信息再好不过了，它是一个非常方便的集中记录点。通过这些列表将所有帖子存档，并为之建立可搜索的索引，如果是开源项目，可以把它公布在网上；如果是闭源项目，则可以把它放在公司的内网上。这样你的项目就拥有了一份完整的历史记录，当新人对过去作出的某项决策心存怀疑的时候，就可以很方便地回溯查看当时那么做的原因。如果不存档这些讨论的话，你会发现自己不得不一次又一次地重复讨论它们。
代码改动应该尽量短小以保证审查的质量——若改动涉及几千行代码，那么除了挑挑格式的毛病外，基本是没办法进行审查的。做到这一点不但能提高整个代码库的品质，更能从长远上培养代码质量的集体荣誉感。
传统型经理关心的是怎么完成任务，而主管只关心完成了什么任务……（并且相信团队能自己想出解决问题的办法）。
另一个让人对当经理这件事避之不及的原因是人人讳言、但又很著名的“彼得原理”，这条原理说道，“在等级制度中，员工会趋于提升到他无法胜任的地位上去”。
要治好这种“管理”病，就应该采用宽松的方式，我们称之为“仆人式领导”，这个名字很好地表达了经理最重要的工作就是为团队服务，如同管家之于一个运转良好的家庭一样。作为仆人式领导，你应该努力去营造一种谦虚、尊重和信任（HRT）的氛围。这意味着消除工程师自己无法消除的像官僚作风这类障碍，帮助团队达成一致，甚至还包括加班的时候帮大家买晚饭等。仆人式领导要为团队填补前进道路上的裂缝，并在必要的时候给予建议，同时还要勇于冲到第一线。仆人式领导唯一要做的管理工作就是对团队的技术和人事健康状况负责。尽管完全把注意力放到团队的技术层面上是个很有诱惑力的想法，但是人事方面的状况也是同样重要的（但管理起来往往要困难无数倍）。
找到对的那个人的成本（不管是付给面试官的钱，还是花在广告上的钱，还是寻求推荐的费用）比起招到一个不应该招的员工的代价来绝对是微不足道的。后者包括了团队丧失生产力，导致团队压力，耗费时间去管理这名员工，以及解雇员工过程中涉及的各种书面工作和压力等。当然，我们假设你在遇到这种事情的时候，不想出现把他丢在一边任他侵占团队的成本的情况。假如你在自己管理的团队里，在招聘上没有发言权，而你又不喜欢招进来的人，那么你一定要尽一切力量抢到最好的工程师。要是招进来的仍然是水平不怎么样的人，那你还是想办法另谋高就吧。没有人才是打造不出顶尖团队的。
很多刚刚担任领导职务的工程师总是迫不及待地想要立刻做好所有的事情，了解所有的事情，回答所有的问题。我们敢保证，你不可能把每件事都做对，也不可能知道所有问题的答案，而且假如你硬要如此表现的话，很快团队就不会再尊重你了。
我们认识一个主管，他自制了一张表格，列出了所有没人想干但是一定要完成的脏活累活，然后平均分配给大家。
此外还有一个重要的部分就是要关心他们的职业生涯。如果你问你的队员五年后对自己有什么展望，绝大多数时候他们都只会耸耸肩表示没想过。其实这种情况下大多数工程师都不会说太多，但是每个工程师心里总有一些想要在未来五年之内完成的东西，比方说升职、学一点新东西、发布重要的产品，或者是和牛人一起工作等。不管有没有说出来，大多数工程师心里都会有抱负的。要是你想当一个好领导，就应该考虑一下怎么帮忙才能够实现这些愿望，让你的团队知道你真的放在心上了。最重要的就是了解这些没有说出来的目标，让它们显现出来，这样才能在给出职业建议的时候有可以依赖的标准来评估不同情况和机会。
记住，有些出色的工程师只想在自己的岗位上发光发热，没有当领导的兴趣，这种选择并没有错。我们总是会吃惊地发现一些公司不顾员工意愿，把最优秀的工程师放到管理职位上去。其实这么做往往只会让你的团队失去一名优秀的工程师，平添一名蹩脚的经理罢了。
工程师拥有自主权的意思就是他可以独立工作，不需要别人盯着才能干活。对有自主意识的工程师，你只要告诉他们产品的大致走向就行了，至于具体怎么操作，完全可以留给他们自己决定。这是很有激励性的，因为他们更了解产品（比你更清楚怎么打造产品），而且这样更能激发他们的主人翁精神。产品的成功和他们关系越大，他们就越希望看到它成功。
从本质上来讲，所谓的精通就是说你要让工程师有机会学习新技能，在现有的基础上继续磨炼提高。大量地提供这样的机会不但有助于激励工程师，还有助于工程师进步，进而令团队变得更强。工程师的水平就和刀刃一样：你可能要花好多钱才能为团队找到最高水平的工程师，可要是你只“用”刀却不磨刀的话，用不了几年，这把刀就钝了，运气差点干脆就废了。只有给工程师提供大量的机会让他们去学习和掌握技艺，才能保持锐利、高效实用。
说到底，要是一个人不知道为什么工作的话，不管有多大的自主权，不管精通多少技艺都是没有意义的。因此你需要给他一个工作的目标。很多工程师虽然做的产品是非常了不起的，但是这些产品对公司、客户，甚至世界所产生的正面影响和他们都没有关系。其实就算产品的影响力没有那么大，你也可以让他们知道自己的努力是有价值的，以此来激励团队。只要你能让他们看到工作的目标，他们的动力和生产力就会成倍增加。我们有个经理朋友一直都会关注公司里有关产品（某个“没什么影响力”的产品）的E-mail反馈，只要他看到有客户说到这个产品是怎么帮到他或者他的业务的，他立即就会把它转发给团队。这不但激励了整个队伍，还能不断地激发他们的灵感，想方设法把产品做得更好。
然而除此之外，你同样还需要理解怎么在好公司和坏公司里生存。大多数软件工程师都服务于效率低下的官僚机构（公司），因此要采取一些非常的手段才能达到目的。有些人称之为办公室政治，你也可以把它叫作社会工程。而我们给它起的名字是组织操纵。
你的经理不是千里眼，公司里几乎不存在沟通过多的情况，所以别犹豫，一定要在经理问你进展之前，就向她汇报自己在干什么。在遇到困难、完成任务、需要帮助，或是希望看到什么事情发生的时候，不妨给她写张条子。这样不但你的经理很清楚你在干嘛，同时也是对付微管理的绝佳办法：假如你的经理不断催你进度，那么主动以同样的频率给她发E-mail汇报就是让她收手的好办法。
通常没有安全感的经理会坚持要参与你和团队之外任何人之间的交流中去，进而防止你说出一些“没有经过上级批准”的东西来。这种经理认为任何你和团队之外的工程师所作的直接交流都属于背叛，更不要说和其他经理接触了。如果你需要从团队或者公司之外寻求任何帮助，她会希望你先去找她，这样才能凸显自己的重要性以及和你的上下级关系，这样也就让她觉得自己更有力量。
坏经理通过藏匿消息，硬是成为信息和沟通的渠道的办法，来达到窃取胜利果实以及让你背黑锅（有时候，甚至是她们自己的错误）的目的。很多时候，这种坏经理只是把你当作她往上爬的垫脚石，根本不关心你的职业发展，更不用说团队的幸福指数了。
刚接触一个人的时候很难界定他是不是所谓的办公室政治高手，因为这种人往往左右逢源，很擅长和人打交道——所以一开始的时候他一定让人觉得很好相处。一般这种人很会利用同僚或下属，踩着他们往上爬。他会抓住各种机会推卸责任，甚至比抢别人功劳还迅速。通常这种人都是两面三刀，见人说人话，见鬼说鬼话，就是希望给你留个好印象。但要是发现没办法利用你或是操纵你，他就会当你不存在，或是把你当作是威胁，想方设法地在暗地里中伤你。所以只要相处一段时间，这种人就藏不住狐狸尾巴了：他大多数时间都在想办法让自己表现得有影响力，而不是真正地让自己变得有影响力。
我们的建议是对这种办公室政治高手最好敬而远之：没什么事的话就躲远点，但不要口没遮拦地在公司里跟人说他的坏话，谁知道对方是不是清楚他的为人呢，或许他也被蒙蔽了。另外，如果你是那种喜欢保持低调、专心干活的人，可偏偏身边就有那么一位高手的话，你最好改变一下这种工作方式。你或许会觉得不想“玩这种勾心斗角的把戏”，懒得去争权夺位，可最后却发现那些小丑变成了你的上司，结果你身边不但有玩弄办公室政治的家伙，又多了一个坏经理。
不幸的是，在那些不尊重工程师，只把他们当奴隶的公司里，这种情况是非常典型的，在这种公司里，工程师对公司如何运作是完全没有发言权的。
尽管在清理代码和重构上面花大力气是非常有诱惑力的想法，但是经验教训告诉我们，不要花太多时间在这种防御性的工作上，很少有人看重这些，到时候你会发现自己的处境很尴尬，因为花了那么多时间，你却拿不出什么（政治上）看起来很重要的成果。这样你不但得不到别人的认可，还很容易导致自己的项目被取消。
如此我们不妨作这样的总结：不管技术债务有多少，团队也永远不应该花超过三分之一甚至一半的时间和精力去做防御性的工作，否则就等于政治自杀。
大多数工程师都觉得，只有工作成绩优秀才是符合逻辑的晋升条件，然而这种事情只有在最牛的公司里才会出现。其他大多数公司通常都需要你（在出色地完成工作的基础之上，）再耍一点手段才能如愿。
这里有一个很遗憾，但是很简单的答案：你可能真的无能为力了，赶紧撤退，别被波及了。
如果你改变不了整个体系，继续投入精力去改变它是没有意义的。你应该把精力放到怎么离开它上面去：更新自己的简历，去问问周围的好朋友，看看有没有机会到其他公司就职；自学一点新知识。今时今日，身为工程师的最大好处就是优秀的工程师永远是紧缺的，因此你完全有能力掌握自己的未来。