努力工作OR懒惰，你是1个什么样的程序员 当1个人在完成一件体力工作时，你很容易评估他是否在努力的工作。你能够观察他的物理动作，看他流了多少汗水。你还能够看到他工作的达成目标：砖墙在砌高，地面上挖的坑在变大。对努力工作的认可和褒奖是人性中非常基本的本能反应。这也正是为什么人们对体力耐力体育活动如此着迷的原因之中的1个。这种对体力上的辛苦工作的本能的赏识，在遇到管理一群科技创造型的员工时，却成了1个麻烦疑问和未知办法。高效的脑力工作者通常会被看作并没有在努力的工作。
早在2004年，我也是1个初级程序员，工作在一家有线电视公司，在1个大型团队中开发财务和供销体系。跟所有的大型体系一样，这个体系由很多的相对独立的模块组成，分别由一些个人或小团队肩付的责任。之中模拟电视和数字电视的财务和供销体系几乎全部独立，分别由两个团队开发。
模拟电视开发组决定在早期的微软Biztalk平台上开发他们的体系。由这个公司的4个小伙和微软的1个团队一起开发，并肩付的责任产品环境的运行。他们看起来真的工作的十分辛苦和努力。你经常能看到他们加班到深夜或周末加班。每个人都会随时放下手中的活儿来解决正式环境中突现的疑问和未知办法，经常会在一张桌子前一群人围绕着1个小伙，各自说出自己的见解，讨论什么地方错了，应该如何修正。工作气氛永远是热火朝天，每个人都能看到这些——即使只是经过瞟一眼，不仅仅从整个团队讲，而是他们每个人都真的真的工作的很努力。
数字电视供销体系开发团队却是全部的不同。代码几乎是由1个家伙写的，我们就叫他大卫吧。我是1个初级程序员，在团队里做维护工作。起初我在理解他的代码时遇到了很大的麻烦。他的代码里没有很长的过程，通常我的代码会把很多操作放到一起，相反，他的代码里有更多的很小的类文件和只有几行代码的小方法。好几个同事都抱怨大卫把代码搞的过度复杂了。但大卫耐心教导我，建议我去读几本面向对象编程的书籍。他给我讲设计模式，SOLID编程原则，单元测试等知识。很快，我对他的代码开始有了理解，我越研究他的代码，越欣赏这些程序中优雅的设计。这些代码放到产品环境中非常好用，运行稳定的干着它们的工作。这些代码修改起来也相当简单，因此，一些新性能的增多变得轻松容易。单元测试保证了大部分的bug都阻挡到了正式环境之外。
这些做法产生的结果就是，我们看起来全部不是在十分努力的工作。我们5点半准时下班，周末从来没有加过班，我们从来没有发生过一大群人围绕着1个人数小时的讨论正式环境中的错误是怎么发生的场景。在外人看来，我们肯定是被分配了一件相对容易的任务。但事实上，需要都是十分相似的，我们只是更好的设计和实现了这个体系，有更好的支持体系基础架构，特地是单元测试。
管理部门宣称他们要根据员工的工作表现涨薪。当轮到老板跟我谈话时，老板说只给那些工作真的努力的员工涨工资才显的公平。而我们的团队看起来对公司发展的好坏并不太在意——跟那些放弃了自己的晚上和周末的英雄们相比。
这家公司是1个稀有的实验室，你能够将好的软件设计和坏的软件设计、好的团队特征和不好的团队特征的影响效果做1个快速的按原来的方式的对比观察。大多数的公司里不可能给予这种比较的机会。你很难说这些挥汗如雨、工作到深夜和周末、坚持冲在灭火第一线的小伙们是为了开发1个真的非常非常复杂的体系而展示了伟大的付出，也是就是一次失败。除非你有能力给予两个团队来竞争，让他们解决同样的疑问和未知办法，可是哪个公司愿意做这样的事情呢。相反，如何看待那些坐在角落里，朝九晚五，看着像是整天上网读什么东西的程序员呢？是他们善于写出强健稳定的代码吗？也是分配的活儿比其他人容易？在常人的眼里，前1个团队的小伙们是在努力的工作，而第二个不是。努力工作值得赞扬，懒惰可耻，不是吗？
我敢断言，表面上看起来工作很努力通常会是一种失败的信号。在高压下，在1个不断被打搅的环境中，软件开发通常是不能干好的。长时间的工作往往不是1个好的方式。有时解决1个难题的最好的方法是停止思考，出去散散步，或更好的，去睡1个好觉，让潜意识帮你解决。我最喜欢的一本书就是20世纪英国数学界领军人物G. H. Hardy先生写的《A Mathematician’s Apology》。在这本书里，Hardy先生描述他的日常规律：上午4小时的工作，下午看板球比赛。他说一天超出四小时的高强度脑力劳动都是无意义的，还可以是无效率的。
对这个那些管理者们，我想说的是，判断1个人要看结果，要看开发出的软件的好用和否，而不是看他们表现的是如何在努力的工作。很反直觉吧，你其实最好不要坐在这些程序员中间，这样能保证你不受传统的、本能上的评判指标的影响，这样你才能对他们的产出有更好的认识。远程工作是特地有效的一种做法，你只能通常他们的产出来评判他们，而不是省事的观察他们是否8小时都坐在办公桌前对着IDE噼里啪啦的敲着键盘或“热心的”围聚在另外1个人的桌前给予着“有效的”建议。
