写在前面

本文为转载的译文，原文链接为Today’s Software Developers Will Stop Coding Soon | by Kairsten Fay | CodeX | Dec, 2022 | Medium，原作者Kairsten Fay – Medium。

正文

一位初级个人开源贡献者的经历

试想一下：一位初出茅庐的开源贡献者开始了她的道路。她正在她作为新人软件工程师的早期生活中。她坐下，靠在桌子上，每月编写出上千行代码。

她提交了高质量代码，并在社区中建立起了良好的口碑和信任。不久之后，她收到了社区管理者的会议邀请，她的管理者希望她能在更广范围的问题上工作。

这一变化开始之后，她被要求写出设计文档标记问题区域和可行的解决方案，而非提交定义好的代码或明确目的的任务。她编程的时间从90%下降到了80%乃至70%，她的主页不再是绿色。（github或其他开源社区会用绿色表示提交数量）

她的经验提升了。她修改了多个她的个人项目，并更多地参与了同行的项目设计。但受限于个人的能力范围，新特性和功能的提交速度远超过了她个人可以加入的范围。她的管理者在获悉情况后，为她分配了一名助手，但也给出了一个条件：所有的设计和规划都必须预先完成。她接受了，于是写下并交接了许多工作由助手执行。

代码发生了什么变化

尽管她仍然热爱编程，她花在VScode上的时间变少了而花在谷歌文档上的时间变多了。这一变化，无论认为是好事还是坏事，都成为了许多程序员的工作轨迹，包括我。当我资历增长时，我工作的场地不再是代码之间而是管理大型项目、影响团队方向或者指导他人。

尽管我坚持作为开发者的工作并避免管理事务，但我似乎90%的工作时间都不在编程上。兼顾更大的责任增加了对队友、利益相关者和跨功能合作伙伴之间的协作和驱动清晰度的需求。没有人有足够的周期来自己做。

我能为之做什么？

当需要承担更多的工作职责时，我能够有两个选择：我可以借此升职或直接回到我温暖的VScode中。没有哪一个是生来正确或者错误的选择。在我看来，船到桥头自然直，当你需要做出选择的时候，你会知道哪一项更适合你。我在去年同时完成了两者。

我的旅程

在2022年的第一个工作日，我加入了meta（原Facebook）的新团队，我向我的经理清晰地表述了我想在我过去的技能范围工作的新目标。我希望能深入后端建立我的新技能。无可否认，我也想对抗我在技术堆栈中工作而产生的严重的冒名顶替者综合症。

【冒名顶替症候群（英语：Impostor syndrome），亦称为冒名顶替现象（英语：impostor phenomenon）、骗子症候群（英语：fraud syndrome）。这个名称是在1978年由临床心理学家克兰斯博士（英语：Pauline R. Clance）与因墨斯（英语：Suzanne A. Imes）所提出，用以指称出现在成功人士身上的一种现象。患有冒名顶替症候群的人无法将自己的成功归因于自己的能力，并总是担心有朝一日会被他人识破自己其实是骗子这件事。他们坚信自己的成功并非源于自己的努力或能力，而是凭借著运气、良好的时机，或别人误以为他们能力很强、很聪明，才导致他们的成功[1] 。即使现实环境中的证据指明，他们确实具备优秀才能，他们还是认为自己只是骗子，不值得获得成功。有研究显示，冒名顶替症候群在高成就女性当中较为常见[2] ；同时也有研究指出男性与女性的盛行率没有差异[3]。】

在新团队呆了六个月之后，我的经理分配给了一个非常重要的私密后端项目。随着我们的一个关键模拟中断，混乱立即随之而来，我的团队花了接下来两个月的时间调试端到端依赖关系。我曾在一天内学会c++只为了在其他团队的库中提交一个pr（pull request）。

然后，在调试隐私项目时，一个合作伙伴团队向我们的UI提交了一个SEV（即优先级事项，priority ticket）。我维护的一个特性被一个500 OOM（out of memory 超过可用内存）错误崩溃。随着这两个项目都戛然而止，我已经远远离开了我的舒适区。

在解决了优先级事项之后，我向我的技术领导说明我需要几周的时间慢慢修正ui问题。我知道这些事情本来需要在一周内文章，但我难以找到时间去做这么多事。

我的领导鼓励我去解决剩余的低效ui问题。然而，我推辞了。我希望将注意力集中在我已经信服的后端项目上。尽管这一隐私项目需要填补额外的时间，我怕承担另外一项职责将会同时毁掉这两份职责。我害怕，一旦我失败，我就会永远被认为只是一个做ux的。

当我的领导又一次让我重新考虑去领导ui团队时，我再一次推辞了。我已经完全掌握了ui技能并想在更多的技术方向上得到成长。这意味着我不再处理ui问题，而是让一份新工作蒸蒸日上并获得成功。

我在那一天选择“回到桌子前”，我有充足的理由去拒绝追加的职责。一部分是出于恐惧，另一部分则是不理解我的领导为什么在那个时间提出要求。

换句话说，我可以用简单的英语来描述我们的大多数UI性能问题的问题、根本原因和解决方案。我已经留下了可复制的处理问题的模式。所以，我想，让别人解决剩下的问题会对他们有好处。正如我们常说的，“授人以渔”。

几个月后，我才意识到，我的经理只是想让我证明我理解我的专业领域，而非实际修复问题。我本可以写下一些任务，并在一些workplace LARPing中，在内部发布关于UI工作的进展。

我的领导知道我除了拓宽我的技术宽度之外的其他事业目标。他想要就此问题更加细节而书面的交流。领导ui团队将会在未来几周占据我本就稀少的时间。然而，在我的隐私项目难以摘去的时候，它也可能给我所需要的项目影响。

回想起来，一切都更清楚了。如果我回到ui工作来支持我的晋升计划，但同时会让我觉得捉襟见肘。我承认在必要时说“不”是一项值得训练的重要技能，每个人都不应为保护他个人的精神健康而后悔。

在我做出有几分令人失望的决定的两个月后，一个新的大学毕业生加入了我的团队。我的领导让我培养她，这样我可以将一些我的工作分配给她。此时我对自己后端项目更为自信，得益于我的自大与良好的心态，我接受了这一新挑战，开始分配给应届生一些隐私项目的工作并设计一个资产迁移项目供她完成。

现在，随着隐私项目的按时上线，我期待着在2023年我能够领导一个更大、拥有更多未知的后端项目。这一次，将有两个人服从我的安排。再一次，我离开了我的舒适区。然而，我已经明白不舒适是漫长生活的一部分。

你可能不写代码的原因

编程肯定不会占据你100%的时间。即使是初级的工程师也需要参与会议以及会有没有编程工作的时候。但你成为高级工程师或者成为更高位的角色，非编程的工作将会增加。除了参加会议，我还强调了这项工作的一些重要职责。

写或者更新文档

开始写或者更新文档，并永远不要停止。没有人“经验不足”——即使是新员工也可以从填补他们在入职时遇到的任何概念空白或“陷阱”开始。

写设计文档

当你处理的问题日渐庞大而复杂，你需要开始写设计提案。在这之中，你会获取需求，做一些分析或者研究，并向管理者或者贡献者分享你的发现。

对于初级工程师来说，不要吝啬这一步。虽然直接深入研究代码很诱人，但有时我们需要放慢速度才能快速移动。或者，换句话说，“两周的编码可以节省你两个小时的计划。”（“Two weeks of coding can save you two hours of planning.”）

注意：我之前写了一篇关于可以提高你的技术写作水平的练习的博客。（exercises that will improve your technical writing.）

戴上另一顶帽子

软件工程师团队经常面临技术断层。作为一个项目经理或者管理者经常会面临缺乏某项跨功能技术支持的情况。因此，您可能需要发展相邻角色的技能，比如项目管理，以设定截止日期，并执行与监督项目完成相关的其他职责。

指导团队中的其他开发者

当你在团队中经验渐涨时，你将被要求带领新员工，包括指导初级工程师。成为一名导师将提高你的沟通技巧，并帮助你晋升。

关于成为一个专注的软件工程导师的建议已经在其他地方广泛讨论过了，所以我只会在这里分享一些。

分享实施方案——在你的指导下，给新人或青少年提供学习的机会。创建定义良好、范围良好的任务，任务的模糊性会随着时间的推移而增加。
鼓励一下——新员工不会完全像你想要的那样编写代码。在仍然坚持团队风格指南和其他标准的同时，留出空间。在他们的代码评审中平衡积极的反馈和建设性的反馈。
定期一对一见面——根据新员工在最初几个月的需要，每周或每两周进行15到30分钟的聊天。注意他们所面临的任何问题，并根据需要将其反馈给你的经理或技术主管。

尾声

ChatGPT最近的成功让程序员再次猜测他们是否以及何时会被人工智能取代。然而，我们这些程序员已经在通过软件职业开发周期来取代我们自己。随着每个新的工作级别，工程师将进一步远离代码编辑器，并更接近更多的会议室。

因此，今天的软件开发人员只有几年的时间才能完全停止编码。这种工作职责的转变可能会引发人们对简单时代的呻吟和怀旧，但软件开发者的职业生涯以这种方式进步，为下面的人腾出了空间。换句话说，职业发展周期自然地赋予了下一代软件开发者的能力。让我能够有意义的指导别人，并有意图，有一天，他们会比我更好。

我在工作中的责任让我欣赏了早期的编码。我的更资深的同事的贡献使我能够自信和清晰地只关注实施细节。从那以后，我就面临着新的挑战，并以不同的方式来处理它们。

【转载】今天的软件开发者将会在不久的将来停止编程