为什么软件工程师或程序员脾气暴躁？ -Human Who Codes

通常，软件工程师通常以傲慢，不愉快和喜怒无常而著称。声誉不是随机分配的，它们是根据经验获得的。使声誉困扰我的是，我本人认识许多软件工程师，并且他们通常是爱好娱乐，乐于助人（如果不自觉的话）和娱乐性的一群。他们是您下班后想闲逛并在周末赶上去的人。那么，为什么在工作中却出现了不同的性格呢？

程序员是创造者，而不是建造或构造者
在大型和小型公司工作超过十年的软件行业后，我得出了一个结论：软件工程师对自己的看法与与他们一起工作的人截然不同。公司（产品经理，设计师，其他经理）倾向于将软件工程师视为建造者。产品经理的工作是梦见要建造的东西，设计师要使它美化，程序员工程师要建造他们想出的东西。基本上，程序员工程师被视为这个行业的短期厨师。
当我工作的第一家公司倒闭时，我和经理就我的职业进行了坦率的讨论。

尼古拉斯，您的价值要超过代码。不管您接下来的演出是什么，请确保您不是临时厨师。不要接受会告诉您确切要建造什么以及如何建造的工作。您需要在某个地方工作，以欣赏您对产品的见识以及构建产品的能力。

他是绝对正确的。有很多公司想要短期厨师，他们希望实施者和建造者按照特定的节奏行事并保持一致。实际上，我会说大多数公司都希望这样做，无论大小。我无法告诉您有多少家初创公司与我联系，提供股权以换取建立创始人的愿景。含义：我们已经弄清了所有这些，我们只需要有人来构建它。
这是问题的真正症结：软件工程师不是构建者。软件工程师是创造者。当您从宜家购买家具并将其带回家时，构造就是您要做的事情。如何构造的说明书已经有了，只要按照其说明逐步进行，您会得到想要的那个可笑的小桌子。
创建是一个不同的过程，它在没有指导或指示的情况下诞生了某些东西。它从一块空白的画布开始，然后绘制杰作。软件工程师之所以一开始不会立即涉足编码，是因为他们希望某人告诉他们该怎么做，而因为他们发现自己可以创造出有用的东西而参与其中。每个软件工程师就会都爱上了编码，因为她很早就编写了一个小巧而有用的程序，并且深深着迷。
在软件，产品经理，设计师和软件工程师的三足鼎立中，只有工程师才能放弃他们的创造力而只生产产品。软件工程师并不愚蠢，他们看到这种情况的发生，并且怨恨开始形成（没有双关语）。工程师希望成为创意过程的一部分，并被拒绝。因此，您最终会遇到脾气暴躁的典型软件工程师个性。

等等，怎么了？
产品经理是有趣的人。他们的想法和理解市场的能力令人印象深刻。他们也倾向于认为，实际上，如果存在很大的漏洞以至于火车可以通过，他们的想法才会完全形成。这绝对不是对产品经理的批评，只是他们的本性。他们的工作是富有创造力的，而想法并没有形成完整的形式。这就是使软件工程师脾气暴躁的部分原因。
工程师和产品经理都倾向于错误地认为产品规格或要求等同于宜家的家具手册。实际上，这些文档很少包含足够的信息来构建实际的东西。它们通常只是起点。这给工程师带来了一个独特的问题。
要了解该问题，请想想盖房子的工作。有人决定他们要在特定的土地上盖房子。这房子要是两层楼，有一个车库。甚至还有一张粗略的房子前部草图，然后说：“这足以让您开始构造了，对吗？”您能够开始构造吗？
从逻辑上讲，您此时无法开始建造房屋。您不知道平方英尺。您没有平面图。您不知道这座城市需要什么样的新房屋代码。字面上没有足够的信息让您甚至无法开始挖掘泥土。此时，您要告诉客户他们疯了，需要准确弄清楚他们想要什么。现在想象您不能这样做，因为有人设定了最后期限，您有责任开会。
“好吧，”您的客户告诉您，“为什么不立即开始构建，我将为您提供详细信息。这样，我们就不会浪费任何时间。”
您知道没有足够的信息来开始构建，并且进一步质疑客户现在不会产生任何其他信息。但是，您有一个限期开会，因此您真的负担不起坐下来等待更多信息的机会。你是做什么？您开始进行假设。
古老的格言“当你假设的时候，你就和你我混在一起了”，这几乎是正确的。假设很危险，而且常常是错误的。
但是，如果不做一些假设，该项目将无法进行。那就是你要做的。首先，假设您已经知道的是真实的，那所房子将有两层楼和一个车库。车库，应该安装还是分离？应该多大？好吧，让我们保持简单，并说它是分离的并且只容纳一辆汽车。这意味着您可以作为侧面的独立结构从车库开始，然后，在有关于房屋的更多详细信息时，可以在车库旁边继续。
在车库工作一个星期后，您的客户出现了更多细节。实际上，房子必须是三层楼（phe，好东西，你不是从那里开始的），并且要有八间浴室。没有关于车库的更多信息，但是房子将被漆成蓝色。然后，您从逻辑上认为独立车库也应被涂成蓝色，这就是您接下来要花费时间的地方。
几天后，车库快要用完了。您对质量感到非常满意，因为您获得的信息很少。现在，当客户返回更多详细信息时，您就可以开始工作了。车库实际上需要容纳两辆车，因此不应拆开。因为您创造了美好的事物，但您的内心深陷其中，现在需要推销它，为“真实”的事物让路。更糟糕的是，您现在没有更多的时间来完成整个项目，这只会增加工作量。
如果您觉得这种类比很疯狂，那么您可能从未以软件工程师的身份工作过。这是我们每一天的现实。我们试图通过使用创新工具来保持项目运转，只是发现我们实际上无法读懂任何人的想法，因此错误地猜测了我们正在构建的是什么。但是，如果我们不这样做，我们就会闲着，因为没人喜欢软件开发的瀑布式过程。
在几乎所有其他建筑行业中，都可以在开始建筑之前就所有要求和细节达成一致并最终确定。除软件外。在软件中，“没有足够的时间”来提前收集所有需求。从第一天起，快速行动的重要性就已经扎根于我们。因此，工程师学会填补产品经理留下的空白，只是为了保持项目的进行。当然，产品经理也因经常改变主意而享有声誉，这意味着工程师的假设经常在过程中途失效。
难怪软件工程师会很快精疲力尽并经常更换工作吗？

第一要务
任何创建者的敌人都是上下文的切换。一旦进入了深具创造力的模式，就如人们所说的那样，被“流程”干扰将注意力转移到其他事物上了，这将完全中断当前流程。是的，编写代码是一个创造性的过程。同时具有逻辑性和创造性。我们不仅在编写代码，而且还在精心设计。
管理工程师时间的人们似乎认为，从一项任务转移到另一项任务很容易。毕竟，正如某些人告诉我的那样，努力就是努力。您只需将其定向到需要加农炮和火力的地方即可。当然，那根本不是真的。如果您在一个任务上花费大量时间，然后被要求将其放到其他任务上，那么您将很难返回到第一个任务并从上次中断的地方继续工作。一旦您返回以确保您了解所有上下文，就会有一个重新适应的时期，这就是上下文切换的成本。即使完成新任务仅需几分钟，也足以中断流程并因此降低工程师的工作效率。

这是使工程师脾气暴躁的最重要的事情之一：不断改变优先级。如果某事物在一天中是第一优先级，而其他事物在第二天是第一优先级，则意味着必然发生上下文切换。创意类型不喜欢在完成之前就被打断，这就是为什么工程师乐于继续编码直到凌晨，以便完成他们正在做的工作。中断流程使我们的生产力下降。

真正的优先级不是暂时的，而是静态的。在我们职位之上的人们改变主意的频率对于软件工程师来说实在令人沮丧。我们经常随时准备进军战斗，而只是想向前进。但是，如果您有一天告诉我们我们正在建造房屋，第二天我们正在建造汽车，那么您应该期望正在此队伍中。

工程师的缺陷
软件工程师每天都处于困境中，但是即使我们中那些比较熟练的人倾向于这样做，我们也不是受害者。我们的部分脾气实际上来自内部，出于某种原因，大多数软件工程师都已根深蒂固。我们有一个悲惨的缺陷，那个缺陷是我们高估了我们的知识和能力。
此缺陷以多种方式出现。最频繁的是时间估计。我认识的几乎每个工程师都长期低估了完成一项或多项任务所需的时间。只有最优秀的人才能够给出并满足准确的时间估算，而其他人有时却相差两个或更多。问题是，作为有创造力的人，软件工程师无法预见他们将遇到的问题。
即使许多工程师会抱怨产品经理改变了主意，但几乎没有人会在他们的时间估算中做出解释。没有时间花在会议上来超过需求并进行更改。bug？我们的代码是完美的，并且从来没有错误，因此我们不必担心（毕竟，质量检查会捕获我们以某种方式错过的任何东西，对吗？）。我们依赖的其他一些工程师会退出市场吗？没关系，其他人会帮忙。
所有这些因素都会很快导致错过的最后期限，但是没有一个造成的伤害与未能按时完成任务的第一原因一样严重：没有考虑到学习的时间。这直接回到了我们的缺陷。我们认为我们已经知道如何完成给我们的任务，但是很多时候这是我们从未完成过的事情。时间估算反映出一种完美的知识状态，您可以在其中获得《宜家手册》并向前迈进。实际上，许多任务要求我们去做以前从未做过的事情。
在大学学习计算机科学的工程师在课堂上被赋予错误的安全感。当他们实际上几乎一无所知时，他们以为自己了解软件和软件开发过程而出来。我绝对是第一份工作的傲慢大学毕业生，告诉每个人他们做错了。仅仅几年后，我才发现自己一无所知。
计算机科学程序并不是要为您准备好要在行业中面临的任务做准备。它们是关于为您提供广泛主题的概念性知识，以便您在工作中找到它们时不会失明。您将了解变量，函数和对象，因为这些是您始终会遇到的事情。您将学习数据库和查询，尽管所学的常规形式实际上是无用的。您花了大量的时间在排序算法和数据结构上，而在专业编写代码时，所有这些算法和数据结构都是抽象的。简而言之，计算机科学程序会审查解决问题的解决方案，而这些问题在您进行专业编码时就不需要自己解决。如果这些天我需要排序一些东西，请调用sort()方法。如果我需要一个队列或一个链表，那么我将使用所使用语言的本地实现。这些都是已解决的问题。
因此，我们来自大学时代，我们知道如何做所有事情，而实际上我们只知道如何做已经做过的事情。为此，我们知道已经完成的工作非常少。但是，我们的行为就像我们知道的一切一样，并且假设有完善的知识，他们给出的估算值太短了，因为我们没有考虑学习时间。
问题的一部分还在于我们脆弱的自我。我们担心如果我们给出的估计值“太长”，人们就会对我们的想法减少。他们说，“好的工程师”应该能够更快地工作，所以我们默认了。当对一个项目给出初步估计而一个非工程师回来并说那太长时，我总是感到惊讶。首先，正如我已经提到的，由于我们的缺陷，它实际上可能太短了。第二，非工程师如何才能知道需要多长时间才能完成建造？这导致了另一个问题。

我曾经编码
很少有比“我以前也编写过代码”更能激怒软件工程师的短语。无论是来自产品经理，设计师还是高层管理人员，除了合理说明工程师为什么出错的原因外，使用此短语都只会导致以下结果：蔑视。
以下是非工程师在我面前说的一些常见谬论：

• 我不明白为什么这么大功能。只是几行代码吗？（从技术上讲，所有内容都是几行代码。这并不容易。）
• {在此处插入名称}表示可以在几天内完成。（这是因为{在这里插入名称）已经对解决方案有全面的了解。我没有，我需要先学习它。）
• 我们可以采取什么措施来加快速度？您是否需要更多工程师？（使更多的工程师经常遇到问题会使情况变得更糟。更快构建某些东西的唯一方法是构建一个较小的东西。）

更多厨师
软件工程师还不断面临厨房里厨师过多的问题。由于我们低估了完成任务所需的时间，因此大多数软件都已延迟。无论大小的公司，您都知道和喜爱的产品，都属于这一类。迟到会使管理人员不满意，他们通常认为问题是人太少了。他们说，我们将只雇用更多的工程师，这将使一切变得更好。
在某些情况下，可以再增加一些工程师。在大多数情况下，增加工程师人数只会使问题变得更糟。要让富有创造力的人互相协调非常困难，一旦加入更多的人就变得更加困难。通常，不允许工程师有空闲时间。如果管理层意识到工程师闲置，他们倾向于为他们创建工作。
几年前，这以一种几乎滑稽的方式发生在我身上。我们正在设计新的Yahoo主页，仅由一小部分人从头开始对其进行重建。实际上，这是一种理想的情况，我们中的少数人能够专注于应在其上构建页面的基础体系结构。我们进行了全部设计，当我们突然得到八名工程师时，准备开始进行原型设计。我们的行军命令？这些工程师需要立即开始为新主页编写代码。因为该体系结构不存在，这是一个难题。但是工程师不能闲着，他们被分配到项目中并且需要开始做一些事情。这是一个经典的鸡肉和鸡蛋问题。
在理想的情况下，我们至少应该构建该体系结构的原型，然后再聘请其他工程师来帮助构建。但是，在这种情况下，我们陷入了困境。我最终要做的是使用另一个项目中的现有架构，并创建一个薄的外观，使其看起来像我们实际的架构一样。工程师能够停止他们的工作，而我们能够同时构建实际的架构。对于可怕的问题，这是一个可怕的解决方案，但后来又困扰了我们，因为工程师到达了立面的边缘，而新建造功能最终将存在但还不存在。我最后不得不告诉我的经理，除非他给我们时间来构建实际的体系结构，否则我们建造的纸牌屋将崩溃。
一个项目中有太多的工程师是一个严重的问题。增加更多的工程师假设要完成并行任务，但实际上，任何一个项目上的并行任务数量都是有限的。当可用的工程师人数过多时，工程师的时间将最终从开发转向计划，同步和协调。回到我之前的隐喻，您必须先构建第一层，然后才能构建第二层。软件项目上的许多任务实际上是顺序的，因此增加更多的工程师并不能加快工作速度。就像我以前的一位同事曾经经常说的那样，我不在乎你给我送多少女人，还是要花9个月才能生孩子。

真正的脾气暴躁
因此，如果没有足够的信息，不断变化的要求，没有足够的知识来完成这项工作，并且人们不断地猜测我们，那么我们每天就会步履艰难。作为有创造力的人，我们忍受了所有这些，因为我们知道有一天人们会使用我们的工作。这实际上是驱动软件工程师的主要因素：我们甚至不认识的人的想法将受到我们工作的影响。无论您是在每天访问数百万人的网站上工作，还是在餐厅的销售点系统上工作，都知道我们正在影响人们的生活，这是一个强大的推动力。
当由于人们改变主意而出现延误时，我们会变得非常脾气暴躁。脾气暴躁。我们推迟在人们面前开展工作的目标，这令人沮丧。令人惊讶的是，软件工程师通常不是完美主义者。我们通常可以从那里得到一些好的东西，而不是从那里得到一些好的东西。我们喜欢构建能够快速交付的小物件，然后再将它们组合成大物件。为什么？因为这就是我们将工作推向人们的方式。
现在，我们都知道延迟与其他任何东西一样，都是软件的一部分。如果他们不花时间去尝试并使工程师工作，工程师们将疯狂地工作。工程师不讨厌辛勤工作或长时间工作。我们讨厌它没有回报。

谢谢你
作为软件工程师，我们的工作时间表与其他时间表截然不同。通常在深夜醒来的不是设计师或产品经理，因为生产中发生了一些问题。一次我正要离开办公室，因为生产问题办公室要去约会。她坐着耐心地等待了一个小时，而在我最终设法起飞之前，我疯狂地试图解决这个问题（我不能怪她）。
但是，您很少会发现软件工程师抱怨长时间工作或由于生产问题而被唤醒。该软件是我们的宝贝，我们喜欢照看它。这意味着如果它需要在深夜喂食，我们就这样做。如果周末需要额外的照顾，我们也会这样做，因为我们的创造力正在增长，所以都面带微笑。
工程师能够签入任务的最后代码时，尤其高兴。我从未见过工程师这么高兴，就像他们发送一封电子邮件说任务已完成并准备进行审查一样。
想象一下，如果可以的话。您已经在某件事上工作了一天，一周或几周，并进行了提交。您为自己感到骄傲，因为您完成了任务，可能学习了以前不知道的事情。您真正想要的只是花一点时间坐下来欣赏一下您的作品。也许有人说“干得好”。我们得到什么回应？Bug。某些功能不起作用，其他功能不正常，依此类推。当我们进入固定模式时，我们的好心情被破坏了。

为什么我们说“不”
鉴于我提到的所有内容，以下是工程师拒绝（或看上去很脾气暴躁）的常见原因：

• 该需求在开发过程中来得很晚，没有足够的时间在截止日期之前完成。
• 该需求使为使项目继续进行而在流程的早期做出的一个或多个假设无效。
• 该需求是先前需求的冲销。
• 否则，该需求会增加截止日期之前必须完成的工作量。
• 我们非常精疲力尽，任何需求似乎都需要大量额外工作，而我们只是不想处理它。

护理和喂养
那么，您如何处理业务中这些脾气暴躁的必需品呢？回顾一下推动工程师发展的因素：

• 有创意
• 解决问题
• 人们使用我们的工作

跨职能工作
就像产品经理和设计师一样，软件工程师是富有创造力的，因此您应该努力将它们纳入创作过程。在集思广益会议和审查初始设计时，工程师是宝贵的资产。让每个工程师都有机会与构想团队会面并直接与他们合作（不一定要同时全部工作）。简而言之，请尽早将工程师注入到创作过程中。没有工程师不喜欢在不了解规范和设计的情况下把它们扔在墙上。
工程师具有很高的逻辑性，因此在这些早期会议中了解需求的来源可以大大避免产生问题。当工程师觉得自己像建造者时，他们会提出质疑，这会拖慢整个过程。当工程师是共同创作者时，问题会更少，因此流程后期的延迟也更少。
此外，工程师在可能的知识方面经常遥遥领先。如果您考虑使用前端工程师，那么我们比产品经理和设计人员早就具备了什么样的浏览器功能。当我们共享这些知识时，实际上，由于可能，我们实际上会给每个人关于如何构建产品的新想法。想象一下，如果您试图创建一个照片共享站点，却不知道现在可以将文件从桌面拖放到浏览器中进行上传？2这将如何影响产品设计？
因此，请尽早邀请工程师参与创作过程。让他们给您反馈并提供有关可能的信息。受到命令的感觉越少，我们就越有可能倾听并乐于完成工作。只有当我们觉得我们为创造这个东西做出了贡献时，这才真正发生。

创造空间
遵循软件工程师作为创造者的主题，尝试为我们提供足够的创造力。黑客日和黑客周之所以如此受欢迎是有原因的–这是因为这是工程师需要加油并重新发现对代码的热爱的创造性渠道。黑客事件是工程师可以完全发挥创造力，摆脱常规工作约束的时候。
每个季度的黑客日足以使人们兴奋。想让人们更加兴奋吗？给黑客天一个主题。为最有创意，最有可能运送的产品提供奖励，依此类推。关键是要养活软件工程师的创造力，这样，当他们回到正常的工作中时，他们会感到精神焕发并准备再次做出贡献。
请记住，工程师在这方面并不特殊。每个人都需要时间来发挥创造力。但是，以我的经验，产品经理和设计师往往会更频繁地获得这些东西。对于设计师来说，在场外有管理和设计峰会，但工程师往往被排除在外。
顺便说一句，黑客事件并不是做到这一点的唯一方法，但它们是入门的最佳方法。您还可以通过派工程师参加会议来点燃创造力，使他们可以保持最新技能。允许工程师购买对公司有用的书籍。允许工程师表达他们对正在进行的项目的想法。众所周知，Google为工程师提供了20％的时间从事辅助项目。所有这些都可以大大有助于与您的工程师建立良好的关系。

鼓励休息
由于我们会定期进行大量的时间和智力锻炼，因此工程师需要休息一下。不幸的是，这也是我们在调度方面不太擅长的事情。我们被整个过程所困扰，以至于忘了去度假。在我职业生涯的前五年，我认为我总共休了7天的假期。我不知道为什么，但是我们不太擅长抽时间让自己减压。那是个问题。
工程师的倦怠是独特的，因为我们习惯于通过它进行供电。当倦怠变得足够严重时，我们离开，寻求缓解。而且，工程师可能永远也不会告诉您他们正在接近这一点。我们为此感到自豪。在我的上一个团队中，我告诉工程师，他们第一次感到沮丧，就来找我说话。我不希望他们等到变得如此之大以至于他们逃脱的唯一方法就是离开。我不希望他们离开，我希望他们幸福，而我唯一能帮助的方法是，如果我知道他们开始不幸福。
鼓励工程师请假。贵公司会给您一些假期，因此请确保鼓励工程师使用全年的假期。至少每4-5个月一次。经理们很容易为此提供帮助，因为他们知道项目进度表。
当工程师定期休息时，它将使他们脱离严格的期限来恢复他们的创造力。是的，我们可能仍会在放假时进行某种编码，但这将完全是我们的创造，因此与我们在工作中的工作有很大不同。这是刷新并为下一场战斗做好准备的重要部分。

让他们编写代码
听起来可能具有讽刺意味，但许多公司雇用软件工程师，他们的日子充斥着无用的会议，然后才让他们实际进行编码，影响了生产力。通常，软件工程师可以连续至少四个小时编写代码而不会受到干扰，因此这段时间他们的生产力最高。
如果您知道一个小时或两个小时内要召开会议，那么在编码时就很难进入良好的流程，这在编码时始终在您的脑海中。编码一个小时，停止一个小时，编码一个小时，停止一个小时等等，这简直是徒劳的。您无法进入流程，就像开始一样，必须停止。软件工程师的大脑必须切换到良好的编码模式，因为这种切换需要时间。
确保工程师每天至少有四个小时的不间断编码时间。这是使工作更快完成的关键。这似乎是合乎逻辑的：如果人们通常每天工作八小时，则至少应将一半时间用于主要任务。我曾经发现我在下午1点到5点之间的工作效率最高。我知道，如果每天都有时间，我可以轻松完成任务。当那段时间开始被会议打断时，我知道我不会做太多事情。
另外，每周至少需要一天没有开会。这包括每日站立。只是让工程师们有一天可以完全自己管理时间并完成所有工作。一整天不间断地完成了多少工作，这绝对令人惊讶。如有必要，允许工程师在家工作以确保他们不被打扰。实际上，我经历了一段职业生涯，期间经理要求我每周至少两天在家工作，因为我在办公室经常被打扰。结果：我很快完成了工作。

表达赞赏
这是可以立即完成并且完全有效的。前面我提到过辛苦地完成任务，但遇到的错误却使它感到沮丧。我们的工程师很少有机会坐下来欣赏我们的工作，更别说得到别人的支持了。
当工程师完成一项任务，尤其是一项漫长的任务时，简短地说声感谢将大有帮助。即使只是，“嘿，感谢您完成此操作。我们来看看。”足以分散漏洞开始泛滥时通常发生的防御性。感到赞赏对软件工程师很重要，因为我们得到的大多数反馈都是错误的，包括错误，生产问题，等等。一点点积极的反馈使其余的一切都可以容忍。
对于奖励积分，设置一个奖项，该奖项每季度颁发给对影响力最大或改善最大的工程师。该奖项甚至不必像iPad那样大而可取（尽管我们很乐意接受它以及其他礼物），它可能是一个小小的奖杯，并向团队或部门发了一封电子邮件，以表彰其努力。
并且，当您感谢人们在产品上的辛勤工作时，请确保不要忘记工程师。我参加过无数次会议和许多项目，在这些会议上，人们公开称赞产品团队或设计师在项目上的工作，却从未提及工程师的血汗与泪水使事情变得真实。由于这三类产品，每一种产品都是成功还是失败，所以没有人能够独自完成。确保您的公司始终将团队视为一个整体，而不仅仅是一个特定的部分。

结论
我们的软件工程师是一群有趣的人。我们伴随着一种确定的个性，我们确实希望使最好的事情成为可能。如果您不再像短时间厨师那样对待我们，而开始像创造性过程中那样对待我们，您可能会比以前更快，更远。我所工作的团队由于不了解工程师的心态以及驱动他们的原因而产生了不同程度的摩擦。我衷心希望这篇文章能够导致工程师与他们之间的更好的沟通。其实并不难。我们都是想成为解决方案一部分而不是工蜂的人。