在工作中学习

原文；Learning at work

作者：Julia Evans

谈点：学习是一件没有尽头的事，虽然在工作中很多时候被淹没在没玩没了的需求里面，加班是常态，或许很多人不知不觉放弃学习的心思。这篇文章中提到的一些方法我很赞同，很多点也是我的做事方式，这里也希望所有人都能找到适合自己的学习方式。

在 Twitter 上我提了一个问题，“你是如何花时间用于自身学习”（这个推文)，这些回答有一些相同之处：

• 阅读博客文章
• 去参加业界大会
• 读书
• 在洗碗时看一些演讲
• 在一些不那么重要的项目里运用你想要学习的技术

这些方法都挺管用的。为了个人职业发展，在工作之外花时间学习新技能是非常普遍的事，在这方面我也有不少经验。

另一方面，我知道有一些很厉害的程序员在工作之外完全不写代码。于是我开始思考，如果你想变得更牛，但又不想工作之外花太多额外时间要怎么办？

这些是我以及在 Twitter 上的朋友提到的一些观点，并且都是能在工作时候做的事情。

不要学习工作之外的编程语言/框架

这一点听起来有些消极，但确实还是很有用的。对于学习编程语言，我的观点是：

• 我很熟悉几种编程语言（python，scala，ruby）
• 学习新的编程语言需要相当长的时间
• 我不想把空闲时间花在上面

最近我在做一些 Go 方面的工作，还挺有趣的，我也喜欢做这件事。但是又觉得在上面花费太多个人时间，所以显得不是那么有趣了。通过编写代码学习编程，阅读别人的代码掌握一些模式，然后自己审查代码，然而这些都不是必须的，因为完全可以在工作中去做这些事情。

选择一些可以从中学习的项目

这些是我在过去三年学到的一些东西：

• Scala/Ruby/Go
• hadoop/mapreduce/scalding
• 如何使用 Java 并发库，以及如何配置一个 Java 程序
• 关于各种 AWS 服务的工作原理
• 很多机器学习的东西
• 网络/ CDN / TLS 如何工作
• docker/容器/rkt/kubernetes
• 服务发现 / DNS / jenkins

一个关于如何选择项目的例子：如果在工作使用一个不能很好并行的程序，这时候问题就来了。我可以选择去问写这个程序的人为什么不使用并行编程，但是如果我也很想学习一下并行编程的话，就可以自己去完成这件事。所以后来我就 学到了如何在 Java 中使用线程池。

我只为此工作了几天，但却因此学到了新东西。

现在我正在从事 Kubernetes 相关的工作，当时选择它并不是因为可以在这里面学到很多东西。但是我确实学到很多有关分布式系统的东西，还在工作中使用 Go 语言，我觉得这很很棒。

当人们说像“嘿，我们使用 X 技术，需要有相关经验的人才能在这里工作”时，这其实相当愚蠢。现在我在网络/ puppet / kubernetes / docker / AWS 上花了很多时间，在这项工作之前没有任何相关工作经验。

观察那些高级人员是如何做事的

我会观察那些我敬佩的人在工作中的做事方式，然后尝试模仿他们或者是向他们寻求建议。例如，当 Cory 加入时，我注意到，在引进新技术的时候，他会这样做：

• 找到另一个有类似问题需要解决的团队
• 与他们合作，确保技术真正解决问题

现在我正在开展一个新项目，一直在考虑这些工作可以帮到谁以及如何帮助，这样做就会感觉好很多。

阅读每个 pull request

在这个主题下引用两个我很喜欢的观点：

我在一个小团队，所以会阅读所有的 pull request，直到完全了解问题和解决方案

和

我也是一样！我跟踪检查，看看人们如何解决各种问题

事实上，我并没有阅读团队中的每一个 pull request。但是那确实很有用，通过跟踪别人在这方面做的工作来学习这个领域的东西。

但我并不是能完全做到。我曾经从事机器学习方面的工作，发现理论也很有趣，就想跟踪人们在这方面的情况，但对我来说有太多要注意的东西。我只能尽量注意那些比较接近我的东西，像是其中网络团队的一些工作。

阅读源代码

阅读我用到的源代码对我而言是一个大块头。了解它在内部在做什么，主要是为什么可以通过某种方式工作。

这是很重要的一点，也非常重要。很多库、框架、工具并没有很好的文档，在没有阅读源代码的情况下根本无法了解其工作原理。

跟进你无法解决的 bug

有时我会遇到一些自己没办法解决的 bug。后来，可能别人会找到解决方法，在这时候，就值得花时间去搞清楚具体的解决方法是什么，以及他们如何想出来的。

例如，最近有一个我没有调试出来的网络问题，刚好有人在上周搞清楚这个问题。现在想一想，大概明白造成这个 bug 的原因，但是我并不清楚他们用什么工具来获取调试所需的信息。当我重新开始工作时，必须确保我真的搞清楚这个问题，这样下次就可以做得更好。

Jessica Kerr 评论道

每当我在故障排除时，除了解决这个问题，还会更深入或更广泛地延伸开去。

我也喜欢这个回复：

有时候，想解决一个与工作有关的问题，但并没有真的在实际工作中发生，只是看看我能不能在某方面有所突破。

运用好通勤时间

对我而言，其实并没有通勤时间。但很多人提到他们会利用通勤时间来听播客/阅读报纸/阅读有趣的文章。这似乎是一个很不错的方式，来做一些你感兴趣的事情。

花时间在工作中学习

Twitter上有人说“我希望每天可以花 1 小时来学习”。我的观点是，我的工作就是要在工作日中抽出时间来学习东西。像现在我正在工作中使用 Kubernetes，这是一个很复杂的系统需要很长时间才能理解，我得花时间了解它是如何工作的。例如，在开始的时候，没什么目的地在做集群测试，只是想了解容器的网络如何工作的，同时也在项目上取得进展。

这可能对我来说挺容易的，因为我的工作跟别人隔得很远，没有人真的知道我具体在做什么，他们只是关心在大方面做的是什么。

实际上，如果要是提前多花点时间阅读，可能效果会更好。就像我刚刚在阅读 Kelsey Hightower 的“learn kubernetes the hard way”的文档，读完不需花太长时间，而且其中有一个关于如何设置一个集群的很好的点，这样就可以很节省我很多时间。

关于这个点，有些人还要想得更远。比如，我的朋友 Dan 就提到好几次，说他喜欢在工作中阅读技术书籍。最初觉得这是一件令人惊讶的事情，但它确实很有用。事实上，有很多跟我工作相关的书籍，找不到理由为什么不能在工作中阅读它们。