Clean Coder

Name: Clean Coder | Verhaltensregeln für professionelle Programmierer
Brand: MITP
Price: 34.99 EUR
Availability: OnlineOnly

Verhaltensregeln für professionelle Programmierer

Robert C. Martin(Autor*in)

MITP (Verlag)

1. Auflage

Erschienen am 24. März 2014

216 Seiten

E-Book

ePUB ohne DRM

Systemvoraussetzungen

E-Book

PDF ohne DRM

Systemvoraussetzungen

978-3-8266-3208-2 (ISBN)

34,99 €inkl. 7% MwSt.

Systemvoraussetzungen

für ePUB ohne DRM und PDF ohne DRM

(Hinweis: Die Auswahl des von Ihnen gewünschten Dateiformats und des Kopierschutzes erfolgt erst im System des E-Book Anbieters)

E-Book Einzellizenz

Als Download verfügbar

Beschreibung

Erfolgreiche Programmierer haben eines gemeinsam: Die Praxis der Software-Entwicklung ist ihnen eine Herzensangelegenheit. Auch wenn sie unter einem nicht nachlassenden Druck arbeiten, setzen sie sich engagiert ein. Software-Entwicklung ist für sie eine Handwerkskunst.
In Clean Coder stellt der legendäre Software-Experte Robert C. Martin die Disziplinen, Techniken, Tools und Methoden vor, die Programmierer zu Profis machen.
Dieses Buch steckt voller praktischer Ratschläge und behandelt alle wichtigen Themen vom professionellen Verhalten und Zeitmanagement über die Aufwandsschätzung bis zum Refactoring und Testen. Hier geht es um mehr als nur um Technik: Es geht um die innere Haltung. Martin zeigt, wie Sie sich als Software-Entwickler professionell verhalten, gut und sauber arbeiten und verlässlich kommunizieren und planen. Er beschreibt, wie Sie sich schwierigen Entscheidungen stellen und zeigt, dass das eigene Wissen zu verantwortungsvollem Handeln verpflichtet.

Großartige Software ist etwas Bewundernswertes: Sie ist leistungsfähig, elegant, funktional und erfreut bei der Arbeit sowohl den Entwickler als auch den Anwender. Hervorragende Software wird nicht von Maschinen geschrieben, sondern von Profis, die sich dieser Handwerkskunst unerschütterlich verschrieben haben. Clean Coder hilft Ihnen, zu diesem Kreis zu gehören.
Robert C. "Uncle Bob" Martin ist seit 1970 Programmierer und bei Konferenzen in aller Welt ein begehrter Redner. Zu seinen Büchern gehören Clean Code - Refactoring, Patterns, Testen und Techniken für sauberen Code und Agile Software Development: Principles, Patterns, and Practices. Als überaus produktiver Autor hat "Uncle Bob" Hunderte von Artikeln, Abhandlungen und Blogbeiträgen verfasst. Er war Chefredakteur bei The C++ Report und der erste Vorsitzende der Agile Alliance. Martin gründete und leitet die Firma Object Mentor, Inc., die sich darauf spezialisiert hat, Unternehmen bei der Vollendung ihrer Projekte behilflich zu sein.

In diesem Buch lernen Sie:
Was es bedeutet, sich als echter Profi zu verhalten
Wie Sie mit Konflikten, knappen Zeitplänen und unvernünftigen Managern umgehen
Wie Sie beim Programmieren im Fluss bleiben und Schreibblockaden überwinden
Wie Sie mit unerbittlichem Druck umgehen und Burnout vermeiden
Wie Sie Ihr Zeitmanagement optimieren
Wie Sie für Umgebungen sorgen, in denen Programmierer und Teams wachsen und sich wohlfühlen
Wann Sie "Nein" sagen sollten - und wie Sie das anstellen
Wann Sie "Ja" sagen sollten - und was ein Ja wirklich bedeutet

Aus dem Inhalt:

Verantwortung übernehmen
Feindliche Rollen
Ein Teamplayer sein
Verbindliche Sprache
Der Flow-Zustand
Schreibblockaden
Test Driven Development
Das Coding Dojo
Akzeptanztests
Teststrategien
Zeitmanagement
Aufwandsschätzungen
Umgang mit Druck
Mentoring, Lehrzeiten und die Handwerkskunst
Werkzeuge und Hilfsmittel

Rezensionen / Stimmen

»Das Buch Clean Coder gibt tolle Einblicke in die tägliche Arbeit eines Entwicklers. Es beschreibt die typischen Probleme in Softwareprojekten und zeigt Lösungswege dafür auf. Sie sollten also nicht nur wissen, wie man sauberen Code erstellt, sondern auch, wie Sie selbst zu einem sauber arbeitenden Entwickler werden.« (Raspberry Pi Geek Magazin, 07/2022)

»Der große Verdienst des Buches ist meines Erachtens, dass es den Job eines Entwicklers in seiner gesamten Komplexität zeigt. (.) Für angehende oder noch am Anfang stehende Entwickler ist die Lektüre von Clean Coder durchaus empfehlenswert, da es gut zeigt, was alles neben Technik notwendig ist, um ein Profi zu werden.« (nososo.de, 11/2020)

»Die Tipps zum Verhalten, besonders gegenüber Mitarbeitern und der Führungsetage, finde ich sehr gut gelungen und man merkt, dass der Autor hier aus einem großen Pool von Erfahrung schöpfen kann.« (Daniel Bocksteger.com, 03/2015)

Weitere Details

Weitere Ausgaben

Person

Inhalt

1 - Cover [Seite 1]
2 - Titel [Seite 5]
3 - Impressum [Seite 6]
4 - Inhaltsverzeichnis [Seite 9]
5 - Vorwort [Seite 15]
6 - Einführung [Seite 21]
7 - Danksagungen [Seite 25]
8 - Über den Autor [Seite 29]
9 - Auf dem Titelbild [Seite 31]
10 - Kapitel 1: Professionalität [Seite 39]
10.1 - 1.1 Seien Sie vorsichtig, wonach Ihnen verlangt [Seite 39]
10.2 - 1.2 Verantwortung übernehmen [Seite 40]
10.3 - 1.3 Erstens: Richte keinen Schaden an [Seite 42]
10.3.1 - 1.3.1 Beschädige nicht die Funktion [Seite 42]
10.3.2 - 1.3.2 Beschädige nicht die Struktur [Seite 45]
10.4 - 1.4 Arbeitsethik [Seite 47]
10.4.1 - 1.4.1 Sie sollten sich in Ihrem Bereich auskennen [Seite 48]
10.4.2 - 1.4.2 Lebenslanges Lernen [Seite 49]
10.4.3 - 1.4.3 Praxis [Seite 50]
10.4.4 - 1.4.4 Teamwork [Seite 51]
10.4.5 - 1.4.5 Mentorenarbeit [Seite 51]
10.4.6 - 1.4.6 Sie sollten sich in Ihrem Arbeitsgebiet auskennen [Seite 51]
10.4.7 - 1.4.7 Identifizieren Sie sich mit Ihrem Arbeitgeber bzw. Kunden [Seite 52]
10.4.8 - 1.4.8 Bescheidenheit [Seite 52]
10.5 - 1.5 Bibliografie [Seite 52]
11 - Kapitel 2: Nein sagen [Seite 53]
11.1 - 2.1 Feindliche Rollen [Seite 55]
11.1.1 - 2.1.1 Was ist mit dem Warum? [Seite 58]
11.2 - 2.2 Hoher Einsatz [Seite 58]
11.3 - 2.3 Ein »Teamplayer« sein [Seite 60]
11.3.1 - 2.3.1 Versuchen [Seite 62]
11.3.2 - 2.3.2 Passive Aggression [Seite 64]
11.4 - 2.4 Die Kosten eines Ja [Seite 65]
11.5 - 2.5 Code unmöglich [Seite 72]
12 - Kapitel 3: Ja sagen [Seite 75]
12.1 - 3.1 Verbindliche Sprache [Seite 76]
12.1.1 - 3.1.1 So erkennt man mangelnde Selbstverpflichtung [Seite 77]
12.1.2 - 3.1.2 Wie echte Selbstverpflichtung klingt [Seite 78]
12.1.3 - 3.1.3 Zusammenfassung [Seite 80]
12.2 - 3.2 Lernen, wie man »Ja« sagt [Seite 81]
12.2.1 - 3.2.1 Die Kehrseite von »Ich versuch's mal« [Seite 81]
12.2.2 - 3.2.2 Der Disziplin verpflichtet [Seite 82]
12.3 - 3.3 Schlussfolgerung [Seite 84]
13 - Kapitel 4: Programmieren [Seite 85]
13.1 - 4.1 Bereit sein [Seite 86]
13.1.1 - 4.1.1 Code um drei Uhr früh [Seite 87]
13.1.2 - 4.1.2 Sorgencode [Seite 88]
13.2 - 4.2 Der Flow-Zustand [Seite 89]
13.2.1 - 4.2.1 Musik [Seite 90]
13.2.2 - 4.2.2 Unterbrechungen [Seite 91]
13.3 - 4.3 Schreibblockaden [Seite 92]
13.3.1 - 4.3.1 Kreativer Input [Seite 92]
13.4 - 4.4 Debugging [Seite 93]
13.4.1 - 4.4.1 Zeit zum Debuggen [Seite 96]
13.5 - 4.5 Die eigene Energie einteilen [Seite 96]
13.5.1 - 4.5.1 Wann man den Stift weglegen muss [Seite 97]
13.5.2 - 4.5.2 Die Heimfahrt [Seite 97]
13.5.3 - 4.5.3 Die Dusche [Seite 97]
13.6 - 4.6 In Verzug sein [Seite 98]
13.6.1 - 4.6.1 Hoffnung [Seite 98]
13.6.2 - 4.6.2 Sich beeilen [Seite 98]
13.6.3 - 4.6.3 Überstunden [Seite 99]
13.6.4 - 4.6.4 Unlautere Ablieferung [Seite 99]
13.6.5 - 4.6.5 Definieren Sie »fertig und erledigt« [Seite 100]
13.7 - 4.7 Hilfe [Seite 100]
13.7.1 - 4.7.1 Anderen helfen [Seite 101]
13.7.2 - 4.7.2 Hilfe annehmen [Seite 101]
13.7.3 - 4.7.3 Mentorenarbeit [Seite 102]
13.8 - 4.8 Bibliografie [Seite 102]
14 - Kapitel 5: Test Driven Development [Seite 103]
14.1 - 5.1 The Jury is in [Seite 104]
14.2 - 5.2 Die drei Gesetze des TDD [Seite 105]
14.2.1 - 5.2.1 Die Litanei der Vorteile [Seite 105]
14.2.2 - 5.2.2 Die professionelle Option [Seite 108]
14.3 - 5.3 Was TDD nicht ist [Seite 109]
14.4 - 5.4 Bibliografie [Seite 109]
15 - Kapitel 6: Praktizieren und Üben [Seite 111]
15.1 - 6.1 Etwas Hintergrund übers Üben [Seite 111]
15.1.1 - 6.1.1 22 Nullen [Seite 112]
15.1.2 - 6.1.2 Durchlaufzeiten [Seite 113]
15.2 - 6.2 Das Coding Dojo [Seite 114]
15.2.1 - 6.2.1 Kata [Seite 115]
15.2.2 - 6.2.2 Waza [Seite 116]
15.2.3 - 6.2.3 Randori [Seite 117]
15.3 - 6.3 Die eigene Erfahrung ausbauen [Seite 117]
15.3.1 - 6.3.1 Open Source [Seite 118]
15.3.2 - 6.3.2 Ethisch handeln [Seite 118]
15.4 - 6.4 Schlussfolgerung [Seite 118]
15.5 - 6.5 Bibliografie [Seite 118]
16 - Kapitel 7: Akzeptanztests [Seite 119]
16.1 - 7.1 Anforderungen kommunizieren [Seite 119]
16.1.1 - 7.1.1 Verfrühte Präzisierung [Seite 121]
16.2 - 7.2 Akzeptanztests [Seite 124]
16.2.1 - 7.2.1 Die »Definition of Done« [Seite 124]
16.2.2 - 7.2.2 Kommunikation [Seite 127]
16.2.3 - 7.2.3 Automatisierung [Seite 127]
16.2.4 - 7.2.4 Zusätzliche Arbeit [Seite 128]
16.2.5 - 7.2.5 Wer schreibt die Akzeptanztests und wann? [Seite 128]
16.2.6 - 7.2.6 Die Rolle des Entwicklers [Seite 129]
16.2.7 - 7.2.7 Verhandlungen über die Tests und passive Aggression [Seite 130]
16.2.8 - 7.2.8 Akzeptanz- und Unit-Tests [Seite 132]
16.2.9 - 7.2.9 GUIs und andere Komplikationen [Seite 132]
16.2.10 - 7.2.10 Andauernde Integration [Seite 134]
16.3 - 7.3 Schlussfolgerung [Seite 134]
17 - Kapitel 8: Teststrategien [Seite 135]
17.1 - 8.1 Für die Qualitätssicherung sollte nichts übrig bleiben [Seite 135]
17.1.1 - 8.1.1 Die Qualitätssicherung gehört zum Team [Seite 135]
17.2 - 8.2 Die Pyramide der Testautomatisierung [Seite 136]
17.2.1 - 8.2.1 Unit-Tests [Seite 136]
17.2.2 - 8.2.2 Komponententests [Seite 137]
17.2.3 - 8.2.3 Integrationstests [Seite 138]
17.2.4 - 8.2.4 Systemtests [Seite 139]
17.2.5 - 8.2.5 Manuelle explorative Tests [Seite 139]
17.3 - 8.3 Schlussfolgerung [Seite 140]
17.4 - 8.4 Bibliografie [Seite 140]
18 - Kapitel 9: Zeitmanagement [Seite 141]
18.1 - 9.1 Meetings [Seite 142]
18.1.1 - 9.1.1 Absagen [Seite 142]
18.1.2 - 9.1.2 Sich ausklinken [Seite 143]
18.1.3 - 9.1.3 Tagesordnung und Ziel [Seite 143]
18.1.4 - 9.1.4 Stand-up-Meetings [Seite 144]
18.1.5 - 9.1.5 Planungstreffen zur Iteration [Seite 144]
18.1.6 - 9.1.6 Retrospektive und Demo der Iteration [Seite 145]
18.1.7 - 9.1.7 Auseinandersetzungen und Meinungsverschiedenheiten [Seite 145]
18.2 - 9.2 Fokus-Manna [Seite 146]
18.2.1 - 9.2.1 Schlaf [Seite 147]
18.2.2 - 9.2.2 Koffein [Seite 147]
18.2.3 - 9.2.3 Die Akkus aufladen [Seite 147]
18.2.4 - 9.2.4 Muskelfokus [Seite 147]
18.2.5 - 9.2.5 Input vs. Output [Seite 148]
18.3 - 9.3 Zeitfenster und Tomaten [Seite 148]
18.4 - 9.4 Vermeidung [Seite 149]
18.4.1 - 9.4.1 Umkehrung der Prioritäten [Seite 149]
18.5 - 9.5 Sackgassen [Seite 150]
18.6 - 9.6 Morast, Moore, Sümpfe und andere Schlamassel [Seite 150]
18.7 - 9.7 Schlussfolgerung [Seite 151]
19 - Kapitel 10: Aufwandsschätzungen [Seite 153]
19.1 - 10.1 Was eine Aufwandsschätzung ist [Seite 155]
19.1.1 - 10.1.1 Ein Commitment [Seite 155]
19.1.2 - 10.1.2 Eine Aufwandsschätzung [Seite 155]
19.1.3 - 10.1.3 Implizierte Commitments [Seite 157]
19.2 - 10.2 PERT [Seite 158]
19.3 - 10.3 Aufgaben schätzen [Seite 161]
19.3.1 - 10.3.1 Wideband Delphi [Seite 161]
19.4 - 10.4 Das Gesetz der großen Zahlen [Seite 163]
19.5 - 10.5 Schlussfolgerung [Seite 164]
19.6 - 10.6 Bibliografie [Seite 164]
20 - Kapitel 11: Äußerer Druck [Seite 165]
20.1 - 11.1 Druck vermeiden [Seite 167]
20.1.1 - 11.1.1 Commitments [Seite 167]
20.1.2 - 11.1.2 Sauber arbeiten [Seite 167]
20.1.3 - 11.1.3 Verhalten in der Krise [Seite 168]
20.2 - 11.2 Umgang mit Druck [Seite 168]
20.2.1 - 11.2.1 Keine Panik [Seite 168]
20.2.2 - 11.2.2 Kommunizieren Sie [Seite 169]
20.2.3 - 11.2.3 Verlassen Sie sich auf Ihre Disziplinen [Seite 169]
20.2.4 - 11.2.4 Hilfe holen [Seite 169]
20.3 - 11.3 Schlussfolgerung [Seite 170]
21 - Kapitel 12: Teamwork [Seite 171]
21.1 - 12.1 Programmierer kontra Menschen [Seite 172]
21.1.1 - 12.1.1 Programmierer kontra Arbeitgeber [Seite 173]
21.1.2 - 12.1.2 Programmierer kontra Programmierer [Seite 175]
21.2 - 12.2 Kleinhirne [Seite 177]
21.3 - 12.3 Schlussfolgerung [Seite 178]
22 - Kapitel 13: Teams und Projekte [Seite 179]
22.1 - 13.1 Harmoniert es? [Seite 179]
22.1.1 - 13.1.1 Das zusammengeschweißte Team [Seite 179]
22.1.2 - 13.1.2 Aber wie managt man so etwas? [Seite 181]
22.1.3 - 13.1.3 Das Dilemma des Product Owner [Seite 181]
22.2 - 13.2 Schlussfolgerung [Seite 182]
22.3 - 13.3 Bibliografie [Seite 182]
23 - Kapitel 14: Mentoring, Lehrzeiten und die Handwerkskunst [Seite 183]
23.1 - 14.1 Der Grad des Versagens [Seite 183]
23.2 - 14.2 Mentoring [Seite 184]
23.2.1 - 14.2.1 Digi-Comp I - Mein erster Computer [Seite 184]
23.2.2 - 14.2.2 Die ECP-18 in der Highschool [Seite 185]
23.2.3 - 14.2.3 Unkonventionelles Mentoring [Seite 188]
23.2.4 - 14.2.4 Schicksalsschläge [Seite 189]
23.3 - 14.3 Die Lehrzeit [Seite 189]
23.3.1 - 14.3.1 Die Lehrzeit bei der Software [Seite 191]
23.3.2 - 14.3.2 Die Realität [Seite 192]
23.4 - 14.4 Die Handwerkskunst [Seite 193]
23.4.1 - 14.4.1 Menschen überzeugen [Seite 193]
23.5 - 14.5 Schlussfolgerung [Seite 193]
24 - Anhang A: Werkzeuge und Hilfsmittel [Seite 195]
24.1 - A.1 Tools [Seite 196]
24.2 - A.2 Quellcodekontrolle [Seite 197]
24.2.1 - A.2.1 Ein »Enterprise«-System der Quellcodekontrolle [Seite 197]
24.2.2 - A.2.2 Pessimistisches kontra optimistisches Locking [Seite 197]
24.2.3 - A.2.3 CVS/SVN [Seite 198]
24.2.4 - A.2.4 git [Seite 198]
24.3 - A.3 IDE/Editor [Seite 201]
24.3.1 - A.3.1 vi [Seite 201]
24.3.2 - A.3.2 Emacs [Seite 201]
24.3.3 - A.3.3 Eclipse/IntelliJ [Seite 201]
24.3.4 - A.3.4 TextMate [Seite 202]
24.4 - A.4 Issue-Tracking-Systeme [Seite 202]
24.4.1 - A.4.1 Bug-Zähler [Seite 203]
24.5 - A.5 Continuous Build [Seite 203]
24.6 - A.6 Tools für Unit-Tests [Seite 204]
24.7 - A.7 Tools für Komponententests [Seite 205]
24.7.1 - A.7.1 Die »Definition of Done« [Seite 205]
24.7.2 - A.7.2 FitNesse [Seite 205]
24.7.3 - A.7.3 Andere Tools [Seite 206]
24.8 - A.8 Tools für Integrationstests [Seite 206]
24.9 - A.9 UML/MDA [Seite 207]
24.9.1 - A.9.1 Die Details [Seite 207]
24.9.2 - A.9.2 Keine Hoffnung, keine Änderung [Seite 209]
24.10 - A.10 Schlussfolgerung [Seite 209]
25 - Stichwortverzeichnis [Seite 210]

Vorwort

Sie haben sich für dieses Buch entschieden, also darf ich davon ausgehen, dass Sie ein Software-Profi sind. Das ist gut, das bin ich nämlich auch. Und da ich nun schon Ihre Aufmerksamkeit habe, will ich Ihnen berichten, warum ich mir dieses Buch vorgenommen habe.

Alles begann vor nicht allzu langer Zeit an einem gar nicht so weit entfernten Ort. Vorhang auf, Licht und Kamera an, Ton ab ...

Vor einigen Jahren arbeitete ich bei einer mittelgroßen Firma, die Produkte mit besonders strengen behördlichen Auflagen verkaufte. Das ist Ihnen sicherlich geläufig: Wir saßen in einem Großraumbüro in einem dreistöckigen Gebäude. Geschäftsführer und die höheren Ränge hatten eigene Büros, und es dauerte ungefähr eine Woche, um alle relevanten Personen für ein Meeting in den gleichen Raum zu bekommen.

Wir operierten in einem hart umkämpften Marktsegment, als die Regierung ein neues Produkt freigab.

Plötzlich hatten wir eine völlig neue Zielgruppe potenzieller Kunden. Wir brauchten nur dafür zu sorgen, dass sie unser Produkt kauften. Das hieß, wir mussten unsere Unterlagen bis zu einem bestimmten Datum bei der Behörde einreichen, zu einem anderen Termin ein Assessment Audit bestehen und zu einem dritten Termin auf den Markt gehen.

Immer wieder betonte unser Management nachdrücklich, wie wichtig diese Termine seien. Ein kleiner Fehler, und die Regierung würde uns für ein ganzes Jahr vom Markt sperren, und wenn die Kunden sich nicht gleich vom ersten Tag an bei uns anmelden konnten, dann würden sie sich bei anderen Anbietern registrieren, und wir wären aus dem Rennen.

Es war die Art von Umgebung, über die sich manche Leute beschweren und andere betonen, dass hier »der Druck herrscht, der aus Kohle Diamanten formt«.

Ich war der technische Projektmanager, aus der Entwicklungsabteilung heraus dazu ernannt. Meine Verantwortung bestand darin, die Website an besagtem Tag online zu bringen, damit sich die potenziellen Kunden Informationen und vor allem Registrierungsformulare herunterladen konnten. Mein Partner bei diesem Vorhaben war der fürs Business zuständige Projektmanager, den ich hier mal Joe nennen möchte. Joes Rolle war, auf der »anderen« Seite zu arbeiten, also mit der Verkaufs- und Marketingabteilung und den nicht-technischen Anforderungen. Er war auch der Typ, von dem der Kommentar über den Druck, »der aus Kohle Diamanten formt«, stammte.

Wenn Sie sich mit der unternehmerischen Welt Amerikas auskennen und darin gearbeitet haben, dann kennen Sie wahrscheinlich all die Schuldzuweisungen, die anderen die Verantwortung zuschieben, und den Widerwillen gegen Arbeit – alles völlig normal. Unsere Firma hatte für das Problem mit Joe und mir eine interessante Lösung parat.

Es war ein bisschen wie mit Batman und Robin, wie wir unsere Sachen erledigen sollten. In einer bestimmten Büroecke traf ich mich täglich mit dem technischen Team. Wir erstellten jeden Tag den Fahrplan neu, erarbeiteten den kritischen Pfad und räumten anschließend jedes mögliche Hindernis auf diesem kritischen Pfad weg. Wenn jemand bestimmte Software brauchte, besorgten wir sie. Wenn jemand »liebend gerne« die Firewall konfigurieren wollte, aber »ach du meine Güte, es ist ja schon wieder Zeit für die Mittagspause«, dann ließen wir ihm sein Mittagessen anliefern. Wenn jemand an unserem Configuration Ticket arbeiten wollte, aber andere Prioritäten aufgetragen bekommen hatte, dann wandten wir uns an seinen Vorgesetzten.

Dann den Manager.

Dann den Geschäftsführer.

Wir sorgten dafür, dass alles fluppte.

Es wäre etwas übertrieben zu sagen, dass wir Stühle umwarfen, brüllten und tobten, aber wir setzten aus unserer Werkzeugkiste jedes einzelne Instrument ein, um alles auf die Reihe zu bekommen. Wir erfanden nebenher ein paar neue Instrumente und Techniken und machten das auf eine ethische Weise, auf die ich noch heute stolz bin.

Ich betrachtete mich selbst als Teammitglied, das sich keinen Zacken aus der Krone bricht, im Notfall auf die Schnelle auch mal eine SQL-Anweisung zu schreiben oder mit Kollegen zu zweit zu programmieren, damit der Code ablieferbar wird. Zu jener Zeit dachte ich über Joe auch auf diese Weise: Ich betrachtete ihn als Mitglied des Teams und nicht drüberstehend.

Schließlich musste ich erkennen, dass Joe diese Meinung nicht teilte. Das war für mich ein sehr trauriger Tag.

Es war Freitag, ein Uhr nachts. Die Website sollte planmäßig sehr früh am folgenden Montag live gehen.

Wir waren fertig. *FERTIG*. Alle Systeme schnurrten wie Kätzchen, wir waren bereit. Ich ließ das gesamte Tech-Team für das finale Scrum-Meeting zusammenkommen, und nun musste nur noch der sprichwörtliche Schalter umgelegt werden. Mehr als einfach bloß das technische Team hatten wir außerdem auch die Leute aus der Marketing-Abteilung, also die Product Owner, bei uns.

Wir waren stolz. Es war ein toller Moment.

Dann kam Joe vorbei.

Er sagte etwas wie: »Schlechte Nachrichten. Die Rechtsabteilung hat die Registrierungsformulare noch nicht fertig. Also können wir noch nicht live gehen.«

Das war kein sonderlich großes Problem. Die ganze Projektlaufzeit schon waren wir immer wieder mal von der einen oder anderen Sache aufgehalten worden und zogen die Batman-und-Robin-Masche aus dem Effeff durch. Ich war bereit, und meine Antwort lautete im Wesentlichen: »Okay, Partner, machen wir uns noch mal an die Arbeit. Die Rechtsabteilung ist im zweiten Stock, nicht wahr?«

Dann wurde die Geschichte merkwürdig.

Anstatt mir zuzustimmen, fragte Joe: »Wovon redest du da, Matt?«

Ich entgegnete: »Ach, du weißt schon. Unser üblicher Auftritt. Wir reden hier über vier PDFs, oder? Die sind doch schon fertig, und die Rechtsfritzen müssen sie nur abnicken, oder? Komm, wir hängen ein bisschen an ihren Schreibtischen rum, schauen sie ein wenig böse an, und bringen das Ding hier endlich in trockene Tücher!«

Joe stimmte meiner Einschätzung nicht zu, sondern antwortete: »Wir gehen einfach erst Ende nächster Woche live. Keine große Sache.«

Sie können sich wahrscheinlich ausmalen, wie die restliche Unterhaltung weiterging. Sie verlief etwa wie folgt:

Matt:
»Aber warum denn? Die kriegen das doch in ein paar Stunden hin.«

Joe:
»Vielleicht dauert das aber auch länger.«

Matt:
»Aber die haben doch noch das ganze Wochenende! Das ist doch eine Menge Zeit. Komm, wir ziehen das durch!«

Joe:
»Matt, das sind Profis. Wir können sie nicht einfach mit bösen Blicken dazu zwingen, dass sie ihr Privatleben für unser kleines Projekt opfern.«

Matt:
(holt Luft) »Joe ..., was haben wir denn deiner Meinung nach in den vergangenen vier Monaten mit dem Entwicklerteam gemacht?«

Joe:
»Sicher, aber die sind eben Profis.«

Pause.

Tief Luft holen.

Was. Hat. Joe. Gerade. Gesagt?

Zu jener Zeit war ich der Ansicht, dass das technische Team aus Profis besteht, und zwar im besten Sinne des Wortes.

Wenn ich es mir im Nachhinein noch einmal überlege, bin ich mir da nicht mehr so sicher.

Schauen wir uns diese Batman-und-Robin-Masche noch einmal an, und zwar aus einer anderen Perspektive. Ich dachte, dass ich das Team durch Ermahnungen zu Höchstleistungen anspornte, aber ich hege den Verdacht, dass Joe ein Spiel spielte mit der impliziten Annahme, das technische Personal stelle seinen Gegner dar. Denken Sie mal drüber nach: Warum war es nötig, herumzurennen, gegen Stühle zu treten und Kollegen zu bearbeiten?

Hätten wir nicht eher das Team fragen sollen, wann es fertig ist, um eine zuverlässige Aussage zu bekommen? Dieser Antwort hätten wir dann Glauben geschenkt und uns bei diesem Glauben nicht die Finger verbrannt.

Sicher sollten wir als Profis das so machen ... und gleichzeitig auch wiederum nicht. Joe vertraute unseren Antworten nicht und fühlte sich beim Mikromanagement des Teams unwohl. Gleichzeitig vertraute er dem Team der Rechtsabteilung und war nicht gewillt, das Mikromanagement auf sie auszudehnen.

Worum geht es hier eigentlich?

Auf irgendeine Weise hat das Team der Rechtsabteilung einen Professionalismus auf eine Weise demonstriert, wie es das technische Team nicht vermocht hatte.

Irgendwie hatte eine andere Gruppe es geschafft, Joe davon zu überzeugen, dass sie keinen Babysitter brauchte, dass sie keine Spielchen spielte und erwartete, dass sie auf Augenhöhe zu behandeln sei und als Gleichberechtigte respektiert werden wollten.

Nein, ich glaube nicht, dass das etwas mit ein paar schicken Zertifikaten an der Wand zu tun hat oder ein paar Extraseminaren am College, obwohl diese zusätzlichen Jahre am College einem vielleicht implizit ein soziales Training ermöglicht, wie man sich zu verhalten hat.

Seit jenem Tag vor vielen Jahren habe ich mich gefragt, wie der technische Berufsstand sich ändern müsste, damit er als Profis betrachtet wird.

Oh, ich habe so meine paar Ideen. Ich habe ein bisschen gebloggt, viel gelesen, es geschafft, meine eigene Arbeits- und Lebenssituation zu verbessern, und ein paar anderen geholfen. Und doch kannte ich kein Buch, in dem man einen ganzen Plan vorgestellt bekommt und das einem die ganze Sache explizit erläutert.

Dann bekam ich eines Tages aus heiterem Himmel die Anfrage, den frühen Entwurf eines Buches zu prüfen – und zwar genau jenes, das...

Inhaltsverzeichnis (PDF) Inhalt (1) (PDF) Inhalt (2) (PDF)

Systemvoraussetzungen

Als PDF speichern Als Link merken