本文是一篇论文的翻译，该论文是 Paul Luo Li、Amy J. Ko 和 Andrew Begel 三位学者在微软公司进行研究后，综合前人研究成果而写出的。由于篇幅过长，译者对一些重点词句进行了标注，方便想快速了解的朋友阅读。另外，文中很多受访者的访谈也很有意思，值得细细品味。当然，想看原版的朋友，可以访问 https://faculty.washington.edu/ajko/papers/Li2019WhatDistinguishesEngineers.pdf ，或者搜索《What distinguishes great software engineers?》。
摘要伟大的软件工程师对于创造伟大的软件至关重要。然而，今天，我们对伟大工程师与普通工程师的区别缺乏了解。我们通过对经验丰富的工程师进行迄今为止最大的混合方法（mixed-method）研究之一来解决这一知识差距。我们调查了 1,926 名专家工程师，包括高级工程师、架构师和技术研究员，请他们判断伟大工程师的 54 项综合属性的重要性。然后，我们进行 了 77 次电子邮件采访，以解释我们的发现并了解背景因素对评级的影响。综合调查结果后，我们认为伟大工程师的前五个显著特征是编写好的代码、调整行为以考虑未来的价值和成本、进行明智的决策、避免让别人的工作更难，并不断学习。我们将研究结果与之前的工作联系起来，并讨论对研究人员、从业者和教育工作者的影响。
1 介绍归根结底，要对 [软件] 进行更改，仍然需要开发人员(坐在某个座位上的屁股)输入 [源代码控制系统] 提交。— 开发经理
（图片来自网络侵删）伟大的软件工程师对于创造伟大的软件至关重要。因此，了解区分优秀工程师的属性是我们世界快速发展的软件生态系统的基础：公司希望聘用和留住优秀工程师，大学希望培训他们，而有抱负的工程师想知道什么是伟大。
软件工程研究⻓期以来一直渴望发展这种理解，许多研究都严格考虑了伟大工程师的属性。例如，从计算的早期开始，许多研究人员和从业者就认识到一些软件工程师比其他软件工程师更优秀。使用生成的代码行数和错误率等指标，早期研究试图量化优秀工程师与普通工程师在生产力方面的差异(Sackman 等人，2017 年)。1968年)。 通常在实验室或大学环境中进行(Gugerty 和 Olson1986年; 罗比拉德等人。2004年), 研究试图分离技术编码任务。这些观察导致了“10倍开发人员”这一软件工程在互联网的流行语。
开发人员技能的一些概念在课程中进行了规范编码。例如，ACM 课程标准将软件工程师定义为：编写供他人认真使用的软件的人。课程列举了软件工程师的基本知识；它几乎完全专注于技术技能，如编程基础和软件设计（计算课程联合工作组2014）Software Engineering Book of Knowledge (Bourque et al.2014)，它试图列举软件工程师能够并且应该知道的一切才能胜任。
虽然许多先前的工作坚持认为编程和技术知识是核心，但一些证据表明，优秀工程师的特质还在于他们与队友有效互动的能力。例如，许多检查软件工程师日常活动的研究发现，工程师花费大量时间执行非编码活动(Singer et al.1997; 佩里等。1994)，包括解决冲突 (Gobeli et al.1998)，错误分类 (Anvik et al.2006年; 阿兰达和维诺利亚2009) 和信息搜索 (Koet al.2007年)。 研究还从进入行业的应届毕业生的⻆度考虑了这些因素，检查应届毕业生的能力与在现实世界中设计软件所需的技能之间的差距(Radermacher 和 Walia2013)。研究人员通常发现，成为高效的工程师需要非编码属性，例如自信、渴望学习以及与他人有效合作的能力(Begel2008年; Hewner 和 Guzdial2010).
软件工程过程研究意味着工程师所需的技能。各种指南(特别是 CMM Herbsleb 等人。1997)、方法(例如，螺旋方法 Boehm1988) 和宣言(例如，敏捷宣言 Beck 等人。 2001年), 提出了许多具体的工作、计划和决策方式，这些方式对于高效的团队合作至关重要。这些与名人的说法是一致的(布鲁克斯1995) 和微软等公司的其他公司 (Brechner 2003年) 和谷歌(Fitzpatrick 和 Collins-Sussman2009)，这表明优秀的软件工程师拥有一系列跨越支持组织需求的社会技术范围的属性。他们共同指出人格特质、技术能力和人际交往能力相结合，以区分现实环境中的伟大工程师。
研究工作最近在两项综合研究中达到顶峰，将先前的工作综合到更高层次的框架中。我们之前的 ICSE 论文(Li 等人。2015年) 通过全面列举伟大工程师的属性奠定了基础， 从对 Microsoft 经验丰富的工程师的 59 次半结构化访谈中得出了一组 54 项属性。巴尔特斯和迪尔 (2018) 建立在我们的研究之上，通过贡献一个全面的将软件工程过程与工程师的个人和社会特征相结合的理论。然而，这两项研究都缺乏对这些特征的相对重要性的理解。因此，在本文中，我们探讨了三个研究问题。第一，经验丰富的工程师是否认为某些属性比其他属性更重要？第二，属性的感知重要性如何因工程师的人口统计、背景和工作经验而异？第三，这些属性如何将伟大的工程师与其他人区分开来?
这些问题的答案需要大量的信息提供者样本，在丰富多样的背景下，对伟大工程师的特征做出判断。因此，我们对经验丰富的工程师进行了大规模的混合方法研究。我们对 1,926 名微软专家工程师进行了定量调查，覆盖 67 个国家(调查时全球所有专家微软工 程师的 13%)。此外，我们进行了 77 次后续访谈，以定性解释属性的相对重要性和背景因素的影响。我们的工作是迄今为止对软件工程师进行的最大的真实世界研究之一。
在本文的其余部分，第2节讨论了我们之前的访谈研究以及它产生的伟大工程师的 54 条属性，它们是本研究的基础。第3节描述了这项研究的方法，包括调查和后续访谈。我们按照第4节与结果。在第5节我们首先讨论之前的工作，然后我们综合⻅解并将这些⻅解与之前的工作联系起来。我们讨论研究人员、教育工作者和从业者的收获，以及对有效性的威胁。最后，我们在第6节得出结论。
2 伟大软件工程师的特质在本节中，在描述我们的研究之前，我们回顾了我们之前研究的属性 (Li 2016年)，这构成了我们调查和访谈的基础。图1显示了这些属性的概述以及它们之间的关系。先前工作中的 54 个属性包括软件工程师个性的自我聚焦属性和他们做出有效决策的能力，以及优秀工程师对人和产品的影响的外部聚焦属性。先前的出版物提供了每个属性的详尽描述(Li 等人。2019)。
如图1显示，第一组的 18 个属性是与工程师个性有关：
图1 优秀软件工程师的属性模型
那是教不来的东西。我认为这是一个人必须拥有的东西 [...] 他们不需要任何外部动力。他们只是去做 [...] 他们只是内心渴望成功，我不知道为什么。不一定是为了钱，也不一定是为了认可。只是无论他们做什么，他们都想做得非常好 [...]
一些属性，例如热情和好奇，与伟大工程师作为人有关。受访者认为，许多这些属性是工程师固有的——通过他们的成⻓形成的——并且很难（如果不是不可能）改变。
第二组包含 9 个属性，这些属性与工程师做决定的能力有关。所谓决策，我们指的是“理性决策”，正如 Simon 所描述的那样(1955年)：评估当前情况（即了解需要在何时做出什么决定），确定替代行动方案，衡量概率结果，并估计未来状态的价值。
我们如何做出我常说的“稳健决策”？根据我们无法预⻅的一系列潜在结果，我们可以做出什么决定？[...] 如果我们能够做出可行的决定，无论 A 还是 B 发生，那么我们现在就不必为 A 或 B 争吵。— 技术研究员
受访者将软件工程描述为需要关于“构建什么软件以及如何构建它”的许多复杂选择。此外，除了书本知识之外，优秀的工程师还了解决策在现实世界中是如何发挥作用的。他们不仅知道应该发生什么，也知道可能发生什么。结合内部知识、将知识联系在一起的心智模型以及对其模型进行推理的认知能力，决策制定属性是很自我的。然而，与个性不同的是，受访者们认为，有效的决策是可以学习的。
第三组 17 个属性与工程师 与队友的互动 有关：
[这位伟大的软件工程师] 触动人们的方式，就是在那儿化解冲突 [...] 这种魔力让人们尊重他。那是有趣的魔法，我想不是每个人都拥有。— 高级软件工程师
大多数受访者认为，伟大的工程师会对队友产生积极影响。对于许多受访者（他们的头衔包含“主管”或“经理”）来说，这是他们作为其他工程师经理的重要工作。关于与队友互动的属性通常围绕四个概念：做一个通情达理的人、影响他人、有效沟通和建立信任。我们将这四个概念解构为它们的组成属性。
最后一组包含的 9 个属性与 伟大工程师制作的软件 有关：
⻛格 [...] 总是一贯，而且一切都很干净 [...] 非常简洁。只要看着它，你就可以说，“好吧，这家伙，他知道他在做什么。” [...] 没有多余的东西。一切都是最低限度的必要和足够的，因为那就是它该有的样子。屏幕外经过深思熟虑。— 高级软件工程师
就像艺术家欣赏其他艺术家的杰作一样，我们的受访者（其中许多人本身就是伟大的工程师）从其他伟大工程师开发的软件中看到了美。
在本文中，我们以伟大工程师的这些综合属性为基础，使用混合方法研究（定量调查和定性后续访谈）来了解属性的相对重要性以及背景因素如何影响它们的重要性。然后，我们综合了两项研究中的经验教训，以深入了解杰出工程师的不同之处。
3 方法为了确定属性的相对重要性，我们进行了大规模的定量调查，试图通过以下方式对 54 个属性进行排名：协议该属性对于伟大来说是必不可少的。此外，我们根据之前的研究 (Hewner 和 Guzdial)考虑了影响软件工程实践的背景因素2010; Radermacher 等 人。 2014; 费舍尔和⻢戈利斯2002年; ⻢戈利斯和费舍尔2003年; 卡佛等人。2008年; 沙克尔福德等人。2006年)(以及我们自己之前的研究)：经验量、性别、国家、计算机科学教育背景和软件类型(服务器端、客戶端或两者)。桌子2个, 稍后在部分中显示4个, 详细说明了这些因素是如何运作的。最后，由于定量统计检验可能存在虚假相关性，因此我们使用定性后续访谈来帮助验证和解释调查结果。
对于这项研究，我们选择继续在微软进行调查，与我们之前的访谈研究相同的设置(Liet al.2015年)。尽管微软作为一个组织，存在明显的外部有效性限制，但它也有优势。首先，在 Microsoft 的持续调查有助于构建和内部有效性。Microsoft 员工有共同的理解（例如，术语和资历基于头衔），这有助于对我们的问题以及我们对他们的回答的解释保持一致。此外，共同的组织结构（例如职位）使我们能够以一致的方式为研究确定经验丰富的工程师（在第 3.1 节中讨论）。其次，微软是一个多元化产品和环境的联合企业。其中包括游戏、消费电子产品、操作系统、生产力、搜索、消费者服务、企业服务、企业资源规划、客戶关系管理、数据库、开发人员工具、和通信，以及世界各地特定区域的发展中心。这种丰富多样的语境实际上有利于外部有效性，并增加了辨别有趣语境因素的前景。第三，微软始终如一地利用最佳实践和技术，并聘用顶尖人才;这有助于排除混杂的缺陷。最后，我们承认权宜之计; 两位作者是 Microsoft 员工，可以访问工程师并获得执行研究的组织许可。我们将在其他情况下进一步验证我们的结果留给未来的工作。微软始终如一地利用最佳实践和技术，并聘用顶尖人才；这有助于排除混杂的缺陷。
3.1 调查方法
我们方法中的一个关键决定是确定可以考虑谁的主观意⻅有效的对“伟大”属性的判断。对于这项研究，我们假设经验丰富的工程师最能做出这些判断，因为他们在采访和评估其他工程师时经常做出这些判断。我们在抽样中包括了工程师的主管和经理，因为在 Microsoft，几乎所有人都有工程师的实践经验。与我们最初的访谈研究一样(Li 等 人。2015年), 我们采用了 ACM 对软件工程师的定义 (Shackelford et al.2006年)：编写供他人认真使用的软件的人。 我们使用 Microsoft 公司目录来实施此定义。我们根据需要“软件开发”的头衔确定软件工程师，然后合并头衔列表，删除各种地址簿措辞异常。为了确定“有经验”，我们使用了人类专业知识的研究人员 (Ericsson et al.1993)。我们确定了那些已经取得一定程度认出经验丰富，通过招聘或晋升过程，选择软件开发工程师 2 级 (SDE II) 职称或以上的工程师。
认识到更有经验的工程师的⻅解是有价值的（而且更难获得），我们有两个抽样层经验水平。 首先，对于“有经验”，我们选择了SDE2级职称到“高级软件开发工程师主管”晋升级别的工程师；这些工程师通常至少有 5 年的经验。第二，对于“非常有经验”，我们选择了“高级软件开发工程师负责人”晋升级别以上的工程师；这些工程师通常拥有 10 年以上的经验，并且通常负责关键的技术领域。
我们在 Microsoft Research 网站上主持了我们的匿名调查。我们通过电子邮件向工程师发出邀请，要求他们参与，提供调查结果报告并参加礼券抽奖活动作为奖励（两张礼品卡，每张 75 美元，中奖几率与受访者人数成正比）。我们用软件工程师的名字个性化征集，描述了研究的目的，并解释了为什么我们需要他们的观点；这些步骤有助于减少漫不经心的调查回答（用戶提供不真诚或随意的回答）（Meade 和 Craig2012）。 每个征集都有一个单独的匿名调查链接，以防止多次提交（例如通过机器人，这可能会导致偏⻅和虚假结果）。我们在第一周和一个月后发送提醒邮件。该调查于 2014 年 12 月至 2015 年 2 月开放。
在调查中，在解释了研究的目的和受访者不参与的权利后，我们询问了受访者的人口统计数据、经验水平和当前工作环境(使用数字输入框，例如经验年限，或单选按钮， 例如服务器端/客戶端软件)。这些是我们后来与他们的评级相关联的背景因素。
然后，我们寻求受访者对所有属性的评分。预计受访者会疲劳，我们提出了四组问题，对应于我们访谈研究中的四组，在第2个. 为了解决排序偏差并能够分析不完整的结果，我们随机化了四个组的排序，以及随机化(单独)每个组内属性的排序。有关属性的问题以类似的方式组织和措辞，使受访者能够快速阅读和回答。为了说明，图。2个显示了对勤奋属性的调查结果。我们以一个开放式的包罗万象的问题结束了调查，旨在检测操作问题和缺失的属性。
我们采取了几个步骤来确保受访者准确理解这些属性。在调查构建的第一次迭代中， 我们描述了一位拥有该属性的工程师。然后，我们对调查进行了试点，以确定理解问 题，从而导致措辞发生变化（例如，“软件工程师”改为“开发人员”，以区分不编写代码的人），为 37 个属性添加支持引语，为混淆的属性添加说明（例如，“实践”和技术”附加了“例如单元测试、代码审查、Scrum 等”)。
为了获得重要性的绝对评级，我们问“如果一个经验丰富的开发人员——其主要职责是开发软件——没有这个属性，你还能认为他们是伟大的开发人员吗?” 我们给了受访者六种李克特⻛格的选择(⻅图 1)。2个): “如果他们没有这个，就不能成为一个伟大的开发人员”，“没有这个很难成为一个伟大的开发人员，但并非不可能”，“没有这个也可以成为一个伟大的开发人员，但拥有它会有所帮助，”“是否无所谓他们没有这个，这是无关紧要的，”“一个伟大的开发商不应该有这个；这不好，”和“我不知道。”
图 2 属性调查问题的屏幕截图:“勤奋”
试点调查表明，这种对“重要性”的负面操作对受访者来说更容易，并且更容易引出属性的重要性。积极措辞的描述导致反应混为一谈，因为受访者几乎总能想象出一种属性可能很重要的情况。消极的措辞产生了更多的差异化，更符合我们对重要性的概念化：伟大的工程师不可能具备的属性没有。
调查构建完成后，我们对 200 名开发人员进行了初步部署(~每个体验层中有 100 个)来寻找其他问题，并预测响应率。在没有发现任何问题后，我们将调查部署到整个样本中，目标是在每个抽样层中获得 500 个响应。
受访者完成调查的平均时间为 28 分钟。总的来说，我们获得了 1,926 份调查回复，825 份回复来自有经验的工程师 (~7% 的有经验的微软的工程师，回复率为 46%) 和来自 1,101 的回复非常有经验工程师 (~全部的 35%非常有经验 Microsoft 的工程师，响应率为 44%)。在回复中，1,634 (84.3%) 是完整的，292 对至少一个属性进行了评级。我们没有发现项目响应偏差——属性和响应之间没有关系，在α = .05 水平使用 Logistic 回归。也没有从开放式最终问题中检测到任何问题（例如，没有缺失的属性）。由于随机化以及每个属性的排名独立于其他属性（即非相对评级），我们在分析中同时使用了完整和部分数据。
我们的定量分析评估了我们的相对重要性概念：受访者同意工程师不能被认为没有该属性的程度。这排名的两个重要方面是：评分和受访者之间对评分的认同程度；从统计上讲，这意味着分配评级:集中趋势(即临界性)和分散性(即一致性)。更重要的属性的分布更集中在较高的评级上。因此，我们通过比较每个属性的评分分布与每个其他属性的评分分布来对属性进行排名，计算一个属性的分布明显更高的其他分布的数量(53 是可能的最大数量)。我们没有用平均评级的三个原因:数据是有序的(即评级水平之间的距离不一致)，我们的响应水平不居中(四个正面评级和只有一个负面评级)，并且平均值不考虑评级的分散。为了对属性进行排序(即比较分布)，我们使用了 Mann-Whitney 排序测试;该测试可用于比较有序数据和分布(集中趋势和分散)，并且可以在观察数量不相等时使用(Hollander 等人。2013)。 没有异常的双峰分布。对于每个属性，我们执行了 53 个单侧 Mann-Whitney 等级测试，一个测试针对所有其他属性。然后我们计算了水平上具有统计显着性的成对比较的数量α= .05。最后，我们根据统计显着性测试的数量对属性进行排名。例如，排名最高的属性的评分分布在统计上高于所有其他属性。
为了分析上下文因素和评级之间的关系，我们使用了序数 Logistic 回归。我们评估了上下文因素和每个属性的评级之间的一阶关系。由于是可选的，只有 1,512 名受访者提 供了年龄信息。为了最大化统计功效，我们首先用所有因素拟合模型以评估年龄的影响，然后拟合没有年龄的单独模型，以评估其他因素的影响。
由于我们测试了每个因素和每个属性之间的统计显著关系(总共超过一千次测试)， 为了解释执行多个统计测试，我们在标准 FDR 下使用了 Benjamini 和 Hochberg 错误发现率 (FDR) 调整q=0.1级。我们通过删除最高 p 值关系来过滤出具有统计意义的关系以实现 FDR q=0.1(所有关系都有 p<.05).
3.2 后续邮件面试方式
量化结果告诉我们什么(例如重要的属性和统计上显着的关系)，但它们并没有告诉我们为什么。 为了解释排名和关系，我们通过电子邮件向受访者发送电子邮件，以深入了解他们的调查回复，从而提供对定量结果的有效理解。
我们对排名最高的属性(表中排名前五的属性)进行了后续访谈1个)，潜在的有害属性(具有最高百分比的两个属性“一个伟大的开发者不应该有这个；这不好”收视率，在表的底部1个)，以及受上下文因素显着影响的属性(表中列出的关系2个). 对于排名最高的属性和积极关系，我们选择了在属性评分和中位数评分之间具有最大正差的受访者，旨在避免对所有属性都给予高度评价的受访者。对于有害属性和负面关系，我们 同样选择了负面评级差异最大的受访者。
在我们的调查中，771 名受访者表示他们愿意回答后续问题。我们向 111 发送了后续电子邮件，收到了 77 的回复(回复率为 69.4%)。
表1 伟大的软件工程师的属性，顺序：必须有、应该有、最好有、无关的和不该有
更高
模式
属性和描述
53
必须
注意编码细节，例如错误处理、内存、性能、样式
52
必须
能够处理复杂性；能够理解多个交互式软件组件
49
必须
持续改进：改进自己、产品或周围的环境
49
必须
诚实：提供可靠的信息和反馈，以便他人采取行动
49
必须
思想开放：让新信息改变他们的想法
46
必须
执行：知道什么时候停止思考并开始行动
45
必须
自力更生：独立完成事情，不易受阻
45
必须
自我反省：意识到何时出现违背计划和要点的问题
43
必须
坚持不懈：不因挫折和失败而气馁
41
必须
与其周围的其他部分相适应：代码体现了周围的约束和产品
41
必须
了解他们的技术领域，包括产品、平台和竞争对手
39
必须
做出明智的权衡：代码响应市场目标的时间、业务的关键需求
39
必须
更新他们的决策知识：不要让他们的理解停滞不前
36
必须
好奇：渴望知道事情为什么会发生以及事情是如何运作的
36
必须
进化：代码结构可以有效地构建、交付和增量更新
35
应该
了解工具和材料：了解代码的优缺点
35
应该
提高他们做出正确决策的能力：建立对决策可能结果的理解
34
应该
见林见树：通过多个抽象层次的情境进行推理
31
应该
工艺：希望他们的输出反映他们的技能和能力
30
应该
预先审查: 在决定之前审查现有的信息
30
应该
优雅：设计其他人可以理解和欣赏的解决方案
29
应该
寻求帮助：知道自己知识的局限，并用他人的知识来补充
28
应该
渴望将想法变为现实：以构建软件为乐
28
应该
远期：考虑随着时间推移的成本和收益，而不仅仅是短期目标
25
应该
愿意进入未知：可以走出舒适区去探索新领域
24
应该
是一个好的倾听者：有效地获取、领会和理解他人的知识
22
应该
充满激情：对他们工作的领域有内在的兴趣
22
应该
管理期望：清楚地传达他们将要做什么以及何时完成
22
应该
专注：为最有影响力的工作优先安排时间
21
应该
系统性：以有组织的、有原则的方式解决问题
21
应该
适应新环境：随着环境的变化对组织仍然有价值
19
应该
整合对他人的理解：可以与他人建立更完整的理解
19
应该
不针对个人：避免根据个人目标和感受做出决定
19
应该
创意：根据上下文及其局限性生成新颖和创新的解决方案
18
应该
用行动说话：为他人树立榜样
18
应该
了解软件工程流程：了解最佳实践和技术
13
应该
预测需求：主动确定潜在的问题和需求
13
应该
在构建过程中使用正确的流程：使用最佳实践和技术来构建软件
13
应该
为软件产品的利益而抗拒外部压力：坚定地抵抗外部压力
11
应该
有良好的声誉: 有信仰、尊重、信任和信心
11
应该
富有成效：能更快地达到与他人相同的结果
10
帮助
了解客戶和业务：了解他们产品的价值主张
10
帮助
创造与他人的共同理解：通过有效的沟通塑造他人的知识
9
帮助
为每个人创造共同的成功：建立每个人都可以接受的 期目标
8
帮助
与组织目标一致：为产品和组织的利益采取行动
7
帮助
彬彬有礼：尊重他人
7
帮助
数据驱动：让数据驱动行动，而不仅仅是直觉
6
帮助
为他人创造一个安全的避风港：让他人自由地做出基于正确的决定，而不是恐惧
5
帮助
指导：教授、指导和支持其他开发人员
4
帮助
了解人和组织：了解他人的责任和知识
2
帮助
挑战他人以提高：鼓励扩展能力和目标
2
帮助
风度翩翩：建立信任、积极的社会关系
1
帮助
勤奋：愿意每天工作超过 8 小时以交付成果
0
帮助
交易恩惠：与他人建立个人权益，允许他们以后拜访他人
我们试图向单个受访者询问多个属性(根据上述选择标准，当线人有资格回答有关多个属性的问题时)，以揭示跨越多种关系的⻅解。这封电子邮件以问候语开头，并感谢您参与这项研究。接着是:“我在分析数据时发现了一些有趣的东西，希望你能帮助我更好地理解它”。然后电子邮件描述了属性或关系，需要进一步理解的原因(例如，是最重要的属性之一，可能不是重要的属性，X 与 Y 的重要性评级较低相关)，受访者的评分， 然后:“你为什么选择这个答案？你能帮我理解你的推理吗？”。
我们对回答进行定性分析以获得理解，选择有代表性的引述，然后征得知情人的同意匿名引述。
表 2 背景因素、调查研究中的分布和显著影响。行没有排序。一些分配列为[最小值、中值、最大值]
序号
因子
编码
分配
关系（OLR，FDR，q=0.1)
1
经验
依据职称分类
经验丰富 (825,43%) 非常 (1,101,57%)
执行 (+) 了解工具和材料 (+)做出明智的权衡（+）
2
年龄
数值的
[20, 39, 73]
非常了解业务 (+)了解流程 (+)与组织目标保持一致 (+)
3
开发人员年限
数值的
[0, 15, 41]
勤奋 (+)渴望将想法变为现实(+)
4
在微软的岁月
数值的
[0, 10, 30]
与组织目标一致 (+)
5
# 职业生涯中的公司
数值的
[0, 3, 10]
持续改进 (+)
6
在当前团队中的年数
数值的
[0, 3, 25]
—
7
经历过经理
是/否
经理 (1,028,53%)
—
8
是女性身份
是/否
是 (149, 8%)
使用正确的流程 (+)
9
拥有CS学位
是/否
是 (1,228, 64%)
—
10
拥有非MBA学位
是/否
是 (762, 40%)
寻求帮助 (‒)
11
拥有工商管理硕士学位
是/否
是 (49, 3%)
—
12
拥有博士学位
是/否
是 (49, 3%)
行动表率 (+) 挑战他人以提高 (+)
13
有其他学位
是/否
是 (103, 5%)
—
14
拥有非 CS 学位
是/否
是 (537, 28%)
—
15
不在美国工作
是/否
是 (351, 18%)
与组织对齐 (+)
16
工作经验
绝对的非美国国家
印度 (273, 14%)中国 (168, 9%)加拿大 (77, 4%)英国 (63, 3%)以色列 (51, 3%)其他 (383, 20%)无 (911, 47%)
31 个属性 (+)9个属性(+)任劳任怨(-)任劳任怨(-)，与组织对齐(-)
17
非英语语
是/否
是 (926, 48%)
热情 (+)
18
客戶类型
分类
内部(791, 41%)外部(270, 39%）两者(865, 32%)
坚持不懈（+）
19
服务器端软件
分类
客戶端（562，29%)服务器端(754, 39%)两个都(610, 32%)
—
20
# 开发人员工作在过去的一年
数值的
[0, 15, 1,000]
—
4 结果
在本节中，我们重点关注我们在后续访谈中询问的属性和关系，因为这些是最有趣的属 性和我们对其有最有效理解的属性。我们讨论了前 5 个(排名最高的)属性、后 2 个 (可能有害的)属性，以及属性组之间的总体排名。对于因背景因素造成的差异，我们 讨论每个具有统计显着性的关系。
4.1 属性排行
表1显示属性，根据我们的调查答复对其重要性的一致程度进行排名。根据评分分布，最重要的属性位于顶部，最不重要的属性位于底部。我们没有观察到异常的双峰分布，并使用 Mann-Whitney 检验比较了分布。第一列中的数字是该分布相对较高的其他分布的数量。关键性的主观评级在第二栏中。第三列列出并解释了属性。
4.1.1 排名最高的属性
最重要的属性是注意编码细节(排名 1，评分分布高于 53 个属性；63.1% 必不可少，28.8% 重要，7.5% 有帮助，0.3% 无关紧要，0.1% 有害)。受访者解释说，工程师首先通过他们的代码来判断其他工程师。因此，无法正确掌握基础知识的工程师不受尊重：
另一个强大的驱动力是我们同行的尊重，你不会通过编写劣质代码来获得 [...] — SDE 负责人
其次，受访者认为软件可以有多种用途，这通常是工程师无法预料的；因此，工程师需要注意细节以避免代价高昂的问题：
此代码对性能至关重要，对兼容性敏感，并且在各种各样的上下文中使用。如果开发人员未能处理错误，一些客戶会中招，我们可能需要发布修补程序；如果开发人员实现了低效算法 (上2个)不好)[...]在某些环境中过度消耗内存[...]等。— 校⻓ SDE
这在微软可能尤为重要，因为软件产品通常是平台、组件和/或在工程师无法预⻅的环境中使用。
这种理解也是心理处理复杂性的基础（排名第 2，评分分布高于 52 个属性；54.2% 的受访者给出最高评分，36.2% 重要，20.1% 有帮助，1.6% 无关紧要，0.2% 有害)一个高排名。受访者认为，优秀的工程师需要能够思考复杂的情况：
大多数有用的软件必须高度容忍上面的用戶/调用者的不正确使用，并与其下面的支持代码交互 [...]考虑到他们没有想到的情况 [...] — SDE 校⻓
受访者认为持续改进（排名第 3，评分分布高于 49 个属性；51.0% 的受访者给予最高评分，34.8% 重要，13.5% 有帮助，0.7% 无所谓，0.1% 有害）和开放的心态(排名 第 5，评分分布高于 49 个属性；49.4% 的受访者给出最高评分，36.5% 重要，13.2% 有 帮助，0.7% 无所谓，0.1% 有害)很重要，因为软件行业发展迅速；因此，伟大的工程师需要对新想法持开放态度并不断学习：
随着技术/技术的发展和更好的工具的出现，思想开放的开发人员会接受这些并愿意应用它们来提高生产力/效率 [...] 而无需努力持续改进 [...] 开发人员很快就会发现自己落后于行业和/或技术和技术的最新水平。— 首席 SDE 负责人
这种想法也促成了诚实的 (排名4，分布比49属性高，50.8% 的受访者给出了最高的评价，32.1% 重要，14.3% 有帮助，2.2% 无关紧要， 0.1% 不利)很重要。受访者表示，伟大的工程师需要承认错误，以便为他们自己和他们的团队做出最佳的未来决策：
在我的职业中，对自己撒谎比在我所知道的任何其他职业中都容易得多 [...] 很容易认为您知道该主题并错过(下意识地忽略)与您的“知识”相矛盾的证据。伟大的开发者 [...] 同时知道很多，并质疑他所知道的一切。— 校⻓ SDE
受访者还讨论了开发人员的不诚实可能对他人有害，并强烈认为这种行为是有害的：
这在我身上发生过很多次 [...] 拥有这样一个组件的团队会向我“谎报”它的可用性和成熟度，以便让我成为用戶并向管理层证明他们自己的存在 [。 ..] - 负责人
4.1.2 排名最低的属性
两个属性收到了负面评价——“一个伟大的开发者不应该有这个；这不好”—来自超过 5% 的受访者：互惠互利 (排名 54，分布高于 0 属性；4.0% 必不可少，15.1% 重要， 44.1% 有帮助，29.1% 无关紧要，6.0% 有害）和勤奋(排名 53，分布高于 1 属性， 11.0% 必不可少，19.9 % 重要，36.0% 有帮助，27.8% 无关紧要，5.0% 有害)。我们没有预料到会有如此高的负面评价，因为从之前的采访中得出的属性都是正面的。
后续采访表明，这些属性可能并不是天生的坏事，但可能反映了糟糕的情况。对于勤奋属性，受访者认为每天工作超过 8 小时可能表明计划不周或软件工程实践不可持续：
[...] 开发人员的工作量是发生在该开发人员之上的管理和规划的功能。通常需要⻓时间的工作，因为规划不好，在项目生命周期中做出的决策不好，变更管理不够“敏捷”。— SDE2
对于互惠互利属性，受访者认为，需要个人恩惠可能反映了一种有偏⻅的决策文化，在这种文化中，决策不是基于理性，而是基于个人的主观意⻅：
他们应该完全分开，否则我所看到的是我们倾向于对他人做出有偏⻅的决定和意⻅。— SDE2
此外，需要未记录的流程来完成工作可能表明组织实践不佳，使工程师更难有效运作：
一旦你“交换恩惠”，你就会进入个人的给予和索取，并围绕人图中的几个节点建立机构记忆，并且可能在这种关系之外不可⻅ [...] - SDE 负责人
4.1.3 属性组综合排名
总体而言，与队友互动相关的属性被评为最低（高一致性低重要性），中位数排名为 40 (4 组中最低)，并且 77.8% 的属性处于排名的下半部分；其次是个性属性（中位数排名为 24，下半部分为 44.4%)。相比之下，与决策相关的属性被评为最高（下半部分的中位数排名为 17 和 33.3%)，紧随其后的是软件产品的属性（下半部分的中位数排名为 17.5 和 33.3%)。这可以在图 1 中直观地看到。3个，它根据属性的排名(x 轴)和前两个框中的评级百分比(y 轴)绘制属性。
在后续采访中，许多受访者认为开发人员的想法应该通过其自身的优点来证明价值， 而不是通过其演示者的说服力。例如，以下是关于与他人创建共享环境属性，
图 3四类属性的属性排名
“有效沟通”最重要的组成部分，但在 54 个属性中排名第 43 位:
[...] 感觉就像将您的意志强加给其他人 [...] 其他开发人员通过控制对话或谈论其他人来推动他们的想法让我对该特定属性产生负面的直觉反应。想法应该立足于它们自己的优点，而不是它们被卖得有多好/有多强烈。— 高级 SDE
这些属性的较低相对排名可能反映了 Microsoft 的包容性文化。由于编码技能和心理能力排名最高(第 4.1 节)，排名可能反映出存在不同类型的人(个性)和不同方法 (与队友的互动)的信念。只要软件结果良好，就可以(而且应该)容忍每个工程师实现这些目标的不同方式。受访者认为，开发人员的首要工作是生产出高质量的软件，其他的都不是必须的：
一个伟大的开发者会促进公司的商业利益。他通过生产如此耐操和可靠的软件来做到这一点 [...] 除了这些考虑之外，我对那个开发人员没有兴趣 [...] — SDE 负责人
4.2 语境的影响
表2描述了我们调查中的 26 个背景因素：描述、描述性统计以及因素和评级之间具有统计意义的关系的摘要。为便于统计分析，我们仅将非美国国家工作经验排名前 5 位 的国家(每个国家的受访者均超过 51 人)分开；其他 61 个非美国国家合并为其他(⻅表中第 16 行2个). 第 5 列列出了基于 FDR 校正后的有序逻辑回归 (OLR) 的统计显着关系。 我们用 (+) 表示正相关(存在与较高评级相关的因子或因子的较高值)，以及负相关与 (−) 的关系(存在与较低评级相关的因素或因素的较高值)。在上下文因素中，10 个没有任何统计上显着的关系(在 FDR 校正后)，用“-”表示。
4.2.1 经验水平
我们讨论表中的前五个因素2个(很有经验、年龄、多年的专业开发人员、在微软的司龄、和 在软件公司就业) 统称为经验水平，因为所有因素都旨在衡量相同的“经验”基础结构， 并且彼此高度相关。之间的关系经验等级和八个属性(表中的前 4 行2个) 所有积极的。
我们后续采访中的受访者——他们都是非常有经验的。- 为观察到的积极关系提出了四个潜在原因。首先(也是最明显的)，受访者认为开发人员具有更高的经验等级更加重视对“业务目标”的贡献，因为更高级别的工程师是根据他们对元组织目标的贡献进行评估的。这可能是与组织目标一致并了解客戶和业务的关系的基础：
我们的评估系统一直强调实现公司组织目标的开发人员 [...] 更有经验的开发人员可能要明白，与公司目标保持一致会带来更大的回报。— 首席 SDE 经理
其次，受访者认为具有较高经验水平的开发人员重视交付结果，包括与勤奋的关系，希望将想法变为现实，并且执行。 受访者认为，凭借经验，工程师们了解到，要做出有意义的贡献，工程师需要交付软件：
20 年在初创公司和大公司管理工程师的经验 [...] 无论多么有才华、头脑敏锐和技术娴熟，如果他们不努力工作(即愿意⻓时间工作以按时完成任务/交付)，他们就不会成功 [...] — 合伙人 SDE 主管
第三，受访者认为经验水平较高的开发人员更注重获取知识和做出更明智的决策，因为他们经历过多次发布并经历过错误的痛苦。这包括与了解工具和建筑材料、了解软件工程过程以及做出明智的权衡 :
“知识渊博”和“消息灵通”仅来自经验。这完全是关于广度和对许多情况的接触，这些情况可以让你概括出新的情况 [...] 您实际上变得更加灵活，并且愿意在您职业生涯早期甚至可能没有考虑过的目标之间进行权衡 [...] 大多数人需要一段时间才能真正了解大局并能够根据更广泛的背景 [...] — 架构师
许多受访者进一步认为，只有通过实际的第一手经验才能获得这些知识和理解：
软件工程流程的存在是有原因的 [...] 你越有经验，你就越能亲眼看到流程的利弊。 —首席SDE负责人
最后，作为先前发现的推论，受访者认为经验丰富的工程师明白他们需要不断改进才能保持领先地位。经验丰富的软件工程师认识到，如果他们不继续学习，他们可能会过时：
没有人能在不“改进”的情况下保持领先地位，因为下一波技术浪潮很快就会淘汰 [原文如此] 处于领先地位的任何东西。— 合作伙伴 SDE
4.2.2 性别
我们观察到统计上显著的正相关关系性别并在施工期间使用正确的流程。我们询问了女性受访者为什么她们高度评价该属性，然后试图推断这些回答背后的推理的共性。女性受访者似乎认为流程的存在有充分的理由，优秀的软件工程师不应该试图“重新发明轮子”：
如果你不断地重新发明轮子或使用过时的工具/流程，你就不可能是伟大的。— 高 级 SDE
此外，女性受访者似乎更强烈地认为软件工程应该有条不紊地进行，而不是自行其是：
好的工程师必须知道执行过程并遵循它。每个项目/产品/团队可能有不同的流程，但优秀的工程师必须了解并遵循它，或者如果他/她认为应该更改流程，则开始讨论[...]—高级SDE主管
4.2.3 教育背景
我们发现拥有硕士和/或博士学位在寻求帮助、挑战他人以改善关系、用行动做出表率（Walks the walk）等方面是消极的 (对于硕士，请参⻅表中的第 11 行2个; 对于博士，请参⻅表中的第 12 行2个)。受访者提供了两个有趣的假设。首先，受访者认为，要想在软件行业取得成功，研究生学位在很大程度上是可选的（根据之前的讨论，可能不如实践经验重要）；因此，获得这些学位的工程师可能比其他人更有内在动力，导致他们不太愿意提供或接受帮助：
他们对最低限度的学士学位不满意 [...] 他们想自己找出事情来。—校⻓SDE
其次，受访者还表示，具有研究生学位的工程师通常被聘为技术专家。这样一来，他们经常需要解决新的问题，很少有机会给予或接受帮助：
[...] 以前没有人尝试解决的问题，其他人以前都未能解决的问题，或处理某种重大危机的问题 [...] 他们的运作假设是在发生危机时没有人可以寻求帮助他们将需要能够自己找出解决方案。— 校⻓ SDE
我们通过比较过去一年与之合作的开发人员数量(表格第 20 行2个) 具有和不具有高级学位的工程师之间。我们发现过去一年共事的工程师人数统计上显著减少(α=。05) 对于两位拥有硕士学位的工程师 (p=0.004，拥有硕士学位的人的中位数为 12，没有硕士学 位的人的中位数为 15)并且拥有博士学位。学位 (p=0.037，拥有博士学位的人的中位 数为 11，没有博士学位的人的中位数为 15。学位）使用 Mann-Whitney 等级检验。这些结果表明，拥有高级学位的工程师与更少的工程师一起工作。
总的来说，我们得出的结论是，由于研究生院的原因，这种关系不太可能教学工程师贬低给予和获得帮助的价值。相反，正如所讨论的，研究结果可能是由于选择偏差(导致工程师攻读研究生学位的条件)和幸存者偏差(硕士/博士毕业生的工作分配)。
4.2.4 在另一个国家的工作经历
我们发现在另一个国家的属性和工作经验之间存在许多正相关关系；定性后续行动提出了四个基本主题。我们向受访者询问了他们的评级，然后推断出潜在的主题。首先，受访者表示，在一些国家，高薪软件工程工作竞争激烈。这个可能是 31 的根本原因积极的属性之间的关系和有工作经验印度，以及属性和之间的 9 个 正相关关系有工作经验中国. 竞争要求这些国家的工程师在许多领域表现出色才能竞争：
我认为从文化 [...] 如果你不是班上的佼佼者，你就不会进入。继续你的下一件事， 无论如何。如果你不是第一名，你就不会进入个人所得税。无论如何，你都不是排名数字，你得不到那份工作 [...] 在西方世界不会那样工作，因为 [...] 人口。有很多机会 [...] 不仅一个人获胜，十个人都可以获胜。在世界的东方也许不是。— 高级开发经理
其次，受访者认为文化规范影响了一些国家的软件工程实践。最突出的例子是两者之间的关系在中国有工作经验(汇总于表第 16 行2个) 和互惠互利属性。虽然互惠互利属性是整体排名最低的属性，其评分在中国受访者中明显更高。后续采访表明，较高的收视率受到中国更广泛的文化规范的影响：
在文化上有不同的看法[...](“关系”)，它只是做生意的一部分。当然，最好的、最成功的是那些拥有这些关系的人。这将是一件积极的事情 [...] 任何职业或专业 [...] 即使在工程环境中也是如此。— 首席 SDE 经理
除了交换利益之外，受访者暗示许多其他属性(例如勤奋和系统性)同样受到当地实践和期望的影响：
系统性的，如果有偏差，我不会感到惊讶 [...] 其中一部分是文化。每天都在努力完成工作。那里的人会承认这没有意义；这就是它的工作方式，你为什么要改变它。 —首席SDE经理
第三个主题是距离。受访者认为，由于远离位于美国华盛顿州雷德蒙德的微软总部，一些软件工程师缺乏对公司方向的了解。这可能会影响工程师对与组织目标保持一致的看法。一些知情人表示，近年来公司重心的众多转变导致工程师将注意力集中在他们的直接客戶而不是公司的整体战略上:
[...] 组织目标通常是通用的并且经常变化 [...] 一个开发人员是伟大的，无论外部事件、条件或事件如何 [...] 一个伟大的开发人员应该为了产品和客戶的利益而采取行动. 在优秀的公司中，这样的行为会给个人和组织带来回报和好处。— SDE2
第四个主题是某些属性可能与这些国家/地区正在设计的软件产品类型以及这些国家/ 地区的软件工程实践状况有关。对于与勤奋的负面关系，几位拥有非美国工作经验的开发人员表示，他们曾在游戏行业工作过，他们必须进行“死亡行军”，需要加班加点才能发布软件产品。这对于美国以外的受访者来说可能尤为突出，说明在英国和其他国家勤奋工作和拥有工作经验之间的负相关(表中第 16 行2个):
我亲眼目睹了这一点，随着时间的推移，人们的工作效率逐渐降低，并且倾向于做出更多短期决策 [...]资深SDE
4.2.5 客戶类型
拥有内部和外部客戶与坚持不懈之间存在统计学上显着的正相关关系(表中第 18 行)2 个)。然而，根据后续采访，我们认为这种关系可能是虚假的(这并不奇怪，因为 FDR 调整减少了但不会消除偶然发生的具有统计意义的关系)。
一位受访者试探性地提供了可能的解释，即拥有不同需求的客戶会导致需要坚持不懈的相互冲突的要求；不过，即便是他，也觉得这种关系可能是巧合：
同时处理两组客戶也很令人沮丧，因为他们经常有相互冲突的要求。它需要坚持不懈，能够在冲突面前坚持执行哪些。与我已经提到的内容相比，我没有更多的想法，所以这可能是巧合。—首席 SDE 经理
5 讨论在本节中，我们综合并讨论了关于杰出工程师的区别的知识。首先，我们通过讨论之前的工作来设定背景，然后我们讨论我们的学习告诉我们什么，包括伟大工程师的区别和之前的工作。我们讨论对研究人员、教育工作者和从业者的影响。最后，我们以对有效性和未来工作的威胁的讨论作为结束。
5.1 相关工作
之前的工作为软件工程师的许多方面提供了广泛而有价值的⻅解，但文献未能提供关于开发人员技能的整体、以开发人员为中心、生态有效的观点。例如，许多研究只关注技术技能：比较新手和专家编程技能(例如，Sackman 等人。1968年; 古格蒂和奥尔森 1986年; 罗比拉德等人。2004年) 或提出软件工程毕业生应具备的技能(例如，计算课程 联合工作组2014; 布尔克等人。2014; 白格尔 2008年; Hewner 和 Guzdial2010). 一些研究关注人和社会因素，但没有将这些因素与技术技能联系起来(例如，Kelley1999; 罗佐 夫斯基2015年; 艾哈迈德等人。 2012). 其他先前的工作提供了关于最佳实践和信息需求的团队和组织观点，这意味着必要的技能，(例如，Herbsleb 等人。1997; 伯姆1988; ⻉克等。2001年; 柯等。2007年; 歌手等。1997; 佩里等。1994), 但通常不明确解决个人 技能。行业从业者之前的一些工作做提供开发人员技能的更全面和经验的观点，结合技 术、人际关系和心理属性;他们的⻅解也得到现实世界的例子和解释的支持(布鲁克斯 1995; 布雷希纳2003年; 菲茨帕特里克和柯林斯-萨斯曼2009). 然而，这些著作的调查既不严谨也不完整(他们的目标也不是如此)。
最相关的先前工作，Baltes 和 Diehl 的综合软件工程专业理论 (Baltes and Diehl2018 ), 是一个有趣的补充到我们的研究。虽然“伟大”和“专家”密切相关，但它们并不完全相同。作为一个专家软件工程师意味着成功地生产软件；然而，作为一个伟大的软件工程师可能会超越工程成果。例如，“指导”属性(⻅表1个)：虽然成为一名优秀的导师是工程师的理想属性(我们的许多受访者都讨论了从拥有导师中获益)，但尚不清楚该属性如何使导师更像“专家”。因此，我们的排名提供的⻅解很有价值，有助于理解工程成果的重要性。
因此，相对于之前的工作，我们的研究试图比现有文献更全面、以开发人员为中心、生态有效且更科学严谨。
5.2 伟大软件工程师的区别
相对于之前的工作，我们的研究表明，区分伟大工程师的属性全面地包括内在人格特质、与他人交往的能力、技术能力和决策能力。尽管专家的意⻅指出了伟大工程师的显著属性的“联合武器”性质，但以前的研究工作很少检查超过一种属性。需要全面深入地检查软件工程师是我们研究的关键⻅解，也是我们工作的主要贡献之一。
5.2.1 成为称职的编码员
我们的结果表明，至少在微软，成为一名优秀工程师最重要的方面是成为一名称职的编码员。虽然许多关于伟大工程师的研究都在吹捧各种“软技能”(凯利1999)，我们研究中经验丰富的工程师将编写好的代码的技术能力列为最重要的。理解这方面如何区分伟大的工程师很简单：没有代码，就没有软件；因此，伟大的软件工程师需要能够编写好的代码。正如 ACM 对软件工程师的定义 (Shackelford et al.2006年) 表明，编写代码是成为软件工程师的核心。
我们的调查结果表明，最高级别(在 Microsoft)的生产软件工程可能是一项复杂的技术任务。知情人指出，不确定性和复杂性影响着他们的软件，包括底层依赖项、系统状态、外部调用者和/或合作伙伴组件。注意编码细节和处理复杂性的心理能力位居榜首可能反映了这种情绪(⻅第4.1.1)，以及其他产品和决策属性的整体高排名(⻅第4.1.3). 这加强了布鲁克斯的情绪人月神话(布鲁克斯1995); 编写“生产”代码很难。
我们的发现与 ACM 的软件工程计算课程相一致(Shackelford 等人。2006年) 和 SWEBOK (Bourque et al.2014)，主要侧重于技术编码技能。这些发现也符合对工程师日常活动的观察；尽管工程师花时间做其他活动，但他们的大部分时间仍然花在编码上 (Ko et al.2007年; 拉托萨等人。2006年; 歌手等。1997; 佩里等。1994). 此外，我们的研究结果在很大程度上证明了旨在理解和缩小新手和专家编码员之间差距的研究工作的合理性(Sackman 等人，2017 年)。1968年; 瓦莱特和⻨克加里 1988; 古格蒂和奥尔 森1986年; 罗比拉德等人。2004年; 巴尔特斯和迪尔2018). 虽然专注于编码可能是近视的，因为它是软件工程师的基本技能，确保新手首先成为称职的编码员可能是一个很好的起点：
但是，当我们谈论代码的质量、性能、空间以及它有多少错误时——它有多健壮 ——以及它如何处理异常 [伟大的软件工程师的代码] 会有很大的不同 [...] 例如，当我以前在中国做游戏的时候，我在做一个棋盘分区程序 [...] 花了大约 3 个小时。然后我的 CTO 带着程序去优化。当他完成后，程序运行了 10 分钟。这就是人与人之 间可能存在的差异 [...]
— SDE2
相反，我们的研究结果表明，不考虑技术技能是仅关注工程师软技能的研究的主要局限性(例如 Kelley1999; 罗佐夫斯基2015年; 艾哈迈德等人。2012). 正如 Cruz 等人所讨 论的那样，各种人为因素与工程结果之间缺乏一致的关系。(2015年), 可能是由于技术技能的遗漏。毕竟，如果软件工程师不能开发软件，那么所有其他属性可能都没有实际意义。
5.2.2 最大化你工作的当前价值
“⻛险和预期回报”的经济概念可以解释我们研究中许多看似矛盾的属性和情绪。当应用经济镜头时(⻛险投资和知识2000)，考虑到概率未来值(可能为负)和可用于行动的时间，一个连贯的主题出现了。伟大的工程师通过考虑他们的软件产品的上下文，最大化他们当前行为的价值，并根据可能的未来价值和成本进行调整，从而使自己与众不同。
(明显的)矛盾的第一个方面是，许多受访者讨论了伟大的工程师在设计他们的软件时着眼于未来，例如⻓期和预期的需求，花时间和精力来确保他们的软件能够适应未来的变化(⻅表1个). 然而，其他受访者不同意，认为预测未来是徒劳的。实验、更快的迭代和做出改变的意愿更好。在他们看来，⻓期和预期的需求是有害的属性，会在可能不会、发生的未来上浪费精力。从经济⻆度来看，这些观点是可以调和的。工程决策可能会招致“技术债务”(Kruchten 等人。2012); 因此，努力的当前价值需要考虑到未来可能的服务和维修费用。对于寿命⻓、维修成本高的软件，工程师需要提前考虑。然而，在其他情况下，软件的使用寿命可能较短或维修/更新成本较低(例如，与盒装软件相比，在 线服务);在这些情况下，伟大的工程师可能会正确地推迟未来的成本：
[...] 你在为客戶编写软件?[...] 云?这是一场不同的比赛。如果您正在为云编写软件 [...] 错误的成本并没有那么高。我会修好它。我不必将修复程序发送给您;我会在我的服务器上修复它 [...] 关键是我会冒这个险。— 高级开发主管
(明显的)矛盾的第二个方面是期待伟大的工程师花时间彻底思考这个问题。系统的属性意味着不要仓促下结论，也不要行动得太快；优雅的属性涉及深入思考以提出简单的解决方案；与周围其他部分的配合属性需要考虑与周围组件的关系(⻅表1个)。 然而，许多受访者也希望伟大的工程师能够勇往直前并“去做”。这进入未知属性的意愿是关于在信息不完整的情况下采取行动的意愿，而没有分析麻痹属性的执行明确是关于停止思考的需要(⻅表1个). 从经济⻆度来看，软件只有在部署后才具有价值(例如赚钱)，对于某些产品而言，时间安排会极大地影响这些未来收益。游戏和消费电子产品等产品的市场条件可能会因错过最后期限(例如假期)而导致严重的收入罚款；已部署软件中的缺陷可能正在积极伤害客戶。从这个⻆度来看，关于行动速度的矛盾观点具有经济意义。高质量的代码可以节省未来的维修和维护成本；然而，必须权衡这些节余与因不作为而可能丧失的收入。因此，虽然高质量的代码通常是好的， 但也可能存在一些情况，尤其是接近“交付截止日期”或面临高优先级错误时，
[...] 甚至没有非灵丹妙药。人们有时，甚至我在发版截止日期之前这样做，你会做 一些快速而肮脏的事情，不幸的是它总是发生 [...] 通常，当你这样做时，你会意识到这一点 [...] -主要SDE
⻛险的重要性和预期的经济回报可能因具体情况而异，因为 Microsoft 是一家营利性组织。尽管如此，相关概念——“回归”或“重新打开”——经常在关于开源软件项目错误分类的研究文献中讨论(Anvik 等人。2006年; Ko 和 Chilana2011年).
价值最大化作为一个经济概念，与人类行为的许多方面广泛相关(Ventures and Knowledge2000). 然而，有趣的是，软件工程教育文献(甚至是那些关注软件工程中人为因素的文献)。2015年) 基本上没有提及经济思想在软件工程中的应用。在我们的调查中，经验水平的影响表明工程师需要真实世界的经验来理解何时以及如何完成某些任务。受访者认为，许多事情在理论上或孤立地听起来不错，但在相互竞争的担忧和严格的最后期限(⻅第 4.2.1 节)中放到现实世界的背景下就变得不重要了。相比之下，ACM 的课程 (Shackelford et al.2006年) 和 SWEBOK(IEEE 计算机协会等。2014) 规定了一组技能，但几乎没有关于何时或是否使用这些技能的信息。软件架构和软件验证等主题在理论上很棒；然而，我们的研究结果表明，鉴于现实世界软件工程的经济性，最佳解决方案有时可能是“快速而肮脏的”。
5.2.3 进行知情决策
工程师面临关于构建什么软件以及如何构建软件的无数决策；因此，有效的决策是伟大工程师的一个关键属性。随着工程师在职业生涯中的成⻓，他们面临着越来越复杂和模棱两可的情况，通常会对他们自己和他们的组织产生重大影响。我们认为，获取所需信息的过程是有效决策的最重要方面，而不是结果(结果常常被未来的不确定性和外部因素所混淆)。伟大的工程师通过正确的流程做出明智的决定，从而使自己与众不同。
总的来说，决策属性(第4.1.3) 在四组属性中排名最高；我们发现与“信息收集”相关的属性是最重要的。工程师通常没有做出决策所需的信息；伟大的工程师通过有效地获得必要的信息，然后做出明智的决定。在理性决策框架内观察，系统属性，描述实际上从事 “信息收集”活动，寻求帮助属性，关注寻找最有信息的人，思想开放，数据驱动这两个属性都描述了伟大的工程师愿意让新信息影响他们的决定的意愿：
忘却。就像，五年前我曾经做过的让我成功的事情已经不重要了；事实上，它们现在可能会让我陷入困境 [...] 我开始达到评估 [工程师] 忘却能力的地步。过了一段时间，你所知道的东西中有三分之二或四分之三仍然有价值，四分之一到三分之一是错误的 [...] — 技术研究员
相反，我们专家讨论的许多不良工程师的负面特征是没有收集或没有使用正确的信息来做出决策的症状。例如，在讨论数据驱动属性，受访者感叹一些工程师有确认偏差，只选择确认他们初步理解的信息：
让我感到惊讶的一件事 [...] 即使我们受数据驱动，至少我们试图相信我们是 [...] 一些数据显示给我们，我们想出一些方法来忽略它。所以，也许每个人都认为他们是数据驱动的，但我看到人们想出借口解释为什么数据不适用于他们。我已经看过一百万次了。— 高级 SDE
决策是每个人的日常活动；然而，做出正确决策的过程直到最近才在 Baltes 和 Diehl 的软件开发专业知识理论中受到关注(Baltes 和 Diehl2018). ACM课程中没有提到它。尽管如此，决策制定的各个方面——好的和坏的——散布在整个软件工程文献中。错误分类，由许多研究人员检查(Anvik 和 Murphy2007年; 郑等人。2009; Podgurski 等人。 2003年; 鲁内森等人。2007年; 伯特伦等人。 2010) 实际上是一个决策过程。Gobeli 等 人研究了软件工程团队中有效(和无效)的冲突解决方法，并谈到了决策(Gobeli 等 人。1998). 几乎所有检查工程师日常活动的研究都提到了与团队成员协商以决定如何最好地实现功能或修复错误(Ko et al.2007年; 拉托萨等人。2006年). 现在是软件工程教育工作者和研究人员更加关注其教育和研究工作中的决策制定的时候了。
5.2.4 使他人能够有效地做出决定
笼罩在礼貌的描述中，例如与他人建立共同的理解和创造为每个人共享成功，我们在调查结果中看到了一个主题：请不要让我的工作变得更难。伟大的工程师通过让别人的工作更轻松，帮助他们更有效地做出决定(或者，至少，他们没有让他们变得更糟)来脱颖而出。这方面是一个普遍适用于大多数团队的组织问题(Simon 1973年)，并且可能对软件工程等信息驱动和协调密集型职业尤为重要。这也符合 Baltes 和 Diehl 包含的人格特质宜人性和尽责性(Baltes 和 Diehl2018)。
在解释工程师拥有各种属性的好处时，这个主题浮出水面，尽管更常⻅的是，不具有各种属性的缺点。这种情绪对于诚实的 属性(⻅节4.1.3); 几乎在所有情况下，受访者描述了缺乏诚实的工程师给其他团队成员带来问题的负面情况：
影响力来自信任你的其他人，这种信任的一部分是他们会去，“你知道吗?我知道这个人总是说真话。” 因此，当他们说某事好时，我会完全相信他们，因为他们并没有试图歪曲某些事情或使他们看起来更好或其他什么。— 首席开发经理
管理期望属性包含有关工程师因不说出潜在延迟而使项目脱轨的讨论。自我反省属性要求工程师在意识到当前计划不可行时主动更改计划，同样的情绪也是寻求帮助属性的基础(⻅表1个)。 此外，对于许多受访者来说，创造共同理解的属性是关于伟大的工程师帮助他们理解各种选择背后的原因——通常是陷阱和潜在问题——以便他们做出适当的决定。对于这些属性，受访者讨论了工程师不具备阻止其他人采取纠正措施以避免团队出现不良结果并最终使每个人的工作更加困难的属性：
[...] 你真的想让 [伟大的软件工程师] 有更多的投入。如果有人不同意我们所做的权衡，请发表意⻅ [...] 他们确实参与并发表了他们的意⻅。— 首席开发经理
在研究文献中，很少直接提到不要让我的工作更难。尽管在软件工程工作的各种研究中都有暗示。例如，Ko 等人。成立保持意识成为软件工程师的一个重要关注点(Koetal. 2007年), 拉托萨等人。成立团队代码所有权和护城河(这促进了团队内部的理解并限制了外部干扰)成为一个共同的主题(Latoza 等人。2006年)，以及 Scrum 开发过程中强制要求的站会(Rising 和 Janoff2000) 可能是为了强制信息共享。使用不深入挖掘答案背后原因的研究方法可能特别难以检测到像这样的潜在情绪。因此，元分析等各种研究方法(Radermacher 和 Walia2013) 和二次分析 (Ahmed et al.2012) 在用于研究工程师时可能会在理解上留下空白。
5.2.5 持续学习
我们的研究结果表明，由于软件工程领域不断变化，那些不成⻓和进化的人有被淘汰的⻛险(参⻅第4.1.3)。 因此，我们认为，区分伟大工程师的不是一组特定的知识，而是学习的愿望、能力和能力。
不断学习的主题贯穿于我们的整个学习过程中；受访者经常表示，伟大是随着时间的推移而获得和保持的。这促成了多个相关属性——诚实、思想开放和不断改进——从而在排名中名列前茅(⻅第4.1.3)，以及与学习和改进相关的众多人格属性的高排名。受访者还解释了众多属性如何有助于学习。好奇的属性——想知道事情是如何运作的——是学习背后的一个激励因素：
好奇心 [...] 事情是如何运作的，为什么事情会运作，它们是如何运作的，拥有这种好奇心可能是一个优秀工程师应该具备的一个好品质。想撕开的东西，弄清楚它是如何工作的，并理解为什么。— 首席开发主管
两者都提高了他们做出正确决策的能力，并更新了他们的决策知识，包括学习和不断重新学习如何做出最佳决策。寻求帮助并整合对他人的理解，这两者都涉及有效地向他人学习(⻅表1个).
我们发现，学习新技术技能的能力可能与任何个人技术技能一样重要(如果不是更重要的话)。受访者，即使是同一部⻔的受访者，也使用不同的技术。对于哪个特定技术主题(例如架构)是必不可少的，没有达成共识。相反，大多数受访者强调了学习必要的新技能和技术。
伟大不是一次性的称号。这是一个持续的进步。这与相关工作的观点一致。持续学习的需要与 Baltes 和 Diehl 的软件专⻓理论中的“持续学习”密切相关(Baltes and Diehl2018)，以及 ACM 课程(计算课程联合工作组)中讨论的“持续专业发展”2014). 该法令也包含在许多职业的道德准则中，例如医学(AMA2001年) 和“传统”工程 (NSPE2007年). 尽管持续学习似乎是所有学习型职业的基本方面，但这对软件工程师来说可能是最重要也是最困难的方面。作为一个相对较新的领域，创新和变革的步伐很快：
与其他科学或技术相比，计算机技术还很年轻。每年都有一些新技术，新想法。如果你只对你已经学过的东西感到满意，那么你可能会在几年后发现，你已经过时了 [...] 优秀的软件工程师 [sic]，他不断调查，投资。[原文如此] — SDE2
与大多数专业(例如医学)不同，计算的基础是可以改变的；要求软件工程师警惕地跟上步伐以避免过时：
所以，回到过去，如果你想优化一些你计算指令的性能。处理器变得越来越快，但内存引用却没有。有一天，计算内存引用比计算指令更有意义。除非您意识到这些事情何时会相交，否则您将站在历史的错误一边并感到沮丧。— 技术研究员
5.3 对研究和实践的启示
我们对优秀软件工程师的独特属性的了解可以对软件工程研究、实践和培训产生广泛的影响。我们注意到软件工程可能独有的考虑因素；但是，软件工程师是工程师，是雇员，是人。我们的许多⻅解可能广泛适用于/有益于许多人。
5.3.1 研究人员
我们的发现可能对研究人员有几个影响。首先，为了更好地理解和利用本文中讨论的属性，我们将从对属性进行操作的指标中受益。这些对于使严谨的科学能够更好地理解属性如何变化及其对团队和结果的影响至关重要。这些指标也可能为管理人员识别和培养人才、为新手提高水平以及为教育工作者评估学习成果奠定基础。
其次，我们的发现确定了软件工程方法研究人员可能想要解决的几个痛点。例如，我们讨论了工程师缺少所需信息的问题(参⻅第5.2.3)。 解决这些问题的更好流程(例如通过强制信息共享)可能有助于软件工程团队。
第三，研究人员可能还想更深入地研究文化差异及其对有效软件工程的影响。由于许多软件开发组织是跨国的，研究人员可能想要检查组织应该(或不应该)适应当地文化规范(相对于制定组织标准)的条件。
最后，我们的结果为工具研究提出了几个新方向。例如，我们不知道有任何工具可以帮助工程师更彬彬有礼在电子邮件或评估权衡做决定时。工具研究还可以探索培训工程师，尤其是新手，使其具有理想的属性。
5.3.2 有抱负的软件工程师
我们的发现对新软件工程师有几个可能的影响。显然，我们的研究结果列举了一组优先属性，新工程师可能会考虑通过培训、实践、指导或自我反省来改进这些属性。此外，这些信息还可以帮助工程师更好地向雇主展示自己。无论我们确定的属性是否真的会导致卓越，我们的发现表明经验丰富的工程师(包括经理)重视这些属性；因此，有抱负的工程师可以考虑向雇主展示它们，无论是在简历中还是在面试中。
5.3.3 软件工程负责人
我们的发现也可能对工程师领导者产生影响。我们的研究结果列举了对高级和领导职位的工程师很重要的多个属性，例如指导、提出挑战和实际行动。因此，处于领导地位(或寻求成为领导者)的工程师可能希望改进这些领域。
除了自我提升之外，我们的发现还可以帮助管理人员做出更有效的招聘决策。他们可能会更好地确定适合团队的具有所需属性的候选人。此外，我们的调查结果还表明，当前的招聘做法——通常是一日面试——可以改进。伟大工程师的一些重要区别属性，例如“渴望、能力和学习能力”，需要更多时间来评估。实习计划等方法——历时数月，基于真实世界的项目——可以让管理人员更好地评估申请人的能力和成⻓潜力。
最后，我们的研究结果表明，软件工程师的管理者可能希望在他们的团队中培养理想的品质，建立一种有利于吸引、培养和留住优秀工程师的文化。
5.3.4 教育工作者
最后，我们的发现可能对教育工作者有不同的影响。最重要的是，教育工作者可以考虑增加当前课程中没有的主题课程。虽然决策不是 ACM 课程的一部分(Shackelford 等 人。2006年)，我们发现与有效决策相关的属性是伟大工程师的关键区别属性。
专⻔关于决策的课程(例如西蒙的理性选择模型(Simon 1955年) 或软件工程决策的案例研究) 可能很有价值。
教育工作者可能还想重新审视他们的教学方法。伟大工程师最显著的特征包括如何而不是什么，而软件工程中的大多数说明都侧重于知识(什么)，例如测试和分析技术。教育工作者可以考虑改进如何达到软件工程目标。例如，现有的基于项目的课程可以考虑评估代码的行为和非功能属性，例如优雅、预期需求和有创造力的。教育工作者也可以考虑教学什么时候应使用各种技能，因为我们的结果表明，在现实世界中，避开最佳实践可能具有最大的经济意义。
最后，教育工作者可以考虑明确讨论学生在学校不会学到什么，让他们意识到潜在的知识差距，并使他们能够在学术环境之外寻找机会。例如，像这样的属性自力更生在学术环境中教授可能不合理，通过指导/实习可能会更好地学习。
5.4 有效性威胁
与任何实证研究一样，我们的结果受到各种有效性威胁。首先，有一些威胁构造有效性。明显的问题是参与者对术语的不同解释。我们从一开始就降低了这种⻛险，方法是选择在一个组织中进行我们的研究，那里的员工更有可能达成共识。我们通过进行预测试、根据需要调整和澄清调查问题(例如添加支持性引述和改用“开发人员”一词)以及使用开放式结论问题来发现问题，进一步降低了⻛险。双峰分布的不存在表明没有明显的问题，我们的大样本量和统计测试减少了由于偶尔的误解而造成的噪音影响(考虑到受访者的不同背景，包括许多非英语母语者，这是不可避免的)。
其次，存在多种威胁内部的有效性。FDR 调整的使用以及与在印度和中国有工作经验可能隐藏了其他有趣的关系。此外，我们的分析仅检查了评级和上下文变量之间的一阶关系。虽然，虽然二阶关系可能存在，但我们认为我们的选择是适当的，因为之前很少有研究支持调查二阶关系。我们研究的参与者是一组自选的工程师(特别是后续访谈)；他们的意⻅可能有偏⻅，并且可能存在对排名和关系的其他解释。最后，即使作者是具有现实世界软件工程经验的经验丰富的研究人员，也可能存在对数据的其他有效解释。
三、还有各种有趣的外部的未来工作可能考虑调查的有效性问题。除了经验之外，我们没有针对其他特征(例如性别和非美国软件工程师)进行抽样。尽管我们收到了来自女性(149 份答复，7.7%)和非美国受访者(351 份答复，18.2%)的许多答复，这应该让我们能够发现较大的系统差异，对有趣的亚群进行更深入的研究是值得的。属性的全面性是另一个外部有效性问题。我们使用了一组源自微软工程师访谈研究的属性。此外，尽管我们在调查结束时有一个开放式问题，询问我们可能遗漏的任何内容(没有发现缺失的属性)，但受访者在快速连续看到 54 个属性后识别缺失的能力如何还是值得怀疑的。因此，在其他组织重复我们的调查之前，重复访谈研究以确定可能缺失的属性是可取的。 微软本身也存在一些问题;显而易⻅的是，它是一个单一的组织。我们还明确地对非常有经验的工程师进行了过度抽样，他们可能会表现出特别适合 Microsoft 环境的思维和观点。因此，尽管我们的研究是一个坚实的起点，但在未来，研究人员可能想检查其他情况。例如，受访者讨论了金融和零售等非以软件为中心的行业的不利条件，这些行业会影响很多观点；在其他成功的以软件为中心的组织(例如谷歌)复制这项研究也可能会产生有趣的发现。
5.5 未来工作
本节中讨论的所有问题都是有趣的主题和未来研究的理由。调查不太可能是实验性的（即我们不能将属性分配给工程师而对其他人隐瞒），并且没有任何单一的观察性研究可以建立因果关系。前进的道路是由许多研究人员在许多情况下进行的许多研究，对我们前进的道路进行三⻆测量，加深我们对什么造就伟大软件工程师的理解。
6 结论在本文中，我们对杰出软件工程师的区别提出了全面的、以开发人员为中心的、生态上有效的和科学上严谨的⻅解。随着我们的社会越来越依赖软件，像我们这样的研究和我们的工作可能激发的其他研究将至关重要。毕竟，没有伟大的软件工程师（一个某处座位上的屁股， 输入“提交”），就不可能存在伟大的软件。
致谢作者要感谢参与我们研究的 Microsoft 软件工程师。这项工作得到了 Microsoft、Google 和国家科学基金会 (NSF) Grants CCF-0952733、CNS-1240786 和 IIS-1314399 的部分支持。
参考
略。
出版者注施普林格·自然 (Springer Nature) 对已出版地图和机构隶属关系中的管辖权主张保持中立。
保罗罗力（Paul Luo Li）是美国华盛顿州雷德蒙德 Microsoft 核心操作系统和智能边缘组织的首席数据科学家。他获得了博士学位。2016 年获得华盛顿大学信息科学学士学位，2007 年获得卡内基梅隆大学软件工程硕士学位。除了研究“什么造就了伟大的软件工程师”，Paul 还发表了关于软件可靠性工程、大型规模实验系统、局部差异私有数据的统计分析，以及 AI 和 ML 的许多其他领域。
艾米·柯（Amy J. Ko）是华盛顿大学信息学院的副教授，她在那里研究编程的人性化方面。她最早的工作包括自动回答有关程序行为的问题以及支持调试、程序理解和重用的技术。她后来的工作研究了开发人员和用戶之间的交互，以及通过帮助系统在网络范围内聚合用戶意图的技术；她与他人共同创立了 AnswerDash，将这些想法商业化。她最近的工作调查了编程技能和学习这些技能的新方法，包括编程语言知识、API 知识和编程策略。她获得了博士学位。2008 年在卡内基梅隆大学人机交互研究所获得博士学位，2002 年获得俄勒冈州立大学计算机科学和心理学荣誉学位。
安德鲁·⻉格尔（Andrew Begel）是美国华盛顿州雷德蒙德微软研究院 Ability 小组的首席研究员。他获得了博士学位。Andrew 于 2005 年获得加州大学伯克利分校计算机科学博士学位。Andrew 专注于研究和帮助自闭症患者实现就业并促进社交互动。Andrew 还探索了软件行业不断变化的工作⻆色，并研究了人工智能技术对软件工程日益增⻓的影响。
