《代码英雄》第二季(4):更好的失败( 四 )


00:12:15 - Saron Yitbarek:
雾是变得如此受欢迎 , 它基本上被认为是《寂静岭》系列中的一个特点 。 它限制了玩家的视野 , 使游戏变得更加恐怖 。 甚至当处理器的速度快到不需要再掩盖那些弹出的时候 , 他们也保留了雾气 。
00:12:33 - Jessica Rudder:
你无法在没有雾的情况下玩《寂静岭》 。 而这些雾最初所做的一切都是在掩盖一个错误 。
00:12:40 - Saron Yitbarek:
我喜欢这个故事!他们拥抱失败而不是逃避失败 , 从而挽救了一个重大的发展 。 这条关于不怕失败的原则也适用于个人的小事 , 而不仅仅是全公司的决策 。 从容面对失败是我们一点一点地变得更好的方法 。
00:13:01 - Jessica Rudder:
很多时候人们脑子里想的太多了 , 他们认为失败意味着我不擅长某样东西 。 并不是代码坏了我还不知道如何修复它 , 而是“我不知道如何编写 JavaScript” 。 而且 , 你永远不会通过说“我不知道如何编写 JavaScript”来学习所需的知识 。 但是如果你能确定 , “哦 , 我不知道如何在 JavaScript 中实现这个循环” , 那么你可以通过 Google 找到答案 , 而且效果很好 。 我是说 , 你仍然需要努力 , 但你遇到的麻烦会少的多 。
00:13:36 - Saron Yitbarek:
因此 , 无论你是新开发人员还是大型工作室的负责人 , 我们的错误将我们推向更大的领域 , 那些实验 , 那些失败 , 那些英勇的尝试 , 它们占据了旅程的大部分 。 在我所熟悉和喜爱的开源社区里 , 这是最真实的情况了 。 失败在开源中可能是一件美好的事情 , 这就是我们接下来的故事 。
00:14:14:
我们在前面看到了失败是如何带来惊喜 —— 那些我们甚至不知道自己想尝试的事情 。 在最好的情况下 , 开源开发文化正好符合这一点 。 它让失败变得正常 。 为了理解这种愿意失败的想法是如何被引入开源开发的 , 我和 Jen Krieger 聊了聊 。 她是 Red Hat 的首席敏捷架构师 。 我们讨论了对开源失败的态度 , 以及这些态度是如何塑造无限可能的 。 请听:
00:14:47:
我想谈谈这个口号 , 我觉得这也许是一个很好的表达方式 。 “快速失败 , 打破现状fail fast and break things” , 这几乎是为我们社区所设计的一个巨大的召集口号 。 你怎么看?
00:15:04 - Jen Krieger:
我对此有很多想法 。
00:15:06 - Saron Yitbarek:
我也觉得你会有 。
00:15:06 - Jen Krieger:
快速失败 , 在失败中前进 , 所有这些都是一个意思 。 所以 , 在我刚刚参加工作的时候 , 我在一家没有失败空间的公司工作 。 如果你做错了什么事情 , 你就可以准备辞职了 。 任何人都不能做错事 , 没有任何空间、途径允许你犯错 。 这令人们困扰 。 你绝对没有失败的余地 , 导致我们几乎陷入一场文化运动 。 愿意的话 , 这会催生出一个很棒词 —— 敏捷 , 以及催生出另一个很棒的词 —— DevOps 。 当我看到这些词的时候 , 我看到的是我们只是要求团队做一系列非常小的实验 , 帮助他们修正方向 。
00:16:02:
这是个 , 哦 , 你已经做出了选择 , 而这实际上是一件积极的事情 。 你可能会做一个冒险的决定 , 然后你赢了 , 因为你做出了正确的决定 。 或者反之 , 就是你做了错误的决定 , 然后你明白了 , 那不是正确的方向 。
00:16:18 - Saron Yitbarek:
是的 , 这是有道理的 。 所以 , 当你把“快速失败 , 打破现状”当成这个运动的时候 , 感觉在如何失败 , 如何以正确的方式失败上还是有一些方式 , 有一些最佳的实践的 。 那么 , 如何以一种正确的方式失败 , 有哪些最佳实践和原则呢?
00:16:44 - Jen Krieger:
我总是喜欢告诉工程师 , 他们需要尽早和尽可能多地破坏构建 。 如果他们正在破坏他们的构建 , 并且他们意识到他们已经破坏了构建 , 他们在当下还有机会真正修复它 。 而这一切都围绕着“反馈循环feedback loops”这个概念 , 并确保你在工作中得到的反馈循环尽可能小 。


推荐阅读