工程师的绝望谷

原始链接：https://www.seangoedecke.com/the-valley-of-engineering-despair

我已经交付了许多成功的工程项目。现在每次启动新项目时，我总是非常（甚至可能有点盲目地）确信能够顺利上线。即便如此，在每一个项目中，总会有那么一段时间（可能是一天，甚至一周），让你感觉所有事情都搞砸了，项目注定要完蛋。我把这称为**"工程师的绝望谷"**。要成为优秀的项目管理者，很大程度上取决于你能否预见并熬过这段时期。

项目初期总是美好的：你要做什么很清晰，时间也很充裕。项目尾声通常也不错：那时所有重要部分都已经就绪，只需做最后的微调和修复 bug 即可。最艰难的是项目的中期，各种问题会同时爆发：

你发现原本以为很简单的事情，实际上出乎意料地困难
出现了新需求（这几乎是必然的）
在你做出了一些实际的截图和演示后，发现你和产品同事的想法并不像你们以为的那么一致
截止日期的压迫感开始变得真实起来

面对这些，我总是会感到有些崩溃。但诀窍在于：认识到这种感觉是暂时的------你总能挺过去------并且确保在这期间别做蠢事。比如，不要试图通宵解决剩下的问题：这只会让其他人恐慌，带来的 bug 可能比解决的还多。另外，不要大吼大叫地抱怨项目注定失败、在这种条件下根本没法工作。这只会逼着你的经理来安抚你。（经验之谈：永远不要让自己成为经理需要去解决的麻烦。）

那么，你该怎么做呢？放慢脚步，一次只解决一个问题。 解决完一个问题后（无论是通过技术手段直接解决，还是与产品/管理/设计团队协商把它从需求中砍掉），再继续解决下一个。

从最让人头疼的问题开始解决。 如果能解决它，会极大地提振士气。如果解决不了，越早知道越好。如果你实在不想面对它，暂时搁置一下这个最难的问题也是可以的，毕竟做点什么总比什么都不做强，但注意不要拖得太久。

充分沟通你遇到的具体问题。 如果可以的话，把它们以要点的形式写在公开的地方。你的产品经理或主管可能会立刻帮你解决（比如直接砍掉该需求）。就算他们不能，至少他们也清楚你在忙什么。

不过说实话，如何度过"绝望谷"的具体建议并不是最重要的。核心点在于：你要预见到在工程项目中迟早会经历绝望，并在它到来时保持冷静、不要恐慌。

编辑注：这篇文章在 r/ExperiencedDevs（我心目中远远领先其他同类的 Reddit 软件工程社区）上引发了热烈讨论。

如果你喜欢这篇文章，欢迎订阅我的邮件更新，或者[在 Hacker News 上分享](news.ycombinator.com/submitlink?... valley of engineering despair)。下面是一篇同样带有相关标签的推荐文章预览：

调试、情绪韧性与心智模型

擅长调试比擅长写代码更实用------一段代码你只写一次，但你可能需要调试它几百次。随着程序员使用越来越多由 AI 编写的代码，调试可能最终成为唯一保留下来的编程技能。但不知为何，绝大多数的编程内容都在教你如何写好代码，而不是如何调试。调试到底有何不同？
继续阅读...