软件项目失败的心理原因

免责声明

本文是我对软件工程领域现状的个人看法。本文并非科学论文，因此许多陈述有意大胆直白，以使文本简洁。我尽力根据自己的观察和现有资料指出软件项目失败的心理原因，但我既不是专业的心理学家也不是统计学家，而且我很可能完全错了。此外，我没有数据来支持这些陈述，因此请带着怀疑的态度对待。

“我们真正的发现来自混沌，来自那些看起来错误、愚蠢和荒谬的地方。”
—查克·帕拉尼克

永无止境的泥沼

软件项目失败，定义为未按时完成、预算超支、功能缺失和故障，在软件行业中普遍存在。关于这种情况的原因已有很多论述，指责不切实际的项目目标、对所需资源的不准确估计、定义不清的需求、糟糕的报告、未管理的风险、糟糕的沟通、不成熟的技术、草率的开发实践、糟糕的项目管理、利益相关者政治或商业压力。这些大多将重心放在开发过程的管理方面，正确地将其识别为这些失败的原因。在我看来，基于多年的观察，这种困境的另一个因素几乎完全被忽视或有意省略——程序员本身。

在本文中，我将使用“程序员”一词，不仅指软件开发人员，还指技术负责人、架构师和需求/领域分析师，他们都负责软件开发过程的技术部分，并对软件项目的成功或失败负有同等责任。

“聪明”的程序员

社会普遍认为，在程序员群体中也普遍认为，“程序员很聪明”，他们是从社会中最聪明的一部分人中招募而来的。我认为这基于一个错误的假设，即编程机器很困难。我不敢苟同这个假设，因为实际上，编写代码并不比编写一份恰当的烹饪食谱（两者都是关于如何做某事的明确指示）更困难。计算机本质上是非常简单的机器，基于变量、算术、向量等基本数学概念，以及条件执行、重复和工作委托等一些现实世界概念。这些概念非常基本，我们要么直观地知道它们，要么在小学就学习过。编程确实需要一定程度的文化素养，这排除了不合适的人，但声称某人因为能够做平均12岁孩子能做的事情而“特别聪明”，这是一种强烈的夸大。由于人类智力的分布由钟形曲线给出，程序员智力分布由相同的钟形曲线给出，只是缺少图表的左侧部分。

根据维基百科，完成1到3年大学学业的人智商至少为104，我怀疑这是“24小时学会Java”型程序员的最低智商。这意味着，按照自然分布，行业中存在相当数量的“普通人”。

挑战的本质

编码不是挑战。事实上，代码是人们最不愿意花钱的东西（尽管讽刺的是，它最终是产出的最重要东西）。真正的挑战，也是程序员真正的职责，是解决客户面临的问题，很可能是通过代码，但不一定是。这些问题通常只是部分“技术性”的，常常是社会性的，常常是复杂的，常常是棘手的。随着问题复杂性的增长，解决它所需的努力、智力、知识和奉献精神也随之增长，有时甚至是指数级的。识别复杂性、限制复杂性和最小化复杂性是程序员的最终目标。这使得门槛变得如此之高，以至于一个普通人可能无法展现出胜任这项工作所需的足够个人素质，并因此显得**相对**愚蠢。

正如大卫·帕纳斯所说：“我听说有人自豪地宣称他们构建了许多大型复杂系统。我试图提醒他们，如果他们花更多时间在‘前端’设计上，这项工作可以用一个小型简单系统完成。庞大的规模和复杂性不应被视为一个目标。”

4 + 2 模型

在编程语境下，明确定义“愚蠢”是必要的。

“一个愚蠢的程序员是指那些在软件产品中引入复杂性，从而对其他程序员、客户或整个公司产生负面影响，同时并未从中获得任何收益，甚至可能对自己产生负面影响的人。”

我所说的“引入复杂性”，指的是未能通过使用所谓的“蛮力”解决方案来降低软件所解决问题的固有复杂性，或者实际上引入了偶然的（通常是技术性的）复杂性，如果对解决方案给予更多的思考和关注，这些复杂性是可以避免的。

我所理解的负面影响，是指工作量增加、效率降低和成本更高。

遵循卡洛·M·奇波拉的研究，程序员可以分为四类：智能型、强盗型、无助型和愚蠢型，另有天真型和无知型两类。重要的是要记住，所呈现的模型是动态的，每个人都会根据各种内部和外部因素在类别之间迁移，但似乎**成熟**的程序员在大多数时候倾向于保持在一个类别中。

**智能型**程序员能够以一种方式来阐述问题和解决方案，使得他自己及其他人工作的复杂性得以降低。例如，一个具有精简、连贯功能和定义明确的接口的软件模块，易于实现、测试和集成。通过深入思考所解决问题的更广泛范围，智能型程序员能够为自己、部分/整个组织以及客户带来净积极效应。这些程序员通常被称为“10倍程序员”，因为他们仅凭自己就能超越整个团队的表现。

另一方面，**强盗型**程序员主要专注于自己的任务。他的首要任务是以牺牲他人为代价来优化自己的表现。这类程序员通常不攻击问题本身，而是力求限制自己任务的范围（以减少工作量或争取更多时间），从而影响他人的任务。此外，这类程序员为了短期内获得管理层认可而牺牲了代码质量，如灵活性、性能、可测试性，这些在长期来看是有益的。这类人通常从自私的角度看待整个产品。他们行动的净效应可能是积极的也可能是消极的，这取决于个体是倾向于智能型还是愚蠢型。此外，这类人经常表现出过度的自信和表面专业性，以支持他们在组织中未经获得的地位（表现出冷漠或火爆的傲慢）。这些人通常被称为“牛仔程序员”。

**无助型**程序员通常致力于公司的成功，并赞扬团队合作而非个人主义。他们通常与强盗型程序员智力相当，但目标导向相反，他们尽力以牺牲自己的时间和表现为代价来支持组织。他们倾向于妥协自己的设计和代码质量，通过引入原本可以避免的复杂性，以使事情“对他人更容易”，即使这可能会给自己带来更多问题。他们倾向于无偿修复他人的代码，无偿加班，或在业余时间贡献。他们通常愿意教育他人，希望能帮助他人或整个组织。这些行动的净效应取决于个体是倾向于智能型还是愚蠢型。这类人通常在组织中保持低调。他们可能会因其贡献而受到直属经理的认可，但由于他们自愿引入的可避免复杂性导致绩效评估不佳，他们很少因其努力而获得奖励。

**愚蠢型**程序员是遇到过的最糟糕的一种。他是一个通常不知道自己在做什么的人，除了熟悉编程语言外，往往缺乏编程所需的任何技能。这样的人通常只能提供勉强解决问题的权宜之计。通常，缺陷数量超过已实现功能的数量，代码难以甚至无法测试，并在整个组织中造成负面连锁反应。他工作质量低下（或缺乏）对组织和自身都产生负面影响，因为他经常花费长时间无偿加班来解决自己制造的问题。这样的人通常在组织的某些角落保持低调，不被管理层注意。他们从不进步，通常很高兴有份工作。愚蠢型程序员和无知型程序员仅因薪水而被行业吸引。这些程序员有时被称为“1/10程序员”，因为他们能使整个团队的绩效陷入困境。他们通常数量不多，因为最终会被发现，但他们造成的危害与其数量不成比例。

另外两种个体是天真型和无知型。

**天真型**程序员是指专注于自己的工作，而不关注大局的人。天真型程序员的工作质量尚可，但通常对除了自己任务之外的任何事情都不感兴趣。从组织角度看，他们是隐形的。他们倾向于精确地朝九晚五工作，很少晋升。他们展现出流水线工人的心态，易于管理，但如果没有适当的管理，如果他们在垂直轴上的位置接近零，他们的表现可能会停滞不前。

最后一类是**无知型**程序员。无知型程序员最显著的特点是“我不在乎”。他对自己的工作完全不感兴趣。他只提供足以不被解雇的质量，不考虑他人的任务或组织目标。他通常不合作，对同事不响应，导致整个组织范围内的负面影响。另一方面，他可能会通过向其他组织成员寻求帮助而造成干扰。他展现出流水线工人的心态，将自己视为一种“有机编译器”，应该将一套工件转换为代码，而无需投入太多智力努力。他更强调遵守开发流程，而非实际完成的工作。他对缺陷的态度通常是“我会在下一个冲刺中修复”。他可以被管理，但尽管管理层努力，他可能无法产出甚至能抵消其薪水的价值。他可能会表现出冷淡的傲慢。我个人认为，这一类别最为常见。

智力和奉献精神只是整个图景的一部分，将在以下段落中全面展示。

城门的野蛮人

根据以下文章，世界上的程序员数量每五年翻一番。如果我们大胆假设十年经验能让人成为专业人士，且平均工作四十年，这意味着只有四分之一的程序员人口经验足够丰富，能够正确地开展工作。与更稳定的学科相比，这个数字令人担忧，在那些学科中，人们可以预期四分之三的人是经验丰富的专业人士，只有一人是学徒。更糟糕的是，我敢于进一步挑战这一点。

教育的困境

首先，我想挑战“计算机科学学位具有相当价值”这一说法。程序员的指数级增长意味着对计算机科学教师的指数级需求，这又意味着经验丰富的计算机科学教师与新手教师的比例再次是1比3。这意味着大多数计算机科学学生由年龄不大，通常根本没有实践经验的人（通常是博士生）教授。我怀疑这种教学很少超出“照本宣科”。结果是，计算机科学毕业生能够编写代码，但仅此而已，因为没有人教他们软件工程的真正含义。当然，这仅在假设每年每个教师的学生数量保持不变的情况下成立（否则，教育质量下降得更快）。

无尽的无知之海

另一个重要的事实是，大学所教授的与行业需求之间存在不匹配。许多大学教授计算机科学，而行业需要软件工程技能。问题在于，工程技能往往无法教授，只能“通过实践”习得。这意味着，要成为一名软件工程专业人士，一个人需要花费职业生涯的前十年进行实验、失败、从中学习并自学。这需要真正的兴趣、奉献和某种激情。假设这些品质在毕业生中的分布遵循钟形曲线是合理的。如果是这样，那么只有大约20%的毕业生将职业生涯的前十年用于刻意学习，60%会在此过程中获得一些知识，而20%则几乎一无所获。这意味着十年后，只有20%的程序员成为真正的软件工程专业人士。这使得行业前景更加可怕，真正的专业人士数量仅为5%。如果我们假设其中强盗型、无助型和天真型占50%，那么所谓的“x10程序员”数量约为2.5%。

钟形曲线的谬误

2.5%的数字与钟形曲线分布相协调，其中距离平均值超过双标准差的值占2.1%，但假设程序员能力分布由标准钟形曲线给出（如在任何稳定的工程领域可假定）是错误的。考虑到三分之二的人口或多或少缺乏经验，以及其余50%的专业水平低于平均水平，程序员能力分布实际上严重偏向于不称职（参见图2）。

巨大的误解

程序员是技术导向的。他们因为技术偏好而被计算领域吸引。然而，他们的工作并非像他们经常认为的那样是编写代码，甚至也不是创建软件。他们的工作是解决客户的问题，而软件只是实现这一目标的一种手段。遗憾的是，他们很少能理解这一点。

解决客户问题需要的远不止编写代码。它主要需要获取领域知识，以便能够与客户沟通。它需要深入客户的世界，以便能够理解他们的需求。熟悉特定领域的程序员不仅能够编写代码，而且能够真正创建解决方案。否则，他就是盲目的。作为领域专家的程序员效率更高，因为他可以自己回答更多问题。大多数程序员对领域一无所知。他们对此不感兴趣。他们故意将自己降级为“有机编译器”，因为这更容易。他们不明白公司和他们自己为此付出了代价。

书呆子文化

程序员常常从学生群体中那些书呆子类型中招募，他们通常在社交技能方面存在缺陷。正如杰拉尔德·M·温伯格所描述的：“社会心理学家告诉我们，存在不同的人格类型[…]。在普遍的人格特质中，有一种是根据三个‘维度’来衡量的——一个人是‘顺从’、‘攻击性’还是‘超然’。顺从型的人格特点是喜欢‘与人合作并乐于助人’。攻击型的人想‘赚钱和声望’，而超然型的人则想‘独处并富有创造力’。

现在，每个人都包含这些特质的混合体，但大多数人更倾向于一个方向。毫无疑问，当今编程领域的大多数人都倾向于‘超然’方向，这既是个人选择，也是因为程序员的招聘政策通常旨在寻找这样的人。”

许多未来的程序员选择与计算机而不是人互动，因为在这种关系中，他们是发号施令的一方，而计算机通常不会反对（除非代码无法编译，但那是非个人性的）。他们是那些曾被欺负的瘦弱男孩，终于找到了可以控制和支配的人。随着时间的推移，他们仍然是同样的书呆子，只是年纪大了。

正如温伯格先生所说：“程序员最容易识别的人格需求之一是适度的‘整洁’，表现为轻微的强迫症，即保持文件整齐有序[…]。另一个重要因素是[…]少量的‘谦逊’，以防止‘程序员学会一些简单技术后，感觉自己是专家，然后被计算机不可抗拒的力量击垮’[…]。谦逊的另一面是‘果断’，即性格的坚韧。程序员的工作是完成任务，而完成任务有时需要绕过障碍、跳过障碍，或干脆将其击倒。”

在我的职业生涯中，我发现大多数这些障碍并非技术性的，而是社会性的。它们需要挑战他人，让他们走出舒适区，并对经理说“不！”，换句话说，这需要勇气。许多程序员不知道如何处理冲突，所以他们宁愿避免冲突（天真型和无助型），从而为最终的失败贡献了一份力量。

无知者的自信

尽管我之前估计了行业中非专业人士的数量，但我并未看到程序员数量大规模下降。我没有遇到大量程序员每年仅仅因为意识到自己不适合编程而转行。我相信这背后的原因（当然除了薪水）是达克效应，它“是一种认知偏差，能力低下的人拥有虚幻的优越感，错误地高估自己的认知能力。虚幻优越感的认知偏差源于能力低下的人无法认识到自己能力的不足。在没有元认知（自我意识）的情况下，能力低下的人无法客观评估自己的能力或无能”。换句话说，不专业的程序员无法识别自己的不专业，因为他们不知道什么是专业。他们表现出无意识的无能。此外，他们也无法充分评判自己不专业的同行。这意味着，由于真正的专业人士稀缺，存在大量完全由不专业的程序员组成的团队，他们自我感觉良好，仅仅因为团队中没有人能够识别他们的低水平。我不敢在此明确表态，但我怀疑这种效应在无知型和愚蠢型中最为普遍。

领导者的无力

在能力的另一端，坐着另一个肮脏的野兽，名为冒名顶替综合症。这种心理现象困扰着那些达到最高水平的天才个体——无意识的能力。它“是一种心理模式，个体怀疑自己的成就，并持续内心恐惧被揭露为‘骗子’。尽管有外部证据证明他们的能力，但经历这种现象的人仍然坚信自己是骗子，不配拥有他们所取得的一切。患有冒名顶替综合症的个体错误地将自己的成功归因于运气，或者是通过欺骗他人认为他们比自己认为的更聪明的结果”。这意味着，一部分顶尖专业人士（如果假设是正态分布，则为20%）未能成为技术领导者，仅仅因为他们不认为自己是专业人士。这些人认为他们成功解决的问题是如此简单，以至于任何人都可能做到，包括那些不称职的人。他们未能识别同行的无能，或未能揭露它，从而维持现状，这最终会影响到他们。我怀疑这种现象主要影响无助型和天真型，以及一些倾向于无助的智能型。

内疚驱动的开发

众所周知，程序员对他们所处理问题的复杂性过于乐观。事实上，不切实际的项目目标，通常在时间表方面，是项目失败最常见的原因之一。许多人试图回答如何提高程序员估算能力的问题。我则试图探讨“为什么”。程序员过度承诺的第一个原因是，在被要求提供估算时，他们对问题缺乏充分的理解。正如大卫·帕纳斯所说：“人们倾向于低估任务的难度。过度自信解释了我所看到的许多糟糕的软件。做得好是艰苦的工作。走捷径会把你带到错误的方向，而且往往会导致灾难。”这是一个完全有效的原因，但在我看来，也有一个心理原因。那就是内疚。

每个人都会未能交付。业余爱好者十次中有八次失败。专业人士十次中有两次失败。程序员在职业生涯开始时不可避免地会未能交付。失败会引起内疚感，这就是恶性循环的开始，其运作方式如下：

1. 程序员向管理层做出乐观承诺。
2. 程序员未能兑现承诺。
3. 程序员为了弥补之前的失败，又做出了另一个过于乐观的承诺。
4. 他再次失败，循环重复。

如果没有任何改进，这个循环可能会贯穿程序员的整个职业生涯。这就是愚蠢型和无助型（尽管原因不同）最终的结局。这就是导致缺乏信任的原因。这就是导致微观管理的原因。

有两种方法可以摆脱这种困境。第一是自我提升。一旦技能增长，任务就会变得更容易、更可预测。人们也会学到更好地预见可能出现的潜在障碍。这就是智能型程序员处理问题的方式。第二种是通过少承诺来降低风险，当估算远远超出实际完成任务所需时。这就是强盗型和无知型程序员最终的选择。这就是导致停滞不前的原因，因为每一次进步都被视为成本过高。

敏捷的必然失败

敏捷软件开发是当今做软件的既定方式，但事实证明它并没有很好地兑现其承诺。我坚信这是因为敏捷软件开发只有在由有能力、聪明且勇敢、真正对客户领域感兴趣的程序员执行时才有机会发挥作用。《敏捷软件开发宣言》明确列出了其原则：

• “**业务人员和开发人员**在整个项目期间必须**每天紧密合作**。”——需要对客户领域感兴趣；
• “围绕**有积极性的人**构建项目。给予他们所需的**环境**和**支持**，并**信任他们**完成工作。”——需要积极性和激情；
• “持续关注**技术卓越**和**良好设计**能增强敏捷性。”——需要能力和智慧；
• “**简洁**——最大化未完成工作量的艺术——至关重要。”——也需要能力和智慧；
• “**最佳架构、需求和设计**出自**自组织**团队。”——需要能力、智慧和勇气。

敏捷软件开发的失败是不可避免的。假设行业中智能程序员的数量约为2.5%（1/40），而Scrum团队的最大规模为9人，那么平均Scrum团队中至少有一名智能程序员的概率低于25%。如果团队只由无助型、天真型、强盗型、无知型和愚蠢型程序员组成，结果很少是积极的。

面对敏捷软件开发的失败，公司又回到了瀑布模型，这是与“流水线工人”心态的程序员一起完成任务的唯一方法。或者，他们假装“敏捷”，但在其上层却采用瀑布流程。两者都会带来巨大的流程开销，这往往会导致项目失败。公司未能认识到的是，你不能用流程来替代才能、知识、智力、奉献和关怀。这是一个双输的局面，因为任何流程都无法成功应用，因为不可能管理糟糕的程序员以取得成功。

苦药

我找到了大卫·帕纳斯这段富有启发性的引语：

软件工程中最常被忽视的风险是“不称职的程序员”。有估计称，美国所需的程序员数量超过20万。这完全具有误导性。这不是数量问题；我们面临的是质量问题。一个糟糕的程序员一年内可以轻易创造两个新职位。雇用更多糟糕的程序员只会增加我们对他们的感知需求。如果我们有更多优秀的程序员，并且能够轻易识别他们，我们将需要更少，而不是更多。”

如果项目延期，解雇糟糕的程序员比雇用更多他们更好。至少，他们不会妨碍优秀程序员。

不解雇程序员是一个主要问题，因为行业中缺乏问责制。演员在每部电影后都会被解雇，所以他们每次都感受到表现良好的压力。程序员，由于人为创造的需求，每次都不会感受到展现高绩效的压力，因为他们可以在事情变糟之前跳槽（他们的无能被发现）。这助长了更多的无能和愚蠢。

第十三条原则

遵循敏捷的12项原则，我还要补充一条：“不要雇用愚蠢的程序员。”

不要与图2中虚线对角线以下的程序员打交道，因为他们会产生负净值，并不可避免地导致软件项目失败。识别并解雇他们。**最佳绩效组合是由智能型领导天真型和无助型**，如果能严格控制一些智能型强盗型（前提是他们拥有一些有价值的能力，足以抵消微观管理他们的成本——如图形设计、硬件设计、深入的领域知识等），也可以是少数。此外，要警惕过多的无助型，因为他们的无助最终会影响你。

新希望

上述文字可能暗示我是一个自视甚高的优秀程序员，试图评判那些不幸的同行，但事实并非如此。我希望这段文字能为软件项目失败的原因提供一些启示，在我看来，这些原因尚未得到充分的探讨。我希望它能帮助开发人员在我所描述的多维空间中定位自己，并找到改进的方向。我希望它能帮助经理识别团队的不足并实施适当的纠正措施。它无疑帮助我更好地理解事物，在周围的混乱中找到更多的秩序，我也希望它能为每一位读者服务。

附录A. 归咎于狗

正如我在第一章中所写，管理不善在软件项目失败中占有相当大的份额，但仅仅归咎于管理者，尽管很流行，却忽视了等式的另一部分。为了更好地理解这个问题，我们假设一个经理被分配了一个新项目和一个团队来执行它（这本身就是错误的，因为经理应该自己组建团队），并考虑四种可能性。

如果**经理**和**团队成员**都**有能力**，那么项目成功的可能性非常高（他们会尽一切努力使其成功）。

如果**经理**和**团队成员**都**无能**，那么项目在开始之前就注定要失败（这无需解释）。

如果**经理无能**但**团队成员有能力**，那么项目的成功在很大程度上取决于人们绕过和取代无能经理的意愿和能力。团队需要自选一位“影子经理”，他以降低团队生产力为代价来完成经理的工作。如果经理本人乐于“放弃”其职能（并成为一个摆设），那么项目可能会成功，否则将预期高员工流失率和项目失败。

最后一种可能性是**有能力的经理**与**无能的团队**捆绑。在这种情况下，项目成功是不可预期的，因为即使最好的计划也无法由指定人员正确及时地执行。缺陷、错误、权宜之计和进度延迟将堆积如山，最终导致灾难。在这种情况下，一位有能力且有远见的经理有三种选择：

• 他可以将问题上报给高层管理，并投票**取消项目**，以免造成损失（这需要勇气和良好的分析能力）；
• 他可以解散团队并以额外费用启动新的招聘流程（这需要更多的勇气，因为它需要面对面挑战他人）；
• 他可以**离开**项目或公司，然后当不可避免的灾难最终发生时，被其继任者和团队指责（这无论如何可能都是最好的职业选择）。

总而言之，重要的是要记住，即使是最好的骑师也无法骑着一匹死马赢得比赛，而给他更多死马并不能增加他的机会 ;-)

附录B. 成为强盗型程序员是最佳策略吗？

警告：本章内容纯属推测。

社会建立在互惠互利的概念之上。社会成员之间交换商品和服务时，债务记录会“储存在记忆中”。这比常规交易更有效率和灵活性，并增加了社会成员之间的人际关系。事实上，如果没有互惠互利，人群甚至无法形成社会，而只会形成一群独立的隐士。同样的机制也适用于雇佣关系，因为公司本身就是一种社会。尽管实际合同已签署且款项已处理，但工作和薪酬的实际范围、质量和时间往往在很大程度上是流动的，许多合作都建立在相互信任的基础上。

在一个运作良好的社会中，长期生存的最佳策略是遵守规则、合作并互惠互利。另一方面，短期内最佳策略是从尽可能多的社会其他成员身上榨取价值，却从不回馈。这种策略之所以有效，是因为在互惠社会中，每个成员都被赋予了一定的信任额度。这使得成员之间能够进行互利互动。短期策略可能非常有效，直到骗子名声变坏并被排斥为局外人，除非……骗子可以轻易地迁移到新的社会。对程序员的高需求和缺乏正式认证，加上普遍的匿名性，使得公司（社会）之间的这种迁移变得极其容易。一个骗子（强盗型程序员）可以剥削公司，通过收取薪水并建立自己的专业作品集，却几乎不回馈任何东西（只付出足以通过操纵绩效指标保持不被发现的努力），并在合适的时机（通常是在被发现之前）跳槽到另一家公司（通常伴随着加薪和晋升）。在这种情况下，如果反复应用，最佳短期策略就变成了最佳长期策略。

就我个人而言，我认为人们成为强盗型程序员有三个原因，尽管可能还有更多。

首先，有些人天生就是骗子，患有反社会人格障碍。这类人通常将他人视为资源，可以按需利用。我假设这类人在这个职业中的数量很少，因为其他职业更适合他们（如直销或政治），但仍然可能遇到。同样的行为模式也可能出现在患有自恋型人格障碍的人身上，他们的主要动机是对赞美的渴望（我称他们为“名人程序员”），但我认为他们比反社会型更少见。

人们成为强盗型程序员的第二个原因是懒惰。有些人表现出极低的责任心，根本不愿意诚实工作。这类人倾向于制造大量信息噪音，参加大量会议，并且通常除了生产性工作之外，什么都忙（通常身兼“企业架构师”或“产品策略协调员”等头衔）。这使他们能够靠生产力的幻觉谋生，直到残酷的现实来验证它，但那时他们通常已经离开了。

成为强盗型程序员的第三个原因（可能也是最令人心碎的原因）是当公司未能满足智能程序员的内在需求时。这通常发生在（令人惊讶地普遍存在的）“例行公事”模式下的公司，这些公司被杰拉尔德·M·温伯格描述为极度专注于流程，培养“超级英雄经理”的神话，并总是寻找灵丹妙药，他们不理解软件开发的特殊性。在这种情况下，智能程序员的最佳策略是离开，但有时其他因素迫使人们留下。当这种情况发生时，程序员自然会通过最小化努力来寻求付出与回报之间的平衡。当然，这会产生需要应对的羞耻感和内疚感。应对内疚和羞耻最直接的合理化是：“是的，我无所事事地领取薪水，但这公司太蠢了，活该被掠夺”或“是的，我无所事事地领取薪水，但很多人也一样”。从那时起，苦涩和犬儒主义随之而来，商业和程序员之间的不信任盛行，从而固化了整个行业普遍存在的“例行公事”模式。

附注

如果你想了解我对软件开发真正含义的看法，以及为什么程序员能力是最关键的因素，请阅读我的另一篇文章“作为价值领域研究的软件开发”，它为上述文本提供了背景。

历史

• 2019年5月28日：初始版本