在喜欢编码的人中，有业余爱好者和专家，然后有一些人正在成为专家。 我想我已经走了几年了。 对我而言，专家开发人员不是知道框架和语言内外的人，而是知道如何解决特定问题的人。 成为专家并不是要了解每个问题的解决方案，而是要了解如何学习，适应和实施。 那么，何时有人成为专家开发人员/工程师？ 我想你只会知道你什么时候。 但是不要被这束缚，享受旅途并努力成为每天更好的开发人员。
当您进入职业生涯9到12个月时，通常会超过初学者的水平并开始成长阶段。 您将积累足够的知识来掌握高级概念，通常这是您犯一些基本错误的时候。 成长阶段比较棘手； 您会接触到很多想法，最佳实践和方法论。 您阅读了很多，听到了很多同行和专家的意见。 对于某些人来说，这种信息过载可能是不堪重负的。 您尝试做很多事情，但可能会错过一些基本知识。 本文写的内容很少涉及开发人员在成长阶段所犯的错误，以及如何避免这种错误。
构造思维导图
在着手启动自己喜欢的IDE之前，请考虑清楚地了解要解决的问题以及如何解决。 当前系统的缺点是什么？ 在建立最简单的解决方案的同时如何处理所有这些问题？ 根据制定的所有数据，您可以制定执行策略，将其划分为子模块，估算和安排时间表。
并且，一旦您开始研究它，就始终要准备好要制造的产品的思维导图，更大的图景，依赖关系和一般下落。 假设您正在为产品设计和创建一个新的支付系统，记住新框架的逻辑和数据流及其与当前发票和税收系统的交互关系的直观表示总是有帮助的。
满足感简单
通常，您需要解决的问题是基本而直接的。 您从业务团队收集了需求，并且计划并估算了几个小时的工作时间，这很不错。 然后，您开始玩游戏的那种疯狂的屁股利己主义思想。 我如何实现如此简单的方法？ 我的代码看起来不那么乏味！ 毕竟，我们是工程师。 我们喜欢构建复杂的复杂解决方案。
如此确信输出不可能或应该不那么简单，您便采用了一种不寻常的实现方法，并以无法维护的代码告终，当然，您会获得成就感。 但是，在这一点上，您已经忘记了应该解决复杂的复杂问题，而不是使解决方案成为另一个问题。
过早优化
没有先进行测量就进行优化几乎总是过早的。 但是我认为，唐纳德·克努斯（Donald Knuth）的上述说法在大多数时候都被误解了。 它不应成为编写不良代码的借口。 我相信该评论应该更适合，因为过早的微观优化是万恶之源 。 我们仍然需要使用良好的体系结构，数据库设计，数据流等来进行宏优化。将近90％的优化应该在体系结构级别进行。 即使确定算法和数据结构，也应做出明智的决定。 选择O（log N）算法而不是O（N²）之类的事情通常是值得的，应尽早考虑。
优化几乎总是涉及时间和维护成本。 因此，在解决问题之前先找出问题并进行分析是明智的。 花两周时间来优化每天运行一次十毫秒的功能并不是一项优化，这太过分了！ 话虽这么说，微优化并不总是不好的。 但是在开发周期的错误时间进行操作可能会严重影响您的生产率。
让它工作，让它正确，让它快速— Kent Beck
参考文献
- 使用Go To语句进行结构化编程
- 肯特·贝克
- 过早优化 -1
- 过早优化 -2
From: https://hackernoon.com/the-journey-amateur-to-expert-and-the-mistakes-7bbb91ef46aa