教学不受限于专家与专业知识的二元状态。专业知识是您所知道的多维向量：每个人在不同领域都有不同水平的专业知识。这就是多样性对组织成功至关重要的原因之一：不同的人带来不同的观点和专业知识（见第 4 章）。 Google 工程师以多种方式教授他人，例如办公时间、进行技术讲座、教学课程、编写文档和审查代码。
有时与人交谈真的很重要，在这种情况下，办公时间可能是一个很好的解决方案。办公时间是定期安排（通常是每周）的活动，在此期间，一个或多个人可以回答有关特定主题的问题。 办公时间几乎从来都不是知识共享的首选：如果您有一个紧急问题，等待下一次会议得到答案可能会很痛苦；如果您要安排办公时间，它们会占用时间并且需要定期进行推广。也就是说，它们确实为人们提供了一种与专家面对面交谈的方式。如果问题仍然模棱两可，以至于工程师还不知道要问什么问题（例如他们刚开始设计新服务的时候），或者问题是否与某个特定的没有文档化的问题有关时,特别有用。
Google 拥有强大的内部和外部技术讲座和课程文化5。我们的engEDU （工程教育）团队专注于为众多受众提供计算机科学教育，从 Google 工程师到世界各地的学生。在更基层的层面上，我们的 g2g6 (Googler2Googler) 计划让Google 员工可以注册参加或参加 Google 员工的讲座和课程。该计划非常成功，数千名参与的 Google 员工教授技术方面的主题（例如，“在现代CPU中理解向量化”）到完全是为了好玩的（例如，“初学者摇摆舞”）。
5 (https://talksat.withgoogle.com and https://www.youtube.com/GoogleTechTalks, to name a few.）
技术讲座通常是包括演讲者直接向观众展示。另一方面，课程可以有讲座部分，但通常以课堂练习为中心，因此需要参加者更积极的参与。因此，讲师指导的课程通常比技术讲座的建设和维护要求更高，成本更高，因此仅服务于最重要或最困难的课题。也就是说，创建课程后，可以相对轻松地对其进行扩展，因为许多教师可以使用相同的课程材料教授课程。我们发现，当存在以下情况时往往效果最好：
- 这个话题很复杂，以至于经常引起误解。课程需要大量工作，因此只有在满足特定需求时才应开发。
- 话题相对稳定。更新课堂材料是一项繁重的工作，因此如果主题快速发展，其他形式的知识共享将更划算。
- 该主题受益于教师可以回答问题并提供个性化帮助。如果学生可以在没有直接帮助的情况下轻松学习，那么文档或录音等自助媒体会更有效。 Google 的许多入门课程也有自学版本。
- 有足够的需求定期提供课程。否则，潜在的学习者将通过其他方式获得他们需要的信息，而不是等待上课。在谷歌，对于地理位置偏远的小型办公室来说，这尤其是一个问题。
文档是书面知识，其主要目标是帮助读者学习一些东西。并非所有书面知识都必须是文档，尽管它可以用作纸质记录。 例如，可以在邮件列表线程中找到问题的答案，但线程上原始问题的主要目标是寻求答案，其次才是为其他人记录讨论。
6 g2g 计划详述于：Laszlo Bock，工作规则！：来自 Google 内部的见解，将改变您的生活和领导方式（纽约：十二本书，2015 年）。它包括对项目不同方面的描述，以及如何评估影响和在建立类似项目时关注的建议.
在本节中，我们专注于发现贡献和创建正式文档的机会，从修复错字等小事到记录部落知识等更大的工作。
关于对这些问题的较全面的讨论，见第10章
第一次学习是了解如何改进现有文档和培训材料的最佳时机。当您吸收并理解了一个新的流程或系统时，您可能已经忘记了“入门”文档中的难点或缺少的简单步骤。在这个阶段，如果您发现文档中有错误或遗漏，请修复它！让露营地比你发现它时更干净，7 并尝试自己更新文档，即使该文档所属与不同的组织成员。在谷歌，无论是谁拥有它，工程师都觉得自己有权更新文档——我们经常这样做——即使修复小到更正错字。随着 g3doc8 的引入，这种社区维护水平显着提高， 这使 Google 员工更容易找到文档所有者来审查他们的建议。它还留下了可审计的更改历史记录，与代码的记录没有什么不同。
随着熟练程度的提高，编写自己的文档并更新现有文档。例如，如果您设置了一个新的开发流程，请记录这些步骤。然后，您可以通过将其他人指向您的文档来使其更容易跟随您的路径。更好的是，让人们更容易自己找到文档。任何足够不可发现或不可搜索的文档也可能不存在。这是 g3doc 的另一个亮点，因为文档可以预见地位于源代码旁边，而不是在某个（无法找到的）文档或网页中。最后，确保有反馈机制。如果没有简单直接的方式让读者指出文档已过时或不准确，他们可能不会费心告诉任何人，下一个新人也会遇到同样的问题。如果人们觉得有人会真正注意到并考虑他们的建议，他们就更愿意做出改变。在 Google，您可以直接从文档本身提交文档错误。此外，Google 员工可以轻松地在 g3doc 页面上发表评论。其他 Google 员工可以看到并回复这些评论，并且由于留下评论会自动为文档所有者提交错误，因此读者无需弄清楚该联系谁。
传统上，鼓励工程师记录他们的工作可能很困难。编写文档需要时间和精力，而这些时间和精力可能会花在编码上，而这项工作所带来的好处并不是立竿见影的，而且大多是由其他人获得的。考虑到许多人可以从少数人的时间投资中受益，像这样的不对称权衡对整个组织都有好处，但如果没有良好的激励措施，鼓励这种行为可能具有挑战性。我们将在第 57 页的“激励和认可”部分讨论其中一些结构性激励措施。 但是，文档作者通常可以直接从编写文档中受益。假设团队成员总是要求您帮助调试某些类型的生产故障。记录您的程序需要预先投入时间，但在完成工作之后，您可以通过将团队成员指向文档并仅在需要时提供动手帮助来节省未来的时间。 编写文档还有助于您的团队和组织扩展。首先，文档中的信息被规范化为参考：团队成员可以参考共享文档，甚至可以自己更新。其次，规范化可能会传播到团队之外。也许文档的某些部分不是团队配置所独有的，并且对寻求解决类似问题的其他团队有用。
7 见 “The Boy Scout Rule” and Kevlin Henney, 97 Things Every Programmer Should Know (Boston: O’Reilly,2010).
8 g3doc 代表“google3 文档”。 google3 是 Google 单一源代码库的当前化身的名称。
##代码 就其元层面上，代码就是知识，因此编写代码的行为本身可以被认为是知识转录的一种形式。尽管知识共享可能不是生产代码的直接意图，但它通常是一种紧急性的作用，可以通过代码的可读性和清晰度来促进。 代码文档是分享知识的一种方式；清晰的文档不仅有利于类库的调用方，也有利于未来的维护方。等同于实现时给予注释会跨越时空传递知识：您正在写这些评论是为了未来的读者（包括未来的你！）。在权衡方面，代码注释与一般文档有同样的缺点：它们需要积极维护，否则它们很快就会过时，任何读过直接与代码相矛盾的注释的人都可以证明这一点。 代码审查（见第 9 章）通常是作者和审查者学习的机会。例如，审阅者的建议可能会向作者介绍一种新的测试模式，或者审阅者可能会通过看到作者在其代码中使用它来了解新库。谷歌通过代码审查和可读性过程标准化指导，本章末尾的案例研究中有详细说明。