你的程序员是在努力工做仍是在偷懒？

　Mike Hadlow 是一位资深软件开发者，同时也是 EasyNetQ 与 Suteki Shop 的做者，喜好历史与科技，是一个技术极客。近日，Mike 就程序员工做效率、工做表现以及工做成果等主题撰写了一篇博客，谈到了咱们该如何看待程序员究竟是在努力工做仍是在偷懒这个问题。

　　若是人们从事的是体力劳动，那么咱们就很容易可以看出他们工做的努力程度。你会直观、清楚地看到他们频繁移动的步伐，流下的汗珠。还会看到他们 工做的成果：逐渐升起的砖墙，地上的洞变得愈来愈深，等等。观察到并奖励努力工做的人是人类的一种很基本的天性，这也是咱们以为忍耐力运动使人着迷的缘由 之一。不过对于管理技术创造性的员工来讲，这种对努力的体力劳动自然的欣赏之情就会出现问题。高效的知识工做者经常看起来并非那么努力工做。

　　回到 2004 年，那时我仍是一名初级开发者，工做在一个大型团队中，主要从事有线电视公司的帐单与供应系统。就像全部的大型系统同样，这个系统由大量相对比较独立的组 件构成，不一样的小组负责不一样的组件开发工做。模拟电视与数字电视供应系统几乎是彻底分开的，由两个不一样的小组分别进行开发。

　　模拟电视团队决定根据 Microsoft Biztalk 的一个早期版原本构建他们的系统。团队有 4 我的以及一个来自于微软的团队共同开发并运行这个系统。他们看起来工做很是努力，经常工做到深夜，周末也在加班加点。当遇到生产问题时，团队的每一个人都会 放下手头的工做，围拢在一块儿，提供各类建议和意见，以及如何修复问题的看法。你会看到，这个团队中的每一个人都有很强的团队凝聚力，并且他们工做都很是努 力。

　　数字电视供应系统则截然不同。系统的代码几乎是由一个家伙搞定的，咱们暂且称这个家伙为 Dave 吧。我是团队的一名初级维护工程师。一开始，我在理解代码时遇到了不少麻烦。程序中并无长长的过程语句，相反有大量的小体积类和方法，每一个方法的代码也 只有寥寥数行而已。我有几个同事抱怨 Dave 将事情搞得过于复杂了。不过 Dave 却建议我应该阅读几本关于面向对象编程的图书。他教会了我设计模式、SOLID 原则以及单元测试等知识。很快，他所编写的代码开始变得具备现实意义了，随着我不断加深对代码的理解，我也愈来愈发现它优雅的设计。代码在产品中没有出现 问题，只是一直在默默地工做。要想对代码作出修改也是垂手可得的事情，所以实现新的特性简直是手到擒来。单元测试意味着进入到生产系统中的 Bug 数量变得微乎其微。

　　结果就是咱们这个团队看起来工做不那么努力。我天天下午5:30 下班，周末也历来不用工做，咱们也没必要围聚在一块儿猜想究竟是什么缘由致使了生产系统的问题。从外人的角度来看，咱们所从事的工做确定要比模拟电视团队的简 单得多。事实上，两者的需求很是相像，只是咱们开发出了设计更好的软件、提供了更好的支持基础设施，特别是单元测试。

　　管理团队宣布要根据绩效给予员工奖励。轮到老板与我谈话时，他说公平的作法是对那些努力工做的员工给予奖励，工做越努力，奖励力度越大，咱们的团队看起来对公司并不那么在乎，更没法与那些放弃晚间与周末时间的英雄相提并论。

　　这家有线电视公司有一点不同凡响，你能够直接比较好的软件设计与差的软件设计之间的差异，还能够对团队行为进行比较。大多数组织者都并无提供 这一比较。咱们很难说某个员工是否是通宵达旦地工做，甚至周末时间也在工做，频繁充当救火队员的角色，这种作法是否是就是复杂软件系统必需要作的呢。除非 你可让几个互相竞争的团队解决同一问题，不然你永远也无法直接比较他们工做上的差异。相反，对于那个坐在角落里，朝九晚五工做的家伙有可能花了不少时间 在上网呢？也许他很是善于编写稳定、可靠的代码，也许他的工做要比其余人的简单。对于偶尔过来检查的管理者来讲，他们会以为第一种人工做很努力，第二种人 则不是这样。努力工做就很好，偷懒就很很差，真的是这样么？

　　个人见解是表面上的努力工做经常是失败的信号。高压力、频繁中断的环境经常没法开发出好的软件。长时间的工做也不是一种正确的作法。有时，解决 难题最好的方式多是再也不思考这个问题，出去走走，或是睡个好觉，让你的潜意识来解决问题。我最喜欢的一本书是G. H. Hardy 所编写的 A Mathematician’s Apology，他是 20 世纪英国的一位杰出数学家。这本书描绘了他天天的工做：上午工做 4 个小时，下午观看板球比赛。他说对于复杂的脑力工做来讲，一天工做 4 个小时以上是彻底没有意义且生产力低下的方式。

　　我想对管理者说的是，以结果为导向，根据员工工做的成果，根据可运行的软件为导向，不要被人们表面上的努力工做所蒙蔽。另外，最好不要与你的开 发者坐在一块儿，你会获得更好的结果，不受传统、直觉判断所影响的好结果。远程工做的好处是很是多的，你只能以输出来衡量员工的工做状况，而不是看他们是不 是天天端坐 8 小时盯着 IDE 在看为标准，或是汇集在一块儿提出本身的看法为衡量的准则。

　　有读者评论说，文章写的很实在，有时真的很难说服同事设计的简单性与恰当使用 OO 原则所带来的好处。我就看到有的人以编写复杂代码并工做到深夜为傲。

　　还有读者说，我曾经与一个家伙共事过，他说“第一次就将事情作对的困难之处在于没有人认识到事情会有多么复杂”。几年过去了，我发现这句话很是正确。我如今都会在项目开始前进行大量的提早设计。这经常会让执行变得很是平滑，不过可能会让其余人以为这件事挺简单的。

来自: InfoQ