读《团队之美》

正文之前

• 资深团队领导讲述发人深省和引以为戒的故事
• 团队构建软件，但是如果你们的团队不能在一起有效的工作，那么在软件开发这个游戏中，成功的机会将微乎其微
• 卓越的团队不仅产出成果，而且锻炼人，并能开出美丽的团队之花
• 任何一个稍具规模的项目都不是一个人能够完成的
• 毫无疑问，人员和团队是使项目成功的最重要因素
• 一个在公司解散前夕仍旧劲头十足、照常工作的团队；在面临人类的灾难时互相帮助、同舟共济的团队；为了同事的利益而表现出正义感和不懈努力的团队；一个为一千万人民提供洁净饮用水的团队。这些团队告诉了我们什么是团队之美。
• 团队中包含哪些成员更为重要：他们的技能如何，他们在一起工作的融洽程度如何
• “最佳”实践是不存在的——至少没有那种已知的实践方法能够保证每次都取得成功
• 你对不同的人运作项目的方式了解越多，对自己运作的项目帮助就越大
• 在正确的时机做出正确的决定，这对项目的成功非常重要

第1章 领导力

• 管理的技巧就是通过其他人的工作实现你的目标。而更重要的：写作的技巧就是创造一个能够激发其他人进行思考的环境
• 系统必须具有这样一个基本特征：每个任务都很小，人们能够独立完成
• 我们需要有一个可以激发人们创造力的体系，还要有一整套原则
• 狭缝令创造力如喷泉般涌出
• 骑过马的人都知道，要想骑好马，秘诀在于让马认为它做的是自己想做的事情
• 最好的领导就是能够让人们自觉自愿的去做事
• 完成的方法不止一种
• 领导一个团队，如何能让一群人发挥他们的潜力？关键是了解他们，了解他们能够做些什么
• 对自己做的工作要保守，接受别人的意见时要心胸开阔
• 如果你的系统结构良好，团队取得成功的机会就会大一些
• 没有最佳方案，只是做出的选择不同而已
• 也许上帝是为了让人们信仰而虚构出来的
• 创建一个令人信服的愿景并让别人接受
• 我们是一个小群体，在一起紧密的工作
• 你应当让人们自由的做他们的事情，然后看看他们的情况
• 我必须让事物动起来，然后再赶上它们
• 作为一个好领导，就是要知道人们什么时候有能力去做那些事情
• 你需要能和你争执的人，你需要人们有他自己的想法
• 美即是真，真即是美，这就包括你们所知道和该知道的一切
• 为了让人们能够一起工作，最重要的是给他们一个愿意接受的美学愿景。在你为自己构造的真理构建一个大家都能接受的愿景时，你也是在表达一种理想。因为只有这样才能让人们独立的、自由自在的追求那种理想

第一部分 人员

• 优秀的团队必须把重点放在团队成员的技术能力上
• 获得适当的团队成员并不是终极目标，它仅仅是完成了组建团队的第一步
• 人们需要能够一起融洽的工作，否则技能再好也没有用
• 最成功的团队实际上并不总是由最好的程序员组成，他们是由一些能够一起融洽工作的人组成的
• 团队中最有影响力的人并不总是最优秀的程序员。实际上，他们也不是经理或领导

第2章 丑陋团队的获胜之道

• 那些未能毁灭我的力量，反而使我更加坚强
• 我们中的大多数人受困于一种变形的、做作的、过于简化的美学认知，总觉得漂亮的就一定好，而丑陋的就必然糟；我们甚至都不愿去探究其他的可能性
• 完美的得分通常意味着能够亦步亦趋的遵循某些规则，这并不能表明此人富有激情、思想自由，而且愿意承担风险
• 没有风险、错误，不能同甘共苦，就难以形成人与人之间深厚的感情联系
• 漂亮的人们害怕伤疤，他们根本无法认识到伤疤的美丽之处
• 这些人会一起经历失败，然后互相舔舐伤疤，再共同重新振作，并仍像一个团队一样战斗。只有共同经历这些，团队才能发展处一种接近于美的特性
• 泰坦尼克号在下水当天身上铆着几千颗有毛病的铆钉

第3章 构建视频游戏

• 人们把他们的时间和技能都投入到团队工作中，他们也需要从团队中得到回报
• 说到什么是最好的领导，这要看你领导的是什么人了
• 领导者最优秀的能力是在开始的时候选择合适的团队，然后尽可能让团队成员实现自我领导
• 让合适的人待在一起非常重要，让两个彼此感到心烦的天才一起工作是很糟糕的事情
• 如果你不去尝试，那么永远都不会成功。如果真想去做，就要有所行动，动手做一做，看看会发生什么事情。需要行动起来，即使遇到困难也不放弃

第4章 打造完美团队

• 如果挤占培训时间，甚至不用等到项目结束就要付出代价
• 我们每个人都带来一些东西，我们每个人都做出了贡献，有一个对人们保持敏感的领导，这个领导知道人们的长处并接受他们的不足

第5章 激发开发人员的因素

• 社会关系交往是开源世界不可分割的一部分，不然，你不过是在自娱自乐罢了
• 你必须要对团队成员的工作状态保持敏感，并为他们提供一种工作环境，让他们觉得这是你能给出的最有趣、最好玩的社交环境
• 尊重他人是有益的
• 礼仪就是人际交往的润滑剂
• 关于礼仪，要记住三件事——尊重他人，倾听他人，每天洗澡。如果能做到这些，那就解决80%了。原因在于：如果你做不到，人们是不会愿意与你一起工作或跟你接触的
• 除了服务器着火之外，最影响工作效率的事情就是人们彼此憎恶，或无法共同工作。如果人与人之间存在任何发生冲突的可能，都应该马上进行处理
• 经理的职责是让人们顺畅工作，不受其他事情的阻碍
• 正在干扰团队的人们必须马上改变自己的行为
• 智者领导：工作做得最多、最好的人就应该受到奖励。如果奖励就是此人被视作社区一位值得尊敬的成员，那他成为领导也是顺气自然的

第6章 激励成员

• 如果人们不相信你会关心他们，那他们也不会在意你所说的话
• 我要做的就是给他一个有挑战性的环境，让他有动力去实现那个目标
• 在我们的团队中，每个人都处于职业生涯的某个阶段，将会到达某个目标，每个人都是不同的
• 人们渴望被关注
• 我们都讨厌别人批评自己，但又都擅长批评别人
• 如果是零风险，那么回报率也是零。没有风险是不可能获得成功的。风险就是不好的事情发生的可能性

第7章 将音乐带向21世纪

• 花时间设计简洁的架构，如果有已经公布的标准就按照标准进行设计

第8章 内部开源

• “为重用进行设计”太僵化了，效果不一定好，而且适应性很差。这也许是努力的方向，但是在可预计按的未来中不具有可行性。“使用-使用-重用”方法要更合适
• 无论设计的目的是什么，它总是在不断变化的，所以永远无法做到特别合适

第二部分 目标

• 在于团队一起工作时，团队目标不一致是可能出现的最糟糕的错误
• 团队要确保目标写在白板上，通过会议的方式，确保团队对任何变化都一清二楚
• 客户，也就是我们为之构建软件的人，并不善于告诉我们他们需要什么
• 作为开发人员，我们很容易认为自己已经完全了解了将要构建的软件
• 如果你从一开始就让每个人都与目标保持一致，在目标变化时让每个人都知道（目标总是在不停变化的），那么项目取得成功的可能性就会大得多

第9章 创建团队文化

• 如果你所在的地方做的是一些极富创新的产品，而你们缺乏相互信任的文化，哪么创新肯定会受到很大影响
• 软件开发是一种关于人的体验。如果能够尽可能的考虑人的体验，那么信任自然也就产生了
• 既要尊重个人的工作风格，又要满足业务的需求
• 作为优秀的项目经理，必须成为开发人员和组织的政治中间的一道屏障
• 最好的领导都非常善于表达，他们能够编写非常好的代码，他们也能够和外面的人进行交谈——他们能够超越代码本身
• 优秀的领导都非常在意人际关系，能够明白并尊重人们的感受
• 优秀的领导能够同时在多个抽象级别工作
• 你面对的往往都是一些技术能力很强的人，他们都有一定的自尊，傲慢与缺少尊重是让他们感到最恼火的事情。所以，请心态平和的进入角色。同时还要勇敢，不怕失败
• 要向权力部门讲真话，虽然这样做在拿自己的生计冒险，因为有些人难以迈出第一步，但是这个职位确实需要如此。你必须尊重事实，否则，整个过程就会变成一个又一个谎言。要对权力部门说真话，这点非常重要。这是把你的团队与令人不习惯的政治隔离开的另外一个方面
• 就算失败，你也总是能找到另外一份工作：生命短暂，不必浪费在拙劣的组织中
• 健康组织的标志之一是他们对失败不会过分渲染。
• 极度刻板、根本不想失败的组织一般来说也都是缺少创新的组织，那些人非常害怕失败，总是采取最保守的行为方式，所以他们也没有什么乐趣
• 在失败方面有一定自由度的组织是生产率更高的团队
• 持久的组织一般都会不断的重构，不仅仅是程序级别的重构，还包括架构级别的重构
• 把重点放在可执行的代码上，将没有加工过的代码作为初始产品推出，这是最重要的事情，是一个敏捷过程
• 以增量、迭代的方式完成事情，节奏有一定规律，可以引入重构，在某个时刻可以做的稍微差一点，并且有并行的路径让你尝试一些东西
• 把重点放在架构上，把架构作为管控手段之一

第10章 让“我”为失败负责

• 软件项目的总体失败率高达80%
• 实践方法并不能确保成功
• 尽力为人们争取一些更为合理的目标，尽管有些时候你的愿望无法实现

第11章 制定计划

• 优秀团队都能从清晰明确、引人向上的目标中受益
• 想赚很多钱并没有错，但那并不能让团队团结一心，达成非同一般的目标
• 做的越好的团队走的越快。如果你能写出高质量的代码，你就可以加快步伐，因为没有那么多代码拖你的后腿
• 相对劣质代码而言，好代码能够提升开发速度
• 清晰、催人向上的目标
• 一个应用中所有的代码不一定都要处于同样质量水平
• 不是每件事情都要做到一流。在大多数情况下，我们根本没有机会做到一流
• 不管工作流程的其他部分有多么好，如果它不能提供某种程度上的可预测性，就无法使用

第12章 公众利益斗士攻占邪恶之城

• 有时候，一定的成本消耗是不可避免的
• 身处社会之中，我们只能做这样的事，它们产出的价值一定要比废话多。项目越大，变为废话的成本就越多

第13章 保卫自由世界

• 要有向更高目标前进的感觉
• 让我们的技术人员从客户那里获取深入的领域知识

第三部分 实践

• 所有的团队（即使每个团队成员都表现出色而且配合默契）都存在不好的习惯
• 要找到更好的做事方法，这样团队就不会一再受困于同样的老问题了
• 改变团队的文化特别危险，这一点不必怀疑。实际上，不仅仅是文化会受到影响，改变甚至会威胁到团队自身的存在。
• 在尝试使用新实践的时候，团队会面临两个主要风险：一个风险是实践本身可能没有价值，而推动这个实践的人对此一无所知；实践本身确实很不错，团队成员却无法深入体会其妙处。
• 对于团队文化来说，最危险的事情莫过于在他们身上强加不适合他们的改变

第15章 构建协作性和学习型的团队

• 团队要保持活力，以高效开发软件。过多加班会降低产品质量，让人员疲惫不堪，得到难以预测的产出。每个人都会努力工作，但是要保持可持续的速度
• 构成伟大团队的一个要件：一位眼光长远、敢作敢当、愿意支持团队的管理者
• 唯一具备所有细节的需求形式就是代码
• 一粒老鼠屎真的会坏一锅汤。某人的情绪不对头，真的会毒害整个协作团队
• 要改变现状还是有可能的
• 只要人们想协作，他们就会去协作。如何提升想协作的气氛？
  • 提升他人：认可他人
  • 提升安全感：支持其他人，可以挑战别人的想法，但是要予以实践
  • 取得进度：成功孕育成功
  • 增加活力：挑战和奉献

第16章 更好的实践

• 质量就是要满足需求
• 如果人们很自私，只愿意做他们喜欢做的事情，就很难建立一个高绩效的团队了
• 作为团队领导，大量的思想应当投入到团队的目标上
• 做一些工作来培养团队，这对工作本身是有帮助的
• 士气与激励通常都是相关的，但并不总是这样
• 我们学习的课程告诉我们你是一名个体程序员，你的目标是成为编程大师，但是在参加工作以后，面临的环境无一例外都是基于团队的
• 如果某个程序员是不可或缺的，那么应当解雇他
• 团队中的问题程序员代表了对项目的超高风险；他们可能并没有那么出色；他们耗尽了团队其他成员的精力。作为经历，可以想办法培训他们，让他们变得更好；作为老板，应该尽早摆脱他们以降低成本
• 组织规模越大，层次越多，就越难维持开放与责任制，因为会存在一些小区域

第17章 TRW软件生产率项目回忆录

• 文化变革是困难的，而在大型组织中跟上技术的快速步伐就更加难了
• 在开发上每投入一元钱，就需要在软件生命周期中花费两元钱来保证产品是可用的
• 打造完美团队的关键之处
  • 识别所有对成功至关重要的利益相关者，并将他们全部包括进来
  • 事先做大量的倾听、探索和团队构建工作
  • 指定一个产品及其结构的愿景，并让大家都知道
  • 支持以为思想开放、善于倾听、善于打造团队的经理
  • 鼓励来自外部和内部的思维创新
  • 关注并处理团队的需求
  • 以尊重个人的方式调配相处不融洽的团队成员
  • 与有冲突的利益相关者协商一个双赢的解决方案
  • 仔细的监控进度并主动的处理决定成功的威胁

第18章 建造宇宙飞船

• 团队是很难管理的，有时候让不同技能的和不同个性的人恰当的组合在一起是一件很有挑战的事情
• 如果太多的人都有很强的个性，就很容易产生分歧了；如果太多的人都很温顺，你可能就无法得到最优秀的想法了。需要在二者之间找到平衡点。需要有一个让人感到安全的环境，让他们表达出他们关注的问题以及他们的想法
• 影响团队日常运作的因素有两个：个人性格和责任
• 最佳团队都有一个共同目标。在为同一个目标而努力，彼此欣赏。尊重每个人。每个人都明白，团队中的每一个人都做出了自己的贡献
• 最让人满意的项目做的不一定是伟大的事情，而是那些团结一致、每个人都因为自己的贡献而受到尊敬的项目

第19章 成功的需求

• 常常的，团队在开始一个项目时并没有讨论如何进行协作。在项目支出就应当花些时间讨论团队如何运作，这段时间的投入是值得的
• “你们需要什么？”在挖掘需求的时候这是一个最没用的问题了。“你们打算利用系统做些什么？”是更好的提问方式
• 马拉松式的会议是没有用处的，因为在几个小时后，疲劳的眼睛就很难再贡献更多有价值的意见了

第20章 在Google的开发工作

• 团队经理的成功就是团队的成功
• 有了敏捷方法的高可视性，就能够早早的面对痛苦的现实了。你面对现实越早，痛苦就越少。虽然仍旧是痛苦，但那是修复问题所带来的痛苦。
• 敏捷方法的缺点是无法隐瞒，这对很多开发人员和经理来说都非常恐怖
• 完成的意思就是完成了。完成的意思就是明天可以交付了
• 任何被检入、审批、接受的主干代码，任何一个调用功能部件的详细过程在完成之后，都应当可以在今天交付
• 确定下来需要做些什么，这是项目工作量的最主要的一部分，在项目过程中还需要做出调整，以便和利益相关者的需要做出相应
• 燃烧图回答的问题完全是投入的工作量以及完成的工作
• 在截至日期之前没有经过测试、承诺和接受的东西都不在这个迭代中
• 迭代中间的需求改变不是让你的团队成员大吃一惊的、出乎意料的随机改变。这是有计划的，它是可以预测的
• 工程师们，特别是年轻、聪明但是做过的项目不多、也没有留下伤痕的工程师们，一般都喜欢多做一些东西。
• 开发团队可以归结为两个主要目的：开发正确的软件，以正确的方式开发软件
• 更重要的是开发合适的软件：软件的功能集要让公司能够成功

第21章 团队与工具

• 优秀的工具对团队协作能力有变革效应
• 在项目中引入一个新标准并不是一件容易的事情
• 完美不可与优秀为敌
• 即使一小步自动化工作也可能给团队的协作能力带来显著差异
• 对一个普通任务增加几秒钟的额外开销足以让这个任务变得不再普通
• 你的团队不是懒人，只是普通人
• 对代码的提交进行评审保持了代价的士气，提高了人们的技能（因为他们都能相互学习），增强了团队一起工作的能力（因为每个人都习惯于接受他人有建设性的批评），并且对参与项目形成了激励（因为评审是公开的，所以鼓励其他人做同样的事情）
• 如果一开始就面对一条陡峭的学习曲线，真是再糟糕不过了
• 部分自动化常常已经足以产生差别
• 好工具的关键并不是说不再需要人们，而是让人们更快乐

第22章 研究团队

• 如果不知道一件事情对不对，就必须通过试验来证明

第23 章 HADS团队

• 一个高级语言编译器，能够跟踪利用的知识比程序员脑海中保留的知识要全面的多
• 如果用户找不到其他原因，就要责怪工具了

第四部分 障碍

• 在构建软件的时候，一些最难处理的问题是那些你无法控制的事情
• 如果不处理那些阻挡团队道路的障碍，软件将很难构建。一个最大障碍就是糟糕的经理
• 人的本性都倾向于谈论自己的失败
• 在每一种情况中，都有一个重要的经验需要学习，人们由于经验而变得强大，即使他们所在的团队本身已经不存在了

第24章 糟糕的上司

• 有些时候，在明天道歉比今天获得批准更好

第26章 跨越障碍

• 在软件团队中，人是成功最主要的因素。你和其他人的交流方式比你今天使用的任何一种很酷的新技术所产生的影响都要大
• 需要关注的不仅仅是技术
• 不是每个人都一样，有些人就是不愿意在团队中工作。有些工作是可以单枪匹马完成的。
• 敏捷开发：有纪律的敏捷软件开发是一种迭代和增量（演进）的软件开发方法，由自我组织的团队通过高度协作的方式，在一个繁文缛节“刚好足够”的有效的监管体系下，以节省成本和及时的方式生产高质量的软件，从而满足利益相关者不断变化的需求
• 需要有人密切注意整个团队，确保整个团队停留在正轨上，确保他们所作的任何事情对整个组织来说都是有意义的
• 糟糕的监管会削弱领导能力，让我们试着提高监管的有效性，因为监管的价值在于帮我们做出好的决策，走向正确的方向
• 把洗澡水倒掉，但把孩子留下
• 一个组织总会有很多要做的事情，但是资金只有这么多，所以他们必须选择做些什么，希望能够有效的完成。因为你要确保实现那些目标，所以项目决定了工作量。如果目标发生了变化，要确保自己立刻跟着变，你需要监管这种发展。你需要常常对照现实情况做出检查，应当经常进行检查，但实际上并没有做到。
• 项目遇到困难时，必须有人做出决策，看看如何把团队带出困境。如果没有人知道如何把团队带出困境，现在就需要切断供给，不要再把钱扔到没有用的地方
• 让项目与公司保持一致，确保项目构建的是它应该构建的东西
• 如果一组人在一起工作的时间足够长，他们就开始以同样的方式思考了，对于同样的问题产生盲点
• 监管应当与授权和激励有关，不应当成为命令和控制的方式，不应当成为负担
• 做监管的人最常犯的一个错误是试图把同样的过程和同样的监管体系强加给不同的团队，因为不同的团队需要不同的方法来监管，所以这种方法是行不通的。目标可能是一样的，但是实现这些目标的方式是不同的。你应当实现可重复的结果，不是可重复的过程
• 愿意寻求帮助是至关重要的，但是愿意给予帮助也是至关重要的。武术的一个原则是通过帮助与教导别人，比你自己学习能够学到的东西要多
• 不仅要帮助他们完成工作，还要帮助他们以专业的方式开发
• 对于结对编程，你需要做的就是坚持到底做下去

第27章 速度与质量

• 团队有一个“绅士般”的文化，在出现糟糕的事情时也不会说脏话
• 抓紧那些小任务，如果遇到困难，请告诉我

第28章 层层障碍铺垫之路

• 如今的猪圈都有格子间的两倍大
• 摆脱掉这些拖后腿的家伙后，如果你要是做的事情太少，那么自己都会觉得内疚。因为你环顾四周会发现所有人都忙的不亦乐乎，于是你也只能努力工作了
• 质量问题的开销在产品时间线上呈非线性
• 质量是一家企业成败与否的最根本因素
• 质量问题就像地雷，可以潜藏很长时间。恰恰在最不合时宜的时候，它们会给我们造成严重的损害
• 没有了乐趣，这就只是一份工作而已，甚至还算不上什么好工作

第29章 办公室内外

• 孩子们不喜欢向父母表露自己的感情，需要仔细的观察

第30章 汇集团队的声音

• 企业的创建和消亡是已经很平常的事情。它们留下的永久财产是那些雇员们
• 项目对员工成长的影响与项目的既定目标同样重要
• 负责理性行为的自我退回到本我，导致本能冲动的爆发
• 让每个人的意见都能得以表达
• 每一次成功和失败都可以用来帮助改进团队建设
• 每一个项目决策都应该考虑它对团队成员和项目资源有何影响
• 消除那些没用的会议
• 项目的加速前进只能让时间变得更快
• 历史上，公司在作出重要的工程决策时都会重视工程师的意见
• 尊重工程师，容忍他们固执己见的表达方式
• 公司应该彻底开发并利用雇员（或客户以及其他利益相关者）的潜力，使他们成为有发言权的组织政策制定者
• 我们没有必要去努力维持一个正在消亡的商业模式

第五部分 音乐

• 随波逐流、全凭感觉是不够的。美学愿景驱动着过程
• 如果人员足够优秀，受到激励、产生兴趣并且具备技能，是可以奏出曲目的，让他们有所领悟并即兴发挥

第31章 制作音乐

• 要成为项目经理，应当对将管理的所有工作都非常熟悉。你不需要是最好的，只要掌握了每项工作的知识就可以了
• 某些人如果尊重你的能力，就会按照你的指导去做，或听从你的建议，至少认为你的知识足以给他们指导
• 学习如何跟人们说话实际上是一门非常重要的课程
• 你的诚实和承认错误的勇气能够让团队保持对你的尊重。如果你想掩饰自己的无知或让自己看上去总是很清高，你就越来越像个赝品，团队会离你而去
• 好的项目经理一个最正面的目标是激发出项目成员最好的一面，而不是抑制他们，不能妨碍他们前进，不要把他们挤在两堵墙中间
• 你要做的是在团队中培养英雄，让你团队中的人（如果可能，是团队的所有人）都能发光，让你们的团队看上去像是一个顶尖的团队
• 你必须让他们的意见得到倾听，你必须这样做，一定要这样做
• 当你拒绝某人的想法时不要针对个人
• 交流的方式可以有多种，当你发现他们走错路的时候，你要激发出人们最好的一面而不是抑制他们
• 要么好，要么不好，总要有个人出来说一下
• 你一定不能有这种想法，认为付钱给你制作这一切的人是敌人
• 如果早期让出资人介入，那么他们会因为感到自己介入了中间过程而对最后的结果更容易接受
• 你必须具备技术能力，你必须理解程序员的问题，你也必须理解公司的利润问题
• 挑选团队成员时要非常小心
• 你必须根据人们以后是否能够融洽相处来建立自己的团队。一旦出现问题，你有终极武器：解雇某个团队成员。这不是坏事。这可能成为很好的事情，因为如果能够摆脱麻烦制造者，团队的力量会得到增强。
• 解雇人是不可避免的
• 如果你冲着他们叫嚷，他们听到的不是你说的话，而是你的怒气。你必须控制怒气
• 当你讲出事实的时候可能会很生气，但是不要显露出来，它会让你付出代价的
• 公开的进度图让每个人都能参与进来
• 任何一个涉及大量资金的事情都需要有组织
• 在做项目的时候，必须诚实的考虑预算所带来的约束
• 交互的事情能够让团队真正的融合到一起。如果你在做决策的时候能够让他们参与，他们会非常热心
• 人类的思考方式很奇怪，有高度创造力的人社交技能一般都不好，因为他们大部分的脑力都用到了高度创造力的事情上
• 如果没有“明星”，将无法成为一个团队
• 真正聪明的“明星”知道如果没有一个优秀的团队，他们将很难成功
• 你必须是团队中最清醒的人
• 在这个充满天才的世界上，任何一个团队都可能被替换掉。每个人都有责任学习如何与其他人一起相处，就算是“明星”也不例外
• 你们是在与其他顶尖团队竞争，你不能让内部有争吵，你不能让团队的明争暗斗破坏士气和团队生产率。
• 一个态度好的人会替换掉你。谁都可以被替换
• 现在有太多让人分心的东西，让我们很难把精力集中在所从事的事情上
• 计算机技能并不难获得
• 我们的危险是失去了集中注意力去掌握一样东西的能力
• 你知道的越多、学习的越多，你人生中成功的机会就越大

• 把你的闲暇时间拿出来，多学点东西

from: http://dearymz.blog.163.com/blog/static/205657420110884838587/?suggestedreading&wumii