【编者按】软件开发者会需要一直写代码吗？听听本文作者怎么说吧。

Photo by Ruffa Jane Reyes on Unsplash

一位初级工程师的经历

想象一下：一位初级个人贡献者 (IC) 的职业生涯开始了。她很早就代入了她的第一个软件开发角色。她坐在办公桌前，每月编写数千行代码。

她交付高质量的工作成果并开始在她的队友之间建立信任。随着时间的推移，她会收到来自项目利益相关者的各种额外的会议邀请。她的经理要求她处理更宽泛、更模棱两可的问题。

转变就此开始了。她不再处理一些定义明确且严格限定范畴的任务，而是被要求编写一些设计文档，概述整个问题域和可能的解决方案。渐渐地，她花在编码上的时间从 90% 减少到 80% 再到 70%。她不再频繁提交代码了。

然而，她的专业知识在不断增长。她正在兼顾多个自己的项目并更多地参与到队友项目的设计。随着能力的扩展，她涉及的新功能和改进的堆积速度超过了她解决的速度。她的经理关注到了这个情况并给她提供了另一位队友的帮助，但是有一个前提：所有的设计和规划都必须事先完成。她欣然接受，然后设置了一些任务交给队友去执行。

她为什么不写代码了？

尽管她仍然热爱编码，但她却逐渐减少了对 VSCode 的投入，转而更多地把精力放在了编写 Google 文档。这个故事无论好坏，却正是像我这样的众多程序员的职场轨迹。随着经验的积累，我的绩效不再以代码行数来衡量，而更多地取决于我管理大型项目、影响团队的技术方向和指导他人的能力。

即便我继续坚持深耕技术事业而不去做管理，我也不太可能再将 90% 的时间用于编码。兼顾更大责任的同时这也给我增加了额外的团队成员、利益相关者和跨职能合作伙伴之间协作和明晰分工的需求。没有人有足够的时间周期来自主完成这所有的工作。

我能做什么？

当一个人在工作中需要承担更多责任时一般有两个选择：我可以乘风破浪或回到我舒适的办公桌上使用 VSCode。两者并没有什么绝对的正确或错误的说法，在我看来，当你准备好的时候，你自然就会知道什么是最适合你的。我在过去的一年里先后做出了这两种选择。

我的个人经历

在 2022 年的第一个工作日，我加入了 Meta 的一个新团队。我向我的新经理明确表达了自己的意愿：我的目标是在我的专业领域 (UX) 之外发展新的技能。我想要更深入地研究后端以建立我的 T 型技能。不可否认，我也想和因为使用的技术栈太高而养成的冒名顶替综合症作斗争。

在加入新团队六个月后，我的经理给我分配了一个至关重要的隐私后端项目，该项目需要在当年晚些时候交付。当我们的一个关键模拟失败后混乱立马接踵而至，接下来的两个月的时间里我的团队把时间都花在了调试端到端的依赖关系。我曾经在一天内学习了 C++，只是为了在另一个团队的代码库中提交一个 PR。

然而，在调试隐私项目时，合作伙伴团队针对我们的 UI 提交了 SEV（也就是优先票）。我维护的一个功能则因为一个 500 OOM 报错而崩溃。随着这两个项目的戛然而止，我也和舒适区说再见了。

解决 SEV 后，我向我的技术主管和经理解释说，过去几周我一直在缓慢优化 UI 查询。我了解需要完成的工作，但我找不到时间来完成所有工作。

我的经理鼓励我带头努力解决剩下的容易解决的 UI 性能问题。但是，我退缩了。我想专注于我一直有信心的后端项目。尽管隐私项目的排期里有包含额外的休息时间，但是我担心在那一刻承担更多责任会更加冒险。我担心，如果我失败了，我将永远被贬低成"只是"一个用户体验人员。

当我的经理要求我重新考虑领导新的 UI 工作时，我再一次拒绝了。我已经理解了 UI 问题，然而我想在技术方面继续深耕。这意味着我将不再处理 UI 问题，取而代之的是让一个新员工继续跟进，然后将其作为该员工的提升项目并轻松胜任。

那天我选择回到办公桌前。我有自己的理由去拒绝承担这些额外的职责。一部分是出于恐惧，另一部分则是因为对经理在那一刻对我的要求还不甚了解。

换句话说，我可以用通俗易懂的语言描述大多数 UI 性能问题的问题域、根本原因和解决方案。我已经向他们展示了一种模式。所以，我想的是，让另外一个队友解决剩下的问题，这也算是帮到他们了。正所谓：“授人以渔”。

几个月后，我才意识到我的经理希望的是我可以证明我了解自己的专业领域，而无需实际去实现这些修复。我本来可以布置下一些任务，然后半带着在工作场所里表现自己的意思，以某种节奏在内部发布有关 UI 工作进展的信息。

除了拓宽技术广度之外，我的经理也了解我的职业目标。在这里，关于这个问题他之前也在寻求详细的书面沟通。领导 UI 工作会占用我本已稀缺的几周时间。但是，在我的隐私项目还在挣扎前行的时候，它可能也给我带来了我所需要的项目影响力。

复盘以后一切都明朗了。如果我能回到过去，我会付出额外的努力去跟进 UI 工作来支撑我的晋升计划。与此同时，我也曾感到筋疲力尽。我承认，在正确的时间点说"不"是一项需要练习的重要技能，给自身心理健康的成长买单是完全值得的，无需后悔。

在我做出有些令人失望的决定的几个月后，一名新的大学毕业生加入了我的团队。我的经理要求我带她跟上进度，这样我就可以通过给她分配工作来释放我自己的一些时间精力。我对后端项目的状态更有信心了。由于做过一些自我反省，也调整了以成长为导向的心态，我接受了新的挑战，并开始为新毕业生分配我的一些隐私项目任务，然后也在设计一个新的资产迁移项目让她完成。

现在，随着隐私项目的如期结束，我期待着 2023 年我将领导一个更大的后端项目，后面还有更多的未知等待探索。这一次，两个人将在我的指导下工作。我将再一次向舒适区说再见。但是，我已经接受学习忍受不适是旅程的一部分。

一些你可能不写代码的理由

编码永远不会占用你 100% 的时间。即使是初级的个人贡献者也需要参加会议和完成非编码任务。随着级别被提升到资深乃至更高的级别，非编码的工作部分也会随之增加。除了参加会议之外，下面我会着重强调一些重要的部分。

编写或更新文档

随时开始这样做，永远不要停下来。“经验不足"往往只是个借口 —— 即使是新员工也可以从填补他们在入职时遇到的任何概念空白或"陷阱"开始。

书写一份设计文档

随着处理的问题范畴、模糊性和复杂性的增加，你将需要开始编写设计方案。在这个过程中，你将会需要去收集需求，进行一些分析或研究，然后和利益相关者和合作者分享你的发现。

少年们：不要吝惜这一步的时间。虽然直接钻研代码很诱人，但是有时我们需要放慢脚步才能快速行动。或者，换句话说，“两周的编码可以为您节省两个小时的计划时间。”

注意：我之前在博客上发表过有关提高技术写作水平的一些练习。

戴上另一顶帽子

软件工程团队将始终面临技能差距。你将会缺少一些跨职能支持，比如项目或程序经理、产品设计师，等等。因此，你可能需要培养相邻角色的技能，例如项目管理，给任务设定截止日期以及履行其他监督一个项目完工相关的职责。

举个例子，Meta 推崇"自底向上"的工程文化，这意味着有关实际要完成哪些工作的决策来自于个人贡献者（IC）。我们通常会先是自己的项目经理。因此，在过去的一周里，我把主要的时间花在将综合摘要、前期需要做的一些探索工作和目标整合到我在 2023 年即将开展的项目的新工程计划里。

指导团队里的其他开发人员

随着你在团队里不断积累经验，你也会被要求去接纳新的团队成员，包括作为导师去指导初级开发者。成为导师将提高你的沟通技巧并提升你的晋升机会。

成为一名有思想的软件工程导师的建议已在其他地方广泛介绍过，所以我在这里只分享一些核心的。

  • 共同实现 —— 给新人或初级工程师机会在你的指导下学习。创建定义明确且范畴清晰的任务，最初的歧义可能会随着时间的推移而增加。

  • 鼓励他们 —— 新员工不会完全按照你的方式编写代码。给他们留出适当的空间，但与此同时仍然要求他们遵守团队风格指南和其他标准。在他们的代码审查中平衡积极和建设性的反馈。

  • 定期 1:1 —— 根据新员工的需要，在头几个月每周或每两周会面一次，每次进行 15 到 30 分钟的聊天。记下他们面临的任何问题，并根据需要将其上报给你的经理或者技术主管。

结语

ChatGPT 最近的成功让程序员群体再次猜测他们是否以及何时会被 AI 取代。然而，在软件职业发展的周期里我们已经在革自己的命了。每增设一个新的职级，个人贡献者就离代码编辑器更远了一步，同时也离更多的会议室更近了一步。

因此，今天的软件开发人员距离完全停止编码只有几年的时间。这种工作职能的转变可能会引发人们对原初时代的怀念，但是个人贡献者的职业生涯正是以这种方式进步，为下面的人腾出空间。换句话说，职业发展周期自然会赋能下一代软件开发人员。从事这样的职业是一件幸事，它让我能够有意义地指导他人，并希望有一天他们会比我更好。

我在工作中承担的责任越来越多，这也让我很感激自己早期的编码工作。周围一些更资深的同事的贡献让我能够自信而清晰地只关注实现细节。自那以后，我遇到了很多新的挑战，也尝试着通过不同的方式应对它们。

进步从来都不是线性的，但是你应当在你的工具箱里加上一个成长性思维，当你准备好的时候这个高级转变自然就会发生。

感谢阅读我的 2022 年软件开发文化回忆录。在 Medium、Twitter 或 LinkedIn 上关注我，以获取新的博客文章的通知。

进一步阅读

原文链接：todays-software-developers-will-stop-coding-soon （翻译：Colstuwjx）