作为程序员，我们都熟悉一些明星开发者的故事。

他们从小就开始编程序，11岁就开发了第一个盈利的网站。16岁上大学；17岁创办有限责任公司；23岁成为亿万富翁。我们爱看这些故事，喜欢这些英雄；他们凭借卓越的编程能力和创造潮流的精神激励着我们。从解决NP复杂问题到筹集数百万美元的A轮融资，他们似乎从来没有失过手。

但是事实上，每个开发者，即使是顶尖高手，都会犯错，但也会克服挫折。唯一的区别在于规模：我们犯错，数据库记录会被损坏；而他们犯错，造成的损失可能高达数十亿美元。

为什么我们如此害怕犯错？错误是件好事，没有什么比失败更能教会我们东西。然而，犯错却带有污名。没人愿意谈论它，没人想在一群天才中被视为笨蛋。

这种压制会带来一些后果——当开发人员犯错时，会被视为个人失误。他们会感到羞愧，并常常受到指责。类似“比尔忘记更新发布文档了”或者“比尔选错了分支”。这样的行为往往适得其反，而失败几乎总是系统性的。

因此，我认为失败是发现和纠正业务缺陷的绝佳机会。失败是最好的老师，我们不应该害怕谈论它。本着这种精神，我将在下文中坦诚地回顾我作为一名初出茅庐的软件开发工程师所犯下的三个最严重的错误。

接下来，我将向大家解释我是如何从中成长，并感谢每一个错误的。

删除了一千个网址

在一家大型金融机构工作期间，我开发了一套系统，用于清理 F5 负载均衡设备中网络层里未使用的路由。F5 路由池最多只能容纳大约 5000 个 URL，超过这个数量便会不堪重负。我的系统能够自动监控这些 URL 的流量，通知资源所有者哪些资源未使用，最终会将其清理掉，从而避免 F5 系统崩溃，这样能使运维人员摆脱持续不断的人工干预。

这个系统运行良好，已成功用于在较低级别环境中删除数十条路由。然而，某个星期天早上，我醒来后发现一封邮件，说前一天晚上删除了 1000 条路由，用户抱怨说这些都是激活的 URL！

然后这样就毁了大家的周末，我们的团队立即行动起来。原来是一个旧的 .YAML 配置文件随应用容器一起部署了，它删除了那些一周内没有活动的路由，而不是一个月。幸好我设置了安全机制来防止删除生产资源，但情况仍然很严重。如果我的程序真的删除了正在使用的资源，那么很可能会导致公司所有高负载范围内的应用宕机。

事实证明，大多数闲置一周的资源会持续闲置一个月；换句话说，重要的应用程序不会闲置一周。因此，最终损失还在可控范围内；在删除的1000个URL中，只有少数团队提出了投诉。然而，这件事给我和我的管理员们带来了巨大的压力和批评，尤其是在损失规模尚不明朗的初期。因此，我们基本上设立了一个“作战室”，调动整个团队的资源，随时准备手动重建这些丢失的资源。

这怎么可能呢！？

起初，我觉得这一切都是我的错。我的管理员们也这么认为，这更让我感到不安。但事后再看，这也是系统性失误。首先，现有的F5路由管理系统无法满足业务需求，并且缺乏清晰的备份/回滚策略，这些都是大问题。此外，旧的配置文件一直存在，是因为部署流程过于复杂。这个流程过于繁琐，也更容易出错。最后，这项关键任务被单独交给了我一个人，也就是说，没有代码审查，也没有团队协作，而且截止日期非常乐观，这简直就是灾难的根源。我们从未将此事视为首要任务，现在回过头来看，这样的结果也就在所难免。

我的成长历程

我非常感激我的同事们，他们挺身而出，帮我摆脱了我造成的烂摊子。与此同时，我的经理和资深开发人员告诉我，他们已经对我的工程师能力失去了信心，不会让我继续参与这个重要的项目，这让我感到前所未有的职业打击。

换句话说，他们无法相信我会做出如此愚蠢的事情，也不信任我继续负责这个项目或其他关键项目。

后来，他们收回了之前的说法。

虽然说出来很尴尬，但我真的为此哭了。事后，一位战友请我喝啤酒。我把这件事告诉他后，他说这非常不公平，也很没品，并且告诉我他和团队其他成员都非常感激我。这整整一周我都备受打击，情绪一直很低落，听到他这么说，我真的感觉好多了。我的直属经理也请我吃了午饭，帮我走出了困境。这两件事我都铭记多年。

这件事让我明白，虽然代码管理得井井有条，但基础设施和数据往往并非如此。因此，使用DBMate和Terraform等数据库迁移工具来管理系统的这些组件至关重要，而且它们的重要性应该与应用程序代码同等重要，甚至更高。

限制对生产环境的访问至关重要。例如，我甚至不在自己的 IDE 中保留本地主分支，而是倾向于在全团队范围内限制所有非功能分支的直接推送。数据库和云账户默认应设置为只读，并且应该有清晰的备份和恢复策略。例如，在我下一份工作中，一位开发者不小心删除了生产环境 S3 存储桶中的文件。如果不是我一周前设置了S3 版本控制策略（默认情况下是关闭的——亚马逊，你在搞什么鬼！），我们可能就永久丢失这些文件了。

最后，我学到的最重要的一课是同理心。犯错已经够让人沮丧了，管理层再雪上加霜更是增加压力，而且完全没必要。最近我的一个同事就遇到了类似的情况：他把错误的代码部署到了生产环境，我们不得不手动修正一些数据。他为此感到非常内疚。我借此机会清楚地解释说，出现这种情况的原因是我们的部署数据迁移流程不够完善。这是我们团队的失误，而不是他个人的，而且这种情况迟早会发生。我还提醒他，他一直在努力开发出色的功能，这些功能对我们和公司来说有多么重要。他的错误只是一个提醒，让我们重新审视一下工具和流程，同时也激励他为解决方案做出贡献。错误是我们的机遇。

通过邮件将代码发送给公司外部人员

离职前，我给自己发了一封邮件，里面记录着一些源代码。我花了将近一年的时间开发 Spring 库，期间总结出了一些非常棒的测试模式。我不想忘记这些好点子，原本还计划在 Medium 上写一系列文章来分享它们。

大约一个月后，在我新工作的第一天，我收到了人生中最让我脸色苍白的短信。“兄弟，我们团队惹上麻烦了。有人把代码发到了公司外部，法务部门已经介入了。你知道是谁干的吗？”

我立刻给前任经理打电话，没人接。我又给同事打电话，也没人接。法务部门介入，指示他们断绝与我的联系。这真是太可怕了。我的新经理察觉到不对劲，就问我情况。他以前也是律师，建议我最好找个律师以防万一。我赶紧给妻子的家庭律师打了电话，我们讨论了各种可能的情况。因为涉及到公用事业法规，他们“找我麻烦”的可能性不大，但也不是完全没有可能。

那天我老婆来接我，我心情特别好。她问我第一天过得怎么样，我回答说“我觉得我把我们俩都搞砸了”。她顿时笑了。我把事情经过告诉她后，她表现得非常坚强。她说虽然我当时确实很蠢，但我们会挺过去的。接下来的一个星期我一直浑浑噩噩的，直到我以前公司的法务团队联系我说，如果我签署一份协议，并立即删除那些代码，他们就不会追究我的责任。

这怎么可能！？

我当时目光短浅——就这么简单。

虽然听起来像是什么阴谋，但事实是，我为自己开发的那些模式和工具感到非常自豪，觉得如果失去了它们，作为一名开发者，我会失去一些东西。我当时天真地以为，这些模式和工具能让我写出几篇很有趣的博客文章，不知怎么的，在我这种一心只想着这件事的思维里，收益远远大于风险。

时至今日，我仍然对这件事给前队友们带来的影响感到愧疚。这完全是我的错，但他们肯定也承受了后果。团队的声誉很可能受到了损害，应对审计肯定也给每个人都带来了很大的麻烦。这件事不仅损害了我的职业声誉，也让我和很多人的关系破裂。

我的成长历程

后来，我对公司邮件和内部沟通变得非常谨慎。入职不到一周，就有几名员工因为在Slack私信中进行不当对话而被解雇。事情闹得很不愉快——他们都被开除了，最终我们其他人都不得不参加强制性的人力资源培训，学习职场骚扰的相关知识。无论你公司的技术人员多么不称职，你都应该始终假设他们能够完全看到你的私人通信内容。

这件事让我受益匪浅的另一个重要教训是，我的妻子和父母是如何支持我的。当时我情绪低落，思维混乱，他们的冷静和理解让我重新振作起来。我几乎陷入了人生的危机——我拥有博士学位，从事这个领域多年的工作，怎么会同时如此粗心大意、愚蠢无知呢？难道我毁了自己的前途？如果没有他们强大的支持，我可能早就失控，让情况变得更糟。他们建议我聘请律师，才避免了事态进一步恶化。

这些不仅仅是软件开发原则。我真的会再看一遍那些代码吗？即使它能让我写几篇博客文章，那又能弥补所冒的风险吗？当然不能。当你离开一份工作，或者人生中的任何阶段，就直接离开。不要带走任何东西；不要回头看；继续前进。

新冠疫情期间我失去了工作

2019年，我曾就职于一家相对成功的初创公司，它致力于革新路面养护流程。我们的主要收入来源是地方政府，同时我们也获得了风险投资。然而，这两个收入来源在2020年3月突然消失。在接下来的几个月里，我们公司也成功渡过了疫情难关，迅速调整业务方向以满足客户不断变化的需求，并通过小企业救助基金获得了一些资金。

然而到了七月，很明显我们必须缩减规模，否则就会倒闭。上午11点30分，CEO在Slack上私信我，语气不祥地要求我们在中午12点通话。12点15分，我就被解雇了。大致意思是：“亚当，我们决定立即解雇你。我们认为你表现出色；但是，由于目前的形势，我们需要裁员。”那天，大约有15个人都被毫不留情地解雇了——没有任何警告，没有遣散费，甚至连5分钟的时间都没给团队说声再见（在通话期间我的Slack账号立即被禁用）。

我和妻子六个月前才搬进我们的第一套房子，若没有稳定的收入，我们的经济状况无法维持太久。

接下来的几个月简直是煎熬；我到处都找不到工作。市场上到处都是和我一样失业的高质量工程师。更糟糕的是，我连失业救济金都领不到，这让我非常沮丧。

这怎么可能！？

新冠疫情犹如双重打击，直接导致公司裁员和就业市场严峻。

但其中也蕴含着一个惨痛的教训——我被解雇是因为我在公司里并非不可或缺，公司没有我也能正常运转。他们留下的工程师技术实力雄厚，但更重要的是，他们负责核心业务系统的开发。解雇他们可能会让公司彻底垮掉。而这正是我犯下的最大错误。

因为我入职时间不长，公司安排我参与一些很棒的全新项目。我用 Jupyter 开发机器学习流水线和数据分析。然而，我们的核心系统却是一些普通的 Flask 应用。没有人真正让我接触这些系统，所以我一直和核心保持距离。当它们出现 Bug 时，我没有去主动解决。当它们运行缓慢时，我也没有去维护；没人要求我这么做，所以我也没做。我当时沉浸在那些很酷的新项目——那预示着公司的未来！结果证明，这些系统以及构建和维护它们的工程师对公司的价值远高于我。现在回想起来，一切都明了了。回想当时 CEO 面临的艰难抉择，他让我离开的决定是正确的！

我的成长历程

七月到九月这段时间很艰难，我屡屡碰壁。

最令人沮丧的是，我几乎就要得到梦寐以求的音视频公司的工作了，却在最后一步被拒之门外（这已经是连续第二年了）。最终，我接受了一家乏味公司里做枯燥的Java开发工作。但我很快就发现，枯燥的软件开发其实很棒。这类软件需求简单明了，用户也都很稳定。像“这个按钮不起作用”这样的问题很容易解决，不需要博士学位，也不需要多年的规划。为一个标准的Web应用程序解决一些简单的问题，然后听到用户表达他们的感激之情，这种感觉真的很有成就感！

做那些枯燥乏味的工作也能培养你的批判性思维。我自愿承担了大量核心工作，从搭建基础设施到开发复杂的功能。虽然我的目标并非成为系统的一部分（也就是说，我仍然希望实现自动化），但这应该会让公司更难解雇我。

另外，我不再为求职面试或丢掉工作而焦虑。我们只能尽力而为，其余的则不由我们掌控。也许你没得到那份工作，是因为其他候选人在某个技术领域更有经验。也许他们已经发出了offer。又或许，你只是不如别人优秀。放下你的自尊，坦然接受所有这些原因，恐惧就会消散。要知道，你可能不是，也永远不会成为顶尖的开发者，但这没有关系。

最后，我学到的最后一点：是要不断寻求反馈。我做得怎么样？我为什么要做X——X对公司的成功至关重要吗？如果不是，那什么才是？不要对你的工作太过执着。我们常常害怕反馈，因为它会打击我们的自尊心，但接受反馈才是快速进步的捷径。还有，如果你所在的公司是众多拒绝向求职者提供反馈的公司之一，那真是太可耻了。

这一切都告诉我们，失败和挫折不仅不可避免，而且必不可少。

个人的失败很少仅仅是个人的错。失败是一种机会——一个了解自己和身边人的机会。你的老板是打击你还是鼓励你？你的朋友和家人是否支持你？这是停下来反思、调整方向的最好时机。

作者：场长

来源：

https://levelup.gitconnected.com/my-3-biggest-failures-as-software-developer-6c16a171eaaf