因为工作的关系，经常要快速学习各种新软件和硬件。运气好的时候，还可以和客户提提建议，提前做功课选择比较合适的设备；运气不好的时候，刚到公司人还蒙圈呢，老板把不知道哪里搞来的东西咔嚓一下放你桌子上，「我们要用这个」，那一瞬间是真抓瞎……
交代一下背景，关于我自己的工作，之前一直没有细说过。我现在在一家小公司，公司业务是解决方案和系统集成，自动驾驶相关。但是这个话题真心比较大，涉及到的领域非常多，而且没啥定数，今天做什么常常取决于公司来什么项目，所以经常会有老朋友问「你之前不是说做……，怎么变成……了？」。
我自己的工作是 项目经理 + 开发，可能最大的优点就是不存在开发人员和项目经理吵架的问题了，因为都是我自己 😂。不过缺点也比较明显，工作量和压力稍大，而且精力所限比较难在技术上实现尖端的突破。我给自己的理想定位就是——能解决问题，遇到麻烦知道应该请教谁。
好了说回快速学习的问题，分享一下我自己的学习方法，主要希望解决资源和时间有限的条件下实现快速学习。概括下来就是：
先说资源的限制，开始时我也比较不爽，因为公司小、资源少，经常要在没有任何额外资源的前提下快速学习各种新东西并解决问题。
不过后来联想到理财上的预算问题，我发现这其实也不是坏事。资源和时间上的限制反倒可以倒逼我们避免浪费，联想到学生时期写论文，时间充裕、资源丰富，最后反倒迷失在各种细节问题和复杂的背景中。
我现在的头号原则就是——最大化手头资源，免费搞定一切。会用上的工具基本就是 Google 和 说明文档，有时也会看 Mathworks 的相关文档，但是鉴于用 Matlab/Simulink 做开发的读者可能不多，这部分就不多说了。总之一句话，把手头资源发挥出最大价值远胜于寻找新工具。
另外，坚持免费资源对于快速学习还有一个额外的好处——间接屏蔽了过于系统的知识框架。
大家常说学习知识要系统，要有框架，对于一些要受用一生的领域确实是这样的。比如我写理财的时候，也是建议大家先系统的掌握一些东西，一切慢慢来。
但是在很多工作上的任务，这个逻辑通常并不适用，从一开始就知道要用一辈子的东西基本是没有的，而且公司和客户也不可能等你建立起全套知识框架再来开发，到时候全凉了。
在真正深入一项技术之前，我们对于未来长期使用实际上是没有预期的。而且在资源和时间有限的前提下，学了太多没有的知识也是一种浪费。因为我们工作的意义是解决问题，而不是堆砌一堆不知道什么时候才会用上的所谓的「知识」。
很多技术可能项目开发结束也就不用了，而且为了解决自己面临的问题，往往只需要一个或者几个功能仅此而已。
对于起步和入门，我觉得最高效的方法就是找两篇「Get started with ……」和几篇官方用例来读。
对于完全不熟悉的设备，到手就连上一顿尝试也是不可取的，效率低、浪费时间是一方面，搞坏了才是真头疼。有时候到手一些小众设备，通读说明文档的前面几个章节可能是最高效的选择。
了解入门以后，尽量别纠结在复杂的功能和信息里面，快速切换回要解决的问题。通常这个时候应该已经有个大概的方向了，虽然这个时候很多细节问题还完全不清楚。
过了入门阶段，最高效的学习方法就是边做边学了。很多问题和细节要在实际操作中才能体会到，往往是遇到问题再回头去找解决方案，并在这个过程中不断学习新方法。
很多知识点在真正遇到实际问题之前，往往很难真正理解它的意义和作用。只有等遇到麻烦了，我们才会一拍大腿「原来这玩意是这么用的」。
大多数工具用完了以后再用的机会不多，对于这种知识做好归档就够了，以后用上再来回顾和补充。但是有的时候我们会觉得「这东西太好用了，以后得经常用」，对于这类知识，我们有必要进一步精进补充知识点，这个时候就可以考虑开始系统学习。
这个时候就可以考虑通读官方文档或者买一本书来了，因为我们已经成功解决了一些问题，需求和使用场景已经相当明确，学习时也更有针对性，效率比刚刚开始就逼着自己系统学习要高很多。
在系统学习的过程中，我们常常会发现前期知识不足，做事做的非常笨。比如，明明有个集成功能，一行代码就搞定了，结果自己搞出了两页的类定义。有的时候我们会感慨「当时要是早点读文档就好了」。
但是感慨归感慨，真要重头再来，我还是会把系统学习放在后面。我们不可能一下精通一门全新技术，「感慨应该早知道」会伴随后面整个学习过程，无论你用的是什么学习方法。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。