大多数管理者根本不知道程序员实际做什么。

最近我一直在思考以下三个问题：1）科技行业正在发生的大规模裁员；2）目前推动远程办公人员重返办公室的趋势；3）最近围绕人工智能的狂热。虽然这些问题涉及诸多因素，但我认为它们之间存在一个共同点：太多“开发经理”对软件工程师的实际工作内容知之甚少。

在深入探讨细节之前，我想先说明一点。为了本文的讨论，当我提到“开发经理”时，我将采用非常宽泛的定义。具体来说，我使用“开发经理”来指代任何负责管理软件开发人员（或整个开发团队）工作成果的公司员工。

软件开发管理模式多种多样。有时，你的“开发经理”可能和你一样是技术程序员。但也可能是高管（例如首席技术官）、项目经理、产品经理、业务分析师——或者几乎任何其他职位。然而，我在这个行业待的时间越长，就越发确信，无论头衔如何，真正理解我们工作本质的人寥寥无几。

反直觉的

乍听之下，这似乎是一个奇怪的前提。“软件工程师是做什么的？”这个问题，答案看似简单（也显而易见）：我们编写软件！（废话……）但如果你从事代码编写工作超过几年，你可能已经注意到，每天相当一部分时间并非花在你的集成开发环境（IDE）里。

会议

首先，软件工程师通常会被各种各样的会议所困扰。团队内部会议（例如，站会、演示会、代码审查会）。与管理层的会议。与客户/利益相关者的会议。甚至还有一些与你的核心工作职能无关的会议。（例如，“全体员工大会”。）

我曾经在一家大型银行担任“IT经理”。我带领一个小团队，负责管理银行公共互联网平台的系统。我的工作需要亲力亲为，我不仅要直接参与开发项目，还要履行一线经理的职责。

有一天，我安排了四个会议：上午9点到10点、11点到12点、下午1点到2点以及3点到4点。第二天，我的主管要求我汇报团队前一天的工作进展。我向他简要介绍了已完成（和未完成）的工作后，他问我：“那你昨天写了什么代码？” 我直截了当地告诉他，我昨天没写任何代码，因为我安排了四个会议。他接着问我：“但这些会议只用了四个小时。为什么剩下的四个小时你没写代码？”

我的主管完全不理解，我一天要开四个会，每隔一小时就开一次，根本没有时间坐下来真正写代码。我日程表上的每个会议都需要一些“准备工作”。而且每次会议都会产生一系列“要点”和后续沟通，我需要会后立即处理。这意味着，在会议间隙，我最多只有30分钟的时间可以真正写代码——而对于任何需要认真思考的工作，我根本不可能在30分钟内突然投入到某个任务中并完成任何有意义的工作。

团队合作

除了大多数软件开发工作中没完没了的会议之外，通常还需要一定程度的“团队合作”。你可能需要帮助别人解决问题，或者帮助新人快速上手，或者花些时间调整部署流程，或者审核其他人的拉取请求，或者花时间分析日志，或者……总之，这样的例子不胜枚举。

大多数这类“团队协作”任务很少能交付令人满意的成果。它们通常无法满足迭代冲刺的要求，也无法带来让客户满意的新功能。它们通常被定义为繁琐的体力劳动。但这并不意味着这些任务毫无必要。事实上，如果完全没有人去做这些任务，团队的高效运作可能会彻底停滞。

阅读/研究/理解

即使你幸运地沉浸在代码中，也不一定意味着你在编写新代码。关于开发人员阅读代码和编写代码所花费的时间，有很多估算数据。这些估算结果总是表明，阅读代码所占的时间远比实际编写代码要多。然而，当你阅读代码时，你很少能交付任何管理者可以量化为“进展”的实质性成果。

盲人管理

这些“软性”任务的问题在于，管理层往往视而不见。如果你坐下来跟他们解释这些任务，他们只会口头上承认它们的重要性。他们会声称理解开发人员的工作中有很多任务不会直接产生交付成果——然后……他们马上就会转过头来问：“但是……你今天肯定会把那些交付成果完成的，对吧？？？”

平心而论，这未必是他们故意视而不见。他们当然需要确保按时完成交付物，也当然会把大部分精力放在这些交付物及其相关的时间节点上。但有时候，当你告诉他们你不得不临时花一天时间搭建新服务器时，他们却想当然地认为交付日期不会受到影响，这种认知上的脱节确实令人恼火。

你看，这就是软件开发的核心问题：

那些没有直接参与软件编写的人，很难理解工作中非编码方面的因素，也很难在管理预期时考虑到这些因素。

理论上，他们知道几乎任何软件工程里程碑都涉及许多非编码任务。然而，在实践中，他们很难理解这些任务具体是什么，或者需要多长时间才能完成。

即使你特意向他们详细说明所有非编码任务——即便工作正在进行中——他们仍然以交付成果为核心进行思考。任何无法直接与交付成果挂钩的工作都可能让负责软件开发工作的管理人员感到沮丧。

提防“技术经理”

解决这个问题的一个简单方法似乎是确保软件工程师的管理人员对软件工程流程本身有深刻的理解。换句话说，只要“开发经理”本身就是程序员出身，我们就能避免这些误解……对吧？

嗯……

虽然我确实遇到过一些不擅长技术的非技术型经理，但我不得不说，我也遇到过一些曾经是程序员的经理，他们的表现同样糟糕。这听起来可能很奇怪。毕竟，如果一个人不久前还在写代码，那么他们应该对开发人员日常工作中涉及的所有“软性任务”都有着深刻的理解……对吧？

嗯……

问题在于，在许多组织中，“开发经理”被安排参加大量会议，花费大量时间与开发团队以外的人员沟通，以至于他们几乎无暇顾及实际的工作进展。他们可能疲于奔命，试图掌握六位（甚至更多）程序员的日常工作。他们很少有时间亲自审阅代码，或与开发人员进行一对一的交流。这意味着，开发经理最终往往只能关注那些其他不具备直接编程知识的经理也会关注的基本“指标”（交付成果和时间节点）。

有时候，开发经理的技术知识反而会成为一种负担。因为他们可能只记得自己当年参与代码开发时（通常是几年前）完成某个特定任务所需的步骤，而很难理解当前代码库是如何演变（或者说退化）的。

【有趣的小提示：如果你在站会上忍不住想说“这项任务比预期花费的时间长一些，因为这一段代码简直一团糟”，你最好先快速浏览一下代码，看看是谁写的。很有可能是你的开发经理git blame几年前写的。而有些开发经理可能缺乏足够的心理承受能力来应对这类评论。】

问责制的幻觉

我花了很长时间才意识到我和我的开发经理之间可能存在的这些沟通障碍。因为现代软件工程流程通常给人一种感觉，那就是它们本身就具有（甚至可以说是……非常详尽的）文档记录。当我处理一项任务时，审计/问责记录通常是这样的：

1. 某个任务管理系统（例如 Jira）会分配给我一项任务。该任务包含各种关于任务本身的元数据。理想情况下，它应该包含预估时间和详细的说明，明确指出需要完成的具体内容。
   

2. 这项任务的编码部分全部包含在一个或多个提交中。我在每个提交中都添加了注释（例如，提交信息）。
   

3. 在整个编码过程中，我每天都会进行口头汇报（通常是在站会上），解释我的进度和预计完成时间。
   

4. 完整的代码还包含单元测试，这些测试能够很好地描述代码预期执行的操作。
   

5. 当我确认提交的代码满足任务要求后，我会提交一个拉取请求。我通常会在拉取请求中添加更多注释，以帮助其他审查代码的开发者。如果其他开发者对我所做的任何操作有疑问，他们也会在拉取请求中添加自己的注释，有时会引发直接记录在拉取请求中的讨论。
   

6. 代码合并完成后，除了更新工单本身的状态外，我还会在任务管理系统中添加更多备注。
   

因此，当我真正完成一项任务时，我已经为以下三处添加了我自己的文档：1）每个单独的提交；2）包含这些更改的 PR；3）跟踪更改状态的工单。这还不包括每天大量的口头汇报。

感觉每个任务都要写这么多文档，是不是有点太多了？有了这么详细的文档，我的开发经理（或者团队里的其他人）应该不会对我的工作内容或者为什么耗时这么长感到困惑了吧……对吧？

嗯……

不幸的是，我发现我的开发经理经常不花时间监控这些沟通渠道。他们通常没有精力去审核提交或拉取请求。他们也常常没看过我添加到任务管理系统中的任何文档。更糟糕的是……有时我每天站会口头汇报进度时，他们甚至都没在听。

换句话说，尽管进行了所有这些状态跟踪，我仍然多次遇到这样的情况：我的开发经理对此一无所知。他们“听到”的只有两个问题：1）任务完成了吗？2）如果还没完成，什么时候完成？除了这些基本信息之外，开发经理通常对我（或团队中的其他任何人）每天的实际工作内容知之甚少，甚至一无所知。

去年我在亚马逊工作时，我的开发经理以前也是程序员。几个月后，他不知怎么地觉得我“落后了”。尽管从很多指标（例如提交次数、PR、完成的任务、代码行数）来看，我的实际工作量是团队里其他任何人的好几倍。

我把做的每件事都详细记录了下来，包括提交信息、PR 信息和工单管理系统。但这一切都毫无意义，因为我的开发经理根本懒得看。更糟糕的是，我逐渐意识到，即使在站会上我口头汇报工作进展，他也没在听。

【注：我完全明白，许多衡量编程“速度”的指标——例如提交次数、PR 数量等等——并不能很好地衡量生产力。我之所以在这里提及它们，是因为当你的指标比团队中其他任何人高出好几倍时，暗示你“落后”就显得近乎荒谬。】

远程办公人员面临的危险

还记得我在本文开头提到的与远程工作相关的问题吗？嗯，对于那些不在传统办公室工作的人来说，问题就变得非常棘手了。

当你坐在别人的办公室里时，你的开发经理可能并不完全了解你具体在做什么。但是，很多面对面的经理会使用一种极其基础（而且……很无知）的“指标”来“衡量”你的工作成果：他们只是看到你在工作。

听起来很荒谬，但残酷的现实是，对很多管理者来说，衡量员工工作效率的主要“指标”仅仅是他们路过你的办公桌时，看到你在……嗯，在工作？他们可能并不了解你实际的工作内容。但最基本的层面来说，他们只要从自己的办公桌前抬起头，就能看到你在……打字？写代码？还是在做别的什么？

你可能对着代码发呆好几个小时。事实上，如果他们没在你身后看着，他们甚至可能根本不知道你有没有在看代码。但只要知道你坐在办公桌前，表面上在工作，他们就会感到很欣慰。

遗憾的是，远程办公者无法享受这种（极其基本的）“信任特权”。如果你远程办公，并且所做的事情并非直接与“硬性”交付成果挂钩，那么要让你的经理了解你正在努力工作并完成关键任务，就可能极其困难。即使你特意添加了几乎所有软件团队都会记录的各种文档（例如提交、PR 和工单等），情况也依然如此。

所以，当公司高管们开始为上季度不太理想的业绩而焦虑，并开始寻找解决方案（任何方案）时，很容易把矛头指向远程办公人员。因为你的开发经理可能根本不知道你实际在做什么。（或者，在最极端的情况下，他们甚至不知道你是否真的在工作。）

整天坐在公司办公室里，噼里啪啦敲着键盘的乔，在这些评估中通常“安然无恙”。乔的开发水平差劲与否无关紧要。他制造的bug和返工如潮水般涌来也无关紧要。重要的是，你的开发经理——他对软件工程的真正工作一无所知——能看到乔一直在工作。尽管他……并不清楚乔到底在干什么。

裁员责任

这种对远程办公者的偏见在裁员时也同样存在。管理层几乎总是倾向于首先裁掉远程办公者。（或者……他们会采取一种懦弱的“软裁员”方式，发布返岗令——他们心里很清楚，很多远程办公者会主动离职。）

这种情况的出现是因为很多组织根本不知道如何监控/衡量软件工程师的实际工作成果。诚然，如果你独自一人重写了团队的核心应用程序，而且速度很快，也没有出现任何 bug，那么你的领导或许会意识到你对组织的价值。但如果你最近的工作更多的是那些“软性”任务——比如搭建服务器或深入研究错误日志——那么你可能会发现，他们根本看不到你的真正价值。

在这种情况下，他们几乎总是会选择相信坐在办公室里的那个人。就算那个人能力很差也没关系。他们能看到他在工作——这通常就足够了。

还应该指出的是，最近有很多关于远程办公人员无所事事的报道。（我狠狠地瞪了你一眼，Meta。）在这些情况下，这听起来似乎是对远程办公人员的贬低。但是，如果一家公司雇佣了一批远程工程师，却懒得让他们忙于关键任务，这究竟是谁的错呢？

为什么这些大型科技公司要白白囤积无法派上用场的编程人才？因为这些公司的许多管理者根本就不了解软件工程师的工作内容。

人工智能恶魔

最后，我想指出，这种无法（或不愿）真正理解软件工程师工作内容的现象，对开发人员来说构成了短期威胁。（对于远程开发人员来说尤其如此。）

不，我并不是说人工智能会让你的工作过时。但我的意思是，如果你的管理层没有充分认识到你的工作价值，他们就更容易想象你会被人工智能工具（部分或全部）取代。

首先，我想从历史角度来看待这个问题。我年纪足够大，还记得外包/离岸外包曾被视为软件工程师面临的最大“威胁”。（至少对于那些不住在主要外包地区的开发者来说是这样。）现在我们都知道结果如何了。

离岸外包仍然是一种普遍现象，而且短期内不会消失。但是，许多几十年前外包的大型开发项目最终都被撤回了总部所在地。为什么呢？因为那些以为可以通过将所有业务外包来钻空子的高管们发现，结果往往……令人大失所望。

为什么结果如此令人失望？因为这些高管根本不了解软件工程师的实际工作内容。他们把软件开发看作是一条流水线，可以外包给出价最低的承包商。但最终，这些项目耗时远远超出预期。即使最终交付，结果也往往差强人意。

之所以会出现这种情况，是因为优秀的内部软件工程师会执行一系列关键任务，而不仅仅是接收需求文档并编写所需的算法。他们会与利益相关者进行访谈，设计稳健的解决方案，预见短期和长期的挑战。他们不仅仅是在集成开发环境（IDE）中敲代码，而是真正解决问题。

当然，外包在某些情况下是完全适用的。而且，外包已经成为许多公司不可或缺的一部分。但是，能够成功管理完全外包的持续软件开发运营的组织却寥寥无几。

不幸的是，我认为许多类似的错误策略也会在人工智能领域重演。没错，人工智能是一个非常棒（而且发展迅速）的工具，可以提高精明开发人员的生产力。没错，人工智能在软件工程中的作用几乎肯定会随着时间的推移而不断增强。

但在人工智能被企业广泛接受之前，肯定会有人愚蠢地认为他们可以用 ChatGPT（或其他任何新兴工具）来取代他们的工程资源。这种情况很可能会发生，因为时至今日，仍然有很多人管理着开发项目，却不了解开发人员的实际工作内容。

下一期预告……

这篇文章可能有点……令人沮丧。但我并非有意如此。在下一篇文章中，我将提出一些策略，供您作为独立开发者参考，以尝试克服这些障碍。

敬请关注...