sean goedecke

不愿承担责任的工程师

有些工程师认为在技术讨论中保持不置可否是一种美德。例如，我们的团队应该以事件驱动的方式还是同步的方式构建一个新功能？好吧，这取决于情况：双方都有很多强大的技术理由，所以最好保持开放的心态，不要偏向任何一方。当你是初级工程师时，这种策略是可以的，但到了一定阶段，你将会成为房间里掌握最多背景信息（或技术技能，或机构权力）的人。在那时，你需要表明立场，无论你是否感到特别有信心。

如果你不这样做，你就是在迫使技术背景不如你的人自己去弄清楚。通常这意味着有人会随机猜测。在最坏的情况下，团队中最弱但声音最大的工程师会抓住机会，推动一个非常糟糕的想法。如果你是一个强大的工程师，你有责任表明立场，以防止这种情况发生，即使你只有 55% 或 60% 的信心1.

为什么保持不置可否是懦弱的

像大多数形式的懦弱一样，保持不置可否从内部感觉像是明智的谨慎。毕竟，技术问题是复杂的。总是有理由表达不确定性或在声明中添加警告。如果正确的做法真的不清楚，那么（他们说）表达不确定性是完全正确的。

我认为经常驱动这种态度的原因是，许多工程师（包括我）真的、真的、病态地讨厌犯错。当我犯错时，尤其是在公共场合，我的胸口会感到一阵恶心。之后我会思考很长时间。这很有用，因为它使我努力去做对。但这也在情感上使我难以在一个会议上给出一个可能最终完全错误的有根据的猜测。我必须努力才能接受这样做，所以我同情那些不能这样做的人。但我也看到了它的本质：懦弱。当人们依靠你做出决定时，你应该挺身而出并做出决定。

如果你错了怎么办？

当工程师过度使用警告和限定词时，经理们通常不会想“哇，我很高兴这个人如此小心和准确”。他们会想“呃，你为什么要强迫我自己做决定？”

根据我的经验，当你做出一个技术决定，但最终是错误的，经理们通常会非常宽容。那是因为他们的工作也涉及做出很多有根据的猜测，所以他们已经内化了有些猜测不会成功。当你做出的决定确实很困难时，这一点尤其明显——例如，一个技术问题在会议中出现，每个人都沉默不语。如果你是唯一一个站出来回答的人，即使你错了，那仍然是有价值的。朝着错误的方向前进至少通常会给你信息，或者提供一个迭代的基础。

当然，如果你错得太多，人们将不再信任你的估计。或者如果你在任何特定情况下错得太离谱——例如，你为一个事件提供了一个解决方案，但最终导致了一个更糟糕的事件——你也会失去信誉。我建议通过经常做对的事情来避免这种情况。

有时避免承诺是明智的

估计是一个有趣的例子。对于除了最明显的单行代码更改之外的所有事情，许多工程师默认的回答是“好吧，这取决于情况，很难说，可能需要几天或可能需要一个月”。但你的经理不是出于好奇才问的，他们问是因为他们需要一个粗略的估计来进行计划。如果你给出一个不确定的答案，他们会在心里叹息并自己猜测这个估计。

但是，有时避免估计不是懦弱的问题。在某些公司，工程师避免给出确定的估计，因为当这些估计没有达到时，他们将面临真正的、不公平的后果。在这里，工程团队和产品团队之间的信任已经完全破裂。工程师们被激励着保持低调，永远不要承诺任何事情（至少在管理层面前）2.

我确信在某些公司环境中，每一项技术承诺都如此危险。我对于这些环境中的工程师没有任何批评。

总结

我想以重复我自己的一个警告来结束。我说的是你应该强迫自己做出承诺_当你是在房间里最能知道答案的人时_。当你与一位技术同行——例如，你团队中的另一位工程师——进行具有同等背景信息的对话时，你可以尽可能地不置可否。但请记住：

  1. 这有点讽刺，因为我之前写过关于不要对大局问题采取坚定立场的文章。区别在于你是否在工作场所这样做。在工作场所之外，我真的不知道类型语言是否比非类型语言更好。在工作场所，我会倡导 TypeScript，因为我大约 60% 确定它具有净收益。 ↩
  2. 根据我的经验，这实际上不起作用。产品经理只是编造或半虚构的估计，然后仍然要求团队负责。但我对于严重功能失调的公司的经验有限。 ↩

February 10, 2025 posts │ resume │ github │ linkedin │ rss │ what I'm working on now