编程是枯燥的，除非……

作为一个开发者，我干同一份工作的时间不会超过两年。

每一份新工作都是一次职业的飞跃，而且在我们这个行业中，高频跳槽本来就很常见。但是我前任，前前任，前前前任，前前前…任雇主对于我的辞职并不开心。有些甚至试图挽留我，但是我已经厌倦了，我真心无法继续留下来了。

（免责声明：我很幸运地生活在程序员供不应求的地方，不过后来我发现换工作并不总是一个很好的选择！）。

我现在是Enki的联合创始人和CTO。我负责工程文化。我的部分工作是要确保我们的开发人员永远不会像我过去那样觉得工作无聊枯燥。

在我的团队的共同努力下，我们制定了防止程序员感到无聊枯燥的策略，并应用到公司里。由于这一策略到目前为止一直运作良好，所以在这里我想和大家一起分享。

在Enki公司，我们可以放肆地冲锋具有挑战性的问题。为很多有趣的事情写代码，解决大量有趣的谜题。因此，“无聊”并不是一个迫切的问题。甚至刚开始的时候，你完全找不到它的踪迹。但是，随着时间的流逝，无聊会像藤蔓一样渐渐爬满大树，然后在最糟糕的时刻击垮你。

这就是为什么我们要建立一种拯救无聊的文化来尽早解决这个问题的原因。

时间太长；学不到东西

开发人员感到无聊枯燥最常见和最明显的原因是，项目的持续时间过长。

我在我第一份工作中就亲身经历了这种体验。我们团队的任务是通过一个便捷API来准备和提供财务数据。一开始因为数据的复杂性和规模，令我非常兴奋。同时我从中也学会了如何高性能地分析数据和API设计。但是一年以后，我们依然工作于完全相同的数据集，用着完全相同的技术。我只是成为了某个特定方面的“专才”，也没有什么可以学习的新内容。

我无法改变团队或项目，因为对于公司而言，这种重复性的枯燥的任务是有意义的。并且由于我熟知数据和技术而无法换到其他岗位。我没有理由只是为了学习新的东西而去更换现有的技术。在我表明了我的枯燥和沮丧之后，因为问题依然没有解决，所以我选择了跳槽。

在我们的团队中，我们尝试着不让任何人从事相同的代码、产品和数据集超过三个月。三个月的时间是我们任意定的，或许对于规模较大的公司而言，显得太短了点。但是我们主张快速转换。

为了做到这一点，我们提出了一个全栈文化。我们每一个开发人员都能够工作于（或者可以很快学会）代码库的任何部分。

另一个预防枯燥的方法是经常性地讨论。我们每个星期都有直接、开放、一对一的讨论。如果开发人员开始觉得过于舒服或已经熟能生巧了，那么就到了转换工作的时候。

维护遗留代码很无聊

当项目处于维护模式，即开发人员90%的时间都花在了修复bug，而不是开发新功能的时候，你可以报告给我们——正式或非正式的方式都可。

有人会说，维护是不可避免的。旧代码需要支持。建造软件就像盖房子。你需要维护的老房子，并时常翻新。是这样的吗？

是的，但又不是。问题的关键是态度。

我曾经有一个导师，他对此抱着一种玩世不恭的心态。他将无为当作理所当然。他总是说，软件开发工作就是这样的；假如生活强奸了你，那就躺着享受吧。

如何避免呢？

维护模式有时是糟糕的技术决策加之缺乏勇气才导致的结果。

大型，整体式的，依赖关系复杂的代码库往往需要额外的维护工作。与此相反的是，架构良好的微服务基础结构就显得较为灵活。当微服务出现故障的时候，你可以更换它。你可以使用不同的语言或技术从头开始重写。这样你就可以学到新的东西，而不是简单地修补旧的代码。如果你的架构还不允许这么做，那么你需要采取步骤来改进它，并在此过程中学习一些开发技能。

微服务策略只是解决“枯燥”维护问题的方法中的一个。还有一个措施是构建智能工具，使维护变得更加高效和乐趣。这方面的一个极端例子就是，Facebook对他们那个庞大的PHP代码库做的事情。他们在熟练掌握PHP的基础上构建了自己的编译器和自己的类型语言（Hack），既方便维护，又提高了开发体验。虽然我怀疑Facebook依然没有完全“解决”遗留问题，但听上去它让工作变得更有趣了。

复制/粘贴很无聊

还有就是编码，编码，还是编码。

在我以前的一些工作中，我写了很多收效甚微的代码。例如，我曾为了数据整合写过Groovy和Python脚本。数据很复杂，有许多不一致的模式，这使得大多数地方无法做到自动化。因此，我不得不写大量的代码，而我的同事因此认为我学到了很多东西。

但其实我并没有学到很多。为什么？

因为50％（没有计算过，纯粹是夸张手法！）的代码是从Stack Overflow直接复制/粘贴来的。还有40％则复制/粘贴自其他脚本。无论是我同事的脚本，还是我的，都是如此。很多很多代码都是重复性的。很少涉及创造和学习。

那么对此我们又是怎么做的呢？

作为一个团队，我们要关注其他人写的代码类型。我们会审查，同步和回顾代码。如果发现有人一个星期都没有生产创造性的代码，那我们就会去查看原因。

有时，问题的根源在于技术。我们可能比我们应该的做了更多的脚本和配置工作。在这种情况下，我们会增加自动化。不过，很多时候，是因为我们基于某种原因做了太多的复制/粘贴工作。在这种情况下，我们会共同承担这个枯燥的工作以便于尽快完成。

内部工具通常很没意思

作为开发人员，我们希望创建定制的内部工具来解决具体问题，因为创造新事物总是令人兴奋不已。此外，打造定制的解决方案常常比重复利用现有的解决方案更清洁。但学习专有工具要比学习流行的开源技术无趣多了。

为什么？

因为你不能跟你的朋友交流专有工具；它成不了你吹嘘的资本；你不能在Hacker News上看到它的身影；你不能在编程马拉松中使用它；它在你秘密的业余项目中也毫无用武之地。

但是，很多企业陷入创造的陷阱——他们所创造的东西反而会带来更多的烦恼。换句话说：他们解决了一个短期的挫折，从长期来看却会导致更多的挫折。

我对此深有体会。在我曾经的一份工作中，对于大规模数据集成，我被约束必须使用公司制造的DSL。在我看来，它就是另一种类似于SQL的术语（夸张手法）。我更喜欢使用和学习低级的开放式技术，例如Spark。如果没有这种限制的话，我的效率能高5倍都不止（请不要纠结这个数字，领会精神！）。

什么样的文化可以预防这种情况呢？

我们应该尽量偏向于开源技术。勇于面对最前沿的技术。毫不留情地抛弃自定义代码，只要有开源技术成熟到足以取代这些自定义代码。而当我们自己编写的代码变得够格通用的时候，开放源码。

偶尔我们也会犯错。例如，曾经有一段时间我们使用agenda.js库来安排我们的后端工作，因为它看上去既现代化又鼓舞人心。但是最后，它反而让事情变复杂了，所以我们只能回头用一个旧的更可靠的技术（略显古老的cron！）。尽管如此，我们也没有后悔用它试验，因为这是一个宝贵的学习经验。

做一只程序猿很无聊

令开发者无聊的另一个常见原因是糟糕的人力管理。更具体地讲是从上而下，独裁地管理开发人员。

自认为目标远大的主管有时候会使用这种管理风格而不自知。特别是当一个项目不会进展良好，或截止期限将至的时候。在压力的作用下，独裁统治会成为一种自然反射——讨论时“一言堂”，不接受集思广益，没有经过辩证和解释就直接告诉大家去做什么。目的就是为了节省时间，尽快完成工作。

不过很多被管理的员工也不一定会生气：事实上，有些人还很享受直接被告知要做什么。当然，告知的方式得合适。

不过，这里还有一个隐藏成本。

你在开发人员写代码之前就准确告知了他们该如何编码，将这个智力和创造性的过程变成了一个机械的过程：换句话说，就是将开发人员训练成了程序猿。

除非是黑客在攻克边界情况，或是，程序需要做一个临时补丁，否则参与的开发人员总是希望能了解“为什么”他们要采取这种做事方式而不是另一种。当一个开发人员不再关心重大决策以及决策背后的原因的时候，也是他准备换工作的时候。

如何避免这种情况？

鼓励公开讨论的文化。一个用于讨论，制定战略和计划的定期论坛是一个团队所必须的。为了保持这样的文化，每个团队成员都应该保持警惕。

特别是当举步维艰的时期（或最后期限正在逼近的时候），学生需要说出他们的心声，而导师需要仔细聆听。

做一天和尚撞一天钟很无聊

最后但并非最不重要的一个原因：一个封闭的环境中会成为乐趣的绝对杀手。

这在开发领域或高科技产业并不罕见。也适用于几乎任何办公室工作。每天都在同一间办公室，面对同样的人，沐浴同样的文化，做同样的工作……即使是在一个高速发展的环境下，即使所有情况客观都是“好”的，大家也会对这些好的地方习以为常，然后开始对那些不那么好的部分闷闷不乐耿耿于怀。

那么我们该怎么战胜它呢？

关键因素是多样性：雇用不同背景和不同来源的人（例如目前我们团队的6个人就来自于英国，法国，俄罗斯和希腊4个不同国家）。如果团队中的每一个人都能会我们的文化带来新鲜要素，那么即使每天面对同样的人也会变得有趣，也会变得不那么难以忍受。

同时，我们努力创造走出去的机会。

比如，我们会去公共场合聚会，会一起去参加编程马拉松。我们都有自己业余项目，并致力于最喜欢的开源工具。我们甚至时不时地会帮助其他团队承担技术含量不那么高的工作（如招聘，营销，分销…）。不是因为我们擅长这些，而是为了能有一个变化。

我们还组织团队搞活动（例如Secret Cinema），每周举办一次不预定日程的“enkithon”活动。有时候，我们会一起过把黑客的瘾。有时候，我们会头脑风暴一个新点子。有时候，我们会沉溺于玩英雄联盟。甚至我们还一起去泡吧。不到最后一秒我们自己也不知道要去做什么，直到我们共同决定。

我们对抗无聊和枯燥的方法或许还不成熟，还有点混乱。但就像食谱一样，每一份食谱都不能自称是绝对完美的。调整用量，更换配料，反复练习才能精益求精。