我正式走上職業生涯是 2011 年秋天，完成了博士學業，躊躇滿志地加入了 google。當時，我的理想是做 google 裡生產率最高的軟體工程師。為此，我列了乙個高效工程師名單，看他們每天提交的**是些什麼，以從中學習高效的工作方法。這個名單裡有 jeff dean, sanjay ghemawat, rob pike，還有一些 google 內 7 級以上的工程師。因為 google 內部源**提交全部公開，我可以看到他們每天的工作內容。
很快，從讀這些**中我認識到了一點：人每天只有八個小時工作時間，誰都一樣。其中能高效工作的時間絕對不超過4個小時。這些工程師編寫的**行數絕對不算多，但從事的專案影響大。比如 pike，大部分時間花在了審查其他成員的 go **上。而乙個剛入行的 golang 工程師，每天的任務就是寫作 go 的標準庫，今天寫 http 明天寫 sort，寫的比 pike 多很多。考核時，高階工程師因為帶領著高效團隊，每季度 okrs 上都有諸多亮點；而剛入行的工程師，只能報告一些比較瑣碎的成就。
這個觀察近乎於常識，然而對於當時的我來說是乙個頓悟：做出 mapreduce 框架的和寫瑣碎 mapreduce 程式的工程師之間的差距並不是他們的工具和程式設計效率，也往往不是教育背景或者經驗，而是他們各自的槓桿：所帶領的團隊。
問題是，沒有人會給你這個槓桿。於是，我開始觀察別人的槓桿是怎麼搭建的。
google 的芝加哥 office 有兩個技術領導：brian fitzpatrick 和 ben collins-sussman。他們合寫了一本書，叫做 team geek。近水樓台，我就拿了一本過來看。或許對於 google 之外的人來說，這本書講了許多有價值的東西，對於 google 員工來說，基本上書裡面說的就是公司每天實踐的，因此讀來覺得都是常識。這讓我突然領悟到，其實所謂的團隊工作，或許說白了就是正確地運用這些常識。
在實踐中運用常識遠比想像中的難。有一次在搏擊課上，師傅讓我和某個拿過法式拳擊世界冠軍的師兄對練。他手腿都很長，出拳又快，根本拿不到破綻。為了不被首輪打倒，我不得不滿場跑著閃躲。躲著跑過師傅的時候，他就說了一句：「你只管出拳，不出拳永遠贏不了點數」。其實這是每個學搏擊的人都知道的常識，卻因為一時的恐懼徹底忘了。做技術領導時也是一樣，許多我們知道的常識性的東西，一旦遇到複雜情況，我們往往依賴於舊習慣和情緒反應，忘了要解決的問題，忘了運用常識做出正確的判斷。
常識是可以習得的，因為每個人都有包容常識的心性。問題是，所謂常識，是名常識，實非常識。根本沒有一本叫做「技術管理常識」的書，讀完就事理無礙了。在領悟到技術管理其實是運用基本常識之前，我買了一大堆的關於技術管理的書，幻想能夠博聞強記速成。想明白「習得」這一點，讓我輕鬆了好多：這不是入學考試，慢慢積累最省時省事。就像練習武術一樣，最強的鬥士絕不是看書最多或者理論最強的，而是訓練時間最長的。
我曾經也醉心於一些管理方法。比如說，kanban 管理法是照搬了豐田在七十年代的高效率生產模式而提出的。06年第一次讀這個管理方法的時候崇拜無比。到了2023年，豐田汽車在世界範圍內發生了多起質量問題召回的事情，使我重新審視這個問題：任何管理方法都是為了解決某些類問題而催生的。問題變了，不管以前多麼神奇的管理方法都會變得一地雞毛，因為管理方法不能脫離要解決的問題。
也就是這個時候，我重溫了溫伯格的《技術領導之路》。這本書對於我來說最有價值的一點，是讓我體會到儘管管理方法成千上萬，歸根到底需要一些「元方法」去支配。比如，書中提到了乙個大家都明白的元方法：寫日記。技術領導者每天寫日記，記下每天的活動，反思一些事情。儘管寫日記並不能直接解決技術管理上的難題，卻開啟了反思之門，也把許多事情前因後果連線起來。比如，通過在日記裡反思一些會議的效率，我開始有意識地反思高效率的會議和低效率的會議的差別，並主導一些會議的日程。顯然，真正的問題不是要不要設定議事日程（元方法），而是學會怎樣設定乙個特定會議的議事日程（解決問題的方法）。而後者，只能通過設定議事日程學到。
我是乙個理科生。理科生理解世界的第一工具是模型。世界過於複雜，人腦計算能力有限，只能付諸模型抽象簡化。技術管理作為技術（工程學）和管理（自然科學）的橫切點，自然免不了各種各樣的模型。技術管理的模型本身多種多樣。人月神話模型，人件模型，豐田模型，溫伯格模型，agile 模型，lean 模型等等不可列舉。對於乙個技術管理人員來說，幸運的是，所有的模型都是錯的，所以即使不知道這些模型，也未必遺漏了什麼重要的。不幸的是，有些模型的確比較有用，所以知道一些還是有好處的。
正因為此，我開始收集一些工作中積累的管理模型 (pattern)，像 gof 的 design pattern 一樣，列出要解決的問題，模型，和自己的實現。我收集了不少細碎的模型。有時候覺得過於細碎，不足為外人道也；有時候又覺得好像還是有些用處的。
就這樣，在不斷的寫作懶惰症中過了三四年。直到最近，說來也巧，在檢查乙個 bug 的時候發現有某使用者呼叫 fitbit 的食物記錄 api 中試圖存下 「豬和雞」，這提醒了我那個著名的 the chicken and the pig 笑話，以及我的好友 tinyfool 一直開玩笑說我寫的「程式設計豬和雞番外篇」系列，促發了我寫作「技術管理豬雞」的想法。這一篇，算是乙個很不正式的開頭。
upyun.com是國內領先的雲服務提供商，專注於提供靜態檔案的雲儲存、雲處理和cdn加速服務。現在註冊，即可免費體驗！
Google工程師批評Google 可悲的馬後炮
2011 10 13 05 15 22 閱讀 31次 pathetic afterthought google軟體工程師史蒂夫 耶格 steve yegge 周二晚上公開發表文章，後來文章被撤銷，儘管如此，他的話仍然迴盪在網路。史蒂夫 耶格的文章顯然只是想與內部人分享，但因為失誤而公開。文章談及了自...
誰更聰明 Google工程師PK微軟工程師
一次，三個google公司的工程師和三個微軟公司的職員乘火車到另乙個城市去開會。在火車站三個微軟公司的職員每個人各買了一張火車票。然而他們驚奇地看到三個google公司的工程師一共只買了一張火車票。你們三個人怎麼可以只用一張火車票乘火車旅行呢？乙個微軟公司的職員問。你們就等著瞧吧。google公司的...
如何成為Google軟體工程師？
原文 http www.google.com.hk intl zh cn jobs lifeatgoogle meet 招聘的流程？簡歷篩選 訪談 現場面試 offer發放 面試包括哪些內容？如何對申請人的工程技能進行評估？我們會根據以下四個方面來進行評估 如何準備面試？認識google員工？和他聊...