这是心态的差别，或者说，是技术境界的差别，烙在 Google 工程师的基因里，旁人想学也未必学得到。
3. “管理”二字的意义完全不同了
在 Google，有时候工程师很难管理，因为大多数人都想法新、主意多、眼光高、个性强。在 Google，有时候工程师也很容易管理，只要鼓励他们把一件看似普通的事儿做出世界级的水准，他们自己就有足够优秀的执行力，用不着督促。
在 Google 做技术经理带团队，和我以前在其他公司带团队，完全是两码事。这也许和技术团队的平均水平有关，但 根本还是管理境界的问题。
记得以前在别的公司，花大力气搞开发流程管理，现在想想，大多是繁文缛节，程式化，教条化，最极端的像 ISO9000 之类的流程认证，弄得所有人筋疲力尽，效果未必有多好。
到了 Google，发现一个秘诀， 再多的规章制度，再多的流程，不如一套好用的工具来得有效。比如 Code Style 和 Code Review，以前能把技术经理烦死，三令五申也执行不下去，顶多三天热度之后，大家就阳奉阴违了。在 Google，这件事不完全是个制度的问题。
刚进来的工程师没有过 Readability Review，他就没法方便地自主提交代码，这是代码管理工具设置的硬性限制。这直接把工程师们送到评审委员会那里接受“再教育”，没错，真的是“再教 育”，连 Python 之父 Guido van Rossum 也花了挺大力气才通过了 Python 语言代码的 Readability Review。
接下来，提交新代码前，各种静态、动态检查工具自动运行，帮你报出一系列风格错误、编译错误、单元测试错误和简单的逻辑错误，你得先依着工具的提 示，把这些低级别错误改一遍，然后才进入 Peer Review 的环节。整个 Code Review 都在非常方便的网页工具里完成，写代码的和审阅代码的人可以方便地交互、讨论，甚至在线修改代码。
工具的“强制性”保证了制度的执行，工具的“便捷性”最大程度减轻了工程师执行制度的负担，二者相辅相成。当然，Google 内部也不乏对制度敷衍了事的，但相对其他公司，Google 的确做得更好些。