?
1. 轉載自http://book.douban.com/review/6007037/，版權歸丸子(^.^)v所有。
New Google employees (we call “Nooglers”) often ask me what makes me effective at what I do. I tell them only half-jokingly that it’s very simple: I do the Right Thing for Google and the world, and then I sit back and wait to get fired. If I don’t get fired, I’ve done the Right Thing for everyone. If I do get fired, this is the wrong employer to work for in the first place. So, either way, I win. That is my career strategy.?
?
這是我讀這本書過程中看到覺得最激動人心的話^_^ 工程師科學家群體可愛的一點， 就是在這個群體中你還可以找到這么一些人， 他們不僅敢于堅持， 毫不畏懼自己的堅持可能給自己帶來的所有潛在的損失， 敢于面對， 并且敢于說出來， 以一種非常自豪的態度， 類似像老子 敢做就敢當， 敢想就敢承認！ 這樣～ 這讓我覺得我并不孤單>_< 這已經有點相依為命的感覺了， 因為同類真的太少太少～ 然后我就在當天的facebook廣播里插播上了以下這么一段:?
?
It applies to be effective to find the right one. I just do the right thing for her and me and possibly "us", and sit back and wait to get fired. If I do not get fired, I have done the right thing for everyone. If I do get fired, this is the wrong one to accompany with in the first place. So, either way, I win. That is my truelove seeking strategy = v=?
?
開篇intro說是寫給工程師看， 其實到后來， 后來特指最后一章， 感覺更像是寫給經理看來著， 但跟專門寫給經理看的 比如人月神話， 人件等等相比又總有點獨善其身的味道。 個人覺得就是寫給team lead那么個角色看的～ 首先， team lead并不一定是coding最強那個， 比如我現在就是team lead了， 在以intermediate level入職14～15個月以后， 其中前兩個月是完全頹廢的 接下來四個月是半廢狀態， 個人覺得單就技術而言還遠遠不到principle engineer或者architect的程度； 第二， team lead的職責不是說code完自己那部分就完事了， 下接程序員 上接經理， 要按各人的強項分派給各人相應的任務， 保證隊員的個人生活的同時還要按著經理的要求， 保證各功能特性的開發進度貼著商業宣傳發布計劃或者集團里其他部門的合作項目的進度那么來走， 有任何搭不上的就是team lead在奔走協調 有任何特別難都沒人做得來或者直接就沒人愿意接手的就是team lead來做 holy shit； 最后， 在木有架構師并且又非常需要大的翻新重寫的時候， 就是team lead來擔任這個苦逼的角色了， 尤其隊中有元老反對重構的時候， 還必須用禮貌而堅決強硬的方式獲取他們對此事的支持， 維持…… 媽的那個詞兒用中文怎么說來著？ 團隊的結構完整思想一致性～ 囧～ Anyway, this book is not for writing good code, but for writing good software! For some reasons, 除了設計模式， make it big in software和代碼閱讀技巧以外， 這本書是每個CS畢業生都應該懂但學校沒有教的內容之一。 For future reference， 下面簡單總結一下全書中比較實用需要時刻銘記在心練習到深入骨髓任何時候不爆線不走光的技能和辦公室行為基本指導思想：?
?
不要隱藏自己的過失以及能力上不足的地方， 做不到就老老實實說做不到 向做得到的人請教＝ ＝ 盡管有可能失敗， 還是可以努力往前邁進， fail early, fail fast, fail often. 這樣我們才有改進的機會～ 那做為人生來講，如果每件事事后都注意總結， 注意改進， 簡單說如果能保證每個錯誤你此生只犯一次， 那一生失敗的總數應該是一定的～ 那么， 少年， 讓我們盡量向只犯一次這個目標看齊， 把失敗的quota在前40年都用光吧～?
?
讓團隊成員之間心無芥蒂 同心協力的關鍵： 人性， 尊重， 信任(HRT)。 實際上包括但不限于辦公室這么個背景環境， 任何社交方面的沖突都可以歸結為 這三樣中某一樣或幾樣的缺乏。?
?
做為HRT的具體實現， 比如：?
沒人喜歡跟在哪里都表現得好像他特別重要的人合作。 看待自我的態度很重要， 這跟你對團隊的貢獻是兩碼事。?
關于code review， 討論措辭， 永遠記得一點， 幫助性的善意的批評 破是為了立 先立再破或者不破， 大家都心悅誠服滴follow你立起來的東西那其他的沒人去做了那就不攻自破， 這樣最大的好處是提出對立觀點的隊友不會有被critisized的不悅感＝ ＝ 沒人想被critisized 即便只是隊里一個嘍啰～?
迅速入手， 要失敗也失敗早一點， 這樣可以早點學習， 迭代式滴快速進行改進。?
留出時間學習 要分清重要的事和緊急的事。 緊急的事就是那些有deadline的， deadline越靠近越緊急。 重要的事就是那些區分你跟其他人技能等級知識水平的， 讓你變得不可被取代讓領導都感到有壓力覺得老婆生氣都不重要但一定要哄好你否則你一生氣撒腿走人一大攤子事舍你其誰可以瞬間陷入癱瘓。 區分度越大越重要。 一般公司讓你做的大多緊急的事， 辦公室里的生活就是deadline oriented， 有些可能很有技術含量， 不過應該不多， 因為做為經理來講他大概知道每個人的知識和能力， 分配你做你做不來的事到時候ship不出來那項目是要fail 的， 這時候要想獲得career promotion就要靠自己每天劃出一定時間來增益己所不能。 做為我來講， 在原來那家公司是android tech lead， 到現在這家公司一開始就是寫些可有可無的東西， 經理態度很明確啊， 就是你寫得出來當然好， 寫不出來那也沒所謂， 反正我們公司大著呢也不缺養著你這么個廢物的錢。 這時候尤其需要一種耐心， 那么耐心哪里來呢？ 從盼望中來。 每天學新的東西， 并且你知道怎么樣使你做同樣的事情比其他人做得更好的那些， 日積跬步， 始終focus在whatever currently assign to you， 然后你大概會知道在什么時候能冒出來， 然后你知道這樣不被信任的感覺什么時候可以終結， 這就是盼頭哇～ 而快速晉升的關鍵也恰恰在于此： 每一次不僅僅deliver一個能work的東西， 更重要的是deliver一種遠超預期， 一種amazing， 一種over qualified current position的感覺。 記住， 每一次！?
?
快節奏的生活中， 計劃往往趕不上變化， 但這不意味著我們就不需要計劃， 而是說， 在面對變化的時候， 懷著一種open 而實事求是的態度。 永遠不要覺得中途插進來策劃時間不到1分鐘的意圖取代你原來花一個星期才做好的計劃的這么一個想法就是不成熟不可采納或者totally bullshit， 試著想想你隊友也不弱， 無論技術水平開發經驗， 好吧其實我一直覺得我隊友們都比我強， 就那些一開口就“你還沒出生的時候我就怎么怎么滴”的貨， 那為什么會產生這樣的想法， 試著順著他們的出發點往下走， 一旦end to end的整條通路每個環節的邏輯都make sense，并且在bottleneck問題上跟你的方案比有勝出的地方， 那就不用管你原來那一個星期的努力白費了好可惜早知道就不去想了神馬這些碎碎念了， 大膽采用新想法。 這是一種快速自適應的能力， 也是一種適當相信別人， 相信你不能掌控的部分的能力。如果別人沒有能力掌控， 卻愿意憑著對你的信心相信你你覺得很appreciate的話， 那相信我， 你對別人做同樣的事情時別人心里會有跟你一樣的感覺！?
?
其實中國傳統教育中有很多事， 我覺得現在看來已經不適用了～ More specifically對快節奏辦公室生活來說我此時此刻腦里想到的有兩件事， 以前讀書時候學校從來沒教， 或者說有些學校教著完全相反的做法， 反倒是一些經常失戀的家伙寫的那些無病呻吟的文字里見得比較多： 一是忘記不該記住的， 二是相信你目前無法相信的， 無論那是憑你個人主觀感情， 或者甚至憑你已有知識能力做出的客觀分析都無法相信的。 第二點就是剛才說滴。 至于第一點， 遇到事情如果能在幾分鐘之內迅速處理， 或者figure out應該forward給誰處理最妥當， 那就迅速把它給做了， 然后最重要也是最難做到的是， 徹底忘了它！ 這樣你不用一直keep住一堆事在你腦里， 然后你可以全力以赴做好眼前的事。 如果不能， 那么靜下心來分析一下， 或者跟相關的人談如果有必要的話， 至少figure out要解決這個問題必須先解決哪幾個問題， 或者必須先滿足哪些條件， 而那些事又都是什么時候才會發生， 把整個dependency和各事情的timeline做成一個diagram整進calendar里 然后徹底忘記直到calendar提醒你每個單獨的事件。 Point就是說， 你要心無旁騖滴一直focus在你目前工作的事情上。這不是一句空話， 要切實做到， 最好的辦法是有效滴清空但不遺忘其他事情， 使你腦里任何時候就一件事…… (這跟 不要在一棵樹上吊死是兩碼事， 那是給那些有勇無謀的家伙， 用來把他們從另一個極端中拉回來用的。)?
?
接下來就是談文化的問題了。 構建團隊文化， 或者說企業文化的關鍵， 在于溝通。 溝通的量要大到能讓那么多千奇百怪思維形態各異的家伙工作起來真正實現 “one mind, many hands.” 方式可以有很多， 郵件列表， 內部wiki/BBS， 設計文檔， 代碼注解等等。?
?
大量溝通的關鍵是要讓別人樂意花時間花精力跟你練習英語原書講了很多很實用很具體的技巧， 總的來說， 就一條原則， 不要讓不想知道或者不需要知道的人知道。把握對象的背景知識傾聽興趣和時機。 向合適的對象傳遞合適的內容就比如如果我在看陳綺貞音樂專輯的頁面， 很可能我對陳綺貞在當地或者附近的現場演唱會信息感興趣， 收集了我的位置信息和瀏覽歷史紀錄以后你pop up相應的廣告我會很感激并且很樂意點擊， 但如果你這時候pop up 寶馬車的廣告， 無論畫面多好deal多吸引人我只會覺得占用了我本可以多看音樂專輯插圖以及過往現場演唱會圖片的地方； 在合適的時候傳遞合適的內容比如 OK我是很喜歡陳綺貞， 但現在我要聽一下她新專輯的demo片段， 我已經大量瀏覽過她的現場演唱會圖片或者我其實想等下再看這些， 反正我現在不想看， 我只想聽， 你就不要整版滴鋪那些圖片讓我找一個play button還要多點一堆鏈接 拼命壓抑自己狂躁的情緒多load一堆頁面， 最后才來到play button的所在。?
?
還有一點我現在做得很不好的， 尊重對方在交流中發表自己基于剛聽到的東西臨時起意產生的一些想法并得到認真對待無論那想法有多傻多天真的意愿和權利。?
?
有幾點原則需要一直遵守， 因為在絕大多數情況下這些實踐都是有利無害的～?
對每次commit 都要有code review?
開發過程需要有實時測試， 發布過程需要控制好， 使得發布變得容易， 這樣可以至少每周出一個QA release并且不占用dev team太多時間。 I do think we really need some automation。?
所有這一切溝通的努力都是圍繞著代碼在進行， 在進行溝通的過程中應該時刻記得這一點。 不要喧賓奪主讓工具和輔助手段變成工作生活的全部或者說， 大部分～ 這不僅在開發活動中， 其實我想說在日常生活中人們經常犯著類似的錯誤， 矯枉過正。 比如以前在計算機學院經常可以看到一堆人整天都在學英語， 沒錯英語是計算機的母語， 沒錯工欲善其事必先利其器， 沒錯我們全都用英文影印版在教學英文不好看到都頭大根本沒法學， 好吧老師講課是用中文所以…… 但是也不用把90%以上的時間都拿去學英文到畢業的時候英文比外語學院的人都利害看到函數指針直接傻掉“這什么呀這寫錯了吧 指針沒有這么聲明的吧blablabla” ； 再舉個例子， 比如在一段relationship里， production code是你的另一半， 是那個人， 愛只是工具或者輔助手段， 愛把你們兩連在一起， 結婚是跟那個人連接成一體不是跟愛連接成為一體， 很多搞錯這兩者關系的人的一個外部表現就類似， 不斷滴換著愛人， 享受被愛的感覺， 愛是重點是享受的來源人只是一個工具用來提供愛的具體是哪個人來提供并不重要 重要的是如果這個工具malfunctions， 很簡單那就換一個啰就像如果我的車壞了修都懶得修直接買一輛新的， 坐什么車我并不在乎我在乎的是任何時刻要有這么個東西給我提供這種競速的感覺…… 這項原則應該應用在不只包括平常隊友間的口頭溝通， 包括但不限于電子郵件， 內部IM， 設計文檔， 產品目標定義文檔， 代碼注釋等等， 既要保證別人充分理解， 又要盡量減小communication overhead， 這里不是打馬虎眼， 而是這個微妙平衡的拿捏真的是case by case。 這本書中介紹的是對大多數場合70％～80％適用的approach， 看完以后需要自己figure out的是稍微改變一下， 看怎么樣就對我現在身處的場合100%， 或者至少95%適用的approach。 關于這個平衡的拿捏， 有一本書， 中國人寫的個人覺得還挺不錯的， 名曰 大道至簡。 貌似作者是在金山還是騰訊當一個什么東西記不清了……?
?
Every boat needs a captain 這一章真的就完全是針對team lead這么個角色說的了～ 其實并不是說一定要title 掛上這個， 很多公司甚至都木有這么個title 但是如果你每日的工作主體， 你60%以上的時間都工作在相應的職責上， 那都可以讀一下。 實際上如果一些基本指導思想已經在你腦中成型甚至運用得爐火純青的話， 這一章是可以不看的， 或者說任何軟技能的東西都可以不看， 遇到事情具體問題具體分析只要解決方案不違反江湖道義不違背武林狹義你看怎么好使就怎么來吧， just simply let it as it is, 我相信在一些靠譜指導思想下做出的解決方案不會差到哪里去， 比那些教條主義把課本中的定理運用到不合適的地方的家伙要好得多。 這一章最主要就是給出， 比如基于這么幾條辦公室行為指導思想， 那具體到team lead這個位置面對這種情況應該具體使怎么表現呢？ 如果你不具備自己figure out解決方案得能力或者你想求快直接拿人家現成的做法來進行實踐然后基于反饋去修正的話， 也可以讀一下。 書中列舉了幾個antipattern， 我不是完全贊同的， 但是人家對此是有著多年實踐經驗的， 最重要的一點是有著眾多成功經驗的， 而我剛那啥＝ ＝ 還是那句話， 如果沒立起來， 不要隨便去破……?
?
最后一章主要論述了， OK前面說的是理想情況， 那萬一真遇到了豬一樣的隊友， 好吧也不是說人家蠢就是說對團隊產生負面影響的人要是不幸跟你共事， 從developer的角度應該如何相處； 這是一方面另一方面在于如果你直接report的那個經理是個小人， 餓你筋骨勞你體膚還搶你credit 屁事不干啥都不懂就會瞎指揮， 那從developer的角度又該怎么辦， 什么時候采取defensive的approach什么時候采取農村包圍城市的還蠻aggressive的approach， 然后談到辦公室政治 ＝ ＝ 局面變成這一步就很不好了但是感謝主， 我現在的情形還不需要考慮這個。 最后講到對產品， 如果你個人能控制產品特性和發展戰略的話在考慮這些問題的時候思路里應該包括哪些因素， 目前我也還沒到這一步， 可以mark一下到時候再回來看。?
?
這段時間職場上發生的事情讓我越發相信，真正的相信，純粹的熱愛，小小的嘗試，長長的堅持，就可以慢慢成就大大的夢想， 雖然生活中發生的事情恰恰相反＝ ＝?
?
最后， 以一首詩來概括一下這段時間的工作學習生活：?
?
日升月落， 生生不息的世界?
永恒的遠方， 你的輪廓在夕陽中融化?
找到了一種幸福足以悲傷?
沉默的祈禱只為安撫受傷的靈魂?
當一切歸還于寂靜 我則別無渴求……??
?
?2.自己的話
我沒有丸子(^.^)那么多的經歷和經驗，能從自身和外部環境寫出這么多的感悟。
我的感悟，可能就是，作為一名職場新人，如何融入團隊，如何對待豬一樣的隊友，如何對待神一樣的隊友，如何處理與leader的關系，如何從leader的角度出發考慮問題，如何培養自己成為leader。
至于目前，對我來說，融入團隊最重要的是，培養自己的技能樹，讓自己成為某一方面的專家。做一些career promotion方面的工作。
?
?
?
?
?
)
