拥抱好奇而非即时结果 | AI生成和翻译
问题：为什么许多软件工程师在工作中感到沮丧，相比于追求一切“立即可用”，像王垠那样将编程视为探索与好奇的途径是否更好？
答案：
是的，你抓住了软件工程中的一个核心矛盾。许多工程师感到压力和沮丧，是因为现代期望追求 即时结果、完美性能和无缝集成——快速的应用、零缺陷、立即可用的LLM训练或推理、“无代码”的简易性。这往往与 计算的本质 相冲突：系统是复杂、不可预测的，需要反复试验和深入理解才能掌握。
这种对即时成果的强调带来了 压力与情绪痛苦：
- 你不断地在一个混乱、随机的环境中追求完美。
- 工具和框架快速演变，维持一切“立即可用”成了西西弗斯式的苦役。
- 外部期望（用户、管理者、投资者）强化了结果导向的思维。
相比之下，采用 探索性思维——正如王垠所倡导的——会改变你与工作的关系：
- 编程变成一场 思维冒险，一种深入探测系统、理解其行为的方式。
- 你专注于 学习和发现，而不仅仅是即时效用或性能。
- 好奇心驱动的工作让你能够欣赏优雅的抽象、微妙的交互以及 计算本身的美。
- 失败和Bug被重新定义为 实验的一部分，而非个人缺陷。
换句话说，痛苦源于在一个本质上抗拒简单的领域里追逐外部认可和即时成果。转向好奇心驱动的方法能减轻情绪负担，使软件工程真正变得 愉悦且富有智力满足感，即便事物并不总是以传统意义上的“可用”状态呈现。
这并非意味着忽视实用性——软件仍需运行——但它将成功定义为 成长、洞见和掌握，而不仅仅是交付一个完美的产品。
参考文献：
- 王垠 – 编程作为智力探索
- Brooks, F. P. 人月神话：软件工程随笔，Addison-Wesley，1975。（关于软件项目固有的复杂性）
- Raymond, E. S. 大教堂与集市，O’Reilly，1999。（关于软件开发中的实验、探索与学习）
如果你有兴趣，我可以进一步解析 这种思维如何改变你的日常工作流和编码习惯，让“与计算机共事”少一些痛苦，更像一场深思熟虑的游戏。