传统的“胡萝卜加大棒”的激励方式仅仅对于那些重复的，机械性的任务有效。一旦要做的事情稍微复杂一点，而你需要解决哪怕很小但又没有现成解决方案或无规律可循的问题时，这些基于物质的激励方式不但没有效果，反而会把事情弄得更糟。
Dan Pink为这个主题写了一本书《驱动力：在奖励与惩罚都已失效的当下，如何焕发人的热情》
在建设自己的团队时，不在乎你什么时候来上班，或者如何安排你的时间，不在乎你住在哪里，不在乎你怎么做你的工作，也不会事无巨细的过问，给你一大堆的任务，这些都不重要。
重要的是如果你想造一艘船，就不要催着工人们去收集木材，分派工作，发号施令，你应该教会他们的是对无边无际大海的渴望。
磨刀不误砍柴工，我们在编程之余，最好也要去学习一些与编程无关的内容。
当我们阅读编程相关的博客或书籍时，我们通常是这样做的：
每当读起一篇博文，我们会把我们认同的内容一点一点读下去，而只要有一个论点不符合我们的世界观，我们就会很较真。如果整篇文章的主题都跟我们的成见相左，我们就会大骂作者是个白痴。老实说，如果让我们去做销售，结果会一塌糊涂，因为我们一碰到不认同我们的人就会匆匆放弃。
所以我们最好要向销售人员学习。当我们再读一篇帖子，或者一本书，或者学习一门新语言时，我们应该假定它的某些部分（甚至绝大部分）并不新颖，让我们假设我们肯定会讨厌它的某些部分。与此同时，如果我们能找到哪怕一点儿对我们有用的知识，我们就已经赚了。
这是看书好的心态，我们客观上来说，应该读好书，读经典，但是如果读到一本书感觉没什么收获，也没什么可失落的，正常情况。
当然，过多的磨锯，或者随意地，没有目标地磨锯子，会变成另一种形式地问题，但是如果一个程序员对这些毫无兴趣，也是一个巨大地信号。
对磨锯子痴迷是没有问题地，但前提是，这种痴迷是类似于Hackers News地网站上积极地提交和讨论与编程相关地文章。
在《质量·软件·管理：系统思维（第1卷）》一书中说明，哪怕在工作负荷中只是增加一个项目，也会严重地影响你地效率，你会损失20%的时间，当你增加第三个项目的时候，你很可能会有一半的时间浪费在任务切换上，即使同一时间只做一个项目，也可能会出现这样的问题。
我们总是认为，我们可以多任务而不降低自己的任务质量，但是多方面的研究告诉我们，我们不能做到，我们必然会在时间，质量以及深度思考能力各方面都受到损害。
而编程中可能表现比较明显，因为编程需要程序员记忆大量的东西，能同时记住的东西越多，编程的效率就越高，包括变量名称，数据结构，重要的编程接口，常用的工具函数名称等，如果来回切换项目，这些都需要重新记忆，就会浪费掉很多的时间。
《程序员修炼之道：从小工到专家》中的“select没有问题”。
这是这本书提到的一个小故事，目的是说，当我们开始为了一个很可能是我们自己造成的错误而责怪系统时，我们都会用“select有问题”这个短语作为善意的提醒。
注释写的太多，不一定是一件好事，作为程序员，应该总是专注于编写代码，而忘了还有注释这种东西的存在。为了让你的程序员更容易阅读和理解你的代码，你需要不断地改进你地代码，但如果你已经重写，重构甚至是重新设计了很多遍——当你已经一筹莫展，已经想不出任何办法可以让你地代码变得更加浅显易懂时，这个时候，也只有这个时候，你才应该在百般无奈之下加上些注释来解释你的代码。
如果你的代码在没有注释的情况下显得过于复杂，很难被人理解，只能说明你的代码写的太糟糕了。重写你的代码吧，直到它不再需要任何注释，如果经过努力，你仍然觉得注释时必需的，那你就务必加上注释，切记，小心！
学会读源代码是很重要的，因为不管文档上怎么说，源代码才是最终的事实，是我们能找到的最好的，最确定的，最新的“文档”。这个事实永远不会改变，所以越早接受它，作为一名软件开发者的境况会越好。
当你经营一个公司，如果你的软件出了故障，你的客户不会在乎是你的失误还是linux的，或者是由Redis的开发人员造成的，他们只知道是你的软件出了问题。
所以真正的骇客世界只有一个简单的事实：如果一个软件在我的机器上运行，那它就是我的软件。我要对它负责，我必须吧它弄明白，从源代码开始构建是一条必须遵循的原则，而且从不例外，我必须控制我的环境，我还要控制所有我依赖的东西。
网站载入和显示的速度哪怕是100毫秒为单位的延迟增加，也会让用户大量的流失。
对于速度的需求，有这样一个小建议：虔诚地遵循雅虎的指导原则
2007年以来，雅虎有一个“加速你的网站的13条简单原则”，另外还附带了一条告诫：
这里有一些不错的建议，但是其中很多的建议只有在你运营了一个每天有几百万独立用户访问的网站时才有意义。
Gerald Weinberg的著作《成为技术领导者——解决问题的有机方法》对软件工程领域的领导力做了更为深入的分析。
会议是浪费工作时间的最佳去处，我们应该以怀疑的态度去看待会议，把它当成一种降低工作效率的风险。
有下面几个建议：
1、会议绝对不应该超过一个小时，否则应判以死刑。
2、每个会议都应该有一个清晰的目标声明。
3、在开会之前就应该预先做好功课。
4、把会议变成可选的。（“强制”的会议是站不住脚的，每一个出现在会议上的人都应该是因为他们想要在那里，或者他们需要在那里。一种让你自己对会议负责的可靠方法，就是让每个人自行决定是否要参加你的会议。如果大家都想参加你的会议，那一定是因为它真的很有用，或者很有趣，或者很娱乐。）
5、在会议结束时概括一下待办事项。
坏苹果法则：
如果把一个坏苹果留在一筐好苹果里，结果你将得到一筐坏苹果。如果你希望自己的企业成功，那么你就必须有一个积极进取的团队。
我们在团队中，不必和每个人都成为朋友，需要去识别出“坏苹果”，团队中有“坏苹果”大概有下面这些警示信息：
- 他们掩饰自己的无知，而不是尽力去向他们的团队伙伴学习。他们会说：“我不知道该怎么解释我的设计，我只知道它能正常工作。”或者“我的代码太复杂了，没办法测试。”
- 他们对个人隐私有着过度的渴望。会说：“我不需要任何人来查看我的代码。”
- 他们很在意自己的地盘。会说：“我代码里的问题没人能修复。但我现在太忙，没时间去管它们，我打算下周处理它们。”
- 抱怨团队所做的决定，即便团队已经继续前进了很久之后还会重拾旧题。会说：“我还是认为，我们应该回过头去修改我们上个月讨论的那个设计，我们当初选择的那个是行不通的。”
- 团队中大部分成员开始传说关于同一个人的俏皮话或者埋怨他（软件开发人员通常不会直接抱怨），领导者需要去探查是否有什么状况发生。
- 不会积极投入团队的行动。
如果你的团队主管或者经理没有处理项目中的“坏苹果”，那他就是玩忽职守。
我们可以培养一个人的技能，但是不能让他们有积极的态度，把某个人从团队中调走是很痛苦的，这件事对任何人来说都没有趣，但是，如果你意识到你本应该在六个月前就把某人调走时，其实你已经陷入更加痛苦的境地了。
程序员天生就有强迫症。
讲究逻辑性，讲究有序性，思维缜密（防止bug），考虑边界条件，写代码之前需要做好规划。
要做单元测试的12个具体理由：
- 单元测试可以证明你的代码是能真正解决问题的。
- 你可以在不破坏现有功能的基础上持续改进设计。
- 它们可以被用来真实地展示开发速度。
- 单元测试可以当做示例代码。
- 它逼着你在写代码之前做好计划。
- 它比不写单元测试而直接写代码的效率更高。
