关于把bug控制到零还有另一件重要的事，那就是你可以对竞争响应更快。一些程序员认为这点能让产品在任何时候为发售准备好。如果你的竞争对手从你的客户那里引入了一个杀手级的新功能，你就能在发售之前只实现这个功能，而不必去修复大量累计下来的bug。

这条测试把我们带到了日程安排上来。如果你的代码对生意是很重要的，会有很多知道代码完成日期怎么对生意很重要的原因。程序员在制定日程安排上是出了名的倔。“该完成的时候就完成了！”他们会这样对商务人士尖叫。

不幸的是，这并没有让一切变得更好。在发售代码之前，公司需要做太多的计划好的决定：软件演示，展会，广告等。而要做到这一点的唯一方法就是拥有一个日程安排，并保证其为最新版本。

关于要有一个日程安排的另一个至关重要的原因是，它能强迫你决定要做哪些功能，然后迫使你挑选出最无关紧要的功能并砍掉它们，而不是陷入长期的犹豫中去。

同时，跟随日程安排做事并不一定要很苛刻。

书写规范就像牙线，每个人都同意这是一个很好的事情，但却没人做。

我不知道这是为什么，但很可能是因为大多数程序员讨厌写文档。结果，对一个大部分有程序员组成的团队遇到了一个难题的时候，他们更倾向于用代码来表达他们的解决办法，而不是用文档。他们宁愿埋头写代码而不是先写一份规范。

在 设计阶段，当你发现问题时，你可以很容易地通过编辑几行文本就修复它。一旦开始写代码，修复问题的代价就大大地提高了，无论在感情上（人们讨厌扔掉代码） 还是在时间上，所以这时候修复问题是有阻力的。不是从规范开始建立起来的软件通常会很糟糕地结束设计，并且日程安排会不受控。这个在Netscape好像 已经成为大问题了，Netscape的前四个版本慢慢变得一团糟，然后管理层愚蠢地决定抛弃旧代码再重新开始。然后他们又在Mozilla上再一次犯了这 个错误，创建了一个失控的怪物，并且浪费了好几年时间才又回到初始阶段。

我的一贯主张是，这问题可以通过把程序员送去学习写作的集中课程，把他们变为差不多的写手来解决。另一个方案是雇佣一些聪明的程序管理人员，让他们来写代码规范。在这两种情况下，你应该执行简单的规则“无规范不出代码”。

广泛的记录表明，通过给知识型员工提供空间、安静和隐私就能提高生产力。经典的软件管理书《人件》就广泛地记录了生产力受益于这些方面。

问 题来了。我们都知道知识型员工随着“灵感流动”工作最好，就是我们所说的“进入状态”，在哪里他们会全身心专注于他们的工作，并且完全脱离了周围的环境。 通过绝对的专注，他们忘记了时间，产生出伟大的代码。这是他们把工作完成的过程。作家、程序员、科学家，甚至篮球运动员都会告诉你要进入状态。

问题是，进入状态并不那么容易。当你尝试去考量它的时候，在最大生产力下好像需要15分钟才能开始工作。有时，如果你累了或那天已做了很多创造性工作时，你就是进入不了状态，你会把这天剩下的时间都用来摆弄点什么，看看网页，或玩玩俄罗斯方块。

另 一个问题是，很容易脱离那个状态。噪声，来电话，出去吃午饭，不得不开5分钟车去星巴克喝咖啡，还有被同事打扰–尤其是被同事打扰–都会把你从那个状 态里拉出来。如果同事问你问题，导致了一分钟的中断，但这个会很悲惨地把你从状态里脱离出来，你的话费半个小时才能再次变的高效起来，你的整体生产力会遇 到很大的麻烦。如果你在一个含咖啡因的网络公司喜欢创造的嘈杂的牛棚一样的环境里，有营销人员在程序员身边尖叫着打电话，你的工作效率会大幅下跌，因为知 识型工作者一次又一次的被打断，一直都进入不了状态。

对 程序员来说，这就更难了。工作效率依赖于能够同时在短期记忆中兼顾很多小细节。任何类型的打断都会导致这些细节轰然倒下。当你重新开始工作，你已经记不起 任何细节（比如你刚才还在使用的本地变量名字，或你刚想出来的实施搜索算法的好点子）了，你不得不一直回想这些事情，这会让你变得很慢，直到你重新变得高 效起来。

这 有一个简单的代数运算。可以这么说（有证据暗示）如果我们打断了一个程序员，即使只有一分钟，我们真的会失去15分钟的工作效率。在这个例子里，我们假设 有两个程序员，Jeff和Mutt，在一个标准的相邻开放的格子间里。Mutt记不起strcpy函数的Unicode版本的名字。他可以查一查，这需要 30秒，或者他可以问问Jeff，这需要15秒。因为他就坐在Jeff旁边，所以他选择直接问Jeff。Jeff被分心了，失去了15分钟的工作效率（仅 仅节省了Mutt的15秒）。

现 在我们把他们两个分到有门和墙隔开的两个办公室去。这时如果Mutt忘记那个函数名，他可以花30秒去查一查，或者花45秒去问问Jeff，这过程包括了 站立起来（考虑到程序员的平均体能这并不是一项简单的任务！）。所以他会选择自己查一查。这样Mutt失去了30秒的工作效率，但同时为Jeff节省了 15分钟。哈哈哈哈！

在 公园里使用家用电脑立即用一门编译语言写代码仍然是最不能做的事情之一。如果你的编译过程超过几秒钟，使用最新和性能最强的电脑会让你节省点时间，当编译 器运行的时候，程序员会感到厌倦，这是他们会切换到阅读点别的书籍，这会吸引他们的注意力，失去好几个小时的工作效率。

使用单个显示器调试GUI代码是很痛苦的，这也不是不可能。如果你在写GUI代码，两台显示器会让很多事情变得更加容易。

大多数程序员最终要处理图标或工具栏的位图，但他们大多数都没有一个好用的位图编辑器。尝试用Microsoft Paint来处理位图是个笑话，但这就是大部分程序员们所要做的。

在 我上一份工作中，系统管理员一直给我发自动的垃圾邮件抱怨，说我用了超过220兆字节的服务器上的硬盘存贮空间。我指出，鉴于最近硬盘的价格，这些硬盘空 间的成本比我使用的卫生纸的成本都低多了。甚至花费我10分钟来清理我的邮件目录，这真是对我工作效率的极为荒诞的浪费。

顶尖的开发团队不会折磨他们的程序员。即使是因为功能不完善的工具引起的小挫折累加起来，也会使程序员脾气暴躁和不愉快。一个脾气暴躁的程序员是不会有工作效率的。

程序员最容易接受最酷、最新的东西贿赂了。与支付有竞争力的薪水比起来，这是一种让他们为你工作更便宜的方式。

如 果你的团队没有专门的测试人员，至少应该为两三个程序员就配一个测试人员，你会写出有很多bug的产品，或者你在花冤枉钱让测试人员30刀每小时就能做的 工作交给100刀每小时的程序员来做。在测试人员身上节省下来的钱是一个离谱的虚假的经济，我只是想让更多的人认识到这一点。

你会雇佣一个没看过他魔术技巧的魔术师么？当然不会。

你会雇佣一个没尝过他的食物的餐饮服务商来为你的婚礼服务么？我对此表示怀疑。

然 而，一天天的，程序员通过让人印象深刻的简历被雇用，或是因为面试者喜欢跟他们聊天。或者他们被问到很细的问题（“CreateDialog（）和 DialogBox（）之间有啥不同？”），这些看文档就能回答了。你不关心他们是否记得关于编程的成千上万的细节，你只关心他们到底能不能写出代码。或 者，更糟糕的是，他们被问到的都是“啊？”问题：就是那种你知道答案就看起来很简单，但如果不知道答案就什么也回答不上来的问题。

拜托，以后不要这么干了。在面试期间你想怎么问就怎么问，但一定要让参加招聘的程序员写点代码。