作为一名 Dev，我做出的三大最难决定（与代码无关）
Source: Dev.to
决定解决哪个问题（产品困境）
有一个让所有热爱自己手艺的程序员都感到困扰的不便真相：我们热衷于写代码，但代码并不总是产品所需要的。
我学会做的第一个重要决定是把技术选择放在次要位置。刚开始时，总是想解决最具技术挑战性的难题——重构遗留模块、实现超复杂的架构，或是优化毫秒级运行的函数。在现实中，最难的决定是看着待办事项列表并问自己：
“这现在能带来真实价值吗？”
有时正确的决定是做一些技术上“无聊”或简单的事，以快速验证业务假设。接受产品愿景必须领先于技术热情是痛苦的，但却是必要的。
教训
代码只是达成目标的手段。选择不去编写完美的解决方案，而是编写必要的解决方案，这一点将初级开发者与高级开发者区分开来。
一个重要的区分
交付一个并非“完美”的方案并不意味着陷入基本的工程错误，比如写出糟糕的代码或创建复杂、难以阅读的逻辑。实际上，最简单的方案往往是最难找到的。能够在保持长期质量的同时简化问题，是有远见的开发者与缺乏远见者之间的区别。
决定何时寻求帮助（平衡自尊）
这是一个每日都要面对且充满风险的决定。当你在一个复杂任务上卡住时，时间开始对你不利。坚持与固执之间有一条几乎看不见的细线。
- 太早求助： 可能会显得你没有足够努力，或者“太急切”。
- 等太久： 你会消耗公司的资金并拖延交付。
举手说“我卡住了”需要吞下自尊。我学会基于时间盒来做出这个决定：给自己设定一个固定的时间去破解问题；如果没有进展，就去寻求帮助。
这不是无能，而是效率。懂得以正确的方式求助——说明你已经尝试了什么、你的假设是什么——可以把一次软弱的时刻转化为责任感的展示。
决定“这要多久？”（估算的艺术）
或许是任何站会或计划会议中最让人畏惧的问题：“这个任务你需要多长时间？”
回答这并不是随意猜测，而是一次承诺的决定。起初，我会基于理想情景设定截止日期——没有 bug、没有中断。剧透一下：这种情景从未出现过。这里的决定在于通过为未知因素预留安全余量来管理期望。
设定截止日期实际上就是在决定你在给定时间内能够交付的质量和范围。我学到，承诺一个稍长的截止日期并提前交付，要比用短期限去取悦他人、随后再解释延迟更为可靠。
结论
这就是我面对的三大决定。你的呢？