Google-Mitarbeiter Nr. 59

Problem hat, wenn eine Warnung erfolgt. Du kannst es nicht einfach ignorieren«, erzählte er mir. Er formalisierte die wichtigsten Elemente in einer Gestaltungsrichtlinie, die zu einem von Craig Silverstein durchgesetzten Auftrag wurde.
    »Ich hatte kein Verlangen nach einer Gestaltungsrichtlinie«, verriet mir Craig, »aber Urs ließ nicht locker.«
    Die größte Frage war, welche Programmiersprache benutzt werden sollte. Craig wollte C. Urs bevorzugte C++. Urs setzte sich durch, aber er stimmte zu, dass Google-Programmierer nicht »die schlechten Teile von C++ nutzten«.
    »Was sind die schlechten Teile von C++?«, fragte ich Craig einmal.
    »Das meiste davon«, antwortete er, ohne eine Miene zu verziehen.
    Craig war davon überzeugt, dass Google eine integrierende Kraft brauche, um unnötige oder gegenläufige Bemühungen zu verhindern, den Standard zu halten, dabei zu helfen, Prioritäten zu setzen, und bei Leistungskontrollen ein Feedback zu geben. Er machte es sich zum Ziel, diese Kraft zu sein, »derjenige zu sein, der über alles Bescheid wusste«.
    »Bis wir so etwa hundert Leute waren«, erinnert er sich, »bin ich herumgegangen und habe mit jedem gesprochen. ›Wie läuft’s bei dir? Brauchst du Hilfe?‹, habe ich zum Beispiel gefragt. Einige Leute haben sich darüber aufgeregt. ›Der Typ geht mir auf die Nerven. Was will er?‹ Urs musste mich zur Seite nehmen und mir sagen, ich solle damit aufhören.«
    Craig erkannte, dass »die Leute niemanden brauchten, der ihnen ständig über die Schulter schaute. Alle waren nur einen Schritt weit auseinander. Sie wussten, an wen sie sich bei Bedarf wenden konnten. Es herrschte eine gute Kommunikation.«
    Die einzige Sache, die hoher Aufmerksamkeit bedurfte, war das Programm selbst. Um potenzielle Probleme aufzuspüren, untersuchte Craig jeden Alarm, der ausgelöst wurde, wann immer jemand eine Codebasis-Änderung durchführte – wie geringfügig diese auch war. Ein Korrektor allein konnte jedoch mit dem Wachstum des technischen Wachstums nicht Schritt halten. Deshalb richtete Urs einen formalen Softwaretest ein.
    »Du musst dir eine gute Entwicklungstechnik aussuchen, die dein kultureller Maßstab wird«, sagte Craig, »und für uns war das der Softwaretest des Programms.« Um eine Prüfung anzustoßen, musste ein Programmierer ein Signal an ein Online-Design-Dokument senden. Jeder konnte dazu antworten und Kommentare abgeben, aber ein offizieller Tester musste das jeweilige Programm freigeben.
    Der Nutzen lag auf der Hand. »Probleme im Anfangsstadium aufzuspüren«, erklärte Techniker Ron Dolin, »war hundert Mal effizienter, als sie erst später zu entdecken.«
    Während Google wuchs, verschrieben sich jedoch nicht alle Programmierer der Idee, dass ihr Programm eine Überprüfung brauche oder dass es in ihrer Verantwortung lag, die Arbeit der anderen durchzusehen. Craig erklärte das so: »Wir haben einen Prozess eingeführt, um das Abschicken ungeprüfter Programme zu verhindern – es sei denn, du lügst.«
    Um diesen Prozess zu umgehen, würden die Leute flüchtige Prüfungen durchführen. »Ich schickte ein riesiges Programm herum«, sagte Craig. »Und zurück bekam ich ›Sieht gut aus‹. Ich nehme doch an, dass es mehr über dieses Programm zu sagen gab.« Wenn neue Mitarbeiter anfingen, überprüfte Craig deren Programme persönlich und schärfte ihnen das System der kollaborativen Autorenschaft ein. Manche Leute mochten das nicht. »Paul Bucheit hasste es«, erinnert sich Craig. »Noam 31 hasste es. Aber am Ende führte Paul viele Programmüberprüfungen selbst durch und wurde ein großer Befürworter dieser Methode. Noam hielt es für Zeitverschwendung – wie Larry und Sergey ist er ein Research Developer. Er würde sagen: ›Es kostet mich mehr Zeit, dieses Programm zu überprüfen, als es zu schreiben – wie soll das eine sinnvolle zeitliche Investition sein?‹«
    Sanjay Ghemawat hasste Programmüberprüfungen nicht. Obwohl er aus einem Forschungslabor kam, in dem es als aufdringlich – wenn nicht gar unpassend – galt, anderen über die Schulter zu schauen, erkannte er sofort den Wert des Inputs durch einen intelligenten Prüfer. Die Programmüberprüfungen forcierten eine Fremdbestäubung von Ideen, während sie den Standard hoben, was akzeptabel war.
    »In dem einen Extrem«, so Sanjay, »konntest du sagen: ›Stell einfach sicher, dass es den Stilrichtlinien folgt‹, was eine ziemlich mechanische Vorgehensweise war. Meine