硬着头皮上（Taking the hit）

简介

我以前就这么干过，而且是无意中干的；回头看，那是一个很棒的战略。

当你知道自己的工作会被专家审阅时，清晰但错误，要好过含糊其辞。

这是我经常遇到的一个场景：我正在撰写一篇事故复盘或 OOPS 复盘。我已经访谈过系统中的关键专家，基于这些访谈，我对实现细节已经理解到足以用文字解释故障模式的程度。

但当我真正落笔写解释的时候，我发现自己对所有相关细节其实并没有很好的理解。我可以回头再去问澄清问题，但我担心这样会问很多次，而我想避免占用别人太多时间。

现在，在描述故障模式时，我面临一个选择。我可以：

(a) 对自己理解不透彻的部分刻意含糊其辞。

(b) 对自己不确定的部分，就实现细节做出自己最好的猜测。

每当我选择 (b) 时，总会有一些细节弄错。当我把草稿拿给关键专家看，他们直截了当地告诉我“Lorin，这一节是错的”时，这一点就会变得无比清晰。

我把选择 (b) 称为硬着头皮上（taking the hit），因为，嗯，我讨厌自己出错的感觉。但我总是尽量采用这个做法，因为它能最大化我自己（但愿也包括读者）的学习效果。我硬着头皮上。当你知道你的工作会被专家审阅时，清晰但错误，要好过含糊其辞。