文章發出之後，Jeff Dean 表示：「我認為這篇文章精準地捕捉了我們的工作風格。」
讓我們看看這篇歷時一年半才寫成的「黑歷史」都說了些什麼。
0 和 1 之下
2000 年 3 月的一天，谷歌六名最優秀的工程師聚集在一個臨時「作戰室」裡。當時的谷歌正處於前所未有的緊急狀況中：1999 年 10 月，谷歌的核心繫統（抓取網頁然後構建「索引」）停止運轉。儘管使用者當時仍可以在 google.com 中輸入查詢，但搜尋結果已經是五個月前的了。工程師意識到的困難更多。當時，谷歌聯合創始人 Larry Page 和 Sergey Brin 商議與雅虎進行合作，為雅虎提供搜尋服務，他們承諾提供十倍於目前索引結果的索引，以跟上全球資訊網的增長（2000 年全球資訊網的規模是前一年的 2 倍）。如果失敗，google.com 仍然是時間膠囊，凝固在過去的時間中，與雅虎的合作可能失敗，谷歌有可能燒完現有資金，然後死亡。
在樓梯旁的一間會議室裡，工程師將門板橫在木板凳上，在上面放置計算機。27 歲的 Craig Silverstein 坐在牆邊。他是谷歌第一名員工：在谷歌辦公室還在 Brin 起居室時他就加入了這家公司，並且憑一己之力重寫了很多程式碼。四天四夜之後，他和一名羅馬尼亞系統工程師 Bogdan Cocosel 仍然一籌莫展。「我們所做的所有分析都沒有用，一切都崩潰了，而我們卻找不到原因。」Silverstein 說道。
Silverstein 幾乎沒有注意到 Sanjay Ghemawat，這位安靜的 33 歲 MIT 畢業生眉毛濃密，一頭黑髮，但鬢角處已經斑白。Sanjay 幾個月前加入這家公司（12 月）。他追隨 Jeff Dean 加入谷歌，他們之前同在 Digital Equipment Corporation。Jeff Dean 比 Sanjay 早十個月離開 D.E.C.。他們關係很好，喜歡一起寫程式碼。在作戰室裡，Jeff 把椅子挪到 Sanjay 的桌子處，Sanjay 使用鍵盤工作，Jeff 就在一旁糾正錯誤，就像製片人通過耳機對新聞主播耳語一樣。
Jeff 和 Sanjay 開始專心檢查停頓的 index。他們發現一些關鍵詞丟失了，搜尋「mailbox」時無搜尋結果，有搜尋結果時也是亂序的。這些天來，他們一直在查詢程式碼中的錯誤，檢查程式碼的邏輯。然而，每一部分都檢查過之後，依然沒有發現 bug。
程式設計師有時候將軟體概念化為多層結構，包括頂層的使用者介面和比較基礎的層。探索該結構的底部（即軟硬體的交接處）意味著不再按照程式碼的邏輯順序，而是觀察程式碼依賴的電子和矽的宇宙。在作戰室的第五天，Jeff 和 Sanjay 開始懷疑問題可能不在於邏輯，而存在於物理層面。他們將混亂的索引檔案轉換成原始表示格式：二進位制程式碼。他們想了解機器看到了什麼。
多個 1 和 0 的列出現在 Sanjay 的顯示器中，每一行表示一個索引詞。Sanjay 指出：一個本應該是 0 的數字卻顯示為 1。Jeff 和 Sanjay 將所有錯誤分類的詞放在一起，然後觀察到一種模式：每個詞都出現了同樣的故障。機器的儲存晶片被破壞了。
Sanjay 看著 Jeff。幾個月以來，谷歌正在經歷越來越多的硬體故障。當時的問題是，谷歌正在成長，所以它的計算基礎設施也在擴張。計算機硬體很少出錯，直到問題積累爆發——然後就會一直無法運轉。線路磨損、硬碟壞道、主機板過熱。很多機器從一開始就沒有工作過，有些則速度慢的讓人無法接受。各種奇特的環境因素也必須考慮在內——當超新星爆發時，爆炸會產生向所有方向散發的高能粒子。科學家認為有很小的機率，一種被稱為宇宙射線的粒子可以擊中計算機晶片，讓 0 和 1 翻轉。所以，世界上最魯棒的計算機系統，比如 NASA、金融公司的系統，會使用可以接受單位元翻轉的特殊硬體。但此時的谷歌仍然更像一家初創公司，使用的是缺乏這種功能的廉價計算機。這家公司已經到了發展的拐點，它的計算叢集變得無比巨大，大到無法忽視這種硬體故障。
Jeff 和 Sanjay 一起寫程式碼來補償硬體的問題。很快新 index 就完成了，作戰室宣告解散。Silverstein 曾陷入困境。他是一個很好的除錯員，但解決的關鍵是找到問題的根源，Jeff 和 Sanjay 走得更深。
在 3 月份 index 崩潰之前，谷歌的系統根植於其創始人在史丹佛大學攻讀博士期間所寫的程式碼。Larry Page 和 Sergey Brin 並不是專業的軟體工程師，他們是在學界進行搜尋技術實驗的人。當他們的網路爬蟲崩潰時，並不會出現診斷資訊——只會出現諸如「Whoa、horsey!」之類的字眼。谷歌的早期員工常稱之為 BigFiles，其名稱來源於 Page 和 Brin 的一個軟體 BugFiles。他們最重要的索引程式碼需要數天時間才能執行完成，如果遇到問題則必須從頭開始重新啟動。按照矽谷的說法：谷歌不具有「可擴充套件性」。
我們會說「搜尋整個網路」，但實際上搜尋引擎並不會這麼做：我們的搜尋引擎會遍歷 Web 的索引——一張地圖。當谷歌在 1996 年仍被稱為 BackRub 時，它的地圖還很小，足以被裝進 Page 在宿舍安裝的電腦裡。但到了 2000 年 3 月，已經沒有足夠大的超級計算機可以處理它了。谷歌要跟上全球資訊網增長速度的唯一辦法就是購買消費級電腦並將它們組成叢集。因為電腦的一半成本都花在了對谷歌無用的軟盤驅動器、金屬機箱上，因此谷歌購買電腦主機板、硬碟，然後自己組裝電腦。谷歌有五百個這樣的計算機，堆起來有六英尺高，它們被放置在加州聖塔克拉拉的谷歌資料中心。由於硬體故障，僅有二百臺計算機能夠正常運轉。這些看似隨機發生的故障繼續摧殘著整個系統。為了生存，谷歌不得不將計算機連線成為一個無縫、堅韌的整體。
Jeff 和 Sanjay 共同主導這一舉措。2000 年 11 月，曾在蘋果公司研究蘋果電腦的 Wayne Rosing 加入谷歌，運營百人工程團隊。「他們是領導。」他說。工程師每週工作九十個小時，如果不把程式碼輸入整體系統，則單個硬碟肯定會出現故障。於是工程師為網頁抓取過程新增了檢查點。通過開發新的編碼和壓縮機制，他們有效地使系統容量翻倍。他們是不懈的優化者。汽車拐彎時，外輪覆蓋的地面面積更大；類似地，運轉著的硬碟的外邊緣（outer edge）比內邊緣更快，但內部處於半空狀態。Jeff 和 Sanjay 使用該空間儲存常見搜尋查詢的預處理資料。2001 年 1 月 4 日，他們證明谷歌的 index 可以使用快速隨機存取儲存器（RAM）來儲存，而不用相對緩慢的硬碟，這一發現重塑了谷歌的經濟狀況。Page 和 Brin 知道使用者會樂於使用一項能夠提供即時答案的服務，問題在於速度（即時性）需要算力，而算力需要錢。Jeff 和 Sanjay 完成了這一艱鉅任務。
2005 年 Rosing 離開谷歌後，Alan Eustace 成為工程團隊的新領導。Eustace 稱，「荒謬的是，要想解決大規模問題，你必須先了解最微末的細節。」Jeff 和 Sanjay 對計算機有非常深入的瞭解。Jeff 曾經寫過一份清單《Latency Numbers Every Programmer Should Know》。實際上，這是一份數字清單，幾乎沒有程式設計師瞭解。而這些數字已經嵌在 Jeff 和 Sanjay 的大腦中。他們帶頭對谷歌的核心軟體踐行了幾次重寫，該系統的容量擴充套件了幾個數量級。同時，谷歌的資料中心專家按照軟體生成的指令來設定硬碟、電源供給和記憶條。這樣即使某個部件壞了，整個系統仍然能夠運轉。
今天，谷歌的工程師處於一個「存在鎖鏈」中，從 Level 1 開始。最底層一級即 Level 1 是 IT 支援人員，Level 2 是應屆大學畢業生，Level 3 通常有碩士文憑。到達 Level 4 需要幾年工作經驗，或者有博士文憑。大部分工程師停留在 Level 5。Level 6 工程師（top 10%）能力非常強悍，他們可以是一個專案成功的關鍵。Level 6 工作經驗逐漸增長到一定程度會升成 Level 7，而 Level 8 和主要產品或基礎架構相關。Level 9 是 Distinguished Engineer。Level 10 是 Google Fellow，該榮耀一旦得到將伴隨一生，Google Fellow 通常是其領域內的世界級頂級專家。而 Jeff 和 Sanjay 是 Google Senior Fellow——谷歌唯二的 Level 11。
大腦的兩個部分
這兩位頂級程式設計師就像一個大腦的兩個半球
谷歌園區坐落在距離山景城中心幾分鐘車程的高速公路旁，園區裡的建築矮矮的，沒有什麼吸引力。去年夏天的一個週一，在一起程式設計整個上午之後，Jeff 和 Sanjay 去了一家名為 Big Table 的餐廳吃午飯，這家餐廳是以他們倆 2005 年幫助開發的一個系統命名的，該系統將無數計算機視為一個資料庫。Sanjay 又高又瘦，穿著一件 maroon Henley 的舊 T 恤、灰色褲子，戴著一副小小的線框眼鏡。他發現餐廳外面有張空桌子，快步走過去佔了，開啟傘，在陰涼處坐下，還替 Jeff 把另一把椅子搬到了太陽下。幾分鐘後，Jeff 到了，肩膀寬寬，穿著短袖襯衫和時髦的運動鞋。
兩人就像一對夫妻，各自講述一點過去的事情，就這麼拼湊出了過往的回憶。他們開始回憶早期的專案。
「我們當時還是手打程式碼，」Sanjay 說道。他的眼鏡在陽光下萌生出一絲陰影。「我們會重寫程式碼，然後感覺——『噢，這和上個月寫的好像差不多』。」
「或者索引資料的傳遞略有不同。」Jeff 補充道。
「略有不同……我們就是這樣發現問題。」Sanjay 說。
「這是重點。」Jeff 說。
「這是常見模式。」Sanjay 補充完。
Jeff 咬了一口他買的披薩。他長著像水手一樣的手指，指節粗大還有點粗糙；相比之下，Sanjay 看起來似乎有點脆弱，他也不知道當初是怎麼和 Jeff 成為搭檔的。「我也不知道當初是怎麼決定在一起合作的。」他說。
「我們加入谷歌之前就是搭檔了。」Jeff 說。
「但我記不清為什麼要在一臺電腦上程式設計，而不是在兩臺電腦上幹活。」Sanjay 說。
「在 D.E.C. 工作的時候，我經常從我的實驗室走兩個街區去他的實驗室，」Jeff 說道，「路上有家冰淇淋店。」
「是有家冰淇淋店！」Sanjay 高興地說道。
Sanjay 一直未婚，但他會和 Jeff 一家人去度假，Jeff 的兩個女兒喊他 Uncle Sanjay。他們五個人經常在週五一起吃飯。Sanjay 還會和 Jeff 的大女兒 Victoria 一起做烘焙。他自豪地說：「我算是看著她們長大的。」2004 年穀歌首次公開募股以後，他們搬到了僅隔四英里的房子裡。Sanjay 住在山景城一個普通的三居室裡；而 Jeff 則在帕羅奧多市中心附近設計了自己的房子。他在地下室裡裝了一張蹦床。在設計房子時，他發現雖然自己喜歡設計空間，但並沒有耐心去完成「適合 Sanjay 的部分」：橫樑的細節、螺栓以及保證整個設計不至於分崩離析。
「我不知道為什麼別人不這麼幹——合作程式設計。」Sanjay 說道。
「你要找一個與自己思考方式相容的人一起合作程式設計，這樣你們兩個就可以互補了。」Jeff 說。
在分享工作生活多年以後，兩個人會形成一種私密的語言，就像雙胞胎一樣。他們會模仿彼此的穿著和習慣，幽默感會在潛移默化中傳遞。他們的貢獻也很難分出高下。但這種強度的夥伴關係在軟體開發中非比尋常。雖然有些開發者嘴上會說「合作程式設計」——兩個程式設計師共用一臺電腦，一人「駕駛」一人「導航」，但他們通常認為這種合作是累贅。相比之下，Jeff 和 Sanjay 有時候看起來像是一個大腦的兩個部分。他們很多著名論文是二人合著的。他們的經理之一 Bill Coughran 回憶：「他們倆搭檔時效率很高也很多產，所以我們經常得圍繞他們倆組隊。」
1966 年，System Development Corporation 的研究人員發現，最出色的程式設計師效率是最差的程式設計師效率的十倍以上。自此，所謂的「十倍效率程式設計師」開始引發爭議。這個概念推崇個體，但軟體專案通常是龐大的集體專案，在程式設計中很少有人能獨立取得成就。即便如此——甚至有些諷刺的是，很多程式設計師都相信「十倍效率程式設計師」的存在，因為他們看到了 Jeff 和 Sanjay 的合作成果。
Jeff 和他的父母經常搬家。13 歲的時候，他在八年級的最後三個月裡翹課去西索馬利亞的難民營幫助父母。高中的時候，他開始為流行病學家編寫叫做 Epi Info 的資料收集程式；之後，這個程式成了流行病學家野外作業的標配工具，最終，該程式以十幾種語言發行了數十萬份。
Jeff 讀博期間專注於編譯器（一種將人寫的程式碼轉化成為計算機優化的機器語言指令的軟體。）「要說性感，編譯器真是無聊透了，」Alan Eustace 說道；但另一方面，編譯器卻可以幫你「拉近與機器之間的距離。」Jeff 描述道，Sanjay 則用食指揉著太陽穴。「你寫程式碼的時候他在研究一個模型，」他說。「『程式碼的效能將會如何？』他基本上會半自動地考慮所有極端情況。」
Sanjay 17 歲之前沒有碰過電腦，直到他去了康奈爾大學。1966 年，他出生在印第安納州的西拉法葉，但在印度北部工業城市科塔長大。他的父親 Mahipal 是一名植物學教授。Sanjay 的家人都很愛讀書：他的叔叔 Ashok Mehta 買過一本 Frederick Forsyth 寫的 The Day of the Jackal，這本書裝幀非常破舊，他看著 Ghemawat 家的孩子們一起閱讀這本書，並在讀完一頁時為他們翻到下一頁。Sanjay 的哥哥 Pankaj 成為了哈佛商學院獲得終身教職的最年輕教師（他現在是紐約大學斯特恩商學院的教授）。Pankaj 和 Sanjay 上同一所學校，被譽為「全才」（Renaissance man）。「我有點活在我哥哥的陰影下。」Sanjay 說道。因此，他一直都很謙遜。2016 年，當他入選美國人文與科學院（American Academy of Arts and Sciences）時，他沒有告訴他的父母，他們還是從鄰居那兒聽說的。
在 MIT 研究生期間，Sanjay 結交了一群關係密切的朋友。那時候 Sanjay 幾乎不曾約過會，現在也很少。他說過不是不想組建家庭，只是還沒到時候。他的朋友和父母已經學會接受這樣的他。也許是因為他安靜的性格，他在谷歌是充滿了神祕色彩的存在。他以安靜而深刻著稱：一個深思熟慮且不同尋常的人。在他的桌子上有一堆 Mead composition notebook，這些筆記本有近二十年曆史，裡面裝滿了整潔的清單和圖表。他用鋼筆寫作，字跡潦草。他很少引用舊筆記本，寫作是為了思考。在 MIT，他的研究生導師是 Barbara Liskov，這是一位有影響力的電腦科學家，研究複雜程式碼庫的管理。在她看來，最好的程式碼就像是一篇好文章。它需要一個精心實現的結構，每個詞都應該起作用。以這種方式程式設計需要與讀者共情。它還意味著不僅要將程式碼視為達到目的的手段，也要把它作為工藝品。「我認為 Sanjay 最擅長的是設計系統，」Craig Silverstein 說。「如果你只是看著他寫的程式碼檔案，會發現那就像一個比例勻稱的雕塑般美麗。」
在谷歌，Jeff 更為人所知。谷歌有所謂的 Jeff Dean 模因。但是，對於瞭解他們二者的人來說，Sanjay 是個與 Jeff 同等的人才。「Jeff 非常善於提出瘋狂的新想法和原型設計，」他們的長期同事 Wilson Hsieh 說，「Sanjay 是那個能夠持續開發到最後的人。」在生活中，Jeff 更外向，Sanjay 更內向。在程式碼中，情況正好相反。Jeff 的程式設計令人眼花繚亂（他可以迅速勾勒出令人吃驚的想法），但是，因為它完成得很快，並以發現的形式出現，所以它可能會把讀者甩在身後。而 Sanjay 的程式碼具備社交性。
「某些人的程式碼非常鬆散，滿螢幕的程式碼只攜帶了很少的資訊，你需要來來回回的反覆閱讀才能讀懂。」Silverstein 說。另一些人寫的程式碼則太密集了。「Sanjay 的程式碼風格恰好處於兩者之間，讀他的程式碼能很容易理解，同時也能獲取足夠的資訊。」Silverstein 繼續說，「無論我想在 Sanjay 的程式碼中新增什麼函式，都似乎是水到渠成的事情。我認為這很棒，但又不知道他是怎麼做到的。」
今年春天的一個週一清晨，Jeff 和 Sanjay 站在 40 號大樓（谷歌 AI 部門多數人的家）的簡易廚房裡。在他們背後，一塊白板上寫滿了矩陣代數的式子，一篇關於無監督對抗網路的論文躺在桌子上。Jeff 穿著一件褪色 T 恤和牛仔褲；Sanjay 穿著毛衣和灰色褲子。透過明亮的窗戶可以看到一片高大的松樹，還有一片田野。無論 Jeff 在谷歌何處工作，咖啡機都會隨之轉起來。在小廚房的櫃檯上，一個三英尺寬的 La Marzocco 咖啡機嗡嗡作響。「我們遲到了。」Sanjay 在咖啡機旁說道。現在是八點三十二分。
在喝完卡布奇諾之後，他們走到電腦前。Jeff 將一把椅子從自己凌亂的桌子前轉到 Sanjay 的桌子上，Sanjay 的桌子一塵不染。他把一隻腳放在檔案櫃上，向後靠，Sanjay 在他面前檢視螢幕。他開啟了四個視窗：左側是 Web 瀏覽器和終端，用於執行分析工具；右邊是文字編輯器 Emacs 中的兩個文件，一個是組合待辦事項列表和 notebook，另一個是色彩斑斕的程式碼。Sanjay 的 Mead 筆記本放在電腦旁邊。
「好了，我們在幹什麼？」Sanjay 問道。
「我想我們正在思考 TensorFlow Lite 的程式碼 size。」Jeff 說道。
TensorFlow Lite 是一個與機器學習相關的重要軟體專案，Jeff 和 Sanjay 擔心它會臃腫，他們像圖書編輯一樣尋找精簡程式碼的方法。為此，他們構建了一個本身需要優化的新工具。
「所以我正在嘗試弄清楚它到底有多慢。」Sanjay 說道。
「非常慢。」Jeff 說。他向前傾身，仍然很放鬆。
「所以這一塊程式碼有 120 KB，需要 8 秒的執行時間。」
「那是 120,000 個堆疊呼叫，不是 KB。」
「額，我是說有多少 KB 的文字。」
「哦，這樣，抱歉。」
「我不清楚我們應該採用多大的單元 size 閾值，0.5MB？」
「聽起來不錯，」Jeff 說道。Sanjay 開始寫程式碼，Jeff 盯著螢幕。「所以你是說，如果比這大，那我們就……」他只說了一半，Sanjay 用程式碼來回答他。
Sanjay 開車時把手放在十點鐘和兩點鐘方向，專注地看著前方。他在鍵盤上也是這樣。他的雙腳分開與肩同寬，看起來好像在練習坐姿。他的細長手指輕輕地滑過鍵盤。一些年輕的程式設計師開始加入進來。
不久，他們達到了一個小的里程碑，Sanjay 鍵入了一個命令來測試他們的進展。他在執行時檢查了一下 e-mail。看起來很疲憊。測試結束了，他沒有注意到。
「嘿，」Jeff 打了個響指，指著螢幕。雖然在談話中他經常講些冷笑話和雙關語，但當他和 Sanjay 一起坐在電腦前時，他會變得自以為是、唐突並提出反對意見。當 Sanjay 認為 Jeff 說的太快時，他會將手從鍵盤上抬起並伸出手指，好像在說「停」。（一般來說，Jeff 是油門，Sanjay 是剎車。）當他們爭論時也是如此。
Sanjay 滾動螢幕，展示了一段新的程式碼，「這些程式碼都可以寫成一個程式，不是嗎？」Jeff 說道。
「嗯。」Sanjay 表示同意。
Jeff 扳了一下他的指關節。「看起來可行，要寫嗎？」
Sanjay 謹慎地說道，「不，我……」
「所以我們要忽略眼前的問題？」Jeff 生氣地說道。
「不，我是說，我們正在思考眼前看到的是什麼型別的問題。我們可以記個筆記，不是嗎？」
「OK。」Jeff 開心地說，他的心情變化之快就像六月的天氣。他們一起記了筆記。
接近午餐時間。他們工作了兩個小時，休息了十分鐘，大部分時間都在說話。（如果有較年輕的程式設計師看著他們會留下深刻的印象，因為他們從未停止或被卡住。）讓你的程式碼由另一個程式設計師 review 是標準的工程實踐，但 Jeff 和 Sanjay 跳過了這一步，只在他們的日誌中寫下，一個敷衍的「lgtm」以及「我覺得還不錯。」從某種意義上來說，他們的工作充滿細枝末節。但是，他們的程式碼是以 Google 的規模執行的。他們擔心的千位元數和微秒數在世界各地的資料中心會急劇增加。這些喧鬧、悶熱、倉庫大小的建築物中的無數處理器由大量水冷卻。在這樣的日子裡，Jeff 回家告訴他的女兒們，「Sanjay 和我今天把谷歌的搜尋速度提高了百分之十。」
框架、規模和大資料
在 2003 年的四個月裡，Jeff 和 Sanjay 給谷歌進行了最大的一次升級。他們用一款名為 MapReduce 的軟體做到了這一點。在第三次重寫谷歌的抓取工具和索引器時，他們有了這個想法。他們解決了重要的問題：讓分佈在各地、彼此獨立的大量計算機協同工作。推廣他們的解決方案意味著可以避免一次又一次地重新解決這個問題。但它也會建立一個工具，谷歌的任何程式設計師都可以使用它來執行其資料中心的機器，就好像它們是一臺行星大小的計算機一樣。
Jeff 和 Sanjay 在一個高階辦公室裡寫下了 MapReduce，這個辦公室俯瞰著一個鴨子池塘，這一架構使得令人費解的程式變得井井有條。在 MapReduce 之前，每個程式設計師都必須弄清楚如何分割和分配資料、分配工作以及自己解決硬體故障。而 MapReduce 為程式設計人員提供了一種思考這些問題的結構化方法。就像一位廚師在掌勺之前做餐前準備，MapReduce 要求程式設計師將他們的任務分成兩個階段。首先，他們需要告訴每臺機器如何進行任務的「map」階段（比如，計算一個單詞出現在網頁上的次數）; 接下來，他們需要編寫「reduce」所有機器計算結果的指令（例如，把它們累加）。MapReduce 處理分配細節。
第二年，Jeff 和 Sanjay 依照 MapReduce 任務重寫了谷歌的爬蟲和索引系統。很快，當其他工程師意識到了這種方法的強大時，他們開始使用 MapReduce 來處理視訊以及在谷歌地圖上渲染圖塊。MapReduce 是如此的簡單，新任務也在不斷昭示著這一點。谷歌有所謂的「晝夜使用曲線」（即白天的流量比夜晚更大），MapReduce 任務開始佔用谷歌伺服器的閒置時間。生物大腦會在夢中處理白天的經歷。現在谷歌用同樣的方式處理自己的資料。
在早些時候就已經出現了一些跡象，暗示谷歌是一家假裝成搜尋公司的 AI 公司。2001 年，與 Jeff 和 Sanjay 同一辦公室的 Noam Shazeer 因為谷歌從其它公司獲得授權的拼寫檢查器而感到心力交瘁：它不斷犯一些讓人尷尬的錯誤，比如告訴輸入了「TurboTax」的使用者他們可能是想搜尋「turbot ax」（turbot/大菱鮃是生活在北大西洋的一種比目魚）。拼寫檢查器的表現取決於它的詞典，Shazeer 意識到了這一點，谷歌能在網路上獲取有史以來最大的詞典。他編寫了一個程式，可以利用網上文字的統計屬性來確定哪些詞有可能被錯誤拼寫。該軟體學習到「pritany spears」和「brinsley spears」都是想表示「Britney Spears（布蘭妮·斯皮爾斯）」。當 Shazeer 在谷歌每週的 T.G.I.F. 聚會（谷歌每週五下午固定的放鬆聚會）上展示這一程式時，谷歌的員工嘗試糊弄它，但大都失敗了。通過與 Jeff 以及另一位工程師 Georges Harik 合作，Shazeer 將類似的技術應用到了網路頁面的關聯廣告上。定向廣告成了一條淌著錢的河，谷歌將這條河導向了其計算基礎設施。這是反饋迴圈的開端——規模造就了谷歌的智慧，智慧帶來了谷歌的財富，財富推動谷歌壯大規模；這將使得該公司佔據極其強勢且令人不安的主導地位。
隨著富有進取精神的程式設計師使用 MapReduce 來發掘谷歌的資料中的洞察，轉錄使用者的語音郵件、回答他們的問題、自動完成他們的查詢以及翻譯上百種語言也隨之變得可能。這樣的系統都是用相對不那麼複雜的機器學習演算法開發的。不過 Jeff 說：「都是非常簡單的技術，當你有大量資料時，效果就會非常好。」隨著「資料、資料、資料」變成谷歌的最高指導原則（可使用 BigTable、MapReduce 及其後繼技術儲存和處理這些資料），該公司那全球擴張的基礎設施也變得更加無縫和靈活。分散式計算是一個古老的思想，「雲端計算」和「大資料」等概念在谷歌崛起前就已出現。但是，Jeff 和 Sanjay 使這些技術可被智慧地管理，讓普通程式設計師也能編寫分散式程式，進而讓谷歌在這些技術方面又佔據了進一步的主導地位。使用者可能已經注意到某些東西已然改變：谷歌的雲正越來越聰明。
2004 年，因為 Jeff 和 Sanjay 認為這些技術對天文學家、遺傳學家和其他有大量資料需要處理的科學家很有用，所以他們寫了一篇論文《MapReduce: Simplified Data Processing on Large Clusters》，並將其公開。這篇 MapReduce 論文真乃一場及時雨。廉價硬體以及網路服務和互連裝置的增長帶來了巨量資料，但只有很少的公司擁有處理這些資訊的軟體。Mike Cafarella 和 Doug Cutting 這兩位工程師堅信 MapReduce 的重要性，以至於他們決定從頭開始建立一個該系統的免費克隆版本——在此之前，他們一直在艱難地擴充套件一個小型搜尋引擎 Nutch。他們最終將自己的專案命名為 Hadoop，得名於 Cutting 的兒子喜歡的一個毛絨小象玩具。Hadoop 日趨成熟，已經得到了半數「財富 50 強（Fortune 50）」公司的採用。Hadoop 幾乎已成為「大資料」的同義詞。眾所周知，Facebook 使用了 Hadoop MapReduce 來儲存和處理使用者後設資料——關於使用者點選、喜歡、廣告檢視等行為的資訊。Facebook 曾有一段時間擁有世界上最大的 Hadoop 叢集。Hadoop MapReduce 還幫助驅動了 LinkedIn 和 Netflix。前美國國家安全域性（NSA）技術主管 Randy Garrett 記得曾向 NSA 局長 Keith Alexander 上將演示過這項技術。Hadoop 執行分析任務的速度是之前系統的 18000 倍。它成了一種新的情報收集方法的基礎，某些觀察家稱之為「collect it all」。
AI 和程式設計師
Jeff 的本性是不安現狀的：一旦他看到了問題解決方案的輪廓，這個問題就不再那麼有趣了。2011 年，在全世界都擁抱雲的時候，他開始與來自史丹佛大學的電腦科學教授吳恩達合作；吳恩達教授當時在谷歌領導著一個研究神經網路（由虛擬「神經元」構成的計算機程式）的祕密專案。Jeff 曾在本科階段接觸過神經網路；那時候，它們還不能解決真實世界的問題。吳恩達告訴 Jeff 情況正在發生改變。在史丹佛，當研究者為神經網路提供大量資料時，他們取得了一些激動人心的結果。吳恩達認為，有谷歌這樣的規模，神經網路不僅僅會變得有用，而且會變得非常強大。
神經網路與傳統的計算機程式截然不同。和通常的做法不同，神經網路的行為不是由程式設計師指定的，而是使用輸入和反饋「學習」到的。Jeff 對神經網路的瞭解自本科階段以來一直沒什麼進展，於是 Heidi 看到他們家的衛生間擺滿了教材。Jeff 開始每週投入一天時間到這個被稱為「Google Brain（谷歌大腦）」的專案上。谷歌內部有很多人對這項技術持懷疑態度。他當時的經理 Alan Eustace 回憶道：「簡直浪費人才。」Sanjay 也不能理解 Jeff 的舉動。「你的工作是基礎設施，」他認為，「你在那裡做些什麼？」
接下來的七年時間裡，谷歌大腦團隊開發的神經網路在機器翻譯以及語音和影象識別方面超越了之前最佳的方法。最終，它們替代了谷歌最重要的用於搜尋結果排序和定向廣告的演算法，谷歌大腦也變成該公司增長速度最快的團隊之一。2001 年加入谷歌的工程師 Claire Cui 說 Jeff 的參與標誌著谷歌內部 AI 發展的一個轉折點：「有人相信它，也有人不相信。Jeff 證明了它是有效的。」
事實證明，AI 依賴於規模，而系統工程師 Jeff 提供了規模。他的一項努力是領導了 TensorFlow 專案的開發——目標是為 AI 創造出類似 MapReduce 的東西。TensorFlow 簡化了將神經網路分配到多臺計算機的任務，從而可將它們變成一個巨大的腦。2015 年，TensorFlow 公開發布，變成了 AI 的通用語言。谷歌 CEO Sundar Pichai 近期還宣佈谷歌是一家「AI 優先」公司，並讓 Jeff 領導該公司的 AI 計劃。
Jeff 現在每週花四天時間管理谷歌大腦。他指導著三千人的工作。他到處旅行發表演講，每週召開一次有關一款新計算機晶片（張量處理單元/TPU，專為神經網路設計）的例會，並且還會幫助開發 AutoML，這是一個使用神經網路來設計其它神經網路的系統。他每週只有一次能與 Sanjay 一起寫程式碼。
Jeff 和 Sanjay
現在，他們兩人的角色已經大不相同。在谷歌，Sanjay 被看作是「個人貢獻者」——獨自幹活的程式設計師，不管理任何人。對此，他很感激。他說：「我可不想要 Jeff 的工作。」他目前正在開發能讓工程師能更輕鬆地組合和控制數十個程式（用於獲取新聞、照片、價格）的軟體，會在使用者開始在谷歌搜尋框輸入文字時開始執行。他每週會與一群「區域技術主管（Area Tech Leads）」開一次會，這算得上是谷歌工程開發方面的最高委員會；他們會一起制定會影響整個公司的技術決策。如果把谷歌比作一座房子，Jeff 正在建新房間，而 Sanjay 則在支撐結構、加固橫樑、鉚緊螺栓。
同時，在 Jeff 和 Sanjay 週一的共同程式設計時間，他們啟動了一個新東西。這是一個 AI 專案。Jeff 說這是一個嘗試，要訓練一個「巨型」機器學習模型來做數千或數百萬個不同的任務。Jeff 多年來一直在思考這一思路，最近他認為這是可能的。他和 Sanjay 計劃構建一個原型，然後讓一個團隊圍繞其開發。在軟體的世界裡，最好的領導方法就是用程式碼。
Jeff 的妻子 Heidi 說：「我認為他們想念彼此。」在他們合作放緩的時候，他們開始一起在週五吃晚餐。
三月的一個週日，Jeff 和 Sanjay 一起去庫比蒂諾城外遠足。天氣清爽、乾冷，但在太陽底下還是有些熱。Jeff 開著一輛藍色的特斯拉 Roadster 抵達山口，車的保險槓上貼著 Bernie 2016 貼紙。Sanjay 開著自己的紅色特斯拉 Model S 緊隨其後。Sanjay 整個早上都在讀書。Jeff 則選擇踢足球（綁在小腿上的裝置提醒他已經跑了 7.1 英里）。在創造「March index」20 年後，Jeff 像一名退休的耐力運動員，他的皮膚受到太陽灼曬。但 Sanjay 看起來卻年輕得多。
旅程全長 6 英里，途中穿過了茂密的樹林。Jeff 在前面領路。他們在樹林裡追憶谷歌的發展之快。Sanjay 想起在谷歌的第一個快速發展時期，一名管道工一次性為男廁所安裝了兩個廁位。「我記得當時 Jeff 評論道，」他說，「三個臭皮匠賽過諸葛亮！（Two heads are better than one!）」說完他笑了起來。
他們走出叢林，走進一片乾燥裸露的區域。一隻土耳其禿鷹從頭頂飛過。
「這山比我想象中的要陡。」Jeff 說道。
「我記得有人說這是一次非常平坦的遠足。」Sanjay 說。
「我猜這就是那一側沒有自行車道的原因。」Jeff 說道。
他們又走進了一片叢林。在一個之字形的爬坡路段，Jeff 瞥了一眼樹後。「我們可以在某個點好好眺望一下。」他說道。
他們腳下的小徑通往山頂，那裡高聳、寬闊，沒有樹木，可以領略全景。視野中有淡淡的薄霧。
他們依然可以看見南邊的聖克魯斯山和東邊的使命峰（Mission Peak）。「Sanjay，那是你的辦公室！」Jeff 說道。他們並肩而立，視線穿越山谷。
原文連結：https://www.newyorker.com/magazine/2018/12/10/the-friendship-that-made-google-huge/amp?__twitter_impression=true