引言 | 今天推薦一位老工程師的人生經歷， 內容來源社區， 希望能對大家有所幫助。
我 2006年 3月加入 Google， 2016年 9月離開。 離開時的頭銜/職位是 Staff Software Engineer / Manager。 前後 10.5年， 大致分三期：
前兩年關注 Linux桌面搜索產品和 Google的開源項目；中間三年花了許多力氣在 Google中國相關的產品上， 諸如輸入法、穀歌音樂之類；後面四五年大致都在 Knowledge Graph的範疇內工作， 這些工作和 Google搜索、Google Now最近幾次大幅度的變革密不可分。
其間， 代碼寫了不少， 團隊也帶過好幾個。 除此以外， 這些年還長期在 Google Doodles團隊作為 20%的開發人員幫忙開發那些好玩的首頁塗鴉——嗯， 這是真的， 好多好玩的 Doodle裡面，
學到了啥？
嗯， 很多， 很雜， 揀最重要的四條來說說。
1
1.差異化
第一次真實地生活在一個差異化的世界裡國內教育氛圍向來是不喜歡差異化的， 個人愛好、冒險精神、特立獨行之類的語詞， 總會讓家長、老師乃至領導、官員操碎了心。 從小到大， 我基本生活在一個試圖將所有孩子圈養在尺子、框子、籠子裡的世界；可以想像， 像我這樣的 70後一腳踏入 Google時， 會有怎樣的感慨。
Google、Apple、Facebook、Twitter……對雇員來說， 這些公司本身就是一種鼓勵差異化生存的大家庭、大社會。 其中， Google又總是扮演引領者的角色， 這是在 Google工作很值得驕傲的一件事。
差異化的最大好處， 就是你有機會認識形形色色的神奇人物， 然後， 當你和人生觀、生活方式、個人愛好乃至行為習慣差異巨大的人一起工作時，
在 Google， 看見什麼樣的差別都不該奇怪。
往小了說， 身邊既有縮在角落裡悶頭寫代碼， 討厭和人交流的社交恐懼症患者， 也有精神煥發的社交明星。 辦公室裡， 有帶狗上班的愛心族， 有重視家庭的好爸好媽， 有整夜整夜奮鬥的夢想家， 有癡迷奇特愛好的技術極客……
就拿愛好來說， 跟我一起工作過的同事裡， 說起來好玩的愛好就包括：天天在車庫裡打造奇形怪狀的自行車， 休一個無薪假期去幫別人競選總統， 每個週末都跑到一個從沒去過的地方留下到此一遊照，
當然， 要尊重差異化， 你就沒法阻止任何人從早睡到晚然後每天只花兩個小時幹完別人十二個小時才能幹完的活兒。
往大了說， Google對 LGBT群體的支持眾所皆知。
另有一次， 自己所在的整個團隊收到了一位高管宣佈自己性別改變的郵件， 說從那天開始， 大家需要稱呼他為“她”。 與許多人理解的相反， 這些發生在身邊的事情並沒有時時提醒你 LGBT群體的存在， 反之， 經歷愈多， 你會愈加淡化對他們的注意——他們或她們就是人類的普通成員， 與你我並沒有太大的分別。
去年在 YouTube上追看 Google推介的紀錄片 HUMAN時， 我已經很清楚，
我覺得， 這個世界最可笑的一件事就是人類進化明明得益于基因與性格的差異， 許多人竟會嘲笑別人與自己的不同之處， 並竭力迫使他人改變， 恨不得全世界的人都如自己一般固執、愚昧。 性取向如此， 戀愛、婚姻、家庭、工作、事業無不如此。
Google員工經常面臨一個典型的兩難困境：因為許多同事早早離開 Google去融資、創業、上市、發財， 像我這樣安心在 Google工作了十年的普通工程師就變成了另類——當面問我“為什麼還沒離開 Google”的人， 他們眼睛裡鄙夷的目光藏都藏不住；反過來， 在家人眼中， 我打算離開 Google的舉動無異于自己砸碎金飯碗，放著穩定的收入和豐厚的福利不要，非要和不確定性為伍。
其實，如果懂得“多樣性”的重要，這種左右兩難的困局就不再成立。既然有人選擇快節奏和世俗生活，為什麼我就不能辭了職，慢悠悠地隨著自己的興趣，由著性子，從不同的角度理解這個世界與自我的關係？為什麼“慢生活”就必須是一種逃避？
宇宙很大，人很渺小。安全感是扯淡，特立獨行地活著才最重要。
2
2.改變看技術心態
到 Google以前，我在國內做銀行業的業務軟體研發，給工行、中行之類的大企業做軟體。這和 Google這種面向最終用戶的互聯網背景是有天壤之別的。
以前看待技術，覺得是身外之物，是工具，是磚木，是用來解決用戶需求的必需品。這個心態其實也沒什麼錯，但不自覺地就把自己放在技術追隨者的位置上了。
那時的我，很多時間都拼命在瞭解、學習和追趕新技術，生怕落伍。從這個語言追到那個語言，從這個框架追到那個框架，從這個模式追到那個模式，從這個平臺追到那個平臺……根本停不下來。
那時的我只是個技術的“用戶”，就像搬磚蓋房子，如果不天天關心今年流行什麼材質的磚，明年流行什麼樣的房子架構，後年流行什麼樣的房子外觀，那肯定被客戶和其他程式師罵“老土”。
到 Google擼胳膊挽袖子一忙活，才發現以前的自己狹隘了，小氣了，井底之蛙了。原來以前追的好多頂尖技術，根本就是 Google工程師主導或參與鼓搗出來的。而且，Google內部還藏著許多外界不大知道的神奇玩意兒。最最重要的不同是——自己現在是引領技術潮流的大團隊中的一員了。
以前是不斷學別人怎麼設計房子，看別人推薦什麼材料蓋房子。現在，最頂尖的房屋設計專家、材料專家就在身邊，自己也很快就能和他們一樣指導別人蓋房子了。這種感覺，就像跳進了一個大寶藏，還清楚地知道自己並非盜賊，而是寶藏的主人。盜竊寶藏 vs.創建寶藏，這兩者間的差別很微妙。
心態一下子大不一樣了，從技術的“用戶”變成了技術的“主人”。
比如，有段時間要解決 C++的 ABI相關問題，猛想起 C++標準委員會的相當一部分人都是在 Google工作的，有一年的全體大會還是在 Google總部開的——那直接拉著既是同事也是 C++權威決策人的傢伙一起開會討論不就是了？
類似的，Linux內核的維護者、Python的發明人、UNIX的元老、Google Brain的創建者……跟那麼多牛人在一個公司裡工作，你肯定不好意思只是單方面地跟人討教，但凡有機會，你總會希望自己也像那些牛人一樣，為技術發展做點兒貢獻，哪怕只是一丁點兒。
再比如，像 MapReduce、Bigtable、TensorFlow之類由 Google原創、對業界影響深遠的技術，在 Google內部可不僅僅是身外的工具，它們都是 Google工程師這個大集體的作品和驕傲。因為大家都是主人，對哪些東西不爽，可以去鼓搗原始程式碼，可以去提交自己的補丁或者新功能，甚至推翻重做。
別小瞧這推翻重做，雖然很難很難，因為你得一邊說服老闆和用戶，一邊找到足夠的開發人手，但事實上， Google內部重新發明一遍、兩遍、三遍的框架、工具、庫、介面、服務比比皆是。一言不合就動手做個新版本、新系統，這毛病既帶來數不清的流程混亂，也帶來一山又比一山高的良性競爭——表面的混亂之下，良性競爭引發的技術飛躍常常超出想像。
在 Google，工程師有好幾萬，不能說每個人都渴望做技術的主人，但躊躇滿志的大有人在。因為 Google走在技術最前沿，有追求的工程師確實沒臉當個純粹的技術追隨者。當然，我的意思不是說 Google裡沒人去做那些不那麼酷的“苦力活兒”，而是說大多數人都有個爭強好勝的心態，即便是做相對簡單的技術工作，也時常會想想怎麼能做出世界一流的效果來。
拿面試來說，有個工程師想出了一道與月球相關的面試題，把演算法、程式設計、設計、維護問題放在太陽系的大背景下，層層追問。我在一次內部面試技術培訓時拿這道題當過樣例。結果，參加討論的工程師表達了截然相反的兩種意見，有人說這題設計精妙如天馬行空，另一些人則批評這題目遠離實際如鏡花水月。
其實，Google的技術宅們幾乎每天都在深入實際與憧憬未來這兩個極端的對位、矛盾、轉化中工作。常說的“仰望星空、腳踏實地”遠不能形容 Google工程師的兩面性。
一方面，工程師們深知自己的代碼是如何參與了這個地球乃至這個星系裡最前衛、最大膽的電腦系統，如何為諸如十年後的搜尋引擎、擁有人工智慧的手機或機器人、量子電腦、基因工程、無人駕駛汽車等貢獻力量；
另一方面，工程師們“極客”和“宅”的一面常常在外人難以注意的工作細節裡表露無遺——這裡有十數年如一日致力於優化編譯器的語言高手，有設計最好的代碼審讀系統的工具專家，有親自動手實現軟硬體原型的技術總監，有堅持為地球上每一種人類語言提供輸入輸出解決方案的國際化團隊……
這是心態的差別，或者說，是技術境界的差別，烙在 Google工程師的基因裡，旁人想學也未必學得到。
3
3.“管理”二字的意義
有時候工程師很難管理，因為大多數人都想法新、主意多、眼光高、個性強。在 Google，有時候工程師也很容易管理，只要鼓勵他們把一件看似普通的事兒做出世界級的水準，他們自己就有足夠優秀的執行力，用不著督促。
在 Google做技術經理帶團隊，和我以前在其他公司帶團隊，完全是兩碼事。這也許和技術團隊的平均水準有關，但根本還是管理境界的問題。
記得以前在別的公司，花大力氣搞開發流程管理，現在想想，大多是繁文縟節，程式化，教條化，最極端的像 ISO9000之類的流程認證，弄得所有人筋疲力盡，效果未必有多好。
到了 Google，發現一個秘訣，再多的規章制度，再多的流程，不如一套好用的工具來得有效。比如 Code Style和 Code Review，以前能把技術經理煩死，三令五申也執行不下去，頂多三天熱度之後，大家就陽奉陰違了。在 Google，這件事不完全是個制度的問題。
剛進來的工程師沒有過 Readability Review，他就沒法方便地自主提交代碼，這是代碼管理工具設置的硬性限制。這直接把工程師們送到評審委員會那裡接受“再教育”，沒錯，真的是“再教育”，連 Python之父 Guido van Rossum也花了挺大力氣才通過了 Python語言代碼的 Readability Review。
接下來，提交新代碼前，各種靜態、動態檢查工具自動運行，幫你報出一系列風格錯誤、編譯錯誤、單元測試錯誤和簡單的邏輯錯誤，你得先依著工具的提示，把這些低級別錯誤改一遍，然後才進入 Peer Review的環節。整個 Code Review都在非常方便的網頁工具裡完成，寫代碼的和審閱代碼的人可以方便地交互、討論，甚至線上修改代碼。
工具的“強制性”保證了制度的執行，工具的“便捷性”最大程度減輕了工程師執行制度的負擔，二者相輔相成。當然，Google內部也不乏對制度敷衍了事的，但相對其他公司，Google的確做得更好些。
說到管理，在 Google帶技術團隊的其實都苦哈哈的。我就先後兩次把團隊交給別人帶，自己樂得去做些單純的代碼工作。道理很簡單，頭銜是 Manager，可你沒法高高在上指手畫腳，Google最好的團隊帶頭人都是沖在第一線帶著大家一起幹，除了主動包攬大家不想幹的髒活、累活、雜活之外，還要做管理者必須的非技術工作，比如給每個人寫評語、定獎金，幫每個人申請升職，跟心理負擔重的談心……
一個人做兩份工，吃力不討好，對團隊成員的晉升也沒有決定權（這事兒也挺神的），這種 Manager的活兒，誰願意幹誰幹去，我是不大喜歡幹的。不過，不喜歡歸不喜歡，Google這種挺不一樣的管理既顯著混亂無序，又運行良好，確實很神奇。
嚴格地說，聰明人在一起，只需要激勵，不需要管理，Google的辦法主要也是強調這一點。
必須坦白，我加入 Google時，工程師才三千人上下，無序管理、自發管理、扁平管理占主流。Google越來越大以後，大公司病也如約而至。流程越來越複雜，層級越來越多，職權重疊和模糊越來越嚴重，不同團隊之間管理風格的差異也越來越大。
但即便如此，Google基因裡那種蔑視陳規、抵制辦公室政治、抗拒繁文縟節的管理風格還是能在許多團隊帶頭人的身上找到——這是 Google肌體裡的健康因素，活力因數，彌足珍貴。
順便說一句，最近中文圈子熱傳不寫代碼/不會寫代碼的 CTO一事，許多 Google工程師出身的 CEO/CTO都在朋友圈裡曬自己寫的代碼，以表明態度。我自己對技術管理者寫不寫代碼沒啥傾向，寫不寫都可以是好的管理者，但如果“不會寫代碼”還以此為榮，就完全沒法接受，這個是底線。
我在 Google面試了不少 Manager和 Director的候選人，都考過對方寫代碼或者至少討論一段代碼的能力——不是要他一定在管理過程中寫代碼，而是怕他和 Google工程師沒法交流，和 Google技術基因沒法共存。
在 Google做技術管理，學不到啥成文的規矩，能學到的其實主要靠“悟”。
4
4.看待職業生涯的心態
很多人來 Google還是奔著一份優越的薪資待遇來的。所以，這裡只談我自己。
有一種感覺是我開始在 Google工作才有的。而且，那感覺越來越清晰，越來越吸引人，以至於十年下來，我幾乎把這種感覺視為我工作時的第一推動力了。怎麼說呢，這種感覺可能很多人都有，描述出來大概是：
在整個職業生涯裡，至少要有一部分（哪怕是一小部分）時間，可以比較純粹地為了開心而工作。一家公司是否適合自己，主要就是看這家公司能不能，或者在多大程度上能滿足這個需求。
我在 Google做不同項目，有時很吃力，有時很痛苦，有時很緊張，當然有時也會開心。但普通項目沒法讓我比較純粹地享受那種開心、愉悅的幸福感，於是乎，我在最近五六年裡，把我的 20%時間，都投入到了 Google Doodles這個既有趣，也適合我的項目裡。
Doodle，嗯，首頁塗鴉，純粹為了讓用戶開心而設立的專案。這專案既需要畫畫的藝術家，也需要寫動畫、音效和遊戲代碼的成員，不但好玩，還特別有品，特別有文化。因為參與其中，我有機會跟 Google總部那些厲害的藝術家一起合作，真的開心。
有一次做 Google生日的 Doodle，大家選中的是美國小孩子在生日常玩的一種叫 Piñata的遊戲。在電腦裡實現這樣的遊戲，需要簡潔的美術風格，支援 JavaScript的物理引擎，還有平滑、高效的動畫引擎，這些是技術細節，不展開談。
可在技術之外，我們這群追求開心的人硬是嚷著要親自玩一次現實裡的 Piñata。那次在 Mountain View，就在 Google總部有一隻霸王龍骨架的那片空地上，我們把一個真的 Piñata掛在樹上，輪流用竹竿去打，直到打出一地的糖果來。十幾個藝術家和工程師開心得像小孩子。
就是很純粹的，很簡單的，很開心的那種體驗。無論工作裡有多少煩惱，至少要給自己保留這樣一塊空間，叫心情家園也好，叫隨便什麼名字也好，哪怕再小，也得有那麼一個。
對我來說，在參與 Doodles專案的過程裡，可以和 Doodles紀念的偉大科學家、藝術家們跨時空交流，可以和正在設計、製作的小動畫、小遊戲隨時互動，可以預測到最終用戶看到每個 Doodle時的快樂，這的確是一件超贊的事。
很幸運，Google可以為我這樣追求開心的人提供合適的機會。很不幸，（我確切地知道）不少公司從不考慮員工的這種需求。這大概也是公司基因決定的事，沒法強求。正因為有了在 Google的十年工作經歷，我才會毫不猶豫地將職業生涯中最重要的追求定義為“開心”。
十年職業生涯，除了快樂，還有歷史的厚重感。特別是 Google中國這十年，我有幸親歷歷史，可算人生裡的大風浪。不幸，許多歷史是不能詳盡言說或評價的，所謂春秋筆法，絕不僅僅是史官的政治妥協，更多情況下也是從更高維度審視歷史的一種大智慧。
總的說來，我喜歡一種本質上不是消極避世的“慢生活”，“快樂”和“多樣化”是這種生活的力量源泉。離開 Google後，我堅信這種生活就是自己的未來。想法漸多，身心漸老。下一個十年，請慢一些到來吧。
對於web前端的學習有不懂的，或者不知道學習路線，不知道學習方法，不知道該如何扎實能找到工作的朋友，我還是要推薦下我自己建的前端學習群：523218370，首先你要是前端黨，其次不管你是小白還是大牛，我都挺歡迎，小白嘛，主動點多問問題也就學好了，群裡每天分享乾貨，包括我自己最近花了一星期整理的一份適合2017年自學的最新web前端資料，送給大家，歡迎初學和進階中的小夥伴。
我打算離開 Google的舉動無異于自己砸碎金飯碗，放著穩定的收入和豐厚的福利不要，非要和不確定性為伍。其實，如果懂得“多樣性”的重要，這種左右兩難的困局就不再成立。既然有人選擇快節奏和世俗生活，為什麼我就不能辭了職，慢悠悠地隨著自己的興趣，由著性子，從不同的角度理解這個世界與自我的關係？為什麼“慢生活”就必須是一種逃避？
宇宙很大，人很渺小。安全感是扯淡，特立獨行地活著才最重要。
2
2.改變看技術心態
到 Google以前，我在國內做銀行業的業務軟體研發，給工行、中行之類的大企業做軟體。這和 Google這種面向最終用戶的互聯網背景是有天壤之別的。
以前看待技術，覺得是身外之物，是工具，是磚木，是用來解決用戶需求的必需品。這個心態其實也沒什麼錯，但不自覺地就把自己放在技術追隨者的位置上了。
那時的我，很多時間都拼命在瞭解、學習和追趕新技術，生怕落伍。從這個語言追到那個語言，從這個框架追到那個框架，從這個模式追到那個模式，從這個平臺追到那個平臺……根本停不下來。
那時的我只是個技術的“用戶”，就像搬磚蓋房子，如果不天天關心今年流行什麼材質的磚，明年流行什麼樣的房子架構，後年流行什麼樣的房子外觀，那肯定被客戶和其他程式師罵“老土”。
到 Google擼胳膊挽袖子一忙活，才發現以前的自己狹隘了，小氣了，井底之蛙了。原來以前追的好多頂尖技術，根本就是 Google工程師主導或參與鼓搗出來的。而且，Google內部還藏著許多外界不大知道的神奇玩意兒。最最重要的不同是——自己現在是引領技術潮流的大團隊中的一員了。
以前是不斷學別人怎麼設計房子，看別人推薦什麼材料蓋房子。現在，最頂尖的房屋設計專家、材料專家就在身邊，自己也很快就能和他們一樣指導別人蓋房子了。這種感覺，就像跳進了一個大寶藏，還清楚地知道自己並非盜賊，而是寶藏的主人。盜竊寶藏 vs.創建寶藏，這兩者間的差別很微妙。
心態一下子大不一樣了，從技術的“用戶”變成了技術的“主人”。
比如，有段時間要解決 C++的 ABI相關問題，猛想起 C++標準委員會的相當一部分人都是在 Google工作的，有一年的全體大會還是在 Google總部開的——那直接拉著既是同事也是 C++權威決策人的傢伙一起開會討論不就是了？
類似的，Linux內核的維護者、Python的發明人、UNIX的元老、Google Brain的創建者……跟那麼多牛人在一個公司裡工作，你肯定不好意思只是單方面地跟人討教，但凡有機會，你總會希望自己也像那些牛人一樣，為技術發展做點兒貢獻，哪怕只是一丁點兒。
再比如，像 MapReduce、Bigtable、TensorFlow之類由 Google原創、對業界影響深遠的技術，在 Google內部可不僅僅是身外的工具，它們都是 Google工程師這個大集體的作品和驕傲。因為大家都是主人，對哪些東西不爽，可以去鼓搗原始程式碼，可以去提交自己的補丁或者新功能，甚至推翻重做。
別小瞧這推翻重做，雖然很難很難，因為你得一邊說服老闆和用戶，一邊找到足夠的開發人手，但事實上， Google內部重新發明一遍、兩遍、三遍的框架、工具、庫、介面、服務比比皆是。一言不合就動手做個新版本、新系統，這毛病既帶來數不清的流程混亂，也帶來一山又比一山高的良性競爭——表面的混亂之下，良性競爭引發的技術飛躍常常超出想像。
在 Google，工程師有好幾萬，不能說每個人都渴望做技術的主人，但躊躇滿志的大有人在。因為 Google走在技術最前沿，有追求的工程師確實沒臉當個純粹的技術追隨者。當然，我的意思不是說 Google裡沒人去做那些不那麼酷的“苦力活兒”，而是說大多數人都有個爭強好勝的心態，即便是做相對簡單的技術工作，也時常會想想怎麼能做出世界一流的效果來。
拿面試來說，有個工程師想出了一道與月球相關的面試題，把演算法、程式設計、設計、維護問題放在太陽系的大背景下，層層追問。我在一次內部面試技術培訓時拿這道題當過樣例。結果，參加討論的工程師表達了截然相反的兩種意見，有人說這題設計精妙如天馬行空，另一些人則批評這題目遠離實際如鏡花水月。
其實，Google的技術宅們幾乎每天都在深入實際與憧憬未來這兩個極端的對位、矛盾、轉化中工作。常說的“仰望星空、腳踏實地”遠不能形容 Google工程師的兩面性。
一方面，工程師們深知自己的代碼是如何參與了這個地球乃至這個星系裡最前衛、最大膽的電腦系統，如何為諸如十年後的搜尋引擎、擁有人工智慧的手機或機器人、量子電腦、基因工程、無人駕駛汽車等貢獻力量；
另一方面，工程師們“極客”和“宅”的一面常常在外人難以注意的工作細節裡表露無遺——這裡有十數年如一日致力於優化編譯器的語言高手，有設計最好的代碼審讀系統的工具專家，有親自動手實現軟硬體原型的技術總監，有堅持為地球上每一種人類語言提供輸入輸出解決方案的國際化團隊……
這是心態的差別，或者說，是技術境界的差別，烙在 Google工程師的基因裡，旁人想學也未必學得到。
3
3.“管理”二字的意義
有時候工程師很難管理，因為大多數人都想法新、主意多、眼光高、個性強。在 Google，有時候工程師也很容易管理，只要鼓勵他們把一件看似普通的事兒做出世界級的水準，他們自己就有足夠優秀的執行力，用不著督促。
在 Google做技術經理帶團隊，和我以前在其他公司帶團隊，完全是兩碼事。這也許和技術團隊的平均水準有關，但根本還是管理境界的問題。
記得以前在別的公司，花大力氣搞開發流程管理，現在想想，大多是繁文縟節，程式化，教條化，最極端的像 ISO9000之類的流程認證，弄得所有人筋疲力盡，效果未必有多好。
到了 Google，發現一個秘訣，再多的規章制度，再多的流程，不如一套好用的工具來得有效。比如 Code Style和 Code Review，以前能把技術經理煩死，三令五申也執行不下去，頂多三天熱度之後，大家就陽奉陰違了。在 Google，這件事不完全是個制度的問題。
剛進來的工程師沒有過 Readability Review，他就沒法方便地自主提交代碼，這是代碼管理工具設置的硬性限制。這直接把工程師們送到評審委員會那裡接受“再教育”，沒錯，真的是“再教育”，連 Python之父 Guido van Rossum也花了挺大力氣才通過了 Python語言代碼的 Readability Review。
接下來，提交新代碼前，各種靜態、動態檢查工具自動運行，幫你報出一系列風格錯誤、編譯錯誤、單元測試錯誤和簡單的邏輯錯誤，你得先依著工具的提示，把這些低級別錯誤改一遍，然後才進入 Peer Review的環節。整個 Code Review都在非常方便的網頁工具裡完成，寫代碼的和審閱代碼的人可以方便地交互、討論，甚至線上修改代碼。
工具的“強制性”保證了制度的執行，工具的“便捷性”最大程度減輕了工程師執行制度的負擔，二者相輔相成。當然，Google內部也不乏對制度敷衍了事的，但相對其他公司，Google的確做得更好些。
說到管理，在 Google帶技術團隊的其實都苦哈哈的。我就先後兩次把團隊交給別人帶，自己樂得去做些單純的代碼工作。道理很簡單，頭銜是 Manager，可你沒法高高在上指手畫腳，Google最好的團隊帶頭人都是沖在第一線帶著大家一起幹，除了主動包攬大家不想幹的髒活、累活、雜活之外，還要做管理者必須的非技術工作，比如給每個人寫評語、定獎金，幫每個人申請升職，跟心理負擔重的談心……
一個人做兩份工，吃力不討好，對團隊成員的晉升也沒有決定權（這事兒也挺神的），這種 Manager的活兒，誰願意幹誰幹去，我是不大喜歡幹的。不過，不喜歡歸不喜歡，Google這種挺不一樣的管理既顯著混亂無序，又運行良好，確實很神奇。
嚴格地說，聰明人在一起，只需要激勵，不需要管理，Google的辦法主要也是強調這一點。
必須坦白，我加入 Google時，工程師才三千人上下，無序管理、自發管理、扁平管理占主流。Google越來越大以後，大公司病也如約而至。流程越來越複雜，層級越來越多，職權重疊和模糊越來越嚴重，不同團隊之間管理風格的差異也越來越大。
但即便如此，Google基因裡那種蔑視陳規、抵制辦公室政治、抗拒繁文縟節的管理風格還是能在許多團隊帶頭人的身上找到——這是 Google肌體裡的健康因素，活力因數，彌足珍貴。
順便說一句，最近中文圈子熱傳不寫代碼/不會寫代碼的 CTO一事，許多 Google工程師出身的 CEO/CTO都在朋友圈裡曬自己寫的代碼，以表明態度。我自己對技術管理者寫不寫代碼沒啥傾向，寫不寫都可以是好的管理者，但如果“不會寫代碼”還以此為榮，就完全沒法接受，這個是底線。
我在 Google面試了不少 Manager和 Director的候選人，都考過對方寫代碼或者至少討論一段代碼的能力——不是要他一定在管理過程中寫代碼，而是怕他和 Google工程師沒法交流，和 Google技術基因沒法共存。
在 Google做技術管理，學不到啥成文的規矩，能學到的其實主要靠“悟”。
4
4.看待職業生涯的心態
很多人來 Google還是奔著一份優越的薪資待遇來的。所以，這裡只談我自己。
有一種感覺是我開始在 Google工作才有的。而且，那感覺越來越清晰，越來越吸引人，以至於十年下來，我幾乎把這種感覺視為我工作時的第一推動力了。怎麼說呢，這種感覺可能很多人都有，描述出來大概是：
在整個職業生涯裡，至少要有一部分（哪怕是一小部分）時間，可以比較純粹地為了開心而工作。一家公司是否適合自己，主要就是看這家公司能不能，或者在多大程度上能滿足這個需求。
我在 Google做不同項目，有時很吃力，有時很痛苦，有時很緊張，當然有時也會開心。但普通項目沒法讓我比較純粹地享受那種開心、愉悅的幸福感，於是乎，我在最近五六年裡，把我的 20%時間，都投入到了 Google Doodles這個既有趣，也適合我的項目裡。
Doodle，嗯，首頁塗鴉，純粹為了讓用戶開心而設立的專案。這專案既需要畫畫的藝術家，也需要寫動畫、音效和遊戲代碼的成員，不但好玩，還特別有品，特別有文化。因為參與其中，我有機會跟 Google總部那些厲害的藝術家一起合作，真的開心。
有一次做 Google生日的 Doodle，大家選中的是美國小孩子在生日常玩的一種叫 Piñata的遊戲。在電腦裡實現這樣的遊戲，需要簡潔的美術風格，支援 JavaScript的物理引擎，還有平滑、高效的動畫引擎，這些是技術細節，不展開談。
可在技術之外，我們這群追求開心的人硬是嚷著要親自玩一次現實裡的 Piñata。那次在 Mountain View，就在 Google總部有一隻霸王龍骨架的那片空地上，我們把一個真的 Piñata掛在樹上，輪流用竹竿去打，直到打出一地的糖果來。十幾個藝術家和工程師開心得像小孩子。
就是很純粹的，很簡單的，很開心的那種體驗。無論工作裡有多少煩惱，至少要給自己保留這樣一塊空間，叫心情家園也好，叫隨便什麼名字也好，哪怕再小，也得有那麼一個。
對我來說，在參與 Doodles專案的過程裡，可以和 Doodles紀念的偉大科學家、藝術家們跨時空交流，可以和正在設計、製作的小動畫、小遊戲隨時互動，可以預測到最終用戶看到每個 Doodle時的快樂，這的確是一件超贊的事。
很幸運，Google可以為我這樣追求開心的人提供合適的機會。很不幸，（我確切地知道）不少公司從不考慮員工的這種需求。這大概也是公司基因決定的事，沒法強求。正因為有了在 Google的十年工作經歷，我才會毫不猶豫地將職業生涯中最重要的追求定義為“開心”。
十年職業生涯，除了快樂，還有歷史的厚重感。特別是 Google中國這十年，我有幸親歷歷史，可算人生裡的大風浪。不幸，許多歷史是不能詳盡言說或評價的，所謂春秋筆法，絕不僅僅是史官的政治妥協，更多情況下也是從更高維度審視歷史的一種大智慧。
總的說來，我喜歡一種本質上不是消極避世的“慢生活”，“快樂”和“多樣化”是這種生活的力量源泉。離開 Google後，我堅信這種生活就是自己的未來。想法漸多，身心漸老。下一個十年，請慢一些到來吧。
對於web前端的學習有不懂的，或者不知道學習路線，不知道學習方法，不知道該如何扎實能找到工作的朋友，我還是要推薦下我自己建的前端學習群：523218370，首先你要是前端黨，其次不管你是小白還是大牛，我都挺歡迎，小白嘛，主動點多問問題也就學好了，群裡每天分享乾貨，包括我自己最近花了一星期整理的一份適合2017年自學的最新web前端資料，送給大家，歡迎初學和進階中的小夥伴。