作为软件工程师，我的最佳建议
Source: Dev.to
Introduction
我之前写过一篇关于我作为入门级（初级）软件工程师的经历，分享了日常工作的亮点和教训。自那以后，我承担了许多不同的职责，并且学到了一些在写那篇文章时没有意识到的东西。
我在一年半前开始这份工作。团队里的每个人都经验丰富，而这是我在一家网络安全初创公司的第一份正式工作。环境节奏快，我必须快速了解一个我几乎不熟悉的领域。
随着时间的推移，我掌握了该领域的基础知识。对 C# 和 .NET 的熟悉让我有余力向同事请教那些最初看不懂的概念。
在初创公司，代码会不断被准备和发布，这与大型企业的变更速度较慢形成对比。对于大型功能，资深工程师会与架构师和利益相关者一起讨论架构。我开始主动参加这些会议，仅仅是为了倾听，这成为了我成长的转折点。
Don’t just ask “What should I do?”
这实际上是我最好的建议。听我说完。
在一次讨论中，产品需求文档和设计模型被展示出来。我并不知道最佳方案，但我想承担该功能的大部分工作。我联系了团队，接手了这个功能，而且因为它不是高优先级，我有时间去探索。
我调研了可能的解决方案，在纸上勾画想法，并用 FigJam 创建了简单的流程图。在确定方案后，我向团队进行推介。方案获得批准，我开始实现。功能成功上线；出现了几个小 bug，我也轻松解决了。
在另一个功能中，我重复了同样的过程：通过头脑风暴寻找解决方案，记录下来，然后推介我的想法。与其问 “我该做什么？” 或 “我该做哪件事？”，我问：
- 我该如何解决这个问题？
- 什么可行，什么不可行？
- 这种方法相较于其他方法的权衡是什么？
回顾过去，从最初的方案草拟到投产，完整负责一个功能，是我成长和学习的最佳决定。
Moral of the story
如果你想提升自己，不要只局限于执行任务。提问、探索，并思考如何解决问题。当你不再问 “我该做什么？” 而是开始问 “我该如何解决这个问题？” 时，你的思维会打开，接触到新的想法和方法。你会成为一个能够看到多种选项并选择最佳方案的问题解决者。
希望我的经历能对你有所帮助，即使是最微小的帮助。
Thanks for reading.