程序员讨厌没有价值的任务

寻找其工作的价值
这些年来，我看到很多颇有成绩的软件开发人员转行去了管理岗位，或者其他完全不同的职业。有的时候原因很简单，只是想拿更高的薪水。不过也有因为是厌倦了总是需要不断学习以跟上软件开发步伐这样一种疲于奔命的状态。当然最常见的原因是感到无聊了，或者是对工作本身失去了兴趣。这些人通常是因为工作对于他们而言已经没有了足够的挑战，认为他们是在将自己的时间和精力投入到几乎没有价值的工作中。

我的软件开发职业生涯也有低谷的时候：我花费了大量时间、精力和创造力的一个项目或者任务由于某些原因被终止或者被大大削减了其功能范围。虽然我拿到的货币报酬相同，但是我工作之前的期望是交付一个成功的产品，于是，我的感受不是满意而是非常沮丧。这让我感觉我付出的时间和精力没有了价值。
取消任务并非幻灭工作价值的唯一原因。一些没有必要的任务或其他繁重的工作也会加剧软件开发的难度。这些事情总是看上去好像很有用或者对任务很有帮助的样子，却几乎没有价值。

进程
从众多软件开发人员的角度看的话，软件开发生产力最大的敌人就是冗余的进程。在《Process Kills Developer Passion》一书中，James Turner这样写道，“对整个开发进程最佳实践的盲目应用让我们从一种创造性的流程变成了一种禁锢。”Turner表示所有的开发人员能力并不相同，所以对待他们的方式也不能完全相同。“企业需要明白一点，开发人员之间有着本质的区别，所以你得确保设置给每个人的权重，至少不能有损整体的士气和团队的效率。”
我想大多数淫浸这行多年的人都明白，一定程度的进程才是合理的，甚至是有益的。但是这个“程度”取决于项目、开发人员的经验以及团队的大小。标准化和代码约定是有很多优点的。单元测试和其他质量进程的益处更是众所周知了。可以这么说，最好的开发人员能够确定什么样的进程适合怎么样的情况，以及怎么样的情况是不适合的。 

开会
只有那些时间短、运行良好的会议才能为我们提供巨大的收益，大多数的会议都只是在浪费时间，特别是如果会议还要晚点和加时的话。好的会议，应该准时开始，只需要解决那些必须解决的问题即可。例如有的团队成员不习惯于发表自己的意见，那么一些用于交流工作的简短、非正式的会议就很有必要。而一些难度很高的设计决策和架构权衡也可以放在会议上讨论。可以这么说，运行良好的会议，产生的是积极的效果：能帮助开发人员确立更加明确的方向，提高团队的整体效率。
我以前也发过一个关于如何有效开会的帖子。要点是应该学会记笔记，记下什么时间有哪些人的参与，记录下重大的决策以供将来参考，也可以作为材料借阅给那些没有到会的人看。 

不是每一个想法都应该实施
不是每一个想法都有价值。开发人员在被迫去实施一些糟糕或者没用的点子时，往往会产生不耐烦的情绪。话说，我们很难让自己心甘情愿地去制作一些可能永远不会被使用的东西，或者更糟糕的是，直接影响用户体验。 

繁琐的脚本编写任务
很多开发人员往往会另寻方法去解决特别繁琐的脚本编写任务，而不是手动执行，即使用于手动执行的时间和编写的时间相差无几。这也是可以证明大多数开发人员讨厌繁琐任务的最好例子之一。对于开发人员的这种典型做法其实是有积极面的。首先，可能这个我们以为是一次性的任务又有了需要再次实施的情形。其次，编写脚本的行为比仅仅只是完成一个任务所产生的价值要高得多：既可以提高脚本语言的熟悉度，又能为以后解决相关问题提供很好的思路或案例。 

使用常规配置
只有当配置信息和常规配置不同时，开发者才需要提供详细地配置信息，否则只需要使用常规配置即可。这样可以节省开发者的时间，减少许多枯燥的配置工作。 

开始看上去没价值其实不然
大多数的情况下，我们对于任务有无价值的判断一般是正确的。但也有的任务，一开始看上去是无用的，但是后来则发现它确实能提供实实在在的利益，的确是有价值的。这种情况也提醒我们需要对新点子的价值保持开放的心态，不要一棍子打死，应该仔细分析它的影响。所以软件开发经理要做的就是将有价值的任务分配给开发人员并确保他们能理解这些任务的价值。 

执行力
即便是一种非常有潜在价值的想法如果没有正确的实施，也会大大减少它的价值。同样的，如果能正确使用代码审查和代码质量工具则能创造巨大的价值，反之就是负面的影响。 

结论
当我们喜欢我们所做的工作的时候，当我们认为我们所做的有价值的时候，我们往往能将工作完成得很完美。而毫无价值或者低价值的任务则更容易被认为是冗余的任务从而不能很好地完成。总而言之，如果开发人员毋须被强迫于毫无价值的任务，那么显而易见的他们将更有动力更有开发的激情，也更开心。