达到精通
达到精通
作为工程师，我们工作的一部分是遇到技术挑战并通过它们找到解决方案。
挑战会产生适当的解决方案，然后是下一个挑战。它经常发生——这是一件好事。
但是在每次挑战之后，您是否会在解决方案后花时间回顾您所做的事情以真正了解该解决方案为何有效？
停在解决方案上可以解决当前的问题。进一步深入挖掘以了解其工作原理是您掌握手艺的方式。
这种情况多久发生一次：您正在排除错误，进行大量增量更改，希望修复所述错误。经过几个小时的努力，你修复了它。
下一步你要怎么做？您是否认为您所做的最后一件事解决了问题，然后继续处理下一个问题？您是否至少恢复上一次更改以查看它是否确实产生了影响？
我经常看到这种情况发生；工程师错误地将解决方案归因于一系列莫名其妙的步骤。传给别人，就变成了一个老妇人的故事，没有逻辑推理来证实这个结论。
要真正理解问题和解决方案，您应该重新开始并应用您认为重要的更改，测试每个增量更改以确保解决方案在没有它的情况下中断。最后，您应该能够解释修复的原因和内容。也许这只是您所做的最后一次更改，或者可能是几个更改的组合，但是如果不了解为什么会起作用，您就会错失更深入了解的机会。
真正的大师会深入挖掘，找出某些东西为什么会奏效——并将其添加到他们的工具带中。
实践者VS大师
今天，我们拥有出色的软件框架，例如 React、VueJS 和 Rails，它们为工程师提供了处理常见软件任务的模式。工程师可以使用这些模式来取得一些很好的结果，但仍然缺乏对“如何”和“为什么”的掌握。
工程师是通过学习框架培养起来的，其中涉及遵循特定模式来创建工作“单元”。单元有不同的名称，具体取决于框架，框架可以有不止一种类型的单元。在 React/VueJS 中，基本单元是组件，而在 MVC 框架 Rails 中，模型、视图和控制器作为基本单元。框架允许工程师堆叠许多这些单元来构建软件产品。
如果我们一遍又一遍地构建完全相同的软件，这将是非常棒的，也是我们所需要的。但我们职业的一个有趣品质是，虽然我们构建的某些元素很常见，但我们很少构建完全相同的东西。此外，最重要的是差异。
正是这些差异在某些时候会导致您遇到框架并非完全针对其设计的问题。这是您需要偏离框架以实现解决方案的地方。如果你只是一个框架从业者，只根据它们如何转换为单位来理解问题，那么你会很挣扎。
如果你花时间掌握你的框架，那么偏差没什么大不了的。您可以利用对框架的深刻理解，并在可能的情况下开发在框架内工作的解决方案，但不受其限制。
这类似于遵循指示的一线厨师与可以即兴创作的主厨之间的区别，他们对相互补充和突出的成分和技术有深刻的理解。
我们欣赏精通的价值，因为我们了解实现目标所需的工作。它涉及接受许多挑战，每个挑战都得出一个解决方案，然后确保在继续之前了解该解决方案为何有效。
我们去过那里，并且做到了。
我的商业伙伴 Randy 曾经在他正在构建的一个图形丰富的应用程序中遇到内存分配问题。随着他的深入挖掘，他意识到与其从虚拟机上分配的内存中提取，他可以利用本机操作系统的内存。
最终，即使这样也没有用，但是深入挖掘的过程使他成为了内存管理大师，并且远远超出了那个项目。
不断推动自己
我们都听说要掌握某件事需要花费大量的时间和精力，但重要的是要把精力放在正确的地方。重复是其中的一部分，但推动自己理解它的原因和方式会加速这个过程。
从专注于技术的一小部分开始，并获得专家级别的理解，了解它是如何工作的、为什么会起作用，以及为什么它在某些情况下不起作用。从那里开始，扩展变得很容易，因为大多数构建良好的软件都是基于类似的原则构建的。
这将使您成为您所在领域的顶级工程师。
带走
这不仅仅是修复错误。当我与工程师一起工作并提出模式建议时，更重要的是让他们了解我为什么要提出反馈，而不是简单地执行。我的建议受到我过去对当前软件的经验和知识的影响。不问为什么就是错过更多了解您正在使用的软件或为什么该解决方案比其他解决方案更好的机会。
当人们遇到新技术问题时，他们会将技术视为垃圾。有时它是合法的，但有时是因为我们只从自己的角度看待它，并试图将技术融入我们熟悉的盒子中。只有当我们深入挖掘时，我们才会意识到我们没有正确使用它。
这些总是学习更多的机会；掌握是在这些学习的另一端。
我们多么努力地挖掘以了解问题的真正本质……以及在解决问题后具体解决的问题是从业者与大师的区别。
解决问题并不像理解那样获得掌握 如何 你解决了那个问题。
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明
