卓越程序员密码一书，也是在图书馆偶然翻到，作者通过比喻、动力、生产力、复杂性、教学、客户、代码及自豪感这些方面来叙述了程序员在工作中会形成的坏习惯及遇到的问题，也包括改进的一些策略。本身也是作者几十年从事软件行业的得到的一笔隐藏的宝贵财富。就如书的简介所说，本书讲的不是你写的代码，而是你赖以生存的密码。
分享自己的部分读书笔记，希望能勾起你打开这本书的欲望：
扔掉旧代码
我是在收纳代码(coding hoarding)，把我觉得再也用不上的代码注释掉。虽然我们对所有源代码都有版本控制（你绝对也应该这么做），但我实在没勇气把它们都删掉。因为我随时都可以找回那些旧代码，所以能直接删掉的时候，就没必要注释掉了。
收纳代码实际上是制造了更多的障碍。每次我干活的时候，周围的旧代码总会让我分神，没法专注在眼前最重要的事情上。即使我确定要重新实现我前一阵子写过的东西，早先注释掉的东西一般来说也无论如何用不上。我可能把其他地方的逻辑动过了，旧代码里面引用的对象或者方法可能变了。比起重新干干净净地把代码写对，要把这旧代码救活，我得花更多的时间在那儿东敲西补。
不要把代码囤积在注释里，删除代码可以让代码库精简。眼前的页面应该精确的反映出软件现在的工作方式，一分不多，一分不少。现在就扔掉旧代码，在编程中间就不用跳过一堆不相干的垃圾字节。我们以后也用不着去琢磨，这一大团已经注释掉可看起来还很重要的代码，到底还是不是那么重要。
工作即福利
我所见到的每个有激情的程序员，在谈论起经过长时间苦苦思索才为技术问题找到的优雅解决方案时，都异常兴奋，这比说起在公司编程大会上赢得10%的加薪要兴奋的多。
不要只因为加薪就耗在你痛恨得工作上，把这种工作思路留给那些就为了挣钱而编程，然后消磨时光企盼周末的人吧。
去那些有机会漂亮地做出东西的地方，在这里真实的项目才是大家的兴趣核心。你在工资上所牺牲的（如果你真的需要牺牲的话），将在幸福感上得到更多弥补。
好公司的一个标志就是它对待项目的方式。好的项目有明确而具体的目标。好的项目要么万事俱备，要么有做到万事俱备的计划。好的项目既有宏伟的目标，又经过周密的思考。好的项目有确定的交付时间，而不是时间和预算都含糊不清。这种项目给工作设立了一个目标。我参与的编程项目数以百计，所有好的项目都有这些给人动力的特质。
在选择下一份工作的时候，记住那个能够让我们长期保持干劲的东西——不是外部的福利，而是工作本身。
莫求全
要在这个行业中生存下来，你最好不是个完美主义者，因为没有什么软件是完美的，特别是基于网络的软件。我们的产品是通过用户存活下来的。用户基数增长的时候，它会发生嬗变。新功能会不断呈现，新bug也会不断产生，所以要求完美实在让人精疲力尽。
一个程序员最开始写下第一行代码时所采用的方法，和他今天所用的方法很可能大相径庭。软件会随着时间变化。我们编写、调整、反复，有时候还得重写，所以最好能适应这一点。
没有什么“高招”能够确定某种方式就一定是对的。
休止一下
当代码开始变得有点拖沓的时候——或者，最好是在这之前——就停下来。良好的编程习惯是在精力充沛时高效地工作，而不是一味地呆在屏幕前。两个小时的高质量编程胜过八个小时的煎熬。我们编程编累了的时候，更容易走个捷径，或是违反标准规则。那些低效的时间最后都写了些坏代码——我们第二天就可能后悔的代码。所以请缩短编程时间，出去走走，享受一下生活吧。
早起先测试
早起上班第一件事：测试你的软件。这是你最清醒、最有动力写点好东西的时候。早晨，我们会忘记前夜困扰我们的繁复的代码细节，也不会纠缠于某个功能不太精彩的实现，我们会全心投入眼前所见的东西，而不去思考它背后发生的事情。
测试的时候，从头开始。不要纠缠于某个部分，重新体验一遍就对了。前夜，你可能在实现一个功能，但真正的用户可能只会使用它一两次，甚至从来不会去用。早晨，要专注于那些大多数人会经常使用的功能。关注软件中的优先事项，关注那些需要首先修正的东西，这种方式好得多。
别在卧室里工作
正如帕金森定律所说:“工作会不断膨胀，直至占满所有可用的时间之后才会完成。”由于我可以在一天中的任何时间“工作”，所以可占用的时间就多了去了。每周40个小时的工作忽然变成了168个小时的工作+睡觉+吃喝娱乐。
千万不要在卧室里办公，最好也不要在起居室。搞出一个封闭的工作区，最好是单独的一个房间，这样就可以在工作时间结束后从那里离开。
第一印象也就那么回事
我不是说第一印象毫无价值，但第一次见到某个东西的时候，最初的反应通常不过是对不熟悉事物的反应而已。人类天生会对新事物心怀畏惧。但是，作为开发人员，我们常常太把用户的第一反应当回事了。
第一印象常常是不准确的，因为我们不知道最后是否会适应这个软件。所以当你从顾客、客户或是同事那里得到负面反馈的时候，要坚持自己的想法，解释你这样做的道理，让他们适应你的作品几天，而不要让最初的即时反馈打消你的积极性。如果问题仍然存在，那么你的软件可能确实有瑕疵，但你会惊讶地发现，很多最初的负面印象通常都消失了。
对消闲项目坚决说不
时间是保持编程动力的最重要的因素，对于消闲项目来说，刚开始写代码的时候，你可以出于好玩或者学习的目的。但是当你决定认真对待它的时候，就需要定下一个期限。如果能正确处理下面几个问题，就可以把它变成真正的项目。
我每周要花几天、每天要花多少时间在这个项目上？
我什么时候能把一个基本成型的产品展示给别人？
哪一天向公众发布？
哪一天发布第一个主要的更新版本？
最后期限创造了一种紧迫感，敦促你冲过终点线。即使没有人在逼迫你，它也能给你所需的鞭策。
去掉时间表中的细节
在最开始的时候，根本没办法制定出一个完美的计划。所以，开始做计划的时候，要少计划些细节。
不要为软件中的每个交互动作设定交付期限，而是确定何时完成一个完整的部分。说到底，时间总量是一样的，但中间的检查点要少一些。
在各交付物之间留出合理的时间，以便我们施展身手。可以把一个大型项目分割成多个微型项目，但我们仍然有机会以自己想要的方式来进行开发。这也让我们可以在下次交付前反复雕琢几次。在下次交付前留出一两个星期，也就允许我们多犯几次错误，但仍然能够按时完成。
每天改进产品的两个方面
“二”这个数字本身也很重要。做一个改进有时候让人为难，因为我们不知道到底选哪个；而且“一”跟“零”也没有多大差别。此外，“一”很容易让我们觉得，今天不做也没什么，可以明天再补上。反过来，每天做“三”点改进又太多了。所以，“二”才是那个神奇的数字。
决定每天改进产品的两个方面是一个很好的想法，它可以保证大型项目不断向前推进。一周下来，你的产品就会有十项改进；一个月下来，你的产品就有四十项改进了。
为良好的工作环境投资
在厨房里做的每一件事都跟撕保鲜膜类似。要是每件工具都不那么称手，那么烹饪的体验就会充斥着一个个效率低下的环节。每次完成工作时遇到的小障碍越多，我们的效率就越低下。
生产力依赖于我们工作环境中的每件小事。我们的工作环境应该尽可能减少这种令人分心的事。
速度快、功能多的机器会物有所值 这就是够买好的硬件至关重要的原因。我们现在付出的金钱成本，会在每一天以生产力的形式偿还给我们。
加大“地产”的投资 更大的台面，意味着不太可能不小心把生的原料放在熟的上面，把面粉袋掉到地上，或是因为到处找盐而把鸡蛋煎过头了。
在编程方面，屏幕上“地产”的价值也是这样。要是只有一个显示器，我们就得做出妥协。由于没有足够的地方来把开发环境、浏览器和通信工具客户端同时“摊在台面上”，我们每天不得不在不同状态之间切换一千次。
下次找工作时，若想知道该工作好不好，可以迅速扫一眼办公室，就知道管理层是不是关注开发团队——是不是真正关心开发人员的工作环境。数数房间里面的显示器，然后除以员工人数。得出的值就是“关注系数”。（1不关注，1-2不包括2 有一定程度的关注 2-3非常关注 大于3 你进入短线操作者办公室了，马上走人吧）
列一张个人待办事项清单
和其他文档不同，待办事项清单是随时可以调整的，从来都不是一成不变的。待办事项可以每天添加、勾掉、推迟、提前或是删掉。待办事项清单与项目时间表和甘特图不同，它不关心过去，它的起始点永远是现在。它列的也不是猜测的任务，而全是井井有条的、真实的、必须在近期完成的任务。
程序员的个人待办事项清单应当具有下列特质：
它是一张清单，且只有一张清单。
它有四个栏目，即今天、明天、后天和未来。
它没有嵌套的依赖关系。每个待办事项都直接属于上述一个栏目。
容易修改。可以很容易地把事项挪上挪下。
由若干个短任务构成，在几个小时之内就可以完成。未来一栏中的项目可以更宽泛一点。
在线。不管在哪工作都能看到。
在添加待办事项时，把它们放在合适的分隔符下。如果你也不知道具体要什么时候完成，但是知道很快会有一个任务来，就把它放在未来下面。因为待办事项清单中没有什么是定死的，所以如果你不确定应该归在明天还是后天，那就选明天。如果到明天结束，它还没有成为最紧急的事情，那就可以再推一天。
每天都要看一眼越来越长的未来清单。如果你需要在未来两天内完成其中一项，把这个任务拆分成小块，然后把它们安排好。
有些待办事项一直在今天一栏中晃悠，或是经常被推迟到明天。这些“坏蛋”待办事项可能并没有我们最初添加时所想的那么重要。如果一个待办事项已经晃悠了一两个礼拜，就直接删掉好了。避免不重要的工作和完成重要的工作一样富有成效。
