这条测试把我们带到了日程安排上来。如果你的代码对生意是很重要的，会有很多知道代码完成日期怎么对生意很重要的原因。程序员在制定日程安排上是出了名的倔。“该完成的时候就完成了！”他们会这样对商务人士尖叫。
不幸的是，这并没有让一切变得更好。在发售代码之前，公司需要做太多的计划好的决定：软件演示，展会，广告等。而要做到这一点的唯一方法就是拥有一个日程安排，并保证其为最新版本。
关于要有一个日程安排的另一个至关重要的原因是，它能强迫你决定要做哪些功能，然后迫使你挑选出最无关紧要的功能并砍掉它们，而不是陷入长期的犹豫中去。
同时，跟随日程安排做事并不一定要很苛刻。
你写代码有规范么？书写规范就像牙线，每个人都同意这是一个很好的事情，但却没人做。
我不知道这是为什么，但很可能是因��大多数程序员讨厌写文档。结果，对一个大部分有程序员组成的团队遇到了一个难题的时候，他们更倾向于用代码来表达他们的解决办法，而不是用文档。他们宁愿埋头写代码而不是先写一份规范。
在 设计阶段，当你发现问题时，你可以很容易地通过编辑几行文本就修复它。一旦开始写代码，修复问题的代价就大大地提高了，无论在感情上（人们讨厌扔掉代码） 还是在时间上，所以这时候修复问题是有阻力的。不是从规范开始建立起来的软件通常会很糟糕地结束设计，并且日程安排会不受控。这个在Netscape好像 已经成为大问题了，Netscape的前四个版本慢慢变得一团糟，然后管理层愚蠢地决定抛弃旧代码再重新开始。然后他们又在Mozilla上再一次犯了这 个错误，创建了一个失控的怪物，并且浪费了好几年时间才又回到初始阶段。
我的一贯主张是，这问题可以通过把程序员送去学习写作的集中课程，把他们变为差不多的写手来解决。另一个方案是雇佣一些聪明的程序管理人员，让他们来写代码规范。在这两种情况下，你应该执行简单的规则“无规范不出代码”。
程序员有安静的工作环境么？广泛的记录表明，通过给知识型员工提供空间、安静和隐私就能提高生产力。经典的软件管理书《人件》就广泛地记录了生产力受益于这些方面。
问 题来了。我们都知道知识型员工随着“灵感流动”工作最好，就是我们所说的“进入状态”，在哪里他们会全身心专注于他们的工作，并且完全脱离了周围的环境。 通过绝对的专注，他们忘记了时间，产生出伟大的代码。这是他们把工作完成的过程。作家、程序员、科学家，甚至篮球运动员都会告诉你要进入状态。
问题是，进入状态并不那么容易。当你尝试去考量它的时候，在最大生产力下好像需要15分钟才能开始工作。有时，如果你累了或那天已做了很多创造性工作时，你就是进入不了状态，你会把这天剩下的时间都用来摆弄点什么，看看网页，或玩玩俄罗斯方块。
另 一个问题是，很容易脱离那个状态。噪声，来电话，出去吃午饭，不得不开5分钟车去星巴克喝咖啡，还有被同事打扰–尤其是被同事打扰–都会把你从那个状 态里拉出来。如果同事问你问题，导致了一分钟的中断，但这个会很悲惨地把你从状态里脱离出来，你的话费半个小时才能再次变的高效起来，你的整体生产力会遇 到很大的麻烦。如果你在一个含咖啡因的网络公司喜欢创造的嘈杂的牛棚一样的环境里，有营销人员在程序员身边尖叫着打电话，你的工作效率会大幅下跌，因为知 识型工作者一次又一次的被打断，一直都进入不了状态。
对 程序员来说，这就更难了。工作效率依赖于能够同时在短期记忆中兼顾很多小细节。任何类型的打断都会导致这些细节轰然倒下。当你重新开始工作，你已经记不起 任何细节（比如你刚才还在使用的本地变量名字，或你刚想出来的实施搜索算法的好点子）了，你不得不一直回想这些事情，这会让你变得很慢，直到你重新变得高 效起来。
这 有一个简单的代数运算。可以这么说（有证据暗示）如果我们打断了一个程序员，即使只有一分钟，我们真的会失去15分钟的工作效率。在这个例子里，我们假设 有两个程序员，Jeff和Mutt，在一个标准的相邻开放的格子间里。Mutt记不起strcpy函数的Unicode版本的名字。他可以查一查，这需要 30秒，或者他可以问问Jeff，这需要15秒。因为他就坐在Jeff旁边，所以他选择直接问Jeff。Jeff被分心了，失去了15分钟的工作效率（仅 仅节省了Mutt的15秒）。