为什么有人会觉得程序员脾气暴躁？

我们程序员是有趣、聪明的一群人，但是为什么有人会认为程序员脾气不好呢？这篇文章的作者也是一名软件从业者，他从两个角度分析了可能的原因。第一是从程序员本身出发，谈我们所处的充满各种挑战的工作环境。第二是从与程序员打交道的人的角度出发，总结别人说了什么做了什么才会引起我们不快的回应。下次如果遇到还有人这样说，建议你把这篇文章丢给对方看看。

曾经看过一篇文章，里面给出了一条建议：作为程序员的我们，不要那么快说“不”。我认真想了想这条建议，甚至还反复琢磨了一番。因为我的第一反应永远是，“我们说‘不‘是有道理的！”接下来，还有其他无数种理由涌上来，支持着我继续用恶劣的态度面对对方（比如说产品经理）。但我很清楚，她说得是对的。我们这帮搞技术的就爱快速否定对方，不仅是对产品或设计，也是对其他所有事物。这就使我开始审视软件工程师的群体心理，并希望了解到底是什么让我们成了一群心浮气躁、难以相处的“恶人”。

我们的形象

说起工程师，大家首先会想到哪几个形容词？傲慢、不快、喜怒无常，差不多吧。另外，我们也习惯了说不、总在细节上揪着不放，而且永远认为自己才是掌握了真理、知道该如何更好地完成工作的人。我得承认，大多数情况下这样的形象或者说印象并不冤枉。我们确实在日复一日当这种“恶人”，因为很多技术人员分不清编写代码与人际交流之间的区别——换言之，分不清跟机器打交道与跟人打交道的区别。

（旁注：有些朋友可能会争辩，认为并非所有工程师都是这个样子。没错的。总有一小部分群体与整个群体之间存在比较明显的差异。但我相信大家能明白我想表达的意思，所以如果还有其他弄错的地方，请在评论中不吝赐教。好了，咱们回归正题。）

群体形象可不是偶然建立起来的，它源自实际经验与体会。根据我的个人经历，很多软件工程师实际上爱好娱乐、热情助人而且相当有幽默感。他们是那种具有强大亲和力，能够吸引很多人在周末或者下班之后聚集在其身边的类型。那么，为什么同样友好的个体，走进办公大楼之后就变了个样子？

创造者，而非构建者

我个人对此有个理论。这种理论认为，软件工程师对于自己的看法，跟他人对他们的看法存在巨大差异。在各类不同规模的企业工作了超过十年之后，拥有丰富软件从业经历我整理出了这一结论。企业（产品经理、设计师、其他经理）倾向于将软件工程师视为构建者——产品经理的工作在于勾勒出不存在的东西，设计师的工作是让这东西更美观，而工程师的工作就是把这种东西构建出来。基本上，工程师有点像……那种临时厨师，差不多吧。

我的第一任经理就曾经警告过我。当时我就业的第一家企业倒闭了，这位经理就我的职业跟我进行了一番坦率的讨论。虽然我们在工作中相处不算特别融洽，但他向我提出了下面这条超棒的建议（大意）：

Nicholas，你的价值不止在代码上。不管你接下来要做什么，请一定要想明白，你不能永远当个临时厨子。不要总是关注那些非常具体的、关于如何构建的工作。你应该换个思路，我觉得你有非常出众的产品设计见地与构建能力。

他说得一点没错。有很多企业都只想要临时厨子，他们希望你按照构建者的意思实施完成即可。实际上，大多数企业都是这个德性。在求职的过程中，有很多很多初创企业跟我联系过，包括提供股权让我帮助将创始人构想转化为现实。但这背后的潜台词是：我们已经想明白了一切，只缺个人把它构建出来了。

这才是真正的症结所在：软件工程师并不是构建者，而是实实在在的创造者。从宜家买回一套家具，然后把所有部件拆开慢慢进行安装，这叫构建。毕竟说明已经分项列出，只要逐步进行，消费者最能拼装好这张可笑的小桌子。但是，创造则完全不同，要求在缺少指导或者指示的前提下成就一些东西。创造的起点尖于一张空白的画布，但传世杰作有可能成就于此。只有对编码工作还不够熟悉的软件工程师，才乐于接受他人的指导；真正水平高超的软件工程师，总会发现自己拥有巨大的创造空间，并将这一点视为延续自身职业生涯的必要前提。每一位深爱编码的软件工程师之所以如此，是因为他们很早就曾编写过一款小巧而实用的程序，并且为此而深深着迷。

而在软件这个三足鼎立的世界当中，对于产品经理、设计师与软件工程师这几大势力而言，就只有工程师拥有放弃创造力、单纯生产产品的空间。软件工程师绝不是什么蠢货，他们能够意识到这种状况的发生，并因此心生不满。工程师们希望成为创造过程的一部分，但却被残忍拒绝。于是乎，典型的软件工程师性格就这么来了——心浮气躁？情商不高？随便怎么说吧。

那到底出什么问题了？

产品经理是一群有趣的人，他们拥有令人印象深刻的市场规划与理解能力。他们也倾向于认为，只要脑洞够大，自己的主意总会得到他人的重视，甚至最终变成现实。我很高兴能有机会把这话说出来，因为我有几位好朋友就是产品经理，他们都曾不止一次向我表达过类似的观点。我这绝对不是在批评产品经理，而是他们确实本性如此。他们的工作极富创造力，但想法却并没有完整的形式甚至是可行性保障。这，也是令软件工程师们生气的部分原因。

工程师与产品经理都错误地认为产品规格或者要求等同于宜家提供的家具组装手册。实际上，这些文档并未提供充足的构建信息，而往往只是种起点。这就给工程师带来了一个独特的问题。

为了理解这个问题，我们不妨以盖房子为例。有些人打算在特定的地块上起房子。房子一共有两层，外加一个车库。甚至连粗略的外立面草图都画好了，列在一张餐巾纸上。带着这些要求与餐巾纸，此人问道，“这些就够了吧？”那么，这些真的就够了吗？

从逻辑上讲，这些根本就不够，因为我们不知道比例尺、没有平面图，也悄清楚这座城市对于新建房屋有哪些要求。由于缺少大量必要信息，我们甚至连挖地基这第一步都没法开展。这时候，最科学的方法当然是告诉客户他们疯了，因为还有一大堆事情没弄清楚。但是，这话可不好讲——毕竟人家设定了完工期限，而且我们还总得出席各种碰头会。

客户方面的意见很简单，“这个嘛，要不你们先干着，我这边有新消息了马上通知你。这样，咱不就不用干等着啦。”

这就纠结了，你很清楚目前的信息不足以支持开工，但也知道继续跟客户纠缠下去也不是办法。更要命的是，时间在一分一秒地过去，实在不能再等了。于是乎，大家会怎么办？对！开始做假设。

常言常大哥说得好，“你只要一做假设，就把你想要的跟我想要的混到一块去了。”这话挺有道理。假设往往相当危险，而且经常充满了错误。但是，如果不做假设，那么项目根本是寸步难行。没办法，我们首先假设自己得到的信息是真实的，也就是这栋房子要有两层楼外加一个车库。车库……是独立的还是包含在主体之内？应该设计多大？好吧，为了降低设计难度，独立车库显然更靠谱，而且就按能停一辆车来规划吧。这意味着我们就先从独立车库开始，在关于房子的更多信息到来之后，我们就能在不影响先前工作的条件下继续补充。

在车库工作进行了大概一周之后，客户那边给出了更多细节。实际上，房子得是三层（好吧……这跟当初说的根本不一样啊），而且得有八间浴室。关于车库仍在未定之天，但客户要求把房子的外立面刷成蓝色。这么说来，车库也应该保持统一呀，那同样得是蓝色的吧？这才合乎逻辑嘛，于是我们开始投入更多精力。

又过了几天，车库部分已经接近完工了，我们很开心，因为咱可是在信息极为有限的前提下完成了阶段性的任务。这样，当客户给出更多细节信息后，我们就能进一步对接了。但是，这时候对方提到车库实际上需要容纳两辆车，而且要包含在建设主体之内。正常人遇到这种情况会怎么办？车库可是我们的心血结晶，说废就废了？绝对不行！所以我们会努力推销这套几近完成的方案——因为如果不这么做，那么把车库推倒重做只会增加额外的工人得，最终导致项目无法按时完工。

不知道大家能不能认同我的这个比喻，如果不行，我怀疑各位可能没有真正接触过软件工程项目。这就是我们这帮软件工程师的日常体验。我们一直努力通过自己的创意与设想让项目保持运转，但这一切最终却被打上了“自以为是”、“自作主张”之类的标签。没错，我们承认自己的假设与客户的实际需求存在出入，但如果不这么干，我们就只能闲坐在那里，然后等着被产品经理赶出公司。

在几乎一切其他行业当中，人们都能在开始构建之前就在要求与细节等层面达成一致，至少是阶段性的统一意见——但软件除外。在软件行业中，我们永远“没有足够的时间”提前收集到所有需求。从第一天起，快速行动就成了保证生存的第一前提。因此，工程师们不得不学习如何填补产品经理们留下的空白，用自己的聪明才智保证项目能够照常推进。当然，产品经理的整体形象也不咋样，这帮家伙经常改变主意而且翻脸不认人，直接令软件工程师们的假设在项目进行过程当中失去意义。

要不然，怎么会有那么多软件工程师焦躁不安并且频繁更换工作岗位呢？

第一要务

对于创造者来说，最大的敌人就是需求变化。相信大家都有体会，一旦进入了深度创造模式，我们就不愿自己的“流程”被其他人或事干扰，这会彻底破坏自己原本顺畅的思路。没错，代码编写也是这样一种创造性的过程，或者说是逻辑性与创造性的综合体。我们不是在编写代码，而是在精心规划代码。

但在另一方面，管理工程师的人们总觉得在不同任务之间往来转移应该很轻松才对。毕竟我自己就不只一次听人说过，干活就是干活，还要分什么活吗？你的注意力、你的专注度，必须得听你自己的指挥，明白不？明白……我明白个屁！如果我们已经把时间和精力长期投入某件事上，那么突如其来的转换只会让人思路中断，而且很难返回前一项任务从中断的地方继续推进。换句话说，在转换回来之后，我们还是需要一定的时间投入才能完成重新适应，从而再次全身心沉浸在当前工作当中。这，就是上下文切换成本。即使新任务只需要几分钟就能完成，这种转换同样会带来高昂的切换成本，最终极大降低工程师的工作效率。

这也是工程师们普遍脾气不好的原因之一：总有人在不断改变工作内容的优先级。如果某项任务在这天属于第一要务，但第二天内容又有所转变，则必然伴随对应的上下文转换。创造性的工作就是有这种不愿被打断的天然属性，因此工程师们更愿意一直编码到凌晨，确保自己完成自己的阶段性工作目标——这是一种自我要求，我们不愿因为中断降低自己的生产效率。

真正的高优先级工作，或者说第一要务，应该是稳定且持久的，不可随时变动。但是，“上面那些人”经常改变主意，这一点令软件工程师们倍感沮丧。我们是一群单纯的人，我们只想朝着一个目标不断前进、艰苦奋斗。但如果前一天的目标还是建造房屋，第二天就改成了制造汽车，那大家可以想到团队会爆发出怎样的怨言。

工程师也有缺陷

软件工程师每天都麻烦缠身，但可怜人不只有我们，我们并不是唯一的“受害者”。事实上，我们的一部分负面情绪确实来自内在，而且由于种种原因，很多软件工程师把这种暴躁视为理所当然。这是一种悲剧性的缺陷，其中的内核在于——我们高估了自己的知识与能力。

这种缺陷可能以多种形式出现，最常见的就是时间估算。我接触过的几乎每一位工程师都经常会低估完成一项或者多项任务所需要的时间。只有最优秀的人才能够给出并实现准确的时间估算目标，而大多数人既给不了这样的目标，也没法按时实现。问题在于，作为创造性人才，软件工程师无法遇见自己可能遇到哪些具体挑战。

虽然很多工程师成天抱怨产品经理没个准谱，但他们自己倒是对粗糙的时间估算能力泰然处之。开会讨论项目进度与预期变更？不需要，一切尽在我胸！检查一下代码有没有 bug？开玩笑，我写的代码能有 bug 吗！我们工作所依赖的其他工程师有可能离职？不要紧，总有人会顶替上来，一切 OK 哒～

所有这些因素，都有可能导致预期目标无法按时完成。但其中最重要的一点，就是大多数软件工程师都没有考虑到一项重要的时间支出项——学习周期。这又回归了我之前提到的工程师固有缺陷。我们以为自己完全有能力搞定分配下来的任务，但实际上其中很大一部分却是我们从来没接触过的内容。时间估算，反映出一种完美的知识状态。不同于照着手册就能顺利完成的宜家家具组装，实际工作中的很多任务会要求我们完成自己没做过、甚至根本就不会做的目标。

在大学的计算机科学课堂上，工程师们被错误地灌输了一种虚假的安全感。他们虽然一无所知，但却误以为自己已然掌握了软件原理与软件开发领域的全部诀窍。我就是这么一名傲慢的大学毕业生，到处给别人挑毛病来显示自己的高明。但在几年之后，我发现自己真的是无知到了极点。

计算机科学课程要做的，并不是帮助学生们掌握实际从业当中所需要的经验与技巧。相反，课程更强调主题广泛的概念性知识，确保大家在工作中接触相关主题时不会发生原则性误解。我们需要学习变量、函数与对象，因为这些将伴随我们的整个编程职业生涯。我们还要学习数据库与查询，当然课堂上的那些常规形式并没什么用处。我们花了很多时间在排序算法与数据结构之上，但在专业编写代码时，这一切算法与数据结构知识都只抽象存在，无法在任务中实际落地。简而言之，计算机科学课程考察的是学生解决基础问题的能力，但这类问题在专业编码时并不需要各位自行解决。如果要进行排序，我会直接使用 sort()方法国；如果需要队列或者链接清单，可以使用原生语言自带的功能。这些都能解决问题，而且更加高效。

我们这帮大学生似乎知道该如何实现一切，但实际上我们真正知道的，只是自己接触过的案例。因此，我们有能力完成的工作其实非常有限。但是，我们非常张扬，表现得好像自己对一切都了然于胸一样。但是，我们的知识并不完善，我们总是低估时间需求，因为我们误以为自己不需要继续学习。

另一个问题在于，软件工程师的内心比较脆弱。我们担心如果自己给出的估算时间“太长”，会降低自己在他人心目中的形象。毕竟“优秀的工程师”肯定能更快完成工作，别人相信这一点，我们也就跟着信了。每当我就某个具体项目给出初步估算时间，而某位非工程师表示时间太长时，我都会感到非常惊讶：首先，正如我之前提到，由于存在自身缺陷，我给出的时间可能根本就不够；其次，非工程师怎么知道需要多长时间？他们有能力做出判断吗？这就引出了下一个问题。

“我也编过程！”

软件工程师容易发脾气，但在听见“我也编过程”这类屁话时，他们发脾气的几率又会进一步上升。无论是产品经理、设计师还是高层管理人员，除非能够合理说明工程师的意见哪里有问题，否则这句话只坐引发同一种结果：蔑视。道理很简单，如果我们在勒布朗·詹姆斯介绍了自己的赛前准备时间后，表示他这筹备节奏太慢，并强调自己在高中也打过篮球比赛，那得到的也会是同样的回应。对，“你是不是脑子出问题了？”大概就是这样。

下面是我从非工程师们嘴里听到过的几种常见谬论：

• 我不明白这有什么大不了的，不就是几行代码吗？（从技术上讲，所有内容都是"几行代码"，但这事绝对不简单。）

• “某某”说他几天就能搞定。（这是因为这位"某某"对项目以及解决方案已经拥有全面的了解，但我没有，我得先学习。）

• 我们能不能加快速度？多加点人手行吗？（人手的增加往往只会让情况变得更糟。加快构建速度的唯一方式，就是降低构建目标的规模。）

回归主题：大家对工程师做出的最糟糕的回应，就是告诉他们你自己也编过程（如果还嫌不够拉仇恨，可以再加个儿化音）。确实，从软件工程师晋升上去的产品经理在刚开始几年还能有一定的技术威信（一般是五年，但再往后的话，整个技术环境都变了，过去的经历也就失去了说服力）。但是，如果各位从来没有专职从事过编程工作，请千万千万别提起这一茬——最多说自己也是编程爱好者就好了，绝不能把这个当成工作探讨的依据。

（公平地说，设计师也经常遇到这个问题。每个人都能在视觉设计方面说上几句，因为我们都觉得自己拥有一定的审美能力，但这并不代表每个人都有能力或者资格进行设计。）

人手过剩

大家可能还记得，我在文章开头提到过软件工程师有时候更像是临时厨师。而厨房里一旦厨师过多，情况就会陷入混乱。由于我们低估了任务需要的时间，软件项目的时间进度开始大幅落后，于是管理从员表示不满，并决定增加人手。这些有时天真的高管喜欢量化问题，既然工作负担太重，那多招几名软件工程师不就行了？

没错，有时候增加人手确实有助于解决问题。但在大多数情况下，工程师人数的上涨只会令问题更糟。事实上，富有创造力的员工之间很难相互协调，这种难度会随着人员数量的增长而呈指数级上升。另外，企业往往无法容忍工程师们闲着不干事。如果管理层发现有工程师不忙，那他们就会想办法让这群人忙起来。

几年前，我就遇到过类似的、近乎滑稽的情景。当时我们在设计新的 Yahoo 主页，但只有一小部分人从头到尾跟进这个项目。这其实是种很科学的处理方式，毕竟人少更好协调，能够真正将基础设施的设计思路贯彻下去。但在设计工作开始之后，部门里突然又来了八名工程师，要求一起动手加快原型设计。上头的要求很简单：马上开始为新主页编写代码。但因为架构问题还没有解决，所以工作没法马上开始。而且由于工程师绝对不能闲着，所以他们不得不开始做项目中其他一些可有可无的杂事。反正呢，就是乱成了一锅粥。

在理想的情况下，我们至少应该先把页面的架构原型设计出来，而后再引入其他工程师帮忙构建。很遗憾实际情况并非如此，所以我们很快陷入困境。我们最终只能直接套用加一个项目中的现成架构，然后创建出一套简单的外观，让其看起来跟我们的预期架构基本相符。这样新旧两支队伍终于能够并行不悖地各自完成一部分工作。这个问题非常可怕，因为我们内部都很清楚，这八位大哥干的都是白费力气的活，最终项目还是得用我们偷偷开发的这套新架构。而且随着他们手头工作的推进，双方的对接工作变得越来越难。

同一个项目中人手过多是个严重的问题，因为增加工程师数量背后的真实意图，就是要以并行方式完成工作。但实际上，任何项目中能够以并行方式推进的任务数量都是有限的。但人手过多时，工程师的时间与精力终将由开发转向规划、同步与协调。回到我之前盖房子的比喻，先得规划第一层，然后才能构建第二层。软件项目上有很多任务实际上是依序推进的，因此增加更多工程师并不一定能加快工作速度。就像我以前的一位同事常说的那样，不管你给我多少老婆，我都得 9 个月之后才能当上爹。

什么叫真正的暴躁

好了，缺少必要的信息、要求不断变化、没有完成工作的充分知识，人们还在不断臆测我们的判断——这些因素加在一起，让软件工程师的每一天都过得怨气丛生。作为创造性人才，我们忍下了这一切，因为我们都知道自己的工作成果终有一天会发挥作用，非常非常重要的作用。这确实是驱动软件工程师的主要因素：我们的工作是有意义的，可能影响到无数我们并不认识的用户。无论是开发每天有数百万人访问的网站，还是构建餐厅的销售系统，我们都知道这些会直接改变人们的生活方式。这种成就感与充实感，代表着最强大的内驱力。

我总在说：真正让程序员崩溃的不是辛苦的工作与极高的强度，而是不断变化的要求与粗暴干预。

— Mark Berry (@markab) 2012年3月18日

在因为要求导致项目延误时，软件工程师的脾气立马就会上头。心浮气躁？这是客气的，没动手就算不错了。作为技术人员，我们难以容忍自己无法达成预定的工作目标。有趣的是，软件工程师通常不是那种完美主义者，大家一般都觉得这东西好用就行，不用整得太完善。我们喜欢构建那些能够快速交付的小功能，再一步步把它们组合成大成果。为什么？因为这符合我们的工作方式，也能随时给我们带来一定的成就感与满足感。

现在，我们都意识到延误跟其他元素一样，都是软件项目中的必然组成部分。只要上头别没完没了地催促，工程师们就会疯狂地投入工作。工程师们讨厌的不是艰难或者时间投入巨大的开发体验，而是没有回报的徒劳努力。

有何回报？

作为软件工程师，我们的工作时间表与其他员工的时间表截然不同。我们不是设计师或者产品经理，我们不想因为生产过程中发生的某些问题而被凌晨打来的电话吵醒（当然，我知道有些经理经常这么干）。有一次，我正打算下班回家，但电话响了起来。那头说生产环境出现了问题，让我留一下。于是乎，我的女伴傻等了一个多小时，在此期间我一直在疯狂尝试解决问题。当然，受折磨的不只是我，还有在网上待命的其他同事。

但是，大家可能会发现，软件工程师一般不会对工作时间过长或者因生产问题突然打来的电话抱有太多抵触情绪。因为软件就像是我们的宝贝，就像自己的孩子，我们喜欢照看它。如果需要夜里起床喂奶，那就起来，这是种为人父母的心态。这些，是我们实现创造力的必然结果与后续影响，所以我们更愿意微笑着接受。

工程师们在处理收尾部分的代码时，精神往往额外亢奋。事实上，我发现这时候的工程师比任何时候都要开心，就像是任务已经彻底完成并随时可以接受审查一样。但是，这种亢奋往往很快就会消失，因为在十分钟之后，最让人头痛的 bug 修复工作就该开始啦。

但大家应该可以理解这种心情。设想一下，如果我们已经为某项工作忙了几天、几周甚至几个月，那么在最终的收尾阶段，我们一定会为自己的表现感到自豪。这时候的我们，更愿意安静坐着欣赏自己的作品。但要说有什么回报——bug、功能无效、运行不正常之类的。这些问题总会出现，破坏我们的心情，毁掉这段本该美好的时光……毕竟，这就是生活。

我们为什么要说“不”

之前聊了这么多，现在咱们谈探讨一下工程师们表示拒绝（或者发脾气）的几种常见原因：

• 要求来得太晚，已经不可能在截止日期之间做出改动/

• 要求导致项目初期做出的一项或者多项假设无法成立。

• 新要求与原有要求相互冲突。

• 虽然有望按时完成，但新要求会极大增加预期工作量。

• 我们已经身心俱疲，所以任何新要求在我们看来都显得难以承受。

就是这样，软件工程师也是人，任何人面对这些问题都会做出类似的反应。我们钛任务能够按时完成，而按时完成的唯一方法就是在整个处理过程中保持要求不变。一旦要求改变，那我们就该闹闹脾气了。请安心，我们还是会按要求办的，只是需要宣泄一下，免得原地爆炸。

关注与维护

那么，我们该如何解决这些情绪方面的问题呢？这里不妨再回顾一下驱动工程师坚持工作的基本因素：

• 创造性工作

• 解决问题

• 人们享用我们的工作成果

请注意，这里没有提到“钱”。是的，光是给钱无法令软件工程师们满意。虽然听起来像是在灌鸡汤，但工程师最关注的不是钱，至少不只是钱。钱能让他们在个人生活中玩得更开心，但工程师真正的价值在于编程与创造。只要能够在健康的环境下肆意发挥，我们就能长时间保持快乐的情绪。

那么，如何为工程师们创造这种良好的工作环境？

跨职能工作

与产品经理以及设计师一样，软件工程师同样极具创造力，因此管理者应该尽量在工作流程中体现这一点。在讨论会与初始设计审查阶段，工程师们的意见是一种宝贵的资产。确保每位工程师都有机会当面发言并直接与项目规划者合作（当然，具体时间可以自由安排）。简而言之，让工程师接触创造性过程。反过来说，最让工程师们难以接受的就是不参与设计构思，而只能直接接受上头商量好的规划意见。

工程师们都很讲逻辑，所以在早期会议中听取他们的意见能够显著减少实际执行中可能出现的问题。当工程师们感受到自己的构建者身份时，他们会根据个人理解提出质疑，最终拖慢开发流程。但当他们成为共同创造者时，问题会更少，流程的延误问题也将得到极大改善。

更重要的是，工程师们的知识储备绝对不是开玩笑的。在对浏览器功能的理解方面，没有任何产品经理或者设计师能够与前端工程师相匹敌。因此如果由他们来进行知识分享，那么每一位参与讨论的员工都能从中获得关于产品设计的新思路。想象一下，如果大家希望构建一个照片共享网站，却不清楚其他网站已经支持从桌面将文件直接拖拽到浏览器中进行上传，那设计出的方案该有多么不人性化。

所以，尽早邀请工程师们参与到创作中来。重视他们给出的反馈与建议。他们的主观能动力越是得到充分发挥，工作热情就越是高涨。这就是所谓主人翁精神，非常重要的。

提供创造空间

将软件工程师视为真正的创造者，为他们提供充足的创造空间。各种技术活动日与活动周之所以大受欢迎，是因为工程师们需要精神充电，并重新提醒自己对于编程以及相关创造性的热爱。在这类活动中，工程师可以充分发挥自己的创造力，彻底摆脱常规工作的束缚。

每季度定期开展的技术日活动确实令人兴奋。想要再来波新高潮？给活动日定个主题。为那些最具创意以及可行性的主题准备好奖励，进一步激发大家的参与意愿。当感受到自己的创造力并找到认同感之后，工程师们就能在日常工作中精神焕发，随时准备做出卓越的贡献。

需要注意的是，工程师并不是唯一需要激发的群体，实际上每个人都都需要空间来发挥自己的创造力。但是以我的经验来看，产品经理与设计师的创造空间普遍更大——特别是对于设计师，他们能够经常参加内部及外部的管理与设计峰会。但对工程师，这类机会相对有限。

顺带一提，激发创造力的途径不止技术活动一种，但这是个理想的起步选项。大家还可以鼓励工程师们参加技术会议，确保他们跟上技术发展的最新形势。另外，应该允许工程师们对当前项目表达个人观点。众所周知，谷歌公司为工程师预留 20%的工作时间接触其他项目，这一切都能在企业与工程师之间建立起良好的合作关系。

鼓励休息

长期工作与学习相当累人，所以工程师们也需要休息时间。遗憾的是，我们这帮家伙不太擅长安排时间。我们往往把全部注意力放在项目身上，而忘记享受假期。在从业的前五年里，我一共只休息了七天。我不知道为什么，但我就是不擅长给自己留点放松时间。这是个问题，必须得改正。

工程师的倦怠感与众不同，因为我们习惯了在倦怠的同时自我充电。当太过倦怠之后，我们就会站起来，让自己稍微缓缓。另外，工程师们也不愿向他人倾诉自己的倦怠感受，我也曾经反复吹嘘“硬汉不需要休息”之类的观点。但在管理之前的团队时，我告诉各位工程师，如果觉得累了倦了，一定来找我聊聊。我不希望那种要么无事发生，要么直接离职的悲剧再次发生。我希望每位工程师都能快乐工作，而我能做的唯一一件事，就是在大家情绪低落时多加关心。

鼓励工程师们请假，现在的企业都会给大家准备一定长度的带薪年假。所以，每四到五个月就休息一阵，记得提前跟经理们沟通，他们会根据项目进度适当安排。

当然，定期休息不是彻底放空自己。我们仍然会在休假时写点代码，但这纯粹是种自我创造，因此在感受上与日常工作完全不同。这同样非常重要，既能保持工作状态，又能在愉悦之余为接下来的挑战做好准备。

让他们写代码！

听起来颇为讽刺，但实际上很多企业雇用了软件工程师，但却又不让他们写代码。相反，他们的大量时间被浪费在了无休止的会议当中，进而严重影响生产力水平。一般来说，软件工程师可以连续四个小时高效编写代码，这时候他们的生产效率最高，感受也最愉悦。

但如果听说后来一到两小时后得参加个会，那我们就很难安心推进编程工作，因为开会这事开始在工程师的脑袋里不断回荡。写一个小时代码，停一个小时，再写一个小时，这样的状态将毫无效率可言。软件工程师是有工作状态一说的，这种状态存在于大脑当中；一旦进入了状态，他们不像被任何事情打扰。管他天崩地裂，老子只想安安静静把这段写完！

因此，请确保工程师们每天至少有四个小时不间断的编程时间，这能极大提升团队的开发效率。这也确实合乎逻辑：如果人们每天需要工作八个小时，那至少应该有一半时间用来处理核心任务。我发现自己在下午一点到五点之间的工作效率最高。我也很清楚，如果每天都能保证有这么完整的一段工作周期，那按时完成项目应该不在话下。但如果三点钟有会，那就完了，我知道这一下午绝对干不了什么正事。

另外，每周至少要保证一天不开会，包括那种短小的组会。至少在这一天，让工程师们自主管理时间并完成所有工作。一整天心无旁骛的工作，能够带来令人惊讶的产出。如果有必要，甚至可以允许工程师们在家工作以保证不受打扰。实际上我就有过这样一段经历，经理让我每周至少在家工作两天，因为办公室里的杂事太多。结果是，我很快就完成了任务，轻松愉快。

表达赞赏

软件工程师们心思简单，当然也喜欢赞赏与鼓励。之前我提到过，辛苦完成任务但又面对众多 bug 的情景，往往会令工程师们瞬间陷入沮丧。换句话说，工程师很少有机会坐下来欣赏自己的开发成果，更遑论得到他人的夸奖了。

因此，当工程师们完成了一项任务——特别是那些周期漫长的项目时，简单说声感谢将产生巨大的正面效应。“嘿，感谢你们的辛苦付出，咱们看看还有什么小问题吧～”这样简单的一句话，足以让工程师们放下内心的戒备，全身心投入到 bug 的检查当中。赞赏之所以重要，是因为工程师们日常获得的反馈大多与 bug、生产问题以及功能无效相关。如此一来，哪怕只是一点点积极的回应，都能让他们精神一振。

大家也可以设置积分制度，每季度根据分数向影响力最大或者进步最明显的工程师颁发奖品。奖品不一定非得是 iPad 这种看得见摸得着的实用物件（当然，iPad 确实挺好，我也喜欢！），也可以是一只小小的奖杯，甚至只是写给全部门的表彰邮件。

另外，在项目结束、交付产品时，千万别忘了表达对工程师团队的感激之情。我参加过无数次会议与众多项目，人们会公开称赞产品团队或者设计师在项目中的贡献，但却只字不提工程师付出的血汗。这不公平，因为三方的共同努力才有可能成就一款优秀的产品，缺一不可。项目团队应该是一个整体，单独强调任何一部分都不可取。

总结

我们软件工程师是一群有趣的家伙。我们有种共通的修改，希望能够通过自己的双手让闪光的灵感转化为现实。只要企业能够摆脱临时厨子的思路，把我们真正看作创造性人才，我们就愿意付出一切帮助企业走得更远、更好、更稳定。以往的从业经历告诉我，对工程师思维方式与内驱力的不理解产生了各种各样的冲突。我衷心希望这篇文章能够让工程师与其他同事们更好地进行交流，这其实并不难。毕竟我们都希望成为解决问题的人，而非无脑出力的骡马。

原文链接：

The care and feeding of software engineers (or, why engineers are grumpy)