如何让你的程序员不要厌倦工作

文章来源：Medium，由 TECH2IPO / 创见 陈铮 翻译，首发于创见科技，转载请注明出处。

---

作为一个程序员，我从来没有在同一家公司工作超过两年。每换一份新工作都是一次很好的职业变动，在这个行业里跳槽如同家常便饭。但是我的前东家们对我的离去并不开心，他们其中一些人花了很大力气想要挽留我，但是我已经对一成不变的工作感到厌倦了，真的不想在同一家公司再待下去。

免责声明：我很幸运地生活在一个程序员工作岗位供大于求的地方，所以对我来说在换工作永远不止一个选择。

如今我成为了 Enki 公司的合伙人与 CTO，同时我还要负责在公司里面打造工程师文化。我工作内容的一部分就是确保我们的程序员不要对工作感到厌倦，就像我过去那样。

在团队的帮助下，我们设计了一整套策略去帮助程序员们对抗工作中产生的厌烦情绪，并将这些策略运用到了公司的实践当中。至今为止这套方法还是挺管用的，因此我想要和大家分享一下。

在 Enki 我们的程序员很幸运地一直从事着具有挑战性的工作。我们有很多有趣的事情需要去编码，还有大量有意思的问题亟待解决。因此如何解决「无聊」这件事情对我们来说并不很紧急。但是所有的工作都不会一开始就让你感觉厌烦，无聊这种情绪是随着时间推移蔓延开来的，并且会在最糟糕的时刻爆发出来。

这就是为什么我们从公司成立之初就开始着手预防这类问题，并依靠建立起一种企业文化去帮助我们的程序员克服工作中产生的无聊情绪（真心祈祷这套东西管用吧）。

下面就让我们总结一下为什么程序员会感觉工作无聊，以及如何避免发生这些状况吧。

项目时间延续太长，学不到新东西 ⭐

引发程序员无聊情绪最常见也最明显的原因就是一个开发项目拖得时间太长。

我在自己的第一份工作中就充分体验到了项目时间过长带来的无聊感。我的团队要做的是通过一个通用 API 去处理金融数据。一开始这项工作确实令人兴奋，因为这些数据十分复杂且规模庞大，很有挑战性。我从这项工作学习到了如何高效分析数据以及 API 接口设计。但是在一年之后，我们依然在针对相同的数据库工作，使用的也是同样的技术。我在这一针对性很强的领域已经成为一个专家了，在这项工作中再也没有什么新东西可以让我学习。

我不可能再去别的团队或者项目，因为公司感觉把我留在这个项目里才是最合适的。我明白在这个项目中现有的数据与技术已经用的太顺手，所以不可能被替换。我无法说服公司仅仅为了让项目组成员学习新知而改变原本使用的技术。我向公司表达了自己的这种厌倦情绪与沮丧心情，但是无济于事，那么我只好换一份有奔头的新工作了。

如何阻止无聊情绪的产生？

在我们的团队里会试着避免让任何一个程序员接触相同的代码、产品或者数据库超过三个月的时间。将时间设定为三个月也许比较武断，对于大公司来说这段时间可能也太短了。但是我们相信让程序员在不同项目中快速轮转是正确的。

为了实现这一设计，我们在公司里提倡一种全栈文化，团队里的每一个程序员都能够承担任一部分的编码工作（或者是能够快速学会操作）。

预防无聊情绪滋生的另一个方法就是开诚布公地讨论这个话题。我们每周都会进行一次直接、开放的一对一谈话。如果一个程序员在工作中已经感到太过舒服没有挑战，或者是已经在这一方面过于专精，那么就是时候让他轮转到另一个项目当中去了。

维护代码这种遗留问题让人感觉太无聊 ⭐

你能够很清楚地分辨出何时项目就开始进入了维护模式，不论是从正式的渠道还是别的途径，只要当你的程序员花上了 90% 的时间去修补 BUG 而不是开发新功能，那就代表着他们已经进入了代码维护期。有人会说维护代码是一项不可避免的工作，老旧的代码需要不断得到支持。开发软件就像造房子，你总是需要维护和翻新房子的，不是吗？

既是，也不是。这项工作确实需要有人去做，但是问题通常会出在工作态度上。

我曾经的一位职场前辈对于维护代码具有强烈的抵触情绪，他理所当然地认为维护代码这种事情根本没有什么好做的，软件开发完毕之后就让它们自己去运行好了。生活简直糟透了，你还不得不适应它。

如何缓解这种抵触情绪呢？

项目开发工作进入无聊的维护模式有时候是由于糟糕的技术决策与缺乏勇气的双重作用。

一个拥有着复杂的依赖关系的庞大整体代码库需要额外的付出时间去做维护工作，于此相反的是，一个架构良好的微服务基础设施拥有更强的灵活性。当一个微服务架构出现缺陷时，你可以立即采取措施去修复。你可以重新写一遍代码，使用不同的编程语言或技术。通过这种方式，你会学习到新的东西而不是仅仅在遗留下来的代码上修修补补。如果你的架构不允许你重新来过，你还可以采取别的措施来改善，并且在这个过程中学到一些 DevOps 的技巧（译者注：DevOps 就是开发（Development）和运维（Operations）这两个领域的合并，可将原本笨重的开发与运维之间的工作移交过程变得流畅无碍）。

想要解决程序员在维护代码中产生的无聊情绪有很多种方法可供选择，公司采用微服务战略只是其中一种可行方式。还有别的公司会通过打造智能工具去让代码维护工作变得更有效率也更有意思。一个比较极端的例子就是 Facebook 对他们的海量 PHP 代码库所做的工作。Facebook 开发了他们自己的编译器以及带有 Facebook 风格的语言（Hack），这使得他们的 PHP 代码库不仅便于维护，也改善了程序员的工作体验。我猜想这种方式并不能完全解决代码维护的遗留问题，但是它确实让这个工作听上去更有趣了。

工作只剩下复制 / 粘贴这种小儿科的东西 ⭐

程序员所做的工作就是不停写代码。

我在之前的工作岗位上曾经产出了大量没有什么意义的代码。比如说我曾经为数据集成而编写了 Groovy 与 Python 脚本。这些数据相当复杂，包含了许多不一致的数据库对象集合，因此也不能够自动化运行。鉴于此我不得不编写大量代码，我的同事都猜想我肯定从中学习收获了很多。

然而并没有，为什么会这样呢？

因为 50% 的代码（这是夸张的描写手法！）是我直接从 Stack Overflow 复制粘贴过来的。还有 40% 的代码是从其他脚本中复制过来的，有一些来自我同事的代码，还有一些是我之前写过的。工作变成了一种重复劳动，其中没有一点创造性与学习长进可言。

我们如何避免这种情况？

作为一个团队，我们都会花时间去了解团队其他成员写了哪些类型的代码。我们在代码审查、同步以及工作回顾的时候去完成这件事情。如果一个人花了一星期时间却只写出了毫无创造性的代码，我们就会试图去弄明白在他身上到底发生了什么。

有时候问题的根源来源于你所用的技术。我们可能使用了过多的脚本，或者是做了许多本不应该做的配置工作。如果是这种情况，我们就会添加更多的自动化设置。有些时候我们进行代码的复制粘贴是事出有因的，在这种情况下大家就会一起分担这项不得不完成的无聊工作。

只能使用内部工具也太没劲了 ⭐

作为一个程序员，我们喜欢打造一个自定义的内部工具来解决某些特定问题，因为动手创造是一件令人兴奋的事情。而且，构建一个定制化的解决方案通常要比找出一个现有的方案进行再利用要好得多。

然而相比于学习一门时下流行的开源技术，学习一个内部专有工具的趣味性只有前者的十分之一。 这到底是为什么呢？

因为它不能成为你和朋友聊天时的谈资，你也不能到处吹嘘，你不会在 Hacker News 上读到关于它的新闻，你也不可以在编程马拉松（hackathons）活动中使用它，当然了你也不能将其用到自己秘密开发的副业项目中。

很多公司都跌入了打造内部工具的陷阱当中，因为它随之而来的就是给程序员带来更多的无聊情绪。换句话说：你为了解决一个短期问题所开发的内部工具反而带来了更多后患无穷的长期问题。

在我的上一份工作中就对于这个问题有着切身体会。我被限制只能使用公司自己开发的针对大规模数据集成的 DSL 语言，而我此前一直学习的完全是另一种 SQL 语言。我更希望能够用上哪怕是 Spark 这样开放程度没那么高的语言。如果不使用内部工具，我将会 10 倍投入工作，写出的代码也会 2 倍优于现有的水平，还会让我的生产力提高 5 倍（不要纠结于其中的倍数是否有数学逻辑，你只要体会我的心情就行了！）。

什么样的企业文化能够避免这一困境？

在我们公司中不会对开源技术抱有偏见。如果能够重新利用相关开源技术，我们当然很乐意去做。我们不会回避前沿技术，一旦开源技术变得足够成熟能够取代我们现行的专用语言，我们就会立马抛弃原有的定制化代码投向开源技术的怀抱中。在我们自己开发的定制化代码变得足够通用之时，我们就会将其开源。

这么做也偶尔会犯错。比如说我们曾经使用过一段时间 agenda.js 去安排我们的后端工作，因为感觉这种技术既尖端又令人兴奋。但是不久之后它就变得太过复杂了，我们只好重新用回了之前老旧但是可靠性更高的技术。即便如此，我们依然不后悔曾经尝试过，因为这也是一种宝贵的学习经验。

如果不知道自己为何写代码，必然厌倦工作 ⭐

糟糕的人力管理也是造成程序员对工作心生厌倦的常见原因。更具体地说就是：针对程序员的自上而下的独裁式管理会让他们产生抵触情绪。

心怀良好意图的管理者经常在不知不觉中就使用了这种独裁式工作方法。尤其在一个开发项目进行的不是那么顺利或者是截止日期临近之时，这种管理方法就更为常见了。在巨大的项目压力下，管理者很自然地就会缩短团队讨论时间，减少头脑风暴，直接命令程序员去写代码，却不解释为何这么做，也不接受任何争辩。而管理者通常这么做的出发点就是想要节省时间，尽快完成工作。

如果这种管理方法能够被理解，也不是每一次都会招致厌烦；事实上，有一些人还挺能接受你简单直接地告诉他应该做什么。当然了，这也是建立在你的说话语气是能被对方接受的基础上。

使用这种独裁式管理方法也有隐藏的成本。通常程序员在明确知道写什么代码之前，需要有一个将智力与创造性进行转换的固有思考过程。换句话说，如果你不让他想明白其中的关键，只是一味地命令他去编码，他就会变成一只会写代码不会思考的猿猴。

更重要的是，你应该鼓励程序员去追问「为什么」，这样他们能够更加投入到自己所做的工作中去。除非你们现在所做的是一个剑走偏锋的极端玩意，或者是一个临时补丁，不然的话都应该和程序员交代清楚。如果一个程序员不再关心与项目有关的重要决定，也不再思考这些决定背后的逻辑，那么他应该是已经准备跳槽了。（译者注：哈哈，说的就是我！）

如何防范这一问题？

想要解决这一问题最需要的就是在企业文化中建立起公开讨论问题的机制。要留出固定的讨论时间，让整个团队都参与讨论接下来该做些什么、如何计划。想要保持这种开放讨论的企业文化，每个人都要对独裁式的管理方式保持警觉。

尤其是在团队遭遇困难的时刻（或者是截止日期临近的时候），团队成员需要更大声地表达出自己的意见，而管理者则更需要小心谨慎地聆听大家的心声。

日复一日的工作总会不可避免地走向无聊 ⭐

还有一点不得不提的是：在一个封闭的工作环境里长时间工作绝对会扼杀人感知生活的乐趣。这一点不仅仅是针对科技行业工作者或者是程序员岗位，放诸于其他行业也是一样的。这一条几乎适用于任何一个后台操作岗位，每一天在相同的办公室里，见着同样一帮人，做着一成不变的工作，也没有什么不同文化的碰撞。即便是在一个快速增长的企业环境中，纵然所有的事情从客观角度看都在「良好」运行着，人们也会感觉自己有资格去寻找一些乐趣，并且会从不那么好的事情中感到沮丧。

如何与日常工作中滋生的无聊情绪做斗争？

解决这一问题的关键就是尽力创造多样化：招聘拥有不同背景以及来自不同国家的员工（比如我们的团队现有的 6 个成员就分别来自英国、法国、俄罗斯和希腊）。如果你每天看到的同样一帮人能够给你带来不同文化的冲击，那么上班这件事肯定会更有趣一些。

同时，我们会积极地创造一些走出常规工作环境的机会。

例如我们会一起去参加一些行业聚会以及编程马拉松活动。我们还会一起打造工作之外的副业，共同研究我们喜欢的开源工具。除此之外我们还会不时地帮助其他团队完成一些不那么技术性的工作（包括招聘、市场和分销）。这么做并非因为我们都擅长这些工作，只是为了在日常工作中寻求改变。

我们还会组织一些团队活动（比如一起看一场秘密电影），我们每周还有一个固定的不需要事先预设主题的团队活动时间。在这个自主活动时间里，有时候我们会一起专研技术，有时候会头脑风暴出一个新点子，有时候仅仅是聚在一起玩 LOL，或者是约好一同去泡吧。这个自由活动的美好之处就在于当我们坐下来讨论该该去玩啥的时候，不到最后一分钟根本就不知道要去干什么。

给生活增添这一小小的未知数成为了我们对抗无聊的终极一招。就像其他对抗无聊的方法一样，这也不会是非常完美的解决之道。我们要做的就是在原有基础上不断调整，找出一些新招数，并且将其不断地运用到对抗无聊的战斗中。