image

当人们从事体力劳动时,很容易判断他们的努力程度。你可以看到肢体运动和汗水。并且可以看到他们的劳动成果:高楼拔地,稻谷归仓...。承认和褒奖辛勤的劳作是人的一种本能,是体力运动迷人的一个原因。然而当管理创造性技术员工时,褒扬辛勤劳作的本能就有问题了。高效的员工有时候看起来并没有非常努力的工作。

时光回到2004年,那时我在一家有线电视公司的收费和服务开通系统项目部做初级工程师。这个系统很大,像所有大系统一样,它由一些小的独立的组件构成,每个组件由一些人或小的团队开发。模拟和数字开通系统是几乎毫无关联的系统,由不同的团队分别开发。

模拟电视组计划基于Microsoft Biztalk的一个早期版本开发他们的系统。由我们四名员工和一个微软的团队来开发这个系统和进行生产运行。他们看起来都工作的很辛苦。经常听说他们在晚上和周末加班。一旦出现任何运行故障,每个人都必须放下手头的工作,围在一个人的桌子前,讨论并提出解决意见。正如我们看到的,他们的队伍凝成了一条绳,并且每个成员都非常的努力。

而数字电视组的风貌则截然不同了。初期所有的代码几乎都是一个叫做Dave的家伙写的,我作为初级程序员主要负责一些维护工作。最初我对这些代码很费解,明明一个函数可以搞定的事情,却用好多只有几行代码的类来实现,一些同事也抱怨Dave把事情搞复杂了。但Dave建议我读一些面向对象的书籍,并给我讲解设计模式、SOLID原则、单元测试。于是这些代码在我脑中生动起来,深入看过这些代码之后,不得不赞叹其设计的优雅:改变一些代码非常简单,实现新功能根本没什么难的,有单元测试意味着甚少有BUG。

结果是我们看起来工作的很随意。每天下午五点半回家,周末从不加班,从来不会挤在一个人的桌子边胡乱猜测系统的哪个部分出问题了。外人肯定以为我们接到的工作要比模拟电视团队的轻松许多。事实上是,需求差不多,我们只是有更好的设计和单元测试等的基础支撑。

加薪时,公司宣布以表现作为评定的标准。轮到我和老板对话时,老板讲到给那些辛勤工作的人加更多的薪水是很公平的,我们的团队并不以公司事情为己任,比不上那些牺牲了自己晚上和周末时间的英雄们。

公司应该做个实验,观察对比良好设计和团队表现这两个因素的效果。大部分组织是不会做这个对比的。很难判断一个挥洒汗水、废寝忘食、日夜待命的人是否有胜任复杂系统开发的能力。也很难说朝九晚五,上班淘宝的家伙是高质量代码的编程好手,还是仅仅分配到简单的任务?但常人看到的只是第一种人努力工作,而第二种没有。勤快是好的,懒惰就是坏的吗?

我必须说困苦工作是失败的前兆。软件开发在压力、中断的环境中不会进行的很好。工作很长时间不是个好主意。有时解决一个难题的方法是停止想它,出去溜一圈,甚至睡一大觉让潜意识去解决掉它。我最喜欢的一本书是20世纪著名的数学家哈代写的《一个数学家的辩白》。书中提到哈代自己的作息是这样的:早上四个小时的工作然后下午看板球。他提到超过四个小时的连续脑力工作是徒劳和无意义的。

我想对管理者说,要以结果以可以工作的软件来衡量人,而不是以人工作时的辛苦程度。你应该衡量员工的产出,而不是坐在他们旁边观察他们不自在的操作着IDE,抑或是围在一块儿相互“帮助”。

由Towriting.com翻译自:Code rant: Are Your Programmers Working Hard, Or Are They Lazy?