搞砸了怎么办
原始链接: https://www.seangoedecke.com/screwing-up
我在职场做过最丢脸的事是对同事撒谎。大概十年前，我还是个菜鸟实习生。为了赶进度，我跳过了在测试环境验证代码这一步。结果代码没跑通，发到生产环境后也报错了。其实影响不大：我们正在做的那个页面还没对用户开放。但当同事问我"你测试的时候没问题吗？"我却敷衍说："当时明明好好的，不知道怎么就坏了。"
我打赌他早就忘了这件事。他可能以为我只是测试时没搞对（比如不小心跑了旧代码），或者他明知道我在撒谎，只是懒得计较。但我至今耿耿于怀。即便过了十年，把它写下来时我依然觉得羞愧。
当然，我羞愧的不是犯错本身。没做测试确实草率，但后来在必要时我也会为了效率走捷径，且不后悔。让我羞愧的是我处理问题的方式。不过我也能理解当时的自己：一个想快速学习、急于在科技圈证明自己的年轻人，最不愿面对的就是自己把事情搞砸了。如果我现在处于那位同事的位置，估计也会一笑而过。那么，现在的我会如何处理工作中的失误呢？
处理情绪反应
最重要的是控制情绪。工作中最强烈的情绪波动往往出现在你搞砸事情的时候。通常会有两种矛盾的冲动：一是想为自己辩护、找借口、大事化小；二是想坦白认罪、疯狂自责、乞求原谅。这两个都是陷阱。
找借口（或像我当年那样直接否认）当然很糟。但走向另一个极端，在大家面前过度自责也同样糟糕。原因有三：
首先，你迫使周围人花时间和精力来安慰你，而他们本该专注于解决问题。其次，你把自己从解决问题的团队中摘了出去，而由于是你造成的错误，你最了解背景，往往是最适合排查问题的人。第三，这显得极其不专业。
所以该怎么办？在最初的短时间内，什么都别做。 情绪会随时间消退。试着熬过刚发现搞砸时的那阵恐慌，克制住盲目行动去修复它的冲动。最糟糕的反应往往发生在出事后的第一瞬间，所以只要在这段缓冲期内按兵不动，你就已经有了一个好开局。对我来说，大概需要 30 秒。你需要多久因人而异，但最好别超过 10 分钟。如果需要更久，你可能就得咬紧牙关强行进入工作状态了。
及时沟通
一旦确认情绪在控制之中，下一步就是告诉相关人员发生了什么。通常是告诉你的主管，根据问题情况也可以是同事或其他人员。这里的关键是就事论事，否则又会掉进前面说的"我太差劲了，快安慰我"的陷阱。如果根据上下文已经很明显了，你甚至不需要明确说"我犯了个错"。直接说"我刚发布了一个改动，导致 X 功能坏了"（或直接陈述问题现象）就好。
你需要在想出解决办法之前就去做这件事。人们常常想隐瞒错误并偷偷修好它。但对于面向用户的问题，隐瞒是不可能的------迟早会有人报障。如果你不主动说，别人发现后就会当成紧急突发事件上报。
最坏的情况是：你在默默开发修复补丁时，别人已经拉响了警报，拉各种团队开会排查是不是数据库或网络挂了，搞得鸡飞狗跳。而你因为是始作俑者，明明完全知道原因，也知道只要改个发布配置就能轻松修复。如果你能立刻报告问题，这些混乱完全可以避免。
在我的经验中，科技公司的主管通常能原谅错误，但绝不原谅被当成傻子 。特别是被剥夺了关键信息。如果老板问他们出了什么事，他们因为不知情而支支吾吾，显得对局面失去控制，这会永久性地破坏你们的关系。反之，如果你立刻给他们一个清晰的问题总结，让他们能在老板面前显得掌控全局，你甚至可能会因此获得好评（尽管最初的错误是你造成的）。
接受犯错的代价
不过，你大概率还是不会获得好评。在这一点上，我不同意软件工程界常说的"故障都是系统问题，从来不是个人问题"。故障当然是由复杂系统交互引起的，但宇宙万物都是复杂系统交互引起的！在那个因果链条中，往往确实存在某个人搞砸了这个环节。
如果你是工程主管，为了让项目成功，你心里肯定有一份"能可靠带项目"的工程师白名单。如果某个工程师频繁犯错，他们很可能会被移出名单（或被打上问号）。
主管其实不在乎你犯错是否有合理的技术理由，或者情有可原。他们并不关心，因为他们往往没有足够的技术上下文来判断你是在陈述事实还是在找借口。他们只能通过结果来评估你。这意味着，只要你有足够的成功来弥补，一些失败是可以接受的。
成为一名强大的工程师，意味着要在永远正确和敢于冒险之间找到平衡。如果你只求永远正确，你确实能避免犯错，但你也无法带领项目（因为这始终需要承担风险）。因此，工作中的最佳犯错率绝不是零。 除非你在极少数对安全性要求极高的特殊行业工作，否则你应该允许自己偶尔犯错，一点错都不犯往往意味着你工作得太慢了。
如果你喜欢这篇文章，欢迎订阅我的邮件更新，或者[在 Hacker News 上分享](news.ycombinator.com/submitlink?... screwing up)。以下是一篇带有相同标签的相关文章预览：
抓住核心关键
在科技公司推进项目时，明白你的首要任务是交付项目 能让你少走很多弯路。许多工程师把时间花在了边缘问题上（比如该选技术 X 还是 Y），却对如何让产品真正跑通（例如关键路径实际上该如何运作）等核心问题视而不见。
继续阅读...