前不久，Jenna Bilotta 发表了一篇优秀的文章叫做，设计师和工程师怎样才能相处融洽，文中她讨论了设计师和工程师更加高效工程的方法。与设计师工作时我面临着同样的挑战（以及我在担当UI工作时，面临着与工程师一起工作的挑战），我很是赞赏她推荐的使用方法。在与他人一起工作时，尊重他人角色的作用和了解他们的想法通常会产生促进作用。
她对工程师们提出的观点之一是不要很快的说“不”。这个观点使我纠结了一段时间，时常徘徊在我脑海中。我的第一反映是，“但是你了解为什么我们会说不吗！”。并且诸多的的自我辩护的想法又浮现在我脑海中。当然，她是对的，我们确实会很快的说不，不单单是对设计师，也包括所有事情。这使我考虑起软件工程师的心理以及是什么导致我们会有如此的反应。
我们的名声（Our reputation）
坦白的讲，软件工程师以自大自傲，难相处和容易生气而出名。我们同时也因惯于说“不”，争辩于迂腐的细节，并且认为自己了解如何比其他人更好的完成他们的工作而出名。一般说来，这样的名声确实如此。当我们边写代码边浏览Twitter和Hack消息时，我们确实日复一日都在表现的如此。
（边注：有一些人会说并不是所有的工程师都如此，是的你们是对的。对于有一小部分的工程师来说，这些名声的一部分或全都对于他们来说是不正确的。在跳到本文底部并且留言告诉我说这篇文章是多么愚蠢之前，请继续往下读。）
名声不会无端授予，它们是基于经验获取的。这些名声令我不安，因为我私下认识许多软件工程师，并且他们通常都是一群风趣，和蔼可亲的（如果不是固执己见的），令人愉快的人。所以为什么在工作中的表现，却展现出一个完全不同的个性？
创造者，不是施工者（Creators，not builders）
我有一个理论。这个理论是软件工程师们将他们自己和与之工作的人看作是完全不同的人。这是我在软件行业里的大公司或小公司工作逾十多年后得出的结论。公司里（产品经理，设计师，其他管理者）趋向把软件工程师看作是施工者。产品经理的职责是想出要构建什么产品，设计师的工作是如何令产品让人赏心悦目，工程师的工作是将他们的设计付诸实践。基本上，工程师都被看作是产业里的快餐厨师（short-order cooks）。
我起初的经理警告我一些事情。当我工作的第一家公司破产后，关于我的职业他和我有一个很坦诚的讨论。虽然我们相处的并不是很融洽，但是他给了我这条极佳的忠告（解述）：
Nicholas，你比你的代码更加有价值。无论你的下一份工作是什么，确信你不是一个快餐厨师。不要去接受
一份只会告之你要去做什么和如何去做的工作。你需要工作在一个赞赏你的产品见解和构建能力的地方。
他是完全正确的。有许多公司需要的只是快餐工人，他们需要实现者和施工者以特定的节奏前进并且要排成一队。实际上，我想说的是多数的公司都向那样，无论是大公司还是小公司。我无法告诉你有多少个初创公司联系我，提供股权以换取构建创始人的远景。这暗示着：我们已将设计好了一个蓝图，我们仅需要一些人来构建它。
但是这正是问题的关键：软件工程师不是施工者。软件工程师是创造者。施工是当你从宜家买来一件家具，之后把它弄到家才进行的工作。说明书都安排好了并且如果你按部就班的做下去，你将会获得你想要的那张滑稽的小桌子。创造是一个完全不同的过程，它是在没有指导或说明的情况下产生出某些东西。它始于一个空白的画布，之后绘画产生一副佳作。软件工程师不会因为某人告诉他们要做什么才投入进行编码，他们是因为发现他们可以创造出一些有用的东西才投入编码。每个软件工程师都深爱着编程，因为他们早前编写出了一些小而有用的程序并且被吸引住了。
在软件业的三巨头中，产品经理，设计师，和软件工程师，只有软件工程师被要求打消他们的创意，只要生产就是了。软件工程师不是哑巴，他们看到了所发生的一切，愤愤得开始从事生产（这不是含沙射影）。工程师们想成为创造性过程的一部分，但却被拒之门外。这样你们最终面对的是典型的带有暴躁口音的工程师个性。
等下，有什么问题？（Wait，what's the problem ?）
产品经理是一些有趣的人。他们的对于理解市场的想法和能力真是令人印象深刻。他们也倾向于相信自己的观点是完整成型的，事实上这些观点却存在着可以让火车都能穿过的漏洞。我是出于友善才说这些的，因为我的几个朋友都是产品经理，并且你们都知道我一次又一次的当面说出了这些话。这完全不是在指责产品经理，这些只不过是他们天性使然。他们的工作是富有创造性的，并且创意会不成型的出现。而且这就是让工程师变得暴躁的部分原因。
工程师和产品经理都倾向错误的认为产品说明或需求就像是宜家的家具说明书一样。而实际上，这些文档中很少包含足够的构建一个实际产品的信息。它们通常仅仅是切入点而以。然而这给工程师造成了一个独特的问题。
为了弄清这个问题，细想一下建造房子的工作。一些人已经决定他们想要在一块指定的地块上盖房屋。房屋是两层的并且带有一间车库。甚至还有一份胡乱写在餐巾纸上的房屋正面的草图。这个人拿着这些信息和那份草图找你说：“这些信息对你建造房子足够了，对吧？”你能开始施工了吗？
理论来说，在那个阶段你还不能开始建造这所房子。你不知道施工面积。你没有楼层平面图。你不了解这座城市关于新房屋所需的一系列的规范。你简直没有足够的信息来开始挖土。在这个阶段，你会告诉你的客户，他们真疯狂，他们需要精准的设计出到底想要什么。现在想象你不能那样做，因为某些人已经规定了截止日期并且你负责准时完成。
“好吧，”你的客户告诉你，“为什么你不能先开始施工呢，当信息清晰时我会给你这些细节的。这么做，我们不会浪费任何时间。”
你清楚你没有足够的信息来施工，并且进一步询问你的客户现在也不会获得任何其他信息。然而，你要按期完成，所以你真的不能闲坐着等待更多的信息。你该怎么做？你开始做假设。
古语有言，“when you assume，you make an ass of u and me,”真是再正确不过了。假设通常很危险并且经常是错误的。然而在不做假设的情况下，这个工程就不能向前推进。所以你就开始做假设了。你开始假设你已经知道的都是正确的，这座房子会有两层和一间车库。车库，它应该是连接式的还是独立式的？它应该多大呢？好吧，让我们简单点，比如车库是独立式的，容纳一辆汽车。这意味着你可以在一旁以独立结构方式建造车库，之后当有更多关于房子的细节时，你可以继续在车库旁边建造这所房子。
经过一个星期的车库工作之后，你的客户涌现了更多的细节。实际上，房子应该有三层（唷，还好你没开始盖房子）并且有八间浴室。关于车库仍没有更多的信息，但是房子应该是漆成绿色。你之后很自然的假定这个分离的车库也应该被漆成绿色，所以你下次会花时间这么做。
几天之后，这个车库几乎完成了。你对车库的质量感到十分高兴，因为你是在那么少的信息下把它造成的。你现在准备着手盖房子，这时你得客户回来告诉了你更多细节。车库实际需要容纳两辆汽车并且不应该是分离式的。你的心一沉，因为你创造了一些好的东西，但是现在要被推倒来为这些“真正的”东西让步。更加糟糕的是，你现在没有更多的时间来完成整个工程，这只会增加工程师的暴躁级别。
如果这个类比在你看来很疯狂的话，那只能说明你从没有以软件工程师的角色工作过。这是我们每天都要面对的现实。我们努力尝试利用我们的创造力来保持项目向前推进，但却发现我们实际上没有读懂任何人的想法，并且因此错误的猜想我们究竟是在建造什么。然而，如果我们不那么做，我们会坐在那里无所事事，因为没有人喜欢软件开发中的瀑布流程。
在几乎所有其它制造产业中，预计所有的需求和细节在动工之前都达成了一致并且定案。除了在软件行业。在软件行业中，没有“足够的时间”来提前收集所有的需求。从一开始，快速前进的重要性就灌输到我们的脑海中。所以工程师们学着填补产品经理留下的缺口，目的是为了保证项目推进。当然，产品经理也因经常性的变更的想法而出名，这意味着工程师的假设通常会在整个项目流程中半途而废。
软件工程师很快会筋疲力尽并且经常性的更换工作，这还会有什么奇怪吗？
第一优先级（Number one priorities）
任何创建者的敌人是上下文的变更。一旦你深深的进入创造模式，也有人称之为“流”，被打扰以至于完全转移注意力到其它事情，会阻断这个创造的过程。是的，写代码也是一个创造的过程。它同时是一个逻辑性和创造性的过程。我们不是简单的写代码，我们是在精雕细琢代码。
对于管理工程师时间的人们来说似乎存在一种观点，工程师很容易从一项工作转换到下一项。毕竟，正如一些人告诉给我的，工作就是工作。你只要指挥他们到该去的地方就可以了，就像指挥大炮开火一样。当然，那是不真实的，如果你在一项任务上花费了很多时间，之后被要求放弃它来从事其它任务，你不会轻易的回到你得第一项任务并且很容易的从你中断的地方重新开始。一旦你返回来确保你了解所有的环境，就会有一个重新适应的阶段，这就是环境切换的代价。尽管是项仅需要几分钟就可以完成的新任务，也足够打断之前的工作流程，并导致工程师的生产力更加低下。
这是最令工程师生气的几件事之一：经常性的变更优先级。如果一天中的某件事是首要任务，另件事是次日的首要任务，这意味着会发生不可避免的环境切换。创造型的工作在它们完成之前是不应该被中断的，这也是为什么工程师喜欢持续编码到凌晨，只是为了完成他们一直都在做的东西。打断这个流会使我们生产力更加低下。
真正的优先级不是短暂的，他们是静态的。我们头上的的管理者变更想法的频率令工程师十分沮丧。我们时常准备投入战斗并且只希望有一个前进的方向。但是如果你告诉我某天我们盖房子，次日我们造汽车，那么你可以预料到来自队伍中一些人的争吵。
工程师的缺点（The engineer flaw）
软件工程师每天都会被安排到不同的岗位，但是我们不是受害者，尽管我们我们这些人常常会很夸张的表现为受害者的样子。我们部分的暴躁实际上来自于我们自身内部，由于某种原因而根深蒂固的存在于大多数工程师身上。我们有一种悲剧性的缺点，这个缺点是我们高估了我们的知识和能力。
这种缺点以多种方式展现出来。最常见的是对于时间的估算。几乎所有我知道的工程师都会低估完成一项或一系列任务所需的时间。只有最出色的工程师才能够给出和满足精准的估算时间，然而剩下的人有时会因为两个或多个原因中的一个而未能如期完成。问题在于，作为一个富有创造性的人来说，软件工程师未能预见他们所要遇到的问题。
虽然许多工程师会抱怨产品经理改变了想法，但是几乎没有人会为他们所估计的时间而负责。在会议上没有时间仔细核实需求并作出调整。至于涉及到Bugs？我们的代码是完美的，绝不会有任何bugs，所以我们不用担心bugs（毕竟，QA会抓住任何我们所遗漏的东西，对不对？）。一些我们依赖的工程师会辞职？那没问题，其他人会力挽狂澜。
所有这些很快成为未按时交工的因素，但是在所有未能按时完成的原因中，没有哪个会比这个第一原因造成的伤害更大：没有考虑学习时间的因素。这就又直接回到我们的缺点。我们认为我们已经知道了如何完成分配给我们的任务，然而常常会有一些我们之前从未做过的事情。评估的时间反映的是一个良好的知识状态，在这种状态下你就像手握宜家的手册向前开路一样。现实中，许多任务都要求我们做之前没有做过的事情。
计算机科学的程序设计课程不是为了让你为将来在行业中所要面对的任务做准备的。它们是为了教给你广泛的话题背后的概念性知识，为的是你在工作中碰到它们时不会傻了眼。你学习变量，函数，对象，因为这些是你一直都会遇见的东西。你按常规学习方式学习的数据库和查询语句几乎无用。你大量过度的花费时间在排序算法和数据结构上，这些与你你专门写代码时是相脱离的。简而言之，计算机科学程序设计课程回顾一些问题的解决方案，这些问题在你专门从事编码工作时是不会遇到的。如果现在我需要对一些东西执行排序操作，我只要调用sort（）方法，如果我需要一个队列和链表，我会使用我当前正在使用的本地语言的实现。这些都是已经解决的问题。
所以当我们从学校毕业了，认为我们知道所有事情的解决办法，然而事实上此刻我们只知道一些已被解决问题的解决办法。也因为如此，我们只知道一些已被解决问题的很小的一部分。然而我们表现的却好像我们知道所有，拥有令人骄傲的完美的知识，做出如此短的估算时间，是因为根本没有考虑学习时间。
问题的一部分也源于我们脆弱的自尊心。我们担心如果我们给出的估算时间太长的话，其他人会轻视我们。他们说“优秀的工程师”应该工作的更快，所以我们也就默许了。我经常惊讶于当制定一个项目的最初估算时间后，一个非工程师的人会返回告诉说这个时间太长了。首先，正如我已经提到的，由于我们的自身缺点，可能这个估算时间实际上是很短的。其次，怎么一个非工程师的人会知道一个工程所花费的时间？这就引发了另一个问题。
我过去写过代码（I used to code）
有几个更令工程师恼火的短语，“我过去写过代码”。不管是出自产品经理，设计师，或上级管理者的口中，除了合理的指出为什么工程师是错的，那么使用这个句子只会导致鄙视。假设如果我问勒布朗詹姆斯他需要花费多少时间来准备一场比赛，我敢肯定如果我只因为自己高中打过篮球而和他争执的话，他一定会被逗笑。软件工程师同样也是如此。
这有一些非工程师的人在我面前使用的谬论：
我不明白为什么这是一个这么大的问题。难道几行代码还不能搞定它？ （技术上讲，所有的东西都是几行代码的事儿。这种论调不会使得问题变得容易或简单。） {XXX} 人说这个问题几天就可以搞定。（因为 XXX 人已经有良好的解决问题的知识。我没有，我首先需要学习。） 我们怎么做才能更快点？你需要更多的工程师吗？（在一个问题上丢上去更多的工程师通常会使事情变得更糟。更快的造出某个东西的唯一办法是使这个东西更加简单化。）对工程师做的最糟糕的事，是你告诉他们你过去编写过代码。注意这与已经成为专业的软件工程师比较来说是十分不同的。一位由工程师而来的产品经理，在他换工作后的几年时间内自会有一些可信度（通常是5年，超过这个时间一切都已经完全变了）。但是这些从来没有专业从事软件开发的人，最好将他们的业余编码爱好藏在自己的口袋里，而不要以此作为在工作中进行争辩的依据。
（公平的说，设计师也同样遭受着这个问题。每个人都有一个视觉设计的爱好，因为我们都喜欢可爱的东西。这不等同每个人都能有资格去设计东西。）
更多的厨师（More cooks）
软件工程师也常常面临着一个厨房中有太多厨师的问题。因为我们了解完成任务所花费的时间，多数的软件都是延期的。所有的大小公司，你所熟知和喜爱的产品都是这种情况，它们都属于一类。延期使得管理者不高兴，他们会将问题归咎于工程师太少了。他们会说，我们只要雇佣更多的工程师，情况便会好转。
某些情况下，多添加几个工程师会起作用。大多数情况下，增加更多的工程师只会使问题更加糟糕。协调这些有创意的人已经是很困难了，当你增加更多的人进来时会变得更加困难。一般说来工程师是不允许有空闲时间的。如果管理者发现工程师空闲了，他们更趋向于为其创造工作。
这种情况在几年前以近乎滑稽的方式发生在我身上。我们正在设计新的雅虎首页，从头构建它，我们只有一小组的人。实际上这是一个理想的情况，很少有人能够专注于构建页面的基础架构。我们基本上已经完成设计，准备开始原型设计，突然这时给力我们8位工程师。我们的出发令到了吗？这些工程师现在需要立即开始编码。这真是个难题，因为架构还未产生。但是这些工程师们不能够闲着，他们被分配到项目来是需要开始做事情的。这是一个经典的鸡与蛋的问题。
在理想世界中，我们至少应该已经完成架构的原型设计，之后接收额外的工程师来帮助构建。然而在这种情况下，我们卡壳了。最终我是使用了一个已经存在的架构，它是我们从另一个项目中拿过来的，我们简单的对其做了些修饰让它看起来就像我们真正存在的架构一样。这些工程师们能够停止他们的工作，同时我们能够着手构建我们真实的架构。这是恐怖问题的恐怖解决方案，之后以我们的刺痛为告终，因为工程师们到达了修饰的边缘，新的架构功能应该出现但却没有出现。我最后不得不在某处告诉我得经理，除非他给我足够的时间来搭建真正的架构，否则我们搭建的卡片房子将会摇摇欲坠。
在一个项目中有太多的工程师是一个严重的问题。添加更多的工程师是假设有许多平行的工作要完成，但是实际上，任何一个项目中的平行工作的数量是很小且有限的。当有更多的工程师可用时，工程时间会从开发划分为计划，同步和协调。回到我们之前的比喻上，在第一层楼没盖好之前你是不能建造第二层的。许多软件项目的工作实际上都是串行的，所以增加工程师并不会加快项目进度。或者正如我先前的同事所说：不管你给我找多少个女人，生孩子仍旧要花九个月。
真怒了（Real grumpiness）
所以，没有足够信息，改变需求，工作的知识储备不足，人们不断的猜测我们，我们每天都步履维艰。为成为一个创造性的人，我们忍受了所有的这一切，因为我们知道有一天大众会使用我们的产品。有一信念比其它任何事都能驱动软件工程师：我们甚至都不认识的人会被我们的产品所影响。不管你是否在做了一个每天都会被上百万人浏览的网站，或者是做一个餐厅销售点的系统，这种我们影响了别人的生活的认识是一种极大的驱动力。
当因为某人的想法变更而造成延期时，我们会很恼怒。相当的恼怒。将我们的工作成果展现在大众面前的目标被延误了，这令人十分沮丧。令人惊讶的是，软件工程师通常都不是完美主义者。当东西能在那正常运转时，我们通常就觉得很好，而不会使其运转极佳才罢休。我们喜欢搭建一些小的东西迅速过度，之后将它们与大的东西相互联系。为什么呢？因为这是我们向大众展现我们工作成果的方式。
现在我们都知道延期是和其它东西一样都是软件的组成部分。如果工程师们估算的时间即将到达时，他们将会疯狂的工作以完成预期目标。工程师们不反感辛苦的长时间的工作；我们只会因工作没有回报时才开始反感。
感谢什么呢？（What thanks ? ）
作为一名软件工程师，我们的工作在十分不同的时间线上，这超过其他人。通常设计师或产品经理不会在午夜醒来，只是因为产品出了问题（虽然，我知道有些产品经理希望发生这些事时能够叫上他们）。我有一次正准备下班出去约会，这时办公室打电话给我，因为产品出了点问题。她坐着并耐心的等了我一个小时，而我却在试图疯狂的把解决问题，她最终离开了（我不能怪她），把我丢在了我的工作上，我在网上和我的同事倾诉我的痛苦。
然而，你很少发现软件工程师会抱怨长时间的工作或因为产品问题而被叫醒。软件是我们的孩子，我们乐意去那样照看他。这意味着如果他需要在午夜喂养，我们就会去做。如果他周末期间需要额外照顾，我们也会做，我们都面带微笑接受所有这些，因为我们的创作正在成长。
当工程师们能够提交一项任务的最后一点代码时，他们会尤其高兴。当工程师们发送邮件告之任务已经完成可以准备复审时，我从没有见过他们是如此的欢快。但是接下来的十分钟，当开始提交不利于他们新创造的baby的bugs时，这种情绪会迅速破灭。
如果你愿意，你花几秒钟可以想象一下这个过程。你花费了一天，或一周或好几周来做某个东西，之后提交。你很骄傲，因为你已完成任务，可能还学习了一些之前你不知道的知识。所有你想做的就是休息一会儿，欣赏一下你得工作成果。可能有人会说，“干得漂亮”。那么我们得到的反馈是什么？Bugs。有些东西不工作了，其它的东西错位了，等等。我们匆匆忙忙的跑去修复，所有的好情绪完全被毁灭掉了。
我们为什么说“不”（Why we say "no"）
考虑一下所有我已经提到的，这有几条工程师为什么说“不”（或看起来暴躁）的常见原因：
需求在开发阶段姗姗来迟，在截止日期之前没有足够的时间搞定它。 需求废弃了我们之前因为要推进项目而做出的一个或多个假设。 新需求有悖于原来的需求。 需求增加了工作量，这些需要在截止日期前做完。 我们筋疲力尽了，所有的需求貌似都是繁重的额外工作，我们不想再去处理它了。 记住除了最后一个原因外，其它所有原因都与工程师要赶上截止日期以让项目上线有关。我们希望完成工作，但是唯一的办法是我们在完成任务的过程中，任务本身不要反生变化。当它们确实改变了，那我们就真的生气了，在你话音未落之前，“不”就从我们的嘴里飞出来了。
关怀和犒劳（Care and feeding）
这些你企业中必不可少的脾气暴躁的人，你如何处理呢？回顾一下驱动工程师的几件事：
成为有创造力的人 解决问题 大众使用我们的产品注意这个清单中遗漏了什么。金钱。向工程师丢钱很少会满足他们。听起来很迂腐，但是对于工程师来说钱并不是主要问题。钱会使他们拥有乐趣，但是我们真正感兴趣的是编码和创造。当我们不能在一个健全的环境中做到这些，我们在很长一段时间内仍旧会不高兴。
所以怎样为工程师们创造一个健全的环境呢？
跨职能工作（Work cross-functionally）
软件工程师是有创造性的，就像产品经理和设计师一样，那么在创造性的过程中你应该把他们融入进来。工程师会在集思会议和重审初始设计上发挥巨大作用。要为工程师提供机会，来和这些构思团队碰面并且直接一起工作（并不必须一直这样）。简单讲，要尽早的将工程师注入到这个创造性的过程中。没有工程师喜欢拿到从墙上丢过来的手册和设计稿，但却并不了解这些东西。
工程师的逻辑性很高，所以参加早期的会议来了解需求的出处，大大有助于彻底避免问题。当工程师感觉自己像施工者一样时，他们就会询问，这会减缓这个过程。当工程师是共同创建者时，很少会产生问题，因此之后的过程也很少会有延误的情况。
更重要的是，工程师们常常比其他人更加提前知道什么知识是可用的。想象一下前端工程师，较产品经理和设计师，我们了解浏览器的兼容性。当我们在分享这些知识时，我们实际上为所有人提供如何构建产品的新想法，因为我们了解什么是可能做到的。试想你打算创建一个分享相片的站点，但你不知道现在可以通过从桌面拖拽文件到浏览器的方式来上传文件？[2]这将会对你的产品设计产生怎样的影响呢？
所以，在早期就要邀请工程师参与创造过程。让他们给你反馈，提供关可以做什么的信息。我们被呼来唤去的感觉越少，我们就越喜欢倾听并且高兴的从事我们的工作。只有感觉到我们为了创造这个东西做出了贡献，才能真正发生上面提及的情况。
留出创作空间（Make a creative space）
跟随软件工程师就是创造者的主题，试着为我们提供丰富的创造机会。这也是为什么hack日和hack周如此之流行的原因——因为这是工程师们需要加油和再发现他们对代码狂热的创意爆发口。Hack竞赛的时间里，工程师能够完全发挥创造性，摆脱他们日常工作的约束。
每个季度的hack日使人们十分兴奋。想要让人更加兴奋吗？那么给hack日一个主题吧。奖励那些最具创意，最有可能转换产品的人，等等。重点是回馈软件工程师的创造力，以便当他们回到他们的常规工作时，他们会感到新鲜，准备再次贡献自己的力量。
记住就这点而言，工程师也没什么特殊的。人人都需要时间来进行创作。然而，在我的经历中，产品经理和设计师往往更易于获得创造时间。管理者有训练营，设计师有设计峰会，然而工程师往往被弃之一旁。
顺便说一下，hack竞赛并不是唯一可以为工程师们提供创造空间的方式，但却是一个最好的开始。你也可以派工程师去参加会议以更新他们的技术，并以此来点燃他们的创造热情。公司出钱，允许工程师购买可以提升他们知识的书籍。允许工程师表达他们对正在从事项目的想法。Google公司很好的给出工程师20%的时间来从事分支项目（side projects）。所有的这些都有助于同工程师们创建一种极佳的关系。
鼓励休假（Encourage time off）
常规情况下我们会经过长时间的脑力劳动，工程师们需要休息。不幸的是，我们也不擅长安排我们的休息时间。我们十分专注于工作，以至于我们忘了休假。在我职业生涯的前五年，我想我总共也就休了7天的假。我不知道为什么，但是我们不是很擅长为我们自己腾出时间以缓解压力。这是个问题。
工程师的疲劳很特别，因为我们习惯于快速度过疲劳。当实在疲劳时，我们会离开，缓解一下。而且，工程师可能绝不会告诉你，他们已经快到达了那种状态；我们以此为傲。在我的上一个团队中，我告诉工程师们，他们一旦受到挫折时，一定要来告诉我。我不想让他们坐等这种状态发展下去，以至于只有辞职他们才能释然。我不想然他们离去，我希望他们快乐，当我知道他们开始不高兴时，我才能帮助他们，这是唯一的办法。
鼓励工程师休假。公司给出一定数量的假期，确保工程师能够在一年之中利用这些假日。至少每隔4-5月。项目经理是非常适合做这件事，因为他们清楚项目的计划。
工程师在固定的时间间隔内休息，能够远离苛刻的截止日期，并恢复他们的创造性。是的，在我们的休假时间，我们仍喜欢写一些代码，但是这完全是我们的创意，因此十分不同于我们在工作上的作为。这对于工程师恢复精神并且准备下场战斗来说是什么重要的一部分。
让他们编码（Let'em code）
听起来可能很讽刺，许多公司雇佣软件工程师，之后不会让他们进行实际的编码。相反，他们的日子都被那些阻碍生产力的无用会议所填满。一般来讲，当软件工程师至少不间断的编码四小时，他们的生产力是最高的。
如果你知道在一个或两个小时候会有一个会议，那么你很难进入到一个好的编码流程上去，因为在编码时你总会在你脑中想着这个会议。编码一小时，停一小时，再编码一小时，再停一小时，等等，这样是十分低产的。你无法进入一个流程，当你一开始时，你不得不又结束。软件工程师的大脑不得不切换到一个好的编码状态，然而这种切换时耗时的。
确保你的工程师们每天都有至少四小时的连续编码时间。这是更快完成工作的关键。这看起来似乎很合理：如果人们每天工作八小时，那么至少一半的时间应该花费在主要任务上。我常常发现我在下午的一点到五点之间是最有效果的。我知道如果我每天都有这样的时间，我能很轻松的完成我的任务。当这个时间被会议中断时，我知道我再也不能做更多的事了。
同样，至少一周之内有一天是没有会议的。这包括日常例会。仅为了让工程师利用，完全独立安排自己的时间，处理所有的事情。如果一整天都是自由不被打扰的，我们惊讶于会有多少事情是可以被处理的呀！如果可能得话，允许工程师在家里工作，以确保他们不被打扰。在我职业生涯的一段时间内我经历了这样的事，我的经理要求我一周之内至少要在家里工作两天，因为我在办公室内经常被打断。结果就是：我很快就完成了我的工作。
表示赞许（Express appreciation）
有些事情可以立即处理，并会产生很好的效果。我之前提到了埋头苦干完成工作遇到的挫折，碰到了许多提交的bugs。我们工程师很少有机会坐下来欣赏我们的成果，更别提等到其他人的赞赏了。
当一个工程师完成了一项任务，尤其是一项长期的任务，一张表达谢意的便条会起很大的作用。尽管便条只是写到，“嗨，谢谢你完成了这项任务，我们会看一看的”，这也足够驱散当bugs涌进时工程师们通常会出现的防御性心理。感到赞赏，对于工程师来说是什么重要的，因为我们得到的多数反馈都是消极的，通常以bugs，产品问题，诸如此类的形式展现的。一点小小的积极反馈，也会使其它所有的都可以忍受。
至于奖励部分，在每个季度都设立一个奖品，授予那些影响最大，或提高最快的工程师。这些奖品甚至不一定是一些大的东西以及像iPad样令人满意的东西，它可以是一个小奖品或是发至团队或部门内部的一封认可成效的信件。
所以请确保当你在表扬大家对产品所付出的努力时，一定不要忘记工程师们。我已经参加过许多会议和许多项目，在那里人们都公开的赞扬产品团队或设计师们为项目所做的努力，但却从没有提及工程师们，是他们的心血，汗水和眼泪才使项目得以实现。每个产品的成败都取决于这三个团队，没有哪个团队可以单独肩负起一个产品的。确保你的公司一直都把他们作为一个整体，任何一个部分都不应该特殊。
结束语（Conclusion）
我们软件工程师是一群有趣的群体。我们拥有鲜明的个性，我们真正的希望做出最好的东西。如果你不在把我们看做是快餐厨师，并且开始视我们为创造性过程的一部分，你可能会得到比你想象中的更多，更快的东西。我曾经工作过的团队都有不同程度的摩擦，源起于对工程师的不理解和不明白什么是他们的驱动力。我真心希望这篇文章会引导工程师和与之工作人们间的更好的交流。真的没有那么困难。我们都是希望成为解决方案一部分的人，而不是一只工蜂。
原文链接 请保留原文链接
写在后面的：
- 个人理解：
2.为何再译：
- 算是继续锻炼英文水平和耐力吧，因为好多不错的资料都是英文的，以后免不了还会继续发现并翻译些好的文章。
- 翻译的整个过程也是一个不错的学习过程，毕竟是牛人的文章，文中的内容和观点十分值得学习。
- 虽然可能翻译的水平不咋地，但也还是愿意拿出来和大家分享一下，有不对的地儿，您也指出来，相互学习。
- 英文原文下方标注的中文翻译文档也很好，本文的一些地方也是参考其完成，但有些译处，和我理解的有些出入。
- 我的近期工作一直也围绕着界面设计的实现，也同样遇到了文中指出的问题，感同身受，可作为今后工作的指导。
1004
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
