我来 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 块钱吗？