把整本书中每个章节有用的信息记录如下：
在某些特定环境中所看到的那样，额外的金钱实际上反而可能会让某些人放弃自己工作。
也许你现在会说：金钱的激励作用还不如提高对目标设定的参与程度和对工作数量的关心程度来得有用。
为了更有效地激励他们。涨工资只是权宜之计
只要允许程序员按照自己所偏好的方式进行工作，那么程序开发这项工作本身就是对他们最大的激励。
成员们都在一位令人敬畏的领导手下，为一个实际的项目工作数年。然而，这数年的时间意味着培训与经验的积累。
这一阶段学习的不过关，必将成为他们在后面学习操作系统概念时的拦路虎。
学习的阻力王
令人吃惊的是，只有当存在阻碍学习的负面作用力时，学习才会失败。
是因为在教学过程中，人们过分强调了，如何通过各种精巧的研究并或签发学员的学习积极性。
儿童自己来决定学习的方向，他们总是可以学到大量的东西——虽然这些东西是我们所期望的，但是不管怎样，他们将会学到很多。为了能使他们按照我们见得一行学习，我们会建立一些“围墙”，然后开启几扇“小门”。如果儿童依照我们指定的结果有一个现象也向去学习，我们就会暗自庆幸，但是即使离开我们，没有我们刻意设定的那些屏障，它们仍然可以学习，而且也许会学得更好。
对于成人来说，阻碍学习的障碍通常都来自我们自己的内心。
在开始学习之前，我们需要承认有一些东西值得去弄清楚，而自己还不懂。
程序员的观念中，承认自己某个方面知识的缺乏，就意味着地位的降低——除非他能够意识到：
作为一位名副其实的专业人员，作为一个真正有实力的人，承认自己的不是，不会有任何的损失。
有些人总是心甘情愿地承认自己的不足，而不去尝试学习任何新东西。其原因在于，他们总是想当然地认为，自己不可能取得成功。这种对失败的畏惧心理，有的是由于缺乏自信心造成的，也有的是源自先前此类努力过程中的失败经历。
但是更普遍的情形是，同类型问题这类恐惧主要并不在于失败本身，而在于失败可能被周围人看到。
积极性.
培训及经验一如果要进行学习，我们首先必须做好犯错误的思想准备。但是如果周围有别人，克服自己的畏惧心理将会显得更加困难。事实确实如此，如果使用的知识，那么也许正是由于有周围人在场，我们会努力去避免犯错误。如果把这用在学习程序开发技术的过程中，我们就可以自然而然地猜测：在首次学习某语言时，如果是在一个只有终端相伴、与世隔绝的环境中，那么学习的效果将会最好，因为这时任何错误都不至于为人知晓。
掌握学习之道的第一步，就是要了解自己拥有什么、缺乏什么——也就是要有“自知之明”。
与坐在教室里的学生相比，自己做自己老师的人拥有一项巨大的优势：他可以根据唯一的学生——也就是他自己——的需要，对课程内容做精确的裁减。在上一节中我们曾经介绍过一个例子，其中的教师发现由于两种原因，自己的学生没有学好APL语言。其实，这两种原因不仅不同，而且正好互补。如果为了帮助前一类学生，这位老师尽力去加深课程内容的难度，那么那部分本来已经觉得跟不上老师的讲解实例的学生，就会被抛弃掉，如果朝相反的方向努力，也不会有什么更好的结果。于是，这位教师就似乎面临着一个令人尴尬的悖论。而实际上，为了走出这种进退维谷的境地，他应该采取的是一种兼顾两个极端的策略——也就是说，他应该根据不同学生的特殊情况，分别进行处而对那些自学的学生来说，如果他有自我感觉能力，那么这种个性化的关注恰恰就的是最好的。
根据学校所能够提供的条件，采用一些更为合理的新方案，就可以更好地鼓励学员们表发现最适于自己的学习习惯——只有这样，他们才能在告别学校之后保持不断学习的最佳状态，而不是觉得，要是从某一天起能够不用再去学习，那真是谢天谢地。
无论我们如何精心地为学习建立一个最佳的物理环境，如果不懂得如何利用所有可能的信息来帮助我们学习，再好的环境也不可能保证我们能够成功地完成学习任务。
为了理解某个问题，最好的办法就是进行一番全面的讨论。
认识到：如果一个集体的共同目标仅限于产品层次，那并不见得会促使其中的程序员相学习。而反过来，团队内部成员不仅目标一致，而且其目标与他们具体开发的产品无关系——正是在这种目标的引导下，一支团队的成员才会通过相互学习共同提高。
如果我问客户：“在你们作为团队一员的经历中，哪一段是最美好的回忆？”，他们最有可能的回答是：“最好的团队简直就是一个家庭——其气氛就像是在感恩节前后一样。每个人都将自己创造出来的东西摆到桌子上，而所有人都可以共享并为之庆祝。”我认为健康团队所具有的另一特点就是，它始终能够保持自我的生命活力。正是由于具有这种特点，即使有成员中途离队，也可以建立并维护一支具有共同价值观与习惯的新团队。
人与人之间的交流沟通既不是那么狭窄，也不是那么直载了当，是用一张组织结构图就能表示出来的。而人们之所以会犯种种重大的错误，一个原在于他们总是认为：只有正式的结构，才是一家企业中唯一可能的结构。
当然，工程项目中的非正式结构在很大程度上取决于其工作结构，因此或多或少者组织结构图相符，而具体符合到何种程度，则取决于该项目的组织化程度。
他们可能会把出自非正式结构的新方法以正式的形式固定下来
这则故事告诉我们：非正规的机制到处存在，而且如果你还没有真正搞清楚其规律，就企图改变什么，那将会十分危险——你可能会把有些操作系统搞得一团糟，同时，任何替代方案都需要付出更高昂的代价。许多由此引发的系统紊乱，都源自于对环境的物理格局进行了贸然改动——在各个计算中心，这种改动非常普遍，因此我们值得进一步花费笔墨，讨论一下自然环境与社会结构之间的关系。
对工作场地做过于普通的划分，反而会对程序员的生产效率造成负面的影响。这些方法一方面会切断程序员之间有益的沟通渠道，另一方面却为那些干扰性的声音、动作大开方便之门。
无私式程序开发对上面提到的在程序开发中的唯我独尊问题，我们应该采取什么措施呢？管理学方面的资料通常都会建议，主管应该规动手下的每一个程序员，要求他们加倍努力地查我自己程序中的错误。也许，主管每天都应该在程序员之间来回巡视，不时地要求某个程序员介绍一下他自己发现的程序错误。但是这种办法难以奏效，它带来的后果，与我们的心理学知识所讲的完全相反，因为，一般的人会把这种检查视为对个人的一种考察。此外，不是每个程序员都有一位相应的主管——或者即使有主管，这位主管在看见某行程序被用红色突出显示后，至少应该能够明白是什么样的错误。
不，解决这个问题的方法，并非单刀直入式的着手处理——因为这样的进攻只会引起程序员的抵抗，而这种抵抗正是我们希望戒除的。
不仅是调试时间的偏差幅度减少了，而且由于每段程序都有不止一个人熟悉，所以能对实际的工作进展做出客观的估计，就是一件很容易的事情了。这样，就不必仅仅依赖于某个人的判断，否则，很难保证这一个人能够不带某种偏见。同时，由于我们确定至少有两个人能够理解该程序，所以程序的适应性也将得到提高。在某些特定的程序开发环境中，这意味着无限的提高。另外，在程序员中很可能发生的情况是，有关的某位开发的程序员生病了、怀孕了或者找不到了。现在，即使出现这种情况，整个网络的运转也不容易受到影响。这不仅减少开发进度的偏差，而且在将来的某一天，一旦需要对程序进行修改，也会更容易找到一个了解它的人。
关于效率的问题，我们很难做严格和迅速的说明。但是几乎可以肯定的是，没有任何理由会比通过其他方式开发的程序效率要低。程序整体的效率通常主要取决于最初确定的结构，但是通过请别人帮忙阅读程序，我至少更有可能将最低效的方面消除掉。
这种方法的最后一个好处就是，它对阅读他人程序的人自己也有积极的影响，如果我们能够正确理解阅读程序的重要性，那么通过阅读他人程序这种实践，他的人必然会成为一位更出色的程序员。在有关程序员培训的章节中，我们还将就此进一步探讨。即使缺乏专门的教育措施，我们仍确实可以看出，这些程序开发我体能力和水平会自行提高。
其次，我也确实觉得，开发效率方面的差异，还可以通过其他途径加以解释——更便捷的工具、更融治的团队工作气氛、更高效的管理体制，以及更好地理解程序员将要完成的任务。
设计时，其中的任何部分既不能设计过分，也不能设计不足。
由于种种原因，程序有些部分对开发者的智力有很高的要求，而另一部分则可能需要大量的精力；程序业住习惯于在前一类工作上投入过多的时间，这是程序员中的一种职业病。
程序开发任务的差异工如果把成功的程序员放到管理的位置，那么他想可能一事无成。与此类似，进人界使测试信息，一位原本非常成功的设计师可能会变得明于呵啊。反过来，虽然某个人在测试时可能会大显身手，但是在项目尚处于设计规划阶段时，却由王他这方面的才能沙有用武之地，所以可能要让他暂时靠边站站。为了保证在需要的时候总能找到最合适的人选，我们必须首先将程序员需要完成的工作进行合理，细致的分类，而不是笼统的称为“程序开发”。
程序开发，也常常被人们描述为这样一个过程，它从问题定义开始，然后进行流程图分析，编码、测试，直到最后的文档整理。这种粗略的划分虽然不无道理，但在很多方面却不尽合理。首先，实际工作的流程未必都是这样一成不变的，比如有时在测试。编码，确定流程图之前就可以进行文档整理，有时甚至可以提前到系统分析之前进行。其次，正如我们在把程序移植到另一台计算机上或者另一种语言中时的情况一样，并非每个步骤都是需要的。再次，这些工作根本不可能严格按照某个顺序来实施——而且在实标工作中，确实极少会这样进行。有谁未曾在系统分析，流程图设计，编码，测试，以及文档整理时发现问题后，反过来对问题定义做必要的修改呢？或者反过来，有谁曾经见过哪张流程图，在经过编码后不曾做过任何修改呢？又有谁见过哪段代码，在经过测试之后不曾做任何修改呢？
为了从心理学的角度对程序开发做研究，我们必须把这些复杂的行为划分成更为简单的部分——当然，这些部分都是我们已经建立过的。但是，考虑到程序开发过程本身的循环，选代属性，即使是我们上述的分割也仍然是过于精细的。根据这种划分，各部分之间的界限非常模糊，甚至根本没有界限。如果我们向一位程序员询问他正在从事的工作，那么可以肯定的是，他会毫不犹豫地回答说在“编码”或者“调试”。而且，所谓“进展报告”的制度虽然在多数单位行之有效，但是这种制度会驱使人们不顾实际情况，把自己的工做被生硬的条条框框。人们就这样被逐步地诱导，以至于最终相信：他们的于自己每星期所填写的进度报表中的某个类别。
程序开发主管”，以及一个“优秀的软件”，“优秀的程序员应该具备……”等泛泛的讨发现
所谓“优秀程序员要是什么”的问题，也类似于诸如“深厚友谊的标准是什么”等问题——实质上，是人与人之间互相承认与鼓励的问题。
程序开发任务的差异必要，无论被指定任何一项任务，程序员几乎都能够完成。（然而这并不等于提供性能的指定多少任务，程序员都可以全部完成——尽管有些经理的确这么认为。
我认为我所投入时间的最大回报，就在于发现了那些明确，并且进行了相应的沟通。
无论是心理学研究者，主管或经理，还是程序员本人，只要对性格问题有所重视，都将会从本质上有助于程序员工作绩效的提高。
我相信较之智力因素，人格因素、工作习惯以及培训等方面的因素要与此更为相关。这些因素与智力因素不同，它们都可以道过后天经验发生改变。因此，选拔程序员的问题就转化成为培养程序员的问题。优秀的程序员是培养出来的，而不是天生的。因此，我们必须把注意力放到培养或者培训的过程上来。
我确实经发现，有些人貌似驾钝，却可以写出高质量的、很有用的代码；而另外一些人虽然看起来更显聪颖，却从没写出过任何有用的代码。简而言之，今天的我依然坚持自己经过了25年时间考验的立场：“…较之智力因素，人格因素、工作习惯及培训等方面的素要与此更为相关。这些因素与智力因素不同，它们都可以通过后天经验发生改变。因此，选拔程序员的问题就转化成为培养程序员的问题。”
需要吸取的教训是，应该注意这类意见一致与“集体目标一致”之间的区别：健康的不同意见，将有助于对开发工作进行不带偏见的评估
通常，一个开发团队都是为了完成某个特定的任务而建立起来的，因此在团队建立之前，任务目标往往就已经确定了。但是程序开发的任务通常不会一下子就定义明确，一般要等到开发团队组建起来之后，才能明确地落实，因此除非上层领导们专制，通常只要让团队中的所有成员一起行动，就可以确定意义明确的、有意思的目标，而最大的危险则来自于主管，由于他们都是经过程序开发中的层层选拔才得以出头的，所以这些人总是希望在手下成员看到问题之前，就已经把每一个细枝末节都详细地定义好了。再没有其他做法能够更挫伤成员的积极性了，它只能使成员觉得自己不过是“码器”，而已。
如果一个开发团队是根据这样一种“逐字逐句的”定义开展工作的，就会导致其他问题，而这仅仅是因为该集体对将要完成的任务不甚明确。“精确”和“清晰”的含义并不完全一样目标的清晰程度，是影响目标可接受性的最关键因素，而为了实现“目标清晰”，就必须说明任务的具体含义，然后在这一含义所确定的框架下对任务进行描述程序员需要了解“为什么做”，而不仅仅是“做什么”。
如果开发团队的任务不是开发一个特定的系统，而是为其他程序开发组提供服务和支持，那么这种目标不明确的问题就会显得更为突出。例如，开发一个软件包，即使你根本不理解为什么要开发，但是至少你对要做什么有个概念。但是提供支持的团队则不同，必须经常提醒他们注意自己的贡献，否则，他们的工作就会越来越具体，而且没有什么产出。
最好的情况是，一支开发团队只有一项明确定义的任务。然而不幸的是，这世界上的事情很少会这样简单。即使其任务只是完成一个程序或者子程序，也有可能者如速度、空间或者时间进度等方面存在冲突，人们对这些方面的重视程度可能不同
哪些因素才是导致集体中的成员对工作感到满意的关键，社会学家在经过之后，划分出了4个主要方面。
1.物质的奖励与机会。
2.工作本身所具有的挑战性及其趣味性。
3.其所求属的更大单位的总体条件，比如雇员的福利、工作条件，以及该单位在同类单位中的相对地位。
4.主管与领导者的能力。
就程序开发的现状而言，头三条愿望已经可以通过规章得到满足，而糟糕的管理及领导，却要比我们所想像的更为普遍。这样，程序员对待其“主管”的态度，在很大程度上会导致其对工作的不满意。
与那些世界级的口若悬河的推销商们相比，作为一名语调温和的程序开发奇才，将可以更加轻松地对程序员们进行领导（或影响）。当一名根本没有编过程序的领导者被指定负责某个开发团队时，除非该领导者明确地或者含蓄地承认自己在技术问题上的能力欠缺，否则注定会有麻烦发生。即便是那些曾经当过程序员的人，只要他后来有相当长的时间脱离了这个行当，如果他依然企图去与团队中的其他成员在程序开发才能方面一比高低，那么情况简直就槽糕透顶了。对于那些公开承认自己在程序开发方面经验欠缺的人，他的团队成员还有可能会尊重他，但是如果有人企图掩盖自己在这些方面的无知，那么等到他迟早露馅的时候，就会招到程序员们的无情嘲弄。
通常，在一名程序员同意接受担当团队领导者的指派时，他就已经辟身管理层盼望已久了。在这个方向上的进一步提升，已经与其程序开发能力——尽管是凭借这种能力，他才到达今天的地位——毫无关系，而他今后的升迁将取决于他取悦管理层的能力。
目光短浅、难以依靠的团队领导者可能会认为，博得管理层欢心的最好方法，无论他们要求什么都满口答应。但是最后，管理层需要的不只是诺言，而更重要的守诺言，只有在团队的领导者有能力使整个团队都接受这个诺言，并且以此作为集目标，诺言才有可能兑现。
团队的领导者需要学习的东西包括：
无论主管们怎样地强调诺言，他们真正关心的只是结果。
被指承的团队领导者就可能克服由于被指派而造成而成为一位使立自主的领导者，他会把“指手画脚，发号施令的能力。
作为一名被指派的团队领导者，如果他的手下无法完成某项任务，但是他的一步动作上级却强迫他接受这项任务，那么他所能采取的最好方法，就是坚决予以抵制。
他必须确保还能接收到新的信息，这些信息可能改变他的处境——比如当上级管理层对他承诺，将给他分配更多的人力和更优惠的上机时间。但是，他必须为自己评估一下，到底这些承诺兑现的可能性有多大，因为一旦他向自己的上级做出了承诺，那么他们就很可能把他从他们那里争取到的条件扔到九霄云外。
但是当管理层转而讨论除资源或者任的主管务定义之外的其他方面时，他的判断绝对不能有丝毫的动摇。最为典型的承诺是，在事成之后将给予他特殊的奖励，但是他必须保持头脑清醒，千万不要被奖励的诱惑冲昏头脑，而不考虑得到它的可能性到底有多大。
当上级管理层提出奖励的许诺时，团队领导者除了一味地抵制之外，别无良方。他必须乐于借助自己的专业判断力量，来支撑自己作为一位被指派的领导者的地位。如果落开他本身是位优秀的程序员，那么他在这场斗争中就拥有双重的筹码。
——因为他对自己懂得这是一种抢座位游戏。
所以就生硬地把某个不称职的成员开除掉，不大可能对集体的士气有什么鼓舞作用。担的，同时在一支民主式团队中，如果某个成员能力很强，但是却与周围的人合不来，那么这补他的空缺问题就会比某个成员能力极差的情况更为严重。在一支集权式的团队中，这样的一个人职本不需要在工作方面与其他同事有多少接触，所以只要能够与领导人处得来，他就不会有任何特别的问题。
在智力上远远超出其他同事的成员，也可能会有此类排斥社交的倾向——因为他可能“见到处人就压不住火”。但是另一方面，他周围的同事们也无法承认或实现他的那种建议。如果一个人不会运用他的智慧去调整其社交的行为方式，那么他的聪明才智反而会给他的程序开发工作帮倒忙。
因此我们明白了，对于程序开发团队来说，为什么民主式的也许应该称为：技术式的”一组织形式更为自然，这种自我调节式的结构既不会过于自主，也不会过于被动。在为开发团队挑选程序员时，我们应该尽量考虑选择更适应这种结构的一人。在对程序员进行培训时，我们应该尽量教会他们如何团结在有才能的领导人，教会他们在自己成为集体中最有资格的领导者时，如何抓住机遇，勇敢地挑起领导的责任，此外，虽然从表面上看，团队内部的民主化进程会带来一些损失，但是从长远这将会保证开发团队更为有效地运转。
其实，一旦团队建立起来并开始运作，其上级主管要是聪明的话，就应该对其内结构及结构的调整采取一种“袖手旁观”的政策。与司空见惯的情况一样，在团队成之间发生争论的时候，如果其中的某个成员来找他，并且希望从他这里获得倾向于自的权威性意见，那么他就应该毫不犹豫地效仿老拉比的方法。
开发团队中的每个人不一定都必须与所有同伴的目标完全相同。实际上，只需要找到每个成员不同工作的共同点即可。
当女性程序员很少时，很容易用老一套的方式来对待她们。但是，一旦在团队现女性不再是什么稀罕事，她们就会发现自己其实能够胜任任何角色。有的时候，可能担任开发任务的主管；有的时候，可能是负责协调的主管；有的时候，又可能心某个专题的专家。与这种用人唯贤的方式相比，我现在仍然能够看到的不同，只体现在主管们官方指定团队领导人的时候，在这点上依然很不幸，男性仍然拥有至少二比一偏见优势，这样的偏见使得许多团队不能按照可能的最佳结构来组建。
用人唯贤，预防危机
一个众所周知的心理学原理：如果要使学习的速度最快，就要得到评价反馈
任何歧视都会付出代价。在任何程序开发项目中，以“缺乏能力”或者其他借口，免去任何人的职位，都会有损于项目的整体绩效。而且，一旦某类人开始上级对自己的评判与其他人标准不同，他们的表现也就会不同。
用完全同等的标准和眼光去看待女性——如果她们的确巾帼不让须眉。
根据项目主管及此前曾对项目做过评估的人们所提供的情况，我们对这些项目失败的原因进行了分析。他们给出了项目失败的各种原因，但是就其本质而言，所有的原因都可以归结为管理上的失败。我们之所以会遇到问题，并非由于我们缺乏这些技术本身，而是因为我们根本不知道如何对现状进行有效的管理。
在我们的环境中，第一线的主管对于手下程序的具体工作知之甚少，同时沿着管理的层次逐渐向上，人员之间的沟通建度将会更慢而且变得不再可靠。
本章评注即使经过了四分之一个世纪，新一代的主管们依然迷信：对开发项目的敬业精神可用金钱来购买——每当他们不知如何对开发人员论功行赏时，他们只会一味地涨工资或答为是金。可悲的是，此类想法之所以久治不绝，是因为它确实行之有效。但是，开发项目的时间持续越长，金钱的效力也就越小。此外，一个人若能被金钱束缚住，那么他也可以被更多的金钱所解放。
有些主管已经懂得了这个道理，为了把开发人员留住，他们现在正在考虑采用别的奖励方式。有的人甚至把开发项目按照小型规模来组织，各小型部分之间可以互相转换，从而不再需要——或者说不希望——把开发人员长时间滞留在同一位置。
这些年来，有无数的主管曾经对我表示感谢，感谢我在这一节中振聋发绩的警示直到今天，这一警示依然正确：
如果某个程序员是不可或缺的，那么还是越快请他走人越好。
其中不乏表现出众者，但是其他一些人的表现他们面临的管理上的问题并非来自于软件开发经验的缺乏。与此同时，这些年来地显示出，即使是毫无软件开发经验的人，同样可以成功地管理大型软件开发现目，缺乏软件开发技巧根本不是问题。管理能力的缺乏，总是致命的。而软件开发经验的缺乏，不过是某些主管的一个现成的借口——实际上，这些主管真正缺乏的是尊重。
情感因素
如果没有明确地告诉每个成员应该对各个方面强调到何种地步，那么他们各自的工作目标就很有可能相互矛盾，其效果将互相抵消。可能有一位成员正在把大部分精力放应省时间上，但是偏偏发现另一位伙伴正在费尽心思地把程序占用的空间压缩到最小这样，节约下来的时间就被浪费掉了。当这种矛盾暴露出来之后，就肯定会导致产重冲突，特别是如果有关各方面在各自的工作中已经投入了相当多的精力，那么这种的冲突就在所难免。
令人奇怪的是，如果不同成员对团队的目标理解不一致，而且这些不同观点之间差异几乎无法察觉时，这些分歧的消除就显得极为迫切。人们常常会争论，在使用一子程序时到底应该使用两个入口，还是使用一个入口外带一个附加参数。为了平息“到底应该从哪一头敲破鸡蛋”的争执，格里佛曾经伤透脑筋。但是与白白消耗在前那些问题上的精力相比，格里佛消耗的气力也就算不得什么了。如果在开发团队中持出现这种争论，那么这就是一个确定的信号，它显示出在团队内部存在着更深层次的突——比如说，可能是为了争夺团队的“领导权”所以绝对不能因为其貌似琐碎，掉以轻心。
任何一个精心规划的教育计划，往往都不过是在按照业余人员的习惯，培训未来的专业人员——所以，也许他们还是不要这样去误人子弟的好。只要进入到实际的程序开发环境中去，你至少不会反过来忘记什么已经掌握了的技能。
或许应该为我们的学校制定一项目标，该目标就是要让学员们能够独立自主地去学习。也许这将代价不菲，也许可能不甚精致，
而且也许还会显得过时，然而对程序员来说，可算机和助指导（形非简单的CAF)最佳的学习之道。
显然，MBTI模型并不能解释所有各具特点的积极性——尽管这种尝试的成功机会并不小。
虽然任何理论都无法解释我们各自的嗜好，但是机灵的主管却能轻松自如地了解不同人各自不同的积极性。
他们的方法很简单——答案就在自己的鼻子下面！
当然，这种方法要求在主管与雇员之间建立关系；但是在某些类型的管理体制下，这种关系是不存在的。在这种情况下，主管好努力去猜测手下人的工作积极性到底是什么。
在适应某种程序语言的过程中，我们很容易养成对它的依赖性，只是因为我们对其在出得太多了。我们经常听到男同事抱怨他的老婆多么唠叨、懒散、花钱如流水。但当你问他为什么不离婚时，他说没有她他活不下去。
即便维持现状很痛苦，大多数人宁愿酸，也不愿意放弃一个熟悉的伴侣，尝试未知的新事物。当我们试图教一个程序员另前程序语言时，可以清楚地看到这一点。教他第一门语言是没有任何问题的，等他学会了第二门或更多，他就会知道这个世界上他不懂的事还很多。可是，让他放弃第一门语言就好像告诉他肯定会有痛苦却不一定有快乐来补偿一样。
重要的并不是其中哪个问题将会被“解决”——因为其复杂性实在是高得难以克服，而关键在于，哪些有价值的问题能够得到“解决”？无论如何，我们关心的并非是获得了多少答案，而是在尝试寻求答案过程中的经验。
至今依然保留下来的，除了完全利已程序开发方式问题之外，还有专业测试人员的社会地位问题。显然，通过改良测试工具，并不能找到解决这些问题的办法，真正的解决之道应该从改进管理入手。
只有通过制度化，使文档的制作过程转变为款件行业中的一种专门化的工作。
如果某件事根本就不值得去做，那么无论做得多么出色都肯定是没有意义的。
我们毕生的使命，就是要造就另一个人。
我们正站在一个新时代的边缘，正是由于蕴藏于计算机之中、迟早要发生的革命，这个时代才有可能到来。站在这个边缘，我们有两个可以选择的方向——迈入自由的黄金时代，抑或是倒退回专制的黑暗年代——无论你如何选择，这个世界中任何已知的事物都将被人类征服。也许任何个人的努力对最终的结果都不会有什么影响，但是我们绝对不应该放弃尝试，因为否则其后果必然是回到专制。这本书就是我反抗专制，反抗人奴役人、反抗被自己的无知所奴役的一次努力。但愿专制的力量不会利用这本书，但是毫无疑问，专制的力量确实会借鉴这本书。既然在这方面的希望破灭了，那么我只能希冀，处于杠杆另一端的正义力量能够从本书中获得更大的帮助。
该开发组取得了非凡的成功。鉴于该开发组的成绩如此显著，公司的领导层决定为该开发组颁发奖金。根据通常的管理模式，他们要把这笔奖金颁发导该开发组的主管。但是这名主管却告诉上级领导，除非这笔奖金是颁发给全体成否则他不会接受这笔奖金。你可能设想得出来，当时上级领导们会对他的这一做法不解。
其实，只要他们能认识到，这项工作的成绩是属于整个开发组这一集体的，就为该主管的反应非常正确，而不是无法理解的。然而有的领导居然认定，这只不为谋求更大数额奖金而使的一个花招，而另一些领导则猜测，他领导的这个程序正在变成一个“狂妄自大的”集体。无论如何，他们还是勒令这名主管接受这笔同时也促使该开发组解体——这种想法实在有些凝捉。主管领到奖金后，立即平组中的每个成员，然后，该开发组全体人员一同离开了该公司，转而投向另一软件公司。
在这次事件中，该开发组通过在接受奖金后辞职来保护自身，以避免遭的威胁。要是公司的高层领导们能够懂得应该给该开发组什么样的奖励。
需要使自己的心态重新回到与初学者平等的起跑线上。
对新事物的畏惧、对失败的担忧以及不情愿承认自己的弱点，都会成为学习的直接障碍。
大部分问题的原因，都在于对要学习什么，如何去学习等问题缺乏足够的认识。
如果遇到的问题来自于自己不熟悉的某个背景，那么我们通常可能把问题的难度估计过头，或者把问题想象得过于容易。
实际上，在一个如此大型的程序开发组中，任何一个新成员，甚至一个新的开发组，无论对自己的做事方法如何自信，都不可能改变整个开发组原有的社会系统，即使是其中的一个新的子开发组，也没有这种机会。如果他所加入的开发组成立已有时日，那么很可能他最终会放弃自己的方式，渐渐转向大多数人的方式——尽管他需要为此承受来自心理方面的痛苦，这种痛苦之严重，以至于没有人愿意承受。但是在更多时候，程序开发组可能新近才成立，或者是临时由多个独立的部分拼凑起来的。这时，其中的成员可能还会努力争取，企图根据自己的观念来塑造整个开发组。当然，其结果往往是他不得不情摔地卷起铺盖走人。
从第一天起，无论是哪一位成员完成的哪一项任务，在上机运行程序之前都必须至少经过另一名同事的签字。
程序员的工作环境多样而复杂，其间人与人的关系错综复杂，充满变数，稍不就会引起误解。如果要了解这种环境，你必须首先对正式与非正式结构加以区别，同要找出决定和造成这种环境的众多因素：从周边的自然环境，到个人的自私性。任何个正在运转中的程序开发环境中都包含了丰富的内容，这种丰富性使得它具有一种的保持的特性，这使得该环境可以抵挡来自外部的强制影响——尤其是那些不顾正式与丰式之间的差别，就草率做出的强制性命令。在任何社会层面上，都能看到这种自我保的现象。从本质上讲，这无所谓好，也无所谓坏。它仅仅是程序开发过程中的一种客事实。
现在对软件开发主管们的考评，很大程度上仍然是根据其已有的少，而不是看其是否有能力建立能够创造出更多成果的团队，或是看他们的成果在这样的压力下，主管们就会极尽其能事，编造种种相互矛盾的甜言蜜语去哄鼎其以期得到更多成果——当然，这些成果大多是短期的。他们的一些下属也可能领悟出游戏的原理，于是也会效仿这种传俩，去欺骗他们的下属……，这样一直下去，直们也成为这样的主管。这种主管根本不屑于去建立团队，也开发不出什么高质量的而只会再带出更多像他一样的下属——有朝一日这些人又将成为下一代被这样误导管。
是否有能力建立能够创送出更多成果的团队
在后一种情况下，必须首先透过技术上互相矛盾的需求，发现其背后的人际冲突，才能通过一种社会化的机制加以化解。
我们希望通过最小的代价获得最佳的开发效果，你必须找到尽可能出色的程序员，并且给他们以尽可能长的时间，这样你需要的程序员数量也将最少。反之，如果你希望工作能秀使人们去寻
尽可能快地完成，或者雇用尽量少的经验丰富的程序员，那么开发成本与不确定性都会随之增加。
当前最为常见的情况是：雇用一批实习生，然后给他们施加沉重的压力，但是又不提供必要的监督管理。无论如何，这种程序开发方式都必然是糟糕透顶的。
如果要求初出茅庐的实习生承担真刀真枪的任务，那么他们就无法有效地学习别人忽略了人生的程序开发经验。虽然有些团队的组织结构当前是最优的，但从长期来看却不见得也是我们确实最优一因为要做到长期最优，我们还必须考虑完成培训的任务。所以，尽管我们可以预计到，那些（相对而言）缺乏经验的程序员对当前的任务贡献甚微，但是我们还是应该可能的确设在开发团队中安排一到两名这样的程序员。
在个人能力与日程进度二者之间互外的对应关系，一方面、只有把工作交给最出色的团队，才有可能使开发的日能最短：另一方面，只有在愿意把开发日程拖得很长时，才可能使得团队的规模最小。换而言之、只要我们允许开发且程监得更长，即使团队的编程能力弱一些，也成几乎任何程序——当然，编程能力不能降到基本限度以下。
在程序开发的过程中，开发团队中各成员的地位，通常在很大程度上取决于其对其个人能力的了解程度。如果程序能够（在团队中自由）流通，供程序员们相互指正，那么“精英们”就能够更快地脱颖而出。反过来，如果团队成员都像苦行僧一隐居在各自的小隔间里独自工作，那么其在当前开发团队中的威望，就会更多地取决其在此前建立起来的声誉——至少在大家意识到这种评价的错误之前的确如此，然而等那时往往已经是无可救药了。
同样，在被分配给某项特定工作之后，某个成员也可能相应地获得或者丧失一些位。负责何种程序开发工作，将决定不同成员的身份地位——这就像办公室铺的地毯能反映主人级别一样。为了组织好一个团队，我们必须在推行工作的过程中，在各成员的感性格之间如履薄冰般地周旋。例如，在某些情况下，编写一些诸如数据生成程序测试等附属程序的人，也许会因其工作并不会在最终的系统中体现出来，使承担这项工作的人地位降低。尽管有些子程序需要克服重重困难才能完成，但是相对那些编写调用子序的主程序的程序员而言，子程序的作者往往也居于从属地位，或者是从子程序的从同地位类推过来的。不必经过理性的思考，这些拟人化的观点总会成为确定一支团队内部对任务分配满意程度的决定因素。这些因素的作用是实实在在的——或许正是因为其非理性的一面，他们的作用才最实在。
如果一个成员因为分配给他的工作而感到自卑，那么压抑这和成情将会给团队凝聚力带来灾难性的影响，采用共享式程序开发，共享了系统中的大部分，如果一个团队的工作进展得过快——以至于在有来得及在团队中建立起真正的共识——那么不是。。。
在程序开发的过程中，开发团队中各成员的地位，通常在很大程度上取决于其对其个人能力的了解程度。如果程序能够（在团队中自由）流通，供程序员们相互指正，那么“精英们”就能够更快地脱颖而出。反过来，如果团队成员都像苦行僧一隐居在各自的小隔间里独自工作，那么其在当前开发团队中的威望，就会更多地取决其在此前建立起来的声誉——至少在大家意识到这种评价的错误之前的确如此，然而等那时往往已经是无可救药了。
同样，在被分配给某项特定工作之后，某个成员也可能相应地获得或者丧失一些位。负责何种程序开发工作，将决定不同成员的身份地位——这就像办公室铺的地毯能反映主人级别一样。为了组织好一个团队，我们必须在推行工作的过程中，在各成员的感性格之间如履薄冰般地周旋。例如，在某些情况下，编写一些诸如数据生成程序测试等附属程序的人，也许会因其工作并不会在最终的系统中体现出来，使承担这项工作的人地位降低。尽管有些子程序需要克服重重困难才能完成，但是相对那些编写调用子序的主程序的程序员而言，子程序的作者往往也居于从属地位，或者是从子地位类推过来的。不必经过理性的思考，这些拟人化的观点总会成为确定一支对任务分配满意程度的决定因素。这些因素的作用是实实在在的——或许正是性的一面，它们的作用才更为实在。
建立共识目标的设定与认同如果一个成员因为分配给他的工作而感到自卑，那么压抑这种感情将会力带来灾难性的影响。采用无私式程序开发的方法，可以让每个人都感觉到于系统的一偶，而是共享了系统中的大部分，所以上述不良情绪将会得到缓此，如果一个团队的工作进展得过快——以至于在工程总体结构和任务分工等有来得及在团队中建立起真正的共识——那么不是在这儿就是在那儿，问题迟在很多其他领域中。
社会心理学家们已经证实：只要有一名（或者多名）目标不一致，那么该集体的整体水平就将受到影响。这种影响不仅来自本身，而且也来自于集体内部其他成员的绩效下降。
