在工做中学习

原文；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 就提到好几回，说他喜欢在工做中阅读技术书籍。最初以为这是一件使人惊讶的事情，但它确实颇有用。事实上，有不少跟我工做相关的书籍，找不到理由为何不能在工做中阅读它们。