关于南极动物公司的 H 总半夜回复邮件，凌晨上线生产环境这个段子，总是有一些人拉出来说事。弄得好像判断他人是否勤奋，只能是通过这个人凌晨三点是否还在工作来识别一样。先不说 H 总当时是不是在国外，有没有时差这个问题。有几个公司真得把开发、测试、上线这个流程跑通了？没跑通，有几个人敢这么冒冒然上线？冒冒然上线了，有几个人敢白天蒙头睡觉？敢白天蒙头睡觉，有几个公司允许不考勤的……扯远了，拉回来。这篇文章是我去年12月初看到的，当时就想翻译，结果一拖就成了跨年度项目了（我得承认，我偷懒了）。当了很多年的程序员，也做了几年技术管理工作，感觉原文作者的经历还是很有代表性的。至少如果现在还天天忙着用代码行数来判断程序员贡献的领导，可能得评估一下公司的技术、开发工具相关选型是不是还在原始社会了。原文在这里，请翻墙阅读。 ————翻译分隔线————

你的程序员在勤奋工作，还是在偷懒？

Mike Hadlow 撰写 当人们进行体力劳动时，很容易判断他们是否在努力工作。你可以看到汗流浃背的劳动过程。还可以看到他们工作的结果：砖墙越来越高；地上的洞越来越大。认可并且嘉奖辛勤的劳动绝对是人类最基本的本能，这也是体育运动如此经久不衰的让人着迷的原因之一。但用这种本能的赞赏来面对技术研发的员工时，就成为了一个问题。高效的知识型劳动者经常让人觉得他没有在努力工作。 2004 年，我作为一个初级程序员在一个大团队里为一家有线电视公司开发支付点播系统。与所有大型系统一样，它由若干相互关联的独立组件构成，分别由不同的人或小团队维护。模拟电视与数字电视的点播系统几乎完全分离，由不同的团队来进行维护。 模拟电视团队决定将他们的系统完全基于微软一个早期版本的 Biztalk 进行构建。有四个我们的人和一个来自微软的团队来开发且对生产环境进行维护。他们的辛勤工作有目共睹。他们经常工作到深夜，甚至周末也在工作。所有人都会认为他们正在解决产品问题：经常聚在一个人的桌子周围，关于什么会出错，以及如何修复，发表着各自的见解。这变成了一种常态行为，每个人都能看到。这种情景下，不仅团队体现了凝聚力，而且让人觉得他们确实非常非常努力地在工作。 数字电视点播团队与此完全不同。代码几乎是由一个人编写完成的，让我们叫他戴夫吧。我当时在团队中是初级维护程序员。最开始的时候，我在理解代码方面遇到了大问题。没有处理所有事务的大过程，取而代之的是许许多多的只有几行的类和方法。我的一些同事抱怨说戴夫让事情过于复杂了。但是戴夫把我护在他的翅膀底下，并且建议我阅读一些关于面向对象编程的书籍。他教了我设计模式、面向对象设计（SOLID）原则以及单元测试。很快那些代码开始有点感觉了，我在其上工作得越多我就越感谢这种优雅的设计。这些在产品中不会出错，只是不停的工作着。对代码进行修改也比较容易，因此实现新的功能通常也很轻松。单元测试使得进入生产环境的 Bug 更少。 这样做的结果是我们看起来都不怎么勤奋工作。我在 5 点半回家，并且周末也从不加班，也不会花费数小时聚在某个人的桌子跟前抛出各自的猜想到底是什么地方不对了导致生产环境出错。在外部看来，我们分配到的任务一定远远比模拟电视的伙计们的任务更加简单。事实上，需求是非常类似的，只是我们的软件有着更好的设计和实现，以及更好的支持构建，尤其是单元测试而已。 这部分的管理者计划基于绩效进行薪酬奖励。当轮到我向老板进行陈述的时候，他解释到只有那些辛勤工作的人加工资才是公平的，并且我们的团队看起来并不怎么关心公司，更别说与那些为之付出每个夜晚和周末的英雄们。 有线电视公司是罕见的实验场，你可以直接观察对比良好的软件设计与糟糕的软件设计产生的效果以及团队的行为。大多数组织无法提供这样的对比。除非提供两个甚至更多的竞争的团队解决类似的问题，否则很难说一个人汗流夹背的工作到午夜和周末、不停的救火就能保证是在进行一个非常非常复杂的系统工作，或者只是在犯错误。不过拜托，谁会这么做啊，所以你永远都不会知道。从另一方面说，一个坐在角落从早上 9 点工作到下午 5 点，并且看起来花费了许多时间在网上冲浪的家伙又如何呢？是他精通编写稳定的、可读的代码，还是他的工作比别人的更简单？对于那些漫不经心的旁观者来说，第一条军规就是努力工作，没有第二条。努力工作好，懒惰懈怠坏，这是真得吗？ 我认为那些看起来困难重重的工作常常是失败的特征。软件开发者通常在有压力、受到干扰的环境下不能很好的工作。持续工作很长时间通常不是个好办法。有时，解决一个难题的最好办法就是不去想它，散散步，甚至更奢侈一些，睡一个好觉，让你的潜意识去解决它。《一个数学家的辩白》（A Mathematician’s Apology）是我最新欢的书之一，作者G·H·哈代（G. H. Hardy）是二十世纪数一数二的英国数学家。他所描述的他的日常事务：在上午进行四小时的工作，然后看一下午的板球。他说一天超过四小时的脑力劳动即无意义又无生产力。 我想对管理者说，用结果、用正在运行的软件来评判，而不要用人们在工作中表现出来的辛劳来评判。与直觉相反，可能不与你的开发者坐在一起会更好，你会从他们的输出中获得不受传统/直觉暗示的更好的看法。远程工作尤其有益；你可以通过产出来衡量雇员的工作，而不是懒惰的选择看他们一天八个小时的坐在他们的办公桌前不停的在 IDE 里敲敲打打，或者“有帮助的”聚集在某个人的桌子前面提供一些“有用”的建议。 ————翻译分隔线———— 作者的经历很有代表性。不过按照我的经验，他说的这些东西，不是亲身经历过研发的人，不是认真思考过的人，阅读后也不会明白这其中的奥妙。不过以目标为导向，以结果为评判的管理思想应该不会那么难于理解吧？ 从另一个角度来看，一天花四个小时来完成工作，然后再花八个小时表现出勤奋工作似乎是一个很好的办公室哲学。 只是，这不是我的哲学！是你的吗？