当人们在进行一项体力工作时，你很容易评估他们工作的努力程度。你可以看到他们的身体动作，看他们流了多少汗水。也可以去看他们的工作成果：砖墙越砌越高，地上的洞越来越大。对努力工作的认可和奖励是人类一个非常基本的本能，这也是为什么我们对耐力运动如此着迷的原因之一。然而，在管理一些技术创造型的员工时，这种对体力上的努力工作的本能欣赏却变成了一个问题。高效率的知识工作者通常看起来并不像是在努力工作。
早在2004年，我还是个工作在一家有线电视公司计费和配置系统的初级开发者。像所有的大型系统一样，它由许多相对独立的部分组成，分别由不同个人或小团队负责。模拟电视配置系统和数字电视配置系统几乎是完全分开的，分别由不同的团队负责。
模拟电视团队已经决定在早期的微软Biztalk平台上开发他们的系统，由我们公司的四个伙伴和微软的一个团队共同开发，并负责在生产环境中运行。他们工作都非常努力，并且经常工作到夜晚，甚至周末加班。每个人都会放下自己正在做的事情去帮助解决产品问题，经常是几个家伙围在一张桌子周围，提出哪里可能 会出现问题以及如何修复这些问题的建议。他们的工作氛围非常活跃，仅凭这一点，任何人都能够看出，不仅是整个团队，而是他们每一个人都真的真的非常努力工作。
数字电视配置系统开发团队却是完全不同的。代码大部分是由一个叫戴夫的家伙编写的。我当时是这个团队的一名初级维护开发者。起初，我在理解代码的过程中遇到了很多麻烦，因为它并不是用一个很长的程序来包含所有的内容，取而代之的是许许多多小的类文件和仅包含几行代码的方法。我的几个同事都抱怨戴夫把代码搞得过于复杂。但戴夫把我招致麾下，并建议我阅读一些面向对象编程方面的书籍。他教给我设计模式，SOLID编程原则以及单元测试。不久，我便开始能够理解这些代码，而且我越研究它就越欣赏它的优雅设计。在生产环境中它周而复始的运行，没有出现任何错误。代码改变起来也相当容易，因此，实现新的特性并不困难。单元测试则意味着要保证生产环境中尽可能少地出现bug。
这样做的结果就是，我们看起来好像根本没有努力工作。我每天下午5：30准时回家，周末从不加班，我们也不会挤在一起去猜测一些失败的生产系统可能会遇到的问题。表面上看起来就像是分配给我们的任务一定是比分配给模拟电视团队的任务容易得多。实际上，两个团队的需求是非常相似的，只是我们拥有一个设计和实现地更好的软件系统，更好的支持基础架构，尤其是单元测试。
管理部门宣布他们将根据个人的工作表现加薪，当轮到我和老板谈话时，他说只有给那些真正努力工作的人加薪才算是公平，而我们的团队看起来似乎并不太关心公司的发展，不能和那些牺牲了自己的休息时间来工作的人员去比较。
这家有线电视公司是一个非常少见的实验室，你能够对好的软件设计和坏的软件设计、好的团队行为和坏的团队行为之间的效果有一个直观的比较。大多数组织并不能够进行这样的比较。你很难判断那些汗如雨下、工作到深夜并在周末加班、一直奋斗在一线的家伙是展示了他们在做一件真正复杂的系统工作时的伟大承诺，还是只是表明了他们的失败。除非你能够负担得起请两个或者更多的竞争团队来解决同样的问题，但是你永远也不会知道哪个公司会愿意这样做。相反地，那些整天朝九晚五、坐在角落里、看似花费很多时间浏览网络的家伙们呢？是只是因为他们非常精通编写稳定可靠的代码还是因为分配给他们的工作比别人的更简单？从常人的眼光来看，第一个家伙是在真正努力工作而第二个没有。努力工作值得表扬，而懒惰却是不好的，不是吗？
我认为努力工作的表象往往意味着失败。在一个高压，中断驱动的环境下，通常是不能够进行高质量的软件开发的。长时间工作通常也并不是一个好主意。有时解决一个困难问题的最好的方式就是停止思考，出去散个步，甚至最好去睡个觉，让你的潜意识去解决它。我最喜欢的书籍之一，是由20世纪一位领军的英国数学家G. H. Hardy撰写的《A Mathematician’s Apology | 一个数学家的辩白》，他在这本书里描述了他的日常生活：每天上午工作四个小时，然后看一整个下午的板球。他说一天中，超过四小时艰难的脑力工作是毫无意义并且徒劳的。
我想要对管理者说的是，应该根据结果及可运行的软件来评判人们的工作，而不是通过他们看起来的努力程度来判断。与直觉相反，你最好不要和开发者们坐在一起，这样你才能够对他们的产出有一个更好的、不受常规或直观指标影响的了解。远程工作非常有好处，你只能根据产出来衡量他们的贡献，而不是简单地看他们是否每天8小时都坐在桌前对着IDE噼里啪啦敲键盘，或者是否“热情地”围在彼此桌前提供“有效的”建议。
