在谷歌和推特兩家公司工作情況比較 - ma.nu

核心子域與外包
Twitter外包的東西比Google要多得多。
谷歌喜歡用他們自己的解決方案來處理幾乎所有的事情。他們甚至曾經有自己的人力資源系統（名字叫GHR），直到他們轉而使用Workday。谷歌有他們自己的錯誤跟蹤系統、電子郵件、日曆、線上辦公套件、程式碼審查系統、內部溝通和社會互動工具，你可以說出這些。
Twitter使用谷歌日曆、電子郵件、辦公套件、Jira（錯誤跟蹤器、專案管理）、Okta（單點登入）、Phabricator（程式碼審查）、Sentry（錯誤監控）、WorkDay（人力資源、目標設定、同行評審）、Splunk、Office Timeline、Duo（身份驗證--當我第一次加入並被告知要在手機上安裝Duo時，我感到有些困惑，因為我以為那是指谷歌的影片聊天應用程式）。
這也適用於更多的技術性東西和使用開放技術。
一方面，這使得Twitter不像谷歌那樣是一個 "技術孤島"；另一方面，在Twitter上驗證上千種服務可能有點不方便（單點登入工具使其大部分不費力，但並非總是如此）。

程式碼的 所有權
程式碼的 "所有權 "是一種常見的模式，以防止不良修改。
如要進行任何修改，你需要成為你要修改的那段程式碼（或超集）的所有者，或者得到所有者的批准。
我在谷歌看到的大多數專案中，所有權的 "顆粒度 "水平要低得多，這意味著一個軟體的各個部分和子部分可以由不同的人擁有。一般的經驗法則是，你在一個專案上的時間越長，你在所有權樹上 "冒泡 "的次數就越多，可以改變或批准對更大塊內容的修改。
到目前為止，Twitter有更多的 "全部或沒有 "的方法。一旦你成為網路應用程式程式碼（分別是iOS客戶端、Android客戶端等）的所有者，你可以對任何部分進行修改（有幾個例外）。

程式碼評審
Twitter的程式碼審查過程既快，又需要更多的努力。
谷歌的內部程式碼審查工具為你提供了一個簡單而自動化的方法，為一個給定的修改新增一組建議的審查者。它考慮到了程式碼所有權、時區、不在辦公室的人等等。因此，你一般只需按下一個按鈕，就可以認為你的修改會在一個合理的時間框架內得到審查。
在Twitter，"程式碼所有權 "的限制將被強制執行，但由你來指定審查員（作為小組或個人）。一旦你這樣做了，你需要明確地要求審查，可以在Slack頻道上，也可以給指定的人（我做了一個簡單的瀏覽器擴充套件，讓它更容易一些）。反過來說，你通常可以更快地得到評審。

文件
我沒有客觀的資料來證明這一點，但我覺得Twitter的工程師們在給他們的程式碼新增註釋和文件方面不太勤奮。
我想說的是，谷歌的大多數團隊在這方面遠遠不夠好，但witter的情況更糟糕。
例如，一個好的做法是為每個頂層的 "類"（假設是物件導向的程式設計模型）提供一個簡短的描述，說明它的作用。

駭客周
谷歌有其著名的 "20%專案 "政策已經有很長一段時間了；它現在已經奄奄一息了。我很喜歡Twitter的 "駭客周"，因為它清楚地表明，人們不需要在那一週裡在他們的主要專案上取得進展。不過，這顯然不完全是20%。我想知道每個季度的 "駭客周 "會產生什麼。

溝通
Twitter 上的一切都發生在 Slack 上。一對一聊天、不需要開會的團隊討論、全體會議上向領導提出的問題、程式碼審查請求、社交閒聊等。我什至不費心去參加的情況並不少見幾天檢查我的工作電子郵件；
這在大多數事情都是透過電子郵件完成的谷歌是永遠不會發生的（有些人也使用即時訊息，但這些討論不會被假定為將來存檔/保留）。
在 Twitter，與其他內部屬性相比，您更有可能透過搜尋 Slack 找到與您的問題相關的資訊。
不利的一面是，如果 Slack 在任何重要的時間段內停機，那將是生產力/知識的重大損失。