当一个人在完成一件体力工作时，你很容易评估他是否在努力的工作。你可以观察他的物理动作，看他流了多少汗水。你还可以看到他工作的成功：砖墙在砌高，地面上挖的坑在变大。对努力工作的认可和褒奖是人性中非常基本的本能反应。这也正是为什么人们对体力耐力体育活动如此着迷的原因之一。这种对体力上的辛苦工作的本能的赏识，在遇到管理一群技术创造型的员工时，却成了一个麻烦问题。高效的脑力工作者通常会被看作并没有在努力的工作。

早在2004年，我还是一个初级程序员，工作在一家有线电视公司，在一个大型团队中开发财务和供销系统。跟所有的大型系统一样，这个系统由很多的相对独立的模块组成，分别由一些个人或小团队负责。其中模拟电视和数字电视的财务和供销系统几乎完全独立，分别由两个团队开发。

模拟电视开发组决定在早期的微软Biztalk平台上开发他们的系统。由这个公司的4个小伙和微软的一个团队共同开发，并负责产品环境的运行。他们看起来真的工作的十分辛苦和努力。你经常能看到他们加班到深夜或周末加班。每个人都会随时放下手中的活儿来解决正式环境中突现的问题，经常会在一张桌子前一群人围绕着一个小伙，各自说出自己的见解，讨论什么地方错了，应该如何修正。工作气氛永远是热火朝天，每个人都能看到这些——即使只是经过瞟一眼，不仅仅从整个团队讲，而是他们每个人都真的真的工作的很努力。

数字电视供销系统开发团队却是完全的不同。代码几乎是由一个家伙写的，我们就叫他大卫吧。我是一个初级程序员，在团队里做维护工作。起初我在理解他的代码时遇到了很大的麻烦。他的代码里没有很长的过程，通常我的代码会把很多操作放到一起，相反，他的代码里有大量的很小的类文件和只有几行代码的小方法。好几个同事都抱怨大卫把代码搞的过度复杂了。但大卫耐心教导我，建议我去读几本面向对象编程的书籍。他给我讲设计模式，SOLID编程原则，单元测试等知识。很快，我对他的代码开始有了理解，我越研究他的代码，越欣赏这些程序中优雅的设计。这些代码放到产品环境中非常好用，运行稳定的干着它们的工作。这些代码修改起来也相当简单，因此，一些新功能的增加变得轻松容易。单元测试保证了大部分的bug都阻挡到了正式环境之外。

这些做法产生的结果就是，我们看起来完全不是在十分努力的工作。我们5点半准时下班，周末从来没有加过班，我们从来没有发生过一大群人围绕着一个人数小时的讨论正式环境中的错误是怎么发生的场景。在外人看来，我们肯定是被分配了一件相对容易的任务。但事实上，需求都是十分相似的，我们只是更好的设计和实现了这个系统，有更好的支持系统基础架构，特别是单元测试。

管理部门宣称他们要根据员工的工作表现涨薪。当轮到老板跟我谈话时，老板说只给那些工作真的努力的员工涨工资才显的公平。而我们的团队看起来对公司发展的好坏并不太在意——跟那些放弃了自己的晚上和周末的英雄们相比。

这家公司是一个稀有的实验室，你可以将好的软件设计和坏的软件设计、好的团队特征和不好的团队特征的影响效果做一个直接的对比观察。大多数的公司里不可能提供这种比较的机会。你很难说这些挥汗如雨、工作到深夜和周末、坚持冲在灭火第一线的小伙们是为了开发一个真的非常非常复杂的系统而展示了伟大的付出，还是就是一次失败。除非你有能力提供两个团队来竞争，让他们解决同样的问题，可是哪个公司愿意做这样的事情呢。相反，如何看待那些坐在角落里，朝九晚五，看着像是整天上网读什么东西的程序员呢？是他们善于写出强健稳定的代码吗？还是分配的活儿比其他人容易？在常人的眼里，前一个团队的小伙们是在努力的工作，而第二个不是。努力工作值得赞扬，懒惰可耻，不是吗？

我敢断言，表面上看起来工作很努力通常会是一种失败的信号。在高压下，在一个不断被打搅的环境中，软件开发通常是不能干好的。长时间的工作往往不是一个好的方式。有时解决一个难题的最好的方法是停止思考，出去散散步，或更好的，去睡一个好觉，让潜意识帮你解决。我最喜欢的一本书就是20世纪英国数学界领军人物G. H. Hardy先生写的《A Mathematician’s Apology》。在这本书里，Hardy先生描述他的日常规律：上午4小时的工作，下午看板球比赛。他说一天超过四小时的高强度脑力劳动都是无意义的，也是无效率的。

对于那些管理者们，我想说的是，判断一个人要看结果，要看开发出的软件的好用与否，而不是看他们表现的是如何在努力的工作。很反直觉吧，你其实最好不要坐在这些程序员中间，这样能保证你不受传统的、本能上的评判指标的影响，这样你才能对他们的产出有更好的认识。远程工作是特别有效的一种做法，你只能通常他们的产出来评判他们，而不是省事的观察他们是否8小时都坐在办公桌前对着IDE噼里啪啦的敲着键盘或“热心的”围聚在另外一个人的桌前提供着“有效的”建议。