Debugging-Teams

Einführung

Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: [e-mail]

Technik ist einfach. Menschen sind schwer.

Bill Coughran,
ehemaliger Senior Vice President of Engineering bei Google

Das Leben ist voller unerwarteter Wendungen, und wir beide hätten nie gedacht, dass wir eines Tages ein Buch über Teamwork und Zusammenarbeit schreiben würden.

Wie so viele moderne "Maker" entdeckten wir, dass unser Hobby und unsere Leidenschaft - das Spielen mit Computern - eine gute Möglichkeit war, nach dem College-Abschluss unseren Lebensunterhalt zu verdienen. Und wie die meisten Hacker unserer Generation verbrachten wir die Mitte der 1990er Jahre damit, PCs aus Ersatzteilen zu bauen, Vorabversionen von Linux aus Stapeln von Disketten zu installieren und zu lernen, Unix-Rechner zu verwalten. Zu Beginn der Dot-Com-Blase wurden wir Programmierer und nach dem Platzen der Blase begannen wir, für überlebende Unternehmen aus dem Silicon Valley wie Apple zu arbeiten. Später wurden wir von einem Startup-Unternehmen eingestellt, um Vollzeit an der Entwicklung eines Open-Source-Systems zur Versionskontrolle namens Subversion zu arbeiten.

Doch zwischen 2000 und 2005 geschah etwas Unerwartetes. Während wir Subversion entwickelten, änderten sich langsam unsere Aufgaben. Wir schrieben nicht mehr den ganzen Tag im luftleeren Raum Code, sondern wir leiteten ein Open-Source-Projekt. Das bedeutete, den ganzen Tag mit einem Dutzend anderer freiwilliger Programmierer in einem Chatroom zu sitzen und darauf zu achten, was sie taten. Das bedeutete, neue Funktionen fast ausschließlich über eine E-Mail-Liste zu koordinieren. Dabei entdeckten wir, dass der Schlüssel zum Erfolg eines Projekts nicht nur darin lag, guten Code zu schreiben, sondern dass die Art und Weise, wie die Menschen auf das Ziel hin zusammenarbeiteten, genauso wichtig war.

Im Jahr 2005 gründeten wir Googles Ingenieurbüro in Chicago und setzten unsere Karrieren als Programmierer fort. Zu diesem Zeitpunkt waren wir bereits stark in die Open-Source-Welt involviert - nicht nur in Subversion, sondern auch in die Apache Software Foundation (ASF). Wir portierten Subversion auf Googles BigTable Infrastruktur und starteten einen Open-Source-Projekthosting-Service (ähnlich wie SourceForge) unter dem Namen Google Code. Wir begannen, an Konferenzen für Entwickler wie der OSCON, der ApacheCon, der PyCon und schließlich der Google I/O teilzunehmen und dort auch zu sprechen. Wir entdeckten, dass wir durch unsere Arbeit sowohl in Unternehmen als auch in Open-Source-Projekten eine Fülle von Weisheiten und Anekdoten über die Arbeitsweise von Teams in der Softwareentwicklung gesammelt hatten. Was als eine Reihe von humorvollen Vorträgen über dysfunktionale Entwicklungsprozesse ("Subversion Worst Practices") begann, entwickelte sich schließlich zu Vorträgen über den Schutz von Teams vor Idioten ("How Open Source Projects Survive Poisonous People"). Bei unseren Vorträgen versammelten sich immer größere Menschenmengen zu einer Art "Gruppentherapie" für Softwareentwickler.

Nachdem wir einen Vortrag nach dem anderen über die sozialen Herausforderungen der kreativen Zusammenarbeit gehalten hatten, ermutigte uns unser Redakteur bei O'Reilly Media, die Vorträge in ein Buch zu verwandeln. Der Rest ist Geschichte.

Für wen ist dieses Buch?

Dieses Buch wurde ursprünglich für Softwareentwickler geschrieben - für diejenigen, die ihre Karriere vorantreiben und großartige Software entwickeln wollen. Als wir das Buch für die zweite Auflage aktualisierten, wurde uns jedoch klar, dass die Themen in diesem Buch für eine viel breitere Gruppe gelten. Wenn du inirgendeiner Form mit anderen Menschen an kreativen Projekten arbeitest, gelten die Lektionen in diesem Buch auch für dich. Du könntest Teil eines Nachbarschaftsclubs, einer Kirchengruppe, einer Studentenverbindung, eines Ausschusses oder einer Architektengruppe sein. Wir gehen von zwei wichtigen Dingen über dich als Leser aus:

• Du arbeitest in einem Team mit anderen kreativen Menschen, wahrscheinlich in einem Unternehmen oder einer anderen strukturierten Umgebung.

• Du hast Spaß daran, Dinge zu bauen und glaubst, dass dies eine lohnende Tätigkeit sein sollte, die Spaß macht. Wenn du Produkte nur herstellst, um deine Rechnungen zu bezahlen, geht es dir wahrscheinlich nicht um Selbstverwirklichung oder berufliche Erfüllung.

Unsere eigenen Erfahrungen stammen aus der Softwareentwicklung, daher sind die meisten Beispiele in diesem Buch in diesem Bereich angesiedelt. Aber fast alle Prozesse und Strategien, die wir beschreiben, sind direkt anwendbar (oder haben eine direkte Entsprechung) für jedes Team von Kreativen.

Bei der Diskussion darüber, wie Ingenieure am besten "gut mit anderen zusammenarbeiten", kommen wir auf eine Reihe von Themen zu sprechen, die (oberflächlich betrachtet) nicht in die Aufgabenbeschreibung eines Programmierers passen. An verschiedenen Stellen sprechen wir darüber, wie man ein Team effektiv leitet, sich in einer Organisation zurechtfindet und eine gesunde Beziehung zu den Nutzern deiner Software aufbaut. Auf den ersten Blick scheinen sich diese Kapitel speziell an "People Manager" oder "Produktmanager" zu richten - aber wir versichern dir, dass du irgendwann in deiner Karriere versehentlich auch diese Hüte tragen wirst. Mach dir keine Illusionen und lies weiter! Alles in diesem Buch ist letztlich für jeden relevant, der Dinge entwickelt.

Warnung: Dies ist kein technisches Handbuch

Bevor wir beginnen, müssen wir deine Erwartungen festlegen. Motivierte Programmierer lesen gerne Bücher, in denen domänenspezifische Probleme in einer perfekten mathematischen Darstellung dargelegt werden; jedes Problem ist in der Regel mit einer vorgeschriebenen prozeduralen Lösung verbunden.

Dies ist kein solches Buch.

In unserem Buch geht es speziell um die menschliche Seite der kreativen Produktentwicklung, und Menschen sind komplexe Wesen. Wie wir in unseren Gesprächen gerne sagen: "Menschen sind im Grunde ein riesiger Haufen intermittierender Bugs." Sowohl die Probleme als auch die Lösungen, die wir besprechen, sind chaotisch und lassen sich nur schwer in perfekte logische Schubladen stecken. Dieses Buch liest sich wie eine Reihe von Aufsätzen, denn genau das ist es im Wesentlichen auch. In jedem Kapitel besprechen wir eine Reihe verwandter Probleme (oft in Form von Anekdoten) und anschließend eine Gruppe von Lösungen, die für das Gesamtthema relevant sind. Um alles vollständig aufzunehmen, musst du deine Aufmerksamkeitsspanne verlängern, um mehrere Seiten zu lesen, deine rechte Gehirnhälfte einschalten, um Verbindungen herzustellen, oder einfach nur darüber schlafen!

Wir sollten auch noch ein paar Haftungsausschlüsse machen. Wie wir in unseren Vorträgen gerne scherzen: "Diese Meinungen sind ausschließlich unsere eigenen und basieren auf unseren Erfahrungen. Wenn du anderer Meinung bist, kannst du dir gerne einen eigenen Vortrag suchen." Genau wie bei unseren Vorträgen sind wir für jede Diskussion, die sich aus den Themen in diesem Buch ergibt, dankbar. Wir freuen uns über Feedback, Korrekturen, neue Meinungen und Meinungsverschiedenheiten: Du findest uns unter http://www.debuggingteams.com/. Alles in diesem Buch stammt aus unseren eigenen Feuerproben und den Lehren, die wir aus unseren zahlreichen Fehlern gezogen haben.

Du solltest auch wissen, dass alle Namen in unseren Beispielen geändert wurden, um die Unschuldigen (oder Schuldigen) zu schützen.

Der Inhalt dieses Buches wird nicht in der Schule gelehrt

Die meisten Softwareentwickler/innen, die wir kennen, haben zwischen 4 und 10 Jahren in der Schule Informatik und Softwareentwicklung gelernt. Und doch gibt es kaum Lehrpläne¹ in denen man lernt, wie man in einem Team oder in einem Unternehmen kommuniziert und zusammenarbeitet. Sicher, die meisten Schüler/innen müssen irgendwann in ihrer akademischen Laufbahn an einem Gruppenprojekt teilnehmen, aber es ist ein großer Unterschied, ob man jemandem beibringt, wie man erfolgreich mit anderen Menschen zusammenarbeitet, oder ob man ihn in eine Situation der erzwungenen Zusammenarbeit wirft. Die meisten Schüler/innen sind am Ende von dieser Erfahrung abgestumpft.

Das Spielfeld

Um ein erfolgreicher Programmierer zu sein, geht es nicht nur darum, die neuesten Sprachen zu lernen oder den schnellsten Code zu schreiben. Professionelle Programmiererinnen und Programmierer arbeiten fast immer in Teams und es stellt sich heraus, dass das Team einen direktenEinfluss auf die Produktivität und das Glück des Einzelnen hat, mehr als viele Menschen zugeben möchten.

Die Grundidee dieses Buches ist einfach: Software zu schreiben ist ein Mannschaftssport, und wir gehen davon aus, dass die menschlichen Faktoren genauso viel Einfluss auf das Ergebnis haben wie die technischen. Selbst wenn sie Jahrzehnte damit verbracht haben, die technische Seite des Programmierens zu lernen, haben sich die meisten Menschen nicht wirklich auf die menschliche Komponente konzentriert. Zu lernen, wie man zusammenarbeitet, ist genauso wichtig für den Erfolg. Wenn du in die "Soft Skills" der Technik investierst, kannst du mit dem gleichen Aufwand viel mehr erreichen.

¹ Wir haben PeopleWare von Tom DeMarco gelesen, und es ist ein großartiges Buch, aber es ist weniger ein Buch für einzelne Mitarbeiter, die lernen wollen, wie sie effizienter mit Menschen zusammenarbeiten können, als vielmehr ein Buch für Manager, die lernen wollen, wie sie Teams erfolgreicher machen können.