我来 Google 工作有一年时间了。以下几点，是我个人在 Google 工作的一些感受。
宽容的工作环境与国内的加班文化形成鲜明对比，美国有不少公司很在意『工作与生活的平衡』，也就是 work life balance / WLB。Google 一年一度的调查问卷，有一系列问题围绕 WLB 展开，比如在下班之后，或者休假的时候，是否能做到与工作分割开来。据我的观察，多数人在下班之后都不再查看工作邮件，更不会给别人发消息，有什么事情，等到上班了再说。除了一部分与印度合作的同事，晚上也不开会。
另外，在工作氛围上，大家一般会给出足够的宽限期，不会要求别人立即回复。有一次，我上午上传了一段代码，评审的人到了下午还没有看，我就发了个消息催了一下，结果被怼了回来。对方说，若不是紧急情况，请先等 24 小时，如果还没有动静才可以催。后来我也学聪明了，把邮件和聊天的提醒都关了，有时候别人问我一件事，要过几个小时才会看到和回复。即便如此，也没有同事对此表示不满。
强大的开发工具日常开发，免不了要做一些琐碎的杂活，例如调整代码格式、检查拼写错误。为了偷懒，大家开发出了一些工具，并把它们集成到开发环境和自动化测试中。使用这些工具提高效率，大多数公司都可以做到。但是 Google 的工具更为强大，做到了一些其他公司很难实现的事情。
举个例子，在 Google 的代码评审网站上，会显示每一行修改的代码是否被测试覆盖到。这个功能十分有用：如果有人添加或修改了很多代码，却没有写测试来覆盖这些代码，就是一个危险的信号，说明这些代码可能会引入新的缺陷。不过，实现这个功能并不容易。
首先，测试工具需要支持各种语言，以及该语言的各种测试框架。其次，测试工具需要集成编译器和版本控制工具，计算出本次代码修改的范围，并且只运行有关的测试。如果每次都运行全部的测试，就会显著增加时间，拖累代码评审和提交的进度。另外，测试工具还要把结果显示到评审网站上。如果一家公司独立采购测试工具、版本控制工具和评审工具，那么实现这几点是非常困难的。
相比之下，Google 的编译工具、测试工具、版本控制、评审网站，都是自己研制的。依靠上下游模块的协作，实现了显示每一行代码的测试覆盖的功能。通过使用完善和统一的开发工具，享受它们带来的种种便利，Google 的工程师可以更专注更高效地工作。
模仿不来的可读性评审Google 有一套神奇的制度（我不太清楚其他公司是否有类似的制度），那就是工程师提交的代码需要经过一个专门的『代码可读性评审』。新入职的工程师被认为不具备写出高可读性代码的能力。导师在评审过程中，会指出在哪些方面修改代码，可以让它变得更可读。工程师在此期间不断获得指点，水平日益提高，最终毕业，获得一门语言的代码可读性认证。毕业之后，工程师不再需要接受导师的指教就可以提交代码。
这种评审的作用，除了让大家勤于思考，养成好习惯，努力提升代码的可读性，还可以让工程师快速熟悉编程语言的特定用法和 Google 内部代码库，写出规范和高质量的代码。例如，Go 语言中有个 log.Fatalf 函数，可以在程序遇到严重错误时退出。有一次我使用了这个函数，导师建议我改为使用一个 Google 内部特有的 log.Exitf 函数，因为后者不会打印堆栈信息，错误显示更直观简洁。如果没有可读性评审，我完全不会知道 Google 内部代码库中存在这样一个替代者。
可读性评审制度是大多数公司模仿不来的。大多数公司使用许许多多分散的代码仓库。出于保密的需要，你根本无法访问那些与日常工作无关的仓库，更别说对那里的改动指指点点了。而可读性评审的核心，就是让一个与你的日常工作没有交集，不了解你的项目的人，来尝试理解你的代码。如果不熟悉项目的人，也能通过阅读源代码的方式大概摸清作者的意图，那就说明代码的可读性足够好。
可读性评审，一方面有助于提升工程师的能力，另一方面，也在提升人员的流动性。你写的代码，不熟悉的人也能看懂，意味着代码没有秘密可言，你这颗螺丝钉，随时可以被另一颗换掉。我觉得，Google 是有意在维护一个开放和高流动性的工作环境，如果你在一个组不开心了，可以考虑换一个组，而不是必须要跳槽去别的公司。我身边有的同事换过多次组，不知不觉就在 Google 待了十余年。另外，即便有个别员工离开，其他人也可以很快顶上，不会对项目造成巨大的影响。
缓慢的流程Google 对外一向宣传产品的安全性很好，不会出现几亿人的数据被骇客偷个精光这种事故。能做到这一点，依赖于 Google 多年来在安全领域持续投入，并且建立起了完善的安全评审体系。安全评审确实有助于打造一款安全的产品，但是也往往会拖慢产品上线的进度。
我先前做过的一个项目，是使用一种 Google 自己研制的 VPN 传输控制指令，远程操控散落在数据中心之外的机器。这个项目的一个环节，是在某个代理服务中添加一条规则，允许特定身份的用户使用特定的 IP 地址段建立网络连接。这个代理服务处于中枢位置，掌握着访问 Google 核心网络的生杀大权。专门有一个组负责维护这个代理服务的规则。如果需要修改规则，那就需要找他们进行安全评审。
由于全公司有各种业务都从这个代理走，他们的日程安排从早到晚都挤得满满当当。运气好的时候可以安排在本周会谈，运气不好的时候则只能安排在下周。第一次开会时，由于他们不是很了解这款 VPN，询问了不少背景情况，等我们讲解完毕，会议的时间已经耗尽，只能下次再约了。后来的几次会议，他们又详细讨论了我们的使用示例，针对一些不寻常的做法讨价还价，最后算是破例批准了我们。从开始接触，到最后允许接入我们的流量，花费了一个半月的时间。
Google 对于安全的极致追求，是它赢得用户信任的重要基础，这也会成为 Google Cloud 区分于其他云计算服务的卖点。然而，安全评审，以及其他缓慢的流程，是否会拖累 Google 推出新服务和新产品的速度呢？
在奇奇怪怪的地方抠门Google 一年有数百亿美元的净利润，一位工程师一年的工资有数十万。但是 Google 却在一些边角的地方，为了区区几百块钱抠门到令人难以置信。
入职之前，我们有机会自行选择工作用的电脑。做软件开发，一般来说 Macbook Pro 是标准配置，没什么好挑的。但 Google 的政策是，新 Macbook Pro 只能选 13 寸的，如果需要 16 寸的，则只能使用别人用过的二手货。这不是因为买不到 16 寸的电脑，而仅仅是因为它为了省钱，不想给你买。
于是我拿到了一个 13 寸屏幕的电脑。13 寸的屏幕很小，代码竖着只能显示三十来行，横着也不过一百个字符左右，无论阅读还是编辑都极为困难。如果没有外接显示器，我是不会用这个小小的屏幕搞开发的。如果配一个 16 寸的电脑，我可以自由移动，在任何我觉得舒服的地方工作。而现在，我必须先找一台显示器，然后接上显示器才能工作。因为公司的办公桌上还没有显示器（进了公司之后一直在家办公），所以我基本上也不去办公室，毕竟去了也不方便工作呀！
根据 Google 的政策，移动设备上不能存储代码。大家的开发环境，要么运行在办公桌下的主机里，要么是运行在 Google Cloud 上的虚拟机。由于疫情的影响，使用 Google Cloud 虚拟机是我唯一的选择。另我大吃一惊的是，分配的虚拟机使用的竟然是传统的机械磁盘（HDD），而没有使用速度更快的固态硬盘（SSD）。我专门咨询过为什么不使用 SSD，得到的回答是，（以 1 TB 为例）SSD 每个月的开销会比 HDD 多大概 100 美元。但是，我每天早上更新代码索引的时候，都要一边等待一边刷手机。那个时候磁盘读写时间非常可怕，甚至会让开发环境完全卡住。请问我刷手机的时间，折算成工资，难道还不到 100 块钱吗？