前几周买了本《高效能程序员的修炼》，花了几个周末的时间读完了
P8 何去何从
作为一名软件工程师你非常成功，你的能力使你在工作中游刃有余。你从来不会为得到一份满意的工作而发愁。你的同事也非常尊敬你。每一家你曾经工作过的公司都因为你的加盟而在某些方面得到了提升。 但问题是：接下来你将何去何从？
P19 阅读的心态
只要我们在读了100个帖子后能学到一样有价值的新东西，我们就已经赚大了。
P27 同时做多个项目
总结来说：同时做多个功能，或经常被“紧急”事情打断，会导致效率低下。
P28 永远都是你的错
你写的代码在任何时候出了问题，那一定都是你的错。
P36 避免写注释
如果你觉得你的代码在没有注释的情况下显得过于复杂、很难被人理解，那只能说明你的代码写得很糟糕。重写你的代码吧，直到它不再需要任何注释。如果经过了这些努力，你仍然觉得注释是必需的，那么就尽你所能加上注释吧。切记，小心！
P43 向橡皮鸭求助
强迫自己去完整地解释自己的问题（最好以书面形式），常常也会引领你进入新的视野或为你带来新的发现。
P52 电梯测试
你团队里的每个人都应该能通过由陌生人主持的“电梯测试”——在60秒之内，清晰地解释他们在做什么，以及为什么人们会在意他们正在做的事情。
在缺乏清晰的远景声明时，无法通过“电梯测试”的团队的数目将是令人震惊的——他们不能解释他们正在做什么，或者为什么他们的工作是有意义的。
P60 招聘程序员须得其法
- 只雇用认同公司文化的人。
- 电话面试的注意事项和聊的内容。
- 软件开发者最擅长的就是学习。
- 工作经验年数与编程技能之间是没有必然联系的。
- 与程序员面谈面试相关的考察点。
P86 领导须以身作则
最有效的一种技术领导就是以身作则。
P98 处理坏苹果
列举了一些警报信号，用以识别你的团队中是否有”坏苹果”：
- 他们掩饰自己的无知，而不是尽力去向他们的团队伙伴学习。他们会说：”我不知道该怎么解释我的设计。我只知道它能正常工作。”或者”我的代码太复杂了，没办法测试。”（这些可都是他们的原话。）
- 他们对个人隐私有着过度的渴望。他们会说：”我不需要任何人来查看我的代码。”
- 他们很在意自己的地盘。他们会说：”我代码里的问题没人能修复。但我现在太忙了，没时间去管它们。我打算下周处理它们。”
- 他们抱怨团队所做的决定，并且在团队已经继续前进了很久之后还会重拾旧题。他们会说：”我还是认为，我们应该回过头去修改我们上个月讨论的那个设计。我们当初选择的那个是行不通的。”
- 所有其他的团队成员都在传说关于同一个人的俏皮话或者抱怨他。软件开发人员通常不会直接抱怨，因此当你听到很多俏皮话的时候，你必须去查探是否有什么状况发生。
- 他们不会积极投入团队的行动。在我经历的一个项目中，就在我们第一个重要的截止日期的前两天，有个开发人员突然要求请一天假。原因是什么呢？他想那天去参加邻城的一个男装展销会-那清晰地表明他并没有融入整个团队。
坏苹果是团队的毒药，除掉害群之马
P106 固定的邮件列表
每次当你看到有东西从邮件列表发到你的信箱时，你最好从内心深处相信它包含着有用的信息。一旦邮件列表沦落成了”等我有时间再去读那些东西”、噪音引擎或者工作之余的消遣，就说明有人喊”狼来了”喊得太多了，已经把这个邮件列表给毁了。因此，一定要非常小心。嘈杂的、有争论的或者没用的东西不应该被发布到邮件列表里去。要不然，就狠敲他们的脑袋！
RTX群聊类似于邮件列表，要注意这点。
P107 周一的团队状态报告
每个星期一（就像星期一综合征那么规律），每个团队都应该生成一个简报以概要说明:
- 我们上周做了些什么？
- 我们这周准备做些什么？
- 有什么事情在阻碍我们或者让我们担忧？
P126 设计时要把用户放在心上
- 细节决定成败
- 你的团队对用户反馈的响应速度会为你的软件定下基调。
- 即使第一版做的很差劲，也要坚持把它发布出去。
P187 代码评审：说做就做
同级之间的代码评审是你为提高代码质量所能做的最大的贡献。
P195 我同情那些不写单元测试的傻瓜
任何时候当你想把某些信息打印到屏幕或输出给调试器，你都应该把它改写成一个单元测试。
P196 单元测试和Beta测试的对比
只有当你把你的软件交给Beta测试者的时候，真正的、最有价值的测试才算开始。如果因为写单元测试牺牲了Beta测试的时间，那你正在犯一个非常严重的错误。
P206 倾听社区的声音，但别被它们牵着鼻子走
90%的社区反馈都是垃圾，但这也意味着，有另外10%的社区反馈是非常棒的！假如你有毅力看上上百条帖子，我保证你会发现其中有10条的含金量很高，而就是它们能让你的网站得到明显的提升。做好准备吧，若想从一大堆社区反馈里挖掘出“宝石”，你需要花很多时间，而且这时间还不是一般的多！我坚信，每个社区总会有一些足够聪明的人来制造一定数量的“宝石”，他们常常让你喜出望外。