为什么大部分软件工程师脾气都很暴躁

前不久，Jenna Bilotta［译注1］写了篇很棒的文章叫做《设计师和工程师怎样才能默契地工作》［译注2］。在文章中她说到了设计师和工程师更加富有成效地工作的方法。面对相同的和设计师一起工作的挑战（及当我作为UI角色和工程师一起工作的挑战），我赞赏她建议的那些实际方法。尊重其他角色起到的作用以及明白他们工作时的想法总是有好处的。

其中有一个她对工程师的建议是不要过快地说“不”。这困扰了我很久，并一直在我脑海中挥之不去。我的第一反应是：“但你们不明白为什么我们会说‘不’！”，随后产生了成千上万的自我防卫想法。当然她是对的，我们的确非常快地说“不”，不仅仅是对设计，对所有的一切都会这么说。这使我开始思考软件工程师的心理以及是什么导致我们变成现在这样的。

译注1：Jenna Bilotta，Google产品体验设计师和自由顾问。设计过YouTube和Google Reader等产品。

译注2：本文相当精彩，推荐给所有的设计师和工程师们。

我们的名声

坦白讲，软件工程师一般都因傲慢自大、难以相处以及喜怒无常而著称。我们也因在辩论卖弄学问的细节时说“不”而出名，并且认为自己知道怎样把每个人的工作做得更好。总之这种名声是应得的。这正是我们天天在做的：一边写代码，一边上Twitter和Hacker News。

（边注：有些人会说这对所有的工程师来说是不正确的，你说对了。对于在工程师中的一小部人来说，上面的某个或者所有的观点对于他们来说都是不正确的。在滚动到底部留言告诉我这篇文章让你有多无语时，请继续读下去。）

名声不是随便就能获得的，名声是靠经验挣得的。名声这东西困扰我的是，就我自身认识的一些工程师来说，一般他们都是喜欢娱乐的、和蔼可亲的（如果不是固执己见的话）且令人愉快的群体。他们是你在工作之余想一起出去玩的及在周末想追随的人。那么为什么在工作面前，另外一个不同的性格就会出现了呢？

创造者，不是建造者

我有一个推理。这个推理是软件工程师把自己和与之一起工作的人看成是非常不同的群体。

我在软件行业的大公司和小公司工作了十多年后得出了这个结论。公司（产品经理、设计师及其他管理者）往往把软件工程师当作建造者。产品经理的工作是梦想建造什么，设计师的工作是怎样在审美上取悦别人，工程师的工作是建造他们想出来的东西。基本上，工程师被看作为该行业的“临时工”［译注3］。

译注3：英文原文是”short-order cooks”

我的第一个经理告诫过我一些事情。在我的第一家公司快要倒闭的时候，他和我就我的职业生涯进行了一场很坦白的探讨。虽然我们有时相处得不好，但他给了我这个非常好的建议（大概的意思）：

“Nicholas，你比你的代码有价值。不管你下份职业是什么，务必不要当“临时工”。不要接受那种会明确告诉你要建造什么和怎么建造的工作。你应该在那种对产品有深刻理解并且也有能力来建造的地方工作。”

他是完全正确的。有很多的公司都想要“临时工”，他们想要实现者和建造者按特定的节奏并要保持一条直线前进。实际上，我会说几乎所有的公司都想这样，不管是大公司还是小公司。我无法告诉你有多少家创业公司联系我，给我股权，作为交换的条件是帮创始人建造他们的愿景。这隐含的意思是：我们已经想清楚了所有的东西，只需要某个人来建造它。

这里正是问题的症结所在：软件工程师不是建造者。软件工程师是创造者。建造是你从宜家买了一件家具带回家，说明书就摆在那儿，如果你按部就班地照着做，就能得到你想要的滑稽小桌子。创造是不同的过程，它在没有指导和说明书的情况下会产生一些东西来。这就像是在一块空白的画布上绘一副杰作。软件工程师不编码是因为他们想别人来告诉他要做什么，他们开始编码了是因为他们发现了能够创建一些有用的东西。每个软件工程师都是因为早先做了一个有用的小程序而爱上编码，从此便迷上了。

在软件的三个统治角色中（即产品经理、设计师及软件工程师），只有工程师是被期待不用创造的，只管生产。软件工程师不是傻瓜，他们看到发生了什么，会开始“创造”不满（没有双关语义）。工程师想成为创造过程的一部分，但被拒之门外。因此最终有了典型的软件工程师的性格叫做暴躁。

等等，出了什么问题？

产品经理是很有趣的人。他们的想法和了解市场的能力令人钦佩。他们也有一种倾向，认为他们的想法是完整的，其实，那漏洞大得火车都能通过了。我是友好地说的，我有几个要好的朋友是产品经理，大家都知道我曾经当着你的面说过这种话。这绝对不是对产品经理的批评，这是他们的本性使然。他们的工作是一种创造性的，呈现的想法是不完整的。这是使软件工程师脾气变得暴躁的一部分原因。

工程师和产品经理都趋向于认为，产品规范或需求就相当于宜家的家具使用说明书，这是不对的。在现实中，这些文档很少包含足够的信息来建造实际的东西。他们通常只是工程的起点，这给工程师提出了一个独特的问题。

要理解这个问题，考虑造房子的工作。有人已经决定希望在某块土地上造一所房子。房子有二层和一个车库。甚至还有一张餐巾纸，上面画着房子的正面草图。那人带给你这个信息和餐巾纸，说“这足以让你开始造了吧，对不对？”那你是否能够开始造呢？

从逻辑上讲，这时你还不能开始造房子。你不知道房子的建筑面积。你没有房子的平面图。你不知道城市对新房屋的要求规范。从字面上看是没有足够的甚至可以开始挖土的信息。此时，你会告诉你的客户，他们是疯狂的，必须要弄清楚自己想要什么。现在假设你不能这样做，因为某人已经设定了Deadline，于是你负责召开会议。

“嗯，”你的客户告诉你，“为什么你不先开始造呢，当我想到细节部分时我会告诉你的。这样一来，我们没有浪费任何时间。”

你知道，没有足够的信息能让你开始造，并且现在进一步质疑客户也不会得到任何别的信息。然而，你要赶Deadline，坐在那里等更多的信息你是受不了的。你会做什么？你开始假设了。

俗话说得好，“当你假设时，就把你和我都当成驴了”，大概再如此正确不过了。假设是危险的，而且往往是错误的。然而，如果没有做一些假设，项目就无法向前推进。这就是你所做的。你假设你已经知道的信息是对的：房子有两层楼和一个车库。车库，它应该是附着式的或分离式的？它应该是多大？好吧，简单起见，它和房子是分开的，并只能停一辆车。这意味着你可以先开始造车库，作为一个房子旁边的独立建筑物，当有关于房子的更多细节时，你可以继续建造一旁的车库而不受影响。

车库造了一周后，你的客户想到了更多的细节。事实上，房子有三层和八间浴室（唷，真幸运，还没有开始造房子）。没有车库的进一步信息，但房子要被漆成蓝色。然后，你从逻辑上假设，车库也应该被漆成蓝色，所以未来的一段时间你都花在这上面了。

几天后，车库差不多造好了。你对建造的质量相当满意，因为只有这么少的信息你就造出来了。你现在开始准备造房子了，就在这时，你的客户回来告诉你更多的细节。车库实际上需要能停下两辆汽车并且不是分离式的。你感到很沮丧，因为你造了一件好东西，现在需要用推土机推平掉，为“真实”的东西让道。更糟糕的是，你现在只有更少的时间来完成整个工种了，这只能增加暴躁的级别。

如果这个比喻对你来说近乎疯狂，你可能永远没做过作为一个软件工程师的工作。这是我们现实生活的每一天都会发生的。我们试图通过我们的创造力来推进项目，最终发现事实上我们不能读懂任何人的想法，因此错误地猜测真正要建造的东西。然而，如果我们不做假设，就会坐在那里无所事事，因为没有人喜欢瀑布流方式的软件开发过程。

除了软件行业，几乎所有其他行业建造东西，预期的所有需求和细节在建造开始前都已商定并最终确定。在软件行业，“没有足够的时间”提前收集所有的需求。从第一天开始“快速推进的重要性”就已深深地钉在了我们的心中。所以工程师学着去填充产品经理留下的空白，仅仅是为了保持项目能够向前推进。当然，产品经理也因经常改变主意而著称，这意味着工程师的假设在项目推进过程的中途往往会失效。

那么，软件工程师们常常会很快失去工作的热情并频繁跳槽，这还用怀疑吗？

第一优先级

上下文切换［译注5］是任何创造者的敌人。一旦你沉湎于创造模式（有人称之为“流”）里，把注意力转移到别的东西上面就会使你焦虑不安，当前的过程也被完全中断。编码是一个创造性的过程。它同时是逻辑性的和创造性的。我们不仅仅是在编码，我们是在精心地设计代码。

译注4：英文原文是”context switching”

在管理工程师时间的人当中，好像认为工程师很容易从一个任务转移到下一个任务。就像有些人告诉我的，工作毕竟就是工作。你就直接指挥他去需要去的地方，就像指挥发射大炮一样。当然这根本就是不对的。如果你在一个任务上花费了大量的时间，然后被要求放下它去做其他的任务，你就不能很容易地再回到首次的任务，并从离开时丢下的地方重新拾起来。在你再回过头时要确保明白所有的状况，这有一个重新适应的过程，这是上下文切换的代价。即使新的任务只需要几分钟即可完成，这足以把“流”中断，从而使工程师生产力低效。

这是让工程师脾气变得暴躁的最主要的原因之一：不断改变任务的优先级。如果第一天某个任务的优先级最高，第二天别的任务优先级最高，这意味着必然会发生上下文切换。富有创造性类型的工作是不想被打断的，这是为什么工程师们能高兴地持续编码，直到早上凌晨才结束工作。把“流”中断，会使我们的生产力低下。

真正的优先级不会是临时性的，它们是不变的。在我们上面的人频繁改变他们的想法，这会非常令软件工程师们沮丧。我们时刻准备着投入到战斗中去，只需给一个行军的方向。但如果第一天你告诉我们是在造一所房子，第二天告诉我们是在造一辆汽车，你应该预料到你的士兵会和你的意见不合。

工程师的不足

软件工程师每天都被推入困境，但我们不是受害者，即使我们这些人会很夸张地倾向于表现为受害者。实际上我们脾气暴躁的一部分原因来自于自身，由于某种原因深深扎根在大多数软件工程师的心中。我们有一个很悲剧的不足之处，这个不足是我们高估了自己的知识和能力。

这个不足会以多种方式表现出来。最常发生的是时间估计。几乎每一位我知道的工程师，会习惯性地低估完成一项或一系列任务需要花费的时间。只有最出色的人能给出精准的时间，并和实际情况相符，而其余的人有时会漏掉两个或多个因素的一个。问题是软件工程师作为创造者，无法预见他们会遇到的问题。

尽管许多工程师会抱怨产品经理改变他们的想法，但几乎没有人会对他们的时间估计负责。没有时间申请召开会议再过一遍需求并做出更改。Bugs？我们的代码是完美的，从来没有bug，所以我们并不需要担心（终究QA还是会测出一些莫名其妙遗漏掉的问题，对吧？）。我们依赖的一些人会退出？没关系，其他人会来补足这个空缺的。

所有这些原因加起来很快就会赶不上Deadline，但是在事情没有及时完成的理由当中，没有一个比这更加危险：没把学习的时间算进去。这又直接回到了我们的不足了。我们认为已经知道如何完成所分配的任务，但这经常是我们之前从来没有做过的。时间估计反映了一个完美的知识状态：你有宜家手册帮你开路。现实情况是，许多任务都要求我们做以前没做过的事情。

在大学学习计算机科学的工程师，在课堂上教会的对软件安全的感觉是错误的。他们出校门后认为明白软件及软件开发过程，其实什么都不知道。我在第一份工作的时候绝对是傲慢的大学毕业生，告诉大家他们这样做是错的。我在多年以后才能弄清楚其实我什么都不知道。

计算机科学课程不是为你工作时准备的。他们教会你的是主题范围广泛的理论知识，以便你在工作中遇到他们时不会傻了眼。你学习变量、函数和对象，因为你将一直会遇到这些东西。你学习数据库和查询，然而你学习的正规形式在实际工作中是没有用的。你在排序算法和数据结构上花费了大量时间，所有这些在你工作编码时都是不用考虑的。总之，计算机科学课程是在评论问题的解决方案，你在工作编码时决不需要靠自己来解决。如今如果我需要对什么东西进行排序，只需调用sort（）方法即可。如果我需要一个队列或链表，只要使用所用语言本身的实现即可。这些都是已经解决好的问题。

因此，刚走出大学校门的我们认为知道如何做一切东西时，其实知道的都是已经被解决的问题。事实情况是我们只知道已被解决问题中的很少一部分。然而，我们做出像知道一切一样，自认为有完整的知识，给出的估计时间很短因为不用考虑学习的时间。

我们脆弱的自尊心也是问题的一方面。我们害怕如果估计的时间“太长”，人们就会小看我们。他们说“优秀的工程师”应该能够快速地工作，我们默许了。我一直很惊讶，当项目有了初步的估计时间后，一个非工程师人员来说这太长了。首先，正如我已经提到的，由于我们的不足，实际上很可能时间还是太少了。其次，一个非工程师人员怎么知道需要花多少时间来建造呢？这引申出了另外一个问题。

我曾经写过代码

没有比“我曾经写过代码”这样的话更能让软件工程师恼火了。无论这是来自一个产品经理、设计师或高层管理人员，除了合理的质疑为什么工程师是不对的外，说出这种话来的人只会遭人鄙视。如果我问LeBron·James［译注6］，他为一场比赛需要准备多少时间，如果我不同意他的理由是因为我在高中时打过篮球，我相信他会被逗乐的。软件工程师也都是一样的

译注5：即勒布朗·詹姆斯，NBA著名球星，人称小皇帝

下面是一些常见的谬论，是非工程师人员在我面前说的：

我不明白这为什么会是这样一个大问题。不就是几行代码吗？（从技术上来说，一切都是几行代码，这种话不会使问题变得容易或简单。）

{请对号入座}说，这个可以在一两天内完成。（这是因为{请对号入座}已经拥有完整的解决方案的知识。我没有，我需要先学习。）

我们能做些什么能使这个建造得更快些？你需要更多的工程师吗？（在一个问题上投入更多的工程师，往往会使情况变得更糟。快速建造东西的唯一方法是建造一个小点的东西。）

你能做到的最糟糕的事情是告诉他们你曾经写过代码。请注意，这实际上和一个专业的软件工程师是非常不同的。工程师转行做产品经理，在一段有限的时间内还是有些可信的（通常约为5年，大于这个时间则一切都已经完全改变了）。但是，那些从来没有专业地开发过软件的人，最好还是偷偷地保持编码的爱好吧，而不是在企业里面使用它来为你争论一切。

（说句公道话，对于设计师们也是有这个问题的。每个人都是业余的视觉设计爱好者，因为我们都喜欢漂亮的东西，但并不是每个人都有资格来设计东西的。）

更多的厨师

软件工程师也经常面临厨房里有太多的厨师的问题。因为我们低估了完成任务需要花费多长时间，大多数软件都会延迟交付。这对大公司和小公司、你知道的和喜欢的产品都是适用的，他们都属于这一类。延迟交付会让管理者不高兴，他们通常觉得问题是工程师太少了。他们说将会雇用更多的工程师，这会使一切变得更加美好。

在某些情况下，再多增加几个工程师是有效果的。但在大多数情况下，增加更多的工程师，只会使问题变得更糟。让富有创造力的人互相协调配合已经够难的了，你再添加更多的人进来只会变得更加困难。一般地，工程师是不允许有空闲时间的。如果管理者注意到有工程师闲着，就常常会为他们制造一些工作来。

这样的事情在几年前以一种几乎是滑稽可笑的方式发生在我身上。我们一个小团队在设计新的雅虎首页，从头开始重做。其实，我们之中的少数人能把注意力集中在构建页面依赖的底层构架上，就是一个很理想的情况了。我们把所有的都设计完了，正准备开始做原型，突然给了我们8位工程师。我们的开拔令吗？这些工程师需要立马开始为新首页编码。难题相当多，因为架构根本不存在。但工程师不能闲着，他们被分配到项目中总需要开始做一些事情。这是一个典型的鸡和蛋的问题。

在理想的世界里，我们至少先建成一个原型，然后再接受别的工程师来帮忙建造。然而在这种情况下，我们被困住了。最后我使用了从别的项目拿过来的已有架构，创建一个很弱的模型，使它看起来好像实际的架构存在一样。工程师们能够停止他们手中的工作，同时我们能够建造实际的架构。这是对恐怖问题的恐怖解决方案，这最终会刺痛我们，因为工程师最终会碰到目前并不存在的新架构功能的条条框框。最后在某个时候，我不得不告诉我的经理，如果不给我们时间建造实际的架构，空中楼阁是会倒塌的。

一个项目有太多的工程师，是一个严重的问题。添加更多的工程师就是在假定有并行任务需要完成，但在现实中，任何一个项目的并行任务数量是很小且有限的。当有更多的工程师可以使用时，很多工程时间就会从开发转向规划、同步和协调。回到我刚才的比喻，在第一层楼建成前你是无法建造第二层楼的。实际上许多软件项目的任务是连续的，因此增加更多的工程师并不会加快速度。或像我以前的一个同事经常说的，不管你给我多少个女人，要生小孩仍然需要九个月的时间。

真正暴躁

所以，没有足够的信息、不断变化的需求、没有足够的知识来完成这项工作及另外人们不断猜疑我们，导致我们每天都在吃力地工作。作为创意人，我们容忍了所有这一切，因为我们知道有一天人们会用我们的作品。这是最主要的真正驱动软件工程师的动力：甚至我们不认识的人都会受到我们作品的影响。无论你是在做一个每天有百万级访问人数的网站，抑或是为餐馆做一个销售点系统，影响人们生活的知识是强大的驱动力。

由于人们改变他们的想法导致有延误时，我们会变得非常暴躁。发神经似地暴躁。我们在人们面前的工作目标已被推迟，这是令人泄气的。令人惊讶的是，软件工程师通常不是完美主义者。我们通常对有些东西好了就行，而不是要非常好。我们喜欢先快速地发布一些小东西，然后晚些时再把它们组合成一个大东西。为什么？因为这就是我们如何把产品给人们的。

现在，我们都知道延误和其他东西一样都是软件的一部分。估计的时间不够时，工程师们会拼命工作并完成目标。工程师不讨厌努力工作或长时间工作，我们讨厌没有取得成功。

得到了什么可以表示感谢的东西？

作为一个软件工程师，我们的工作时间线和其他人是非常不同的。通常不会是设计师或产品经理在半夜醒来，是因为产品中的一些东西出问题了（虽然，我也知道在发生这样的事情时产品经理也是希望能被通知到的）。有一次我即将下班去约会，突然被叫到办公室里，因为有个产品问题。她坐在那儿，而我在狂暴地试着解决这个问题，她最后离开前耐心地等了一个小时（我不能责怪她），留下我一人在那儿工作，我只能在即时聊天工具上和我的同事分享我的痛苦。

然而，你很少发现软件工程师会抱怨长时间的工作或者由于产品问题被叫醒。软件是我们的孩子，我们喜欢这样来关心她。这意味着，如果需要在半夜起来喂她，我们就会做。如果需要在周末额外的照顾，我们也会做，我们会面带微笑，因为我们的创造力在增长。

工程师在可以提交任务最后的代码时会特别高兴。当他们发送一封电子邮件说任务完成了准备接受评论时，我从来没有见过他们如此快活过。然而，在接下来的十分钟，这种情绪很快破灭了，人们开始对他们新创造的宝贝提交bug了。

如果你肯再想象一下，你在一个东西上工作了一天或一个星期或几个星期，然后提交了。你感到很自豪，因为你完成了任务，很可能学做了一些之前不知道的东西。你真正想要的是花点时间坐下来，欣赏你的作品一会儿。也许有人说，“干得好。”我们得到什么反馈？Bugs。有些东西无法工作，另外有些错位了等等。我们的好心情被破坏了，我们仓促地进入了修复模式。

为什么我们说“不”

鉴于我已经提到的一切，下面是工程师说为什么说“不”（或是脾气暴躁）的常见原因：

需求在开发过程中姗姗来迟，在Deadline前没有足够的时间来适应。

需求导致早期过程中为了推进项目而做的一个或多个设想变得无效。

需求和先前的要求相反。

需求在其他方面增加了工作量，而且在Deadline之前必须要完成。

我们是如此的精疲力竭，任何需求看起来都像是大量的工作，我们就是不想做这个。

请记住，除了最后一项，所有这些工程师要做的都要赶上Deadline，以便完成项目。只有在我们工作的时候任务不发生改变，我们才会想把它做完。当他们发生改变且我们真的很暴躁的时候，“不”字就会在你说完话前脱口而出。

关爱

那么，你的企业是如何处理这些必然会出现的暴躁呢？先回顾一下驱动工程师的东西：

有创意的

能解决问题的

人们使用我们的作品

请注意名单中缺少什么。钱。向工程师砸钱很难满足他们。这听起来是陈词滥调，但对工程师来真的不是钱的问题。钱让他们有乐趣，但我们真正感兴趣的是编码和创造。当我们能在一个健康的环境工作时，我们能在很长的一段时间内保持快乐。

那么，你如何为工程师创造一个健康的环境？

交叉工作职责

软件工程师就像产品经理和设计师一样富有创造力，所以你在创造工作过程中要算上他们。工程师在头脑风暴会议和初始设计评审时是巨大的资产。给每一位工程师和创作团队见面的机会，让工程师直接和他们一起工作（不需要一直在一起）。总之，尽早让工程师加入到创造过程中去。没有工程师会喜欢他们不理解的从墙外扔过来的规格说明和设计稿件。

工程师们的逻辑性很强，所以参加这些早期的会议，明白需求是从哪来的，对完全地避免问题是有很大的帮助的。当工程师感觉像建造者，他们会有疑问，然后进度就慢下来了。当工程师是共同的创造者时，问题很少，因此之后的过程中延误就更少。

更重要的是，工程师们在什么是可能做到的知识方面远远领先于别人。如果考虑前端工程师，我们知道什么浏览器能够实现，远远早于产品经理和设计师知道的时候。当我们分享这个知识点时，我们实际上给了大家如何做产品的新思路，因为知道了什么是可能做到的。试想一下，如果你想创建一个照片共享网站，不知道现在可以把文件从桌面拖放到浏览器上传？［2］这对产品设计会有怎样的影响？

因此，请在早期邀请工程师加入到创作过程。让他们给你反馈，并提供什么是可以做到的信息。我们被呼来唤去的感觉越少，我们就越有可能倾听并愉快地着手工作。只要我们感觉对创造这东西有贡献时，我们就会这么做。

留出创意空间

跟着“软件工程师是创作者”这个主旋律，试着为我们提供充足的机会勇于创新。Hack日和Hack周如此受欢迎的原因：因为这是创意的发泄方式，工程师需要加油，需要重新发现自己喜爱的代码。Hack活动是工程师们可以尽情创作的时候，是摆脱了正常工作的限制的时候。

每季度的Hack日足以让人兴奋。想让人更加兴奋？给Hack日一个主题。给最具创意、最有可能推出产品的人奖励等等。总得来说就是激励软件工程师的创造力，当他们回到正式工作时，会感到神清气爽，准备再次贡献自己的创造力。

请记住在这方面工程师不是特别的。每个人创作时都需要时间。然而，据我的经验，产品经理和设计师往往更加能够体会到这一点。管理者有拓展的地方，设计师有设计峰会，但工程师往往会被遗弃。

随便说下，Hack活动不是做到这一点的唯一方式，但他们是最好的开始方式。你也可以派工程师参加会议，使他们能够保持更新技能，点燃他们的创意之火。花费公司的一丁点儿钱让工程师去买书，有助于完善他们的知识储备。让工程师表达自己对正在做的项目的想法。众所周知，Google给工程师20％的时间去从事编外项目。所有这一切对于和你的工程师建立极好的关系是非常有帮助的。

鼓励休假

我们经常进行数个小时的脑力劳动，我们需要休息。不幸的是，安排时间并不是我们很在行的。我们沉湎在工作的过程中，忘记了休假。我觉得在我职业生涯中的第一个五年里，我总共休了7天的假期。我不知道为什么，但我们对给自己腾出时间来缓解压力这种事情不大在行。这是一个问题。

工程师倦怠是很特别的问题，因为我们习惯于在项目表现为精力充沛。当倦怠变得糟糕透了，我们会离开去寻找安慰。此外，工程师将可能永远不会告诉你他们正在接近这个点，我们太自负了。在我上一个团队，我告诉工程师，请在他们第一次感到沮丧时来和我说说话。我不想让他们等到直到它变得这么大，以至于他们逃脱的唯一办法是离开。我不想让他们离开，我想让他们快乐，只有我知道他们开始不高兴了我才能帮助他们。

鼓励工程师休假。你的公司提供了一些数量的假期，所以一定要确保在一个整年中鼓励工程师们休掉这些假期。每4-5个月至少休一次。管理者是帮助完成这事的好角色，因为他们知道项目的进度。

当工程师需要定期的休息时，他们不用面对苛刻的Deadline，恢复了创造力。是的，我们仍然可能会在休假时花一些时间编码，但这是纯粹的创作，这和我们在工作中做的是相当不同的。这对重新提起精神准备下一场战斗是很重要的。

让他们写代码吧

听起来具有讽刺意味的是，很多公司雇用软件工程师，然后在实际工作中不让他们编码。替代的是他们的日子都充满了阻碍生产力的无用会议。在一般情况下，软件工程师们至少能够编码四个小时而不被中断时，他们的生产力是最高的。

如果你在编码的时候知道在一或两个小时之后有会议，就很难进入到“流”里面，因为这总会在你的脑海里。编码一个小时，停止一个小时，编码一个小时，停止一个小时等等是惊人的低产的。你不能进入“流”当中去，因为你刚开始，你就必须停止。软件工程师的大脑切换到很好的状态去编码是需要时间的。

确保你的工程师每一天至少有四个小时不间断的时间用来编码。这是更快地工作的关键所在。这似乎相当合乎逻辑：如果人们一天通常工作8小时，至少有一半的时间应该花在主要任务上。我以前觉得，我在下午1点和下午5点之间是最高产的。我知道如果每天都拥有这段时间，我可以很容易地完成任务。当这段时间开始被会议中断，我知道就不能完成更多的任务了。

此外，每周至少有一天没有会议，包括每天的站立会议。让工程师有一天能完全自己管理自己的时间，把所有的事情做完。一整天都没有被中断，完成的工作量绝对是惊人的。如果有必要，让工程师可以在家工作，以确保他们不会被中断。实际上在我的职业生涯期间我有过这样的经历，我的经理要求我每周至少两天在家工作，因为我在办公室里会被中断太多次了。结果是：我的工作完成得非常快。

表达谢意

这是可以立即做并且是完全有效果的。我前面提到的长期劳累地赶工完成任务，结果是遭受被提交bug的沮丧。我们的工程师很少有机会坐下来欣赏自己的作品，更不用说得到别人从背面拍肩膀的赞赏了。

当一位工程师完成了任务，尤其是一个漫长的任务，快速地说声谢谢是大有帮助的。即使它只是“嘿，谢谢把那完成了，我们先看看。”也足以增强面对通常会发生的bug涌现情况的防御能力了。被感激的感觉对工程师来说是很重要的，因为我们得到的大部分反馈是消极的：以bugs的形式、产品问题等等。一点点积极的反馈就能使工程师容忍其余全部的东西。

每个季度给那些做了最大影响的，或者改进最多的，或者任何其他东西的工程师加分、设立奖品。奖品甚至并不必是像iPad那样大件的和令人满意的东西（虽然我们会和其他的东西一起欣然接受），它可以是一个小小的记念品以及发封电子邮件给团队或部门，让别人也察觉到我们的努力。

请务必确保当你感谢在产品上辛勤工作的人们时不要忘记工程师。我已经参加过无数次的会议，在上面人们公开称赞产品团队或设计师在对项目的作用，从来都没有提到工程师。正是他们的血液、汗液和眼泪才把东西变成真实的。每一个产品是成功还是失败归根于所有三组人员，没有一组可以单独做到这一点。确保公司始终把团队当作一个整体，而不是一个特别的角色。

总结

我们软件工程师是一个有趣的群体。我们有一定的个性，我们要做最出色的东西。如果停止把我们当作“临时工”，开始把我们看作创作过程的一部分，你很可能得到更多，另外项目也会比你想象得更快推进。由于不理解工程师的心态和是什么在驱动他们，我工作过的团队都有不同程度的摩擦。我真诚地希望本文将更好地引导工程师及和他们一起工作的人之间的沟通。这真的没有那么难。我们都想觉得自己是解决问题的一部分，而不是一只小工蜂。