编程很没劲，除非你……

作为一个程序员，我从来没有干一份超过两年的工作。

每份新工作都是一个好的职业转变，并且在我们这个行业频繁跳槽也很普遍。但之前的老板们对我的离开非常不爽。有些老板一个劲儿地试图挽留我，但是我待得实在太闷了，所以呆不下去了。

（免责声明：我很幸运待在了一个对程序员求大于供的地方！我意识到换工作并不总是一个选择。）

现在我是 Enki 的联合创始人兼 CTO 。同样，我负责公司的工程师文化。我有一部分工作就是确保我们公司的程序员不会像我之前那样感到无聊。

在我团队的帮助下，我们想出了干掉无聊的法子。因为到现在为止，这个办法效果还不错，因此我想在这儿和大家分享。

在我们公司，我们很幸运能忙于解决一个有挑战性的问题。我们为很多有趣的事情编写代码，有很多有趣的谜题需要解决。因此“无聊”并不是一个需要紧急关注的问题。但是“无聊”从不会一开始就出现。相反，无聊是随着时间悄悄地混了进来，并在最不可能的时刻给了我们当头一棒。

这就是为什么我们要很早就营造一种文化来解决这个问题，把你从曾经的无聊中解救出来（手指交叉！（校注：西方祈求好运的一种方式，将食指和中指交叉））。

太久；别学

导致程序员感到无聊，最普遍和显而易见的原因就是项目拖得太久。

我在第一份工作就直接地体验了这种无聊。我的团队负责通过便利的 API 准备和提供财务数据。由于项目的复杂度和数据规模，一开始让人很兴奋。我学习了关于高性能的数据分析和 API 的设计。但是一年之后，我们仍然在使用相同的技术维护相同的数据。我已经在某些特殊领域变成了专家。我已经没啥新玩意儿要学了。

我没法换组或者换项目，因为这对我们公司意义重大，公司必须让我呆在原处。我知道这些数据和技术已经好到无法替代，我不能仅仅因为自己想学点儿新东西就改变现有技术。我表达了我的无聊和挫败感，但是没用，因此我不得不换个工作。

怎样避免这种感觉？

在我们团队，我们试着避免任何人面对相同的代码，产品或数据超过三个月。这个时间段有点儿武断，并且对于一个大公司来说可能也太短了。但是我们渐渐开始赞成这种快速换岗。

为了让这事儿变为可能，我们发扬了一种全栈文化。我们的任何一位程序员都可以对代码库中的任何一部分代码进行开发（或者快速学习如何开发）。

另一种避免无聊的方法是不停地讨论这些事情。我们每周进行直接开放的一对一讨论。如果某个程序员开始觉得太安逸了或者太明白了，那他就到了换岗的时候了。

维护遗留代码很无聊

当程序员花费 90% 的时间改 bug 而不是开发新功能，你就可以判断出某个项目是否正处于维护模式。

有人会说维护是不可避免的。旧代码需要维护。开发软件就像盖房子。你需要维护旧房子并且要时不时整修它们，对么？

如何缓解这个问题？

维护模式通常是不良的技术决策连同缺乏勇气的结果。

当某个一成不变的大型代码库拥有复杂的依赖就需要额外的维护工作。相反，一个设计良好的微服务架构有更好的扩展性。当一个微服务出错的时候，你可以替换它。你可以从头用不同的语言或技术重写这个微服务。这种方法，你会学到新的东西而不是给遗留代码打补丁。同时如果你的架构现在还不允许你这样做的话，你可以逐步的改善它，并在这个过程中学习一些新的开发技巧。

微服务策略是解决“无聊”的维护工作这一问题的方法中的一种。有些地方会创造一些智能工具来让维护工作变的更加有效和有趣。一个极端的例子就是 Facebook 处理他们庞大的 PHP 代码库。他们在 PHP 之上构建了自己的编译器和自己的类型语言（ Hack ），让维护更容易同时提升了开发人员的体验。我怀疑这不能完全“解决”遗留问题，不过这肯定让工作听起来更有趣些。

复制／粘贴很无聊

编程无它，唯手熟尔。

在我之前的一些任务中，我写了很多很烂的代码。比如，我曾经编写 Groovy 和 Python 脚本来做数据集成。这些数据非常复杂，有很多不一致的结构，不允许太多的自动化。因此我不得不写很多代码，我的同事们还猜我学了不少东西。

但是事实并非如此，为什么？

因为我 50% 的代码（为了夸张起见）是直接从 Stack Overflow 上复制／粘贴的。而且另外 40% 是从别的脚本中扒下来的。要么是我同事的，要么是我自己的。这就变成了重复。一点创意都没有或者啥也没学着。

我们是怎么试着缓解这个问题的？

作为一个团队，我们注意不同开发写的不同类型的代码。我们在代码审查，同步和回顾的时候做这件事儿。如果某人花了一周时间写了没有创造力的代码，我们会试着了解这是为什么？

有时，问题的根本就是技术。我们可能做了比应该做的更多的脚本处理或配置工作。在这种情况下，我们添加了更多的自动化。另些时候，是出于复制／粘贴的原因。在这种情况下，我们会平摊这种无聊的工作来搞定它。

内部工具常常让人无聊

作为开发者，我们乐于开发一些定制工具来解决特定问题，因为创造新东西令人兴奋。同样，创建私人订制的解决方案要比重复使用现成的方案更加酸爽。但是学习一个专属的工具可比学习一个流行的开源技术要没劲差不多十倍。

为啥？

因为你不能和你的朋友聊起它；你不能吹牛说你懂这玩儿；你不能在 Hacker News 上读到它的消息；你不能在黑客马拉松上使用它；你不能在自己的秘密项目中使用它。

但是很多公司都会陷入自己亲手创造的，做一些没有价值的新玩应儿的陷阱。换句话说：他们解决了一个短期的挫折，却不料这东西会在将来引起更大的麻烦。

我在之前的工作中直接体验到了。我被迫使用公司自家做的 DSL 来完成大数据的整合。我学的所有的东西只不过是另一种类 SQL 语言（我刻意夸张了）。我可能更喜欢使用和学习一种像 Spark 那样的底层开发技术。我可能会投入十倍精力更加投入其中，虽然我的代码会因此膨胀到现在的两倍，但是我依然会有五倍的生产力。（我算的可能不太准，但你能领会我的精神！）

什么样的文化能避免这个问题？

我们试着侧重于开源技术。如果我们能重用一些相关的和令人兴奋的开源技术，我们就会使用它。我们并不排斥前沿技术。只要一个开源技术变得足够成熟，我们就会抛弃自己写的代码并取而代之。当我们自己的代码变得足够通用，我们就把它开源。

我们偶尔也会犯错。比如：我们曾经使用了一段时间 agenda.js 来安排后台工作，因为这个库时髦且令人兴奋。但后来陷入了麻烦之中，所以我们转去使用一个旧的，更稳定的技术（好用而且陈旧的计划工具！）。同样，我们并不后悔经历这些，因为那是一段宝贵的学习经验。

变为程序猿很无聊

另一个普遍引发程序员感到无聊的原因是疏于对人的管理。更具体的说就是：从上到下，对开发人员进行蛮横管理。

那些拥有高尚目的的管理者，经常会无意中使用这种管理方式。特别是当一个项目进行的不顺利，或者截止时期迫近的时候。压力之下，一个自然的反应就是试着减少讨论，最少的头脑风暴，并且不由分说地明确告诉大家应该做什么。仅仅是为了节省时间把事情做完。

一个聪明的管理者没有必要因为这件事儿心怀意乱；事实上，很多人（偶尔）会很喜欢被告诉具体应该做什么的这种简单。当然，假设这是一种感觉合适的方式。

然而有一种隐藏的代价。

在写代码之前明确的知道要写什么，将一种智力上的创意过程转变成一种机械过程；换句话说，那将把一个开发人员变成程序猿。

更重要的是，参与项目的开发人员想知道为什么他们要用这种方式处理事情而不是另一种。当然，除非，那仅仅是想要解决一个紧急问题的无奈之举或者一个临时补丁。但是如果一个开发对这些重要的决定漠不关心，那背后的原因就是这个开发准备换一份工作了。

如何避免？

最主要的事情就是需要一种文化来鼓励公开讨论。需要一个正规的论坛，作为一个团队来讨论，出谋划策并且计划我们需要做的事儿。为了保留这样的文化，团队中的每个人必须很注意。

当时间越来越紧（或者截止日期正在迫近），学员要勇于表达自己的想法，同时导师要善于聆听。

平淡的日子让人无聊

最后但也很重要的一条：按部就班的封闭环境是趣味的杀手。

这并不只针对开发这个角色或科技行业。这适用于很多“幕后”工作。他们每天都面对着相同的办公室，相同的一群人，相同的文化，相同的角色……甚至在一个快速发展的环境，甚至所有的事情在客观上都“很好”，人们一面为这个美好时代的来临感到沾沾自喜，同时也因为这平凡的生活而变得郁郁寡欢。

我们怎么同这种问题作斗争

这里的一个关键点就是差异性：雇那些有不同文化和来自不同地域的人（比如：我们团队现在的六个人有英国人，法国人，俄罗斯人和希腊人）。如果他们中的每个人能带来不同的文化，那么每天看到这群人绝对更有意思。

同样，我们会创造更多的机会来摆脱平淡的日子。

比如，我们一起去参加公开的聚会和黑客马拉松。我们同样有一些自己的项目并且会给我们最喜欢的开源工具贡献代码。我们甚至会时不时地帮助团队做一些非技术的工作（比如招人，市场，物流……）。不是因为我们擅长这个，只是为了做出改变。

我们也组织团队离开办公室（比如：秘密电影院）进行每周一次的不在日程之上的“ enkithon ”（这是作者自造的词汇； Enki 为作者公司的名字， thon 取自黑客马拉松 hackathon 这个词的后半部分）。在这些活动中，我们有时一起 Hack 一些东西。有时会头脑风暴一个新点子。有时候只是一起玩儿英雄联盟。或者一起去酒馆。事实上这美妙之处在于当我们决定一起行动的时候，不到最后一分钟我们不知道将要做什么。

这点小小的混乱是我们对抗无聊秘诀中的最后一部分。就像每个食谱一样，永远不可能完美。调整剂量，替换食材并反复试验。

本文由 伯乐在线 - 小马快跑 翻译，顾星竹 校稿。
英文出处：Bruno Marnette