其它几篇的链接:
Google一年工作感受(1) Google一年工作感受(3) Google一年工作感受(4)上一篇我们聊了 工作环境, 工作节奏，
继续上一篇，这次我们来谈谈 工作氛围, 工作内容 相关的主题。
工作氛围
要说工作氛围，其实和工作节奏以及工作环境有不少交集的地方。谈论工作氛围可能更多地是围绕人与人之间的相处方式吧。
在谷歌同事之间大部分都非常友善，人也都挺好的。平时有问题去请教，我周围的同事都会立刻放下手中的事情，转过身来专注地听你的问题。如果他们知道怎么回答你，通常会非常耐心地告诉你，解释一些对他们看起来非常傻的问题。如果他们不知道，也会告诉你应该去哪里找答案，或者让你去找谁说不定会知道。之后，当我准备去问某某人时，我发现之前问的那个同事已经拉好了一个小的chat group，在里面帮你问刚才的问题。而且非常积极地在群里来回发言，好像这个问题是他自己的一样。这种情况我遇到不止一次了，每次都让我觉得非常感激。不过这点其实我觉得大部分公司应该都一样，当时在腾讯的时候，大家也是差不多的。一来是行业中大家都是这样，慢慢造就了这样的文化，二来是如果一个人不是特别友善，慢慢地总会被大家排斥吧？
下面说说开会的氛围。我觉得老美特别喜欢自娱自乐，也可能是我没有太get到他们的笑点，开会中经常有些莫名其妙乱入的对话跟工作无关，有点像玩笑之类的，然后整个会议室就很欢乐。有些老美hahaha经常笑地特别响，感觉他们去做脱口秀领笑员特别合适。当时在腾讯的时候好像稍微严肃一点（只是相比而言，对比我之前实习的金融公司，那还是更活泼一些）。
平时吃饭的时候，有一波老美喜欢叫人一起吃饭，不过我平时还不太习惯跟他们一起吃，主要是聊天的过程比较尴尬，不太放得开。我觉得我现在的英语水平就只能刚好应付工作，书面之类的正式场合。日常生活中闲聊，我经常听不懂他们在说什么。他们说的活动啊，剧啊，电影之类的，因为平时都没啥了解，所以基本没啥可聊的，只能默默吃东西，点头，尬笑。记得第一天入职，跟组里六七个人一起吃饭，整个过程半个多小时，我基本一句话都没说，很想插进他们聊话题，但不知道从哪里开始（要是我坐在最边上倒还好，自己默默吃饭就好了，关键是那天我还坐在比较中间，那个感觉真是难以忘记）。相比之前，我还是觉得我在腾讯的时候日常沟通交流更加自如一些。而且平时吃饭，其实只是少数人一起吃，大部分人都是自顾自的，相比国内，好像淡了一些人情味。比如我只知道这个同事是负责做什么的（有的时候甚至他在做什么都不知道，每个人工作内容比较独立，这点在下一部分会详细说），但是对于他这个人一概不知（喜欢吃什么，有什么爱好，平时有空都在做啥）。同事之间的私交好像也没有国内上班的时候那么好，大家只是简单的同事关系，而工作之外，基本没有任何交集。除了公司内部聊天工具之外，甚至都不知道怎么联系到他们。不过这些只是总体给人的感觉，不排除有些特例。而且也有可能是我还没融入美国的文化，之后说不定会不一样，反正留给我以后的自己打脸吧。
工作内容
对于工作内容，如果用一个词形容的话，那就是“螺丝钉”。如果我以前没有小公司工作经验，或者没有国内的工作经验的话我可能会自然而然地觉得刚工作应该就是这样。而我刚开始觉得有点不习惯，每个人都在做非常琐碎的事情，入职两个多月后都没有啥值得说道的贡献（前三周是培训，完全不需要和自己的组有任何交集），如果要是在国内的，估计都快要被开除了吧。比起在腾讯，我刚入职没多久就独立开发了一个游戏模块；在Leetcode，刚没多久就做了整个平台go语言的支持，而且每段时间（一两周）都能有一个可观的贡献，到最后独当好几面。突然一下子到了谷歌，两个月只是给现有代码做了一些静态检查，加了一些Annotation，一点实质性的功能都没有，觉得自己啥都没做，完全没有impact，焦虑的情绪经就此而生。其实后来看看大家也不过如此，真正能做那种我觉得比较有impact的大project都是高级工程师(L5+)在做，而且有些就算是L5，做的也不过是一些稍微大点的螺丝钉。
代码质量
我觉得谷歌对于代码质量有着偏执般的要求。新人的前几个甚至十几个CL经常受到难以想象的“蹂躏”。入职初提交一个小CL（谷歌不用git那一套，可以理解为pull request），大概只有几行代码的那种，同事的review comment往往都比代码长几倍。刚开始看到这种场面，甚至觉得自己毫无价值，同事花时间给你写comment的精力换成他自己早就提交了好几个类似的CL了，要我何用？就算你照着普遍的代码规范要求自己写了，还会有一大堆你都想不到的comment需要处理。而且大家对代码的review不仅停留在表面，他们会花很多精力深入了解你到底在干什么，然后提出他们的想法，“你可以不用这么实现，如果那么写，是不是会有这些那些好处？”，然后贴出他们的伪代码。这些伪代码的详细程度，精细到你不需要过多修改就可以直接编译通过了。每次看到这种评论，就感觉他们他们微笑着往你脸上甩了一个巴掌然后跟你说放轻松。有的时候觉得他们的建议确实挺有道理，就照改了。但有的时候觉得然并卵，both work，但鉴于他写了这么多评论，而且他不给你通过，你的代码还提交不上去，于是就改呗。
虽然不是人人review代码都如此锱铢必较，但这种人在谷歌很常见。有的时候我甚至觉得，你花这么多精力，提出一个没有太多improvement的建议，你图个啥？并不会为你的升职带来帮助，反而让你更少的时间花在做自己的事情上？所以我没有办法理解这么他们执着的原因。要是我的话，我宁可少花点精力这么深入理解你的代码，然后花半天跟你撕逼代码这么写好还是那么写好。这半天用在做我自己的事情上，多完成一个KPI不香吗？这反而对我自己有更直接的帮助，我干嘛要花这么多时间放在你的CL上啊（as long as your code works OK）。
当时我在腾讯开发的游戏，连测试都不需要写的，全是靠人工黑盒测试，更不要说那些锱铢必较的代码review了。
对于以上这些想法，我也有我自己的反思。我可能还没有将谷歌的文化完全融入自己的工作中。谷歌的代码库非常庞大，而且用户非常多。就我所在的组，代码直接影响全球20亿台安卓设备。如果稍微对代码质量放松一点，影响就会很大。而且我所在的组是infra相关，并不是业务相关的组。用我之前在做ToC业务的工作状态（一两周就能有一个可观的贡献）去衡量我现在的产量并以此焦虑，是不合理的。现有的系统已经很稳定，再往上加那种非常大的功能不太现实。一来，有这么大改动的业务需求，为什么之前一直没加，反而等现在系统这么大了再伤筋动骨？二来，就算有这种project，也不至于给我这个刚入职没多久的人做。所以大部分人在做的都是在现有系统上的修修补补：对于一些metrics的定向优化，抑或是定义一些暂时不存在的metrics，设计并实现data pipeline，然后收集数据，再做相应的分析优化措施。
而且这些定向优化，并不一定会有显著的效果，甚至有些时候会有意想不到的坏处。原因有以下这些：
现有的建筑非常大，有上万根承重柱，加固了最细的一根，只能保证最细的那根单位面积承受的应力减少，对于整个大局而言，就算砍了这根柱子，平摊到每根柱子上的压力也小到忽略不计。
由于加固了最细的一根，导致这根柱子附近的那些柱子之间的应力平衡出现了破坏，在重新调整回平衡的过程中，某些地方出现了裂痕。就好比你某天做了什么改动，减少了心跳机制探测的频率，从而减少了网络的消耗(metric提升)。然而，某个别的模块的另一个metric出现了下滑，原因是该模块没有得到以前及时的探测反馈，导致对该模块请求的失败率显著提升。
所以这些就解释了大部分人为什么整天在做的这些螺丝钉般的修修补补，而没有太多显著的贡献。
而至于为什么我之前在腾讯工作内容上完全不一样的呢？我觉得也有一些原因：
- 当时在腾讯的组是一个相对而言垂直领域（网页游戏）。如果是QQ，可能也会有类似的情况。网页游戏可以说是垂直领域中的ToC，而且当时恰好赶上立项，从无到有的开发，往往是要求大家快速开发出一些可用模块，性能方面的要求倒是其次了，甚至当时连metrics都还没定义齐全，更别说完善的data pipeline。
- 国内的工作环境可能更多受小步迭代，快速开发的理念，加上国人普遍着急的心态，更难非常严格地恪守书本上定义的软件开发的流程。我猜宏观而言，可能这也是国内软件开发经常计划赶不上变化，导致需要不断加班解决问题的原因。而大家都不愿意放慢脚步，所以996成了行业中大家不约而同遵循的习惯。在美国，软件开发的节奏就显得更从容些，work life balance这种国内比较难以做到的氛围。
设计
谷歌很看重设计文档，希望大部分工作都有迹可循。这点听说Amazon是最严格的，不写文档会被开除，毕竟人员流动太频繁，必须要有好的文档才能接手前人的任务。
刚入职的时候，有一个在我看来小到不能再小的改动了，我的Lead让我先写个设计文档在做。我当时就很惊讶，这不就10行代码的改动吗，换成我以前，分分钟就能写好发布到线上的东西。惊讶归惊讶，还是先写了，毕竟刚来，这里的规矩不太懂。于是乎，我花了一天写了6页的文档，写了为什么要做这个改动，有哪些好处，会带来哪些可能不好的地方，示意代码之类的。写完后又花了一周的时间，找了组内一些人review，然后改了又改。最后花了30分钟把代码写掉了，然后花了 几天 把测试用例写好 （关于测试，下一节再说）。然后，你以为一切都结束了？NO. 参考，代码质量 这一节，在这上面又花了几天。前前后后一共三周，提交了这功能上的10行代码（测试不止，得几百行吧）。这一系列流程之后，我觉得跟我以前的工作内容比，太不一样了：
- 当你以为这个事情很简单的时候，并不是
- 当你以为你可以马上做完一件事情的时候，并不会
- 当你以为你终于完成了的时候，并没有
- 当你以为你真的终于完成了的时候，还有发布的流程，which might take months long.
反思了一下为什么这10行代码都需要写文档，我觉得主要是因为这10行代码，引入了新的API，而旧的API会被它取代。他们是基于不同的机制，我加的API是异步的，这对整个系统的影响其实很大，而且难以预测。所以就算这只有1行代码，也不是一个小改动。因此，需要写文档，然后一堆人review之后再开发才比较稳妥。而且写了文档对于绩效考评也是很有帮助的，有些评价的人其实并不是你的组的。如果没有文档，他看你只写了10行代码，要是没仔细推敲，还觉得你怎么才做这么点。而如果有文档，就算是很小的事情，感官上也会觉得“你很规范，很organized，让以后的人有迹可循，小伙子干得好”。所以之后只要有我觉得值得写文档的事情，我不惜花一周的时间去完善一篇文档。
我当时在腾讯开发游戏的时候，都是策划丢给我一个十几页的策划案，我照着上面写的要求开发就好了，工作了一年我连一个开发文档都没写过，一周开发2个功能就是比1个功能看上去更能吹一点。不过当时游戏开发确实是非典型的软件开发，虽然游戏是腾讯赚钱的大头，但游戏和别的互联网产品的开发有着很大的不同（关于这个，以后有时间再聊好了），在这个行业扎根久了，想转其实并不是很容易，往往以前的经验没有太多用武之地，去了新的领域就跟刚毕业的人没什么两样，之前组里离职的人大部分之后还是去做了游戏。正是因为这个原因，我加入腾讯一年后就毅然决定离开游戏开发行业，当时加班太多反而不是主因。
说到扎根久了，想转不容易，我现在也深有体会。之前我在Leetcode时积累了大量的web开发，服务器开发，微服务架构以及k8s集群运维的经验，可以说在该领域是相当全栈的了，到了谷歌match到了安卓infra相关的组（之前我其实想去的是cloud端的infra，现在是手机端的infra，需要安卓的知识），还是觉得之前的经验和积累派不上太多用处，整个安卓的生态跟我之前熟悉的那一套完全不一样，有种一身神力但不知道往哪使的无力感。刚开始我感觉跟当时大三去第一次实习一样，什么都不懂，什么都需要学起来，每一步都走得缓慢又艰难。
测试
本来想今天至少写完这章，跟上一篇一样的毛病，说了三小时，越说越多，说不完了，那就下一篇再说吧。
发布
同上