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

本文由 伯乐在线 –
小马快跑
翻译,顾星竹
校稿。未经许可,禁止转载!
英文出处:Bruno
Marnette。欢迎加入翻译组。

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

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

(免责声明:我很幸运地生活在程序员供不应求的地方,不过后来我发现换工作并不总是一个很好的选择!)。

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

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

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

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

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

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

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

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

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

时间太长;学不到东西

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

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

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

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

如何预防无聊和枯燥感?

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

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

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

图片 1

维护遗留代码很无聊

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

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

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

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

太久;别学

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

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

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

怎样避免这种感觉?

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

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

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

如何避免呢?

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

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

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

维护遗留代码很无聊

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

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

如何缓解这个问题?

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

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

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

复制/粘贴很无聊

还有就是编码,编码,还是编码。

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

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

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

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

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

图片 2

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

复制/粘贴很无聊

编程无它,唯手熟尔。

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

但是事实并非如此,为什么?

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

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

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

图片 3

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

内部工具通常很没意思

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

为什么?

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

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

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

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

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

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

内部工具常常让人无聊

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

为啥?

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

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

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

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

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

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

做一只程序猿很无聊

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

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

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

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

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

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

如何避免这种情况?

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

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

变为程序猿很无聊

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

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

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

然而有一种隐藏的代价。

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

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

如何避免?

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

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

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

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

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

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

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

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

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

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

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

来源:码农网

平淡的日子让人无聊

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

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

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

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

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

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

图片 4

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

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

4 赞 13 收藏 12
评论

关于作者:小马快跑

图片 5

平时使用c#开发程序,几乎每天有时间都会看伯乐在线的内容,同时对翻译也很有兴趣,但总是没有能狠下心来好好地把翻译练好,所以参加翻译小组,不仅是为了学习英语,同时也希望自己的翻译的东西能帮助更多的人。
我的新浪微博 小马快跑_Lucky7
个人主页 ·
我的文章 ·
13