Der leidenschaftliche Programmierer: Wie Programmierer ihre berufliche Laufbahn erfolgreich gestalten

The PASSIONATE PROGRAMMER

Der leidenschaftliche Programmierer Wie Programmierer ihre berufliche Laufbahn erfolgreich gestalten

CHAD FOWLER

WAS LESER ÜBER DER LEIDENSCHAFTLICHE

PROGRAMMIERER

SAGEN

Wenn die Software-Entwicklung für Sie eine Leidenschaft ist, wenn Sie ein großartiger Software-Entwickler sein wollen, wenn Sie Ihre Arbeit lieben wollen oder wenn Sie Ihre Ansprüche steigern und Software aus Berufung und nicht als nur als Beruf entwickeln wollen, dann sollten Sie dieses Buch lesen. Chad Fowler hilft Ihnen durch praktische Heuristiken und Anleitungen, Begeisterung für Ihre berufliche Tätigkeit zu entwickeln und Ihre Fähigkeiten bestmöglich zu entfalten. Bob Martin, Präsident, Object Mentor Inc. Das Großartige an diesem Buch ist, dass es zahlreiche Handlungsanweisungen enthält - Dinge, die ich tun kann. Es macht deutlich, dass die Verantwortung für meine Situation dort liegt, wo sie hingehört - bei mir. Dieses Buch arbeitet heraus, dass ich nicht alleine bin, dass auch andere in einer ähnlich unsicheren Situation leben, und erklärt, was ich heute dagegen tun kann. Und morgen. Und im Rest meiner beruflichen Laufbahn. Kent Beck, Programmierer Knapp sechs Monate, bevor ich dieses Buch las, stand ich kurz davor, meinen Beruf zu wechseln. Mehrere Zufälle vom November bis zum Mai brachten mich dazu, nicht nur bei der Software-Entwicklung zu bleiben, sondern aus ihr eine Leidenschaft zu machen, die ich wirklich meistern wollte. Dabei diente mir dieses Buch mit seiner gesunden Prise Inspiration als Wegweiser zu meinen Zielen. Sammy Labri, Chief Spaghetti Coder, codeodor.com

The Passionate Programmer Der leidenschaftliche Programmierer

The Passionate Programmer

Der leidenschaftliche Programmierer

Wie Programmierer ihre berufliche Laufbahn erfolgreich gestalten

Chad Fowler Übersetzung aus dem Amerikanischen von Reinhard Engel

mitp

Bibliografische Information Der Deutschen Nationalbibliothek Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über abrufbar. Bei der Herstellung des Werkes haben wir uns zukunftsbewusst für umweltverträgliche und wiederverwertbare Materialien entschieden. Der Inhalt ist auf elementar chlorfreiem Papier gedruckt. ISBN 978-3-8266-5885-3 1. Auflage 2 0 0 9 E-Mail: [email protected] Telefon: +49 89/2183-7928 Telefax: +49 89/2183-7620 Übersetzung der amerikanischen Originalausgabe: Chad Fowler: The Passionate Programmer. Creating a Remarkable Career in Software Development, ISBN: 978-1-934356-34-0 Original English Edition Copyright © 2 0 0 9 Chad Fowler, published by The Pragmatic Programmers, LLC. All Rights Reserved. © 2 0 0 9 mitp, eine Marke der Verlagsgruppe Hüthig Jehle Rehm G m b H Heidelberg, München, Landsberg, Frechen, Hamburg

-fachportal.de

Dieses Werk, einschließlich aller seiner Teile, ist urheberrechtlich geschützt. Jede Verwertung außerhalb der engen Grenzen des Urheberrechtsgesetzes ist ohne Zustimmung des Verlages unzulässig und strafbar. Dies gilt insbesondere für Vervielfältigungen, Übersetzungen, Mikroverfilmungen und die Einspeicherung und Verarbeitung in elektronischen Systemen.

Lektorat: Sabine Schulz Sprachkorrektorat: Petra Heubach-Erdmann Satz: III-satz, Husby, www.drei-satz.de Druck: CPI - Ebner & Spiegel GmbH, Ulm

Widmung Für Kelley Jeanne

Inhalt Vorwort

13

Einführung

15 25

Kapitell: Führen oder bluten?

27

Kapitel 2: Angebot und Nachfrage

33

Kapitel 3: Codieren reicht nicht mehr

39

Kapitel 4: Seien Sie der Schlechteste

43

Kapitel 5: Investieren Sie in Ihre Intelligenz

49

Kapitel 6: Hören Sie nicht auf Ihre Eltern

55

Kapitel 7: Seien Sie ein Generalist

63

Kapitel 8: Seien Sie ein Spezialist

71

Kapitel 9: Legen Sie nicht alle Ihre Eier in den Korb eines anderen

77

Kapitel 10: Lieben Sie es oder lassen Sie es

81 91

Kapitel n : Lernen Sie zu fischen

95

Kapitel 12: Lernen Sie, wie Unternehmen wirklich funktionieren

101

Kapitel 13: S u c h e n Sie sich einen Mentor

105

Inhalt

10

Kapitel 14: Seien Sie ein Mentor

111

Kapitel 15: Übung, Übung, Übung

115

Kapitel 16: Ihr eigener Stil

123

Kapitel 17: Auf den Schultern von Giganten

129

Kapitel 18: Arbeit automatisieren

135 143

Kapitel 19: Der gegenwärtige Moment

145

Kapitel 20: Gedankenleser

149

Kapitel 21: Täglicher Hit

153

Kapitel 22: Vergessen Sie nicht, für wen Sie arbeiten

157

Kapitel 23: Bei der Sache bleiben

161

Kapitel 24: Wie gut kann ich meine Arbeit heute erledigen?

167

Kapitel 25: Was sind Sie wert?

171

Kapitel 26: Ein Kieselstein in einem Eimer Wasser

175

Kapitel 27: Lernen Sie, die Wartung zu lieben

179

Kapitel 28: Acht Stunden brennen

185

Kapitel 29: Lernen Sie, mit Misserfolgen umzugehen . . . .

189

Kapitel 30: »Nein« sagen

195

Kapitel 31: Keine Panik

201

Kapitel 32: Sagen Sie es, tun Sie es, zeigen Sie es

207

Inhalt

II 219

Kapitel 33: Wahrnehmungen, Verzerrungen

223

Kapitel 34: Führer für eine Abenteuerreise

229

Kapitel 35: Mich richtig gut schreiben

233

Kapitel 36: Präsent sein

237

Kapitel 37: Wie ein Anzugträger reden

243

Kapitel 38: Ändern Sie die Welt

247

Kapitel 39: Verschaffen Sie sich Gehör

251

Kapitel 4 0 : Sich zum Markenzeichen machen

257

Kapitel 4 1 : Veröffentlichen Sie Ihren Code

261

Kapitel 4 2 : Bemerkenswert sein

265

Kapitel 43: Beziehungen herstellen

269 277

Kapitel 44: Bereits überholt

279

Kapitel 45: Sie haben Ihren job bereits verloren

283

Kapitel 4 6 : W e g ohne Ziel

287

Kapitel 47: Machen Sie sich eine Karte

291

Kapitel 48: Beobachten Sie den Markt

295

Kapitel 4 9 : Dieser fette Mann im Spiegel

299

Kapitel 50: Die südindische Affenfalle

305

Kapitel 51: Keine Karriereplanung nach dem Wasserfallmodell

311

Inhalt

12

Kapitel 52: Besser als gestern

315

Kapitel 53: Sich selbstständig machen

321

Kapitel 54: Genießen Sie es!

327

Quellen

329

Danksagungen

331

Vorwort

ch glaube, dass jeder in seinem Inneren über einzigartige Fähigkeiten verfügt. Doch er muss etwas finden, das ihm wirklich am Herzen liegt, um diese Fähigkeiten zu entfalten. Sie können nicht bemerkenswert sein, wenn Sie Ihre Umgebung, Ihre Werkzeuge und Ihren Arbeitsbereich nicht lieben. Bevor mein Feuer mit 37signals und Ruby on Rails entfacht wurde, durchlief ich eine Reihe von Positionen und Aufgaben, die man sicher nicht als bemerkenswert bezeichnen könnte. Ich strampelte mich einfach ab und ein Tag verlief wie der andere. Im Handumdrehen waren wieder sechs Monate vergangen, ohne dass ich etwas Greifbares vorweisen konnte. Ein schreckliches Gefühl des Bedauerns war die Folge. Ich hasse das Gefühl, dass mein Dasein nicht wirklich wichtig ist und dass die Welt auch ohne meine Arbeit nicht nennenswert anders wäre. Um ein bemerkenswerter Mensch zu werden, müssen Sie daran glauben, dass Sie einen bedeutsamen Beitrag zum Universum leisten können. Dass meine berufliche Arbeit unbedeutend war, beeinflusste auch mein Privatleben. Solange ich das Gefühl hatte, während meiner Arbeit nur Unbedeutendes zu tun, war es für mich viel schwieriger, in meiner Freizeit Energie für etwas Sinnvolles zu finden.

H

Vorwort

Für mich ist eine bemerkenswerte Karriere die beste Methode, auch den Wunsch nach einem bemerkenswerten Leben anzufachen, in dem man nicht nur im Beruf Besseres und Wertvolleres leistet, sondern auch ein besserer Mensch wird. Deswegen ist dieses Buch so bedeutend. Es geht nicht nur darum, bessere Widgets zu programmieren und sich in seinem Job sicher zu fühlen, sondern vor allem auch darum, die Fähigkeiten und Einstellungen zu entwickeln, ein lohnenswerteres Leben zu führen, in dem die Arbeit nur einer von vielen bemerkenswerten Aspekten ist. David Heinemeier Hansson, Schöpfer von Ruby on Rails und Partner von 37signals

Einführung

In diesem Buch geht es darum, dass Sie Erfüllung und Glück in Ihrer beruflichen Laufbahn finden. Erfüllung und Glück stellen sich selten durch Zufall ein. Sie erfordern Nachdenken, Absicht, Handeln und die Bereitschaft, den bei Fehlern eingeschlagenen Weg zu ändern. Dieses Buch beschreibt eine Strategie, um eine nachhaltig erfolgreiche Karriere (und deshalb ein ebensolches Leben) in der Software-Entwicklung zu planen und umzusetzen. In diesem Buch geht es auch darum, den Wunsch nach einem herausragenden Leben zu kultivieren. Seltsamerweise haben nicht alle Menschen den Wunsch, ein herausragendes Leben zu führen, wenn sie am Anfang ihrer beruflichen Laufbahn stehen. Die meisten sind damit zufrieden, mit dem Strom zu schwimmen. Unsere Erwartungen wurden von den Medien, von Freunden, Verwandten und Familienmitgliedern gedämpft. Deshalb müssen Sie den Wunsch, ein herausragendes Leben zu führen, überhaupt erst als sinnvolles Ziel entdecken. Es liegt nicht auf der Hand. Die meisten Menschen verbringen den größten Teil ihrer wachen Zeit als Erwachsene mit Arbeit. Nach einer Untersuchung der amerikanischen Behörde für Arbeitsmarktstatistik (http://www.bls.gov/ tus/charts/) aus dem Jahre 2006 verbringen durchschnittliche Amerikaner die Hälfte ihrer wachen Zeit mit Arbeit. Freizeit und Sport

i6

17 Einführung

rangieren mit 15 % weit abgeschlagen. Diese Fakten zeigen, dass unsere Arbeit im Wesentlichen unser Leben ist. Wenn wir unser Leben hauptsächlich mit Arbeit verbringen, ist die Liebe zu unserer Arbeit einer der wichtigsten Schlüssel zur Liebe zu unserem Leben. Eine herausfordernde, motivierende und lohnenswerte Arbeit trägt sehr viel eher dazu bei, morgens gerne aufzustehen, als langweilige, durchschnittliche Aufgaben. Wenn Sie Ihre Arbeit gut erledigen, tun Sie in 50 % Ihrer verfügbaren Zeit etwas, was Sie gut können. Wenn Sie umgekehrt Ihre Arbeit nicht gut erledigen, werden Sie einen großen Teil Ihrer Zeit mit Gefühlen der Inkompetenz und des Schuldbewusstseins verbringen, weil Sie wissen, dass Sie nicht das Ihnen Bestmögliche tun. Letztlich streben wir alle nach Glück. Nachdem unsere menschlichen Grundbedürfnisse nach Nahrung und Unterkunft befriedigt worden sind, drehen sich die meisten unserer Ziele darum, Glück zu finden. Leider passen unsere Aktivitäten oft nicht zu diesem einen übergreifenden Ziel. Denn als Menschen verfangen wir uns zu oft in den Mitteln und vergessen darüber das Ziel. Vielleicht wäre ich glücklicher, wenn ich mehr Geld hätte. Vielleicht wäre ich glücklicher, wenn meine Leistungen mehr anerkannt würden. Vielleicht wäre ich glücklicher, wenn ich in meinem Unternehmen befördert werden würde oder wenn ich berühmt werden würde. Doch was wäre, wenn ich arm wäre und eine triviale Arbeit hätte, aber dabei glücklich wäre? Ist das möglich? Wenn es möglich wäre, sollte ich dann mehr Geld anstreben? Oder einen besseren Job? Vielleicht nicht. Sicher ist jedoch: Wenn wir unser Ziel, glücklich zu werden, als Hauptantrieb fest im Blick behalten, können wir bessere Entscheidungen über die kleinen Schritte treffen, um dieses Ziel zu erreichen. Ein höheres Gehalt könnte tatsächlich wünschenswert sein und zu mehr Glück führen. Aber wenn Sie Ihr Hauptziel aus den Augen verlieren, streben Sie möglicherweise ein höheres Gehalt auf Kosten Ihres Glücks an. Es hört sich lächerlich an, aber ich habe dies gemacht. Und Sie sicher auch. Denken Sie darüber nach.

Scheitern kommt nicht infrage!

17

In diesem Buch gebe ich Ihnen Ratschläge, die Ihnen hoffentlich zu einer glücklicheren und lohnenswerteren Karriere und damit auch zu einem glücklicheren Leben verhelfen. Vielleicht verdienen Sie mehr Geld, wenn Sie diese Ratschläge befolgen. Vielleicht erhalten Sie mehr Anerkennung oder werden sogar berühmt. Doch bitte vergessen Sie nicht, dass dies nicht die Ziele sind. Sie sind nur Mittel zum Zweck.

Scheitern kommt nicht infrage! Einer der Hauptschritte, meine eigene bemerkenswerte Karriere zu schaffen, bestand ironischerweise darin, die erste Auflage dieses Buches zu schreiben. Das Buch hatte den Titel My Job Went to India (And All I Got Was This Lousy Book): 52 Ways to Save Your Job [Mein Job ging nach Indien (und mir blieb nur dieses lausige Buch): 52 Methoden, Ihren Job zu retten]. Auf dem Titelbild war ein Kerl mit einem Schild abgebildet, auf dem stand: »Codiere für Essen«. Es war lustig. Sein Titel und sein schockierend roter Deckel sollten auf die Ängste

der

westlichen

Welt

anspielen,

dass

die

Jobs

per

Outsourcing zu preiswerten Offshore-Programmierteams abwanderten. Doch das Problem war, dass ich ein falsches Bild malte. In Wahrheit kann ich Ihnen nicht helfen, Ihren Job zu »erhalten«. In diesem Buch geht es nicht darum, den Grad von Mittelmäßigkeit zu bewahren, den man braucht, um nicht gefeuert zu werden. Es geht darum, herausragend zu sein. Es geht darum, zu gewinnen. Man gewinnt kein Rennen, indem man versucht, nicht zu verlieren. Und man gewinnt kein Leben, indem man versucht, von den Krümeln anderer zu leben. Glücklicherweise drehte sich der Inhalt dieses Buches niemals darum zu versuchen, mit Krümeln auszukommen. Ich kann so nicht denken, und Sie sollten es auch nicht tun. Ich erinnere mich genau an den Zeitpunkt, als ich beschloss, eine bemerkenswerte Karriere zu starten. Ich hatte mich ständig irgendwie durchgemogelt - erst durch die Highschool, dann durch mei-

i6

17 Einführung

nen abgebrochenen College-Besuch, durch eine kurze und etwas mittelmäßige Karriere als professioneller Saxophon-Spieler und durch einige andere Jobs. Durch eine Kombination aus Glück und angeborenem Talent war ich immer einigermaßen erfolgreich genug, um einen gut bezahlten Job als respektiertes Mitglied der technischen Abteilung eines der »am meisten bewunderten« Unternehmen dieser Welt zu bekommen. Aber irgendwie kam ich immer nur durch, und ich wusste es. Eines Abends stöberte ich nach der Arbeit in meinem Buchladen in der Nähe und stieß im Regal mit den Neuerscheinungen auf das Buch Extreme Programming Explained [Becoo] von Kent Beck. Der Untertitel des Buches lautete: Embrace Change (etwa: Den Wandel willkommen heißen). Die Idee des Wandels hatte mich schon immer irgendwie fasziniert. Ich habe eine winzige Aufmerksamkeitsspanne, die sich bis dato als Job-Hopping manifestiert hatte - ich sprang von einem Unternehmen zum nächsten. Die Vorstellung einer »Software-Entwicklungsmethode« hörte sich für mich ausnehmend langweilig und Management-orientiert an. Doch da sie viel mit Änderung zu tun hatte, nahm ich an, dass sie etwas enthalten könnte, um die Langeweile in meiner Arbeit und das Gefühl zu vertreiben, einen neuen Job suchen zu müssen. Das Buch zu kaufen, erwies sich als glückliche Fügung. Ich fing an, es zu lesen, und konnte nicht aufhören. Nachdem ich seinen Inhalt verschlungen hatte, ging ich ins Internet und las alles, was ich über die Ideen der Extreme Programming (XP; Extreme Programmierung) finden konnte. Diese Ideen sprachen mich so stark an, dass ich zum Leiter unserer technischen Entwicklung ging, um ihm diese Ideen anzutragen. Er und seine Mitarbeiter ließen sich überzeugen. Um das Extreme Programming einzuführen, schickte er eine große Gruppe von uns zu dem Extreme-Programming-Immersion-Kurs von ObjectMentor. Extreme Programming Immersion war der Ort, zu dem man gehen musste, wenn man etwas über XP lernen wollte. Stellen Sie sich vor,

Scheitern kommt nicht infrage!

9

Sie dürften Ihre Lieblings-Rockstars eine Woche lang hinter der Bühne bei ihren Auftritten begleiten. Als ich in diesem Raum mit diesen Leuten zusammen war, wurde ich tatsächlich sehr viel klüger. Ich wurde kreativer. Und als es vorbei war, war ich wirklich traurig. Ich konnte mir nicht vorstellen, zurück in mein Kabäuschen zu gehen und weiter gegen die Mittelmäßigkeit anzukämpfen, an die ich mich bei der Arbeit gewöhnt hatte. Mein Kollege Steve, der den Essay Können wir nicht einfach... in Kapitel 43 beigetragen hat, teilte meine Gedanken. Die einzige Möglichkeit, so oft wie möglich mit solchen Menschen umzugehen, besteht darin, selbst einer dieser Menschen zu werden. Anders ausgedrückt: Wenn ich mit den Leuten umgehen wollte, die mich gefördert hatten, als ich mit ihnen interagierte, konnte ich mich nicht bei einem Unternehmen bewerben oder auf einer Uni für einen Kurs einschreiben. Ich musste einfach nur herausfinden, was es bedeutete, ein solcher Mensch zu sein, und dann das Erforderliche tun. Das war der Wendepunkt meiner Karriere. Irgendwie vergaß ich den Anlass, bis mich Steve Jahre später an unser Gespräch erinnerte. Ich hatte ihm davon erzählt, dass ich zum ersten Mal eingeladen worden war, die Eröffnungsrede auf einer Konferenz zu halten. Es hatte mich umgehauen, dass jemand unter den vielen möglichen Kandidaten ausgerechnet mich bitten würde, auf einer SoftwareKonferenz nicht nur einen Vortrag, sondern eine der wesentlichen Ansprachen zu halten. Ich war tatsächlich einer dieser Menschen geworden, zu denen ich gerne gehören wollte. Ich erreichte all dies ohne eine formelle Ausbildung in der Programmierung von Computern. Bevor ich anfing zu programmieren, war ich Musiker. Ich ging aufs College, um Musik zu studieren. Da Musiker nicht viel von einem College-Abschluss haben, vermied ich die meisten Kurse, die nicht dazu beitrugen, aus mir einen besseren Musiker zu machen. Dies bedeutete, dass ich die Universität mit mehr Punkten verließ, als ich für irgendeinen Abschluss brauchte, aber dennoch mehrere Jahre in Kursen hätte absitzen müssen, um

i6

i617Einführung

tatsächlich einen Abschluss zu machen. So bin ich als professioneller Software-Entwickler nicht qualifiziert, zumindest wenn man die typischen Anforderungen einer Stellenanzeige für einen SoftwareIngenieur zugrunde legt. Doch obwohl ich als typischer Software-Entwickler nicht qualifiziert bin, lieferte mir mein Hintergrund als Musiker eine Schlüsseleinsicht, die mir letztlich den Schritt ersparte, ein typischer SoftwareEntwickler zu sein (außerdem: Wer möchte schon typisch sein?). Niemand wird Musiker, weil er einen Job haben will und ein stabiles und komfortables Leben führen möchte. Die Musik-Industrie ist als Umwelt zu grausam, um ein solches Leben planen zu können. Alle Menschen, die professionelle Musiker werden, wollen herausragend sein. Zumindest am Anfang ist der Wunsch, herausragend zu werden, in der Welt der Musik eine Entweder-oder-Sache. Entweder will ein Musiker herausragend (und deswegen berühmt) sein oder er will überhaupt kein Musiker sein. Ich werde oft gefragt, warum es so viele gute Musiker gibt, die auch gute Software-Entwickler sind. Hier haben Sie den Grund. Es liegt nicht daran, dass ihr Gehirn anders funktioniert oder dass sie sowohl detailorientiert als auch besonders kreativ sind. Es liegt daran, dass Menschen, die herausragend sein wollen, sehr viel wahrscheinlicher herausragend werden, als jemand, der nur seine Arbeit machen möchte. Und selbst wenn nicht jeder ein Martin Fowler, ein Linus Torvalds oder ein Pragmatic Programmer werden kann, wird er, wenn er sich ein hohes Ziel setzt, sehr viel wahrscheinlicher zumindest weit über dem Durchschnitt abschneiden.

Es liegt in Ihrer Hand Die meisten Menschen folgen nicht ihren eigenen Plänen, sondern den Plänen anderer. Wenn Sie anfangen wollen, sich von anderen zu unterscheiden, müssen Sie nur innehalten und Ihre Karriere gründlich begutachten. Sie müssen Ihren Plan für Ihre Karriere befolgen - nicht die Pläne anderer Leute.

Es liegt in Ihrer Hand

21

Wie entwickeln Sie diesen Plan? Software ist ein Geschäft. Als Software-Entwickler sind wir Geschäftsleute. Unternehmen stellen uns nicht ein, weil sie uns lieben. Das haben sie noch nie gemacht, und das werden sie nie machen. Dies ist nicht die Aufgabe eines Unternehmens. Unternehmen existieren nicht, damit wir jeden Tag wissen, wo wir hingehen sollen. Der Zweck eines Unternehmens besteht darin, Geld zu verdienen. Wenn Sie in einem Unternehmen I lerausragendes leisten wollen, müssen Sie verstehen, welche Rolle Sie in dem Geschäftsplan des Unternehmens spielen, Geld zu verdienen. Wie wir später genauer untersuchen werden, ist es für ein Unternehmen recht kostspielig, Sie anzustellen. Ihr Unternehmen investiert in Sie. Ihre Herausforderung besteht darin, eine offensichtlich gute Investition zu werden. Sie werden damit beginnen, Ihre eigene Performance unter dem Gesichtspunkt zu beurteilen, welchen Geschäftswert Sie dem Unternehmen oder dem Kunden bieten, das Sie beschäftigt oder für den Sie arbeiten. Betrachten Sie Ihre Karriere wie den Lebenszyklus eines Produktes, das Sie erstellen. Das Produkt besteht aus Ihnen und Ihren Fähigkeiten. In diesem Buch werden vier Facetten behandelt, auf die sich ein Geschäft konzentrieren muss, wenn es ein Produkt entwirft, herstellt und verkauft. Und wir werden untersuchen, wie Sie diese vier Facetten auf Ihre Karriere anwenden können: •

Wählen Sie Ihren Markt. Wählen Sie die Technologien und die

Geschäftsbereiche, auf die Sie sich konzentrieren, bewusst und gezielt aus. In welchem Verhältnis stehen Risiko und Ertrag zueinander? Welche Rolle spielen Angebot und Nachfrage für Ihre Entscheidung? •

Investieren Sie in Ihr Produkt. Ihr Wissen und Ihre Fähigkeiten bilden die Ecksteine Ihres Produktes. Eine angemessene Investition in diese Faktoren ist ein wesentlicher Aspekt dafür, sich selbst vermarktungsfähig zu machen. Einfach zu wissen, wie man in Visual Basic oder in Java programmiert, reicht heute

i6

i617Einführung

nicht mehr aus. Welche anderen Fähigkeiten könnten Sie in der New Economy benötigen? •

Liefern Sie. Einfach über die richtigen Mitarbeiter mit einem Satz starker Fähigkeiten zu verfügen, zahlt sich für ein Unternehmen nicht aus. Die Mitarbeiter müssen liefern. Wie können Sie den richtigen Lieferrhythmus einhalten, ohne sich selbst aus der Spur hinauszukatapultieren? Woher wissen Sie, ob Sie Ihrem Unternehmen die richtigen Werte liefern?

•

Vermarkten Sie sich! Das beste Produkt aller Zeiten wird nicht gekauft werden, wenn niemand weiß, dass es existiert. Wie finden Sie Anerkennung sowohl in Ihrem Unternehmen als auch in der Branche insgesamt, ohne Ihre Seele und Ihren Stolz zu verkaufen?

Neue englische Auflage Dieses Buch ist die deutsche Übersetzung der zweiten englischen Auflage eines Buches mit dem ursprünglichen Titel My Job Went to India (And All I Got Was This Lousy Book): 52 Ways to Save Your Job. Das Ziel der zweiten Auflage bestand darin, die Absicht des ursprünglichen Buches klarer herauszuarbeiten: eine herausragende Karriere zu schaffen. Z u diesem Zweck habe ich nicht nur einen neuen positiveren Titel gewählt, sondern auch neue Inhalte aufgenommen. David Heinemeier Hansson, der Schöpfer von Ruby on Rails und Partner von 37signals, schrieb ein neues Vorwort. Jeder Abschnitt enthält einen oder mehrere Essays von Leuten, die ich getroffen habe oder mit denen ich gearbeitet habe und deren Karrieren wirklich bemerkenswert sind. Diese Essays vermitteln Ihnen Einsichten in die Entscheidungen dieser Innovatoren, Entwickler, Manager und Unternehmer auf dem Weg zu ihrem Erfolg. Sie unterstreichen auch die Tatsache, dass die hier beschriebenen Techniken nicht einfach idealistische Vorschläge sind, die sich nur unter idealen Bedingungen durchführen lassen, sondern dass es sich u m praktisch

Neue englische Auflage

23

erprobte Vorgehensweisen handelt, die von zielbewussten Menschen erfolgreich umgesetzt werden können und wurden. Einige der ursprünglichen Tipps sind entfernt worden; mehrere neue Tipps sind hinzugekommen. Der gesamte letzte Abschnitt der ersten Auflage, IfYou Can't Beat Them (etwa: Wenn du sie nicht schlagen kannst, ...), wurde weggelassen. Die neuen Tipps, die in das ganze Buch eingefügt wurden, geben die Essenz von Lektionen wieder, die ich seit der ersten Ausgabe gelernt habe. Einige Tipps aus der ersten Auflage sind durch neue UmsetzungAbschnitte erweitert worden. Diese Einführung und das Ende sind neu geschrieben worden, um den Fokus auf das Ziel klarer herauszuarbeiten, eine herausragende Karriere zu schaffen. Mit diesem Buch will ich Ihnen eine systematische Methode vermitteln, Ihre eigene herausragende Karriere in der Software-Entwicklung aufzubauen. Wir werden spezielle Beispiele durcharbeiten und jeweils einen Satz von Aktionen herausarbeiten, die Sie sofort umsetzen können und die sowohl kurzfristige als auch langfristige positive Auswirkungen haben werden. Und wie ich bereits erwähnt habe, geht es nicht darum, Ihren jetzigen Arbeitsplatz zu erhalten. Wenn Sie gegenwärtig Angst haben, Ihren Job zu verlieren, werden die Schritte, die Sie unternehmen, um Ihre eigene herausragende Karriere aufzubauen, Ihnen diese Angst nehmen. Herausragende Software-Entwickler kennen keinen Stillstand. Sie suchen nicht ergebnislos nach Arbeit. Deshalb sollten Sie sich keine Sorgen machen. Konzentrieren Sie sich darauf zu gewinnen, und die Angst, zu verlieren, wird für immer verschwinden.

Teil i

Wählen Sie Ihren Markt

Sie sind im Begriff, eine große Investition zu machen. Auch wenn es sich vielleicht nicht um viel Geld handelt, geht es um Ihre Zeit - Ihr Leben. Viele Menschen lassen sich einfach vom Strom ihrer Karrieren tragen, wo immer dieser hinführen mag. Wir lernen ganz zufällig Java oder Visual Basic, und dann schicken uns unsere Arbeitgeber schließlich auf ein Seminar über die neuesten Modewörter der Branche. So lassen wir uns eine Weile von dem Strom forttragen, bis uns etwas anderes vorgesetzt wird. Unsere Karriere ist eine große Abfolge ungerichteter Zufälle. In ihrem Buch The Pragmatic Programmer [HToo] schreiben Dave Thomas und Andy Hunt über das Programmieren per Zufall. Die meisten Programmierer sind mit folgender Situation vertraut: Man beginnt, an etwas zu arbeiten, fügt ein wenig Code an dieser Stelle und etwas mehr Code an einer anderen Stelle hinzu. Vielleicht beginnt man mit einem Beispielprogramm, das man sich von einer Website heruntergeladen hat. Es scheint zu funktionieren; deshalb ändert man es an einigen Stellen ab, bis es wie das Programm funktioniert, das man wirklich braucht. Man muss nicht wirklich verste-

hen, was man eigentlich tut, sondern das Programm so lange modifizieren, bis es die eigenen Anforderungen fast vollständig erfüllt. Das Problem ist nur: Man versteht nicht wirklich, wie es funktioniert. Und mit jeder neuen Funktion, die man hinzufügt, wächst die Wahrscheinlichkeit, dass das Programm auseinanderfällt. Für einen Software-Entwickler ist es ziemlich offensichtlich, dass das Programmieren per Zufall nicht optimal ist. Dennoch tolerieren es

viele

Menschen,

dass

viele

ihrer

wichtigen

Karriere-

entscheidungen rein zufällig getroffen werden. In welche Technologien sollten Sie investieren? Welches Fachgebiet wollen Sie wirklich beherrschen? Sollten Sie Ihr Wissen eher in die Breite oder eher in die Tiefe ausbauen? Dies sind die Fragen, die Sie sich wirklich stellen sollten. Angenommen, Sie hätten ein Unternehmen gegründet und entwickelten sein künftiges Flaggschiff-Produkt. Scheiterte dieses Produkt, würde Ihr Unternehmen wahrscheinlich bankrottgehen. Wie viel Aufmerksamkeit verwenden Sie darauf herauszufinden, für welche Zielgruppe das Produkt bestimmt sein soll? Bevor Sie das Produkt tatsächlich herstellen, wie gründlich denken Sie darüber nach, was das Produkt eigentlich ausmacht? Kein Unternehmer würde sich diese Entscheidungen von jemandem abnehmen lassen. Er würde sich gründlich um jeden einzelnen Aspekt des Entscheidungsprozesses kümmern. Warum also widmen die meisten Menschen den Entscheidungen, die ihre Karriere betreffen, nicht diese Art von Aufmerksamkeit? Wenn Sie Ihre Karriere als ein Geschäft betrachten (was sie tatsächlich ist), besteht Ihr »Produkt« aus den Diensten, die Sie anzubieten haben. Worin bestehen diese Dienste? Wem wollen Sie sie anbieten? Wird die Nachfrage nach Ihren Diensten in den kommenden Jahren wahrscheinlich zunehmen oder abnehmen? Welches Risiko sind Sie bereit, für diese Entscheidungen auf sich zu nehmen? Dieser Teil des Buches wird Ihnen helfen, diese wichtigen Fragen für sich selbst zu beantworten.

|

K A P I T E L io |

Führen oder bluten?

enn Sie Geld investieren wollen, stehen Ihnen viele Möglichkeiten offen. Sie könnten das Geld auf ein Sparkonto legen, aber die Zinsen würden wahrscheinlich von der Inflationsrate aufgefressen werden. Sie können es in Staatsanleihen investieren. Aber auch damit verdienen Sie nicht sehr viel Geld; und wer weiß, ob diese Anleihen in den heutigen Zeiten noch sicher sind. Sie könnten Ihr Geld auch in ein kleines Startup-Unternehmen investieren, beispielsweise indem Sie mehrere Tausend Euro im Austausch für einen kleinen Geschäftsanteil hergeben. Wenn das Unternehmen auf einer soliden Geschäftsidee basiert und diese effizient in Markterfolg umsetzen kann, könnten Sie potenziell viel Geld verdienen. Andererseits haben Sie keine Garantie, dass Sie zumindest Ihre ursprüngliche Investition jemals zurückbekommen. Dieses Konzept ist nicht neu. Sie lernen es bereits als Kind beim Spielen kennen. Wenn Sie direkt durch die Mitte laufen, überraschen Sie möglicherweise alle anderen, und niemand rennt Ihnen nach. Auch im Alltag begegnet Ihnen das Konzept tagtäglich. Sie treffen eine Risiko-Nutzen-Abwägung, wenn Sie sich zu einem Meeting verspätet haben und versuchen, den richtigen Anfahrtsweg herauszufinden. Wenn die Straßen frei sind, können Sie durch eine bestimmte

28

i - Führen oder bluten?

Abkürzung 15 Minuten sparen; doch wenn sie verstopft sind, dann war's das. Die Risiko-Nutzen-Abwägung

ist ein wesentlicher Aspekt

der

bewussten Entscheidungsfindung, wenn es darum geht, Technologien oder Geschäftsbereiche für Investitionen auszuwählen. Vor etwa zwei Jahrzehnten war das Risiko gering, in COBOL programmieren zu lernen. Natürlich gab es damals auch viel mehr COBOLProgrammierer, mit denen man konkurrieren musste. Deshalb war das

Durchschnittsgehalt

eines

COBOL-Programmierers

nicht

berauschend. Man konnte zwar leicht Arbeit finden, aber die Arbeit war nicht besonders lukrativ. Geringes Risiko. Geringe Belohnung. Hätte man sich dagegen für eine neue Sprache wie etwa Java von Sun Microsystems entschieden, wäre es wahrscheinlich eine Zeit lang schwer gewesen, überhaupt eine Anstellung bei einem Unternehmen zu finden, in dem Java eingesetzt wurde. Wer wusste damals schon, dass überhaupt jemand jemals etwas mit Java tun würde? Doch wenn Sie sich damals die Branche so genau angeschaut hätten, wie es Sun offensichtlich getan hatte, hätten Sie möglicherweise etwas Besonderes in Java gesehen. Vielleicht hätten Sie das starke Gefühl entwickelt, etwas Großes vor sich zu haben. Früh in Java zu investieren, hätte aus Ihnen eine Leitfigur in einem großen kommenden technologischen Trend gemacht. Natürlich hätten Sie in diesem Fall mit Java recht gehabt. Und wenn Sie Ihre Karten richtig ausgespielt hätten, hätte sich Ihre persönliche Investition in Java vielfach ausgezahlt. Hohes Risiko. Hohe Belohnung. Nun stellen Sie sich vor, Sie hätten etwa vor 15 Jahren eine Demonstration des neuen Betriebssystems BeOS von Be gesehen. Es war damals unglaublich. Es wurde von Grund auf konzipiert, mit mehreren

Prozessoren

zu

arbeiten.

Seine

Multimedia-Fähigkeiten

waren einfach erstaunlich. Die Plattform fand damals ein erhebliches Medienecho; und die Meinungsmacher schwärmten in Erwar-

Führen oder bluten?

29

tung eines neuen Mitbewerbers im Markt der Betriebssysteme. Natürlich bedeutete eine neue Plattform auch neue Arten der Programmierung, neue APIs und neue Konzepte für die Benutzerschnittstelle. Es gab viel zu lernen, aber es schien die Mühe wirklich wert zu sein. Sie hätten viel Zeit darin investieren können, der erste Anbieter etwa eines FTP-Clients oder eines Personal Information Managers für BeOs zu werden. Als Be eine Intel-kompatible Version seines Betriebssystems veröffentlichte, zirkulierten Gerüchte, Apple wollte das Unternehmen aufkaufen, um dessen Technologie als Basis für die nächste Generation des Macintosh-Betriebssystems zu verwenden. Apple kaufte Be nicht. Und es stellte sich bald heraus, dass Be nicht mal eine Nische des Betriebssystemmarkts besetzen konnte. Das Produkt kam einfach nicht an. Vielen Entwicklern, die sich die Programmierung für die BeOS-Umgebung angeeignet hatten, wurde langsam und schmerzlich bewusst, dass sich ihre Investition langfristig niemals auszahlen würde. Schließlich wurde Be von Palm gekauft, und das Betriebssystem wurde eingestellt. BeOS war eine riskante, aber attraktive Technologie-Investition, die für die Entwickler, die sich dafür entschieden hatten, keine langfristigen Erträge brachte. Hohes Risiko. Keine Belohnung. Bis jetzt habe ich über den Unterschied zwischen der Wahl von Technologien philosophiert, die sich an der Vorderfront der Entwicklung befinden und die fest etabliert sind. Sich für eine stabile Technologie zu entscheiden, die bereits weltweit in Unternehmen produktiv eingesetzt wird, ist sicherer, aber potenziell weniger lohnend als eine spritzige neue Technologie, die noch von niemandem angewendet wird. Doch was ist mit Technologien, die ihren Höhepunkt überschritten haben? Die nur daraufwarten, dass die letzten Nägel in ihre Särge eingeschlagen werden? Wer schlägt diese Nägel ein? Vielleicht denken Sie beispielsweise an die letzten wenigen RPG-Programmierer, die grauhaarig die Stunden bis zu ihrer Pensionierung zählen, während die neue Genera-

31

31 i - Führen oder bluten?

tion von Programmierern noch nicht einmal von RPG gehört hat. Heute lernen alle Java und .NET. Man kann sich leicht vorstellen, dass sich die Karrieren der letzten verbliebenen Statthalter einer überalterten und sterbenden Technologie in derselben Todesspirale drehen wie die Technologie selbst. Aber die alten Systeme sterben nicht einfach. Sie werden ersetzt. Darüber hinaus werden in den meisten Fällen firmenspezifische Systeme stufenweise ersetzt. Und auf diesen Stufen müssen die alten Systeme mit den neuen kommunizieren. Jemand muss wissen, wie man die alten Systeme überreden kann, mit den neuen zu reden, und umgekehrt. Normalerweise wissen die jungen Grünschnäbel nicht, wie man die alten Systeme dazu bringt, zuzuhören. (Meisten wollen sie dies gar nicht wissen.) Umgekehrt wissen die verkrusteten alten Voreigentümer ebenfalls nicht, wie man die neuen Systeme dazu überredet, mit den alten geliebten Kreaturen zu sprechen. Deshalb erkennt der kühl rechnende Technologe eine Marktlücke oder Rolle, die gefüllt werden muss: das Technologie-Hospiz. Alten Systemen zu helfen, komfortabel und in Würde zu sterben, ist eine Aufgabe, die nicht unterschätzt werden sollte. Und natürlich werden die meisten Menschen einfach das sinkende Schiff vorher verlassen, entweder indem sie in Rente gehen oder auf einen anderen technologischen Bereich ausweichen. Wenn Sie der Letzte sind, der ein immer noch geschäftskritisches System betreuen kann, können Sie recht anspruchsvolle Bedingungen stellen. Es ist riskant. Denn wenn die Technologie wirklich verschwunden ist, sind Sie Experte für etwas, das nicht mehr existiert. Doch wenn Sie sich schnell genug bewegen, können Sie sich die nächste aussterbende Generation überalterter Systeme (engl, legacy systems) ausgucken und von Neuem anfangen.

Merksatz Beide Enden der Übernahmekurve neuer Technologien könnten lukrative Geschäftsmöglichkeiten bieten.

Umsetzung

| 31

Die Übernahmekurve neuer Technologien hat zwei Enden. Wie weit außen wollen Sie auf diesen Enden agieren?

Umsetzung 1. Erstellen Sie für den heutigen Markt eine Liste der Technologien, die sich in der Anfangs-, Mittel- und Endphase ihrer Übernahme befinden. Stellen Sie die Verläufe von links nach rechts grafisch dar; links soll sich die Vorderfront befinden; rechts sollen die Technologien stehen, die kurz vor dem Aussterben stehen. Bemühen Sie sich, in jedem Teil des Spektrums so viele Technologien wie möglich zu finden. Seien Sie so feinkörnig oder detailgenau wie möglich, um die Verhältnisse der Kurven zueinander möglichst korrekt darzustellen. Wenn Sie alle Technologien dargestellt haben, die Ihnen einfallen, markieren Sie diejenigen, in denen Sie Ihre Stärken sehen. Markieren Sie dann (vielleicht in einer anderen Farbe) die Technologien, mit denen Sie einige Erfahrungen haben, aber die Sie nicht wirklich beherrschen. Wo befinden sich Ihre meisten Markierungen auf der Übernahmekurve? Bilden sie einen Klumpen? Sind sie gleichmäßig über das ganze Diagramm verteilt? Gibt es Technologien an den äußeren Enden, für die Sie sich besonders interessieren?

Angebot und Nachfrage

A

ls sich das Web durchsetzte, konnte man viel Geld damit verdienen, einfache HTML-Seiten für Unternehmen zu erstellen.

Jedes

Unternehmen

musste

seine

Webseite

haben, und relativ wenige Menschen wussten, wie man Webseiten erstellt. Unternehmen waren bereit, hohe Honorare für »erfahrene« Webdesigner zu bezahlen, was damals bedeutete, dass diese die Grundlagen von HTML, Hyperlinks und Site-Strukturen beherrschten. HTML-Seiten zu erstellen, ist ziemlich einfach. Es ist schwierig, wirklich gut aussehende Seiten zu kreieren, aber die grundlegenden Schritte sind leicht zu verstehen. Als die Menschen sahen, welche Honorare von diesen Webdesignern gefordert wurden, kauften sich immer mehr Bücher über HTML, um sich die Kunst des Webdesigns anzueignen. Der Markt war heiß, die Gehälter oder Stundenhonorare waren attraktiv, und das Angebot an HTML-Experten stieg aufgrund der Nachfrage an. Als der Markt mit Webdesignern überflutet wurde, begannen Webexperten, wirklich künstlerische und bloß nützliche Webseiten zu unterscheiden. Darüber hinaus sanken aufgrund des Wettbewerbs die Preise. Wegen der niedrigeren Preise waren immer mehr Unternehmen bereit, erste Schritte zu einer Internet-Präsenz zu unter-

34

2 - Angebot und Nachfrage

nehmen. Sie wären nicht bereit gewesen, 5.000 € für ihre erste Website zu bezahlen, aber bei 500 € sah es ganz anders aus. Natürlich waren einige Unternehmen immer noch bereit, exorbitante Honorare für eine fantastische

Website auszugeben. Und

gewisse Webdesigner konnten immer noch ein fantastisches Honorar verlangen. Im Laufe der Zeit ließ die Flut der Webdesigner in den unteren bis mittleren Preisgruppen nach. Weniger talentierte Webdesigner wurden durch Endbenutzer und IT-Experten ersetzt, die sich nicht unbedingt auf HTML-Design spezialisiert hatten. Z u diesem Zeitpunkt erreichten Angebot, Nachfrage und Preise für die Herstellung von HTML-Seiten ein Gleichgewicht. Diese kurze Geschichte des Berufszweiges Webdesign illustriert ein ökonomisches Modell, von dem wir alle schon gehört haben: Angehot und Nachfrage. Die meisten verstehen darunter ein Modell, das beschreibt, zu welchem Preis ein Produkt verkauft werden kann und wird. Wenn ein Produkt in einer höheren Menge angeboten wird, als es Käufer gibt, sinkt der Preis des Produktes. Wenn mehr Leute das Produkt kaufen wollen, als angeboten wird, steigt der Preis des Produktes, weil die potenziellen Käufer konkurrieren. Das Angebot-und-Nachfrage-Modell kann nicht nur die Preise von Gütern und Dienstleistungen vorhersagen, sondern auch angeben, welchen Einfluss Preisänderungen auf die Anzahl der Anbieter und Nachfrager eines Produktes haben. Normalerweise sind bei niedrigeren Preisen mehr Menschen bereit, ein Gut zu kaufen als bei höheren Preisen. Merksatz Sie können nicht über den Preis konkurrieren. Tatsächlich können Sie es sich nicht leisten, über den Preis zu konkurrieren.

Warum ist es für uns wichtig? Der Offshore-Software-Trend hat gerade ein großes Angebot an preisgünstigem IT-Personal in

35

Angebot und Nachfrage

unsere Wirtschaft injiziert. Obwohl wir uns Sorgen machen, im Inland Arbeitsplätze zu verlieren, haben die niedrigeren Kosten pro Programmierer tatsächlich die Gesamtnachfrage vergrößert. Gleichzeitig fallen bei steigender Nachfrage die Preise. Auf dem Arbeitsmarkt geht es dabei um die Gehälter. Sie können preislich nicht konkurrieren. Sie können es sich nicht leisten. Also: Was tun Sie? Der Offshore-Markt hat seine preisgünstigen Programmierer in ein relativ enges Segment von Technologien injiziert. In Indien gibt es Java- und .NET-Programmierer im Überfluss. Indien verfügt auch über zahlreiche Oracle-DBAs (Datenbankadministratoren). Dagegen sind Technologien, die nicht im Mainstream liegen, im Angebot der Offshore-Software-Entwicklung erheblich unterrepräsentiert. Wenn Sie einen Satz von Technologien auswählen, auf die Sie Ihre Karriere bauen wollen, sollten Sie die Auswirkungen eines größeren Angebots und niedrigerer Preise auf Ihre Karriereaussichten kennen. Als .NET-Programmierer konkurrieren

Sie wahrscheinlich

mit

Zehntausenden anderer Anbieter auf dem Arbeitsmarkt, ganz im Gegensatz etwa zu einem Python-Programmierer. Dies führt dazu, dass

die

Durchschnittskosten

für einen

.NET-Programmierer

beträchtlich niedriger liegen und möglicherweise die Nachfrage erhöhen (anders ausgedrückt: mehr .NET-Jobs erzeugen). Deshalb finden Sie wahrscheinlich offene Stellen für .NET-Programmierer, deren Gehälter allerdings nicht sehr attraktiv sind. Das Angebot an Python-Programmierern mag zwar viel kleiner sein als das von .NET-Programmierern, kann aber die Nachfrage möglicherweise nicht befriedigen. Wenn der Python-Arbeitsmarkt merklich höhere Preise pro Programmierer bieten würde, könnten zusätzliche Anbieter angezogen werden, die ihre Dienste ebenfalls zu diesen höheren Preisen anböten. Der daraus folgende Wettbewerb würde die Preise wieder nach unten drücken. Das Ganze ist ein Balanceakt. Aber eine Sache scheint (im Moment) sicher zu sein. Indien konkurriert auf IT-Service-Märkten, die sich

2 - Angebot und Nachfrage

36

bereits im Gleichgewicht befinden. Keines der indischen Mainstream-Offshore-Unternehmen

lässt sich

auf

unkonventionelle

Technologien ein. Sie sind keine Innovatoren. Im Allgemeinen gehen sie keine Risiken ein. Sie warten, bis Märkte für bestimmte Technologie-Services

ein Gleichgewicht erreichen, und greifen

dann diese Märkte mit ihren beträchtlich preiswerteren Programmierleistungen an. Aufgrund dieser Beobachtung ist es vielleicht sinnvoll, in Segmenten des Arbeitsmarktes zu konkurrieren, in denen die Nachfrage tatsächlich geringer ist. Dies scheint der Intuition zu widersprechen. Doch

wenn

Sie

befürchten,

aufgrund

von

Offshoring

oder

Outsourcing Ihren Arbeitsplatz zu verlieren, besteht eine Gegenstrategie darin, die Art von Arbeit zu vermeiden, die von OffshoreUnternehmen

angeboten

wird.

Offshore-Unternehmen

bieten

Arbeit an, für die eine hohe Nachfrage existiert. Deshalb ist die Konzentration auf eine Nischentechnologie eine Strategie, die zwar nicht unbedingt den Wettbewerb verringert (denn es werden weniger Jobs angeboten), die aber den Gegenstand des Wettbewerbs von den Preisen auf die Fähigkeiten verlagert. Das ist genau das, was Sie brauchen. Sie können nicht über den Preis konkurrieren, aber Sie können mit Ihren Fähigkeiten konkurrieren. Außerdem wird die Nachfrage nach Mainstream-Programmierern zunehmen, wenn der durchschnittliche Preis für diese Programmierer sinkt. So könnte etwa eine insgesamt steigende Nachfrage nach Java-Programmierern im Inland nicht zu weniger, sondern zu mehr Jobs (einer bestimmten Art) führen. Ein Anstieg des Angebotes durch niedrigpreisigere Offshore-Märkte könnte die Gesamtnachfrage steigern und damit auch die Nachfrage nach höherwertigeren Entwicklern. Dies passiert in der Praxis. Damit Offshoring und Outsourcing wirklich funktionieren, brauchen viele Unternehmen eine Reserve von hoch qualifizierten, inländischen Entwicklern, die Standards setzen, die Qualität sichern und technische Anleitungen geben kön-

| 37

Umsetzung

nen. Eine insgesamt steigende Nachfrage nach Java-Programmierung würde zu einem natürlichen Anstieg der Nachfrage nach diesen Java-Leistungen führen. Vielleicht wandern die billigeren JavaJobs ins Ausland ab, aber gleichzeitig wird es im Inland mehr EliteJava-Jobs als in der Zeit vor dem Offshoring geben. Wie bei den Nischen-Arbeitsmärkten bilden sich auch bei der Java-Entwicklungsarbeit Schichten heraus, in denen sich der Wettbewerb vom Preis auf die Fähigkeiten verlagert.

Merksatz Nutzen Sie Ungleichgewichte im Markt aus.

Die wichtigste Lektion, die wir aus dem Modell von Angebot und Nachfrage lernen können, lautet: Mit steigender Nachfrage wächst der Preiswettbewerb. Die bewährte Folge-den-Jobs-Strategie führt Sie direkt in den Preiswettbewerb mit Offshore-Entwicklern, weil Ihre Fähigkeiten zu den Offshore-freundlichen Gleichgewichtsmärkten passen. In einem Mainstream-Technologie-Markt müssen Sie in einer höheren Schicht konkurrieren, in der Fähigkeiten wichtiger als Preise sind. Alternativ könnten Sie Ungleichgewichte im Markt ausnutzen und in Nischen arbeiten, die von den OffshoreUnternehmen nicht besetzt werden. In beiden Fällen zahlt es sich aus, die treibenden Kräfte zu kennen und fähig und wendig zu sein, um auf sie zu reagieren.

Umsetzung i. Untersuchen Sie die gegenwärtige Nachfrage nach technischen Fähigkeiten.

Studieren

Sie Stellenanzeigen und

Stellenaus-

schreibungen im Web, u m herauszufinden, welche Fähigkeiten mehr und welche weniger nachgefragt werden. Besuchen Sie die Websites

einiger

Offshore-Outsourcing-Unternehmen

(oder

sprechen Sie mit Mitarbeitern solcher Unternehmen, falls Sie

38

2 - Angebot und Nachfrage

mit einem zusammenarbeiten). Vergleichen Sie die Fähigkeiten, die von diesen Unternehmen angeboten werden, mit Ihrer eigenen Liste der stark nachgefragten Fähigkeiten. Halten Sie die Fähigkeiten fest, die im Inland stark nachgefragt, doch von Offshore-Unternehmen nicht oder nur gering angeboten werden. Vergleichen Sie auf ähnliche Weise fortschrittliche Technologien und die Fähigkeiten, die von Offshore-Unternehmen angeboten werden. Beobachten Sie beide Sätze technischer Fähigkeiten, die bei Offshore-Unternehmen unterrepräsentiert sind. Wie lange werden diese brauchen, um diese Lücken zu schließen (falls überhaupt)? Diese Spanne ist das Zeitfenster, in dem ein Marktungleichgewicht existiert.

|

K A P I T E Lio|

Codieren reicht nicht mehr

s reicht nicht aus, darüber nachzudenken, in welche Techno-

E

logien Sie Ihre Zeit investieren wollen. Schließlich gehört die Technologie heute zu den Verbrauchsgütern, nicht wahr? Sie

können sich nicht zurücklehnen und einfach eine Programmiersprache oder die Bedienung eines Betriebssystems erlernen und den Geschäftsleuten den geschäftlichen Teil überlassen. Wenn diese nur einen Codier-Roboter brauchten, wäre es für sie leicht, für diese Arbeit jemanden im Ausland zu engagieren. Wenn Sie wichtig bleiben wollen, müssen Sie alles über das Geschäftsfeld lernen, in dem Sie arbeiten. Tatsächlich sollte ein Software-Entwickler ein Geschäftsfeld nicht nur so gut kennen, dass er Software dafür entwickeln kann, sondern sollte sich zu einer seiner Autoritäten entwickeln. In einem früheren Unternehmen begegnete ich einem ausgezeichneten Beispiel für diese Auffassung. Das Team für die Datenbankadministration bestand aus Mitarbeitern, die sich eigentlich nicht für Datenbanktechnologie interessierten. Als ich den Mitarbeitern das erste Mal begegnete, war ich leicht schockiert. Ich fragte mich, warum sich diese Menschen überhaupt mit Informationstechnologie befassten. Ihre technischen Fähigkeiten waren nicht überragend. Aber das Team hatte etwas Besonderes. Als Bewahrer und Schützer der Daten des

4°

3 - Codieren reicht nicht mehr

Unternehmens kannten sie die Geschäftsprozesse besser als fast alle anderen Analysten des Unternehmens. Deswegen waren sie auf dem unternehmensinternen Arbeitsmarkt heiß begehrt. Während die IT-Spezis eher verächtlich auf sie herabsahen, waren sie für die Geschäftsbereiche, für die sie arbeiteten, unglaublich wertvoll. Sie sollten Ihre Erfahrungen in Ihrem Geschäftsfeld als wichtigen Teil Ihres Portfolios oder Repertoires betrachten. Wenn Musiker ihr Repertoire um ein Stück erweitern, bedeutet dies nicht, dass sie den Song einmal gespielt haben, sondern dass sie ihn wirklich kennen. Dieselbe Einstellung sollten Sie Ihren Geschäftserfahrungen gegenüber kultivieren. Wenn Sie beispielsweise an einem Kassenabrechnungssystem für Hausarztpraxen gearbeitet haben, können Sie wahrscheinlich die einschlägigen Positionen der Roten Liste herunterbeten. Dies ist die Art von Wissen, die zwei ansonsten gleichwertige Software-Entwickler in der richtigen Situation voneinander unterscheidet. Vielleicht sind Sie »nur ein Programmierer«, aber die Fähigkeit, sich mit einem Geschäftskunden in der Sprache seiner Branche zu unterhalten, ist für Ihren beruflichen Erfolg lebenswichtig. Stellen Sie sich vor, wie viel einfacher Ihr Leben wäre, wenn jeder, mit dem Sie arbeiten müssen, wirklich verstünde, wie Software-Entwicklung funktioniert. Dann müssten Sie nicht erklären, warum es keine gute Idee ist, bei einer Webanwendung 3 0 . 0 0 0 Datensätze auf einer einzigen Seite zurückzugeben oder Links zu Ihrem Entwicklungs-Server freizügig bekannt zu geben. Genau dies ist auch das Gefühl, dass Ihre Geschäftskunden Ihnen gegenüber haben: Stellen Sie sich vor, wie viel leichter die Zusammenarbeit

mit diesem

Programmierer

wäre, wenn er einfach verstünde, was ich von ihm möchte, ohne dass ich ihm bis ins kleinste Detail alles erklären und mich lächerlich konkret ausdrücken müsste! Und wissen Sie was? Er zahlt Ihr Geld. Ähnlich wie heiße Technologien können Sie auch Geschäftsfelder auswählen. Im Moment sind Java und .NET in der Software-Entwicklung in. Wenn Sie diese Technologien erlernen, können Sie

Umsetzung

| 41

sich bei den vielen Unternehmen, die mit diesen Technologien arbeiten, um einen Job bewerben. Dasselbe gilt für Geschäftsfelder oder Branchen. Mit derselben Sorgfalt, mit der Sie Ihre Technologie auszuwählen, sollten Sie auch die Branche auswählen, in der Sie arbeiten möchten.

Merksatz Jetzt geht es darum, über die Geschäftsfelder und Branchen nachzudenken, in die Sie Ihre Zeit investieren wollen.

Weil die Auswahl des Geschäftsfeldes oder der Branche für Ihre künftige Karriere so wichtig ist, müssen Sie einen wesentlichen Teil Ihrer Zeit in diese Aufgabe investieren. Wenn Sie noch nicht gezielt und gründlich darüber nachgedacht haben, in welcher Branche Sie arbeiten möchten, ist dies der geeignete Zeitpunkt. Jeder abgelaufene Tag ist eine verpasste Gelegenheit. Ersparnisse auf einem Sparkonto mit geringen Zinsen anzulegen, während anderswo höhere Zinsen zu erzielen sind, ist eine schlechte Investition. Ähnliches gilt für einen Stillstand Ihrer Entwicklung an der Geschäftsfront.

Umsetzung 1. Verabreden Sie sich mit einem Geschäftsmann zum Essen. Sprechen Sie mit ihm darüber, wie er seine Arbeit erledigt. Fragen Sie sich dabei, was Sie ändern oder lernen müssten, um seinen Job zu erledigen. Fragen Sie ihn über die Details seiner täglichen Arbeit. Sprechen Sie mit ihm darüber, wie die Technologie ihm bei der Arbeit hilft oder ihn behindert. Denken Sie über Ihre Arbeit aus seiner Perspektive nach. Machen Sie dies regelmäßig. Vielleicht fühlen Sie sich bei dieser Idee unbeholfen und unwohl. Das ist in Ordnung. Ich begann vor mehreren Jahren mit solchen Gesprächen. Sie haben mein Verständnis meiner

4°

4° 3 - Codieren reicht nicht mehr

Branche erheblich erweitert und meinen Umgang mit meinen Geschäftspartnern verändert. Außerdem lernte ich, mich unbeschwerter mit meinen Kunden zu unterhalten - ein positiver Nebeneffekt. 2. Lesen Sie eine Fachzeitschrift der Branche, in dem Ihr Unternehmen tätig ist. Wahrscheinlich müssen Sie nicht einmal eine kaufen. In den meisten Unternehmen liegen ältere Ausgaben solcher Fachzeitschriften herum. Versuchen Sie, ein solches Magazin durchzuarbeiten. Vielleicht verstehen Sie nicht gleich alles, was Sie lesen. Doch geben Sie nicht auf. Machen Sie eine Liste der Fragen, die Sie Ihrem Management oder Ihren Geschäftskunden stellen wollen. Selbst wenn Ihnen Ihre Fragen dumm vorkommen, werden Ihre Geschäftskunden zu schätzen wissen, dass Sie versuchen zu lernen. Suchen Sie nach Branchen-Websites, die Sie regelmäßig besuchen können. Sowohl auf den Websites als auch in den Magazinen sollten Sie besonders auf die Dinge achten, die als große Nachrichten herausgestellt und in Artikeln eingehend beschrieben werden. Mit welchen Problemen setzt sich die Branche gerade auseinander? Welches sind im Moment die heißen Themen? Was immer das auch sein mag, sprechen Sie es in einem Gespräch mit Ihren Geschäftskunden an. Bitten Sie um eine Erklärung und um ihre Meinung. Denken Sie darüber nach, wie diese gegenwärtigen Trends Ihr Unternehmen, Ihren Geschäftsbereich, Ihr Team und schließlich auch Ihre Arbeit beeinflussen könnten.

Seien Sie der Schlechteste

er legendäre Jazz-Gitarrist Pat Meheny hatte für junge

D

Musiker einen Standardratschlag parat: »Sei immer der schlechteste Spieler in jeder Band, in der du spielst.«

(Ursprünglich entdeckt von Chris Morris bei http://clabs.org/blogki.)

Merksatz Sei immer der schlechteste Spieler in jeder Band, in der du spielst.

Vor meiner Karriere in der Informationstechnologie arbeitete ich als professioneller Jazz- und Blues-Saxophonist. Als Musiker hatte ich das Glück, diese Lektion früh in meiner Karriere zu lernen und zu beherzigen. Wenn Sie der schlechteste Spieler in einer Band sind, bedeutet dies umgekehrt, dass Sie immer mit Leuten spielen, die besser sind als Sie. Doch warum sollte man immer danach streben, der schlechteste Spieler in einer Band zu sein? Wäre das nicht nervenaufreibend? Ja, am Anfang ist es außerordentlich nervenaufreibend. Als junger Musiker war ich oft in Situationen, in denen ich so offensichtlich der schlechteste Spieler der Band war, dass ich sicher war, wie ein

44

4 - Seien Sie der Schlechteste

bunter Hund aufzufallen. Bei einem Gig traute ich mich kaum, mein Saxophon auszupacken, weil ich fürchtete, mit Gewalt aus der Band rausgeworfen zu werden. Oft stand ich neben den Leuten, die ich bewunderte, und erwartete, mit ihrer Virtuosität zu spielen manchmal als Führungsinstrument! Ohne Ausnahme passierte in diesen Situationen (dankenswerterweise!) etwas Magisches: Ich konnte mich eingliedern. Ich ragte unter den anderen Musikern weder als Star hervor, noch spielte ich u m Klassen schlechter als sie. Ich möchte gerne glauben, dass ich über eine Art übermenschlicher Fähigkeit verfügte, mich in ein Genie zu verwandeln, einfach indem ich neben einem stand. Doch im Nachhinein glaube ich, dass das Ganze etwas weniger glamourös war. Es ähnelte eher einem instinktiven, mir einprogrammierten Herdenverhalten. Es ist dasselbe Phänomen, das mich veranlasst, ein neues Vokabular oder grammatikalische Eigenheiten zu übernehmen, wenn ich mich mit Leuten unterhalte, die anders reden als ich. Als wir nach einem anderthalbjährigen Aufenthalt in Indien zurückkehrten, hörte mir meine Frau manchmal zu und brach dann in Lachen aus: »Hast du gehört, was du gerade gesagt hast?« Ich sprach indisches Englisch. Der schlechteste Spieler in der Band zu sein, brachte in mir dasselbe Verhalten als Saxophonist hervor. Ich spielte auf natürliche Weise so wie alle anderen. Was diesem Phänomen wirklich den Glanz nimmt, zeigte sich umgekehrt, wenn ich in Casinos und irgendwelchen Kaschemmen mit weniger guten Bands spielte: Denn dann spielte ich genauso schlecht wie sie. Ähnlich wie ein Alkoholiker, der seine Worte auch dann lang zieht, wenn er nicht betrunken ist, stellte ich fest, dass sich die schlechten Angewohnheiten der Bar-Bands sich auf meine Nicht-Bar-Bands-Nächte übertrugen. Ich lernte aus dieser Erfahrung, dass sich die Fähigkeiten von Menschen allein durch die Leute, mit denen sie auftreten oder arbeiten, erheblich verbessern oder verschlechtern können. Und eine lange gemeinschaftliche Erfahrung innerhalb einer Gruppe kann einen

454-Seien Sie der Schlechteste

nachhaltigen Einfluss auf die eigene Fähigkeit haben, bestimmte Leistungen zu erbringen.

Merksatz Die Menschen in Ihrer Umgebung beeinflussen Ihr Leistungsverhalten. Wählen Sie weise, mit wem Sie umgehen.

Als ich später in die Computer-Industrie wechselte, stellte ich fest, dass diese angelernte Gewohnheit, jeweils die besten Musiker zu suchen, mir auch als Programmierer gute Dienste leistete. Ich versuchte, für die besten IT-Könner zu arbeiten. Und wie zu erwarten war, bewahrheitete sich diese Lektion auch hier. Das schlechteste Mitglied eines Teams zu sein, hat dieselbe Auswirkung wie die Situation, der schlechteste Spieler in der Band zu sein. Sie stellen fest, dass Sie sich intelligenter verhalten, ohne dies näher erklären zu können. Sie sprechen und schreiben sogar intelligenter. Ihr Code und Ihre Designs werden eleganter; und Sie stellen fest, dass Sie schwierige Probleme zunehmend kreativer lösen können. Kommen wir zum ersten Grund zurück, warum ich mich besser als erwartet in diese Bands einpassen konnte. Ich war nicht wirklich so schlecht, wie ich dachte. In der Musik ist es ziemlich einfach festzustellen, ob andere Musiker Sie wirklich für gut halten. Wenn Sie gut sind, laden sie Sie ein, wieder mit ihnen zu spielen. Wenn Sie nicht gut sind, meiden sie Sie. Dieser Maßstab ist sehr viel zuverlässiger, als sie nach ihrer Meinung zu fragen, weil gute Musiker nicht gerne mit schlechten spielen. Z u meiner Überraschung riefen mich mehrere dieser überlegenen Musiker in vielen Fällen an, um mich zu fragen, ob ich wieder mit ihnen spielen oder sogar eine Band mit ihnen gründen wollte. Der Versuch, der schlechteste Spieler sein zu wollen, bewahrt Sie davor, als Hochstapler entlarvt zu werden. Vielleicht gehören Sie in die A-Band, ordnen sich aber aus Angst immer in die B-Band ein.

46

4 - Seien Sie der Schlechteste

Wenn Sie von vornherein zugeben, nicht der Beste zu sein, verschwindet die Angst davor, als Aufschneider entlarvt zu werden. In Wirklichkeit sind Sie, selbst wenn Sie versuchen, der schlechteste Spieler zu sein, tatsächlich nicht der schlechteste.

Umsetzung i. Suchen eine Situation in Ihrer Praxis, in der Sie der/die Schlechteste sein können. Vielleicht können Sie sich den Luxus nicht leisten, sofort das Team oder das Unternehmen zu wechseln, bloß weil Sie mit besseren Leuten zusammenarbeiten wollen. Suchen Sie sich stattdessen freiwillig ein Projekt, an dem Sie mit anderen Entwicklern zusammenarbeiten können, die Sie durch Osmose besser machen. Finden Sie heraus, ob und wo sich Entwickler-Gruppen in Ihrer Stadt treffen, und besuchen Sie sie. Entwickler suchen oft nach Freizeit-Projekten, bei denen sie neue Techniken ausprobieren und ihre Fähigkeiten erweitern können. Wenn es in der Nähe keine aktive Entwickler-Community gibt, benutzen Sie das Internet. Wählen Sie ein Open-Source-Projekt aus, das Sie bewundern und dessen Entwickler anscheinend auf der »nächsten Stufe« agieren, die Sie gerne erreichen möchten. Gehen Sie die To-do-Liste des Projektes oder die Mailing-ListArchive durch, wählen Sie eine Funktion oder die Korrektur eines größeren Bugs aus und machen Sie sich ans Codieren! Emulieren Sie den Stil des umgebenden Projektcodes. Machen Sie daraus ein Spiel. Machen Sie Ihr Design und Ihren Code so ununterscheidbar vom Rest des Projektes, das irgendwann selbst die ursprünglichen Entwickler sich nicht mehr erinnern, wer den Code geschrieben hat. Wenn Sie mit Ihrer Arbeit zufrieden sind, reichen Sie sie dann als Patch ein. Wenn er gut ist, wird er in das Projekt übernommen. Beginnen Sie von vorne und machen Sie es noch einmal. Wenn Sie Entscheidungen getroffen haben, mit denen die Entwickler des Projektes nicht einverstan-

Umsetzung

| 47

den sind, berücksichtigen Sie entweder ihr Feedback in Ihrem Code und reichen den Patch erneut ein oder notieren Sie sich die Änderungen. Versuchen Sie, bei Ihrem nächsten Patch mit weniger Überarbeitung auszukommen. Im Laufe der Zeit werden Sie so zu einem vertrauenswürdigen Mitglied des Projektteams. Sie werden erstaunt sein, was Sie alles von einer entfernten Gruppe erfahrener Entwickler lernen können, selbst wenn Sie niemals direkt mit ihnen sprechen können.

Investieren Sie in Ihre Intelligenz

enn man das Gebiet auswählt, auf das man sich konzentrieren will, kann man der Verlockung erliegen, sich einfach auf die Technologien zu beschränken, in denen die meisten Jobs angeboten werden. Java ist groß, und .NET ist groß. Java zu lernen hat einen einfachen, transitiven Effekt: Wenn ich |ava kenne, kann ich mich um einen Job bewerben (und ihn mögli< herweise bekommen), in dem Java-Code geschrieben wird. Nach dieser Logik wäre es dumm, sich für eine Investition in eine Nischentechnologie zu entscheiden, insbesondere wenn man keine Pläne hat, wie man diese Nische ausnutzen könnte. TIOBE Software ermittelt die relative Beliebtheit von Programmiersprachen mit Internet-Suchmaschinen. Als Maß dienen Menge und Umfang der Gespräche, die Leute über diese Sprachen im Internet führen (http://www.tiobe.com/index.php/content/paperinfo/tpci/ index.html). Laut der Website von TIOBE »basieren die Bewertungen auf der weltweiten Verfügbarkeit kompetenter Ingenieure, Kurse und Drittanbieter«. Das Ergebnis ist definitiv kein wissensc haftlich beweisbares Maß der Beliebtheit, aber es ist ein ziemlich guter Indikator. Als ich die erste Auflage dieses Buches schrieb, war Java die beliebleste Sprache, gefolgt von C. C++ stand auf einem respektablen

5°

5 - Investieren Sie in Ihre Intelligenz

sechsten Platz, allerdings mit einer leichten Aufwärtstendenz. ABAP von SAP stand mit einer leichten Abwärtstendenz an 17. Stelle. Ruby, meine Lieblingsprogrammiersprache, in der ich so gut wie alle ernsthafte Arbeit erledige und für die ich jährlich eine internationale Konferenz organisiere, steht an elfter Stelle. Doch als die erste Ausgabe dieses Buches veröffentlicht wurde, befand sich Ruby nicht einmal unter den Top Twenty. Es rangierte hinter ABAP! War ich verrückt, Ruby zu benutzen, oder einfach dumm? Ich musste der andere von den zwei Anwendern sein, nicht wahr? In seinem Essay

Great

Hackers

(Große

Hacker,

http://paulgra-

ham.com/gh.html) ärgerte Paul Graham die Branche mit seiner Aussage, Java-Programmierer wären nicht so klug wie Python-Programmierer. Er machte zahlreiche dumme

Java-Programmierer

wütend (habe ich das gerade geschrieben?) und brachte viele dazu, auf ihren Websites Gegenargumente zu veröffentlichen. Die heftige Reaktion zeigte an, dass er einen Nerv getroffen hatte. Ich befand mich unter den Zuhörern, als sein Essay zum ersten Mal in Form einer Rede präsentiert wurde. Für mich war sie wie ein Dejä-vu. Ich befand mich auf einer Rekrutierungsreise in Indien, um unter Hunderten von Kandidaten geeignete Bewerber für nur einige Dutzend Jobs auszuwählen. Das Interview-Team arbeitete bis zur Erschöpfung und kam unter Zeitdruck, weil die Interview-TrefferQuote sehr gering war. Mit brummenden Schädeln und roten Augen hielten wir spät abends ein Meeting ab, wie wir unsere Strategie ändern könnten, um alle Kandidaten zu bewältigen. Entweder mussten wir den Prozess optimieren, um mehr Bewerber zu interviewen, oder wir mussten irgendwie bessere Bewerber interviewen (oder beides). Meine Stimme war von zwölf Stunden ununterbrochener Interviews arg strapaziert, in denen ich versucht hatte, aus maulfaulen Programmierern Antworten herauszuholen. Mit dieser schwachen Stimme schlug ich vor, SmallTalk in die Liste der Schlüsselwörter aufzunehmen, mit der unsere Headhunter ihre Datenbank mit den Bewerbungsunterlagen durchsuchten. »Aber in

5°5-Investieren Sie in Ihre Intelligenz

Indien würde doch niemand SmallTalk kennen«, wandte der Personalchef ein. Genau das war mein Punkt. Niemand kannte SmallTalk, und die Programmierung in dieser Sprache unterschied sich grundsätzlich von der Programmierung in Java. Der andere Programmierstil würde bei den Kandidaten ein anderes Niveau von Erwartungen wecken, und die dynamische Natur der SmallTalkUmgebung würde den Ansatz verändern, wie ein Java-Programmierer versuchen würde, ein Problem zu lösen. Ich hoffte, dass diese Faktoren Bewerber mit einer technischen Reife heraussieben würden, die wir bei den Kandidaten bis dato nicht angetroffen hatten. Nachdem wir SmallTalk-Kenntnisse in unsere Anforderungen aufgenommen hatten, war der Kandidaten-Pool im Vergleich zur vorhergehenden Liste winzig. Doch bei diesen Leuten handelte es sich um Rohdiamanten. Sie verstanden wirklich, worum es bei objektorientierter'Programmierung geht. Sie waren sich bewusst, dass Java nicht das idealisierte Heilmittel ist, als das es manchmal verkauft wird. Viele von ihnen liebten es zu programmieren! Wo waren sie nur in den vergangenen zwei Wochen?, dachten wir. Leider konnten wir nur wenige dieser Entwickler zu den Gehältern gewinnen, die wir zu zahlen bereit waren. Sie diktierten die Bedingungen, und die meisten beschlossen, ihren jetzigen Arbeitsplatz zu behalten oder weiter nach einem neuen Job zu suchen. Obwohl wir nicht viele rekrutieren konnten, lernten wir eine wertvolle Rekrutierungslektion: Wahrscheinlich sollten wir grundsätzlich nach Kandidaten mit abweichenden (und sogar unorthodoxen) Erfahrungen suchen, statt uns auf Kandidaten zu konzentrieren, die einheitliche Erfahrungen aufweisen konnten. Ich habe dafür folgende Erklärung: Entweder suchen gute Leute Diversität, weil sie gerne Neues lernen, oder der Zwang, fremdartige Erfahrungen und Umgebungen zu bewältigen, bringt einfach reifere, vielseitigere Software-Entwickler hervor. Ich vermute, dass beides eine Rolle spielt; doch unabhängig davon, warum es funktioniert, lernten wir, dass es funktioniert. Ich benutze diese Technik immer noch, wenn ich Entwickler suche.

5°

5°5- Investieren Sie in Ihre Intelligenz

Abgesehen von dem Versuch, auf meinem Radar aufzutauchen, wenn ich nach Bewerbern suche, welche Gründe könnte es sonst noch geben, in Nischentechnologien zu investieren, für deren Anwendung Sie möglicherweise selten oder gar nicht bezahlt werden? Der erste Grund für mich als Personalmanager, der für Einstellungen zuständig ist, liegt darin, dass ich daran Ihr Interesse ablesen kann. Wenn ich weiß, dass Sie etwas aus eigenen Stücken gelernt haben, um sich weiterzubilden oder (noch besser) einfach weil es Ihnen Spaß gemacht hat, weiß ich, dass Sie die richtige Motivation und Einstellung zu Ihrem Beruf haben. Es macht mich verrückt, wenn ich Leute frage, ob sie bestimmte, nicht ganz im Mainstream liegende Technologien gesehen oder ausprobiert haben, und dann die Antwort erhalte: »Mir wurde keine Gelegenheit gegeben, damit zu arbeiten.« Die Gelegenheit gegeben'? Mir wurde auch keine Gelegenheit gegeben! Ich ergriff die Gelegenheit, zu lernen.

Merksatz Mir wurde keine Gelegenheit gegeben, ...? Ergreifen Sie die Gelegenheit!

Die Beschäftigung mit Nischentechnologien zeigt jedoch nicht nur, dass Sie beruflich die richtige Motivation haben. Es macht Sie auch tiefer, besser, intelligenter und kreativer. Wenn Ihnen diese Gründe nicht reichen, haben Sie wahrscheinlich den falschen Beruf.

Umsetzung i. Lernen Sie eine neue Programmiersprache. Aber gehen Sie nicht von Java zu C# oder von C zu C++. Lernen Sie eine neue Sprache, die Sie zwingt, auf neue Weise zu denken. Als Java- oder C#Programmierer sollten Sie versuchen, eine Sprache wie Small-

Umsetzung

| 53

Talk oder Ruby zu lernen, die keine starke, statische Typisierung verwenden. Wenn Sie bereits länger objektorientiert programmieren, sollten Sie eine funktionale Sprache wie Haskeil oder Scheme ausprobieren. Sie müssen kein Experte werden. Beschäftigen Sie sich so lange mit dem ungewohnten Code, bis Sie den anderen Ansatz der neuen Programmierumgebung wirklich verstanden haben. Falls sich die neue Sprache nicht fremdartig genug anfühlt, haben Sie entweder die falsche Sprache ausgewählt oder Sie wenden Ihre alte Denke auf die neue Sprache an. Bemühen Sie sich nachhaltig, die Idiome der neuen Sprache zu erlernen. Lassen Sie Ihren Code von erfahrenen Programmierern beurteilen und bitten Sie u m Vorschläge, die ihn idiomatisch korrekter machen würden.

Hören Sie nicht auf Ihre Eltern

n unserer Kultur hat es etwas Heiliges, dem Rat seiner Eltern zu folgen. Es wird als die Pflicht eines Kindes angesehen und gehört mit den religiösen Pflichten zu den Dingen, die man unbedingt tun muss. Bücher, Filme und Fernsehdramen drehen sich darum, dass die Weisheit der Eltern der Moral gleichzusetzen wäre. Doch wenn man in unserer Branche Karriere machen will, ist diese Moral falsch. Ihren Eltern wäre es lieber, Sie würden gut durchs Leben kommen, als eine herausragende Karriere auf Kosten großer persönlicher Risiken zu machen. Mehr als bei allen anderen Außenstehenden wird der Rat von Eltern hauptsächlich durch Angst bestimmt. Ein ganz bestimmter Ratschlag zielt darauf ab, nicht zu verlieren. Darüber nachzudenken, nicht zu verlieren, ist nicht die richtige Methode, zu gewinnen! Gewinner nehmen Risiken auf sich. Sie denken daran, wohin sie gehen wollen - nicht daran, wo der Rest des Haulens ist. Eine von Angst bestimmte Karriereplanung führt Sie nicht •iiif den Pfad zur Größe, sondern eher in Ihr kleines Kabäuschen in einem Großraumbüro, in dem Sie den Rest Ihres Lebens verbringen. Gewiss doch, es ist sicherer, aber Spaß macht es ganz bestimmt nicht.

6o

6o616- Hören Sie nicht auf Ihre Eltern

Vor einer Generation war Spaß kein entscheidender Faktor, wenn man über die Wahl einer Karriere sprach. Man erwartete nicht, dass Jobs Spaß machen. Jobs sind dafür da, das Brot und die Butter zu verdienen. Spaß ist das, was man in seiner Freizeit hat. Spaß hat man am Abend und an den Wochenenden. Doch inzwischen haben wir erkannt, dass Sie, wenn Ihr Job keinen Spaß macht, nichts Herausragendes leisten. Es geht weniger darum, dass die Verhältnisse heute anders wären, sondern eher darum, dass sich unser kulturelles Verständnis der Bedeutung der Arbeit zum Besseren gewandelt hat. Immer mehr Menschen verstehen, dass Leidenschaft zur Exzellenz führt. Und ohne Spaß ist es unwahrscheinlich, dass sich Leidenschaft für einen Software-Job entwickeln kann. Es gibt noch einen anderen, die Karriere bestimmenden Faktor, der wahrscheinlich den Ansichten Ihrer Eltern widerspricht: Es ist in Ordnung (und oft vorzuziehen), den Job zu wechseln. Ein vielseitiger Software-Profi hat viele Aspekte der Branche kennen gelernt: Produktentwicklung, IT-Support, Entwicklung interner Geschäftssysteme und Arbeit für Behörden. Je mehr Geschäftsbereiche Sie kennen gelernt haben und je mehr technische Architekturen Sie studiert haben, desto besser sind Sie darauf vorbereitet, bei schwierigeren Projekten die richtigen Entscheidungen zu treffen. Bei einem Unternehmen zu bleiben und sich die Beförderungsstufen hochzuarbeiten, beschränkt Ihr Wachstum als Software-Entwickler. Die Zeiten sind vorbei, in denen jemand in jungen Jahren bei einem Großunternehmen anfing und es sein gesamtes Berufsleben lang nicht mehr verließ. Ein solches Verhalten galt früher als Hingabe. Heute ist es eine Belastung. Wenn Sie nur an einem Ort gearbeitet haben und nur einen Satz von Systemen kennen gelernt haben, werden sich viele (kluge) Manager bei einer Personalentscheidung gegen Sie entscheiden. Ich stelle lieber jemanden ein, der verschiedene Erfolge und Misserfolge in verschiedenen Umgebungen gesehen hat, als jemanden, der nur eine Methode kennt, Aufgaben zu lösen.

Umsetzung

| 57

Vor vielen Jahren erkannte ich, dass meine eigene Karriere viel zu stark von den beruflichen Werten meiner Eltern und ihrer Generation bestimmt worden war. Ich arbeitete für eines der weltweit größten und stabilsten Unternehmen und machte langsam, aber regelmäßig Fortschritte auf der Karriereleiter. Aber ich stagnierte. Ich redete mir ein, ich würde mich nicht selbst in eine Schublade einsperren, und machte das an der Tatsache fest, dass das Unternehmen so groß war, dass ich mehrere verschiedene Jobs an einer scheinbar endlosen Anzahl von Standorten ausführen könnte. Doch letztlich blieb ich am selben Ort und leistete immer dieselbe Arbeit. Ich erinnere mich an ein Gespräch mit einem Freund über die Möglichkeit, dieses Unternehmen zu verlassen. Er fragte mich damals: »Ist es dein Schicksal, für den Rest deines Lebens bei diesem Großunternehmen zu arbeiten?« Um Himmels willen, nein! Deshalb suchte ich mir schnell einen anderen Job bei einem anderen Unternehmen. Diese Entscheidung markierte klar den Anfang meiner nichtlinearen Erfolgskarriere in der Software-Branche. Ich lernte

neue

Geschäftsfelder kennen, ich arbeitete an schwierigeren Problemen, und ich wurde besser entlohnt als jemals zuvor. Manchmal machte ich mir Sorgen, aber als ich beschloss, bei meinem Karriereentscheidungen weniger konservativ zu sein und mich weniger von meinen Ängsten treiben zu lassen, änderte sich Inhalt und »Klang« meiner Karriere - und meines Lebens - zum Besseren. Gehen Sie in Ihrer Karriere kalkulierte Risiken ein. Lassen Sie sich nicht von der Angst verzehren. Und wenn Sie keinen Spaß an der Arbeit haben, werden Sie nie Exzellentes leisten.

Umsetzung i. Was sind Ihre größten Karriereängste? Denken Sie über Ihre letzten Karriereentscheidungen nach. Es müssen keine großen Entscheidungen gewesen sein. (Denn wenn Ihre Entscheidungen von Angst bestimmt werden, sind sie sowieso nicht groß.) Es

6o

6o616- Hören Sie nicht auf Ihre Eltern

könnte sich darum drehen, ob Sie spezielle Aufträge angenommen haben oder ob Sie sich um eine Änderung Ihres Arbeitsplatzes oder eine Beförderung bemüht haben. Stellen Sie eine Liste dieser Entscheidungen auf. Zwingen Sie sich bei jeder Entscheidung zu einer ehrlichen Beurteilung: Wie stark wurde Ihre Entscheidung von Angst bestimmt? Was hätten Sie gemacht, wenn die Angst kein Entscheidungsfaktor gewesen wäre? Wenn die Entscheidung tatsächlich durch Angst bestimmt war, wie können Sie sie rückgängig machen oder eine ähnliche Gelegenheit finden, in der Sie eine weniger Angst-bestimmte Entscheidung treffen können?

Wie ich 300.000 $ von Microsoft ablehnte, um in Vollzeit an GitHub zu arbeiten von Tom Preston-Werner 2 0 0 8 war ein Schaltjahr. Das bedeutete, dass ich vor 366 Tagen, fast auf die Minute genau, alleine in einem Kubikel in Zeke's Sports Bar and Grill auf der Third Street in San Francisco saß. Normalerweise treibe ich mich nicht in Sportkneipen herum, geschweige denn in SOMA. Aber damals war der Donnerstag eine »I Can Has Ruby«-Nacht. Ich glaube, damals konnte man mit »I can has _« alles Mögliche verkaufen. ICHR war ein semiprivates Treffen gleichgesinnter Ruby-Hacker, das im Allgemeinen und nicht ungern später in ein Trinkgelage überging. Normalerweise schwanden mir diese Abende wie mein Kater am nächsten Morgen aus dem Gedächtnis; aber dieser Abend war anders. Dies war der Abend, an dem GitHub geboren wurde. Ich glaube, ich saß allein in dem Kubikel, weil ich gerade einen frischen Fat Tire bestellt hatte und eine kurze Auszeit von der Verbrüderung an den langen Tischen im schwach erleuchteten

Umsetzung

hinteren Teil der Bar brauchte. Nach meinem fünften oder sechsten Schluck kam Chris Wanstrath dazu. Ich weiß heute nicht einmal mehr, ob Chris und ich damals »Freunde« waren. Wir kannten uns oberflächlich durch die Ruby-Treffen und Konferenzen. Mehr als ein gegenseitiges »Hey, ich glaube, dein Code ist fantastisch« war da nicht. Ich bin nicht sicher, warum, aber ich winkte ihn zu mir in das Kubikel und sagte: »Mann, schau dir das mal an.« Etwa eine Woche vorher hatte ich mit der Arbeit an einem Projekt namens Grit begonnen, mit dem auf objektorientierte Weise der Ruby-Code auf GitRepositories zugreifen konnte. Chris gehörte zu den wenigen Rubyisten, die damals anfingen, ernsthaft mit Git zu arbeiten. Er setzte sich zu mir, und ich begann ihm zu zeigen, was ich hatte. Es war nicht viel, aber es war genug, um zu erkennen, dass es etwas in Chris entfacht hatte. Als ich dies spürte, legte ich meine halb ausgegorene Idee einer Art Website auf den Tisch, die Codierern als Drehscheibe (Hub) dienen sollte, über die sie ihre Git-Repositories austauschen konnten. Ich hatte sogar schon einen Namen parat: GitHub. Vielleicht wiederhole ich mich, aber seine Antwort war sehr empathisch: »Ich bin dabei. Fangen wir an!« Am nächsten Abend - am Freitag, den 10. Oktober 2 0 0 7 um 22:24 Uhr - machte Chris den ersten Commit im GitHubRepository und besiegelte damit in digitalem Stein den Anfang unseres gemeinsamen Unternehmens. Es gab bis dahin keine vertraglichen Verabredungen, wie wir vorgehen sollten. Wir waren einfach zwei junge Männer, die zusammen ein cooles Software-Produkt entwickeln wollten. Erinnern Sie sich an die erstaunlich wenigen Minuten in Karate Kit, als Daniel trainiert, um Kampfkunstexperte zu werden? Erinnern Sie sich an die Musik? Nun, wahrscheinlich soll-

| 59

6o

61 6 - Hören Sie nicht auf Ihre Eltern

ten Sie zum iTunes-Store gehen und sich den Song You're the Best von Joe Esposito kaufen und anhören, während ich Ihnen den Rest meiner Geschichte präsentiere. In den nächsten drei Monaten verbrachten Chris und ich unglaublich viel Zeit damit, GitHub zu planen und zu kodieren. Ich machte weiter mit Grit, und Chris entwarf das UI. Chris erstellte auch die Rails App. Wir trafen uns jeden Samstag persönlich, um Design-Entscheidungen zu treffen und herauszufinden, welche Preise wir für die Dienste verlangen sollten. Ich erinnere mich an einen regnerischen Tag, als wir zwei Stunden lang über verschiedene Preisstrategien diskutierten und dabei einige der besten vietnamesischen Ei-Rollen in der ganzen Stadt aßen. Nebenbei waren wir beide auch noch anderweitig beschäftigt. Ich war Vollzeitmitarbeiter bei Powerset und dort als Tools-Entwickler für das Ranking-and-Relevance-Team beschäftigt. Mitte Januar, nach drei Monaten Arbeit in den Abenden und an den Wochenenden, starteten wir unsere private Beta-Version und schickten Einladungen an Freunde raus. Mitte Februar stieß P. J. Hyett zu uns, wodurch wir jetzt ein Drei-Mann-Team waren. Wir veröffentlichten die Website am 10. April. TechCrunch war nicht eingeladen. Z u diesem Zeitpunkt bestand unser Unternehmen nur aus drei Männern in ihren Zwanzigern ohne einen Penny Investmentkapital von außen. Am i. Juli 2 0 0 8 arbeitete ich noch immer in Vollzeit bei Powerset, als wir erfuhren, dass Powerset gerade für etwa 1 0 0 Millionen Dollar von Microsoft übernommen worden war. Das Timing war interessant. Diese Übernahme stellte mich früher vor eine Entscheidung, als ich erwartet hatte. Ich konnte entweder Angestellter von Microsoft werden oder das Unternehmen verlassen und in Vollzeit für GitHub arbeiten.

Umsetzung

Mit 29 war ich der älteste der drei GitHubbers und hatte eine proportional größere Summe an Schulden und monatlichen Ausgaben angehäuft. Ich hatte mich an meinen sechsstelligen Lebensstil gewöhnt. Die Lage wurde dadurch noch verzwickter, dass meine Frau Theresa bald aus Costa Rica zurückkehren sollte, wo sie für ihre Dissertation recherchiert hatte. Bald sollte aus dem Strohwitwer wieder ein verheirateter Mann werden. Und als wäre dies nicht genug, das Microsoft-Angebot war sehr pikant. Mir wurde für die nächsten drei Jahre Gehalt plus 3 0 0 . 0 0 0 Dollar pro Jahr garantiert. Das war genug Geld, um jemanden dazu zu bringen, zweimal über alles Mögliche nachzudenken. Ich stand also vor folgender Entscheidung: ein sicherer Job mit einem hohen garantierten Einkommen als Microsoft-Mann oder ein riskanter Job mit einem unbekannten Einkommen als Unternehmer. Ich wusste, dass das Verhältnis zu den anderen GitHub-Partnern erheblich strapaziert werden würde, wenn ich länger bei Powerset bleiben würde. Sie hatten etwas Geld gespart, sich schon vor einiger Zeit selbstständig gemacht und beide angefangen, in Vollzeit für GitHub zu arbeiten. Es war eine typische Entweder-Oder-Situation: Entweder wählte ich GitHub und setzte mich voll dafür ein oder ich verließ GitHub, um schubkarrenweise Geld bei Microsoft zu verdienen. Wenn Sie ein Rezept für Schlaflosigkeit brauchen, kann ich Ihnen eines geben: Fügen Sie einen Schuss »Was wird meine Frau denken?« zu 3 0 0 0 Teilen Benjamin Franklin hinzu, rühren Sie ein »Freizeit, wann immer Sie wollen« hinzu und garnieren Sie das Ganze mit der Aussicht auf finanzielle Unabhängigkeit.

| 61

6o

6o616- Hören Sie nicht auf Ihre Eltern

Ich bin ziemlich gut darin geworden, meinen Mitarbeitern die schlechte Nachricht mitzuteilen, dass ich das Unternehmen verlassen werde, um etwas Cooleres zu tun. Ich brachte meinem Chef bei Powerset die Nachricht an dem Tag bei, als ich den Anstellungsvertrag hätte unterschreiben müssen. Ich sagte ihm, dass ich das Unternehmen verlassen würde, um in Vollzeit für GitHub zu arbeiten. Wie jeder großartige Chef war er enttäuscht, aber verständnisvoll. Er versuchte nicht, mich mit einem größeren Bonus oder etwas anderem zu bestechen. Ich glaube, dass er tief im Inneren wusste, dass ich gehen würde. Vielleicht hat man mir sogar einen größeren Anreiz geboten zu bleiben als anderen, weil ich als Flugrisiko eingeschätzt wurde. Ich kann Ihnen versichern, dass diese Microsoft-Manager ihr Handwerk beherrschen. Sie haben aus dem Erhalt der Mitarbeiter durch Boni eine Wissenschaft gemacht - sie funktioniert nur nicht, wenn man die Singularität der Geschäftswelt, einen Unternehmer, in die Rechnung einbeziehen will. Dann ist die Situation unkalkulierbar. So wie Indiana Jones niemals die Gelegenheit verstreichen lassen konnte, nach dem Heiligen Gral zu suchen, konnte ich nicht die Gelegenheit verpassen, für mich selbst an einer Sache zu arbeiten, an der mein Herzblut hing, ganz egal, wie sicher die Alternative sein mochte. Wenn ich alt bin und auf dem Sterbebette liege, möchte ich auf mein Leben zurückschauen und sagen können: »Wow, was für ein Abenteuer!« und nicht: »Wow, habe ich mich sicher gefühlt.« Tom Preston-Werner ist Mitbegründer von GitHub.

Seien Sie ein Generalist

eit einigen Jahrzehnten haben verzweifelte Manager und Unternehmer vorgegeben, die Software-Entwicklung wäre im Grunde ein Produktionsprozess. Zunächst werden die Anforderungen spezifiziert, dann entwickeln Architekten aus diesen Spezifikationen eine allgemein gehaltene technische Vision. Ein Designer ergänzt die Architektur durch ausführliche Design-Dokumente, die dann an Roboter-ähnliche Codierer weitergereicht werden, die in der einen Hand ein Comic halten, während sie schlafwandlerisch mit der anderen die Implementierung des Designs eintippen. Schließlich nimmt ein Inspektor den fertigen Code entgegen, der nur dann das Abnahmesiegel erhält, wenn er mit den ursprünglichen Spezifikationen übereinstimmt. Hs ist nicht überraschend, dass Manager sich wünschen, die Software-Entwicklung würde wie ein Produktionsprozess ablaufen. Manager verstehen, wie man Produktionsprozesse

steuert. Wir

haben jahrzehntelang Erfahrungen gesammelt, wie man physische Objekte effizient und präzise herstellt. Wenn wir das, was wir in der l'roduktionsWirtschaft gelernt haben, auf die Software-Entwicklung anwenden, sollten wir deshalb diesen Prozess ebenso optimieren und präzise steuern können, wie wir dies heute von unseren Fabriken gewohnt sind.

7 - Seien Sie ein Generalist

64

In der so genannten Software-Factory (Software-Fabrik) sind die Mitarbeiter Spezialisten. Jeder hat seinen Platz am Fließband, verknüpft JavaKomponenten und rundet die rauen Ecken und Kanten einer VisualBasic-Anwendung mit seinen Software-Schleifmaschinen ab. Der Inspektor hat das Testen gelernt. Software-Komponenten kommen über das Fließband an, und er testet und stempelt sie jeden Tag auf dieselbe Weise. J2EE-Designer entwerfen J2EE-Anwendungen. C++-Codierer codieren in C++. Die Welt ist sehr sauber, und alles hat seinen Platz. Leider funktioniert diese Analogie zur Produktion nicht. Software ist wenigstens

so

formbar

wie

Software-Anforderungen.

Im

Geschäft ändern sich die Dinge; und Geschäftsleute wissen, dass Software soft (weich, formbar) ist und an neue Anforderungen angepasst werden kann. Dies bedeutet: Die Architektur, die Designs, der Code und die Tests müssen alle in einer Weise erstellt und überarbeitet werden, die agiler sein muss, als es selbst der schlankeste Produktionsprozess ermöglicht. In einer solchen sich schnell wandelnden Umwelt zählt vor allem Flexibilität. Wenn der Druck wächst, wenden sich intelligente Geschäftsleute an einen Software-Profi, der das anstehende Problem lösen kann. Deshalb stellt sich für Sie die Frage: Was müssen Sie tun, damit Ihr Name erscheint, wenn wieder jemand nach einem Superhelden sucht, u m den Tag zu retten? Der Schlüssel ist die Fähigkeit, mögliche Probleme lösen zu können. Worin bestehen diese Probleme? Das ist richtig: Sie wissen es nicht. Ich weiß es auch nicht. Doch was ich weiß, ist, dass diese Probleme so vielfältig wie der Software-Entwicklungsprozess insgesamt sind: Deployment-Probleme, kritische Designfehler, die gelöst und schnell neu implementiert werden müssen, die Integration heterogener Systeme oder die Generierung von Ad-hoc-Reports. Der arme Inspektor wäre mit derartig vielfältigen Problemen sehr schnell überfordert. Die Bezeichnung »Hansdampf in allen Gassen« ist normalerweise abwertend gemeint und impliziert, dass der so Bezeichnete sich nicht fokussieren kann, um ein Thema wirklich zu meistern. Aber

657-Seien Sie ein Generalist

wenn Ihre Online-Shopping-Anwendung am Abgrund steht und Sie pro Stunde Hunderte von Bestellungen verlieren, ist es dieser Hansdampf, der nicht nur weiß, wie der Code der Anwendung funktioniert, sondern der auch sehr systemnah auf Bit-und-Byte-Ebene ein Unix-Debugging Ihrer Webserver-Prozesse durchführen kann, der die Konfiguration Ihrer Datenbank auf Engpässe analysieren kann nnd der die Einstellungen Ihres Netzwerk-Routers auf schwer zu lindende Probleme abklopfen kann. Und was noch wichtiger ist: Nachdem er das Problem gefunden hat, kann der Hansdampf sc hnell Architektur- und Design-Entscheidungen treffen, den Code korrigieren und ein neues repariertes System für die Produktion freigegeben. In diesem Szenario wirkt die Idee einer Software-Faclory bestenfalls kurios und schlimmstenfalls gefährlich weltfremd. Die Idee der Software-Factory funktioniert auch in einer anderen 11 insicht nicht: Im Gegensatz zu einem Fließband, mit dem die Produkte in einem konstanten Fluss erstellt werden, verlaufen Software-Projekte normalerweise sehr zyklisch ab. Dies gilt nicht nur für das Projekt insgesamt. Auch die einzelnen Prozesse innerhalb des Projektes verlaufen zyklisch. Ein Codierer wartet, während die Anforderungen spezifiziert und Architektur und Design entworfen werden; oder er wird parallel in mehreren Projekten eingesetzt. Bei solchen »Multitasking«-Codierern gibt es ein Problem: Trotz der Intention der Software-Factory verlassen sich Codierer in einem hohen Maße auf Kontext und Erfahrung, um ihre Aufgaben zu erledigen. Anforderungen sowie Architektur- und Design-Dokumente können den Start erheblich erleichtern. Doch wenn die Programmierer letztlich nicht verstehen, was das System tun soll, können sie auch keine gute Implementierung des Systems erstellen. Natürlich gilt das nicht nur für Codierer, sondern trifft gleichermaßen für fast jeden Aspekt eines »Software-Fließbandes« zu. Der Konlext ist wesentlich; und Multitasking funktioniert nicht besonders gut. Folglich wird ineffizient produziert. Es hat verschiedene Versuche gegeben, dieses Problem der Ineffizienz zu lösen, ohne von der

66

7 - Seien Sie ein Generalist

Analogie zur industriellen Produktion abzugehen. Aber bis jetzt haben wir noch keinen Weg gefunden, wie wir unsere Software-Factories optimieren müssen, um akzeptable Resultate zu erhalten. Wenn Sie nur ein Codierer oder ein Tester oder ein Designer oder ein Architekt sind, werden Sie während eines Projektes immer wieder unbeschäftigt sein, wenn es sich gerade in einer anderen Phase befindet. Wenn Sie nur ein J2EE-, ein .NET- oder ein Unix-Programmierer sind, haben Sie nicht viel beizutragen, wenn sich der Schwerpunkt eines Projektes oder eines Unternehmens, und sei es auch nur temporär, von Ihrem Spezialgebiet weg verlagert. Dabei geht es nicht darum, wo Sie in der angenommenen Wertschöpfungskette der Projektarbeit angesiedelt sind (wobei der Architekt den höchsten Rang einnimmt). Es geht darum, wie nützlich Sie sich im Allgemeinen machen. Wenn Ihr Ziel darin besteht, bei anstehenden Entlassungen oder Verlagerungen der Jobs in den Osten der Letzte in der Schlange zu sein, sollten Sie sich so schnell wie möglich allgemein nützlich machen. Wenn Sie befürchten, dass Ihr einst überfülltes Entwicklungsbüro nur noch eine Skelett-Besatzung zur Betreuung fernöstlicher Software-Lieferanten beherbergen wird, sollten Sie sich schnell bewusst machen, dass ein Team, das »nur einen Tester«, »nur einen Coder« usw. zu bieten hat, nur wenige Funktionen erfüllt und deshalb nicht sehr nachgefragt sein wird. Besser: Wenn Sie auffallen und herausragen wollen, müssen Sie das große Ganze verstehen.

Merksatz Generalisten sind selten ... und deshalb kostbar.

Wenn man Generalist werden will, darf man sich nicht einer speziellen Rolle oder Technologie verschreiben. Wir werden im Laufe unserer Karriere auf viele Weisen tituliert. Um sich zu veranschauli-

677-Seien Sie ein Generalist

chen, was es heißt, ein Generalist zu sein, hilft es, die IT-Karrierelandschaft in verschiedene unabhängige Aspekte oder Dimensionen zu zerlegen. Mir fallen fünf ein, aber es existiert eine unendlich große Anzahl (es hängt alles davon ab, wie Sie persönlich die Themen unterteilen): •

die Stufe auf der Karriereleiter

•

Plattform/Betriebssystem

•

Code vs. Daten

•

Systeme vs. Anwendungen

•

Geschäft vs. IT

Dies sind verschiedene Dimensionen, in denen Sie das Problem angehen können, ein Generalist zu werden. Dies ist nur eine Möglichkeit, über Ihre Karriere insgesamt nachzudenken; und wahrscheinlich finden Sie für sich eine bessere Liste. Doch im Moment wollen wir diese Punkte diskutieren. Zunächst können Sie entscheiden, ob Sie Führer oder Manager sein oder eher technisch orientiert arbeiten wollen. Oder Sie können sich als Architekt im Gegensatz zu einem Programmierer oder Tester sehen. Der Wert der Fähigkeit, flexibel verschiedene Rollen auszufüllen, wird von vielen Leuten nicht erkannt. Beispielsweise sollte sich ein starker Leiter so weit wie möglich aus dem Tagesgeschäft heraushalten. Doch die neue Welt der Onshore-Skelett-Teams kann von Leuten profitieren, die zugleich Teams und Projekte führen, aber auch die Ärmel hochkrempeln können, um in letzter Minute kritische Fehler zu beheben, während das Offshore-Team schläft. Dasselbe gilt für einen Software-Architekten, der möglicherweise den Fortschritt eines Projektes erheblich beschleunigen könnte, wenn er nur ein wenig codieren könnte, um die Dinge ans Laufen zu bringen. Wenn die Grenzen von Hierarchien überschritten werden sollen, werden die Leute häufig nicht durch ihre Abneigung, sondern durch ihre (mangelnden) Fähigkeiten daran gehindert. Programmier-Geeks können nicht leiten, und Leiter können nicht hacken. Selten findet man jemanden, der beides gut kann.

68

7 - Seien Sie ein Generalist

Merksatz Ihre Fähigkeiten sollten auf verschiedenen technologischen Plattformen anwendbar sein.

Eine andere künstliche (und unentschuldbare) Grenze wird zwischen Plattformen und Betriebssystemen gezogen. Ein Unix-Programmierer, der sich weigert, mit Windows zu arbeiten, verhält sich zunehmend praxisfremd. Dasselbe gilt für die Kontroverse zwischen .NET und J2EE oder andere ähnliche Infrastruktur-Plattformen. Langlebigkeit erfordert, dass Sie sich in Ihrem Arbeitsbereich Plattform-neutral verhalten. Jeder hat eigene Präferenzen, aber Ideale sollten besser zu Hause bleiben. Meistern Sie eine Plattform, und erwerben Sie ausreichende Fähigkeiten auf einer anderen. Ihre Fähigkeiten sollten über die Technologie-Plattformen hinausgehen. Plattformen sind Werkzeuge, sonst nichts. Wenn wir einen Windows-Programmierer suchen, finden wir ihn auf den Philippinen. Doch wenn wir jemanden suchen, der wirklich die Entwicklung unter Windows und Unix versteht und uns helfen kann, beides zu integrieren, schauen wir uns wahrscheinlich im Inland um. Lassen Sie sich durch den so genannten Teamgeist oder Gruppendruck nicht in eine bestimmte Ecke drängen. Die Trennlinie zwischen einem Datenbankadministrator

(DBA;

eine Rolle, die sich im Laufe des letzten Jahrzehnts aus dem Nichts fest etabliert hat) und einem Software-Entwickler sollte ebenfalls nicht scharf umrissen sein. Datenbankadministrator zu sein bedeutet heute in vielen Unternehmen, zu wissen, wie man ein GUIAdmin-Tool einsetzt und ein spezielles Datenbankprodukt einrichtet. Der DBA muss nicht unbedingt wissen, wie die Datenbank eingesetzt wird. Umgekehrt werden Software-Entwickler zunehmend fauler und dümmer, wenn es u m das Arbeiten mit Datenbanken geht. Beide Seiten stützen sich gegenseitig.

Umsetzung

| 69

Als ich anfing, in der IT-Branche zu arbeiten, erstaunte mich anfangs am meisten, dass viele gut ausgebildete Programmierer (vielleicht die meisten) überhaupt keine Ahnung davon hatten, wie die Systeme eingerichtet wurden, die sie für Entwicklung und Deployment verwendeten. Ich arbeitete mit Entwicklern zusammen, die nicht einmal ein Betriebssystem auf einem PC installieren konnten, wenn man sie darum bat. Noch weniger konnten sie einen Anwendungsserver einrichten, um ihre Anwendungen zu deployen. Es ist selten und erfrischend, einen Entwickler zu finden, der seine Arbeitsplattform wirklich versteht. Seine Anwendungen sind besser, und er erledigt seine Arbeit schneller. Schließlich sollte, wie es im Kapitel Codieren reicht nicht mehr weiter vorne beschrieben wurde, die Mauer zwischen dem Geschäft und der IT sofort eingerissen werden. Fangen Sie an zu lernen, wie Ihr Unternehmen arbeitet.

Umsetzung 1. Listen Sie auf einem Blatt Papier oder einer Tafel die Dimensionen auf, in denen Sie Ihr Wissen und Ihre Fähigkeiten generalisieren

können/wollen

(oder nicht).

Notieren

Sie in

jeder

Dimension Ihre Spezialität. Wenn beispielsweise Plattform und Betriebssysteme eine Ihrer Dimensionen ist, könnten Sie Windows/. NET daneben schreiben. Schreiben Sie dann rechts neben Ihre Spezialität ein oder mehrere Themen, die Sie auf Ihre »Zu lernen«-Liste setzen sollten. U m im Beispiel zu bleiben: Sie könnten auch Linux und Java (oder sogar Ruby oder Perl) aufschreiben. Nehmen Sie sich sobald wie möglich (spätestens in dieser Woche!) 30 Minuten Zeit, um wenigstens eines der Themen auf Ihrer »Zu lernen«-Liste zu bearbeiten. Lesen Sie nicht nur darüber. Falls möglich, arbeiten Sie praktisch damit. Wenn es sich um eine Web-Technologie handelt, laden Sie sich ein Webserver-

70

7 - Seien Sie ein Generalist

Paket herunter und richten den Webserver selbst ein. Wenn es sich um ein Geschäftsthema handelt, laden Sie einen Ihrer Kunden oder Kollegen zum Essen ein, um dieses Thema zu diskutieren.

Seien Sie ein Spezialist

Wie würden Sie ein Programm in reinem Java schreiben, das die Java Virtual Machine zum Absturz bringen würde?« Totenstille. »Hallo?« »Tut mir leid. Ich verstehe Sie nicht. Können Sie bitte Ihre Frage wiederholen?« Die Stimme klang verzweifelt. Aus Erfahrung wusste ich, dass es nichts helfen würde, die Frage zu wiederholen. Dennoch wiederholte ich die Frage langsam und lauter. »Wie würden Sie ein Programm in reinem Java schreiben, das die Java Virtual Machine zum Absturz bringen würde?« »Ah ... tut mir leid. Das habe ich noch nie gemacht.« »Ich bin sicher, dass Sie das noch nie gemacht haben. Wie wär's mit folgender Frage: Wie würden Sie ein Programm schreiben, das die | VM NICHT zum Absturz bringen würde?« Ich suchte nach wirklich guten Java-Programmierern. U m das Interview zu beginnen, bat ich diesen Bewerber (und alle anderen, die ich in dieser Woche interviewte), sich selbst auf einer Skala von i bis 10 einzustufen. Er sagte neun. Ich erwartete, einen Star vor mir zu haben. Wenn sich dieser Mensch selbst so hoch einschätzt, warum kann er sich keinen fiesen Programmierertrick ausdenken, um die ) VM zum Absturz zu bringen? Mangel an technischer Tiefe.

72 Merksatz Z u viele scheinen zu glauben, dass Spezialisierung einfach bedeutet, nichts über andere Dinge zu wissen.

Hier saß jemand vor mir, der behauptete, ein Java-Spezialist zu sein. Wenn Sie ihn auf einer Party getroffen und gefragt hätten, womit er seinen Lebensunterhalt verdiente, hätte er geantwortet: »Ich bin Java-Entwickler.« Dennoch konnte er diese einfache Frage nicht beantworten. Er konnte sich nicht einmal eine falsche Antwort ausdenken. Während der zweieinhalb Wochen intensiver Interviews auf einer Rekrutierungsreise durch das ganze Land war dies die Regel, nicht die Ausnahme. Tausende von Java-Spezialisten hatten sich für offene Stellen beworben, doch kaum einer konnte erklären, wie ein Java Class Loader funktioniert, oder einen allgemeinen Überblick darüber geben, wie die Speicherverwaltung normalerweise von einer Java Virtual Machine gehandhabt wird. Zugegeben, man muss diese Dinge nicht wissen, um unter der Aufsicht anderer einfachen Code zu produzieren. Aber wir hatten bisher angeblich mit Experten zu tun. Z u viele scheinen zu glauben, dass die Spezialisierung auf eine Sache einfach bedeutet, nichts über andere Dinge zu wissen. Beispielsweise könnte ich meine Mutter als Windows-Spezialistin bezeichnen, weil sie niemals Linux oder OS X benutzt hat. Oder ich könnte sagen, meine Verwandten, die in Arkansas auf dem Lande leben, wären Spezialisten für Country-Musik, weil sie nie etwas anderes gehört haben. Stellen Sie sich vor, Sie würden Ihren Hausarzt besuchen und sich über eine seltsame Verdickung unter der Haut Ihres rechten Armes beklagen. Ihr Arzt überweist Sie an einen Spezialisten, u m eine Biopsie durchführen zu lassen. Was wäre, wenn dieser Spezialist als Referenz nur ausweisen könnte, dass er während seines Studiums keine Vorlesungen belegt hätte, die nicht direkt mit der speziellen Prozedur zu tun hatten, die er heute an Ihnen ausführen soll? Ich

nieine damit keine Vorlesungen, die die Themen eingehender behandelten, die mit der heutigen Prozedur zu tun haben. Was ist, wenn er diese Themen nur oberflächlich kennen gelernt hat und nichts anderes weiß? »Was ist, wenn die Maschine da drüben während der Operation anfängt zu piepsen?«, könnten Sie fragen. »Oh, das ist noch nie passiert. Es wird auch diesmal nicht passieren. Ich weiß nicht, was diese Maschine macht. Aber sie piepst niemals.« Glücklicherweise sind die meisten Software-Entwickler nicht für Situationen verantwortlich, in denen es um Leben oder Tod geht. Wenn sie Mist bauen, kann normalerweise ein Projekt nicht rechtzeitig beendet werden oder es treten Fehler bei der Produktion auf, die ihren Arbeitgebern Geld, aber keine Leben kosten. Leider hat die Software-Branche große Mengen dieser flachen Spezialisten hervorgebracht, die die Bezeichnung Spezialist als Entschuldigung dafür verwenden, nur eine Sache zu kennen. In der Medizin ist ein Spezialist jemand, der ein bestimmtes Fachgebiet gründlich kennt. Ärzte verweisen ihre Patienten an Spezialisten, weil diese ihnen unter bestimmten Umständen eine bessere Behandlung geben können als ein Allgemeinmediziner. Was sollte ein Software-Spezialist sein und können? Ich kann Ihnen sagen, wonach ich auf dieser Rekrutierungsreise in den hintersten Winkeln gesucht habe. Ich suchte nach Leuten, die die Java-Programmierung und die Deployment-Umgebung gründlich kannten. Ich wollte Leute einstellen, die in 80 % der möglichen Situationen sagen konnten: »Habe ich bereits gesehen/gemacht«, und deren Wissen so tief war, dass sie sich zutrauten, die restlichen 20 % ebenfalls zu meistern. Ich suchte Leute, die bei einem Gespräch über hoch angesiedelte Abstraktionen auch die systemnahen Details verstanden, die zur Implementierung dieser Abstraktionen erforderlich waren. Ich suchte jemanden, der alle Deployment-Probleme lösen konnte, mit denen wir rechnen mussten, oder der zumindest wusste, wen er um Hilfe bitten musste, wenn er das Problem selbst nicht lösen konnte.

74 Dies ist die Art von Spezialist, die sich im Wandel der Computerbranche behaupten kann. Wenn Sie ein .NET-Spezialist sind, ist dies keine Entschuldigung dafür, nichts außer .NET zu kennen. Es bedeutet: Wenn es um .NET geht, sind Sie die Autorität. Hängt ein IIS-Server und muss rebootet werden? »Kein Problem.« SourceControl-Integration mit Visual Studio .NET? »Ich zeige Ihnen, wie es geht.« Kunden wollen wegen obskurer Performance-Probleme ihre Aufträge kündigen? »Geben Sie mir dreißig Minuten.« Wenn dies nicht das ist, was Spezialist für Sie bedeutet, dann hoffe ich, dass Sie nicht behaupten, einer zu sein.

Umsetzung i. Verwenden Sie eine Programmiersprache, die auf einer virtuellen Maschine kompiliert und ausgeführt wird? Falls dies der Fall ist, sollten Sie sich die Zeit nehmen zu lernen, wie Ihre VM funktioniert. Für Java, .NET und SmallTalk gibt es viele Bücher und Websites zu diesem Thema. Man kann leichter darüber lernen, als Sie denken. Doch unabhängig davon, ob Ihre Sprache mit einer VM arbeitet oder nicht, sollten Sie sich Zeit nehmen zu studieren, was passiert, wenn Sie eine Quelldatei kompilieren. Wie werden aus dem Code, den Sie als Text eintippen und lesen können, Anweisungen, die ein Computer ausführen kann? Was würde es bedeuten, einen eigenen Compiler zu schreiben? Wenn Sie externe Bibliotheken importieren oder benutzen, wo kommen diese her? Was bedeutet es faktisch, eine externe Bibliothek zu importieren? Wie verknüpft der Compiler, das Betriebssystem oder die virtuelle Maschine mehrere Code-Dateien zu einem zusammenhängenden System? Wenn Sie diese Tatsachen lernen, kommen Sie Ihrem Ziel einige Schritte näher, ein Experte auf Ihrem Spezialgebiet zu werden.

Umsetzung

| 75

2. Suchen Sie eine Gelegenheit - an Ihrem Arbeitsplatz oder außerhalb

einen Kurs über einen Aspekt einer Technologie zu

geben, über die Sie selbst mehr lernen möchten. Wie Sie im Kapitel Seien Sie ein Mentor lesen werden, ist Unterrichten eine der besten Methoden zu lernen.

Legen Sie nicht alle Ihre Eier in den Korb eines anderen

ährend ich eine Gruppe zur Anwendungsentwicklung

W

leitete, fragte ich einmal einen meiner Mitarbeiter: »Was machen Sie mit Ihrer Karriere? Was wollen Sie sein?«

Ich war über seine Antwort furchtbar enttäuscht: »Ich möchte ein J2EE-Architekt sein.« Ich fragte, warum er nicht ein »Microsoft-

Word-Designer« oder ein »RealPlayer-Installateur« sein wolle. Dieser Mensch wollte seine Karriere auf einer speziellen Technologie aufbauen, die von einem speziellen Unternehmen geschaffen worden war, bei dem er nicht angestellt war. Was würde passieren, wenn das Unternehmen vom Markt verschwinden würde? Was wäre, wenn es seine gegenwärtig gefragte Technologie vom Markt nehmen würde? Warum sollten Sie Ihre Karriere überhaupt von einem Technologie-Unternehmen abhängig machen? Irgendwie geben wir uns in dieser Branche der Illusion hin, Marktführer zu sein, wäre dasselbe, wie ein Standard zu sein. Deshalb scheint es für einige Leute vernünftig zu sein, das Produkt eines anderen Unternehmens zu einem Bestandteil ihrer eigenen Identität zu machen. Noch schlimmer: Einige basieren ihre Karriere auf nicht im Markt führende Produkte - wenigstens so lange, bis ihre Karriere kläglich so scheitert, dass sie dann nicht umhin können, ihre Verluststrategie zu überdenken.

78

9 - Legen Sie nicht alle Ihre Eier in den Korb eines anderen

Denken Sie bitte noch einmal daran, dass Sie Ihre Karriere als ein Geschäft auffassen sollten. Obwohl es möglich ist, ein Geschäft als Parasit eines anderen aufzubauen (etwa wie die Unternehmen, die Produkte zur Entfernung von Spyware herstellen und damit die Unzulänglichkeiten des Sicherheitsmodells des Internet Explorers von Microsoft ausnutzen), ist es für ein Individuum unglaublich riskant, sich auf eine solche Strategie einzulassen. Ein Unternehmen, wie etwa das gerade erwähnte Spyware-Beispiel, kann normalerweise auf Änderungen der Marktkräfte (etwa eine unerwartete Verbesserung der Sicherheit des Microsoft-Browsers) reagieren, während eine Einzelperson weder über die Bandbreite noch über ausreichende Barreserven verfügt, um plötzlich die Richtung ihrer Karriere oder ihren Arbeitsschwerpunkt zu ändern.

Merksatz Anbieter-zentrierte Betrachtungsweisen sind normalerweise kurzsichtig.

Das Traurige bei einer Anbieter-zentrierten Betrachtungsweise der Welt ist, dass normalerweise die Details der Software-Implementierung des Anbieters ein Geschäftsgeheimnis sind. Sie können nur eine bestimmte Menge an Informationen über eine proprietäre Software bekommen, bis Sie an die Professional-Services-Barriere

stoßen

- ein künstliches Hindernis, das von einem Unternehmen zwischen Ihnen und der Lösung eines Ihrer Probleme aufgebaut wird, damit es damit Geld verdienen kann, Ihnen Support-Services zu verkaufen. Manchmal wird diese Barriere absichtlich errichtet, manchmal entsteht sie als Nebeneffekt des Versuchs des Unternehmens, sein intellektuelles Eigentum zu schützen (indem es seinen Sourcecode nicht veröffentlicht). Obwohl es grundsätzlich keine gute Idee ist, einseitig in eine bestimmte Technologie zu investieren, sollten Sie deshalb, falls es

Umsetzung

| 79

nicht anders geht, überlegen, ob Sie sich nicht auf eine Open-SourceLösung (im Gegensatz zu einer kommerziellen Lösung) konzentrieren sollten. Selbst wenn Sie die Open-Source-Lösung an Ihrem Arbeitsplatz nicht propagieren wollen oder können, sollten Sie die Open-Source-Option als Plattform betrachten, von der aus Sie tief in eine Technologie eintauchen können. Angenommen, Sie wollten Experte für die Arbeitsweise von J2EE-Anwendungsservern sein. Anstatt sich auf die Details zu konzentrieren, wie ein kommerzieller Anwendungsserver konfiguriert und deployt wird (schließlich kann jeder herausfinden, wie die Einstellungen in einer Config-Datei angepasst werden, nicht wahr?), sollten Sie sich einen Open-SourceServer wie JBoss oder Geronimo herunterladen und sich Zeit nehmen, um nicht nur die Bedienung dieses Servers zu erlernen, sondern auch seine interne Arbeitsweise zu studieren. Sie werden bald feststellen, dass sich Ihre Ansichten auf natürliche Weise ändern. Dieses J2EE-Ding (oder was auch immer Sie sich ausgeguckt haben) ist gar nicht so speziell. Das Studium der Implementierungsdetails zeigt Ihnen, dass J2EE einige allgemeine konzeptionelle Patterns einsetzt. Und Sie beginnen zu erkennen, dass eine verteilte Enterprise-Architektur, ganz unabhängig von Java oder irgendeiner anderen Sprache, eine verteilte Enterprise-Architektur ist. Ihr Blickwinkel weitet sich. Sie beginnen, großräumiger zu denken. Sie beginnen zu erkennen, dass diese Konzepte und Patterns, mit denen Sie sich geistig auseinandersetzen, sehr viel skalierbarer und universeller sind als die Technologie eines speziellen Anbieters. »Lass die Anbieter kommen und gehen - ich weiß, wie man ein System entwirft!«

Umsetzung 1. Realisieren Sie probeweise ein kleines Projekt, und zwar zweimal. Die eine Version sollte die von Ihnen standardmäßig eingesetzte Technologie verwenden; die andere sollte, so idiomatisch wie möglich, in einer konkurrierenden Technologie realisiert werden.

| KAPITEL I O

|

Lieben Sie es oder lassen Sie es

ielleicht hört es sich an wie die üblichen Cheerleader-Anfeuerungsrufe, die Sie in eine unnatürliche Begeisterung peitschen sollen, aber es ist zu wichtig, um nicht erwähnt zu werden: Sie müssen Leidenschaft für Ihre Arbeit entwickeln, wenn Sie Herausragendes leisten wollen. Wenn es Ihnen egal ist, merkt man dies Ihrer Arbeit an. Als meine Frau und ich nach Bangolore umzogen, war ich wirklich aufgeregt. Z u m ersten Mal in meiner Karriere freute ich mich darauf, auf gleichgesinnte Technologie-Freunde zu treffen, die mit mir die Leidenschaft für das Lernen teilten. Ich erwartete ein anregendes Leben nach der Arbeit, mit Treffen von Benutzergruppen und tiefsinnigen philosophischen Diskussionen über Methoden und Techniken der Software-Entwicklung. Ich erwartete, dass Indiens Silicon Valley wegen einer Überzahl von Software-Könnern aus allen Nähten platzte, die alle enthusiastisch danach strebten, die Kunst der Software-Entwicklung zu meistern. Was ich fand, war eine große Menge von Menschen, die ihre Gehaltsschecks einsteckten, und einige wenige unglaublich hingebungsvolle S oftware- Künstler. So wie zu Hause.

82

io - Lieben Sie es oder lassen Sie es

Natürlich erkannte ich damals nicht, dass alles wie zu Hause war. Ich wusste einiges über die Vereinigten Staaten, aber ich hatte immer angenommen, ich würde nur in schlechten Städten oder ungeeigneten Unternehmensumgebungen arbeiten. Ich betrachtete Situationen wie meine ersten Erfahrungen mit IT-Jobs als Ausnahmen. Die meisten Software-Entwickler müssen es begriffen haben, dachte ich. Ich hatte nur noch nicht die richtige Umgebung gefunden. Ich begann in der IT-Abteilung einer Universität aufgrund einer leichtfertigen Empfehlung meines Freundes Walter, der mich oft genug bei meiner Arbeit mit Computern gesehen hatte, u m zu beurteilen, dass ich ihnen wahrscheinlich helfen konnte, ihre Aufgaben besser zu erledigen als die meisten, die an der Universität Hilfe brauchten. Ich glaubte nicht, dass ich das könnte, da ich keine formale Ausbildung hatte. Ich war nur ein Saxophonspieler, der gerne Videospiele spielte. Doch Walter füllte für mich ein Anmeldeformular aus und verabredete einen Interviewtermin. Ich wurde eingestellt, ohne dass eine einzige technische Frage gestellt wurde, und ich sollte sofort anfangen. Als ich meine Arbeit antrat, war ich von dem paranoiden Gefühl besessen, dass ich als der Scharlatan entlarvt wurde, der ich wirklich war. Was hat dieser Saxophonspieler hier mit uns ausgebildeten Profis zu schaffen? Schließlich arbeitete ich mit Leuten zusammen, die fortgeschrittene Abschlüsse in Informatik vorweisen konnten. Und hier war ich mit meinem abgebrochenen Musik-Studium und versuchte, mich in das Team einzugliedern, als ob ich irgendetwas wüsste. Während der ersten Arbeitstage dämmerte mir die Wahrheit. Diese Leute hatten keinen blassen Schimmer, was sie eigentlich taten! Tatsächlich beobachteten mich einige von ihnen bei der Arbeit und machten sich Notizenl Leute mit Diplomen in Informatik! Meine erste Reaktion bestand darin anzunehmen, ich wäre von Idioten umgeben. Schließlich hatte ich keine formale Ausbildung. Ich verbrachte meine Abende damit, in Bars und einer Band Musik zu machen, und meine Tage damit, Computerspiele zu spielen. Ich

83io-Lieben Sie es oder lassen Sie es

hatte gelernt, mit Computern umzugehen, einfach weil ich mich für sie interessierte. Tatsächlich lernte ich wirklich, wie man Programme schreibt, weil ich meine eigenen Computerspiele entwickeln wollte. Normalerweise kam ich abends nach einem betäubenden Auftritt in einer Bar spät nach Hause und besuchte GopherSites mit Tutorials über das Programmieren, bis die Sonne aufging. (Gopher war ein System für den Austausch von Dokumenten. Es diente einem ähnlichen Zweck wie das World Wide Web. Allerdings ließ seine Beliebtheit erheblich nach, als sich das Web durchsetzte.) Dann ging ich schlafen, wachte auf und lernte weiter, bis ich das Haus zu einem Gig verlassen musste. Ich unterbrach das Studium meiner geliebten Computerspiele zum Essen und kehrte danach zu Gopher und den Compilern zurück, die ich ans Laufen bringen konnte.

Merksatz Arbeiten Sie, weil Sie nicht nicht arbeiten könnten.

Rückblickend war ich süchtig, aber in einer positiven Weise. Mein Drang, etwas zu schaffen, war in derselben Weise angefacht worden wie zu der Zeit, als ich begann, klassische Musik zu schreiben oder )azz-Improvisationen zu spielen. Ich war davon besessen, alles und jedes zu lernen, was mir unterkam. Ich machte dies nicht wegen einer neuen Karriere. Tatsächlich betrachteten viele meiner Freunde aus der Musikszene mein Verhalten als eine unverantwortliche Ablenkung von meiner tatsächlichen Karriere. Ich befasse mich damit, weil ich es nicht nicht hätte tun können. Dies war der Unterschied zwischen mir und meinen überausgebildeten, unterdurchschnittlich performanten Arbeitskollegen. Leidenschaft. Diese Leute wussten einfach nicht, warum sie in der IT-Branche arbeiteten. Sie waren in ihre Karrieren hineingestolpert, weil sie

85

85 i o - Lieben Sie es oder lassen Sie es

dachten, Computerprogrammierung würde gut bezahlt werden, weil ihre Eltern sie dazu ermutigt hatten oder weil ihnen nichts Besseres eingefallen war. Leider spiegelte ihre Performance bei der Arbeit diese Einstellung wider. Wenn Sie Biografien oder Dokumentationen über die herausragenden Persönlichkeiten verschiedener Fachgebiete lesen oder sehen, schält sich immer wieder dasselbe Muster von Sucht und leidenschaftlichem Verhalten heraus. Der legendäre Jazz-Saxophonist John Coltrane soll so viel geübt haben, dass seine Lippen bluteten. Natürlich spielt angeborenes Talent eine große Rolle bei der Entwicklung von Fähigkeiten. Nicht jeder kann ein Mozart oder ein Coltrane sein. Aber alle können das Mittelmaß weit hinter sich lassen, wenn sie die Arbeit finden, bei der ihre Leidenschaft entfacht wird. Es kann sich um eine Technologie oder ein Geschäftsfeld handeln. Umgekehrt

kann

auch

eine

spezielle Technologie

oder

ein

Geschäftsfeld Ihre Fähigkeiten blockieren. Gleiches gilt für eine bestimmte Art von Organisation. Vielleicht passen Sie besser in kleine oder in große Teams. Vielleicht schätzen Sie rigide Prozesse mehr als agile oder umgekehrt. Doch was immer die Mischung ausmacht: Nehmen Sie sich die Zeit, die zu Ihnen passende Mischung zu finden. Eine Weile können Sie so tun, als ob. Doch der Mangel an Leidenschaft wird Sie und Ihre Arbeit immer einholen.

Umsetzung 1. Suchen Sie sich eine Arbeit, die Sie leidenschaftlich gerne tun wollen. 2. Führen Sie ab nächstem Montag zwei Wochen lang ein einfaches Protokoll. Notieren Sie an jedem Arbeitstag, wenn Sie aufwachen, den Grad Ihrer Erwartung auf einer Skala von i bis io. Der Wert i bedeutet, Sie würden sich lieber wieder mit einer Krankheit ins Bett legen, als zur Arbeit zu gehen; und io bedeutet, Sie können es kaum im Bett aushalten, weil Sie so von der Idee besessen sind, Ihre nächste Aufgabe zu erledigen.

Nachdem Sie dieses Protokoll zwei Wochen lang geführt haben, schauen Sie sich die Ergebnisse an. Gab es Spitzen? Gab es Trends? Waren alle Werte niedrig oder alle hoch? Was wäre Ihr Durchschnittsgrad, wenn dies ein Test gewesen wäre? Planen Sie in den folgenden zwei Wochen jeden Morgen, wie Sie aus dem jeweils folgenden Tag eine 10 machen werden. Planen Sie, was Sie heute tun werden, damit morgen einer dieser Arbeitstage ist, den Sie kaum erwarten können. Protokollieren Sie an jedem Tag den Grad Ihrer Erwartung von gestern. Wenn die Dinge nach zwei Wochen traurig aussehen, könnte es Zeit sein, eine größere Änderung ins Auge zu fassen.

Ein serieller Opportunist sein von James Duncan Davidson Ich habe nicht viel von dem vorzuweisen, was viele als einen traditionellen Karriereweg bezeichnen würden. Stattdessen bestand mein Weg hauptsächlich darin, Gelegenheiten zu folgen, die sich mir präsentierten. Die erste dieser Gelegenheiten präsentierte sich mir, als ich an der Uni für einen Abschluss an Architektur arbeitete. Ich hatte im Alter von 15 oder 16 beschlossen, dass ich Architekt werden wollte; und ich hatte sehr viel Zeit in diese Zukunft investiert. Aber die Samenkörner meiner tatsächlichen späteren Karriere nach der Uni waren schon durch meine früher Faszination mit Online-PBS-Systemen ausgesät worden. Ich gehörte zu den Kids, die das 300Baud-Modem im Familien-PC liebten. Dies brachte mich schließlich zum Internet, das mich erst zu Gopher und dann zum World Wide Web führte. Das Web nahm mich sofort gefangen. Ich erstellte schnell hintereinander mehrere persönliche Websites und nutzte dabei jede verfügbare Technologie. Alles, was ich brauchte, brachte ich mir selber bei. Damals betrachtete ich diese Arbeit

86

i o - Lieben Sie es oder lassen Sie es

als Experimente für die Schaffung einer Cyber-Architektur. Das hört sich heute vielleicht zu grandios und sogar spinnert an, aber es war die Welt, in der diefrühen Nutzer des Webs lebten. Wir versuchten uns vorzustellen, was die Zukunft bringen könnte. Natürlich wurde die eigentliche Arbeit an der Zukunft des Internets nicht in Architektur-Labors, sondern in der Geschäftswelt geleistet. Weil ich mit meiner öffentlichen Website etwas vorweisen konnte, wurde ich bald darauf von einem Startup-Unternehmen kontaktiert, das Websites für Unternehmen wie Hilton oder Behörden wie das Better Business Bureau entwickelte. Man hatte meine Websites gesehen, und offensichtlich verfügte ich genau über den Satz von Fähigkeiten, den man benötigte. Mir wurde ein Job mit einem Gehalt angeboten, das damals lächerlich hoch zu sein schien. Ich nahm den Job an, weil ich dachte, dass ich eine Weile lang auf der Welle reiten, etwas Geld sparen und in einigen Jahren an die Uni zurückkehren könnte. Es war 1995. Ich hatte keine Ahnung, wohin die Reise gehen und wie weit mich meine Bereitschaft tragen würde, mich auf etwas Neues einzulassen. Während ich daran mitarbeitete, die erste Version der HiltonWebsite mit einer Echtzeitreservierungsfunktion zu entwickeln, lernte ich, wie man Websites mit einer Reihe serverseitiger Technologien erstellt. In wenigen Monaten entwickelte ich mich vom Lehrling zu einem Entwickler eines eigenen serverseitigen Frameworks. Im Rückblick scheint das lächerlich zu sein, aber damals war es notwendig. Ich sah eine Lücke, packte die Gelegenheit beim Schopf und nutzte sie, so weit es ging, wobei ich mich den Anforderungen entsprechend selbst neu erfand.

Umsetzung

Eins führte zum anderen. 1 9 9 7 ging ich zu JavaSoft, um an serverseitiger Software zu arbeiten. Und nach einigen Jahren war ich für die Servlet-Spezifikation verantwortlich. Leider war dieses Unterfangen finanziell zu schlecht ausgestattet. Ich hatte kein Team, das mir helfen konnte, alle erforderlichen Aufgaben zu erledigen und eine neue Referenz-Implementation zu erstellen. Doch ich ließ mich davon nicht aufhalten und machte mich daran, von Grund auf eine vollkommen neue Implementierung der Software zu entwickeln, die später als JavaServer Web Development Kit veröffentlicht wurde. Es gibt nicht viele, die sich an diese Software erinnern. Aber die meisten Entwickler, die serverseitig mit Java arbeiten, kennen die nächste Version dieses Codes unter dem Namen Tomcat. Sie wurde von der Apache Software Foundation mit einem Ableger namens Ant veröffentlicht. Die Geschichte hinter dieser Veröffentlichung würde ein Buch füllen. Doch es reicht zu sagen, dass alles dies durch einen perfekten Satz von Gelegenheiten passierte, die ich ausnutzen konnte. Nachdem ich vier Jahre lang für Sun gearbeitet hatte und vor der Frage stand, was ich als Nächstes tun sollte, beschloss ich, selbstständig zu werden. Ich schrieb Bücher für O'Reilly. Ich entwickelte Software für den Mac. Ich entwickelte ziemlich viel Software für mich, die niemals veröffentlicht wurde. Und ich beteilige mich schließlich ein wenig an der Entwicklung von Ruby on Rails. Ein unabhängiger Software-Entwickler zu sein, war gut für mich; und ich war ziemlich gut darin. Doch daneben wuchs sich eines meiner Hobbys zu einer eigenen Karriere aus. Ich war nicht nur ein Architekturstudent, aus dem ein Software-Entwickler wurde, sondern auch ein leidenschaftlicher Fotograf. Meine Großmutter brachte mir die Grundlagen bei.

| 87

88

i o - Lieben Sie es oder lassen Sie es

Meine Eltern ermutigten mich. Und solange ich mich erinnern kann, hatte ich immer eine Kamera dabei. Fotografieren spielte in meinem Leben eine große Rolle. Tatsächlich war die nicht veröffentlichte Software, die ich für mich schrieb, nachdem ich Sun verlassen hatte, dazu bestimmt, mit Fotos zu arbeiten. 2005, zehn Jahre, nachdem ich mein Architekturstudium aufgegeben und mich der Software-Entwicklung zugewendet hatte, erhielt ich einen Anruf von meinen Freunden aus der O'Reilly Conferences Group. Sie brauchten jemanden, der ihre Events dokumentierte, und fragten mich, ob ich interessiert sei, zu ihnen zu stoßen und einige Aufnahmen zu machen. Ich nahm an; doch anstatt nur einige Fotos zu schießen, machte ich mehr, als von mir erwartet wurde. Ich verfiel in ein Arbeitsfieber und arbeitete mich durch alle wichtigen Sitzungen. Die Bilder veröffentlichte ich dann bei Flickr, um so ein außerordentlich schnelles Turnaround zu schaffen. Ich wurde wieder eingeladen; und in den letzten Jahren habe ich daraus ein separates Geschäft mit zahlreichen neuen Kunden gemacht. Während ich dies schreibe, programmiere ich immer noch ab und zu. Ich habe sogar für einige Kunden etwas Software geschrieben. Doch meistens arbeite ich heute als Vollzeit-Fotograf. Doch das könnte sich ändern. Man weiß nie. Es ist schwer zu sagen, was die Zukunft bringen wird. Doch was ich sagen kann, ist, dass ich ein serieller Opportunist bin. Wenn ich etwas sehe, das mich interessiert und aufregt, packe ich zu und tue alles, was erforderlich ist, um damit Erfolg zu haben. Normalerweise bedeutet das, dass ich mir neue Kenntnisse und Fähigkeiten aneignen muss. Für einige ist der Erwerb neuer Fähigkeiten etwas Mühsames, aber aus irgendeinem Grund liebe ich es, Neues zu meistern. Schließlich kann man mit neuen Fähigkeiten auch neue Dinge tun. Und ich habe

Umsetzung

mich nie über meine Fähigkeiten definiert. Stattdessen habe ich mich immer dadurch definiert, was ich getan habe und was ich als Nächstes tun möchte. Fähigkeiten sind nur ein Mittel dazu, dieses Ziel zu erreichen. James Duncan Davidson ist Programmierer und Fotograf.

| 89

Teil 2

Investieren Sie in Ihr Produkt

Ich gebe nicht an, wenn ich sage, dass ich ein begabter Saxophonist bin. Sie müssen mir für einen Moment vertrauen, während ich erkläre, dass dies ein Hemmschuh ist. Als Saxophonspielen für mich eine Vollzeitbeschäftigung war, spielte ich sehr viel. Manchmal hatte ich zwei oder drei Gigs pro Tag, wenn ich wirklich beschäftigt war. Dann spielte ich an einem Tag Jazz zum Brunch, Tanzmusik bei einer Abendhochzeit und Rhythm and Blues in einer Nachtbar. Und da mir das Saxophon lag, verbesserte sich mein Können, und ich lernte bei meiner Arbeit. Ich traf den Ton besonders gut und hatte eine natürliche Fähigkeit, Songs durch Hören zu lernen sowie zu improvisieren. Aber ich investierte niemals wirklich in mein Können als Saxophonist. Die Dinge flogen mir so leicht zu, dass ich annahm, zufrieden sein zu können. Außerdem kam ich normalerweise mit den anderen Band-Mitgliedern gut zurecht, so dass ich auch keinen großen Druck von meinen Mitspielern bekam. Ich erkannte es nicht, aber ich glitt langsam in einen Zustand der Stagnation. Während ich in jungen Jahren schnelle Fortschritte

machte, desto mehr hörte sich mein Sound immer gleich an, je mehr R&B-Gigs ich spielte. Meine improvisierten Solos waren eine ewige Wiederholung der Dinge, die ich jeweils am Abend vorher oder sogar früher am selben Abend gespielt hatte. Rückblickend muss ich sagen, dass dies nicht nur für mich, sondern für die gesamte professionelle Musikszene um mich herum galt. Wir steckten uns keine neuen Ziele, und auch das Publikum stellte definitiv keine besonderen Ansprüche an uns (haben Sie je gesehen, dass ein Publikum geklatscht und in Begeisterung ausgebrochen ist, weil ein Saxophonist eine Note für mehr als 30 Sekunden gehalten hat?). Bis vor Kurzem ließ ich mich mehrere Jahre lang von meiner Arbeit so in Anspruch nehmen, dass ich der Musik überhaupt keine Prioritäten mehr einräumte. Dies führte zu einer langen Periode, in der ich mein Saxophon und meine Gitarren vollkommen ignorierte. Ich erkannte, dass ich den Einfluss der Musik auf mein Leben vermisste, und nahm vor Kurzem das Spiel beider Instrumente ernsthaft wieder auf. Diesmal habe ich keine ortsansässigen Musikfreunde. Ich habe keine Zeit, beruflich zu spielen; und ich habe auch nicht mehr die Fertigkeit, gut genug zu spielen. Deswegen spiele ich nur für mich selbst. Vielleicht liegt das daran, dass sich jetzt älter bin. Oder auch klüger, obwohl ich das bezweifle. Doch diesmal habe ich entdeckt, dass man mit einer kleinen Investition sehr weit kommen kann. Anstatt nur die Instrumente auszupacken und mich zu einem Gig aufzumachen, habe ich (notwendigerweise) allein gespielt. Dies hat mich dazu gebracht, dass ich mich nicht mehr auf meine Instrumente konzentriere. Ich habe mir Musik angehört und mir eine Liste der Techniken angelegt, die ich lernen möchte. Beispielsweise wollte ich eine bestimmte Sache tun können, die Phil Woods immer bei seinen Alt-Saxophon-Solos spielt. Oder ich wollte lernen, wie Prince seine Gitarre in der Art zum Schreien bringt, die er am Ende von »Let's Go Crazy« auf seinem Album Purple Rain demonstriert.

Es zeigte sich, dass ich mir diese Fähigkeiten, die ich schon immer haben wollte, durch einige Stunden der Investition, kombiniert mit meinem natürlichen Talent, aneignen konnte. Und dieser Prozess, Zeit in meine Fähigkeiten zu investieren, verstärkt sich selbst. Eine Technik führt zur nächsten, und eine Übungssitzung, mit der ich eine Barriere wegräume, macht den Weg frei zur nächsten. Nach einigen Monaten konzentrierter Übung spielte ich in vieler Hinsicht besser als jemals zuvor, selbst zu der Zeit, als ich beruflich spielte. Das strukturierte Ich, das in seine Fähigkeiten investiert (und sei es auch nur als Hobby), schlägt das naive Ich um Längen, das ganz auf sein natürliches Talent und seine Fähigkeiten setzt. Dies ist ein Beweis dafür, dass Sie, wenn Sie ein herausragendes Produkt auf dem Arbeitsmarkt anbieten wollen - ein Produkt, das herausragt und mit dem Sie wirklich konkurrenzfähig sind - , in dieses Produkt investieren müssen. Im Geschäftsleben sind Ideen und sogar Talent Dutzendware. Es sind Blut, Schweiß, Tränen und Geld, die Sie in ein Produkt stecken, die ihm wirklichen Wert verleihen. In diesem Teil werden Investitionsstrategien für Ihre Karriere behandelt. Wir untersuchen, wie Sie die Fähigkeiten und Technologien auswählen, in die Sie investieren sollten, und behandeln verschiedene Methoden, wie man in sich selbst investieren kann. In diesem Teil beginnt die eigentliche Arbeit.

Lernen Sie zu fischen

ao Tse sagte: »Wenn du einem Mann einen Fisch gibst,

L

ernährst du ihn für einen Tag. Wenn du einen Mann zu fischen lehrst, ernährst du ihn sein ganzes Leben lang.«

Schön und gut. Doch Lao Tse ließ den Teil aus, in dem der Mann nicht fischen lernen will, sondern Sie morgen um einen weiteren Fisch bittet. Ausbildung erfordert sowohl einen Lehrer als auch

einen Schüler. Viele zögern allzu oft, Schüler zu sein.

Merksatz Warten Sie nicht, bis Ihnen etwas gesagt wird. Fragen Sie!

Was entspricht dem Fisch in der Software-Branche? Es ist der Prozess, ein Tool oder einen technologischen Aspekt oder eine spezielle Information aus dem Geschäftsbereich anzuwenden, in dem Sie arbeiten. Es ist das Können, einen speziellen Zweig aus dem Source Control System Ihres Teams auszuchecken oder einen Anwendungsserver zu installieren und für die Entwicklung einzurichten. Viele betrachten diese Details als gegeben. Vielleicht denken Sie, jemand anderer könne diese Dinge für Sie erledigen. Der für den lUiild Zuständige kennt das Source Control System. Sie bitten ihn

9

6

i i - Lernen Sie zu fischen

bei Bedarf einfach, die Dinge für Sie einzurichten. Das Infrastruktur-Team weiß, wie man die Firewalls zwischen Ihnen und Ihren Kunden einrichtet. Wenn Sie ein Anwendungsproblem haben, senden Sie deshalb einfach eine E-Mail; das Team wird dann das Problem richten. Wer möchte von der Gnade eines anderen abhängen? Oder schlimmer: Wenn Sie jemanden für einen Job einstellen sollten, können Sie dann wollen, dass diese Person von der Gnade der Experten abhinge? Ich wäre damit nicht zufrieden. Ich würde jemanden einstellen wollen, der aus eigener Kraft zurechtkommt. Offensichtlich sollten Sie zunächst Ihr Handwerkszeug gründlich beherrschen lernen. Beispielsweise ist Source Control ein leistungsstarkes Tool. Ein wichtiger Aspekt seiner Funktion besteht darin, die Produktivität von Entwicklern zu vergrößern. Es ist nicht nur der Ort, an dem Sie Ihren bearbeiteten Code speichern. Deshalb sollten Sie es auch nicht so behandeln. Es ist ein integraler Bestandteil Ihres Entwicklungsprozesses. Lassen Sie es nicht zu, dass eine derart wichtige Komponente - der maßgebliche Speicherort Ihrer Arbeit - für Sie ein Buch mit sieben Siegeln bleibt. Ein eigenständiger Entwickler kann leicht die Unterschiede zwischen der zuletzt ausgecheckten Version eines Projektes und seiner letzten guten Version im Repository prüfen. Oder vielleicht müssen Sie den letzten veröffentlichten Code auschecken, u m einen Fehler zu korrigieren. Wenn mitten in der Nacht in Ihrem Code ein kritischer Fehler auftaucht, wollen Sie nicht jemand anderen anrufen müssen, um zu fragen, wie man die richtige Version auscheckt, damit Sie den Fehler beseitigen können. Dasselbe gilt für IDEs, Betriebssysteme und so gut wie jede andere Komponente der Infrastruktur, von der der Code und Ihre Prozesse abhängen. Genauso wichtig ist die technologische Plattform, auf der Sie Ihre Software einsetzen. Angenommen, Sie entwickelten Anwendungen mit J2EE. Sie wissen, dass Sie verschiedene Klassen, Interfaces und Deployment-Deskriptoren erstellen müssen. Wissen Sie, warum?

Lernen Sie zu fischen

97

Wissen Sie, wozu diese Dinge benutzt werden? Was genau passiert, wenn Sie einen j2EE-Container starten? Auch wenn Sie vielleicht keinen Anwendungsserver entwickeln, hilft es Ihnen, robusteren Code für eine Plattform zu entwickeln und etwaige Fehler schneller zu beheben, wenn Sie diese Dinge kennen. Eine spezielle Art, bequem zu werden, ist der Einsatz verschiedener Assistenten, die für Sie Code generieren. Dies ist besonders in der Welt der Windows-Entwicklung verbreitet, in der die Entwicklungstools, dank Microsoft, zahlreiche Aufgaben wirklich leicht machen. Der Nachteil ist, dass viele Windows-Entwickler keine Ahnung haben, wie ihr Code wirklich funktioniert. Die Arbeit der Assistenten bleibt ein magisches Geheimnis. Verstehen Sie mich nicht falsch: Code zu generieren, kann, korrekt eingesetzt, ein nützliches Tool sein. Beispielsweise sind Codegeneratoren dafür zuständig, high-Level C#-Code in Bytecode zu übersetzen, der auf dem .NET Runtime ausgeführt werden kann. Offensichtlich möchte niemand diesen Bytecode selbst schreiben. Doch besonders auf den abstrakteren Ebenen führt der Einsatz von Assistenten dazu, dass Ihr Wissen flach und Ihr Können auf das beschränkt bleibt, was die Assistenten bereits für Sie erledigen können. Es ist leicht, den Fisch in seinem Geschäftsbereich zu übersehen. Wenn Sie für ein Unternehmen arbeiten, das Hypothekendarlehen vergibt, können Sie für ein Szenario entweder einen Experten bitten, den Zinssatz zu berechnen, den Sie zum Testen benötigen, oder Sie können lernen, ihn selbst zu berechnen. Obwohl Interaktionen mit Kunden etwas Gutes sind und es nützlich ist, Geschäftsanforderungen mit ihnen abzuklären (im Gegensatz dazu, sich mit einem halben Verständnis zufriedenzugeben und die Details selbst zu ergänzen), stellen Sie sich vor, wie viel schneller Sie vorankämen, wenn Sie den Geschäftsbereich, in dem Sie arbeiten, gründlich kennen würden. Wahrscheinlich müssen Sie nicht jede einzelne Geschäftsregel kennen; dies ist nicht Ihre Aufgabe. Aber Sie können sich wenigstens die Grundlagen aneignen. Viele der besten Soft-

9

ii - Lernen Sie zu fischen

8

ware-Entwickler, mit denen ich im Laufe der Jahre gearbeitet habe, haben sich in ihren Geschäftsbereichen zu besseren Experten entwickelt als einige ihrer besten Kunden. Dies führt zu besseren Produkten. Jemand, der den Geschäftsbereich nicht kennt, lässt dumme Fehler durchgehen, die bei einem rudimentären Verständnis des Geschäftsbereiches hätten vermieden werden können. Darüber hinaus kommt er langsamer voran (und verursacht deshalb letztlich höhere Kosten) als ein gleichwertiger Entwickler, der das Geschäft versteht. Für uns Software-Entwickler könnten wir den Ausspruch von Lao Tse vielleicht wie folgt umformulieren: »Bitte um einen Fisch, iss für einen Tag. Bitte jemanden, dich fischen zu lehren, iss dein Leben lang.« Noch besser: Bitte nicht, unterrichtet zu werden - lerne selbst!

Umsetzung i.

Wie und warum? - Entweder lassen Sie diese Erkenntnis an sich vorbeirauschen oder Sie fragen sich beim nächsten Mal bei Ihrer Arbeit, welche ihrer Aspekte Sie vielleicht nicht gründlich verstehen. Sie können sich bei jedem Aspekt zwei außerordentlich nützliche Fragen stellen, um die unklaren Bereiche aufzudecken: Wie funktioniert das? und Warum passiert das oder warum muss dies passieren? Vielleicht können Sie die Fragen gar nicht beantworten, aber allein die Tatsache, dass Sie sie stellen, verändert Ihren Blickwinkel und sorgt dafür, dass Sie Ihre Arbeitsumgebung mit einem klaren Bewusstsein betrachten. Wie leitet der IIS-Server Anfragen an meine ASP.NET-Seiten weiter? Warum muss ich diese Interfaces und Deployment-Deskriptoren für meine EJB-Anwendung generieren? Wie geht mein Compiler mit dynamischem im Gegensatz zu statischem Linking um? Warum berechnen wir Steuern anders, wenn ein Käufer in Montana wohnt?

| 99

Umsetzung

Natürlich führen die Antworten auf diese Fragen dazu, die Fragen erneut zu stellen. Wenn Sie in dem Wie-und- Warum- Baum nicht mehr tiefer gehen können, sind Sie wahrscheinlich weit genug gegangen. 2. Zeit für einen Tipp: Beschäftigen Sie sich mit einem der wichtigsten Tools aus Ihrer Toolbox, das Sie bisher vernachlässigt haben: Ihr Versionskontrollsystem; eine Bibliothek, die Sie extensiv nutzen, sich aber nur oberflächlich angeschaut haben; oder den Editor, den Sie beim Programmieren benutzen. Wenn Sie das Tool ausgewählt haben, reservieren Sie jeden Tag eine kurze Zeitspanne, um einen neuen Aspekt des Tools kennen zu lernen, der Sie produktiver macht oder Ihnen mehr Kontrolle über Ihre Entwicklungsumgebung verschafft. Angenommen, Sie hätten sich vorgenommen, die G N U Bourn Again Shell (bash) zu meistern. Wenn Ihre Aufmerksamkeit nachlässt und Ihr Geist von der anstehenden Aufgabe abwandert, könnten Sie, anstatt Slashdot zu laden, im Internet nach bash tips suchen. Innerhalb von einer oder zwei Minuten sollten Sie etwas Nützliches über die Anwendung der Shell finden, das Sie noch nicht kannten. Natürlich können Sie ihn jetzt, da Sie einen neuen Trick kennen gelernt haben, mit einer Reihe von Warum-Fragen näher analysieren.

Wie-und-

| KAPITEL!2 |

Lernen Sie, wie Unternehmen wirklich funktionieren

m vorigen Kapitel wurde betont, wie wichtig es ist, dass Sie Ihren Geschäftsbereich bewusst auswählen. Vorhandene Kenntnisse des Geschäftsbereichs können dazu beitragen, Arbeit zu finden, fehlende Kenntnisse können dazu führen, einen angebotenen Job nicht zu bekommen. Deshalb sollten Sie Bereichswissen nicht auf die leichte Schulter nehmen. Bevor Sie Ihre Zeit investieren, einen Geschäftsbereich gründlich kennen zu lernen, sollten Sie prüfen, ob dieser für Sie und den gegenwärtigen Marktzustand geeignet ist. Doch es gibt einen Wissensbereich, der weder technisch noch bereichsspezifisch ist und der kaum in näherer Zukunft überholt sein wird: betriebswirtschaftliche Grundkenntnisse.

Unabhängig

von Ihrer Branche (Produktion, Gesundheitsfürsorge, Nonprofit, Bildung) handelt es sich immer um Wirtschaftsbetriebe. Und Wirtschaft ist selbst ein Wissensbereich, den man lernen kann und lernen muss. Ich erinnere mich an ein Mitarbeiter-Meeting, das ich als junger Programmierer besuchte und bei dem meine Augen glasig wurden, als irgendein Topmanager, mit dem ich nie direkt zu tun haben würde, ein Chart mit Zahlen nach dem anderen präsentierte, die meines Erachtens für mich vollkommen irrelevant waren. Ich bedauerte mich selbst. Ich wollte einfach raus aus dem Meeting und

102

12 - Lernen Sie, wie Unternehmen wirklich funktionieren

die Anwendungsfunktion beenden, an der ich gerade arbeitete. Meine Team-Kollegen sahen aus wie eine Schar zappliger Kinder auf einer langen Autofahrt. Keiner von uns verstand, was präsentiert wurde, und allen war's egal. Wir hielten das Ganze für eine absolute Zeitverschwendung des inkompetenten Managers, der das Meeting einberufen hatte.

Merksatz Sie können einem Unternehmen nur dann kreativ helfen, wenn Sie wissen, wie es funktioniert.

Rückblickend halte ich uns für ziemlich dumm. Wir arbeiteten für ein Unternehmen und unsere Aufgabe bestand darin, diesem Unternehmen zu helfen, entweder Geld zu verdienen oder Kosten zu sparen. Dennoch hatten wir nicht die leiseste Ahnung davon, wie dieses Unternehmen seine Gewinne erzielte. Noch schlimmer: Wir kamen nicht einmal auf die Idee, dass es unsere Aufgabe sein könnte, dies zu wissen. Wir waren Programmierer und Systemadministratoren. Wir dachten, unsere Aufgaben wären strikt auf die Themen beschränkt, denen wir uns zugewandt hatten. Doch wie sollten wir dem Unternehmen kreativ helfen können, Gewinne zu erzielen, wenn wir nicht einmal wussten, wie es funktionierte? Im vorigen Absatz ist das Wort Kreativität der Schlüssel. Es ist verständlich, die Ansicht zu vertreten, dass wir tatsächlich IT-Spezialisten sind und genau dafür bezahlt werden. Wenn wir die richtigen Projekte erhalten und richtig gemanagt werden, sollten wir unsere Arbeit in Aufgaben stecken können, die dem Unternehmen helfen. Wir müssen nicht komplett verstehen, wie das Geschäft funktioniert, um einen Mehrwert beizutragen. Doch

um

kreativ

Mehrwert

zu

schaffen, müssen

Sie

Ihre

Geschäftsumgebung gründlicher verstehen. In der Geschäftswelt wird immer wieder der Ausdruck Nettoprofit (engl, bottom line; dt.

Umsetzung

unterm Strich) verwendet. Wie viele von uns wissen wirklich, was der Nettoprofit ist und wie er zustande kommt? Noch wichtiger: Wie viele von uns wissen, wie wir zu dem Nettoprofit beitragen? Ist Ihre Organisation eine Kostenstelle oder ein Profitcenter (trägt es zu den Kosten oder zum Gewinn bei) ? Wenn Sie die finanziellen Triebkräfte (und die Sprache) Ihres Unternehmens kennen, können Sie sinnvolle Änderungen durchführen, anstatt im Nebel nach Dingen zu stochern, die Sie intuitiv für richtig halten.

Umsetzung 1. Besorgen Sie sich ein Buch über Betriebswirtschaft und arbeiten Sie es durch. Geeignete Titel finden Sie unter den Einführungsbüchern für einen MBA-Abschluss (Master of Business Administration). Besonders geeignet (und angenehm kurz) ist meines Erachtens The Ten-Day-MBA

[SÜ99; nur in Englisch]. Sie kön-

nen es tatsächlich in zehn Tagen durcharbeiten. Diese Investition ist nicht sehr groß. 2. Bitten Sie jemanden aus Ihrem Unternehmen oder Ihrem Geschäftsbereich, Ihnen die finanziellen Grundlagen des Unternehmens zu erklären (falls das Unternehmen bereit ist, diese Informationen an seine Mitarbeiter weiterzugeben). 3. Wiederholen Sie die Erklärung. 4. Finden Sie heraus, warum der Nettoprofit als Nettoprofit (das, was unterm Strich steht) bezeichnet wird.

Suchen Sie sich einen Mentor

ines beherrscht die Jazzmusik-Kultur wirklich perfekt: die

E

Kunst der Mentorenschaft. In der Jazzwelt suchen sich junge

Musiker üblicherweise erfahrenere Musiker, die sie unter ihre

Fittiche nehmen und ihre Linie der Jazz-Tradition weitergeben. Doch das ist nicht alles. Diese älteren Musiker dienen oft als Karri-

ere* und Lebensberater sowie als Resonanzboden. Im Gegenzug sind die jüngeren Musiker ohne Abstriche loyal und bauen um ihre Mentoren herum ein unterstützendes Netzwerk eingefleischter Fans auf. Über diese Netzwerke werden tagtäglich Verbindungen geknüpft und Spieler vermittelt. Die Gesellschaft der Jazz-Kultur hat eine sich selbst organisierende Kultur und einen Satz von Regeln für die Mentor-Schüler-Beziehung geschaffen. Das System funktioniert so gut, dass man annehmen könnte, es wäre von einer Art leitenden Organisation im Hintergrund gelenkt worden.

Merksatz Es ist in Ordnung, von jemandem abhängig zu sein. Sie müssen nur dafür sorgen, dass es die richtige Person ist.

13 - Suchen Sie sich einen Mentor

In der traditionellen Berufswelt (und insbesondere in der IT-Branche) ist es weniger üblich, sich gegenseitig um Hilfe zu bitten. Von anderen abzuhängen, wird oft als Schwäche ausgelegt. Wir haben Angst zuzugeben, dass wir nicht perfekt sind. Wettbewerb ist alles. Nur die Starken überleben, und all das. Leider führt dies zu einem extrem unterentwickelten System der Mentorenschaft. Wenn Sie eine Handvoll Jazz-Musiker fragen würden, wer ihr Mentor wäre, hätten die meisten eine Antwort. Doch stellen Sie dieselbe Frage Programmierern, würden Sie, zumindest in den USA, wahrscheinlich nur unverständliche Blicke ernten. Es war nicht immer so. In der Geschichte der westlichen Welt gab es ein blühendes System der professionellen Mentorenschaft, das bis ins Mittelalter zurückreichte. Berufliche Ausbildung wie das Erlernen eines Handwerks zu betrachten, war noch stärker und formeller ausgeprägt als das System, das sich in der Musikszene entwickelt hat. Junge Menschen begannen ihre berufliche Laufbahn als Lehrlinge bei anerkannten Handwerksmeistern. Sie tauschten ihre Arbeit gegen einen nominellen Lohn sowie das Privileg ein, von dem Meister zu lernen. Die Pflicht des Meisters bestand darin, die Lehrlinge darin auszubilden, Produkte in der Tradition (und der Qualität) des Meisters selbst herzustellen. Der erste und wichtigste Zweck eines Mentors ist der des Rollenmodells. Es ist schwer, sich vorzustellen, was möglich ist, solange man niemandem gesehen hat, der die Grenzen überschreiten kann, die man selbst für gegeben hält. Ein Rollenmodell definiert den Standard, was als »gut« gilt. Wenn Sie beispielsweise Schach spielen, halten Sie sich möglicherweise für ziemlich gut, wenn Sie die Leute in Ihrer Familie und unmittelbaren Umgebung schlagen können. Doch wenn Sie gegen einen Turnierspieler antreten, stellen Sie wahrscheinlich fest, das Schach ein viel tieferes Spiel ist, als Sie sich je vorgestellt haben. Und sollten Sie gegen einen Großmeister spielen, hätten Sie diese Erleuchtung ein zweites Mal. Doch wenn Sie weiter nur gegen Menschen aus Ihrer Familie und Umgebung gewinnen, haben Sie vielleicht das Gefühl, Sie wären wirklich gut

13-Suchen Sie sich einen Mentor

beim Schach. Doch ohne Rollenmodell hätten Sie keinen Anreiz, besser zu werden. Ein Mentor strukturiert auch Ihren Lernprozess. Im vorigen Kapitel wurde Ihnen eine überwältigende Anzahl von Optionen, Technologien und Geschäftsbereichen vorgestellt, in die Sie Ihre Zeit investieren können. Manchmal verleitet eine zu umfangreiche Auswahl dazu, gar nichts zu tun. In vernünftigem Maße ist es besser, sich in eine Richtung zu bewegen, als still sitzen zu bleiben. Ein Mentor kann Ihnen helfen auszuwählen, worauf Sie Ihre Energien konzentrieren sollten. Als ich meine Karriere als System-Support-Mitarbeiter begann, hielt ich mich an einen Heiligen namens Ken, der zu den Administratoren unseres Universitätsnetzwerks gehörte. Er half mir bei der Lösung eines großen Problems mit unserem NetWare-CampusNetzwerk. Das Problem hinderte Studenten daran, unsere Computer-Labore zu benutzen. Danach konnte mich Ken nicht mehr abschütteln (was er auch gar nicht versuchte). Als ich ihn bat, mir Hinweise zu geben, wie ich meine Kenntnisse erweitern und eigenständiger werden könnte, gab er mir ein einfaches Rezept: Mache dich mit den Verzeichnisdiensten vertraut, arbeite dich in eine Unix-Variante ein und meistere eine Skriptsprache. Aus der unendlichen Anzahl möglicher Fähigkeiten wählte er drei raus, die ich lernen sollte. Und mit demselben Selbstvertrauen, mit der diese Person, die für mich ein Meister war, diese Fähigkeiten ausgewählt hatte, machte ich mich daran, mir diese drei Fähigkeiten anzueignen. Seitdem habe ich meine Karriere auf diesen drei Wissensgebieten aufgebaut, die immer noch bei allen meinen Tätigkeiten nichts an Bedeutung verloren haben. Das liegt nicht daran, dass die Richtungsvorgabe von Ken die absolut richtige Antwort war denn absolut richtige Antworten gibt es nicht. Das Wichtige daran war, dass er die lange Liste möglicher Fähigkeiten, die ich hätte lernen können, auf eine kurze Liste von Fähigkeiten reduzierte, die ich tatsächlich lernte.

13 - Suchen Sie sich einen Mentor

Ein Mentor dient auch als Vertrauensperson, die Ihre Entscheidungen und Ihren Fortschritt beobachten und beurteilen kann. Wenn Sie programmieren, können Sie ihm Ihren Code zeigen und Hinweise erhalten. Wenn Sie eine Präsentation im Büro oder vor einer ortsansässigen User-Group halten wollen, können Sie sie vorher Ihrem Mentor vorführen, um Feedback zu erhalten. Einem Mentor können Sie so weit vertrauen, dass Sie ihn fragen können, wie sich Ihr professionelles Verhalten ändern sollte, weil Sie ihn gut genug kennen, u m zu wissen, dass er Sie nicht nur kritisieren, sondern Ihnen auch helfen wird, sich zu verbessern. Schließlich entsteht, wie bei der Jazz-Musik, nicht nur eine persönliche Bindung an und Verantwortung für Ihren Mentor, sondern das Umgekehrte passiert ebenfalls. Besteht meine Rolle in einer Beziehung darin, jemandem zu helfen, investiere ich in den Erfolg dieser Person. Ich versuche, sie bei ihrer Karriere auf einen Weg zu lenken, der meiner Meinung nach der richtige ist. Wenn also sein Weg zum Erfolg führt, ist es auch mein Erfolg. Deshalb hat der Mentor einen Anreiz, den Erfolg seines Schülers zu wünschen. Normalerweise hat eine erfahrenere und bereits erfolgreiche Person in einer solchen Rolle den Respekt eines beträchtlichen Netzwerks anderer Leute. Damit ist der Mentor eine positiv verstärkte Verbindung zwischen Ihnen und seinem Netzwerk. Die Bedeutung einer solchen Verbindung kann nicht unterschätzt werden. Schließlich ist die Aussage »Es geht nicht darum, was du weißt, sondern, wen du kennst« nicht umsonst ein Klischee. Wie formell Ihre Beziehung zu einem Mentor ist, ist nicht wichtig. Niemand muss jemand anderen ausdrücklich fragen, ob er sein Mentor sein wolle (obwohl es definitiv nicht schlecht ist, dies zu tun). Tatsächlich weiß Ihr Mentor möglicherweise gar nicht, dass er für Sie diese Rolle spielt. Für Sie ist wichtig, jemanden zu haben, dem Sie vertrauen, den Sie bewundern, der Ihnen Karriereratschläge geben und Ihnen helfen kann, Ihr Können zu verbessern.

Umsetzung

Umsetzung i. Sein eigener Mentor sein - idealerweise findet jeder seinen Mentor, aber in Wirklichkeit sind wir nicht immer in der Lage, jemanden an unserem Ort zu finden, der für uns diese Rolle übernehmen kann. Hier ist eine Anleitung, wie Sie stellvertretend Ihr eigener Mentor sein können. Denken Sie an eine Person in Ihrem Arbeitsgebiet, die Sie besonders bewundern. Die meisten haben bereits eine kurze Liste im Kopf, die sich im Laufe ihrer Karriere herausgebildet hat. Vielleicht handelt es sich u m Leute, mit denen Sie zusammengearbeitet haben oder deren Arbeit Sie bewundern. Machen Sie eine Liste mit den zehn wichtigsten Attributen dieser Rollenmodelle. Wählen Sie die Attribute aus, die für Sie der Grund waren, diese Personen als Rollenmodelle auszuwählen. Bei diesen Attributen kann es sich um spezielle fachliche Fähigkeiten handeln, etwa die Breite ihres technologischen Wissens oder die Tiefe ihres Wissens auf einem Spezialgebiet. Es kann sich auch um persönliche Eigenschaften handeln, wie etwa die Fähigkeit, ein Team zusammenzuschweißen oder eine begeisternde Rede zu halten. Ordnen Sie dann diese Attribute nach Wichtigkeit von i (am unwichtigsten) bis 10 (am wichtigsten). Sie verfügen jetzt über eine Liste der Attribute, die Sie am meisten bewundern und die für Sie am wichtigsten sind. Diese Attribute geben vor, wo und wie Sie Ihrem gewählten Rollenmodell nacheifern sollten. Doch wie legen Sie fest, worauf Sie sich zuerst konzentrieren sollten? Fügen Sie eine Spalte zu der Liste hinzu, und überlegen Sie sich, wie Ihr Rollenmodell Sie auf einer Skala von i bis 10 (wobei 10 die Bestnote ist) einstufen würde. Versuchen Sie wirklich, sich in Ihr Rollenmodell hineinzuversetzen und sich selbst wie einen Dritten objektiv zu beurteilen. Wenn Sie die Attribute, die Rangliste und Ihrer eigenen Bewertungen zusammengestellt haben, ziehen Sie in einer letzten

13 - Suchen Sie sich einen Mentor

Spalte Ihre Bewertung in jeder Zeile von der Bedeutung ab, die Sie ihr in der vorhergehenden Spalte gegeben haben. Wenn Sie etwa ein Attribut als i o eingestuft haben (das wichtigste Attribut Ihres Rollenmodells) und Ihre Bewertung 3 war, erhalten Sie so einen endgültigen Prioritätswert von 7. Wenn Sie diese Spalte komplett ausgefüllt haben und dann absteigend nach Werten sortieren, erhalten Sie eine nach Prioritäten geordnete Top-TenListe der Bereiche, in denen Sie sich verbessern müssen. Beginnen Sie mit den oberen zwei oder drei Einträgen und stellen Sie eine Liste mit konkreten Aufgaben zusammen, mit denen Sie jetzt beginnen können, sich zu verbessern.

| KAPITEL io |

Seien Sie ein Mentor

enn Sie etwas wirklich lernen wollen, versuchen Sie, es

W

jemandem beizubringen. Es gibt keine bessere Methode, das eigene Verständnis einer Sache zu klären, als sich

selbst zu zwingen, es jemandem so darzulegen, dass er es versteht. Der einfache Akt des Sprechens ist ein bekanntes Elixier zur Behandlung verworrenen Denkens. Z u Puppen oder anderen unbelebten Objekten zu sprechen, um Probleme zu lösen, ist eine recht bekannte Methode aus dem Erfahrungsschatz der Software-Entwicklung.

Merksatz U m herauszufinden, ob Sie eine Sache wirklich beherrschen, versuchen Sie, sie jemandem beizubringen.

Martin Fowler (nein, wir sind nicht verwandt) sagte einmal bei einem Vortrag vor Entwicklern in Bangalore, er würde immer eine Sache schreiben, wenn er wirklich etwas über sie lernen wollte. Martin Fowler ist ein bekannter Software-Entwickler und Autor. Man könnte sogar sagen, dass er zu den bekanntesten und einflussreichsten Lehrern dieser Branche gehört, wenn man seine Rolle als Autor mit der eines fernen Lehrers und Mentors gleichsetzt.

ii113 14 - Seien Sie ein Mentor

Wir lernen beim Lehren. Es ist ironisch, weil wir erwarten, dass ein Lehrer die Dinge bereits kennt. Natürlich meine ich nicht, dass wir ganz neue Fakten lernen können, indem wir sie jemandem beibringen - denn woher sollten sie kommen? Aber Fakten zu kennen, ist nicht dasselbe, wie ihre Ursachen und Konsequenzen zu kennen. Es ist ein derartiges tieferes Verständnis, das wir beim Lehren entwickeln. Wir suchen nach Analogien, um komplexe Begriffe auszudrücken; und intern suchen wir nach den Gründen, warum eine Analogie zu funktionieren scheint, tatsächlich aber nicht tut, und eine andere Analogie nicht zu funktionieren scheint, tatsächlich aber tut. Wenn Sie jemanden unterrichten, müssen Sie Fragen beantworten, auf die Sie selbst vielleicht nie gekommen wären. Durch das Lehren werden die staubigen Ecken Ihres Wissens aufgedeckt und können gesäubert werden. Deshalb können Sie nicht nur davon profitieren, einen Mentor zu finden, sondern auch davon, selbst Mentor eines anderen zu sein. Eine Mentorenschaft hat auch positive Nebenwirkungen. Eine sich überlappende Gruppe von Mentoren und Schülern bildet ein eng geknüpftes und mächtiges soziales Netzwerk. Die Mentor-SchülerBindung ist besonders stark. Deshalb sind solche Bindungen in einem beruflichen Netzwerk stärker als bei passiveren Beziehungen. Wenn Sie zu jemandem in einer Mentorenbeziehung stehen, gehen Sie mit ihm ein Bündnis ein. Ein derartiges Netzwerk ist ein großartiger Ort, um schwierige Probleme zu behandeln oder nach Arbeit zu suchen.

Merksatz Mentoren werden in der Regel nicht entlassen.

Sie sollten auch nicht unterschätzen, dass es einfach ein gutes Gefühl ist, Menschen zu helfen. Wenn Sie an die Interessen anderer denken können, haben Sie faktisch mit Ihren Fähigkeiten etwas Altruis-

Umsetzung

| 113

tisches geleistet. In der Unsicherheit der heutigen wirtschaftlichen Umwelt ist das Helfen ein Job, aus dem man nicht entlassen werden kann. Und er wird in einer Währung bezahlt, die durch Inflation nicht entwertet wird. Man findet Schüler nicht, indem man sich selbst zum Guru erklärt, sondern indem man sein Wissen bereitwillig und geduldig mit anderen teilt. Sie müssen in einem Thema kein absoluter Experte sein. Wahrscheinlich gibt es in Ihren Erfahrungen etwas, das Sie als potenziellen Helfer eines weniger Erfahrenen qualifiziert. Finden Sie heraus, was es ist, fangen Sie an zu helfen. Beispielsweise haben Sie möglicherweise recht umfänglich mit PHP gearbeitet. Sie könnten Meetings Ihrer ortsansässigen PHPUser-Group besuchen und weniger erfahrenen Anwendern Hilfe bei speziellen Problemen anbieten. Oder wenn Sie kein leicht zugängliches Forum haben, um persönliche Mentorenschaft anzubieten, könnten Sie einfach anfangen, Fragen in einem Online-Message-Board oder IRC Channel zu beantworten, oder Leuten helfen, Anwendungsprobleme zu debuggen. Vergessen Sie jedoch nicht, dass es beim Mentoring um Menschen geht. Eine Online-Mentoring-Beziehung kann nie mit einer konkurrieren, die mit einem persönlichen Austausch zwischen Menschen verbunden ist. Sie müssen keine formelle Mentoring-Beziehung herstellen, um diese Vorteile zu erzielen. Fangen Sie einfach an, Leuten zu helfen; der Rest folgt auf natürliche Weise.

Umsetzung 1. Suchen Sie jemanden, den Sie unter Ihre Fittiche nehmen können. Vielleicht finden Sie einen jüngeren und weniger erfahrenen Kollegen in Ihrem Unternehmen, etwa einen Praktikanten. Oder Sie könnten mit der IT-Abteilung Ihrer ortsansässigen Universität reden und sich bereit erklären, einen Studenten zu betreuen.

ii

14 - Seien Sie ein Mentor

113

2. Suchen Sie sich ein Online-Forum und ein Thema aus. Beginnen Sie zu helfen. Werden Sie dadurch bekannt, dass Sie den Wunsch und die Fähigkeit haben, anderen Menschen geduldig beim Lernen zu helfen.

| KAPITEL 15 |

Übung, Übung, Übung

A

ls ich Musik studierte, verbrachte ich lange Abende im Gebäude meiner Universität. Durch die dünnen Wände ihrer Übungsräume war ich permanent in eine der häss-

lichsten musikalischen Klangumgebungen eingetaucht, die man sich vorstellen kann. Das lag nicht daran, dass die Musiker an meiner Uni besonders schlecht waren. Ganz im Gegenteil. Aber sie übten. Wenn Sie das Musikspielen üben, sollte es nicht gut klingen. Wenn Sie in den Übungssitzungen immer gut klingen, gehen Sie nicht an Ihre Grenzen. Das ist der Sinn der Übung. Dasselbe gilt im Sport. Athleten zwingen sich im Training, bis an ihre Grenzen zu gehen, damit sie diese Grenzen beim späteren Wettkampf überschreiten können. Sie geben der Hässlichkeit hinter geschlossenen Türen Raum - nicht, wenn sie tatsächlich arbeiten. In der Computer-Branche werden Entwickler immer wieder bis an ihre Grenzen beansprucht. Leider liegt das normalerweise daran, dass ein Entwickler für die übernommene Aufgabe unterqualifiziert ist. Unsere Branche neigt dazu, das Üben in die Arbeit zu verlagern. Können Sie sich vorstellen, dass ein professioneller Musiker auf die Bühne geht und den Schrott aus den Übungsräumen meiner Universität darbietet? Es würde nicht toleriert werden. Musiker werden

117 15 - Übung, Übung, Übung

dafür bezahlt, in der Öffentlichkeit aufzuführen, nicht zu üben. Ähnlich würde ein Kampfsportler oder Boxer, der sich bei Wettkämpfen bis an die Grenze seiner Möglichkeiten verausgabte, im Sport nicht weit kommen. Als Branche müssen wir dem Üben mehr Raum geben. In den westlichen Ländern wird oft dafür plädiert, einheimische Programmierer wegen ihrer, im Vergleich zu Offshore-Teams, relativ hohen Codequalität einzusetzen. Wenn wir in einen Qualitätswettbewerb eintreten wollen, dürfen wir unsere Jobs nicht länger als Übungssitzungen behandeln. Wir müssen die erforderliche Zeit in unser Gewerbe investieren. Vor mehreren Jahren begann ich mit Programmierübungen zu experimentieren, die ähnlich wie meine musikalischen Übungssitzungen aufgebaut waren. Regel Nummer eins war, dass die Software, die ich entwickelte, nicht etwas sein durfte, das ich verwenden wollte. Ich wollte keine Abkürzungen nehmen, um ein bestimmtes Endziel zu erreichen. Deshalb schrieb ich Software, die nicht nützlich war. Ich nahm keine Abkürzungen, war aber frustriert herauszufinden, dass viele Ideen, die mir beim Üben einfielen, nicht funktionierten. Obwohl ich versuchte, so gut wie möglich zu arbeiten, waren mein Design und mein Code nicht so elegant, wie ich gehofft hatte. Rückblickend erkenne ich, dass das Gefühl der Unbeholfenheit, das ich aufgrund dieser Erfahrungen bekam, ein gutes Zeichen war. Mein Code war nicht ganz frei von brillanten Einfällen. Aber ich streckte meine mentalen Muskeln und entwickelte meine Codierfähigkeiten. Es war wie beim Saxophonspielen: Wenn ich mich zum Üben hinsetzte, und nur schöner Sound herauskam, wusste ich, dass ich nicht übte. Ähnlich, wenn ich mich hinsetze, um Codieren zu üben und nur eleganten Code produziere, arbeite ich wahrscheinlich aus der Mitte meiner gegenwärtigen Fähigkeiten heraus und nicht an ihren Grenzen, an die mich eine gute Übungs Sitzung bringen sollte.

Übung, Übung, Übung

117

Merksatz Üben Sie an Ihren Grenzen.

Wie können Sie also erkennen, was Sie üben sollten? Was bringt Sie an Ihre Grenzen? Das Thema, wie man als Software-Entwickler üben sollte, könnte leicht ein eigenes Buch füllen. U m anzufangen, greife ich wieder auf meine Erfahrung als Jazz-Musiker zurück. Ich würde das Üben von Jazz in die folgenden Kategorien einteilen (die für Nichtmusiker etwas vereinfacht sind): •

Körperlich/Koordination

•

Notenlesen

•

Improvisation

Diese Kategorien können als Framework für eine Methode dienen, über das Üben als Software-Entwickler nachzudenken. Körperlich/Koordination:

Musiker müssen den Umgang mit den

technischen Aspekten ihrer Instrumente üben: Sound-Produktion, körperliche Koordination (etwa die schnelle Bewegung der Finger), Geschwindigkeit und Genauigkeit sind alles Aspekte, die geübt werden müssen. Welches sind die Gegenstücke dieser musikalischen Grundaspekte bei der Software-Entwicklung? Was ist mit den verstaubten, selten besuchten Ecken Ihrer primären Programmiersprache? Unterstützt Ihre Programmiersprache reguläre Ausdrücke? Reguläre Ausdrücke sind eine außerordentlich leistungsstarke und tragischerweise viel zu wenig genutzte Funktion vieler Programmierumgebungen. Die meisten Entwickler verwenden sie nicht, wenn es möglich wäre, weil sie nicht über die erforderlichen Fähigkeiten verfügen, um diese Ausdrücke produktiv einzusetzen. Folglich wird eine große Menge überflüssiger Code für das Parsen von Strings erstellt, der später gewartet werden muss. Dasselbe gilt für die APIs oder Funktionsbibliotheken Ihrer Sprache. Wenn Sie nicht die vielen Tools Ihrer Umgebung in den Fingern

117 15 - Übung, Übung, Übung

haben (wie Musiker zu sagen pflegen), ist es weniger wahrscheinlich, dass Sie auf sie zurückgreifen, wenn Sie Ihnen wirklich helfen könnten. Versuchen Sie etwa, wirklich herauszufinden, wie Multithreaded Programming in der Programmierumgebung Ihrer Wahl funktioniert. Oder was ist mit den Stream-Bibliotheken, den Network Programming APIs oder sogar dem Satz der Utilities für das Arbeiten mit Collections oder Listen? Die meisten modernen Programmiersprachen bieten in allen diesen Bereichen reichhaltige und leistungsstarke Bibliotheken an, aber Software-Entwickler neigen dazu, eine kleine Untermenge zu lernen, mit der sie denselben Code weniger effizient schreiben können, als es möglich gewesen wäre, wenn sie den kompletten Satz der verfügbaren Tools gemeistert hätten. Notenlesen: Besonders für Studiomusiker ist die Fähigkeit, Noten lesen und gleich beim ersten Mal fast perfekt spielen zu können, für den beruflichen Erfolg von überragender Bedeutung. Ich spielte einmal Saxophon bei einem Auftritt für Blockbuster (eine Video-Verleihfirma). Ich spielte sowohl den Lead- als auch den Second-AltoTeil in einem up-tempo Big-Band-Song. Ich sah die Musik buchstäblich zum ersten Mal, als das Band anfing zu laufen. Wir spielten einmal den Lead-Teil durch und einmal den zweiten Teil. Ein Fehler, und die ganze Band hätte das Ganze wiederholen müssen - und die Kosten für die Studiozeit mussten abgerechnet werden. Was würde es für einen Software-Entwickler bedeuten, Code auf den ersten Blick lesen zu können? Oder Anforderungsspezifikationen oder Designs? Die Open-Source-Community ist ein ausgezeichneter Ort, um neuen Code zu finden, mit dem man üben kann. Gibt es Open-Source-Software, die Sie besonders lieben? Schauen Sie Ihre Aufgabenliste nach Software durch, mit der Sie gerne üben möchten, und setzen Sie sich eine begrenzte Zeitspanne, u m eine neue Funktion zu implementieren (oder u m wenigstens herauszufinden, wie lange es dauern würde, sie zu implementieren). Nachdem Sie eine Funktion ausgewählt haben, laden Sie den Sourcecode der Software herunter und untersuchen ihn. Woher wissen

Übung, Übung, Übung

119

Sie, wo Sie nachschauen müssen? Welche Tricks wenden Sie an, um sich in umfangreichem Code zurechtzufinden? Wo fangen Sie an? Dies ist eine Übung, die Sie oft und in kurzen Zeitspannen praktizieren können. Sie müssen die Funktion nicht wirklich implementieren. Benutzen Sie sie nur als Ausgangspunkt. Das eigentliche Ziel besteht darin, den Code so schnell wie möglich zu verstehen. Arbeiten Sie auch mit anderer Software. Versuchen Sie es mit anderen Arten von Software in unterschiedlichen Stilen und Sprachen. Notieren Sie Aspekte, die es Ihnen leichter oder schwerer machen, sich zurechtzufinden. Welche Muster entwickeln Sie, die Ihnen helfen, Code durchzuarbeiten? Welche virtuellen Brotkrumen streuen Sie aus, die Ihnen bei Ihrer Navigation durch den Call-Stack einer komplexen Funktionen helfen? Improvisation: Improvisation bedeutet, ausgehend von einer vorgegebenen Struktur oder Einschränkung beim Spielen, etwas Neues zu schaffen. Als Programmierer habe ich festgestellt, dass ich hauptsächlich unter Stress improvisiere. Oh nein! Der Anwendungsserver des drahtlosen Netzwerks ist ausgefallen, und wir verlieren Aufträge! Das ist die Art von Situation, in der einige der kreativsten Adhoc-Programmierlösungen entstehen. Dann machen Sie verrückte Dinge, wie etwa verlorene Daten wiederzugewinnen, indem Sie manuell Pakete aus einer binären Protokolldatei über ein drahtloses Netzwerk wieder einspielen. Niemand hat Ihnen gesagt, diese Dinge zu tun, besonders nicht in der Hitze des Gefechts. Diese Art der schnellen und punktgenauen Programmierung kann wie ein Zauberstab zum richtigen Zeitpunkt Wunder bewirken. Eine großartige Methode, Ihr Denken zu schärfen und Ihre Fähigkeiten zu verbessern, Programmierlösungen zu improvisieren, besteht darin, unter selbst auferlegten Einschränkungen zu üben. Wählen Sie ein einfaches Programm aus und versuchen Sie, es unter diesen Einschränkungen zu schreiben. Meine Lieblingsübung besteht darin, ein Programm zu schreiben, das den Text des müden

117

11715- Übung, Übung, Übung

alten Songs »99 Botties of Beer on the Wall« ausdruckt. Wie könnte man ein solches Programm schreiben, ohne Variablen zu verwenden? Oder: Wie klein kann das Programm sein, das den Text immer noch korrekt ausgibt? Als zusätzliche Einschränkung können Sie einen Zeitfaktor einführen. Wie schnell können Sie dieses Programm schreiben? Wie wäre es damit, kleine schwierige Probleme zu lösen, während gleichzeitig ein Timer läuft? Dies ist nur eine beschränkte Perspektive, wie man üben könnte. Sie können geeignete Beispiele aus jeder Disziplin entlehnen, von der bildenden Kunst bis zu klösterlichen religiösen Exerzitien. Das Wichtige ist, Ihren Übungsbedarf zu ermitteln und dafür zu sorgen, dass Sie nicht bei der Aufführung (bei der Arbeit) üben. Sie müssen die Zeit für das Üben zur Verfügung stellen. Es liegt in Ihrer Verantwortung.

Umsetzung 1.

TopCoder - TopCoder.com ist eine etablierte Website für Programmierwettbewerbe. Sie können sich registrieren, um ein Konto zu erhalten, und online um Preise konkurrieren. Selbst wenn Sie nicht daran interessiert sind, mit anderen zu konkurrieren, bietet TopCoder einen Übungsraum mit einer großen Sammlung von Übungsproblemen an, die Sie als exzellentes Futter für Ihre Übungssitzungen verwenden können. Melden Sie sich an und probieren Sie es aus.

2. Code Kata - Dave Thomas, einer der Pragmatic Programmers (unser geliebter Verleger), übernahm die Idee, das Codieren zu üben, und machte daraus - nun ja - etwas Pragmatisches. Er schuf eine Reihe so genannter Code Kata, kleine, Gedanken anregende Übungen, die Programmierer in der Sprache ihrer Wahl ausführen können. Jedes Kata hat eine spezielle Technik oder einen bestimmten Denkprozess zum Gegenstand und trainiert einen der gedanklichen Muskeln.

Umsetzung

| 121

Als dieses Buch gedruckt wurde, hatte Dave 21 Kata erstellt und kostenlos in seinem Weblog (codekata.pragprog.com) zur Verfügung gestellt. In dem Weblog finden Sie auch Links zu einer Mailing-List, zu Lösungen, die andere

Entwickler

geliefert

haben, sowie zu Diskussionen, wie die Probleme gelöst worden sind. Ihre Aufgabe: Arbeiten Sie alle 21 Kata durch. Führen Sie ein Tagebuch (vielleicht auch ein Weblog) Ihrer Erfahrungen mit den Kata. Wenn Sie alle 21 Übungen durchgearbeitet haben, schreiben Sie Ihr eigenes Kata und stellen es anderen zur Verfügung.

| KAPITEL! 6 |

Ihr eigener Stil

as Wort Software-Entwicklung

D

bezeichnet keinen Gegen-

stand, sondern eine Tätigkeit, einen Prozess, bei dem etwas

erzeugt wird. Beim Codieren ist es genauso wichtig, sich auf

den Prozess wie auf das zu entwickelnde Produkt zu konzentrieren. Wenn Sie nicht auf den Prozess achten, riskieren Sie es, Ihren Termin zu überschreiten, das falsche Produkt zu liefern oder überhaupt nicht zu liefern. Keines dieser möglichen Ergebnisse wird von Ihren Kunden gerne gesehen. Glücklicherweise haben viele Leute lange über den Prozess der Herstellung guter Software (und Produkte im Allgemeinen) nachgedacht und ihre Ergebnisse in so genannten Methodologien festgehalten. Diese Methodologien sind Gegenstand zahlreicher Bücher, die Sie online oder in Ihrem ortsansässigen Buchladen finden. Leider profitieren die meisten Entwickler nicht von diesen vielen guten Informationen. Für die meisten Entwicklungsteams ist der Prozess ein Hintergedanke oder etwas, das ihnen von oben auferlegt wird. Das Wort Methodologie hat sich in ihrer Vorstellung zu einem Synonym für Papierkram und langer, bedeutungsloser Meetings verfestigt. Allzu oft ist eine Methodologie etwas, das ihnen von ihren Managern auferlegt wird.

124

i6 - Ihr eigener Stil

Manager wissen intuitiv, dass sie irgendeine Art von Prozess befolgen sollten, wissen aber oft nicht, welche Optionen ihnen heute zur Verfügung stehen. Folglich entstauben sie dieselben Prozesse, die ihnen in den 1980er Jahren auferlegt worden sind, hüllen sie in die neuesten Modewörter ein (gegenwärtig ist etwa agil en vogue) und drücken sie dann ihren Teams auf. Und wenn nicht jemand diesen Zyklus durchbricht, indem er tatsächlich untersucht, was funktioniert und was nicht, wird sich dieser Prozess wiederholen, wenn die Entwickler in dem Team selbst Manager werden. Sie glauben, es müsse einen besseren Weg geben, Software zu entwickeln. Und für die meisten Teams existiert ein solcher Weg. Als Programmierer, Tester oder Software-Designer denken Sie möglicherweise, der Entwicklungsprozess läge nicht in Ihrer Verantwortung. Soweit es Ihr Unternehmen angeht, haben Sie wahrscheinlich recht. Leider ist normalerweise niemand für ihn zuständig. Wenn er jemandem zugewiesen wird, fällt er möglicherweise in das Loch einer »Prozessgruppe« oder einer ähnlichen Abteilung, die mit nichts wirklich verbunden ist. Die Wahrheit ist ganz einfach: Soll ein Software-Prozess die Chance erhalten, erfolgreich implementiert zu werden, muss er von den Leuten übernommen werden, die den Prozess anwenden - Leuten wie Sie. Die beste Methode, sich als Eigentümer dieser Prozesse zu fühlen, besteht darin, bei ihrer Implementierung zu helfen. Wenn Ihr Unternehmen keinen Prozess anwendet, finden Sie heraus, welche Methodologien für Sie geeignet sein könnten. Diskutieren Sie informell mit Ihrem Team über die gegenwärtigen Entwicklungsprobleme und Möglichkeiten, sie durch Übernahme eines Standardprozesses zu beseitigen.

Merksatz Wenn Sie sich als Eigentümer eines Prozesses fühlen wollen, helfen Sie bei seiner Implementierung.

Ihr eigener Stil

125

Stellen Sie einen Plan auf, um den gewählten Prozess in Ihrem Unternehmen einzuführen, und lassen Sie sich von jedem die Bereitschaft mitzumachen zusichern. Beginnen Sie dann mit der Umsetzung Ihres Plans. Alternativ arbeiten Sie möglicherweise in einer Umgebung, in der ein Prozess von oben vorgeschrieben wurde. Wenn die Anweisungen endlich bei dem Entwicklungsteam angekommen sind, sind die Praktiken oft so weit verdünnt und uminterpretiert worden, dass ihre ursprüngliche Bedeutung verloren gegangen ist. Der Prozess hat dasselbe Schicksal erlitten wie die geheime Aussage in dem Spiel Stille Post. Auch dies ist eine Gelegenheit, Initiative zu ergreifen. Informieren Sie sich über die vorgeschriebene Methodologie und helfen Sie, ihre ursprüngliche Bedeutung sowohl Ihrem Team als auch Ihrem Management zu vermitteln. Sie werden nicht dagegen ankämpfen können, dass der Prozess vorgeschrieben worden ist; deshalb könnten Sie zumindest dafür sorgen, dass er funktioniert, indem er korrekt ausgeführt wird. In der Methodologie-Welt hat man schnell den Eindruck, dass sich alles wie eine hohle Muschel voller Modewörter anhört. Doch auch wenn sich viele Beschreibungen wie Trendgeschwätz anhören, können Sie immer etwas aus dem Studium eines Software-Prozesses lernen - selbst wenn es nur das ist, was man nicht tun sollte. Wenn Sie die Landschaft der Software-Prozesse gut kennen, können Sie glaubwürdiger für eine bestimmte Vorgehensweise Ihres Teams argumentieren. Selbst bei der Vielzahl der empfohlenen, zur Wahl stehenden Methodologien ist es unwahrscheinlich, dass Sie jemals für ein Unternehmen arbeiten werden, das irgendeine dieser Methoden vollständig implementiert hat. Das ist in Ordnung. Der beste Prozess ist immer der, der Ihr Team am produktivsten macht und die besten Produkte hervorbringt.

126

i6 - Ihr eigener Stil

Methodologien: Nicht nur für Ceeks Oft setzen Unternehmen Projektmanagementtechniken ein, die nicht direkt an die Software-Entwicklung gebunden sind. In der Branche werden zahlreiche Projektmanagementmethoden eingesetzt. In den USA ist wahrscheinlich das Project Book

of

Knowledge

des

Project

Management

Management

Institute

(www.pmi.org; mit einem weit anerkannten Zertifizierungsprogramm) am bekanntesten. Six Sigma (www.isixsigma.com) ist eine weitere, nicht Softwarespezifische Methode zur Qualitätssicherung. Sie wird von Unternehmen wie General Electric und Motorola unterstützt und betont das Messen und Analysieren von Prozessen und Produkten, um die Effizienz und die Kundenzufriedenheit zu verbessern. Obwohl die Vorgehensweise nicht speziell auf die SoftwareEntwicklung zugeschnitten ist, enthält der strikte methodische Ansatz von Six Sigma viele Lektionen, die Sie direkt auf Ihren Job als Programmierer anwenden können. In Deutschland ist das V-Modell (http://www.ansstand.de/) verbreitet.

Die einzige Methode, diesen hybriden Prozess zu finden, besteht darin, einzelne Komponenten auszuwählen, die Ihnen und Ihrem Team sinnvoll zu sein scheinen, und fortlaufend anhand Ihrer Erfahrungen zu verfeinern. Letztlich können Sie, wenn Sie den Prozess nicht beherrschen, das Produkt nicht herstellen. Es ist viel einfacher, jemanden zu finden, der Software zum Laufen bringt, als jemanden zu finden, der den Prozess der Erstellung von Software erfolgreich implementieren kann. Deshalb sind Kenntnisse über den Software-Entwicklungsprozess für Sie nützlich.

| 127

Umsetzung

Umsetzung 1. Wählen Sie eine Methode zur Software-Entwicklung aus, besorgen Sie sich ein einschlägiges Buch, besuchen Sie die entsprechenden

Websites

und abonnieren

Sie eine

Mailing-List.

Schauen Sie sich die Methode kritisch an. Was sind Ihrer Meinung nach ihre Stärken und Schwächen? Was könnte verhindern, sie bei Ihrer Arbeit zu implementieren? Machen Sie dann dasselbe mit einer anderen Methode. Vergleichen Sie ihre Stärken und Schwächen. Wie könnten Sie beide Ansätze kombinieren?

| KAPITEL 17 |

Auf den Schultern von Giganten

A

ls Jazz-Musiker verbrachte ich viel Zeit damit, mir Musik anzuhören. Ich spielte Musik nicht nur beim Lesen oder Autofahren im Hintergrund, sondern ich setzte mich hin,

um mir die Musik bewusst anzuhören. Wenn man die Jazz-Improvisation meistern will, ist bewusstes Zuhören eine wichtige Quelle der Inspiration. Sie liefert Einsichten, welche Variationen funktionieren und welche nicht, welche Sounds wirklich großartig klingen und welche nur Mittelmaß sind. Die umfangreichen historischen Jazz-Aufnahmen enthalten ein unglaublich reichhaltiges Wissen für jeden, der über die Fähigkeit verfügt, es rauszuhören. Deshalb ist das Hören von Musik für einen Jazz-Musiker keine passive Aktivität. Es ist Studium. Darüber hinaus ist die Fähigkeit, zu verstehen, was man hört, etwas, was Sie im Lauf der Zeit entwickeln. Mein Kreis von Musikfreunden setzte sich oft zusammen, u m gezielt diese Art des Hörens zu praktizieren. Wir veranstalten Zuhör-Partys, bei denen eine Gruppe von JazzMusikern zusammensaß, sich Musik anhörte und dann darüber diskutierte. Manchmal spielten wir Nenne den Improvisator: Jemand legte eine Aufnahme eines improvisierten Solos auf, und die anderen mussten anhand des Stils den Jazz-Musiker herausfinden.

T30

17 - Auf den Schultern von Giganten

Natürlich ist diese Art des Lernens nicht nur auf die Jazz-Welt beschränkt. Klassische Komponisten praktizieren Ähnliches. Dasselbe gilt für Romanciers und Dichter oder für Bildhauer und Maler. Die Werke von Meistern zu studieren, ist ein wesentlicher Bestandteil, selbst ein Meister zu werden. Wenn wir uns die Jazz-Aufnahmen anhörten, diskutierten wir über die musikalischen Kniffe, mit denen die Improvisatoren ihre musikalischen Absichten ausdrückten. »Wow. Hast du gehört, wie er am Ende der Form anfing abzuweichen?« oder »Das war wirklich seltsam, wie er diesen Ton in die Länge zog.« Diese Diskussionen halfen uns, Tricks zu entdecken und herauszufiltern, die wir in unserer nächsten Improvisationssitzung ausprobieren konnten.

Merksatz Durchsuchen Sie vorhandenen Code nach Erkenntnissen.

Software-Design und Programmierung haben in dieser Hinsicht viel mit den Künsten gemeinsam. Wir können eine riesige Menge vorhandenen Codes nach Patterns und Tricks durchsuchen. Die Design-Pattern-Bewegung (siehe Design Patterns [GHJV95]) befasst sich mit der Entdeckung und Dokumentation wiederverwendbarer Lösungen für häufig auftretende Probleme bei der Software-Entwicklung. Design Patterns haben das Studium von vorhandenem Code formalisiert und ihre Verfahrensweisen zahlreichen SoftwareEntwicklern zugänglich gemacht. Dennoch sind Design Patterns nur eine kleine Teilmenge der Dinge, die wir durch das Lesen von Code lernen können. Mit welchen Algorithmen lösen andere Programmierer spezielle Probleme? Wie verwenden andere strategisch die Namen von Variablen, Funktionen und Strukturen? Wenn ich das Instant-Messaging-Protokoll Jabber in einer anderen Sprache implementieren wollte, wie könnte ich vorgehen? Welche kreativen Methoden gibt

T3017-Auf den Schultern von Giganten

es, um die Interprocess-Kommunikation zwischen Unix- und Windows-Systemen zu handhaben? Dies sind Beispiele für die Art von Fragen, die Sie durch das Studium von vorhandenem Code beantworten können.

Merksatz Verwenden Sie vorhandenen Code, um Ihre eigenen Fähigkeiten abzuschätzen.

Noch wichtiger, als Lösungen für spezielle Probleme zu finden, ist es, vorhandenen Code als Vergrößerungsglas zur Untersuchung des eigenen Stils und der eigenen Fähigkeiten zu verwenden. So wie das Abspielen einer Aufnahme von John Coltrane mich immer daran erinnerte, wo ich selbst auf der Leiter der Fähigkeiten als Saxophonist stand, macht das Lesen der Arbeit eines großartigen SoftwareEntwicklers ähnlich bescheiden. Dennoch geht es nicht nur darum, Bescheidenheit zu lernen. Wenn Sie fremden Code studieren, entdecken Sie Dinge, die Sie selbst nie getan hätten. Sie entdecken Lösungen, an die Sie selbst nicht einmal gedacht hätten. Warum? Was hat sich dieser Entwickler dabei gedacht? Was waren seine Motive? Sie können sogar von schlechtem Code lernen, wenn Sie ihn mit einer solchen selbstkritischen Einstellung studieren. Diese Art, anhand der vor Ihnen geleisteten Arbeit zu lernen, funktioniert in der Kunstwelt gut, weil es für Gemälde oder Musikstücke keinen verborgenen Sourcecode gibt. Wenn Sie Musik hören oder ein Gemälde betrachten, können Sie davon lernen. Dankenswerterweise steht uns als Software-Entwickler eine praktisch unbegrenzte Menge Open-Source-Software zur Verfügung. Es gibt so viel Open-Source-Software, dass es für einen Einzelnen praktisch unmöglich ist, sie alle zu lesen. Es gibt definitiv einige schlechte Open-Source-Projekte, aber auch recht viele wirklich großartige. Es gibt Open-Source-Code, um fast jede Aufgabe zu imple-

T30

T30 17 - Auf den Schultern von Giganten

mentieren, die mit Software in fast jeder verfügbaren Programmiersprache gelöst werden kann. Wenn Sie sich diesen Code kritisch anschauen, entwickeln Sie allmählich einen eigenen Geschmack, ähnlich wie für Musik, Kunst oder Literatur. Verschiedene Stile und Techniken werden Sie amüsieren, erstaunen, verärgern und (hoffentlich) anspornen. Wenn Sie wirklich suchen, finden Sie alles Mögliche, von Tricks, die Sie produktiver machen, bis hin zu Design-Paradigmen, die Ihre Art, eine bestimmte Klasse von Problemen zu lösen, vollkommen umkrempeln. So wie in den Künsten entwickeln Sie Ihren eigenen speziellen Stil der Software-Entwicklung, indem Sie die Gewohnheiten anderer studieren und von ihnen lernen. Das Lesen von Code hat noch einen weiteren positiven Nebeneffekt: Sie lernen mehr darüber, was bereits existiert. Wenn Sie ein neues Problem lösen müssen, erinnern Sie sich vielleicht daran, dass Sie eine spezielle Bibliothek für das MIME-Handling gesehen haben, das Sie in Ihrem aktuellen Projekt brauchen. Falls die Lizenzbedingungen stimmen, können Sie sich viel Zeit und Ihrem Unternehmen viel Geld sparen, wenn Sie sich gründlich darüber informieren, was bereits anwendungsfertig als Software vorhanden ist. Sie wären erstaunt darüber, wie viel Geld in der Software-Branche verschwendet wird, um das Rad endlos immer wieder neu zu implementieren (erfinden wäre hier zu positiv). Sir Isaac Newton sagte: »Wenn ich weiter gesehen habe, liegt das daran, dass ich auf den Schultern von Giganten gestanden habe.« Kluge Leute wie Isaac Newton wissen, dass man viel von den Menschen lernen kann, die vor uns lebten und arbeiteten. Verhalten Sie sich wie Newton.

Umsetzung i. Wählen Sie ein Projekt aus und lesen Sie es wie ein Buch. Machen Sie sich Notizen. Heben Sie die guten und die schlechten Punkte hervor. Schreiben Sie eine Kritik und veröffentlichen

Umsetzung

| 133

Sie sie. Finden Sie wenigstens einen Trick oder ein Pattern, das Sie nutzen können. Finden Sie wenigstens einen schlechten Aspekt, den Sie auf Ihre »Was man bei der Software-Entwicklung nicht tun sollte«-Checkliste setzen können. 2. Suchen Sie sich eine Gruppe Gleichgesinnter, mit denen Sie sich einmal im Monat treffen. In jeder Sitzung sollte jemand Code im Umfang von etwa 2 0 0 Zeilen vorstellen, über den gemeinsam diskutiert wird. Analysieren Sie den Code. Diskutieren Sie, was hinter ihm steht. Denken Sie an die Entscheidungen, die in ihn eingeflossen sind. Überlegen Sie, welcher Code nicht in ihm enthalten ist.

KAPITEL I 8

Arbeit automatisieren

ährend meiner Karriere gab es ein konstantes Thema:

W

der Konflikt zwischen dem Wunsch des IT-Manage-

ments, billige (oft aus dem Ausland stammende) Bera-

tungsunternehmen für Projektarbeit zu engagieren, und meiner festen Überzeugung, dass die billigsten Entwickler nicht notwendigerweise die geringsten Kosten verursachen. Ich führte viele heftige Diskussionen mit IT-Direktoren oder Vizepräsidenten, in denen ich leidenschaftlich dafür plädierte, einige wirklich gute Entwickler einzustellen, anstatt eine Legion billiger Codierer mit geringen Fähigkeiten zu beschäftigen. Leider wurden meine Argumente oft mittendrin abgewürgt. Mit meiner Position hatte ich ein Problem: Ich hatte zwar nicht offensichtlich Unrecht, konnte aber auch nicht leicht beweisen, dass ich recht hatte. Und aus der Kostenperspektive führt der einzige vorliegende harte Fakt zu dem Schluss, dass ein niedrigerer Stundensatz tatsächlich für das Unternehmen vorteilhafter ist, das die Leute einstellt. Angenommen, Sie müssten ein Software-Projekt einer Größe Ihrer Wahl betreuen. Wie viele Programmierer würden Sie benötigen, um die erforderliche Software in drei Monaten zu schreiben? Fünf,

139

139 i8 - Arbeit automatisieren

sagen Sie? Sechs? Okay, wie wäre es, dasselbe Projekt in zwei Monaten abzuwickeln? Wie könnten Sie einen Monat einsparen? Die Standardantwort des IT-Managements besteht darin, mehr Programmierer zu beschäftigen, um die Arbeit schneller zu erledigen. Das ist zwar falsch; aber das glauben die Leute. Und wenn man ein einzelnes Projekt durch zusätzliche Programmierer beschleunigen kann, führt eine Extrapolation dieser Regel dazu, dass mehr Leute eine höhere Produktivität bedeuten. Doch man kann die Sache auch anders sehen. Wenn das Ziel darin besteht, den Durchsatz bei der Software-Entwicklung zu erhöhen, kann man •

schnellere Mitarbeiter für die Arbeit engagieren,

•

mehr Mitarbeiter für die Arbeit engagieren

•

oder die Arbeit automatisieren.

Da wir immer noch nicht wissen, wie man die Produktivität der Software-Entwicklung wirklich messen kann, ist schwer zu beweisen, dass eine Person schneller arbeitet als eine andere. Deshalb konzentrieren sich Finanzmanager auf die Kosten pro Stunde. Dies führt zu einer einfachen (und einfältigen) Formel, die von einer fixen Zeitspanne ausgeht: Produktivität =

Anzahl der Projekte Anzahl der Programmierer x Stundensatz

In einigen Umgebungen ist es tatsächlich möglich, den wahren Ertrag einer Software-Investition zu berechnen. In den meisten werden jedoch schwammige, formlose Maße verwendet, wie etwa Anzahl der Projekte oder Anzahl der Anforderungen, für die es keine reproduzierbare Messmethode gibt. Deshalb ist es zu schwierig, die Schnelligkeit von Programmierern zu messen. Und da wir keinesfalls für mehr billige Programmierer plädieren wollen, bleibt uns nur die Automatisierung. Ich erinnere mich, wie sensationell der Verlust von Arbeitsplätzen in den Vereinigten Staaten Ende der 1980er Jahre aufgemacht

| 137

Umsetzung

wurde. Damals wurden nicht nur andere Länder, sondern auch Maschinen und insbesondere Computer als die Schuldigen ausgemacht. In den Fabriken wurden riesige Roboterarme installiert. Sie arbeiteten so viel schneller und genauer als Menschen, dass sich nicht einmal ein Vergleich lohnte. Alle waren bestürzt - abgesehen natürlich von den Leuten, die die Roboterarme gebaut hatten. Angenommen, Ihr Unternehmen erstellte Websites für kleinere Betriebe. Im Wesentlichen erstellen Sie immer wieder dieselbe Website mit Kontakten, Übersichten, Einkaufswagen usw. Sie könnten entweder eine kleine Anzahl wirklich schneller Programmierer engagieren, um die Websites zu erstellen; Sie könnten eine Armee billiger Programmierer engagieren, die immer wieder dasselbe langsamer manuell erledigen; oder Sie könnten ein System erstellen, um die Websites zu generieren. Wenn wir einige (erfundene) Zahlen in die Formel unseres Finanzmanagers einfügen, erhalten wir folgende Vergleichszahlen der Produktivität: Schnelle Programmierer:

=

5 3 x 80 Euro

= 0,02

Billige Programmierer:

=

5 = 0,02 2 0 x 12 Euro

Automatisierung:

=

5 1 x 80 Euro

_. 0,06

Umsetzung 1. Wählen Sie eine Aufgabe aus, die Sie normalerweise wiederholt ausführen, und schreiben Sie dafür einen Code-Generator. Kümmern Sie sich nicht um die Wiederverwendbarkeit. Sorgen Sie nur dafür, dass Sie mit dem Generator Zeit sparen. Überlegen Sie, wie Sie diesen Code verallgemeinern könnten. 2. Beschäftigen Sie sich näher mit der Model-Driven Architectur (MDA). Probieren Sie einige der verfügbaren Tools aus. Suchen

139 i 8

- Arbeit automatisieren

Sie nach einem Bereich Ihrer Arbeit, in dem Sie die Konzepte der MDA oder sogar das komplette Toolset ausprobieren können. Überlegen Sie, wie Sie MDA-Konzepte auch auf die Tools anwenden können, die Sie tagtäglich verwenden.

Vom IT-Berater zum leitenden Direktor von Vik Chada Meine Reise von einem IT-Berater bei GE (General Electric) zum Entrepreneur-in-Residence bei bCatalyst (einem Business Accelerator mit einem Budget von 5 Millionen Dollar) war kein Weg, den ich mir als nächsten Schritt meiner Karriere vorgestellt hätte. Wie vollzog sich mein Übergang von meiner Anstellung bei einem Fortune-5-Unternehmen mit Zehntausenden von Mitarbeitern zu einem Beratungsunternehmen, das in junge High-Tech-Startups investierte und sie in der Anfangsphase betreute? Wenn ich rückblickend versuche, Verbindungen herzustellen, zeigen sich einige wichtige Muster, die ich Ihnen gerne in der Hoffnung mitteilen möchte, dass Sie sie auf Ihren eigenen Kontext anwenden können. Bald nachdem ich meinen Master als Elektroingenieur bei der Virginia Tech gemacht hatte, begann ich bei GE als ITBerater. Die kommerzielle

Nutzung des Internets hatte

gerade begonnen, und ich arbeitete an mehreren Projekten, deren Zweck darin bestand, diese unglaublich leistungsstarke Plattform und die ihr zugrunde liegenden Technologien bestmöglich zu nutzen. Ich arbeitete in schneller Reihenfolge mit dem IT-Finanzteam, der Technologies-and-Services-Gruppe, der Sales-Force-Automatisierung und der Data-WarehousingGruppe zusammen, um mit jedem Team neue Initiativen zu entwickeln. Ich liebte es, die neuesten Internet-Technologien

Umsetzung

zu erforschen und dann zu implementieren, um durch ihre Anwendung schwierige Geschäftsprobleme zu lösen. Doch an der Vorderfront der technischen Entwicklung zu leben, machte nicht immer Spaß. Zwangsläufig stießen wir auch auf Probleme mit Technologien, die noch nicht ausgereift waren, und verwendeten viel Zeit und Energie darauf, unseren Anbietern zu helfen, ihre Produkte zu debuggen. Aus Kundensicht lernte ich, dass eine Technologie, unabhängig davon, wie cool sie zu sein schien, nur wertvoll war, wenn sie ein dringendes echtes Problem löste und quantifizierbare Vorteile lieferte. Im Laufe der Zeit half mir diese Einsicht, weniger Technologie-zentriert, sondern mehr lösungsorientiert zu denken. Dass mir diese neue Art zu denken selbst bewusster wurde, erwies sich als sehr wertvoll, als ich einige Jahre später bei bCatalyst Technologie-Startups in ihrer Anfangsphase bewertete. Doch so sehr mir die Arbeit bei GE gefiel, fehlte doch ein wichtiger Aspekt. Ich hatte das Gefühl, dass sich in meinem Job als IT-Experte meine gesamten Fähigkeiten hauptsächlich in einer einzigen Dimension weiterentwickelten und ich keine Gelegenheit hatte, wirklich zu verstehen, wie Unternehmen arbeiten, wie sie Geld verdienen, wodurch sie überlebensfähig werden und wie sie Innovationen hervorbringen. Anstatt in meiner Frustration zu schmoren, beschloss ich, die Initiative zu ergreifen und selbst mehr über Unternehmen und Unternehmerschaft zu lernen. Ich hatte nie Vorlesungen in Betriebswirtschaft besucht und wusste, dass die einzige Methode, wirklich zu lernen, was erforderlich ist, um ein Unternehmen zu gründen, darin bestand, mir die Hände schmutzig zu machen (das heißt, durch eigenes Handeln und Versuch und Irrtum zu lernen).

| 139

139i8- Arbeit automatisieren

Zusammen mit einem unternehmerisch tätigen ehemaligen Zimmerkollegen, mit dem ich eng befreundet war (Raj Hajela), und meiner Frau (Vidya) führte ich Brainstormings durch, um unbefriedigte Bedürfnisse im Markt herauszufinden. Wir wollten E-Commerce-Gelegenheiten entdecken, aber nicht mit vorhandenen Konsumgütern konkurrieren. Wir waren ernsthaft an Kunst interessiert und verfügten über einschlägige Kenntnisse auf diesem Gebiet. Uns gefiel die Tatsache, dass jedes Kunstwerk von Natur aus einzigartig war. Mein Onkel hat sein Leben lang mehr schlecht als recht versucht, seinen Lebensunterhalt als Künstler zu verdienen. Einige Nachforschungen zeigten uns, dass es vielen Künstlern ebenso ging. Da beschlossen wir, das Problem zu lösen, indem wir eine Plattform schufen, um Künstlern zu helfen, ihre Werke zu veröffentlichen, deren Verkauf zu fördern und Kontakt mit ihren Kunden zu halten. Dies war unsere Mission, als wir Passi0n4art.c0m starteten und mit der schwierigen Aufgabe begannen, Künstler zum Beitritt zu unserer Website zu bewegen und digitale Bilder ihrer Kunstwerke online zu veröffentlichen. Nachdem wir unsere ersten 1.000 Künstler gewonnen hatten und sie ihre eigenen Websites eingerichtet hatten, waren wir zu der Überzeugung gekommen, wir würden etwas Wertvolles anbieten, und begannen, uns nach Finanzierung von außen umzusehen. Damals (etwa 1999) lieferte uns ein Unternehmen namens eMazing.com täglich Tipps zu einer Vielzahl von Themen, und wir dachten, wir könnten mit ihm eine Partnerschaft eingehen (indem wir mit unseren Künstlern und seinem Distributionskanal arbeiteten), um einen täglichen Kunsttipp zu liefern. Eine seiner Führungskräfte war bereit, sich mit uns zu treffen. Ihm gefiel, was wir anzubieten hatten, und er stimmte einem Probelauf zu.

Umsetzung

Wir erzählten ihm, dass wir Finanzierung von außen suchten, um unsere Infrastruktur auszubauen, und er bot uns freundlicherweise an, unseren Geschäftsplan an einen neuen ortsansässigen Business Accelerator namens bCatalyst weiterzugeben. Einige Tage später rief uns Keith Williams, der CEO von bCatalyst, an. Er wollte uns persönlich kennen lernen und mehr über unser Unternehmen erfahren. Natürlich waren wir sehr gespannt auf dieses Meeting. Ich erkannte erst sehr viel später, wie wichtig es gewesen war, dass er von uns aus einer vertrauenswürdigen Quelle erfahren hatte. Darin ist eine Lektion enthalten: Wenn Sie jemals Kontakt zu einem Venture Capitalist (Risikofinanzier) aufnehmen müssen, bemühen Sie sich ernsthaft um eine positive Empfehlung, da dies die beste Methode ist, den Fuß in die Tür zu bekommen. Im Laufe mehrerer Treffen mit Keith erkannten wir, dass die Chemie zwischen unserem und seinem Team stimmte. Doch die Internet-Blase war vor Kurzem geplatzt und das Timing für eine Investition in diesen Markt war für bCatalyst zu ungünstig. Bei unserem letzten Treffen teilten sie uns mit, dass ihnen unser Team wirklich gefiel, aber sie nicht rechtfertigen konnten, in uns zu investieren. Doch wenn wir ihnen eine andere Idee anbieten könnten, die ihnen gefiel, würden sie nicht zögern, uns zu unterstützen. Ich fragte sie, ob dies eine höfliche Art war, »Nein« zu sagen, oder ob sie ernsthaft daran interessiert waren, mit uns zu arbeiten. Sie versicherten uns, dass sie meinten, was sie sagten. Ich bat dann um ein weiteres Meeting mit Keith und sagte ihm, ich wäre bereit, GE zu verlassen und im Laufe der nächsten Monate in Vollzeit mit seinem Unternehmen zu arbeiten, um zusammen andere Startup-Gelegenheiten zu untersuchen.

| 141

139

139i8- Arbeit automatisieren

Mein Vorschlag war bewusst so formuliert, dass das Angebot für bCatalyst risikoarm war, indem ich mich nicht um eine langfristige Zusage bemühte, sondern einen Erst-ausprobieren-dann-kaufen-Ansatz verfolgte. Sie ergriffen die Gelegenheit, weil ich sie davon überzeugen konnte, dass ich bereit war, mein eigenes Risiko zu tragen, indem ich meinen Abschied von GE nahm, ohne genau zu wissen, was vor mir lag. Im Laufe der nächsten zwölf Monate trafen wir jeden Tag andere Teams, die uns ihre Ideen vortrugen, und ich erkannte in dem Satz von Fragen, die wir jedem Unternehmen vorlegten, ein neues Muster. Ich habe diese Fragen in einer Liste zusammengetragen und gebe sie an Sie weiter, falls Sie jemals in Verlegenheit kommen sollten, einen VC um Finanzierung zu bitten (siehe http: //www. enterprisecorp.com/resources/assessment.htm). Die Fähigkeiten, die ich in diesem Jahr bei bCatalyst erworben hatte, führten mich zu meinem gegenwärtigen Job als Geschäftsführer von Enterprise Corp. Während der letzten sieben Jahre habe ich mit mehr als 1 0 0 Unternehmen gearbeitet und ihnen geholfen, mehr als 75 Millionen Dollar an Finanzierung zu gewinnen. Diese außerordentlich befriedigende Erfahrung wäre nicht möglich gewesen, wenn ich nicht die Initiative ergriffen und den Mut gehabt hätte, Neues auszuprobieren. Die vielen Zicks und Zacks waren ein wesentlicher Bestandteil des Prozesses. Meine Hoffnung ist, das Sie sich als Leser von meiner Geschichte inspirieren lassen, Ihren eigenen einzigartigen Weg zu finden, auf dem Sie Ihre Fähigkeiten bestmöglich entfalten können. Vik Chada ist Geschäftsführer von Enterprise Corp.

Teil 3

Ausführung

Sie haben alle richtigen Investitionen gemacht und den richtigen Markt gefunden. Sie werden beispielsweise ein Experte für die Implementierung von serviceorientierten Architekturen für mit drahtloser Kommunikation arbeitende Anwendungen für Pizzas-Services; und die Pizza-Service-Branche erlebt ein bisher noch nicht da gewesenes Wachstum. Doch bevor Sie sich zu sehr in Ihren Erfolg verlieben, sollte ich Sie warnen: Alles, was ich bis jetzt geschrieben habe, war nur Vorbereitung. Es führte alles nur zu diesem einen Punkt, wo es ernst wird: Sie müssen tatsächlich aktiv werden. Wenn Sie nicht wirklich Glück gehabt haben, werden Sie wahrscheinlich nicht dafür bezahlt, klug zu sein. Und Sie werden nicht dafür bezahlt, ein führender Experte für die neuesten Technologien zu sein. Sie arbeiten für eine Organisation, die höchstwahrscheinlich versucht, Geld zu verdienen. Ihre Aufgabe ist es, etwas dazu beizutragen, dass die Organisation dieses Ziel erreicht. Ihr gesamtes gründliches Nachdenken und Ihre Vorbereitung haben Sie dazu gebracht, zur Arbeit anzutreten und sich für die Ziele Ihres Unternehmens einzusetzen.

Genau wie der Mensch, der im Kapitel Legen Sie nicht alle Eier in den Korb eines anderen weiter vorne ein J2EE-Architekt werden wollte, finden die meisten Menschen ihre Identität nicht in ihren Beziehungen zu den Unternehmen, für die sie arbeiten. Ich meine damit: Man sieht sich als Programmierer, ehe man sich als Person wahrnimmt, die einem Fortune-500-Unternehmen hilft, Geschirrspülmaschinen zu verkaufen, nicht wahr? Man ist ein Anwendungsarchitekt,

kein

Angestellter

eines

Stromversorgers.

Aus

der

Perspektive, die Software-Entwicklung als ein Gewerbe zu betrachten, ist dies nicht allzu überraschend. Das Gewerbe, das wir uns ausgewählt haben, ist normalerweise nicht mit dem Geschäftsbereich gekoppelt, in dem wir unsere Fähigkeiten anwenden. Ein Architekt, der ein Büro für einen Waffenproduzenten entwirft, ist immer noch ein Architekt, kein Waffenlieferant. Dieses Identitätsbewusstsein schafft einige subtile Probleme, weil unsere übergreifenden Ziele mit unseren alltäglichen Verantwortlichkeiten in Konflikt geraten können. Wenn der Architekt ein Büro entwirft, das für einen Waffenproduzenten unbrauchbar ist, hat er keinen Wert geschaffen. Unabhängig von der ästhetischen Schönheit seiner Schöpfung ist er ein schlechter Architekt. Wir werden dafür bezahlt, Werte zu schaffen. Dies bedeutet, dass wir raus aus unserem Lesesesseln müssen und Dinge erledigt bekommen. Um erfolgreich zu sein, kommt man mit bloßen Fähigkeiten nicht weit. Die Zielgerade gehört den Leuten, die Dinge zu Ende bringen können. Dinge zu erledigen, vermittelt ein gutes Gefühl. Menschen finden oft ihren richtigen Arbeitsrhythmus (suchen Sie beispielsweise bei Amazon nach Prokrastination); aber wenn man einmal dieses innere Feuer verspürt, will man nicht mehr aufhören. Lassen Sie uns darum dieses Feuer entzünden.

Der gegenwärtige Moment

A

ngenommen, Sie befänden sich in einem Wettrennen um ein Preisgeld von 1 0 0 . 0 0 0 Dollar. Das erste Team, das Software erstellt, um ein neues Buchhaltungssystem zu imple-

mentieren, gewinnt den Preis. Sie haben sich mit Ihrem Team zur Teilnahme an dem Wettrennen eingeschrieben. Der Wettbewerb findet an einem Wochenende statt. Um zu gewinnen, muss Ihr Code vollkommen ausgetestet sein und einen minimalen Satz spezifizierter Funktionen implementieren. Sie beginnen am Samstagmorgen, und sie haben bis Montagmorgen Zeit, die Anwendung fertigzustellen. Das erste Team, das vor Montagmorgen fertig wird, gewinnt das Rennen. Wenn kein Team vor Montag fertig wird, gewinnt das Team, das die meisten Funktionen implementiert hat. Selbstbewusst blättern Sie die funktionalen Anforderungen der Anwendung durch. Ein Blick auf den Satz der gewünschten Funktionen zeigt Ihnen, dass das zu erstellende System in Größe und Umfang zahlreichen Systemen ähnelt, an denen Sie bereits in der Vergangenheit gearbeitet haben. Während sich Ihr Team das Ziel gesetzt hat, etwa bis Sonntagmittag fertig zu sein, überfallen Sie für einen flüchtigen Moment Zweifel. Wie kann es sein, dass eine Anwendung mit einem ähnlichen Umfang, an der wir im Büro sechs Wochen gearbeitet haben, an einem einzigen Wochenende erledigt werden kann?

146

1 9 - Der gegenwärtige Moment

Doch als die Startglocke läutet und Sie mit dem Codieren beginnen, erkennen Sie, dass Ihr Team tatsächlich in der Lage sein wird, sein Ziel zu erreichen. Das Team befindet sich in einem Arbeitsrausch, erledigt eine Funktion nach der anderen, korrigiert Fehler, trifft kurzfristig Design-Entscheidungen und bringt Dinge zu Ende. Es fühlt sich gut an. Bei Ihren Design-Reviews und Status-Meetings im Büro haben Sie oft dem Tagtraum nachgehangen, ein kleines Team aus der bürokratischen Umgebung herauszulösen und in Rekordzeit eine neue Anwendung rauszupowern. Viele von uns haben diesen Tagtraum. Wir wissen, dass uns unsere Prozesse verlangsamen. Nicht nur das: Wir wissen auch, dass die Geschwindigkeit unserer Umgebungen die Ursache dafür ist, dass wir langsamer arbeiten.

Frage Was können wir tun? In diesem Moment?

Das Parkinson-Gesetz besagt, dass Arbeit sich so weit ausweitet, dass sie die gesamte Zeit ausfüllt, die für ihre Erledigung zur Verfügung steht. Das Traurige ist: Selbst wenn Sie nicht wollen, dass es dazu kommt, können Sie in diese Falle tappen, besonders wenn es um Aufgaben geht, die Sie nicht wirklich anpacken wollen. Bei dem Programmierwettbewerb über ein Wochenende haben Sie keine Zeit, Dinge aufzuschieben. Deshalb tun Sie es auch nicht. Sie können eine Entscheidung nicht aufschieben. Deshalb tun Sie es nicht. Sie können die langweilige Arbeit nicht vermeiden; und Sie wissen, dass Sie sie so schnell erledigen müssen, dass nichts zu langweilig werden kann. Das Parkinson-Gesetz ist eine empirische Beobachtung, kein unausweichliches Gesetz der menschlichen Arbeitswelt. Ein Gefühl der Dringlichkeit, selbst wenn es künstlich erzeugt wird, reicht aus, um Ihre Produktivität leicht zu verdoppeln oder zu verdreifachen. Pro-

Umsetzung

| 147

bieren Sie es aus, und Sie werden sehen, Sie können schneller arbeiten. Sie können jetzt schneller arbeiten. Sie können Dinge erledigen, anstatt darüber zu reden, Dinge zu erledigen. Wenn Sie alle Ihre Projekte wie einen Wettlauf betrachten, erreichen Sie das Ziel sehr viel schneller, als wenn Sie sie wie eine Gefängniszelle behandeln. Schaffen Sie ein Momentum. Seien Sie derjenige, der schiebt. Machen Sie es sich nicht bequem. Seien Sie immer derjenige, der fragt: »Aber was können wir in diesem Moment tun?«

Umsetzung 1. Schauen Sie auf Ihre sprichwörtliche Aufgabenliste. Untersuchen Sie die Aufgaben, die dort bereits seit langer Zeit stehen, die Projekte, die bereits Schimmel ansetzen oder bei denen Sie gerade ein bisschen festhängen,

vielleicht aus bürokratischen

Gründen, vielleicht weil Sie die Analyselähmung gepackt hat. Wählen Sie eine Aufgabe aus, die Sie in den Lücken zwischen Ihrer normalen Arbeit einfach erledigen können, während Sie sonst normalerweise im Web browsen, Ihre E-Mail prüfen oder einfach eine lange Mittagspause machen. Machen Sie aus einem mehrmonatigen Projekt eine weniger als eine Woche dauernde Aufgabe.

Gedankenleser

ch hatte einmal einen Mitarbeiter namens Rao. Rao stammte aus einem südindischen Bundesstaat namens Andhra Pradesh, aber er lebt in den Vereinigten Staaten und arbeitete in unserem Unternehmen. Rao gehörte zu den Programmierern, die jede ihnen vorgesetzte Aufgabe codieren konnten. Wenn Sie eine systemnahe Programmieraufgabe zu lösen hatten, war er Ihr Mann. Brauchten Sie ein allgemeines Anwendungsprogramm,

gab es praktisch

nichts, was er nicht konnte. Doch eines an Rao war wirklich bemerkenswert: Er tat vieles, bevor man ihn danach fragte. Er hatte diese untrügerische Fähigkeit, vorauszusagen und zu erledigen, um was Sie ihn bitten würden, bevor Sie selbst daran dachten. Es hatte etwas Magisches. Ich glaube, ich beschuldigte ihn einmal, er würde mich irgendwie austricksen, was aber eigentlich unmöglich war. Wenn ich beispielsweise sagte: »Rao, ich habe darüber nachgedacht, die Einkapselung des Controllers in unserem Anwendungs-Framework zu ändern. Wenn wir ihn nur ein wenig ändern, könnte er auch für andere Anwendungen und nicht nur für Webanwendungen eingesetzt werden. Was halten Sie davon?« »Das habe ich Anfang der Woche schon gemacht«, war dann einer seiner Standardreaktionen. »Ich habe es in die Versionskontrolle

150

20 - Gedankenleser

eingecheckt. Sie können es sich dort anschauen.« So etwas kam bei Rao laufend vor. Es passierte so oft, dass es nur dann ein Zufall sein konnte, wenn Rao buchstäblich alles Vorstellbare mit jeder Software anstellte, die von unserem Team entwickelt und betreut wurde. Damals leitete ich das Anwendungsarchitekturteam meines Unternehmens. Unter anderem erstellten und warteten wir Frameworks, die in den Anwendungen des Unternehmens eingesetzt wurden. Meine Teamkollegen unterhielten sich sehr oft darüber, wie man die Software-Entwicklung in dem Unternehmen verbessern könnte. Wir sprachen auch häufig über die Rolle unserer zentralen Infrastruktur-Komponenten bei diesen Verbesserungen. Und dabei kam Raos magischer Trick ins Spiel. Er sagte bei diesen Gesprächen nicht viel, war aber auch nicht uninteressiert. Er hörte sorgfältig zu. Und später tat er das, was kein Magier tun sollte: Er teilte mir sein Geheimnis mit. Sein Trick bestand darin, nur Dinge zu tun, von denen ich bereits gesagt hatte, dass ich sie haben wollte. Ich hatte sie nur in einer Art und Weise ausgedrückt, die so subtil war, dass selbst mir nicht bewusst war, dass ich sie gesagt hatte. Beispielsweise warteten wir an der Kaffeemaschine, bis der Kaffee durchgelaufen war, und ich sprach davon, wie großartig es wäre, wenn unser Code insgesamt etwas flexibler wäre. Wenn ich eine solche Idee oft genug oder mit genügend Überzeugung ausdrückte, prüfte Rao wahrscheinlich die Implementierbarkeit zwischen seinen normalen Aufgaben, auch wenn ich sie nicht auf die offizielle Aufgabenliste des Teams gesetzt hatte. Wenn die Aufgabe leicht (und billig) implementiert werden konnte, tat er es einfach und checkte den Code ein.

Merksatz Der Gedankenlesetrick führt bei geschickter Ausführung dazu, dass andere Leute von Ihnen abhängig werden.

Gedankenleser

Gedankenlesen kann nicht nur auf Manager, sondern auch auf Kunden angewendet werden. Wenn sie Ihnen die richtigen Hinweise liefern, können Sie möglicherweise Funktionen vorwegnehmen und hinzufügen, nach denen sie entweder fragen werden oder gefragt hätten, wenn sie ihre Realisierbarkeit erkannt hätten. Wenn Sie immer das tun, was Ihre Kunden von Ihnen erwarten, stellen Sie sie zufrieden. Doch wenn Sie mehr tun, als sie von Ihnen verlangt haben, oder wenn Sie bereits Dinge getan haben, bevor Sie danach gefragt werden, werden Sie Ihre Kunden glücklich machen - es sei denn, Ihre Fähigkeit zum Gedankenlesen ist defekt. Dieser Trick, Gedanken zu lesen, ist nicht absolut sicher. Es handelt sich um einen Drahtseilakt, den Sie nur mit einem Sicherheitsnetz ausführen sollten. Denn dabei bestehen folgende Hauptrisiken (mit einigen vorgeschlagenen Abhilfemaßnahmen): •

Sie geben das Geld des Unternehmens für Arbeit aus, um die Sie niemand gebeten hat. Was ist, wenn Sie falsch liegen? Beginnen Sie klein. Erledigen Sie kleinere Arbeiten, die Sie leicht in den Pausen zwischen Ihren normalen Aufgaben ausführen können, damit die Auswirkungen klein und unerheblich bleiben. Wenn Sie Lust haben, erledigen Sie diese zusätzlichen Aufgaben in Ihrer Freizeit.

•

Wenn Sie Code zu einem System hinzufügen, besteht immer die große Gefahr, seine Anpassungsfähigkeit zu verringern. Vermeiden Sie deshalb Änderungen und Ergänzungen, die auf Gedankenlesen

beruhen

und

die

dem

System

eine

bestimmte

architektonische Struktur aufzwingen oder es auf bestimmte Funktionen festlegen. Wenn die Änderung größere Auswirkungen hat, muss eine Geschäftsentscheidung getroffen werden. Und bei einer solchen Entscheidung sind selten nur die Entwickler gefragt. •

Vielleicht ändern Sie aus eigenen Stücken eine Funktion, nach der Ihr Kunde tatsächlich gefragt hat, in einer Weise, die diese Funktion in einer für Sie unerwarteten Weise für den Kunden

152

20 - Gedankenleser

weniger nützlich oder wünschenswert macht. Hüten Sie sich besonders bei Benutzerschnittstellen vor Vermutungen. Projekte und Menschen zu managen, ist eine herausfordernde Arbeit. Leute, die ein Projekt ohne große Anleitung in die richtige Richtung vorantreiben können, stehen hoch im Kurs und werden von ihren oft überarbeiteten Managern und Kunden geschätzt. Der Trick, Gedanken zu lesen, hat bei richtiger Ausführung zur Folge, dass andere Leute von Ihnen abhängig werden - was ein ausgezeichnetes Rezept für eine Karriere ist, deren Richtung Sie selbst bestimmen. Gedanken lesen zu können, ist eine Fähigkeit, deren Erforschung und Entwicklung sich lohnt.

Umsetzung i. Ein früher Rezensent dieses Buches, Karl Brophey, schlägt vor, für ein Projekt oder ein zu erwartendes System eine Liste anzulegen, in der Sie festhalten, wonach Ihre Anwender und Manager vermutlich fragen werden. Seien Sie kreativ. Versuchen Sie, das System aus ihrem Blickwinkel zu sehen. Nachdem Sie eine Liste mit nicht so offensichtlichen Funktionen erstellt haben, die nachgefragt werden könnten, denken Sie darüber nach, wie Sie die einzelnen Funktionen am effizientesten implementieren könnten. Denken Sie auch an Grenzfälle, an die die Benutzer möglicherweise nicht sofort gedacht haben. Wenn Sie die Projekt- oder Verbesserungsanforderungen durcharbeiten, halten Sie Ihre Trefferquote fest. Wie viele Ihrer Vermutungen betrafen Funktionen, um deren Implementierung Sie später tatsächlich gebeten wurden? Wenn die von Ihnen vermuteten Funktionen tatsächlich nachgefragt wurden, konnten Sie dann die Ideen verwenden, die Sie bei Ihrem Brainstorming entwickelt hatten?

Täglicher Hit

eder glaubt gern, er könne aufgrund seines Wissens und seiner

J

Fähigkeiten als guter Software-Entwickler Projekte im Handum-

drehen mit einer Spitzenleistung erledigen. Für einige Glückliche (und ich meine hier das Wort Glück) funktioniert eine solche

Strategie. Doch jeder kann davon profitieren, seine Aufgaben und Erfolge zu

planen und zu überwachen. Der gesunde Menschenverstand sagt uns, dass wir in der Gunst unserer Manager ganz oben stehen werden, wenn wir seine Erwartungen übertreffen. In Anbetracht der Erkenntnis, dass das Übertreffen der Erwartungen ein lohnenswertes Ziel ist, haben überraschend wenige einen Mechanismus, mit dem sie nachhalten, wie und wann sie die Erwartungen ihres Arbeitgebers übertroffen haben. Wie bei den meisten Aufgaben, die zu erledigen sich lohnt, wird die Wahrscheinlichkeit, konstant herausragende Leistungen abzuliefern, mit einer bestimmten gezielten Methodik erhöht. Wann haben Sie zum letzten Mal mehr getan, als die Pflicht von Ihnen verlangte? Hat Ihr Manager davon erfahren? Wie können Sie die sichtbaren I nstanzen dieses Verhaltens vergrößern? james McMurry, ein Mitarbeiter und guter Freund (www.semanticnoise.com), erzählte mir sehr früh in unser beider Karriere von

2i - Täglicher Hit

einem System, das er entwickelt hatte, um gute Arbeit zu leisten. In Anbetracht seiner jungen Jahre zeigte es meiner Meinung nach eine bemerkenswert reife Einsicht (vielleicht war es ein Tipp, den er von seinen Eltern bekommen hatte). Ich benutze dieses System bis heute. Ohne seinen Manager zu informieren, begann er, seine täglichen Hits festzuhalten. Sein Ziel bestand darin, jeden Tag etwas Außerordentliches zu leisten, das er seinem Manager mitteilen konnte - eine Idee, die ihm eingefallen war oder die er implementiert hatte, um seine Abteilung zu verbessern.

Eine Woche mit Hits Einfach ein Ziel zu setzen (täglich, wöchentlich oder was immer in Ihren Zeitplan passt) und diese Art von Erfolgen nachzuhalten, kann Ihr Verhalten radikal verändern. Wenn Sie anfangen, nach herausragenden Leistungen zu suchen, bewerten und priorisieren Sie auf natürliche Weise Ihre Aktivitäten nach dem Mehrwert, den sie zu Ihrer laufenden Arbeit beitragen. Wenn Sie auf diese Weise Hits genügend oft überwachen, sorgen Sie dafür, dass Sie nicht irgendwo hängenbleiben: Wenn Sie einen Hit pro Tag produzieren sollen, können Sie nicht zwei Wochen damit verbringen, die Lösung einer Aufgabe zu

perfektionieren.

Diese Art zu denken und zu arbeiten wird zur Gewohnheit; sie ist kein größerer Kraftakt. Und wie ein Entwickler süchtig nach dem grünen Balken einer Unit-Test-Suite wird, beginnen Sie unruhig zu

Umsetzung

| 155

werden, wenn Sie Ihren täglichen Hit noch nicht produziert haben. Sie müssen sich nicht mehr so sehr darum sorgen, Ihren Fortschritt zu überwachen, weil das Arbeiten auf diesem Niveau eher einem nervösen Tick ähnelt als einem Satz von Aufgaben, die mit Microsoft Project geplant werden müssen.

Umsetzung 1. Reservieren Sie auf Ihrem Kalender eine halbe Stunde. Setzen Sie sich mit Papier und Bleistift an einen ruhigen Ort, an dem Sie nicht gestört werden. Denken Sie über die lästigen kleinen Probleme nach, mit denen sich Ihr Team täglich auseinandersetzen muss. Schreiben Sie sie auf. Was sind die ärgerlichen Aufgaben, mit denen jeden Tag einige Minuten der Zeit Ihres Teams verschwendet werden, aber für die niemand die Zeit oder Energie aufwendet, um sie abzustellen? Wo erledigen Sie in Ihrem laufenden Projekt Aufgaben manuell, die automatisiert werden könnten? Schreiben Sie sie auf. Was ist mit Ihrem Build- oder Deployment-Prozess? Können Sie Abläufe verschlanken? Können Sie die Anzahl der Fehler bei Ihrem Build reduzieren? Schreiben Sie alle diese Ideen auf. Reservieren Sie für die folgende Aufgabe zwanzig Minuten. Schreiben Sie alle Ihre - guten oder schlechten - Ideen auf. Hören Sie erst nach zwanzig Minuten auf. Nachdem Sie Ihre Liste erstellt haben, schreiben Sie Ihre fünf liebsten (und ärgerlichsten) Punkte auf ein neues Blatt Papier. Nehmen Sie sich am Montag der nächsten Woche den ersten Punkt dieser Liste vor und machen Sie etwas damit. Nehmen Sie am Dienstag den zweiten, am Mittwoch den dritten usw.

| KAPITEL17|

Vergessen Sie nicht, für wen Sie arbeiten

s lässt sich wirklich leicht sagen: »Sorgen Sie dafür, dass Ihre

E

Ziele und Ihre Arbeit in Einklang mit den Zielen Ihres Unter-

nehmens stehen.« Es ist wirklich leicht zu sagen; doch es ist

nur schwer umzusetzen, insbesondere wenn Sie als Programmierer unter so vielen organisatorischen Schichten begraben sind, dass Sie kaum wissen, worin das Geschäft Ihres Unternehmens besteht. Am Anfang meiner Karriere arbeitete ich für ein größeres Logistikunternehmen in einem Team, das für die Entwicklung von SoftwareArchitekturen zuständig war. Dieses Unternehmen war hierarchisch so straff organisiert, dass ich in meiner täglichen Arbeit nie den geringsten Einblick in das Geschäftsgebiet - die Auslieferung von Paketen - erhielt. Ich erinnere mich, wie ich mit meinem Team am vierteljährlichen Erfolgsmeeting teilnahm und mich vollkommen fehl am Platz und entfremdet fühlte: »Welchen Erfolg feiern wir hier eigentlich? Was bedeuten all die Zahlen?« Zugegeben, an diesem Punkt meiner Karriere war ich mehr daran interessiert, elegante Systeme zu entwerfen und Open-Source-Software zu hacken, als mich mit den Details der Paketauslieferung zu beschäftigen. (Okay, ich gebe zu, dass ich immer noch stärker an jenen Dingen interessiert bin.) Doch ich bin nicht sicher, dass ich gewusst hätte, wo ich hätte anfangen müssen, wenn ich wirklich

i 8 5

22 - Vergessen Sie nicht, für wen Sie arbeiten

den Wunsch gehabt hätte, meine Arbeit mit den Hauptzielen des Unternehmens in Einklang zu bringen. Deshalb ist es zwar schön zu sagen, wir sollten unsere Arbeit mit den Zielen des Unternehmens in Einklang bringen - wir sollten versuchen, unseren Beitrag zu der Zahl unterm Strich zu leisten und all das. Doch, um die Wahrheit zu sagen: Viele haben aus ihrer Perspektive keinen Einblick, wie sie dies überhaupt tun könnten. Sie sehen den Wald vor lauter Bäumen nicht. Vielleicht ist dies nicht unsere Schuld. Vielleicht verlangen wir zu viel von uns. Vielleicht ist die Idee, direkt etwas zum Gewinn des Unternehmens beitragen zu wollen, ein wenig vergleichbar damit, zu versuchen, den Ozean zum Kochen zu bringen. Deswegen müssen wir kleinere abgegrenzte Bereiche ins Auge fassen und das Geschäft in Komponenten zerlegen, die wir tatsächlich überblicken können. Es liegt nahe, dabei mit unserem eigenen Team anzufangen. Es ist wahrscheinlich klein und fokussiert genug, um seinen Zweck und seine Funktion zu verstehen. Höchstwahrscheinlich verstehen Sie die Probleme, mit denen es sich auseinandersetzen muss. Seine Aufgaben sind klar: Es soll die Produktivität oder die Erträge verbessern, die Fehlerzahl reduzieren usw. Und wenn Sie nicht sicher sind, gibt es einen verbindlichen Ansprechpartner: Ihren Vorgesetzten. Letztlich decken sich in einer wohlstrukturierten Umgebung die Ziele Ihres Vorgesetzten mit denen Ihres Teams. Wenn Sie ein Problem Ihres Managers lösen, haben Sie ein Problem des Teams gelöst. Und wenn Ihr Manager nach demselben Prinzip wie Sie arbeitet, sind die Probleme, die Sie für ihn lösen, tatsächlich die Probleme seines Chefs usw. usw., bis hin zur höchsten Ebene Ihres Unternehmens - dem Vorstandsvorsitzenden, den Shareholdern oder sogar Ihren Kunden. Mit Ihrer kleinen Leistung tragen Sie zur Erfüllung der Ziele Ihres Unternehmens bei. Dies kann Ihnen ein Gefühl der Zweckgerichtetheit und Ihrer Arbeit einen Sinn geben.

i5822-Vergessen Sie nicht, für wen Sie arbeiten

Einige widersetzen sich vielleicht dieser Strategie: »Diese Arbeit werde ich für ihn nicht tun« oder: »Sie heimst ja doch nur das Lob für meine Arbeit ein!« Nun, da ist was dran. So läuft es nun mal. Die Rolle eines guten Managers besteht nicht darin, wie Lister und DeMarco in Peopleware [DL99] schreiben, »den Ausputzer zu spielen«, der alle Aufgaben seines Teams lösen kann und eingreift, wenn es schwierig wird. Die Rolle eines guten Managers besteht darin, Prioritäten für sein Team zu setzen, dem Team alle zur Erledigung seiner Aufgaben benötigten Mittel bereitzustellen, die Motivation und Produktivität seines Teams zu erhalten und letztlich den Job zu erledigen. Ein Job, der von dem Team gut erledigt wurde, ist ein Job, der von den Managern gut erledigt wurde.

Merksatz Die Erfolge Ihres Vorgesetzten sind Ihre Erfolge.

Wenn es die Aufgabe des Managers ist, Prioritäten zu kennen und zu setzen, aber nicht persönlich die gesamte Arbeit zu leisten, dann ist es Ihr Job, die gesamte Arbeit zu leisten. Sie leisten nicht die Arbeit Ihres Vorgesetzten für ihn. Sie leisten Ihre Arbeit. Wenn Sie sich wirklich darum sorgen, wer das Lob einheimst, denken Sie daran, dass es Ihr Manager ist, der den Schlüssel zu Ihrer Karriere in seiner Hand hält (zumindest in Ihrem jetzigen Unternehmen). In den meisten Unternehmen beeinflusst der unmittelbare Vorgesetzte die Leistungsbeurteilung,

Gehaltserhöhungen,

Boni und Beförderungen. Deshalb müssen Sie das Lob, das Sie beanspruchen, letztlich mit Ihrem Vorgesetzten abrechnen. Vergessen Sie nicht, für wen Sie arbeiten. Sie passen sich nicht nur an die Anforderungen des Unternehmens an, sondern Sie passen auch das Unternehmen an Ihre Anforderungen an. Aufgaben, die Sie in Ihrem Job gut erledigen, sind auch Aufgaben, die Siefitr sich erledigen.

i58 22 - Vergessen Sie nicht, für wen Sie arbeiten

Umsetzung i. Bitten Sie Ihren Vorgesetzten um eine Unterredung. Ihre Agenda soll darin bestehen, die das Team betreffenden Ziele Ihres Vorgesetzten für den kommenden Monat, das kommende Quartal und das kommende Jahr zu verstehen. Fragen Sie, welchen Beitrag Sie leisten können. Analysieren Sie nach dem Meeting, wie Ihre tägliche Arbeit zu den Zielen Ihres Teams passt. Verwenden Sie die Ziele als Filter für alle Ihre Aufgaben. Priorisieren Sie Ihre Arbeit anhand dieser Ziele.

Bei der Sache bleiben

A

ls Manager ist es meiner Erfahrung nach das Frustrierendste, mit einem Mitarbeiter umzugehen, der immer nach der nächsten Stufe auf der Karriereleiter strebt. Sie

kennen den Typ: Sie können mit ihm nicht eine Stunde zum Mittagessen zusammensitzen, ohne dass er darauf zu sprechen kommt, wer wann von wem warum befördert worden ist. Er kennt immer den neuesten Büroklatsch und scheint sich für die interne Politik des Unternehmens zu interessieren, als handelte es sich um eine Soap Opera, nach der man heimlich süchtig ist. Er beschwert sich über die Inkompetenz des Managements und erledigt seine Aufgaben mit dem bitteren Gefühl, dass er den Job des Managements viel besser erledigen könnte. Es wäre einfach zu inkompetent, sein Potenzial zu erkennen. Er glaubt, viele Aufgaben lägen unter seiner Würde. Er vermeidet sie, wenn es möglich ist, und erledigt sie widerwillig (und langsam), wenn es nicht möglich ist. Er pickt sich die Aufgaben heraus, von denen er, und sei es auch nur unbewusst, glaubt, sie würden seinem Niveau entsprechen und ihm seinem Ziel der nächsten Beförderung näherbringen.

162

23 - Bei der Sache bleiben

Merksatz Seien Sie ehrgeizig, aber posaunen Sie es nicht hinaus.

Das Traurige mit solchen Leuten ist: Weil sie gedanklich schon in ihrem nächsten Job leben, leisten sie normalerweise in ihrer gegenwärtigen Rolle nur Mittelmäßiges. Es ist wie bei mir mit dem Rasenmähen. Ich hasse es, den Rasen zu mähen. Es macht mich nervös und bringt mich zum Schwitzen. Und was am schlimmsten ist: Es hält mich davon ab, etwas zu tun, was ich lieber tun würde. Ich könnte Leute engagieren und den Rasen mähen lassen. Ich war einer dieser Leute. Das ist schon lange her, und jetzt habe ich meinen Abschluss gemacht. Was tue ich also, wenn ich den Rasen mähen muss? Ich beeile mich. Ich mähe nachlässig. Ich denke die ganze Zeit daran, wie ich fertig werden kann, damit ich zu dem komme, was ich lieber tun würde. Kurz gesagt: Der Rasen sieht hinterher schrecklich aus. Glücklicherweise schaut mir in dem Beispiel mit dem Rasenmähen niemand zu und bewertet meine Leistung (obwohl meine Frau sich so darüber geärgert hat, dass ich nicht mehr für den Rasen rund um unser Haus verantwortlich bin). Es ist mein Problem, wenn der Rasen am Ende scheußlich aussieht. Niemand nagelt mich wegen meiner mittelmäßigen Leistung darauf fest, »nur ein Rasenmäher« zu sein. Doch bei einem IT-Job kann dasselbe Verhalten zu fatalen Folgen für die Karriere führen. Betrachten wir noch einmal unseren Freund aus den vorigen Absätzen. Was glauben Sie, wie er von seinem Management beurteilt wird? Wird man einsehen, dass man ihn falsch eingeschätzt und seine Brillanz übersehen hat, und ihn deshalb befördern? Wird man ihm eine große Gehaltserhöhung geben, um zu versuchen, ihn glücklich zu machen? Natürlich nicht. Er leistet mittelmäßige Arbeit und hat eine schlechte Einstellung. Was bringt es also, wenn er ein großes Potenzial hat! Im Moment zeigt er es jedenfalls nicht. Das Unternehmen

Bei der Sache bleiben

163

verdient aufgrund dieses Potenzials kein Geld. Shareholder halten ihre Investitionen nicht, wenn deren Potenzial nicht erfüllt wird. Darüber hinaus führt seine Einstellung dazu, dass er seinen Vorgesetzten jeden Anreiz nimmt, in ihn zu investieren. Das ist also der Standpunkt des Managements. Natürlich bin ich hier nicht ganz ohne Schuld. Bis zu einem gewissen Ausmaß war ich selbst dieser Typ. Und von dieser Seite der Straße sieht auch nicht alles sehr rosig aus. Sie verbringen Ihre gesamte Zeit damit, etwas zu wollen. Begierde ist das Gegenteil von Zufriedenheit. Sie wachen morgens auf und müssen »diesen verdammten Job« antreten, bei dem niemand Ihr Potenzial erkennt. Sie erledigen Ihre Arbeit nur widerwillig und wälzen in Ihrem Kopf Strategien, wie Sie befördert werden könnten. Sie fantasieren darüber, was Sie in der letzten Situation getan hätten, die Ihr Manager an die Wand gefahren hat - wie Sie das Ganze anders gehandhabt hätten. Sie schieben es auf, bei der Arbeit zu leben, bis Sie auf Ihre Weise in einer Position arbeiten können, die Sie verdienen. Hier ist ein Geheimnis: Dieses Gefühl wird nie verschwinden. Falls und wenn Sie endlich die große Beförderung bekommen, von der Sie geträumt haben, bekommen Sie bald zu viel davon und erkennen, dass es nicht dieser Job ist, für den Sie geschaffen wurden - es ist der nächste Job. Der Zyklus beginnt von vorne. Ich habe die Spitze noch nicht erreicht, aber ich habe die dunkle Ahnung, dass ich, wäre ich in einer solchen Position und sollte ich sie erreichen, mich umschauen und erkennen würde, einem Geist nachgejagt zu sein. Was für eine frustrierende Verschwendung eines Berufslebens. Aber sollte man nicht Ambitionen haben? Wo wären Microsoft oder General Electric, wenn die großartigen Unternehmer keine Ambitionen und Ziele gehabt hätten? Natürlich sollten wir. Ich plädiere hier nicht für eine apathische Einstellung. Es ist gut, Ziele zu haben, und es ist gut, Erfolg haben zu wollen. Doch denken Sie an den negativen, widerwilligen Typ, den

164

23 - Bei der Sache bleiben

ich am Anfang dieses Kapitels beschrieben habe. Glauben Sie, dass dies der Typ ist, der Erfolg haben wird? Es scheint genau umgekehrt zu sein: Wenn man sein Denken fest auf die Gegenwart richtet, kommt man schneller zu seinen Zielen, als wenn man an diese selbst denkt. Es hört sich anfanglich schwierig an. Fast wie eine Einstellung eines Mönches. Den täglichen Drang zum Erfolg abzuwerfen, hört sich vielleicht wie ein asketisches, unerreichbares Ziel an. Doch Sie werden feststellen, dass es sehr pragmatisch ist. Wenn Sie sich auf die Gegenwart konzentrieren, können Sie die kleinen Siege in Ihrer täglichen Arbeit genießen: das Gefühl, eine Aufgabe gut gelöst zu haben; das Gefühl, als Experte zu einem schwierigen Geschäftsproblem hinzugezogen zu werden; das Gefühl, ein integrales Mitglied eines funktionierenden Teams zu sein. Diese Dinge verpassen Sie, wenn Sie immer mit dem Kopf im Wolkenkuckucksheim herumlaufen. Sie warten immer auf das eine Große, während Sie die kleinen Dinge ignorieren, die jeden Tag passieren und Ihren Job ausführenswert machen. Und Sie werden sich nicht nur allein besser fühlen, sondern auch den Leuten in Ihrer Umgebung wird es so gehen. Ihre Mitarbeiter, Manager und Kunden werden es spüren. Es wird sich in Ihrer Arbeit niederschlagen. So unintuitiv es scheinen mag: Den Wunsch nach Erfolg loszulassen, verbessert Ihre Fähigkeit, Erfolg zu haben. Sie sind Ihren Kunden nahe. Sie sind den Leitern und Entscheidern nahe, die kurzfristig und möglicherweise auch langfristig Ihre Karriere beeinflussen. Entwickler in Indien oder auf den Philippinen haben diesen Vorteil nicht, aber Sie haben ihn. Seien Sie deshalb bei der Sache.

Umsetzung 1. Schieben Sie Ihre Karriereziele für eine Woche beiseite. Schreiben Sie Ihre Ziele für den laufenden Job auf. Anstatt daran zu denken, wo Sie als Nächstes hingehen wollen, denken Sie darü-

Umsetzung|166

ber nach, was Sie erreicht haben werden, wenn Sie Ihren gegenwärtigen Job erledigt haben. Was könnten Sie in diesem Job Herausragendes produziert haben? Stellen Sie einen Plan auf, der sowohl strategisch als auch taktisch ist. Verbringen Sie die Woche damit, diese Taktiken zu implementieren, um das langfristige Ziel zu unterstützen, diesen Job zu erledigen. Konzentrieren Sie sich in den Gesprächen mit Kollegen während des Mittagessens und in den Pausen auf diese Ziele. Lenken Sie sich selbst und Ihre Gesprächspartner weg von Gesprächen über Beförderungen oder Büropolitik und Klatsch. Geben Sie sich am Ende der Woche Rechenschaft über Ihren Fortschritt bei der Erreichung dieser Job-Ziele. Wie lange wird es dauern, bis Sie alles erreicht haben, was Ihrer Meinung nach in Ihrer gegenwärtigen Rolle erforderlich ist? Wie erkennen Sie, dass Sie fertig sind? Planen Sie die nächste Woche und wiederholen Sie das Ganze.

Wie gut kann ich meine Arbeit heute erledigen?

s macht zufrieden, gute Arbeit zu leisten und anerkannt zu

E

werden. Obwohl die meisten dies intuitiv wissen, sind sie oft sehr wählerisch, wenn es darum geht, wann und wo sie wirk-

lich Herausragendes leisten wollen. Wir schwärmen für das Design des

Nächsten-Großen-Dingsda-Projekts

der

Marketingabteilung

oder sind schnell bereit, bei einer großen sichtbaren Katastrophe Hilfe anzubieten, weil unsere Gehirne so verdrahtet sind, dass wir diese Momente als Gelegenheiten erkennen, um uns hervorzutun. Dann arbeiten wir sogar mitten in der Nacht mit einer Konzentration und Detailversessenheit auch an Aufgaben, bei den wir normalerweise vor Langeweile am liebsten eingehen würden. Eine gefährliche Situation bringt oft das Beste in uns hervor. Ich habe mich schon von diesem berauschenden Gefühl der Euphorie wachhalten und wirksam durch einige der mörderischsten Systemausfälle und verpassten Abgabetermine tragen lassen. Warum können wir, ohne großem Druck ausgesetzt zu sein, uns oft nicht in einen solchen selbstvergessenen, ultraproduktiven Arbeitsrausch bringen? Wie gut würden Sie arbeiten, wenn Sie die uninteressantesten und ärgerlichsten Aufgaben mit demselben fiebrigen Eifer anpacken könnten, alles richtig zu machen?

168

24 - Wie gut kann ich meine Arbeit heute erledigen?

Frage Wie viel mehr Spaß könnten Sie bei Ihrer Arbeit haben?

Die letzte Frage ist vielleicht in anderer Form besser zu verstehen. Wie viel mehr Spaß würde Ihnen die Arbeit machen, wenn Sie die uninteressantesten und ärgerlichsten Aufgaben mit demselben fiebrigen Eifer anpacken könnten, alles gut und richtig zu machen? Wenn wir mehr Spaß haben, arbeiten wir besser. Deshalb sind wir gelangweilt, wenn wir kein Interesse an einer Aufgabe haben. Folglich leidet unsere Arbeit. Wie können Sie einer langweiligen Arbeit mehr Spaß abgewinnen? Die Antwort auf diese Frage ist offensichtlicher, wenn Sie sie umgekehrt formulieren. Warum

ist langweilige

Arbeit

langweilig?

Warum macht sie nicht bereits Spaß? Wodurch unterscheidet sich Arbeit, die Sie gerne machen, von Arbeit, die Sie verabscheuen? Für die meisten technisch Orientierten ist die langweilige Arbeit aus zwei Hauptgründen langweilig. Bei Arbeit, die wir lieben, können wir unsere kreativen Muskeln spielen lassen. Software-Entwicklung ist ein kreativer Akt, und viele Entwickler fühlen sich aus diesem Grund zu ihr hingezogen. Arbeit, die wir nicht mögen, ist in unseren Augen von Natur aus selten kreativ. Denken Sie einen Moment darüber nach. Denken Sie darüber nach, was auf Ihrer Aufgabenliste für die nächste Arbeitswoche steht. Bei den Aufgaben, die Sie gerne verschieben, müssen Sie wahrscheinlich Ihr Vorstellungsvermögen kaum anstrengen. Es handelt sich einfach um Dinge, die erledigt werden müssen und die Sie am liebsten jemand anderem übertragen würden. Der zweite Grund, warum langweilige Aufgaben langweilig sind, ist zugegebenermaßen eng mit dem ersten verbunden: Langweilige Aufgaben stellen keine Herausforderung dar. Wir lieben es, ein schwieriges Problem zu lösen, an dem andere gescheitert sind. Es ist dasselbe Gefühl, das andere Angehörige unserer Spezies dazu

16924-Wie gut kann ich meine Arbeit heute erledigen?

treibt, in ihrer Freizeit ihr Leben beim Bergsteigen oder BungeeSpringen von Brücken zu riskieren. Wir lieben es, Dinge zu tun, um zu beweisen, dass wir dazu fähig sind. Die langweiligen Aufgaben sind normalerweise trivial. Sie zu erledigen, bedeutet eine ähnliche Herausforderung, wie den Müll aus der Wohnung zu tragen. Wie also können wir immer noch unsere Kreativität herausfordern, während wir uns mit den banaleren Restaufgaben unseres Arbeitstages befassen (die wahrscheinlich bei den meisten mehr als 80 Prozent der Gesamtzeit ausmachen)? Was wäre, wenn Sie versuchten, langweilige Aufgaben perfekt zu erledigen? Angenommen etwa, Sie hassten das Unit-Testing. Sie lieben das Programmieren, aber Sie ärgern sich darüber, dass Sie automatisierten Testcode schreiben müssen. Was wäre, wenn Sie sich darum bemühten, perfekte Tests zu schreiben? Wie könnte dies Ihr Verhalten ändern? Was bedeutet perfekt beim Unit-Testing? Wahrscheinlich hat es etwas mit Test-Coverage (Testabdeckung) zu tun. Eine perfekte Testabdeckung würde bedeuten, dass Sie 100 Prozent der Funktionalität Ihres echten Codes testen. Perfekte Unit-Tests sind sauber und wartbar und hängen nicht von vielen externen Faktoren ab, die man nur mit Schwierigkeiten auf einem anderen Computer reproduzieren könnte. Sie sollten direkt ausführbar sein, nachdem auf einem neuen Computer eine frische Version der Software aus der Versionskontrolle ausgecheckt worden ist. Und natürlich sollten alle Tests hundertprozentig bestanden werden. Das wird schon schwieriger; eine hundertprozentige Testabdeckung hört sich fast unmöglich an. Und die Aufgabe, Tests so zu entkoppeln, dass sie ohne Dependencies ausgeführt werden können, ist mit zahlreichen Schwierigkeiten verbunden. Tatsächlich müssen Sie wahrscheinlich Ihren Code ändern, um dies überhaupt zu ermöglichen. Doch wenn Sie dies könnten, würden die Tests unglaublich sein. Ich weiß nicht, wie es Ihnen geht, aber mir könnte eine solche Aufgabe Spaß machen. Zugegeben, das Beispiel ist konstruiert, aber Sie

170

24 - Wie gut kann ich meine Arbeit heute erledigen?

können dieselbe Denke auf die meisten Aufgaben anwenden, die Ihren Weg kreuzen. Probieren Sie es morgen aus. Schauen Sie sich Ihren Arbeitstag an und fragen Sie sich: »Wie gut kann ich heute arbeiten?« Sie werden feststellen, dass Sie mehr Spaß an Ihrer Arbeit haben werden und dass Ihre Arbeit mehr Spaß an Ihnen haben wird. (Ich danke Andy Hunt für diese Idee; siehe http://bl0g.t00lshed.c0m/2003/07/h0w_g00d_a_j0b_.html.)

Umsetzung 1. Machen Sie es sichtbar - machen Sie aus diesen langweiligen Aufgaben einen Wettbewerb unter Kollegen. Stellen Sie fest, wer sie besser erledigen kann. Sie schreiben nicht gerne Unit-Tests? Drucken Sie die Anzahl der Test-Assertions für den Code aus, den Sie jeden Tag einchecken, und hängen Sie sie an eine Wand Ihres Büros oder Kubikels. Führen Sie eine Punkteliste für das gesamte Team. Konkurrieren Sie um das Recht anzugeben (oder sogar um Preise). Vereinbaren Sie beispielsweise, dass der Gewinner am Ende eines Projekts seine gesamten ungeliebten Aufgaben eine Woche lang an den Rest des Teams delegieren darf.

Was sind Sie wert?

aben Sie sich eigentlich jemals überlegt, wie viel genau Sie

H

das Unternehmen kosten, für das Sie arbeiten? Natürlich

kennen Sie Ihr Gehalt. Das ist einfach. Aber was ist mit

anderen Zuwendungen, dem Verwaltungsaufwand, Schulungsaufwendungen und all den anderen Sachen, die nicht notwendigerweise auf Ihrem Gehaltsscheck ausgewiesen werden? Es ist leicht, die Einstellung zu entwickeln, einfach mehr haben zu wollen. Leider scheint dies eine grundlegende menschliche Grundneigung zu sein. Ihr Gehalt wird erhöht, und eine Zeit lang fühlen Sie sich gut. Doch dann fangen Sie an, über die nächste Erhöhung nachzudenken. »Wenn ich nur zehn Prozent mehr verdienen würde, könnte ich mir dieses neue ...« Wir kennen das alle. Irgendwann wird die tatsächliche Zahl abstrakt. Es geht nicht darum, 5.000 € mehr pro Jahr zu verdienen, sondern darum, dass die Zahl überhaupt größer wird. Wenn wir in einem Jahr keine zufriedenstellende Gehaltserhöhung bekommen, werden wir mit unserer Arbeit und unserem Unternehmen unzufrieden. »Warum schätzt man mich nicht?« Wie viel kosten Sie wirklich? Wie ich bereits erwähnt habe, bestehen die Kosten nicht nur aus Ihrem Grundgehalt. Schätzen wir zum Zweck der Diskussion die Kosten etwa doppelt so hoch wie Ihr

172

25 - Was sind Sie wert?

Grundgehalt ein. Wenn Sie also 6 0 . 0 0 0 € pro Jahr verdienen, gibt das Unternehmen tatsächlich 1 2 0 . 0 0 0 € für Sie aus. Das war leicht. Nun der schwierige Teil: Welchen Wert haben Sie im letzten Jahr produziert? Wie hoch war Ihr positiver Beitrag zum Gewinn des Unternehmens? Wir wissen bereits, dass Sie das Unternehmen (in unserem angenommenen Szenarium) etwa 1 2 0 . 0 0 0 € kosten. Was haben Sie dafür zurückgegeben? Wie viel Geld konnte das Unternehmen durch Sie sparen? Wie viel mehr Erträge konnte es durch Sie erwirtschaften? Ist diese Zahl mehr als doppelt so groß wie Ihr Gehalt? Diese Aufgabe zu lösen, ist schwierig; denn es ist oft nicht leicht, jeden Aspekt Ihrer Arbeit mit dem Gewinn des Unternehmens in Beziehung zu setzen. Vielleicht scheint Ihnen sogar die Frage abwegig zu sein. »Woher soll ich das wissen? Ich bin nur ein Codierer!« Natürlich ist genau das der Punkt. Sie arbeiten für ein Unternehmen, und solange Sie nicht einen echten Mehrwert beitragen, sind Sie eine Geldverschwendung. Man tappt leicht in die Falle zu denken, Gehaltserhöhungen würden einem zustehen. Analog hätte ein Unternehmen das Recht, jedes Jahr höhere Preise für seine Produkte zu verlangen. Doch Konsumenten haben das Recht, diese Produkte nicht zu kaufen, wenn der Preis nicht attraktiv ist. Nachdem Sie angefangen haben, darüber nachzudenken, welche Kosten Sie verursachen und welchen Mehrwert Sie beitragen, sollten Sie sich fragen, welchen Mehrwert Sie Ihrer Meinung nach liefern müssten, damit Sie als lohnenswerte Investition des Unternehmens betrachtet werden. Wir haben eine Zahl genannt, die etwa doppelt so hoch wie Ihr Gehalt ist; aber ist das genug? Wenn Sie einen Mehrwert liefern, der doppelt so hoch wie Ihr Gehalt ist, hat das Unternehmen nur seinen Break-even-Punkt erreicht. Ist dies eine gute Methode, Geld auszugeben? Vergleichen Sie dies mit dem Zinssatz normaler Sparkonten. Es ist nicht berauschend, nicht wahr? Dennoch ist der Wert immer noch besser als null. Drei Prozent Zinsen sind immer noch besser als

Umsetzung

| 173

null Prozent. Wenn Ihr Mehrwert nur das Doppelte Ihres Gehalts beträgt, ist dies für ein Unternehmen genau so unattraktiv wie ein Sparkonto mit null Prozent Zinsen für Sie. Das Unternehmen muss 1 2 0 . 0 0 0 € Bargeld pro Jahr für Sie aufwenden, und Sie liefern nicht einmal genug Gegenwert, um die Inflationsrate auszugleichen. Ein Break-even ist in diesem Fall tatsächlich immer noch ein Verlust. Ich erinnere mich, als ich anfing, so zu denken. Am Anfang machte es mich paranoid. Wenn ein Monat vorbei war, dachte ich: »Was habe ich diesen Monat geliefert?« Dann begann ich sogar, kleinere Zeitabschnitte - Wochen oder sogar Tage - auf diese Weise zu betrachten: »Hat sich dieser Tag gelohnt?«

Merksatz Fragen Sie sich »Hat sich dieser Tag gelohnt?«

Sie können dies konkretisieren. Wie hoch ist der Wert, den Sie tatsächlich beitragen? Sprechen Sie mit Ihrem Vorgesetzten, wie Sie diesen Wert am besten quantifizieren können. Allein die Tatsache, dass sie ihn quantifizieren wollen, wird als gutes Zeichen gewertet. Wie könnten Sie dem Unternehmen kreativ Geld sparen? Wie könnten Sie Ihr Entwicklungsteam effizienter machen? Oder was ist mit den Endanwendern Ihrer Software? Sie werden überrascht sein, wie viele Gelegenheiten Sie entdecken, wenn Sie anfangen, diese Fragen zu stellen. Dann sollten Sie beginnen, einige Antworten zu implementieren. Behalten Sie immer diese Zahl im Kopf: doppelt so viel wie mein Gehalt. Lassen Sie nicht nach, bis Sie diese Zahl für das laufende Jahr überschritten haben.

Umsetzung 1. Unternehmen wollen ihr Geld bestmöglich investieren. Die Kapitalrendite

(Return-On-Investment;

ROI;

Sie

investieren

1 0 0 € und erhalten 120 € zurück) allein reicht nicht aus, um

25 - Was sind Sie wert?

174

intelligente Entscheidungen zu treffen. Das Unternehmen muss auch noch andere Faktoren berücksichtigen, etwa die Inflationsrate, die Opportunitätskosten oder das Risiko. Ein Konzept ist für Leute, die sich nicht eingehender mit wirtschaftlichen Fragen beschäftigt haben, besonders schwer zu verstehen: der Zeitwert des Geldes. Auf das Risiko hin, den Begriff zu sehr zu vereinfachen, bedeutet er Folgendes: Ein Euro heute ist mehr wert als ein Euro im nächsten Jahr, weil ein Euro heute dazu benutzt werden kann, mehr Euros zu generieren. Die meisten Unternehmen setzen sich eine Renditegrenze fest, unter der Investitionen nicht geleistet werden. Investitionen müssen eine vereinbarte Rendite innerhalb einer vereinbarten Zeitspanne bringen oder sie werden unterlassen. Dieser Wert wird als Hurdle Rate (Kalkulations-Zielzinssatz, kalkulatorische Grundverzinsung) bezeichnet. Stellen Sie fest, wie hoch die Hurdle Rate Ihres Unternehmens ist, und wenden Sie sie auf Ihr Gehalt an. Sind Sie eine gute Investition?

| KAPITEL17|

Ein Kieselstein in einem Eimer Wasser

as würde passieren, wenn Sie aus Ihrem Büro rausmar-

W

schierten, um niemals zurückzukehren? Ich kenne viele Programmierer, die sich mit dieser Vorstellung trösten.

Sie stehen einfach auf, gehen ins Büro ihres Chefs und kündigen.

Ich zeige denen schon, warum sie mich brauchten! Mit diesem Tagtraum kann man wirklich schlechte Tage überstehen, aber es ist offensichtlich keine sehr produktive Einstellung für die Dauer. Abgesehen davon ist sie falsch. Menschen verlassen jeden Tag Unternehmen. Viele werden entlassen. Viele gehen freiwillig. Einige leben sogar unseren Tagtraum aus und gehen ohne Vorankündigung. Nur in wenigen Fällen spüren die Unternehmen den Verlust deutlich. Doch in den meisten Fällen ist die Auswirkung selbst bei wichtigen Positionen überraschend gering. Dass gerade Sie diesen Job ausfüllen, bedeutet für das Unternehmen so viel wie ein Kieselstein in einem Eimer Wasser. Natürlich steht das Wasser etwas höher. Sie erledigen Dinge. Sie tragen Ihren Teil bei. Doch wenn man den Kieselstein aus dem Eimer nimmt und sich danach das Wasser anschaut, ist der Unterschied eigentlich nicht zu bemerken. Ich versuche nicht, Sie runterzuziehen. Wir alle brauchen das Gefühl, unser Beitrag habe etwas zu bedeuten. Und er hat es auch.

i76

26 - Ein Kieselstein in einem Eimer Wasser

Aber wir verbringen so viel Zeit damit, an unser eigenes Ich zu denken, dass wir leicht vergessen, dass jeder andere ebenfalls ein solches Ich ist. Jeder Mitarbeiter Ihres Unternehmens ist ein empfindendes autonomes Wesen, das in diesen Dingen feststeckt, das als das Selbst bezeichnet wird und das nur ein Fenster ist, durch das es seinen Job betrachtet. Sehen Sie es folgendermaßen: Wenn Sie das Unternehmen morgen verlassen würden, würde dies (im Durchschnitt) nicht mehr oder nicht weniger bewirken als das Ausscheiden irgendeines anderen Mitarbeiters. Ich arbeitete einmal für einen CIO (Chief Information Officer; Verantwortlicher für das Informations- und Kommunikationsmanagement in einem Unternehmen), der einer der mächtigsten CIOs in einem der mächtigsten Unternehmen der Welt war. Er gewann mit seinem Team (zu dem ich gehörte) jeden denkbaren Preis und setzte alle IT-Standards in dem Unternehmen. Er gehörte zu den Menschen, die offensichtlich eine Art magisches Elixier gefunden hatten. Er verteilte es kostenlos bei den Mittagessen und Dinners, die er bei den Y2K-Partys spendierte. Einer der wenigen wirklichen Ratschläge, die ich je von diesem CIO bekam - und immer wieder hörte - , lautete, dass man sich nie zu sehr auf seinen Lorbeeren ausruhen sollte. Er bekannte, dass er sich jeden Morgen nach dem Aufwachen absichtlich und ausdrücklich daran erinnerte, dass er jeden Tag von seinem Podest gestoßen werden könnte. Heute könnte dieser Tag sein, sagte er. Seine Mitarbeiter schauten ihn ungläubig an. Nein. Heute wird es nicht sein. Die Dinge laufen so gut. Es gibt so viel, was für Sie spricht.

Merksatz Hüten Sie sich davor, sich vom eigenen Erfolg blenden zu lassen.

Das war sein Punkt. Bescheidenheit entwickelt man nicht nur, um behaupten zu können, man sei spiritueller geworden. Bescheiden-

i7626-Ein Kieselstein in einem Eimer Wasser

heit lehrt, die eigenen Aktionen klarer zu beurteilen. Unser CIO wollte uns Folgendes vermitteln: Je erfolgreicher Sie sind, desto wahrscheinlicher begehen Sie einen fatalen Fehler. Wenn Ihnen alles zuarbeitet, ist es weniger wahrscheinlich, dass Sie Ihr Urteilsvermögen infrage stellen. Wenn die Methode, die Sie immer angewendet haben, immer funktioniert hat, werden Sie weniger wahrscheinlich eine neue Methode anerkennen, die besser funktionieren könnte. Sie werden arrogant; und mit der Arroganz entwickeln Sie blinde Flecken. Für je unersetzbarer Sie sich halten, desto ersetzbarer (und weniger attraktiv) werden Sie. Sich für unersetzbar zu halten, ist ein schlechtes Zeichen, insbesondere für einen Software-Entwickler. Wenn Sie nicht ersetzt werden können, bedeutet dies wahrscheinlich, dass Sie Aufgaben in einer Art und Weise lösen, die andere nicht beherrschen. Obwohl jeder gerne einen speziellen Genius für sich in Anspruch nimmt, sind nur wenige Software-Entwickler so einzigartig, dass sie tatsächlich unersetzbar sein sollten. Ich habe oft gehört, dass Programmierer halb im Scherz darüber redeten, mit nicht wartbarem Code für die »Sicherheit ihres Arbeitsplatzes« zu sorgen. Und ich habe tatsächlich erlebt, dass Programmierer dies versucht haben. In jedem Fall sind diese Leute zu Zielen geworden. Sicher, es war für das Unternehmen riskant, sie schließlich zu entlassen. Doch letztlich war die Angst das Schlimmste, was passiert ist. Zu versuchen, unersetzbar zu sein, ist ein defensives Manöver, das eine feindliche Beziehung zu Ihrem Arbeitgeber (und zu Ihren Kollegen) schafft, falls eine solche nicht schon bestanden hat. Nach derselben Logik sollte der Versuch, sich ersetzbar zu machen, eine nichtfeindliche Arbeitsbeziehung

schaffen. Wir sind alle

ersetzbar. Wer das akzeptiert und sogar darauf hinarbeitet, unterscheidet sich von den anderen und verbessert verständlicherweise seine eigenen Chancen. Und wenn Sie ersetzbar sind, hält natürlich nichts Sie davon ab, den nächsten größeren Job eine Stufe höher zu übernehmen.

26 - Ein Kieselstein in einem Eimer Wasser

i76

Umsetzung i. Erstellen Sie ein Inventar des Codes, den Sie geschrieben haben oder den Sie warten, sowie aller Aufgaben, die Sie ausführen. Notieren Sie alle Aspekte, in denen das Team vollkommen von Ihnen abhängig ist. Vielleicht sind Sie der Einzige, der den Deployment-Prozess Ihrer Anwendung vollkommen versteht. Oder der Code enthält einen Abschnitt, den Sie geschrieben haben und der für den Rest des Teams besonders schwer zu verstehen ist. Tragen Sie jeden dieser Punkte in Ihre Aufgabenliste ein. Dokumentieren, automatisieren oder refaktorisieren Sie jeden Code oder jede Aufgabe so, dass er bzw. sie leicht von jedem anderen Mitglied Ihres Teams verstanden werden kann. Hören Sie erst auf, wenn Sie diese Liste abgearbeitet haben. Geben Sie diese Dokumente proaktiv an Ihr Team und Ihren Leiter weiter. Sorgen Sie dafür, dass die Dokumente an einem für das Team leicht zugänglichen Ort abgelegt werden. Wiederholen Sie diese Prozedur periodisch.

Lernen Sie, die Wartung zu lieben

or mehreren Jahren war ich daran beteiligt, ein SoftwareEntwicklungszentrum für etwa 250 Mitarbeiter von Grund auf einzurichten. Wir begannen mit einem leeren Gebäude und hatten die Aufgabe, eine komplette Entwicklungsorganisation aufzubauen und das benötigte Personal einzustellen. Bei der Einrichtung dieses Entwicklungszentrums standen wir vor einer Herausforderung, mit der wir nie gerechnet hatten. Jeder möchte neue Systeme entwickeln. Niemand möchte alte Systeme warten. Wir wollten eine neue Umgebung mit einer energiegeladenen Atmosphäre schaffen. U m in die richtige Richtung zu starten, mussten wir deshalb darauf achten, was unsere neuen Mitarbeiter wollten. Jeder schafft gern Neues. Man hat dann das Gefühl, wirklich die Gelegenheit zu haben, einer Arbeit seinen Stempel aufzudrücken, sie zu besitzen; sich selbst durch seine Kreation auszudrücken. Wir neigen auch zu dem Glauben, die Projektarbeit fände in unserem Unternehmen die größte Aufmerksamkeit. Den Leuten, die die neue Generation schaffen, gebührt auch der Ruhm, nicht wahr? Ich wusste, dass diese Einstellung unter den Programmierern vorherrschte, mit denen ich vorher gearbeitet hatte. Aber durch den Umgang mit einigen Hundert Software-Entwicklern in einer Umgebung, die mit einer Petrischale voller menschlicher Ressourcen ver-

181 27 - Lernen Sie, die Wartung zu lieben

gleichbar war, wurde mir dies in einer extremen Form bewusst, mit der ich nie gerechnet hatte. Obwohl Software-Entwickler normalerweise kreative, freiheitsliebende Menschen sind, ähnelt die »Gesellschaft« der Programmierer überraschend stark einer Kaste. Programmierer wollen Designer sein, die Architekten werden wollen usw. Dagegen bekommen sie bei Wartungsarbeiten weder eine Kerbe in ihrem Gürtel noch eine klar herausgehobene Rolle (wie etwa als Architekt), von der sie ihren Eltern oder Studienkollegen erzählen können. Deshalb sind die motivierenden Faktoren im Wesentlichen die Fähigkeit, kreativ zu arbeiten, und die Gelegenheit, einer Beförderung näher zu kommen. Seltsamerweise ist Projektarbeit für beides nicht unbedingt die beste Basis. Bei Wartungsarbeiten geht es normalerweise um alte, verfallende Systeme und fordernde Endanwender. Da die Software als fertig gilt, konzentrieren sich IT-Abteilungen normalerweise darauf, die Kosten für die Wartung dieser Systeme zu reduzieren, und suchen deshalb nach der billigsten Möglichkeit, diese Systeme am Laufen zu halten. Dies führt normalerweise dazu, dass für diesen Zweck zu wenige Ressourcen abgestellt werden und dass keine wesentlichen Investitionen zur Erneuerung dieser Systeme erfolgen. Dagegen ist Projektarbeit der Ort, an dem man mit einer hübschen, sauberen grünen Wiese beginnt. In einem gut geführten Unternehmen trägt jedes Projekt dazu bei, entweder mehr Geld zu verdienen oder Kosten einzusparen. Deshalb stehen für Projekte normalerweise genügend Mittel zur Verfügung, um die Arbeit zu erledigen (obwohl es auch gegenteilige Erfahrungen gibt). Es gibt kein Minenfeld mit altem Code, durch das sich die Programmierer sorgfältig auf Zehenspitzen tasten müssen, um Dinge so zu ändern, dass keine Widersprüche zu dem vorhandenen Code entstehen. Bei neuen Projekten gibt es dieses Problem nicht. Kurz gesagt: Die Umstände bei der Projektarbeit sind normalerweise sehr viel idealer.

18127-Lernen Sie, die Wartung zu lieben

Wenn ich Ihnen 1 . 0 0 0 € gebe und Sie bitte, mir eine Tasse Kaffee zu holen, wäre ich sehr unglücklich, wenn Sie mit 1 . 0 0 0 € weniger und ohne Kaffee zurückkämen. Ich wäre sogar unglücklich, wenn Sie mir sehr viel wirklich guten Kaffee zurückbrächten, aber dafür zwei Stunden brauchten. Wenn ich Ihnen null Euro geben und Sie bitten würde, mir eine Tasse Kaffee zu holen, würde ich es außerordentlich schätzen, wenn Sie tatsächlich mit dem Kaffee zurückkämen, und ich würde es durchaus verstehen, täten Sie dies nicht. Projektarbeit entspricht dem ersten Szenario, Wartungsarbeit dem zweiten. Wenn unsere Arbeit nicht durch schlechten Legacy-Code und fehlende Mittel eingeschränkt ist, erwarten unsere Manager und Kunden mit Recht mehr von uns. Und bei Projektarbeit handelt es sich um eine erwartete Verbesserung des Geschäftsbetriebs. Liefern wir diese nicht, sind wir gescheitert. Da sich unsere Unternehmern auf diese Verbesserungen ihres Geschäftsbetriebs verlassen, schreiben sie oft strikt vor, was, wann, wie erstellt werden soll. Plötzlich fühlt sich unser kreativer Spielplatz mehr wie eine militärische Operation an - jede unsere Bewegungen wird von oben vorgeschrieben.

Merksatz Wartungsarbeit kann ein Ort der Freiheit und Kreativität sein.

Doch bei der Wartung erwarten alle nur, dass die Software reibungslos so kostengünstig wie möglich am Laufen gehalten wird. Niemand erwartet von einem Wartungsteam kreative Geistesblitze. Wenn alles reibungslos läuft, halten sich Kunden normalerweise aus der täglichen Routine der Wartungsleute und ihrer Arbeit raus. Korrigieren Sie Fehler, implementieren Sie kleine Änderungswünsche und halten Sie das System am Laufen. Das ist alles, was Sie tun müssen. Was passiert, wenn es bei einem Fehler erforderlich wird, das Design eines Subsystems einer Anwendung zu überarbeiten? Das

181

181 27 - Lernen Sie, die Wartung zu lieben

gehört alles zum Korrigieren von Fehlern, nicht wahr? Die Designs können alt und angeschimmelt sein, und das ganze System kann mit zerbrochenen Fenstern übersät sein. (Näheres über zerbrochene Fenster finden Sie in The Pragmatic Programmer [HToo].) Bei dieser Gelegenheit können Sie Ihre Refaktorisierungstools testen. Wie elegant kann dieses System sein? Wie viel schneller können Sie diesen Abschnitt aufgrund der jetzigen Rektorisierung beim nächsten Mal reparieren oder verbessern? Solange Sie das System am Laufen halten und die Anforderungen der Anwender zeitnah erledigen, ist die Wartung ein Ort der Freiheit und Kreativität. Sie sind Projektleiter, Architekt, Designer, Codierer und Tester. Sie können Ihre kreativen Fähigkeiten nach eigenem Gusto entfalten, und der messbare Erfolg oder Misserfolg des Systems wird ganz Ihnen zugerechnet. Wenn Sie ein System warten, können Sie auch auf sichtbarere Verbesserungen hinarbeiten. Vielleicht verwendet Ihr drei Jahre altes Websystem nicht die spritzigen neuen Benutzerschnittstellenfunktionen, die in modernen Webbrowsern zur Verfügung stehen. Wenn Sie sie einarbeiten können, während Sie das System am Laufen halten und Fehler korrigieren, können Sie die User Experience mit dem System sichtbar verbessern. An einigen wohl gewählten Stellen ein wenig Schnickschnack hinzuzufügen, den die Kunden nicht erwartet haben, unterscheidet sich nicht allzu sehr davon, Ihre Frau mit Blumen zu überraschen oder als Kind das Haus zu putzen, während die Eltern einkaufen. Und ohne den bürokratischen Klammergriff eines ausgewachsenen Projekts werden Sie überrascht sein, wie viel Sie zwischen Ihren normalen Wartungsaufgaben einschieben können. Und auch Ihre Kunden werden überrascht sein. Wartungsarbeit hat noch einen weiteren verborgenen Vorteil: Im Gegensatz zu der vertragsbasierten Umgebung, in der heute viele Projektteams arbeiten, haben Wartungsprogrammierer oft direkt Kontakt mit ihren Kunden. Das bedeutet, dass mehr Menschen wissen, wer Sie sind, und dass Sie mehr Gelegenheit haben, eine grö-

Umsetzung|184

ßere Basis von Fürsprechern in Ihrem Geschäft aufzubauen. Außerdem befinden Sie sich an einem außerordentlich geeigneten Platz, um die Arbeitsweise Ihres Geschäftes wirklich kennen zu lernen. Wenn Sie für eine Geschäftsanwendung komplett zuständig sind und immer mit Ihren Endanwendern Probleme und Fragen diskutieren, entwickeln Sie sich ganz ohne nennenswerte zusätzliche Anstrengung zu einem Experten für die Aufgaben, die mit dieser Anwendung gelöst werden. Geschäftsregeln sind in der Anwendungslogik codiert, die Geschäftsleute normalerweise nicht lesen können. Ich habe viele Situationen erlebt, dass nur die Wartungsprogrammierer vollkommen verstanden hatten, wie ein spezieller Geschäftsprozess in einem Unternehmen funktionierte. Niemand sonst hatte direkten Zugang zu der verbindlichen algorithmischen Formulierung dieser Geschäftslogik. Diese Teilung in Projekt- und Wartungsarbeit wird von einer großen Ironie umgeben: Projektarbeit ist Wartungsarbeit. Sobald Ihr Projektteam seine erste Zeile Code geschrieben hat, wird jede zusätzliche Funktion einer lebendigen Codebasis

hinzugefügt.

Sicher, der neue Code ist wahrscheinlich sauberer und kürzer als bei der Arbeit an einer Legacy-Anwendung, aber der grundlegende Akt ist derselbe. Z u vorhandenem Code werden neue Funktionen hinzugefügt oder es werden Fehler korrigiert. Wer kann diese Aufgaben besser und schneller erledigen als jemand, der die Wartungsprogrammierung wirklich verinnerlicht und es sich zur Aufgabe gemacht hat, sie so gut wie möglich zu erledigen?

Umsetzung i. Messen, verbessern, messen -

Erstellen Sie für die wichtigste

Anwendung oder den wichtigsten Code, die bzw. den Sie warten, eine Liste der messbaren Faktoren, die die Qualität der Anwendung repräsentieren. Dies könnte die Reaktionszeit der Anwendung sein, die Anzahl der nicht gehandhabten Ausnahmen, die während der Verarbeitung ausgelöst werden, oder die Zeit, in der

181

181 27 - Lernen Sie, die Wartung zu lieben

Ihre Anwendung ohne Ausfälle läuft. Wenn Sie direkt für den Support zuständig sind, messen Sie nicht direkt die Qualität der Anwendung, sondern etwa die Reaktionszeit bei Support-Anfragen, das heißt, wie schnell Sie ein gemeldetes Problem beheben können. Wählen Sie das wichtigste dieser messbaren Attribute aus und beginnen Sie mit seiner Messung. Nachdem Sie eine aussagefähige Menge an Messwerten gesammelt haben, setzen Sie sich ein realistisches Ziel und verbessern Sie die Performance der Anwendung (oder Ihrer Wartungstätigkeit), um dieses Ziel zu erreichen. Messen Sie danach erneut, um zu verifizieren, ob Sie die gewünschte Verbesserung tatsächlich realisiert haben. Ist dies der Fall, erzählen Sie Ihrem Team und Ihren Kunden davon. Wählen Sie dann ein anderes Maß aus und beginnen Sie von vorn. Sie werden feststellen, dass dies, ähnlich wie ein Spiel, anfängt, Spaß zu machen. Dinge messbar zu verbessern kann süchtig machen.

Acht Stunden brennen

ine der vielen Kontroversen u m die Bewegung des Extreme

E

Programming ist die anfängliche Forderung von Kent Beck,

Mitglieder eines Teams sollten nicht mehr als 40 Stunden pro

Woche arbeiten. Eine derartige Aussage eignet sich wirklich, u m Manager mit einer Sklavenhaltermentalität, die so viel Produktivität wie möglich aus ihren Teams herausquetschen wollen, auf die Palme zu bringen. Widerstand regte sich sogar bei einigen Programmierern. Die Gesamtzahl der ununterbrochen

geleisteten

Arbeitsstunden wird zu einem Bestandteil eines Entwickler-Machismos, ähnlich wie die Anzahl der Biere, die jemand bei einem Saufgelage kippen kann. Bob Martin (www.objectmentor.com), eine der Lichtgestalten der Extreme Programming Community, formulierte die Aussage so um, dass sie für beide Parteien erträglicher wurde und zugleich der ursprünglichen Intention von Kent Beck treu blieb. Martin machte aus einer 40-Stunden-Arbeitswoche ein Achtstündiges-Brennen.

Die

Idee dahinter ist einfach: Man sollte so schonungslos arbeiten, dass man dies unmöglich länger als acht Stunden durchhalten kann. Bevor wir uns eingehend mit dem Brennen befassen, wollen wir fragen, warum überhaupt betont wird, die Anzahl der Stunden zu

i86

28 - Acht Stunden brennen

begrenzen. In diesem Kapitel geht es darum, Dinge zu erledigen. Sollten wir nicht darüber reden, länger zu arbeiten? Wenn es um die Arbeit geht, kann weniger tatsächlich mehr sein. Als Hauptgrund nennen die Extremen Programmierer Folgendes: Wer müde ist, denkt nicht so effizient wie jemand, der ausgeruht ist. Wenn wir ausgebrannt sind, sind wir nicht mehr so kreativ, und die Qualität unserer Arbeit lässt dramatisch nach. Wir fangen an, dumme Fehler zu machen, die uns letztlich mehr Zeit und Geld kosten.

Merksatz Projekte sind Marathonläufe, keine Sprints.

Die meisten Projekte dauern sehr lange. Will man einen Marathonlauf zu Ende bringen, kann man nicht die Geschwindigkeit eines Sprinters aufrechterhalten. Obwohl sich Ihre Produktivität kurzfristig beträchtlich erhöhen kann, wenn Sie länger arbeiten, werden Sie langfristig so schwer straucheln, dass Ihre Erholungszeit länger dauern wird als die Produktivitätsgewinne, die Sie während Ihrer 80-Stunden-Wochen erzielt haben. Sie können Ihre Zeit ähnlich wie Ihr Geld betrachten. Als Teenager, der in Teilzeit für einen minimalen Lohn arbeitete, wäre ich glücklich gewesen, von dem Geld zu leben, das ich heute verschwende. Ich habe heute so viel mehr Geld zur Verfügung, dass ich weniger darauf achte, wie ich jeden Dollar ausgebe. Irgendwie schaffte ich es damals, zu überleben. Ich konnte irgendwo wohnen, hatte ein Auto und genug zu essen. Dasselbe habe ich heute auch. Ich kultiviere keinen besonders extravaganten Lebensstil. Offensichtlich fand ich, als das Geld knapp war, Wege, mit meinem Bargeld effizienter auszukommen. Und das Endergebnis war im Wesentlichen dasselbe. Für uns sind knappe Ressourcen wertvoller, und wir nutzen sie effizienter. Wir können dieses Denken nicht nur auf Geld, sondern

Acht Stunden brennen

187

auch auf unsere Zeit anwenden. Denken Sie an den vierten Tag Ihrer letzten 70-Stunden-Arbeitswoche. Zweifellos haben Sie sich wacker abgemüht. Aber am vierten Tag beginnen Sie, nachlässiger mit Ihrer Zeit umzugehen. Es ist 10:30 Uhr, und ich weiß, dass ich noch Stunden später hier sein werde, nachdem alle anderen nach Hause gegangen sind. Ich glaube, ich sollte eine Zeit lang die neuesten technologischen Nachrichten lesen. Wenn Sie zu viel Zeit zum Arbeiten haben, reduziert sich der wahrgenommene Wert Ihrer Arbeitszeit beträchtlich. Wenn Sie 70 Stunden zur Verfügung haben, ist jede Stunde weniger wertvoll, als wenn Sie nur 40 Stunden haben. Wenn der Wert des Euro aufgrund von Inflation abnimmt, brauchen Sie mehr Euros, um dieselben Güter zu kaufen. Wenn der Wert einer Stunde abnimmt, brauchen Sie mehr Stunden, um Dinge zu erledigen. Das Achtstündige-Brennen von Bob Martin unterwirft Sie einer Beschränkung und gibt Ihnen eine Strategie an die Hand, mit dieser Beschränkung umzugehen. Sie fangen an zu arbeiten und denken: Ich habe nur acht Stunden! Weiter, weiter, weiter! Wenn Anfang und Ende Ihrer Arbeit zeitlich streng begrenzt sind, fangen Sie auf natürliche Weise an, Ihre Zeit effizienter einzusetzen. Sie beginnen etwa mit einem Satz von Aufgaben, die auf jeden Fall an diesem Tag erledigt werden müssen, Sie ordnen sie nach ihren Prioritäten und erledigen sie dann zügig eine nach der anderen. Das achtstündige Brennen schafft eine Situation, in der Sie sich wie an den ultraproduktiven Wochenenden fühlen, die Sie gelegentlich bei Ihrem Studium erlebt haben, wenn Sie intensiv für ein Klausurthema gepaukt haben, das Sie längere Zeit vernachlässigt hatten, oder eine Semesterarbeit erledigten, die vorher wegen Ihrer Aufschieberitis liegen geblieben war. Das Wesentliche war die zeitliche Beschränkung dieser Paukerei. Zeiten des Paukens sind normalerweise außerordentlich produktiv, weil die Zeit knapp und deswegen außerordentlich wertvoll wird. Das achtstündige Brennen ist eine

i88

28 - Acht Stunden brennen

Methode, frühzeitig und oft derartige Phasen des Paukens künstlich zu schaffen, ohne dass Sie die ganze Nacht aufbleiben und sich mit Cola oder Kaffee wachhalten müssen. Als geistige Arbeiter können wir arbeiten, auch wenn wir nicht vor einem Computer oder im Büro sitzen. Vielleicht arbeiten Sie, wenn Sie zu einem Abendessen mit Ihrer Frau fahren oder während Sie einen Film anschauen. Ihre Arbeit folgte Ihnen und lässt Sie nicht in Ruhe. Meine Arbeit lässt mich normalerweise nicht in Ruhe, wenn ich ihr nicht genügend Aufmerksamkeit gewidmet habe. Möglicherweise habe ich eine bestimmte Aufgabe nicht rechtzeitig erledigt oder den Stapel der unerledigten Aufgaben auf meinem Schreibtisch zu groß werden lassen. Dies sind Situationen, in denen mir die Arbeit nach Hause folgt und mir keine Ruhe lässt, wenn ich versuche mich zu entspannen. Wenn Sie jeden Tag intensiv arbeiten, werden Sie feststellen, dass Ihre Arbeit Sie nicht nach Hause verfolgt. Sie halten sich nicht nur bewusst davon ab, Überstunden zu machen, sondern Ihr Geist wird es Ihnen tatsächlich erlauben, keine Überstunden zu machen. Budgetieren Sie Ihre Arbeit sorgfältig. Arbeiten Sie weniger, und Sie werden mehr erreichen. Sie werden das Arbeiten immer höher schätzen, wenn Sie ihm eine Weile fernbleiben.

Umsetzung 1. Sorgen Sie dafür, dass Sie heute gut schlafen. Essen Sie morgens Ihr Frühstück und beginnen Sie dann, zu einem genauen Zeitpunkt zu arbeiten (am besten etwas früher als üblich). Arbeiten Sie intensiv vier Stunden lang. Machen Sie eine Stunde Mittagspause. Arbeiten Sie dann weitere vier Stunden so intensiv, dass Sie absolut erschöpft sind und nicht mehr leisten können. Gehen Sie nach Hause, entspannen Sie sich und gehen Sie Ihren Vergnügungen nach.

KAPITEL 196

Lernen Sie, mit Misserfolgen umzugehen

A

ls Programmierer wissen wir, dass wir Software-Fehler umso besser beheben können, je früher wir sie bei der Entwicklung entdecken, und dass die Software dementspre-

chend robuster sein wird. Unit-Testing hilft uns, seltsame Fehler so früh wie möglich zu beseitigen. Wenn wir bizarre Fehler in unserem eigenen Code frühzeitig entdecken, sind wir glücklich. Obwohl jeder Fehler ein kleines Scheitern unserer Arbeit als Programmierer bedeutet, ist sein frühes Aufdecken oft ein gutes Zeichen für die künftige Gesundheit der Software. Wir haben gelernt, dass frühe Programmierfehler ruhig laut und chaotisch sein können. Sie wollen über die Existenz von Fehlern sofort beim Auftreten informiert werden, damit Sie sie korrigieren oder defensive Maßnahmen einbauen können. Wenn Sie codieren, bemühen Sie sich nicht, die kleinen Software-Fehler zu verbergen, die bei der Entwicklung unvermeidlich auftreten. Fehler sind die Form, in der Code zu Ihnen spricht. Fehler gehören dazu, den Prozess zu verbessern. Deshalb fügen wir Zusicherungen in den Code ein, die unsere Programme zum Absturz bringen, wenn etwas schiefgeht, oder führen Unit-Tests durch, die einen roten Balken anzeigen, wenn wir etwas falsch gemacht haben.

191 29 - Lernen Sie, mit Misserfolgen umzugehen

Die kleinen Fehler zeigen uns auch an, mit welcher Art von Programmausfällen wir zu rechnen haben. Wenn Sie noch nie durch ein Minenfeld gegangen sind, wissen Sie vielleicht nicht, auf welche Dreckhaufen Sie nicht treten dürfen. Wenn sich Ihre Software nicht regelmäßig bei Ihnen beschwert hat, wissen Sie vielleicht nicht, wo die gefährlichen Haken und Ösen sind. Defensives Programmieren umgeht Fehler stillschweigend, deckt sie aber nicht auf. Doch darüber hinaus ist es wichtig, defensiv zu programmieren. Die Software-Qualität wird erst dann wirklich getestet, wenn Dinge schiefgehen. Es ist unvermeidbar, dass irgendetwas passieren wird, das Sie in keinem Eventualfall berücksichtigt haben. Segmentfehler und Blue Screens im Produktionscode bedeuten, dass die Programmierer keine gute Arbeit geleistet haben, mit Fehlern umzugehen, die sie nicht vorhersehen konnten.

Merksatz Jede Fehlermeldung ist nur einen Schritt vom richtigen Verhalten entfernt.

Dieselben Prinzipien gelten auch für die Arbeit. Aus welchem Holz jemand geschnitzt ist, zeigt sich erst, wenn Probleme auftauchen. Mit Fehlern umgehen zu lernen, ist eine Fähigkeit, die sehr wertvoll, aber auch nur sehr schwer zu lernen ist. Bei Jazz-Improvisationen lernte ich, dass jede falsche Note höchstens einen Schritt von einer

richtigen

entfernt

war.

Improvisationen

werden

dann

schlecht, wenn der Spieler nicht weiß, was er bei einer falschen Note tun soll. Wenn man die Band im Rücken und das Publikum vor sich hat, reicht der Ton einer echten falschen Note aus, einen Amateur bis ins Mark gefrieren zu lassen. Selbst Meister spielen falsche Noten. Aber sie können die Situation so wenden, dass der Zuhörer nicht erkennen kann, dass das Ganze unabsichtlich passiert ist.

19129-Lernen Sie, mit Misserfolgen umzugehen

Wir machen alle dumme Fehler bei der Arbeit. Es gehört zur menschlichen Natur. Wir machen Programmierfehler, die dazu führen, dass Kunden Stack Traces vor sich haben. Durch kritische Design-Fehler manövrieren wir uns selbst ins Aus. Oder schlimmer: Wir sagen unseren Teamkollegen, Vorgesetzten und Konkurrenten etwas Falsches. Wir gehen Verpflichtungen ein, die wir nicht halten können, oder stellen falsche Behauptungen über unsere Fähigkeiten auf. Oder wir geben aus Versehen einem Kollegen einen falschen Rat zur Lösung eines technischen Problems und verschwenden damit Stunden seiner Zeit. Weil wir alle Fehler machen, wissen wir auch, dass alle anderen ebenfalls Fehler machen. Deshalb beurteilen wir uns, in vernünftigen Grenzen, nicht anhand unserer Fehler. Stattdessen beurteilen wir uns danach, wie wir mit diesen unvermeidlichen Fehlern umgehen. Unabhängig davon, ob der Fehler auf einem technischen Gebiet, bei der Kommunikation oder beim Projektmanagement passiert ist, gelten die folgenden Regeln: •

Sprechen Sie ein Problem sofort an, wenn Sie davon erfahren. Versuchen Sie nicht einen Augenblick lang, es zu verbergen. Wie bei der Software-Entwicklung und beim Testen sind Fehler, die früh entdeckt werden, weniger problematisch als Fehler, die später entdeckt werden. Je früher Sie den Fehler entdecken und offenlegen, was Sie getan haben, desto weniger negativ werden seine Auswirkungen wahrscheinlich sein.

•

Nehmen Sie die Schuld auf sich. Versuchen Sie nicht, einen Sündenbock zu finden, selbst wenn sich ein guter anbietet. Selbst wenn Sie nicht die gesamte Schuld haben, nehmen Sie die Verantwortung auf sich und machen Sie weiter. Das Ziel ist, diesen Punkt so schnell wie möglich zu überwinden. Ein Problem muss gelöst werden. Wenn man sich mit der Schuldfrage aufhält, wird die Lösung des Problems nur verzögert.

•

Bieten Sie eine Lösung an. Wenn Sie keine Lösung haben, schlagen Sie einen Plan vor, wie man eine Lösung finden könnte.

191

191 2 9 - Lernen Sie, mit Misserfolgen umzugehen

Sprechen Sie von konkreten, vorhersagbaren Zeitabschnitten. Wenn Sie durch Ihr Design Ihr Team in eine Ecke gedrängt haben, geben Sie die Zeit an, die Sie brauchen, um den Aufwand für die Korrektur des Problems abzuschätzen. Auf dieser Stufe sind konkrete erreichbare Ziele wichtig, selbst wenn sie nur klein und unbedeutend sein sollten. Sie tragen nicht nur dazu bei, die Sache vom Schlechten zum Guten zu wenden, sondern helfen auch dabei, Ihre Glaubwürdigkeit wiederherzustellen. •

Bitten Sie um Hilfe. Selbst wenn Sie allein für ein Problem verantwortlich sind, verschlimmern Sie die Situation nicht durch Ihren Stolz, indem Sie Hilfe bei der Lösung ablehnen. Ihre Teamkollegen, das Management und Codier-Kunden werden Sie viel positiver einschätzen, wenn Sie eine gesunde Einstellung behalten und Ihr Ego beiseiteschieben, während das Team Ihnen hilft, aus der Grube herauszuklettern. Z u oft verleitet uns ein Gefühl der Verantwortlichkeit dazu, stolz eine Last zu schultern, die für uns alleine zu groß ist; wir schlagen uns dann unproduktiv mit dem Problem herum, bis jemand mit einem Machtwort eingreift.

Denken Sie an das letzte Mal, an dem Sie im Restaurant ein Problem mit der Bedienung hatten. Vielleicht mussten Sie zu lange darauf warten, dass schließlich das falsche Gericht auf Ihrem Tisch landete. Denken Sie darüber nach, wie der Kellner auf Ihre Beschwerde reagierte.

Merksatz Stressreiche Zeiten bieten die beste Gelegenheit, Loyalität aufzubauen.

Der Kellner würde falsch reagieren, wenn er sich herausreden oder die Schuld auf die Küche schieben wollte. Er würde auch falsch reagieren, wenn er einfach die Bestellung erneut aufgeben und außer

19129-Lernen Sie, mit Misserfolgen umzugehen

Sichtweite bleiben würde, während Sie hungernd dasitzen und sich fragen, wo Ihr bestelltes Gericht bleibt. Natürlich wäre es wirklich falsch, wenn der Kellner ein Gericht, von dem er bereits weiß, dass es falsch ist, servieren und hoffen würde, Sie würden es nicht bemerken oder sich nicht beschweren. Wie uns ein Unternehmen behandelt, wenn es einen Fehler macht, kann letztlich den Ausschlag dafür geben, Loyalität aufzubauen (oder zu zerstören). Wird ein Fehler kulant behandelt, werden wir möglicherweise zu loyaleren Kunden, als wir gewesen wären, wenn wir nie ein Serviceproblem mit dem Unternehmen gehabt hätten. Denken Sie daran im Umgang mit Ihren Kunden, wenn Sie einen Fehler bei der Arbeit machen.

KAPITEL 196

»Nein« sagen

er schnellste Weg, Ihre Zusagen nicht einzuhalten, besteht

D

darin, Zusagen zu machen, die Sie nicht einhalten können. Das hört sich zwar so offensichtlich an, doch wir machen es

jeden Tag. Wir werden zu etwas aufgefordert und wir möchten unsere Vorgesetzten nicht enttäuschen; deswegen sagen wir zu, unmögliche Arbeiten in einer unmöglichen Zeit zu erledigen.

Merksatz »Ja« zu sagen, um Enttäuschung zu vermeiden, ist einfach nur eine Lüge.

»Ja« zu sagen, ist eine süchtig machende und zerstörerische Angewohnheit. Es ist eine schlechte Angewohnheit, die sich als eine gute maskiert. Doch es gibt einen großen Unterschied zwischen einer Einstellung des Selbstvertrauens und einer Fehlrepräsentation der eigenen Fähigkeit. Letzteres verursacht nicht nur Probleme für die Leute, denen Sie Zusagen machen. Wenn ich Sie als Ihr Vorgesetzter frage, ob Sie die Protokollierung des Versands im Warenwirtschaftssystem unseres Unternehmens bis zum Ende des Monats umschreiben können, habe ich diesen Termin wahrscheinlich aus

196

30 - »Nein« sagen

gutem Grund genannt. Wahrscheinlich hat mich jemand gefragt, ob die Aufgabe bis dann erledigt werden kann. Oder wir könnten versuchen, eine andere kritische Geschäftsfunktion zu implementieren, die von dem Warenwirtschaftssystem abhängig ist. Deshalb gehe ich im Bewusstsein Ihrer Zusicherung, dass Sie dieses Datum einhalten können, zu meinen Kunden und sichere ihnen zu, dass die Aufgabe bis dann erledigt sein wird. Auf diese Weise »Ja« zu sagen, ist einfach eine Form des Lügens. Ich behaupte nicht, dass es böswillig erfolgt. Wir machen uns selbst genauso viel vor wie den Leuten, denen wir die Zusicherungen geben. Schließlich ist es kein gutes Gefühl, »Nein« zu sagen. Wir sind darauf programmiert, immer Erfolg haben zu wollen. Und zu sagen, wir könnten etwas nicht tun, weckt dasselbe Gefühl, als seien wir gescheitert. Als Menschen haben wir nicht internalisiert, dass »Ja« nicht immer die richtige Antwort ist. Und »Nein« ist selten die falsche Antwort. Ich sage »internalisiert«, weil ich glaube, dass wir alle wissen, dass dies wahr ist. Schließlich möchte niemand auf der Empfangerseite einer falschen Zusage stehen. Die Unfähigkeit, »Nein« zu sagen, ist in der indischen Kultur tief verwurzelt. Unternehmen, die mit dem Offshore-Outsourcing keine Erfahrung haben, stoßen immer wieder auf dieses Problem. Im Laufe der Zeit lernt man, Unsicherheit zu erkennen und die richtigen Fragen zu stellen. Wenn Sie genügend »Noch ein Tag, dann ist alles fertig«-Gespräche geführt haben, lernen

Sie von

selbst,

genauer nachzufragen. Dieses Problem gibt es nicht nur in der ITKultur. Als ich in Bangalore lebte, blieb ich nicht weniger als fünf Mal zu Hause, um vergeblich auf die Installation eines Kabelmodems zu warten. Es stellte sich heraus, dass das Unternehmen die ersten drei Male nicht einmal die erforderlichen Komponenten für die Installation hatte, als es die Zusagen machte. Aber es wollte mich nicht enttäuschen. Ich sagte den Leuten, ich hoffte, das Modem würde in der nächsten Woche installiert werden; deshalb

»Nein« sagen

197

versprachen sie, es bis dahin zu installieren, obwohl sie genau wussten, dass dies in der nächsten Woche nicht möglich sein würde. Obwohl die Absicht positiv ist, sind die Konsequenzen negativ. Schließlich wurde ich meinem Kabelmodem-Lieferanten gegenüber etwas ungemütlich und veranlasste ihn sogar, die Installation an einem Feiertag in meinem Haus durchzuführen. Ich traute dem Versprechen nicht mehr, dass es »morgen, nach dem Feiertag« installiert werden würde. Die wiederholt nicht eingehaltenen Zusagen hatten jedes Vertrauen zu diesem Lieferanten zerstört und in mir eine feindselige Einstellung zu ihm geweckt. Andererseits, was passiert, wenn Sie gefragt werden, eine kritische Aufgabe zu übernehmen, und sagen, Sie könnten dies nicht tun? Als Manager von Onshore- und Offshore-Teams kann ich Ihnen versichern, dass ein »Nein« für mich eine Quelle der Erleichterung geworden ist. Wenn ein Team-Mitglied die Stärke besitzt, »Nein« zu sagen, wenn dies der Wahrheit entspricht, dann weiß ich, dass ich ihm bei einem »Ja« vertrauen kann. Eine Zusicherung einer solchen Person ist glaubwürdiger und gewichtiger. Wenn sie tatsächlich die Ziele erfüllt, auf die sie sich festgelegt hat, stelle ich ihre Aussage nicht infrage, wenn sie sagt, etwas könne nicht getan werden. Wenn jemand immer »Ja« sagt, ist er entweder unglaublich talentiert oder er lügt. Normalerweise ist Letzteres der Fall. »Ich weiß nicht« ist an geeigneter Stelle ebenfalls akzeptabel. Vielleicht werden Sie gefragt, ob Sie einen bestimmten Termin einhalten können, und brauchen Zeit für eine genauere Untersuchung der Aufgabe, bevor Sie etwas zusagen können. Oder Sie werden vielleicht gefragt, wie eine Technologie funktioniert oder wie eine bestimmte Komponente Ihres Projekt-Codes implementiert ist. Ähnlich wie bei Zusagen ist die Unkenntnis der Antwort mit dem Gefühl eines kleinen Misserfolgs verbunden. Aber Ihre Kollegen und Vorgesetzten vertrauen Ihnen mehr, wenn Sie behaupten, etwas zu wissen. Sie werden feststellen, dass ein echter Guru eines

30 - »Nein« sagen

Fachgebiets niemals Angst hat, zuzugeben, etwas nicht zu wissen. »Ich weiß nicht« ist keine Phrase für Unsichere. Derselbe Mut hilft auch im Umgang mit Entscheidungen von oben. Wie oft haben Sie erlebt, dass eine technologische Entscheidung von einem Manager vorgeschrieben wurde, Ihre Teammitglieder betreten auf ihre Schuhe starrten und nur auf die Gelegenheit warteten, den Meeting-Raum zu verlassen, um gegenseitig ihre Klagen loszuwerden? Manager werden oft Opfer des Syndroms, dass »der Kaiser keine Kleider anhat«. Jeder weiß, dass eine Entscheidung schlecht ist, aber alle haben Angst, den Mund aufzumachen. Als Manager treffe ich laufend Entscheidungen und mache verbindliche Vorgaben. Doch meine Mitarbeiter sollen keine Roboter sein. Es sind diejenigen, die den Mund aufmachen und bessere Vorschläge einbringen, die zu meinen vertrauenswürdigen Leutnants werden. Übertreiben Sie das »Nein«-Spiel nicht. Selbstvertrauen wird immer noch geschätzt, und es ist gut, anspruchsvolle Ziele zu setzen. Wenn Sie nicht sicher sind, ob Sie etwas tun können, aber es ausprobieren wollen, sagen Sie es. »Es wird nicht leicht werden, aber ich werde es probieren«, ist eine wundervolle Antwort. Manchmal lautet die Antwort natürlich einfach: »Ja.« Haben Sie den Mut, ehrlich zu sein.

Umsetzung i. Karl Brophey, ein Rezensent, schlägt vor, eine Liste aller Zusagen zu führen: •

Was wurde von Ihnen bis zu einem bestimmten Termin gefordert?

•

Was haben Sie zugesagt?

•

Wenn gegen Sie entschieden wurde, halten Sie fest, was Sie selbst gedacht haben und was Sie laut Vorgabe akzeptieren sollten. Halten Sie fest, w a n n Sie geliefert haben.

Umsetzung

199

Prüfen Sie dies täglich. Teilen Sie anderen mit, welche Zusagen Sie nicht einhalten können, sobald Sie dies erkennen. Prüfen Sie monatlich, wie hoch Ihre Trefferquote ist und wie oft Sie Zusagen genau eingehalten haben.

KAPITEL 196

Keine Panik

ch begann meine Karriere als Computer-Programmierer, weil ich Videospiele liebte. Seit den Tagen, als ich Spiele vom Band in meinen Commodore 64 lud, war ich von ihren fesselnden interaktiven Erfahrungen fasziniert. Es war mir damals peinlich, dies zuzugeben, aber heute erkenne ich, dass es nichts ist, dessen man sich schämen müsste. Für mich wandelten die Computerspiele die Umgebung auf dem Bildschirm (vermutlich das Betriebssystem) in eine Umgebung um, in der ich mich wohlfühlte und die mich faszinierte. Mein liebstes Spiel überhaupt war Doom von id Software. Ich war besonders in einen Teil des Spiels vernarrt: das Death Match, in dem man, Spieler gegen Spieler, auf Leben und Tod kämpfte. Die Spieler waren per Modem oder über einen seriellen Anschluss miteinander verbunden und kämpften in kleinen, schnell wechselnden Umgebungen gegeneinander. Ich wurde bei diesen Death Match in Doom wirklich gut. Ich mache oft Scherze darüber, dass dies möglicherweise die Fähigkeit war, die ich bis jetzt in meinem Leben am besten entwickelt habe. Das Death-Match-Spiel ist überraschend komplex. Es hat sowohl technische als auch psychologische Aspekte - vergleichbar einer frenetischen und hektischen Mischung aus Schach und Fechten.

202

3i - Keine Panik

Wie bei den meisten Fähigkeiten sollte man, wenn man wirklich gut werden will, Meister bei der Arbeit beobachten. Damals in meiner Doom-Zeit gab es einen solchen Meister, der online mit dem ironischen Namen »Noskill« (»Stümper«) agierte. Noskill war der Defacto-Doom-Champion. Leute aus ganz Nordamerika bezahlten Geld für Ferngespräche, um ihr Glück gegen ihn zu versuchen. Die Kämpfe wurden alle mit der in Doom eingebauten Aufzeichnungsfunktion dokumentiert. Ich schaute mir jedes an. Es dauerte nicht lange, bis ich hinter sein Geheimnis kam. Sicher, er beherrschte das Spiel im Allgemeinen gut, aber es gab offensichtlich einen Schlüssel zu seinem Erfolg: Er geriet nie in Panik. Doom zählte zu den Spielen, in der eine Runde buchstäblich Sekunden nach ihrem Start vorbei sein konnte. Es war wirklich schnell. Ich erinnere mich an mein erstes Death-Match-Spiel. Starten, sterben, starten, sterben, starten, sterben. Als es mir endlich gelang, länger als einige Sekunden am Leben zu bleiben, lief ich normalerweise ziellos herum und konnte kaum die Übersicht darüber behalten, wo ich war. Doch Noskill reagierte niemals so. Egal, wie schwierig die Situation war, konnte man anhand der Beobachtung der Aufzeichnungen feststellen, dass er immer entspannt war und immer darüber nachdachte, was er als Nächstes tun wollte. Er war sich scheinbar immer bewusst, wie sein gegenwärtiger Kontext in den übergreifenden Verlauf des Spiels passte.

Merksatz Helden geraten nie in Panik.

Wenn Sie mit dieser Einsicht an andere Spiele, insbesondere beim Sport, denken, erkennen Sie, dass die besten Spieler alle diese Qualität gemeinsam haben. Tatsächlich haben auch die Charaktere, die wir in Büchern, Fernsehsendungen und Filmen bewundern, diese Eigenschaft. Helden geraten nie in Panik. Sie sind immer die Leute,

Keine Panik

203

auf deren Stadt eine Atombombe abgeworfen werden kann oder die in einem Flugzeug abstürzen können und die trotzdem die Fähigkeit behalten, eine Gruppe zu organisieren, den Überlebenden zu helfen, den Feind auszutricksen oder wenigstens nicht in Tränen auszubrechen. Dies gilt auch für das wirkliche Leben. Trotz bester Planung ist mein berufliches Leben eine Kette von Notfällen und Katastrophen gewesen. Projekttermine wurden wirklich ernsthaft überschritten. Software-Anwendungen stürzten ab und kosteten meinen Arbeitgeber Geld und Glaubwürdigkeit. Ich sagte das Falsche zum falschen Vorstand und machte mir einen politischen Feind. Meistens kommen solche Dinge in Wellen: immer alle auf einmal, niemals einzeln. In meinen schlimmsten Momenten gerate ich in Panik. Ich mache einfach dicht und kann bestenfalls nur noch taktisch denken. Ich reagiere auf kleine Inputs, ohne die Klarheit, das Gesamtbild zu berücksichtigen. Doch wenn ich auf buchstäblich jedes derartige Desaster zurückblicke, hat nicht ein einziges einen nachhaltigen, merklichen Einfluss auf mich oder meine Karriere gehabt. Egal, wie desorientiert oder deprimiert oder aufgeregt ich in diesen scheinbar katastrophalen Situationen war, war deshalb keine von ihnen ein echtes Desaster. Was hat mir die Panik gebracht? Was war der Vorteil, auf diese Situationen negativ zu reagieren? Nichts. Sie blockierte nur meine besten Fähigkeiten in Situationen, in denen ich diese wirklich brauchte. Nun muss ich zugeben, dass es leichter gesagt als getan ist, in stressreichen Situationen nicht in Panik zu geraten. Es ist vergleichbar damit, jemanden aufzufordern: »Sei einfach glücklich!« Sicher, der Rat ist gut, aber wie macht man das? Wie vermeidet man, in Panik zu geraten, wenn alles auseinanderzufallen scheint? U m diese Frage zu beantworten, hilft es darüber nachzudenken, warum wir in Panik geraten. Wir geraten in Panik, weil wir die Perspektive verlieren. Wenn etwas schiefgeht, ist es schwer, nicht seine gesamte Aufmerksamkeit auf

204

3i - Keine Panik

das Problem zu konzentrieren. Bis zu einem gewissen Grad ist dies eine gute Methode, Probleme zu lösen. Doch leider führt es auch dazu, dass das Problem, ganz egal, wie klein es ist, übermäßig wichtig erscheint. Und wenn das Problem überdimensioniert und der Stress hoch ist, schaltet sich unser Gehirn ab. Wer ist der schlimmste Computeranwender, den Sie kennen? Für mich sind es wahrscheinlich meine Eltern oder mein Schwager (ich weiß wer, aber ich bin klug genug, keine Namen zu nennen). Angenommen, diese Person säße vor ihrem Computer und versuchte, ein Projekt zu beenden; doch bei jeder ihrer Aktionen erschiene eine Fehlermeldung auf dem Bildschirm. Wir haben das alle schon erlebt. Unerfahrene Computeranwender sind schnell frustriert und geraten in Panik. Sie beginnen hektisch, auf der Tastatur herumzuklicken, ziehen Dinge auf dem Bildschirm herum und ignorieren potenziell hilfreiche Fehlermeldungen, die immer wieder angezeigt werden. Schließlich sind sie so durcheinander, dass sie um Hilfe rufen müssen, aber nicht, bevor sie ein oder zwei weitere Dinge auf dem Computer durcheinandergebracht haben. Halten Sie mich nicht für gemein, aber ich möchte, dass Sie sich bei dieser Situation jemanden als Hauptdarsteller vorstellen, den Sie gut kennen, und ich möchte, dass Sie darüber alleine laut lachen. Diese Art von Verhalten ist wirklich lächerlich, nicht wahr? Man sollte darüber lachen. Doch so lächerlich dies wirklich sein mag, beschreibt das gerade vorgestellte Szenario eine Situation aus dem wirklichen Leben einer Person, die außerhalb ihrer Komfortzone auf ein Problem gestoßen und in Panik geraten ist. Ihre Reaktion unterscheidet sich nicht von meiner, wenn ich einen Projekttermin überschritten, aus Versehen ein System zum Absturz gebracht oder einen Kunden bei der Arbeit verärgert habe. Nur der Kontext ist anders. Deshalb beschreibe ich hier, wie ich lerne, nicht in Panik zu geraten. Wenn etwas Schlimmes passiert und sich in mir als Vorbote der Panik dieses Gefühl breitmacht, total gestresst zu sein und die

Umsetzung

205

Kontrolle zu verlieren, vergleiche ich mich mit dem frustrierten Computer-Neuling und lache über mich selbst. Ich analysiere die Situation aus der Perspektive einer dritten Person, so als würde ich einem frustrierten Familienmitglied aus seiner Textverarbeitungskatastrophe helfen. Scheinbar schwierige Probleme sind plötzlich leichter. Scheinbar schlimme Situationen sind plötzlich doch nicht so schlimm. Und oft stelle ich fest, dass die Lösung einfach ist und mir direkt ins Gesicht starrt, etwa in der Form eines Fehlerdialogs, der mir genau sagt, was als Nächstes zu tun ist. Wenn Sie nur die Geistesgegenwart hätten, die Fehlermeldung zu lesen, könnte das Problem schon gelöst sein.

Umsetzung 1. Führen Sie ein Panik-Journal. Der Schlüssel, Panik einzudämmen, bevor sie sich ausbreitet, besteht darin, ein erhöhtes Echtzeit-Bewusstsein Ihrer Wahrnehmungen und Ihrer Gefühle zu entwickeln, während diese entstehen. Ich habe dies am besten dadurch gelernt, dass ich im Nachhinein meine Reaktionen in bestimmten Situationen analysierte. Ich bin nicht klug genug, auf natürliche Weise einen Hintergrund-Thread laufen zu lassen und meine Gedanken während ihres Vollzugs zu analysieren; aber ich habe entdeckt, dass ich die Analyse in Echtzeit immer besser durchführen kann, wenn ich laufend übe, mein Denken »offline« (im Nachhinein) zu analysieren. Zu sagen, man würde besser darin werden, seine Reaktionen zu analysieren, und es tatsächlich zu tun, sind zwei verschiedene Dinge. Ein Tagebuch zu führen, hilft Ihnen dabei, diesen Prozess zu strukturieren. Reservieren Sie jeden Tag eine bestimmte Zeit (verwenden Sie einen Kalender mit einer Erinnerungsfunktion), öffnen Sie eine Textdatei und halten Sie alle Situationen fest, die in Ihnen Panik ausgelöst hat, selbst wenn sie nur klein war. Schauen Sie sich einmal pro Woche die Liste der vergangenen Woche an und registrieren Sie, welchen nachhaltigen Ein-

206

3i - Keine Panik

fluss jede dieser Panik auslösenden Situationen gehabt hat. War es die Situation wert, in Panik zu geraten? Was wäre die produktivste Reaktion in dieser Situation gewesen? Was hätte der Held in einer dramatisierten Filmversion Ihres Lebens anstelle der Panik getan? Nach einiger Übung werden Sie feststellen, dass die Analyse bereits einsetzt, während sich die Panik ausbreitet. Wenn Sie rational die Gründe für Ihre Panik in Echtzeit untersuchen, werden Sie feststellen, dass die Panik selbst in den Hintergrund tritt und sich mit der Zeit auflöst.

KAPITEL 196

Sagen Sie es, tun Sie es, zeigen Sie es

ie einfachste Methode, nie etwas zu erledigen, besteht darin,

D

sich nie auf etwas festzulegen. Ohne Abgabetermin haben Sie keinen Druck und keinen Anreiz, etwas zu Ende zu

bringen. Dies gilt insbesondere dann, wenn die zu erledigende Aufgabe nicht hundertprozentig aufregend ist. Selbst schlechte Manager wissen instinktiv, dass es wichtig ist, zu planen. Einige Entwickler sind beim Wort planen alarmiert. Endlose Meetings mit geschniegelten Chefs, die umfangreiche Ausdrucke

von Microsoft-Project-Plänen mitbringen, die niemand versteht, geben Grund, alarmiert zu sein. Techies rebellieren oft gegen diese wahrgenommene übermäßige Planung, indem sie nach eigenem Gusto arbeiten. Doch Planung kann auch ihr Gutes haben. Planung kann eine befreiende Erfahrung sein. Wenn Sie zu viel zu tun haben, kann ein Plan am Anfang des Arbeitstages den Unterschied zwischen Orientierungslosigkeit und klarsichtigem Selbstvertrauen bei der Bewältigung der Tagesaufgaben bedeuten. Pläne müssen nicht umfangreich und detailtief sein. Eine Liste in einem Textdokument oder in einer E-Mail kann vollkommen ausreichen. Ein großartiger erster Schritt kann darin bestehen, den Tag mit der Frage anzufangen, was man an diesem Tag erreichen will.

208

32 - Sagen Sie es, tun Sie es, zeigen Sie es

Ich kenne viele Leute, deren Tage so hektisch verlaufen, dass sie diese Frage fast nie beantworten können. Ein geeigneter erster Schritt könnte darin bestehen, heute Nachmittag eine Liste aller Dinge aufzustellen, die Sie an Ihrem nächsten Arbeitstag erledigen wollen, und sie nach Priorität zu ordnen. Seien Sie realistisch, was Sie an einem Tag erledigen können, wahrscheinlich schätzen Sie die Zeit falsch ein und nehmen sich zu viel vor. Sie können den Plan für Ihren ersten Tag so allgemein oder ausführlich gestalten, wie Sie wollen. Ich hatte auf der Uni einen Mitbewohner namens Chris, der an jedem Morgen seinen Tag sorgfältig plante, selbst wenn er dadurch riskierte, zu spät zur ersten Vorlesung zu kommen. Er plante speziell seine Übungsstunden als Pianist (sein Hauptfach war Jazz-Piano). Sein Tag war bereits ziemlich rigide durch Vorlesungen vorgeplant, die er besuchen musste. Dennoch plante Chris, wie er die 15 Minuten zwischen einzelnen Vorlesungen für Übungen nutzen wollte, die man schnell erledigen konnte. Viele Vorlesungen fanden im selben Gebäude statt. Deshalb hatten wir gewöhnlich viel Zeit zwischen einzelnen Vorlesungen, um ein schnelles Gespräch zu führen oder uns ein Getränk aus den Verkaufsautomaten zu ziehen. Chris nutzte sie dagegen, um das Notenlesen oder sein Gehör zu trainieren, während der Rest von uns herumsaß und auf den Beginn der nächsten Vorlesung wartete. Er unterteilte seinen Zeitplan sogar in mehrere drei bis fünf Minuten dauernde Segmente, damit er innerhalb von zehn Minuten mehrere Übungen ausführen konnte. Chris wurde später zu einem der anerkanntesten Musiker in unserer Stadt. Angeborenes Talent spielt natürlich auch eine Rolle, aber seitdem glaube ich, dass er seinen Weg in die Musikelite geplant und ausgeführt hat. Sie haben also Ihren Plan erstellt. Vielleicht ist er nicht so detailliert wie der von Chris, aber er reicht aus, um die Frage zu beantworten, was Sie mit Ihrem Tag anstellen wollen. Wenn Sie morgens zur Arbeit kommen, nehmen Sie Ihre Liste und beginnen Sie mit dem ersten Eintrag. Arbeiten Sie bis zum Mittag Punkt für Punkt ab;

20932-Sagen Sie es, tun Sie es, zeigen Sie es

machen Sie danach weiter, wo Sie aufgehört haben, und versuchen Sie, die gesamte Liste zu erledigen. Wenn Sie einen Punkt auf der Liste erledigt haben, markieren sie ihn als FERTIG. Verwenden Sie Großbuchstaben. Sprechen Sie das Wort fertig aus. Schauen Sie sich am Ende des Tages die Liste Ihrer FERTIGEN Aufgaben an und schwelgen Sie in dem Gefühl, etwas erreicht zu haben. Sie haben nicht nur gewusst, was Sie heute tun würden, sondern wissen jetzt auch, was Sie getan haben. Wenn Sie nicht alles erledigen konnten, machen Sie sich keine Sorgen. Sie wussten vorher, dass Sie nicht genau abschätzen konnten, wie viel Sie an einem Tag erledigen könnten. Übertragen Sie einfach die nicht erledigten Einträge von heute auf die Liste von morgen (falls sie immer noch relevant sind), und beginnen Sie den Prozess von Neuem. Es ist ein anregender

Prozess. Er verläuft

rhythmisch. Er ermöglicht es Ihnen, Ihre Tage und Wochen in eine Reihe kleiner Siege aufzuteilen, und treibt Sie von einem zum nächsten. Sie werden feststellen, dass Sie dadurch nicht nur sichtbar machen, was Sie erreichen, sondern tatsächlich mehr erreichen, als wenn Sie die Dinge nicht so genau beobachten würden. Wenn Sie einen Arbeitsrhythmus entwickelt haben, sind Sie bereit, in größeren Zeiträumen (Wochen oder sogar Monaten) zu denken. Natürlich sollte die Ebene Ihres Planes dem Zeitraum angemessen sein, für den Sie planen: je länger der Zeitraum, desto höher die Ebene. Behandeln Sie Ihre Tages- und Wochenpläne als taktische Schlachtpläne und behalten Sie die Monats-, Quartals- und Jahrespläne Ihren strategischeren Zielen vor. Allein darüber nachzudenken, was man in einem Quartal (90 Tagen) erreicht haben möchte, ist für Software-Feldsoldaten etwas Unnatürliches. Wir sind taktische Menschen. Sich selbst zu zwingen, sich einen Endzustand Ihres Systems, Ihrer Team-Prozesse oder Ihrer Karriere nach einem Quartal vorzustellen, bringt Dinge zum Vorschein, mit denen Sie nie gerechnet haben. Wenn man von oben auf ein Feld schaut, sieht man ganz andere Dinge als vom

210

32 - Sagen Sie es, tun Sie es, zeigen Sie es

Boden. Am Anfang ist es nicht leicht, aber bleiben Sie am Ball. Wie alle guten Fähigkeiten wird auch diese mit der Übung leichter; und die Vorteile werden sowohl für Sie als auch für Ihre Kollegen sichtbar (selbst wenn diese nicht wissen, was Sie tun).

Merksatz Statusberichte können dazu beitragen, sich selbst zu vermarkten.

Sie sollten damit beginnen, Ihre Vorgesetzten über Ihre Pläne zu unterrichten. Der beste Zeitpunkt, Pläne bekannt zu geben, ist der Punkt, an dem Sie wenigstens einen Zyklus des Plans umgesetzt haben. Und - dies ist ein wichtiger Punkt - tun Sie es, bevor Sie dazu aufgefordert werden. Kein Manager, der sein Geld wert ist, wäre unglücklich darüber, wöchentlich eine knappe und präzise E-Mail eines Mitarbeiters zu erhalten, in dem dieser zum Ausdruck bringt, was er in der vergangenen Woche erreicht hat und was er in der nächsten Woche zu erreichen plant. Auf diese Art regelmäßig und unaufgefordert informiert zu werden, ist der Traum jedes Managers. Senden Sie Ihre Berichte zunächst Woche für Woche. Wenn Sie sich mit diesem Prozess vertraut gemacht haben, beginnen Sie, an Ihren 30-, 60- und 90-Tage-Plänen (oder Monats- und Quartalsplänen) zu arbeiten. Beschränken Sie sich bei den längeren Betrachtungen auf wichtige höherrangige Fortschritte, die Sie bei den Projekten oder Systemen erzielen wollen, für die Sie zuständig sind. Bringen Sie Ihrem Manager gegenüber immer zum Ausdruck, dass diese langfristigen Pläne als Vorschläge gedacht sind, und bitten Sie um Feedback. Im Laufe der Zeit werden Ihre Versuche der Vorwegnahme von Ihren Managern weniger überarbeitet werden müssen, weil Sie lernen, welche Punkte normalerweise einfach akzeptiert werden und welche größere Änderungen erfordern. Beim Planen dürfen Sie einen sehr kritischen Faktor niemals vergessen: Über alles, was in einen Plan eingeht, sollte später Rechen-

21132-Sagen Sie es, tun Sie es, zeigen Sie es

schaft abgelegt werden. Jeder Punkt sollte entweder sichtbar erledigt, verschoben, gelöscht oder ersetzt worden sein. Es sollte keine Punkte geben, zu denen keine Rechenschaft abgelegt wurde. Wenn auf einem Plan Punkte erscheinen, die nie wieder erwähnt werden, verlieren die Mitarbeiter das Vertrauen in Ihre Pläne; und Sie unterlaufen mit solchen Plänen die Wirksamkeit der Planung überhaupt. Selbst wenn das Ergebnis schlecht ist, sollten Sie es deutlich kommunizieren. Wir machen alle Fehler. Wenn Sie sich von anderen unterscheiden wollen, sollten Sie offen zu Ihren Fehlern oder fehlenden Fähigkeiten stehen und um Hilfe bitten, sie zu beheben. Wenn Aufgaben auf einem Plan konsistent nachgehalten werden, entsteht mit Recht der Eindruck, dass keine wichtige Arbeit in der allgemeinen Hektik vergessen werden kann. Wenn Sie diesen Prozess einführen, haben Sie in den Augen Ihres Managements plötzlich Ihre strategische Seite offenbart. Wer Pläne erstellt und ausführt, zeigt damit, dass er nicht nur ein Roboter ist, der Code eintippt, sondern dass er ein Leader ist. Es ist diese Art unabhängiger Produktivität, die Unternehmen benötigen, um ihren Overhead zu reduzieren. Ein letzter Vorteil, in Form von Plänen zu kommunizieren, besteht darin, dass Ihre Zusagen glaubhafter werden. Wenn Sie sagen, dass Sie etwas tun werden, es dann tun und dann zeigen, dass es erledigt ist, entwickeln Sie eine Reputation als Macher. Mit der Glaubwürdigkeit kommt der Einfluss. Angenommen, Sie wollten in einem Unternehmen eine neue Technologie oder einen neuen Prozess einführen, etwa die Praxis der agilen Entwicklung (www.agilemanifesto.org). Mit der nachgewiesenen Fähigkeit, Zusagen zu geben und einzuhalten, wird Ihnen ein größerer Spielraum eingeräumt, neue Dinge auszuprobieren. In unserem Software-Zentrum in Bangalore hatten wir ein Team, das länger als ein Jahr Nachtschichten einlegte. Von den sieben Mitgliedern des Teams arbeiteten immer zwei nachts. Sie rotierten wöchentlich, so dass jedes Teammitglied jede dritte oder vierte

212

32 - Sagen Sie es, tun Sie es, zeigen Sie es

Woche von 1 9 : 0 0 Uhr abends bis 3:00 Uhr nachts arbeitete. Das Team war zunehmend frustriert und ausgebrannt und beklagte sich, fast immer unter einem Jetlag zu leiden. Doch das Team spielte eine wichtige Support-Rolle; und die internen Kunden des Teams in den USA waren überzeugt, nicht ohne die Echtzeithilfe der Gruppe in Bangalore auszukommen. Deswegen entwickelte das Team einen Plan, wie die Situation geändert werden könnte. Die Mitglieder schauten sich die verschiedenen Support-Prozesse und zugehörigen Einheiten an und stellten einen Plan auf, wie man sowohl zu einer einzigen Tagesschicht zurückkehren als auch zugleich den Prozess für die Kunden beträchtlich verbessern könnte. Als zuständiger Leiter für den Betrieb des Software-Zentrums half ich ihnen bei den Feineinstellungen ihres Planes und war (als moralische Unterstützung) bei seiner formellen Präsentation bei ihrem Vorgesetzten in den Vereinigten Staaten anwesend. Sie wussten, dass dies für ihren Vorgesetzten ein sensibles Thema war, der seinen Kunden in den USA persönlich Rede und Antwort stehen musste. Natürlich machten sich die Teammitglieder vor dem Meeting Sorgen. Doch ihr Chef war so beeindruckt, dass er sofort und glücklich den Vorschlag annahm. Das Team setzte seinen Plan um. Innerhalb von Wochen war der Jetlag vorbei, und jeder arbeitete wieder in einer Tagesschicht. Die Fundiertheit ihres Plans, nicht nur die Arbeitsstunden zu ändern, sondern auch strategisch die Performance des Teams zu verbessern, schuf bei den Vorgesetzten und letztlich auch bei den Kunden ein großes Vertrauen in das Team. Der Leiter des Teams benutze den Plan, um die Änderungen seinen Kunden zu vermitteln. Und das Team zog mit. Innerhalb von Monaten erreichte das Team ein neues Effizienzniveau. Es hat seitdem so viel an Glaubwürdigkeit und Vertrauen gewonnen, dass ihm immer mehr Spielraum für eigenverantwortliche und unabhängige Arbeit eingeräumt wurde.

21332-Sagen Sie es, tun Sie es, zeigen Sie es

Das Team benutzte seinen Plan als konkrete Lösung für ein Problem. Es ging nicht mit Beschwerden, sondern mit Lösungsvorschlägen zu seinem Leiter. Ihre Führer wünschen sich, dass Sie unabhängig und eigenverantwortlich handeln. Pläne aufzustellen, auszuführen und zu kommunizieren, trägt dazu bei, dass Sie beides erreichen.

Scheitern und Kopieren von Patrick Wilson Larry Wall schrieb, die Eigenschaften eines großartigen Programmierers wären Faulheit, Ungeduld und Hybris. Ich weiß nicht, ob sie angeboren sind oder durch eine fleißige Selbstverbesserung erworben werden können. Doch weder bei dem einen noch dem anderen ist offensichtlich, wie Sie durch diese Informationen ein besserer Programmierer werden können. Deshalb sollten wir nicht auf Eigenschaften achten, sondern uns mit Aktivitäten befassen, die zur Verbesserung beitragen. Müsste ich zwei auswählen, fiel die Wahl auf das Scheitern und das Kopieren. Ich scheitere häufiger als die meisten Programmierer, die ich kenne. Ganz sicher scheitern meine meisten Projekte. In meinem ~/Projects-Ordner befinden sich viele unbeachtete Bemühungen, etwas Interessantes zu tun. Jede einzelne hat ungefähr dieselbe Chance, ein Erfolg zu werden, wie ein Hummer, der aus seinem Kochtopf entkommen will. Sie sind irgendwie interessant. Ähnlich wie Familien haben erfolgreiche Projekte etwas Gemeinsames; doch alle nicht erfolgreichen Projekte scheitern auf ihre eigene Weise. Und obwohl es fast ein Klischee ist, zu sagen, ein gescheitertes Unternehmen hinter sich zu haben, sei eine großartige Erfahrung, habe ich Ähnliches über die Programmierung noch

214

32 - Sagen Sie es, tun Sie es, zeigen Sie es

nicht gehört. (Doch ich bin in beidem gut. Ich habe auch gescheiterte Unternehmen hinter mir.) Ein kommerzielles Scheitern schafft in der Regel eine sehr direkte Art von Erfahrung. Sie lernen, wie wichtig es ist, Ihr Bargeld zusammenzuhalten, oder Sie arbeiten gezielter. Aber beim Programmieren ist nicht so sehr die Erfahrung zu scheitern wertvoll, sondern das Wissen, das Sie beim Arbeiten an der Art von Projekten erwerben, die wahrscheinlich scheitern werden. Als ich anfing zu programmieren, verbrachte ich viel Zeit damit, Misserfolge beim Schreiben aller möglichen faszinierenden Dinge zu produzieren: Betriebssysteme, Dateisysteme, virtuelle Maschinen, Reimplementierungen von Netzwerkprotokollen, Interpreter und JIT-Compiler. Die meisten davon funktionierten nicht richtig, und die, die funktionierten, waren immer noch ziemlich schlecht. Natürlich waren die meisten, selbst wenn man die technischen Aspekte außer Acht lässt, von Anfang an zum Scheitern verurteilt. Ich weiß nicht, welchem Bruchteil eines Prozents die Erfolgsrate neuer Betriebssysteme entspricht; aber sie ist sehr klein. Dennoch macht mir diese Art zu programmieren am meisten Spaß. Solche Projekte repräsentieren fundamentale Probleme der Software-Entwicklung, losgelöst von allem Überflüssigen. Es geht immer um Abwägungen zwischen Speicherplatz, Geschwindigkeit, Zuverlässigkeit und Komplexität, ohne dass man auf ein gefälliges Äußeres oder ein fehlerhaftes API achten müsste. Es handelt sich um die Art reiner Probleme, von denen monatelang absorbiert werden kann, ohne eine funktionsfähige Lösung zu produzieren - was ich regelmäßig demonstriert habe.

21532-Sagen Sie es, tun Sie es, zeigen Sie es

Ich bin nicht genau sicher, warum, aber wenn Leute heute programmieren lernen, scheinen sie diese Erfahrung nicht mehr so häufig zu machen. Ich glaube, dass das zumindest teilweise am Aufkommen der webbasierten Software liegt. Gerade vor einigen Tagen fragte jemand bei Hacker News, ob noch jemand daran interessiert wäre, clientseitige Software zu schreiben. Es ist eine Übertreibung, die aber nicht sehr weit von der Wahrheit entfernt ist. Und hallo - webbasierte Software ist wirklich cool. Doch vom Standpunkt des Programmierens aus hat diese Verlagerung einen Nachteil. Webanwendungen müssen sich eigentlich erst dann mit schwierigen technischen Herausforderungen auseinandersetzen, wenn es um riesige Datenmengen und Skalierbarkeit geht. (Lassen wir die Kompatibilität mit Internet Explorer 6 außen vor.) Anders ausgedrückt: Die Barriere, um Programme zu schreiben, die scheitern, ist höher geworden. Zunächst müssen Sie Erfolg haben. Deshalb ist es in Anbetracht dieser Verlagerung zu webbasierter Software meiner Meinung nach wichtig, sich aktiv Projekte auszusuchen, bei denen ein Scheitern wahrscheinlich ist. Was ist mit dem Kopieren? Jeder wird Ihnen sagen, dass Sie guten Code lesen sollten, wenn Sie ein besserer Programmierer werden wollen. Obwohl das wahrscheinlich nicht wörtlich gemeint ist (denn das wäre viel zu langweilig), bleibt die Forderung, zu »lesen«, im Kern die falsche Idee: Lesen ist passiv. Stattdessen müssen Sie meiner Meinung nach aktiv kopieren, in großem Umfang und ohne Scham. Dies gilt natürlich für viele Dinge. Hunter S. Thompson las nicht nur gute Bücher; er tippte Hemingway und Fitzgerald ab.

216

32 - Sagen Sie es, tun Sie es, zeigen Sie es

Und die ältesten bekannten Bach-Manuskripte sind Transkriptionen,

die

Bach

von

Werken

anderer

Organisten

erstellte. Am berühmtesten ist vielleicht Gates, der in Harvard Programme aus Abfalleimern herausfischte. Es ist nicht schwer zu verstehen, wie dies hilft. Wer kopiert, schult sein Gedächtnis. Er bekommt ein Gefühl für die Nuancen und die Form des Originals - die Art von Details, die beim schnellen Überfliegen verloren gehen. Bei Code gibt es noch einen weniger offensichtlichen - aber wichtigen - Vorteil. Das Kopieren hilft Ihnen, bei Projekten voranzukommen, die wahrscheinlich scheitern werden. Dies kann etwa eine direkte Transkription der Implementierung einer Hash-Tabelle sein (die meinen ersten selbst geschriebenen Interpreter erheblich beschleunigte) oder ein Design, das von einem Original nur inspiriert oder geformt wurde (wie etwa Linux durch Minix). Bestenfalls führt das zu einer Art Circulus virtuosus von Scheitern und Kopieren, der eine Art bequemer Selbstverbesserung darstellt. Sie nehmen eine schwierige Aufgabe in Angriff, stolpern über ein Problem, das Sie selbst nicht lösen können, kopieren die Lösung eines anderen, und voilä plötzlich können Sie das Problem lösen, was auch immer es gewesen sein mag. Bei diesem ungehemmten Plündern, bei dem Sie en gros verschiedene Techniken absorbieren, finden Sie oft neue Wege, vorhandene Komponenten auf neue Weise zu kombinieren. Ich bin nicht sicher, was Picasso meinte, als er sagte: »Gute Künstler kopieren, während großartige Künstler stehlen.« Vielleicht war er nur absichtlich pervers, aber die erste Bedeutung drückt aus, was ich immer angenommen habe.

21732-Sagen Sie es, tun Sie es, zeigen Sie es

Das Programmieren ist voller seltsamer Ideen. Kürzere, weniger aussagekräftige Namen zu verwenden, erzeugt oft Code, der insgesamt besser lesbar ist. Die leistungsstärksten Sprachen verfügen normalerweise über weniger Konzepte als die schwächeren. Und Scheitern und Kopieren ist möglicherweise die beste Methode, erfolgreich innovative Arbeit zu leisten. Patrick Collison ist Student am MIT

Teil 4

Marketing nicht nur für Anzugträger

Sie sind der talentierteste Software-Entwickler, den Sie kennen. Aus dem anscheinend unerschöpflichen Strom Ihrer Kreativität fließt ein elegantes Design nach dem anderen. Ihr Einsichtsvermögen als Architekt sucht an Ihrem Arbeitsplatz seinesgleichen. Sie können schneller und genauer codieren als jeder andere, der je bei Ihrem Unternehmen beschäftigt war. Na und? Viele Software-Entwickler - und wie es scheint, besonders die eingebildetsten - leben in dem Irrglauben, ihre Fähigkeiten wären für jeden fähigen Manager oder Arbeitgeber offensichtlich. Sie verstehen es geschickt, diesen Selbstbetrug in einer Wolke einer zurechtgezimmerten moralischen Haltung zu verbergen: Sie sind einfach zu bescheiden, ihre eigenen Fähigkeiten zu vermarkten. Sich darum zu bemühen, die eigenen Fähigkeiten bekannt zu machen, ist für sie Schleimerei. Kein Programmierer mit Selbstrespekt ließe sich gern dabei ertappen, sich bei seinem Chef lieb Kind zu machen.

Das ist alles nur eine Entschuldigung. In Wirklichkeit haben sie Angst. Die meisten Programmiertypen waren als Kinder Außenseiter. In der Schule wurden sie immer als Letzte bei Mannschaftswettbewerben für ein Team ausgewählt. Wahrscheinlich vermieden sie Geselligkeiten, wann immer es möglich war. Und wenn es nicht möglich war, scheiterten sie miserabel. Deshalb ist es nicht überraschend, dass diese Menschen Angst haben, den Kopf bei dem Versuch zu riskieren, jemandem die eigenen Fähigkeiten zu demonstrieren. Lassen Sie uns den Unglauben für einen Moment vergessen und vorgeben, dieser moralisch-ethische Unsinn wäre schließlich doch nicht so aufgesetzt. Unabhängig von der eigenen Einstellung ist es dumm,

seine

Fähigkeiten

anderen Menschen

vorzuenthalten.

Betrachten Sie es folgendermaßen: Sie sind dafür angestellt, Software zu entwickeln, die für ein Unternehmen einen Mehrwert schafft. Die Aufgabe eines Leiters besteht darin, Teams zusammenzustellen, die für das Unternehmen einen maximalen Mehrwert schaffen. Wie soll ein Leiter diese Aufgabe lösen können, wenn er nicht weiß, wer in dem Unternehmen welche Art von Arbeit leisten kann? Ein Manager erzählte mir kürzlich: Wenn jemand etwas wirklich Fantastisches leistet und niemand davon erfährt, wäre es in seinen Augen nicht passiert. Das hört sich vielleicht rücksichtslos an, ist aber aus der Sicht eines Unternehmens verständlich. Pragmatisch betrachtet haben Manager nicht die Zeit, bis ins Detail zu verfolgen, was jeder Mitarbeiter jeden Tag tut. Und weder Unternehmen noch ihre Mitarbeiter möchten, dass Manager ihre Zeit darauf verwenden. Unternehmen wollen, dass sich Manager auf das Gesamtbild konzentrieren - und nicht, dass sie die alltäglichen Aufgaben überwachen. Und Mitarbeiter (insbesondere Programmierer) hassen es, bis ins kleinste Detail kontrolliert zu werden. Kurz gesagt: Vielleicht haben

Sie das beste Produkt in der

Geschichte, aber wenn Sie nicht dafür werben, wird es niemand

kaufen. Besonders in der Software-Welt wissen wir alle, dass nicht immer das beste Produkt gewinnt. Für den Erfolg im Markt ist sehr viel mehr erforderlich als ein großartiges Produkt. Sie dürfen diese Wahrheit auch im Arbeitsmarkt nicht vergessen. Das reicht mir schon ... was sollte ich tun? Oberflächlich betrachtet ist die Vermarktung der eigenen Person einfach. Sie haben nur zwei Ziele: Erstens müssen Sie anderen Menschen mitteilen, dass Sie existieren, und zweitens müssen Sie darüber informieren, dass Sie die Person sind, die die schwierigen Probleme lösen kann, die ihnen den Schlaf rauben. Dies gilt nicht nur für den Arbeitsmarkt insgesamt, sondern auch in dem Unternehmen, in dem Sie gegenwärtig arbeiten. Nehmen Sie nicht an, dass das Management weiß, wer Sie sind, bloß weil Sie bei diesem Unternehmen angestellt sind. Nehmen Sie außerdem nicht an, dass ein Manager, der Ihren Namen kennt, deswegen auch nur die geringste Ahnung von Ihren Fähigkeiten hat. Dieser Teil hilft Ihnen nicht nur, dafür zu sorgen, dass Ihre gegenwärtigen Vorgesetzten Ihre Fähigkeiten kennen, sondern zeigt Ihnen auch, wie Sie Ihr Wirkungsfeld auf die Branche insgesamt ausdehnen können. In dem Buch ging es bis jetzt um Vermarktbarkeit. Jetzt werden Sie lernen, Ihre Vermarktbarkeit in die Tat umzusetzen.

KAPITEL 196

Wahrnehmungen, Verzerrungen

s ist bequem, den Idealisten zu spielen und vorzugeben, es sei

E

Ihnen egal, was andere Leute über Sie denken. Aber das ist

nur Gedankenspielerei. Sie dürfen daran nicht glauben. Sie

sollten sich darum kümmern, was andere Leute über Sie denken. Wahrnehmung ist Wirklichkeit. Finden Sie sich damit ab. Wahrscheinlich haben

Sie schon das klischeehafte

Zen-Koan

gehört: »Welches Geräusch macht ein fallender Baum in einem Wald, wenn niemand da ist, ihn beim Fallen zu hören?« Die korrekte Antwort auf diese Frage lautet: »Wen kümmert's?« Ich meine: Wahrscheinlich macht das Umfallen Geräusche. Das ist auf metaphysischer Ebene keine aufregende Antwort. Aber wenn niemand den Baum fallen hörte, spielt die Tatsache, dass dabei ein Geräusch entstand, nicht wirklich eine Rolle. Dasselbe gilt für Ihre Arbeit. Wenn Sie sich wirklich anstrengen und niemand es bemerkt, haben Sie sich dann wirklich angestrengt? Wen kümmert's? Niemanden. Ich war erstaunt, wie die Leute in der Subkultur der indischen ITBürokratie diese simple Wahrheit einfach nicht in ihre Birne bekamen. Fast niemand, mit dem ich dort zu tun hatte, verstand, warum ihre Manager wissen sollten, was sie taten. Wenn sie selbst wussten, besser als Soundso zu sein, sollte dies in ihren Leistungsbeurteilun-

224

33 - Wahrnehmungen, Verzerrungen

gen, Einstufungen und Gehältern zum Ausdruck kommen. Sie machten sich selbst mit ihrem Denken vor, die Art, wie sie von anderen Menschen wahrgenommen werden, wäre auf irgendeine Weise der wie auch immer gearteten Wahrheit untergeordnet. Diese Wahrheit... was ist sie? Wer definiert sie? Was ist gut und was ist schlecht, absolut betrachtet? Die Antwort lautet: Es gibt kein absolut Gutes oder Schlechtes, zumindest nicht, wenn es um die Beurteilung geht, wer den Job eines kreativen Wissensarbeiters besser ausfüllt. Wie definiert man, was einen guten Song ausmacht? Wie definiert man ein gutes Gemälde? Jeder hat wahrscheinlich seine eigenen Definitionen, und ein Konsens ist kaum herzustellen. Die Einschätzungen sind subjektiv.

Merksatz Leistungsbeurteilungen sind niemals objektiv.

Schrecklich risikoscheue Personalabteilungen in schrecklich risikoscheuen Unternehmen bemühen sich sehr, das Leistungsverhalten ihrer Mitarbeiter »objektiv« zu messen. Manchmal implementieren sie sogar »objektive« Beurteilungssysteme. Alle Mitglieder meines Teams in Indien dachten, ihre Leistung sollte auf diese Art und Weise gemessen werden. Das lag daran, dass sie noch nie unter einem solchen System gearbeitet hatten. Es gibt keine Methode, die Qualität eines Wissensarbeiters oder die Qualität seiner Arbeit objektiv zu messen. Nur zu. Widersprechen Sie. Denken Sie dann eine Weile über Ihre Argumente nach. Sehen Sie die Lücken? Wenn also der Maßstab für Ihre Qualität in Ihrem Unternehmen (oder in der Branche oder im Arbeitsmarkt oder wo auch immer) subjektiv ist, was bedeutet das? Es bedeutet, dass Ihre Beurteilung immer davon abhängt, wie Sie von anderen wahrgenommen werden. Ihre möglichen Beförderungen oder Gehaltserhöhungen

-

225

Wahrnehmungen, Verzerrungen

selbst die Entscheidung, ob Sie Ihren Arbeitsplatz überhaupt behalten sollten - hängen vollkommen davon ab, wie Sie von anderen wahrgenommen werden. Subjektivität basiert auf persönlichem Geschmack. Das bedeutet, dass Sie sich nicht darauf verlassen können, dass zwei beliebige Meinungen zu demselben Ergebnis kommen. Verschiedene Menschen werden durch unterschiedliche Faktoren beeindruckt. Einige Leute ziehen fest gefügte Strukturen vor, während andere eine lockere freie Kreativität höher schätzen. Einige kommunizieren lieber per E-Mail, andere ziehen Telefonate oder persönliche Gespräche vor. Einige Manager arbeiten lieber mit aggressiveren Mitarbeitern, während andere eher zurückhaltende Menschen bevorzugen.

Sie sagen

»Schina« - ich sage »Kina«. Letztlich geht es nur um persönliche Präferenzen. Menschen, die in verschiedenen Rollen Beziehungen zu Ihnen haben, bauen ihre Wahrnehmungen anhand der Qualitäten auf, die für sie am wichtigsten sind, u m diese spezielle Beziehung möglichst reibungslos und angenehm zu gestalten. Als Projektmanager ist die Qualität Ihres Sourcecodes für mich viel weniger wichtig als die Qualität Ihrer Kommunikation. Als Programmierkollege wird meine Art, Sie wahrzunehmen, viel stärker von Ihrer schieren Fähigkeit und Kreativität bestimmt als etwa von Ihrer Ergebnisorientierung. Doch als Ihr Manager ist Ihre schiere Fähigkeit für mich letztlich bedeutungslos, wenn Sie nicht in der Lage sind, damit Dinge durchzuziehen. In unserer Kultur werden wir darauf dressiert, die Steuerung der Wahrnehmung als eine irgendwie schmutzige und schändliche Aktion wahrzunehmen.

Doch wie Sie sehen, ist die Steuerung der

Wahrnehmung einfach nur praktisch. Wenn Sie ausdrücklich auf die Faktoren achten, die bestimmen, wie Sie von anderen Menschen wahrgenommen werden, können Sie zuverlässiger herausfinden, wie Sie Ihre Kunden zufriedenstellen können. Sie werden einen nicht technisch orientierten Geschäftskunden nicht mit Ihren Fähigkeiten beeindrucken, elegante objektorientierte Designs zu

226

33 - Wahrnehmungen, Verzerrungen

entwerfen. Vielleicht sind Sie ein Design-Genie, aber wenn Sie nicht wirksam kommunizieren können und Ihre Arbeit nicht rechtzeitig erledigen, halten Ihre Kunden Sie für einen Stümper. Es ist nicht ihre Schuld. Sie sind ein Stümper. Wahrnehmungen sind wirklich wichtig. Sie bestimmen, ob Sie angestellt (oder arbeitslos) bleiben. Sie bestimmen, ob Sie befördert werden oder jahrelang auf derselben Position festhängen. Sie bestimmen, ob Sie Gehaltserhöhungen bekommen oder sich mit einem niedrigen Gehalt zufriedengeben müssen. Je schneller Sie sich überwinden und lernen, Wahrnehmungen anderer gezielt zu managen, desto eher werden Sie auf dem richtigen Weg sein.

Umsetzung i. Wahrnehmungen

werden

von

unterschiedlichen

Faktoren

gesteuert, die von der jeweiligen Zielgruppe (oder Zielperson) abhängen. Ihrer Mutter ist es egal, wie gut Sie objektorientierte Systeme designen können, Ihren Teamkollegen wahrscheinlich nicht. Zu verstehen, was in jeder Ihrer Beziehungen wichtig ist, ist ein wichtiger Aspekt, um glaubwürdige Wahrnehmungen in denjenigen aufzubauen, mit denen Sie interagieren. Denken Sie an die verschiedenen Klassen von Beziehungen, die Sie im Allgemeinen zu den Menschen im Büro haben. Beispielsweise haben Sie wahrscheinlich Teamkollegen, die ähnliche Arbeit wie Sie leisten. Sie haben wahrscheinlich auch einen direkten Vorgesetzten, möglicherweise einen oder mehrere Kunden sowie einen Projektmanager. Setzen Sie diese verschiedenen Gruppen (oder die in Ihrer Situation oder an Ihrem Arbeitsplatz relevanten Gruppen) auf eine Liste. Schreiben Sie dann neben jede einzelne Gruppe diejenigen Ihrer Eigenschaften, die höchstwahrscheinlich bestimmen, wie Sie von dieser Gruppe wahrgenommen werden. Hier ist ein Beispiel:

Umsetzung

227

Gruppe

Die Wahrnehmung beeinflussende Faktoren

Teamkollegen

Technische Fähigkeiten, soziale Fähigkeiten, Teamwork

Manager

Führungsqualitäten, Kundenorientiertheit, Kommunikationsfähigkeiten, Ergebnisorientierung, Teamwork

Kunden

Kundenorientiertheit, Kommunikationsfähigkeiten, Ergebnisorientierung

Projektmanager

Kommunikationsfähigkeiten, Ergebnisorientierung, Produktivität, technische Fähigkeiten

Denken Sie gründlich über Ihre eigene Liste nach. Wie könnten Sie Ihr Verhalten aufgrund dieser Liste ändern? In welcher Weise haben Sie bereits Ihren Fokus bei der Interaktion mit jeder Gruppe angepasst? In welcher Weise haben Sie Ihr Verhalten nicht angemessen angepasst?

KAPITEL 196

Führer für eine Abenteuerreise

A

uf die Gefahr hin, einen Allgemeinplatz breitzutreten, möchte ich sagen: Der wichtigste Aspekt, u m sich an seinem Arbeitsplatz bekannt zu machen, ist Ihre Fähigkeit zu

kommunizieren. Die Tage, in denen unordentliche Hacker, über ihr Terminal gebeugt, im Licht ihres Monitors in den tiefsten Eingeweiden des Server-Raums codierten, sind Geschichte. Ein gelegentliches einsilbiges Grunzen zwischen zwei Codierschüben bringt es nicht. So beunruhigend der Vorschlag auch sein mag: Versetzen Sie sich in das Denken eines Managers oder Kunden. (Ich werde das Wort Kunde in diesen Kapiteln für beide Gruppen verwenden.) Sie sind dafür verantwortlich, für ihren Geschäftserfolg wirklich Entscheidendes irgendwelchen IT-Typen zwecks Implementierung anzuvertrauen. Sie helfen, so gut sie können, um die Dinge voranzubringen, aber letztlich sind sie der Gnade dieser Programmierer ausgeliefert. Darüber hinaus wissen sie nicht, wie sie diese kontrollieren könnten. Sie wissen nicht einmal, wie sie sich mit den Programmierern intelligent über deren Arbeit unterhalten könnten. Was ist in einer solchen Situation das wichtigste Attribut, das sie bei einem Teammitglied suchen? Ich wette um den Preis dieses Buches mit Ihnen, dass es nicht die Frage ist, ob der Programmierer die

230

34 _ Führer für eine Abenteuerreise

neuesten Design-Patterns auswendig herunterbeten kann oder wie viele Programmiersprachen er beherrscht. Kunden versuchen, jemanden zu finden, der ihnen durch seine Art, mit dem Projekt umzugehen, Vertrauen einflößen kann.

Merksatz Ihre Kunden haben Angst vor Ihnen.

Diese Manager und Kunden, über die wir hier sprechen, haben ein schmutziges kleines Geheimnis: Sie haben Angst vor Ihnen. Und das aus gutem Grund: Sie sind intelligent. Sie sprechen eine geheime Sprache, die die Kunden nicht verstehen. Sie geben ihnen mit Ihren manchmal sarkastischen Kommentaren das Gefühl, dumm zu sein (selbst wenn Sie gar nicht sarkastisch sein wollten). Und Ihre Arbeit ist oft die letzte und wichtigste Barriere zwischen der Konzeption des Projekts und seiner Geburt. Ihre Aufgabe ist es, Ihre Kunden als Reiseführer sicher durch das strapaziöse Gebiet der Welt der Informationstechnologie zu leiten. Sie sollen für das Wohlbefinden Ihrer Kunden sorgen, während Sie sie durch eine fremde Landschaft führen. Sie sollen ihnen die Sehenswürdigkeiten zeigen und sie dorthin bringen, wo sie hin wollen, und dabei die heruntergekommenen Viertel der Stadt vermeiden, die sie in der Vergangenheit erkundet haben. Nicht-Programmierer sind durchschnittlich genauso intelligent wie Programmierer. (Damit will ich sagen: Die meisten sind nicht sehr intelligent, aber einige wenige sind wirklich brillant.) Es ist nicht unwahrscheinlich, dass Ihr Kunde genauso intelligent wie Sie ist, doch zufällig nur keinen Computer programmieren kann. Das ist in Ordnung. Wahrscheinlich wissen Sie umgekehrt auch nicht, wie man einen großen Teil seiner Alltagsarbeit erledigt. Deswegen gibt es zwei von Ihnen, und Sie werden beide dafür bezahlt, Ihre jeweilige Arbeit zu erledigen.

23134_Führer für eine Abenteuerreise

Ich erwähne die Intelligenz hier ausdrücklich, weil Computer-Leute allzu oft annehmen, Menschen, die keinen Computer bedienen können, wären nicht intelligent. So formuliert hört sich das idiotisch an, aber es gilt für alle Vorurteile. Dennoch ist dieses Gefühl so tief in vielen verwurzelt, dass wir uns seiner Existenz nicht einmal bewusst sind. Absichtlich zu versuchen, es zu kontrollieren, funktioniert nicht. Ich rate Ihnen, die Beziehung umzukehren. Anstatt zu fühlen, Sie wären das Computergenie, das aus dem Computer-Himmel herabgestiegen ist, um seinen armen Kunden aus dem Fegefeuer zu retten, sollten Sie es von der anderen Seite betrachten. Wenn Sie etwa in der Versicherungsbranche programmieren, betrachten Sie Ihren Kunden als Fachmann für Versicherungen, von dem Sie lernen müssen, damit Sie Ihre Arbeit erledigen können. Doch davon abgesehen müssen Sie sehr bewusst darauf achten, in welcher Sprache Sie mit Ihren Kunden kommunizieren, wenn es um Software-Fragen geht. Verwenden Sie zu viele Fachausdrücke, wirken Sie schnell arrogant, verwenden Sie zu wenige, fühlt sich der Kunde möglicherweise als Dummie hingestellt. »Warum reden wir hier die ganze Zeit davon, wie man Kunden behandeln sollte? Ich dachte, hier ginge es darum, wie man sich selbst vermarktet.« Wenn Sie in einer typischen IT-Abteilung arbeiten, stammt ein großer Teil des Budgets, das Ihre fortwährende Anstellung garantiert, aus einer Geschäftsfunktion - und zwar derselben Geschäftsfunktion, für die Ihre Kunden zuständig sind und deren Entscheidungen sie beeinflussen. Wenn über Beförderungen und die Neubesetzung von Positionen entschieden wird, ist der beste Fürsprecher, den Sie haben können, ein Kunde, der nicht ohne Sie leben möchte. Doch stellen Sie sich umgekehrt auch den Einfluss vor, den ein Kunde haben kann, der sich von Ihnen herablassend behandelt fühlt. Ihr Kunde repräsentiert die Bedürfnisse des Geschäfts, und Sie werden dafür bezahlt, die Mittel zur Befriedigung dieser Bedürfnisse zur Verfügung zu stellen. Vergessen Sie dies niemals!

232

34 - Führer für eine Abenteuerreise

Umsetzung 1. Prüfen Sie sich selbst: Sind Sie ein alter grummeliger Codiergnom, der von jedem gefürchtet wird? Sind Sie sicher? Haben die Leute Angst, es Ihnen zu sagen? Durchforsten Sie Ihre Mailbox und suchen Sie nach E-Mails, die Sie an weniger technisch orientierte Mitarbeiter, Manager und Kunden geschickt haben. Versuchen Sie, diese E-Mails aus der Perspektive der Empfänger zu lesen. Wenn einige Zeit seit der Nachricht vergangen ist, werden Sie sich selbst wie aus der Perspektive eines unbeteiligten Dritten sehen können. Noch besser: Zeigen Sie diese E-Mails Ihrer Mutter. Sagen Sie ihr, jemand von der Arbeit habe diese Nachrichten an einen Kunden geschickt, und fragen Sie sie, welches Gefühl die Nachrichten in ihr auslösen würden. 2. Springen Sie über den Zaun: Suchen Sie nach Situationen, in der Sie nicht der Experte sind und deshalb von anderen abhängen, die es sind. Haben Sie zwei linke Füße, stellen Sie sich vor, Sie würden in einer Fußballmannschaft spielen. Haben Sie zwei linke Daumen, stellen Sie sich vor, Sie müssten an einem Mannschaftswettbewerb im Stricken teilnehmen. Wie sollten dann Ihre Teamkollegen mit Ihnen kommunizieren?

KAPITEL 196

Mich richtig gut schreiben

ie Tage der einsilbig vor sich hingrunzenden Programmie-

D

rer

sind

Geschichte.

Wenn

Unternehmen

heutzutage

Schwierigkeiten haben wollen, mit ihren Programmierern

zu kommunizieren, bringen sie ihre Programmierer auf einem anderen Kontinent in anderen Zeitzonen unter und kommunizieren mit ihnen nur per E-Mail oder Telefon. Offensichtlich ist das Problem der Kommunikation wichtig. Auf der Liste der Aufgaben, die Sie beherrschen müssen, um Ihre Anstel-

lung zu behalten, wirkt es vielleicht etwas fehl am Platz, einfältig oder trivial. Vielleicht haben Sie das Gefühl, wieder im Deutschunterricht auf Ihrem Gymnasium zu sitzen. Das ist in Ordnung. Tatsächlich können Sie ja diesmal besser aufpassen. Bringen wir das Langweiligste zuerst hinter uns: Grammatik und Rechtschreibung sind wichtig. Vielleicht haben Sie einen Abschluss in einem fortgeschrittenen Fach wie Elektronik oder Informatik, aber hier rede ich davon, dass Sie lernen, richtig zu schreiben. Nervig! Zumindest hier in den Vereinigten Staaten haben wir ein Problem. Einem Bericht der National Commission on Writing (einer amerikanischen Behörde, die u.a. das Analphabetentum in den USA untersucht) zufolge achten mehr als die Hälfte aller Unternehmen, die an einer einschlägigen

Befragung

teilgenommen

haben,

auf die

35 - Mich richtig gut schreiben

234

Schreibfähigkeiten, wenn sie über Einstellungen und Beförderungen entscheiden. 40

Prozent der befragten Unternehmen

im

Dienstleistungssektor sagten, dass ein Drittel oder weniger der neu eingestellten Mitarbeiter über die gewünschten Schreibfähigkeiten verfügten (http://www.writingcommission.org/report.html). Insgesamt gesehen sind Schreibfähigkeiten sowohl erforderlich als auch knapp im Angebot. Wie Sie wissen, werden die Arbeitsplätze global neu verteilt. Wenn sich dieser Trend fortsetzt, wird eine Zeit kommen - für einige ist diese Zeit heute! - , in der der größte Anteil der Kommunikation am Arbeitsplatz in schriftlicher Form per Instant Messaging oder per EMail erfolgen wird. Sie werden viel schreiben müssen. Wenn viele Aufgaben Ihres Jobs mit Schreiben zu tun haben werden, ist es für Sie sicher besser, es gut zu beherrschen. Mehr als jemals zuvor hängt die Art, wie Sie wahrgenommen werden, von Ihrer Fähigkeit ab, sich schriftlich auszudrücken. Vielleicht sind Sie ja ein großartiger Codierer, aber wenn sie sich selbst nicht in Worten ausdrücken können, werden Sie in einem verteilten Team nicht sehr effizient arbeiten können. Die Fähigkeit zu schreiben, vermittelt sowohl eine oberflächliche Wahrnehmung Ihrer Person als auch eine tiefe Einsicht in Ihre Art, zu denken. Wenn Sie Ihre Gedanken nicht in Ihrer Muttersprache so strukturieren können, dass andere sie klar verstehen können, wie können wir dann erwarten, dass Sie dies in einer Programmiersprache können? Die Fähigkeit, einer Idee Form zu verleihen und einen Leser durch einen Gedankenprozess zu einer logischen Schlussfolgerung zu leiten, unterscheidet sich nicht wesentlich von der Fähigkeit, ein klares Design einer Anwendung zu entwerfen und das System sauber so zu implementieren, dass es von künftigen Wartungskräften verstanden werden kann. Es geht auch nicht darum, beurteilt zu werden. Wenn die Mitglieder Ihres Teams über verschiedene Zeitzonen und weit auseinander liegende Orte verteilt sind, ist Schreiben möglicherweise die einzige

Umsetzung 236

Methode, mit der Sie erklären können, was Sie getan haben, wie Sie ein Design konzipiert haben oder woran Ihre Teammitglieder arbeiten sollen.

Merksatz Sie sind, was Sie erklären können.

Kommunikation, insbesondere in schriftlicher Form, ist der Engpass, den alle Ihre wundervollen Ideen passieren müssen. Sie sind, was Sie erklären können.

Umsetzung 1. Beginnen Sie, ein Entwicklungstagebuch zu führen. Machen Sie jeden Tag einen kleinen Eintrag. Erklären Sie, woran Sie gearbeitet haben, wie Sie Ihre Design-Entscheidungen rechtfertigen und was Sie über schwierige technische oder berufliche Entscheidungen denken. Selbst wenn Sie der Hauptadressat (oder einzige Adressat - das liegt ganz bei Ihnen) sind, achten Sie auf die Qualität Ihrer Schreibe sowie auf Ihre Fähigkeit, sich klar auszudrücken. Lesen Sie gelegentlich ältere Einträge durch und kritisieren Sie sie. Passen Sie Ihre neuen Einträge an die kritischen Einsichten an, die Sie aus diesen älteren Einträgen gewinnen. Dadurch wird sich nicht nur Ihre Schreibe verbessern. Sie können dieses Tagebuch auch als Dokument verwenden, um Ihre Entscheidungen besser zu verstehen und um später nachzulesen, wie und warum Sie frühere Entscheidungen getroffen haben. 2. Lernen Sie zu tippen. Wenn Sie das Zehnfingersystem noch nicht beherrschen, belegen Sie einen Kurs oder laden Sie sich Software herunter, mit der Sie es lernen können. Ihr Schreibstil wird umso natürlicher wirken, je mehr Sie mit der Eingabemethode selbst vertraut sind. Natürlich sparen Sie auch etwas Zeit, wenn Sie lernen, schneller zu tippen.

KAPITEL 196

Präsent sein

ie haben den Vorteil, Ihren Vorgesetzten und Geschäftskun-

S

den von Angesicht zu Angesicht gegenüberzustehen. Verspielen Sie diese Gelegenheit nicht.

Als ich in Bangalore als CTO unseres Software-Entwicklungs-Centers arbeitete, hatte ich die unangenehme Erfahrung, einer Managerin unterstellt zu sein, die ich nicht nur nicht mochte (und die mich nicht mochte), sondern die auch noch in den Vereinigten Staaten stationiert war. Wir führten spät am Abend oder früh am Morgen anstrengende Telefongespräche, die durch Geräusche und unabsichtliche Unterbrechungen zunehmend frustrierender verliefen. Ich schrieb lange ausführliche E-Mails, um möglichst die weite Entfernung und die Zeitzone zu überbrücken, die aber regelmäßig ignoriert wurden. Und wenn ich mich darüber beschwerte, ignoriert zu werden, wurde ich dafür kritisiert, lange E-Mails zu schreiben. Ich schien mich in einer Situation zu befinden, in der ich nicht gewinnen konnte. Mein Unternehmen praktizierte damals eine jährliche Leistungsbeurteilung, in der die Manager die Stärken und (so genannten) Entwicklungsbedürfnisse ihrer Mitarbeiter aufführten. A m Anfang meiner Entwicklungsbedürfnisse stand in diesem Jahr der Punkt Präsenz (engl, presence).

28 3

36 - Präsent sein

Nun ist Präsenz in diesem Kontext ein hoch-artifizieller Begriff aus der Stratosphäre des »Corporate Thinking«. Vor allem ist er schwammig. Er bezeichnet eine unmessbare Führungsqualität, die sich mit der Fähigkeit umschreiben lässt, seine Gegenwart fühlbar zu machen - insbesondere in Von-Angesicht-zu-Angesicht-Situationen. Er umfasst auch die gleichermaßen unmessbare Qualität, wie ein Leiter aufzutreten. Als ich mich hinsetzte, um (über das Telefon) mit meiner geliebten Managerin über meine Leistungsbeurteilung zu sprechen, schaltete ich das Telefon leise, als sie von »Presence« sprach. Ich wollte nicht laut auflachen. Ich fragte mich, ob sie mein halb verzerrtes, halb ironisches Grinsen über das Telefon hören konnte, das ich mir für den Rest unserer Unterhaltung nicht von den Lippen wischen konnte. Sie und ich, wir wussten beide, dass das eigentliche Problem die Präsenz in der gebräuchlicheren Form des Wortes bestand: Ich befand mich einfach nicht mit allen anderen in den Vereinigten Staaten. Die meisten meiner Kollegen, die bereit waren, über ihre Gefühle zu sprechen, mochten diese Managerin nicht. Sie tat wenig, um sich Respekt zu verdienen; deshalb war dies nicht sonderlich überraschend. Es zeigte sich ein Muster: Die einzigen Mitarbeiter, die wirklich negative Beziehungen zu ihr hatten, waren diejenigen, die sich geografisch nicht an demselben Ort befanden wie sie. Wer sich in anderen Ländern wie etwa Indien, Ungarn und Großbritannien (in absteigender Reihenfolge) befand, hatte zu ihr ein angespanntes Verhältnis, da wir nicht nur räumlich getrennt waren, sondern auch noch die Barrieren der Zeitzone, der Infrastruktur, der Kultur und der Sprache zwischen uns standen. Es schien, als würde sogar für die Leute in den Vereinigten Staaten, die alles taten, um nicht mit dieser Person zusammenzuarbeiten, die räumliche Nähe und ein gelegentliches persönliches Gespräch ausreichen, um diese Managerin zufrieden zu machen. Und natürlich wurde dieses »Aus dem Auge, aus dem Sinn«-Phänomen sehr schnell bestätigt, als ich nach Indien ging.

Präsent sein 240

Ich möchte Ihnen damit aber nicht nur eine Geschichte über eine schlechte Managerin erzählen, sondern eine wichtige Erkenntnis vermitteln: Räumliche Nähe ist am Arbeitsplatz ein Vorteil. Denken Sie an das letzte Mal, als ein Verwandter oder ein Freund, der mit dem Computer nicht so vertraut ist, Sie anrief, um Sie wegen eines Computerproblems um Hilfe zu bitten. Sie versuchen, ihn über das Telefon durch das Problem zu leiten; doch wenn er es nicht gleich versteht, wächst Ihr Ärger. Wenn ich ihm doch nur zeigen könnte ... Im Vergleich dazu ist eine persönliche Kommunikation unglaublich effizient. Sie hören die andere Partei deutlicher. Sie können ausdrücklich visuelle Hilfsmittel benutzen, um bestimmte Punkte zu unterstreichen, etwa Handbewegungen oder Zeichnungen auf einer Tafel. Und implizit drücken wir alle sehr viel mehr mit unserer Körpersprache aus, als wir uns bewusst sind. Bei persönlichen Interaktionen ist nicht nur die Produktivität größer und die Kommunikation effizienter, sondern wir knüpfen auch engere persönliche Bande. Es dauert länger, etwas wie eine Freundschaft aufzubauen, wenn man sich persönlich nie trifft. Vor 15 Jahren war das vollkommen unmöglich. Und heute - trotz der Allgegenwärtigkeit des Internets - ist es immer noch weniger üblich als die traditionellen Freundschaften, bei denen man Augen in Auge miteinander redet. Hauptsächlich aus denselben Gründen, aus denen wir per Telefon, E-Mail und Chat weniger effizient arbeiten, stellen wir auch über diese Kanäle weniger effizient Beziehungen her. Nehmen Sie das Unbehagen über die Unnatürlichkeit eines auf E-Mail und Chat basierenden Gesprächs hinzu (woran sich die nächste Generation wahrscheinlich nicht mehr erinnern wird), und Sie werden feststellen, dass sich in der Mehrzahl der Fälle die Beziehungen, die in einer verteilten Arbeitsumgebung aufgebaut werden, strikt darauf konzentrieren, sachorientiert Aufgaben zu erledigen. Eine starke Team-Bindung mit einer effizienten Kommunikation hoher Bandbreite führt dazu, dass schneller bessere Software ausgeliefert wird. In den meisten Umgebungen werden wichtige Projekt-

240

36 - Präsent sein

entscheidungen persönlich in den Kaffeepausen oder in Gesprächen am Rande getroffen. Dies wissen wir alle aus Erfahrung; und der Vorteil, den man als Teilnehmer eines solchen Szenarios hat, ist ziemlich offensichtlich. Was - besonders für eingefleischte Programmierer (Geeks) - nicht so offensichtlich ist, ist die Bedeutung, sichtbar zu sein. Ich gehe niemals in eine Bank. Ich erledige meine Bankgeschäfte entweder online oder am Bankautomaten. Bei meinen Großeltern ist das anders. Sie erledigen praktisch ihre gesamten Bankgeschäfte in der Bank und sprechen mit echten Leuten. Sie mögen es nicht einmal, Geschäfte über das Telefon abzuwickeln. Sie fühlen sich einfach nicht wohl dabei. Sie kennen auch die Leute in dem Lebensmittelgeschäft, in dem sie einkaufen. Sie gehen immer in denselben Laden und unterhalten sich mit den Leuten an der Kasse. Sie würden nicht einmal auf die Idee kommen, zu einem anderen Lebensmittelhändler (oder einer anderen Bank) zu gehen, weil die Auswahl der Bank oder des Ladens mehr als eine pragmatische Abwägung von Kosten und Bequemlichkeit ist. Sie ist etwas Persönliches. Bis wir Roboter oder Computerprogramme für unsere Leistungsbewertung entwickelt haben, werden alle Geschäfte weiterhin persönlich abgewickelt werden. Menschen interagieren gerne persönlich mit anderen Menschen. Jedenfalls einige. Der natürliche Modus einer Computer-Person besteht darin, sich in einem Kubikel oder Büro zu verschanzen, Kopfhörer aufzusetzen und bis zur Essenspause in die »Zone« zu gehen. Douglas Coupland erzählt in seinem Buch Microserfs [C0U96] eine amüsante Geschichte eines Teams, das flache Lebensmittel kaufen musste, die es unter die Bürotür eines Programmierers schieben konnte, der sich auf einer Mission befand. Diese Art der fokussierten Isolation ist in die Kultur und Folklore der Software-Branche eingegangen. Leider ist dies, unter dem Aspekt Ihrer Karriere betrachtet, schlecht fürs Geschäft. Wenn Sie in einem Büro eingesperrt sind, nur per Telefon (falls Sie abnehmen) oder per E-Mail erreichbar sind, viel-

Präsent sein 240

240

leicht die Nacht durcharbeiten und dafür lange schlafen, macht es keinen Unterschied, ob Sie am Arbeitsplatz mit Ihren Vorgesetzten und Kunden in Reichweite oder irgendwo offshore arbeiten. Sie verpassen eine riesige Gelegenheit, sich als festes Inventar Ihres Unternehmens zu etablieren. Vergessen Sie nicht: Sie müssen persönliche Beziehungen aufbauen, und zu diesen Zwecken müssen Sie immer daran denken, dass Menschen die natürliche Tendenz haben, mit anderen Menschen zusammenzuarbeiten - nicht mit Voicemail, E-Mail oder Instant Messaging, sondern mit echten Leuten.

Merksatz Lernen Sie Ihre Kollegen kennen.

In der heutigen verteilten Umgebung befinden Sie sich zwar oft im selben Land wie die Leute, mit denen Sie zusammenarbeiten, aber nicht in derselben Stadt oder im selben Bundesland. Regelmäßige Reisen, um persönliche Meetings abzuhalten, sind in solchen Situationen hervorragend geeignet, falls dies für Ihr Unternehmen praktikabel ist. Doch Sie können jederzeit zum Telefon greifen und Ihre Vorgesetzten und Kollegen anrufen. Verwenden Sie, falls möglich, nicht den Lautsprecher, und verlassen Sie sich nicht auf geplante Meetings. Sie müssen versuchen, die Art zwangloser Unterhaltung zu simulieren, die bei Kaffeepausen zustande kommen, wenn man zusammen im selben Büro arbeitet. Deshalb sollten Sie bewusst Zeit für derartige (anscheinend) spontane Gespräche reservieren. Bei gegebenem Anlass sollten Sie die Gelegenheit nutzen, das Gespräch auf persönliche Themen zu bringen. Lassen Sie dann das normale »Wie geht es Ihnen heute?« in ein »Was machen Sie normalerweise am Wochenende?« übergehen. Versuchen Sie, tatsächlich etwas über die Menschen zu erfahren, mit denen Sie arbeiten. Dadurch binden Sie sich nicht nur fest in das soziale Gefüge Ihres

36 - Präsent sein

242

Unternehmens ein, sondern machen auch eine bereichernde Lebenserfahrung.

Umsetzung 1. Zwingen Sie sich (innerhalb vernünftiger Grenzen) an einem Tag in der kommenden Woche dazu, keine E-Mail zu versenden. Jedes Mal, wenn Sie normalerweise eine E-Mail senden würden, rufen Sie entweder den Empfänger an oder (besser) gehen Sie in sein Büro und sprechen Sie persönlich mit ihm. 2. Legen Sie eine Liste Ihrer Kollegen, Vorgesetzten und Kunden an, mit denen Sie sich nicht häufig genug unterhalten. Tragen Sie wiederkehrende Termine in Ihren Kalender ein, um sie anzurufen oder persönlich aufzusuchen. Führen Sie kurze, aber bedeutungsvolle Gespräche. Sprechen Sie dabei ein Thema aus der Arbeit an oder stellen Sie einfach eine zwischenmenschliche Beziehung her.

KAPITEL 196

Wie ein Anzugträger reden

eine jungen Neffen arbeiten regelmäßig mit Computern.

M

Sie können mit Computern relativ gut umgehen. Sie kom-

munizieren mit Freunden in der ganzen Welt per Compu-

ter. Sie kommen wie selbstverständlich mit Instant Messaging, EMail, Webbrowsern zurecht. Sie veröffentlichen ihren persönlichen Kram und andere Dinge, die man als Schüler bei einer Projektarbeit erledigen muss. Doch wenn ich ihnen gegenüber damit prahlen würde, dass mein neuer Computer eine Serial-ATA-Festplatte mit 10.000 RPM habe, würden sie sich bestenfalls bemühen, aus Freundlichkeit ein wenig Enthusiasmus zu zeigen. Sie wären wahrscheinlich genauso wenig beeindruckt, wenn ich ihnen sagte, ich hätte mehrere Gigabyte RAM und eine GPU, die schneller liefe, als die CPUs in den Systemen, mit denen ich nur fünf Jahre früher gearbeitet habe. Wenn ich ihnen jedoch sagte, ich könnte den neuesten First-PersonShooter in voller Auflösung ohne das geringste Stocken der grafischen Darstellung ausführen, würden sie wahrscheinlich aufmerken. Gigahertz und Umdrehungen pro Minute sind für einen durchschnittlichen 14-jährigen Jungen nicht interessant. Computerspiele finden dagegen seine Aufmerksamkeit.

244

37 - Wie ein Anzugträger reden

Geschäftsleute interessieren sich ebenfalls nicht für Gigahertz und RPMs. Sie schätzen es, wenn ihre Anwendungen schneller laufen, weil sie dann nicht warten müssen, wenn sie mit einem Kunden telefonieren oder während sie versuchen, den Quartalsabschluss der Buchhaltung zu machen. Aber wie viele Anfragen pro Sekunde Ihr neuer benutzerdefinierter Anwendungsserverprozess verarbeitet, ist für sie uninteressant.

Merksatz Vermarkten Sie Ihre Leistungen in der Sprache Ihres Geschäftsfeldes.

Unternehmen und Menschen, die Unternehmen leiten, sind an geschäftlichen Ergebnissen interessiert. Deshalb ist es wenig Erfolg versprechend, wenn Sie Ihre Errungenschaften nicht in der Fachsprache vermarkten, die diese Menschen sprechen. Sie würden nicht versuchen, einer amerikanischen Zielgruppe ein Produkt auf Deutsch zu verkaufen. Ein Unternehmen, das Softdrinks herstellt, würde nicht versuchen, eine Limonade mit dem Argument zu verkaufen, sie enthielte eine bestimmte Menge des Farbstoffs X Y Z . Der gesunde Menschenverstand sagt Ihnen, dass Sie Ihre Zielgruppe in einer Sprache ansprechen müssen, die für diese sowohl verständlich als auch motivierend ist, wenn Sie ein Produkt verkaufen wollen. Als Software-Entwickler bedeutet das, dass Sie Ihre Leistungen in der Sprache und im Kontext Ihres Geschäftsfeldes präsentieren müssen. Sicher, Sie haben die Aufgabe erledigt, aber was genau haben Sie gemacht? Warum war es wichtig? Warum war diese so genannte Errungenschaft nicht nur eine Verschwendung der Zeit des Unternehmens? Ich vermute einmal, dass Sie, wenn Sie über die erledigten Aufgaben des letzten Monats nachdenken, Schwierigkeiten haben würden

Umsetzung 246

zu beschreiben, warum diese Aufgaben für das Unternehmen nützlich waren. Sicher, wahrscheinlich wurden sie Ihnen aufgetragen, aber welchen Vorteil haben sie dem Unternehmen gebracht? Bei General Electric geht eine urbane Legende rum, dass der frühere CEO Jack Welch gerne in einem der Fahrstühle eines der hohen GE-Gebäude fuhr, wo er natürlich zufällig auf irgendeinen GE-Mitarbeiter traf. Er drehte sich dann um und fragte den bereits eingeschüchterten Untergebenen: »Woran arbeiten Sie gerade?«, und dann (hier konnte es wehtun): »Welchen Vorteil bringt das?« Die Moral von der Geschichte ist: Sie sollten für alle Fälle immer Ihre Fahrstuhlrede parat haben. Was würden Sie sagen, wenn Ihr Vorstandsvorsitzender Ihnen aus heiterem Himmel dieselbe Frage stellen würde? Würden Sie, selbst wenn Sie einige Minuten der Vorbereitung hätten, den geschäftlichen Vorteil der Aufgaben darlegen können, die Sie gerade erledigen oder vor Kurzem erledigt haben? Könnten Sie sie in Worten ausdrücken, die auch ein vollkommen untechnischer leitender Angestellter nicht nur verstehen, sondern auch schätzen würde?

Umsetzung 1. Legen Sie eine Liste Ihrer Errungenschaften aus jüngerer Zeit an. Schreiben Sie den geschäftlichen Vorteil jeder Leistung daneben. Wenn die Liste Punkte enthält, für die Sie keinen geschäftlichen Vorteil angeben können, fragen Sie einen Manager oder vertrauenswürdigen Bekannten, wie er den Vorteil formulieren würde. 2. Entwerfen Sie Ihre Fahrstuhlrede und lernen Sie sie auswendig.

KAPITEL 196

Ändern Sie die Welt

as Schlimmste, was man bei der Arbeit über Sie fragen

D

könnte, ist: »Was macht er (oder sie)?« Denn wer diese Frage stellen muss, weiß nicht, was Sie getan haben.

Es ist traurig, aber ich weiß nicht, was die meisten Menschen getan

haben, mit denen ich in den IT-Abteilungen großer Unternehmen zusammengearbeitet habe. Menschen denken einfach nicht auf diese Weise. Sie gehen zur Arbeit, erledigen die ihnen aufgetragenen Aufgaben und gehen wieder nach Hause. Abgesehen von der Spur aus Code, Dokumenten und E-Mails, die sie hinterlassen, hat ihre Arbeit keine dauerhaften Auswirkungen. Was passiert, wenn Sie ohne eine Mission zur Arbeit gehen? Sie sitzen einfach herum und warten auf das, was Sie tun sollen. Und wenn Sie tun, was andere Leute Ihnen auftragen, sind die einzigen Leute, die danach wissen, was Sie getan haben, diejenigen, die Ihnen die Aufgabe aufgetragen haben. Das ist in Ordnung, wenn Sie als Verkäufer im Handel oder vielleicht sogar als Offshore-Programmierer arbeiten wollen. Merksatz Geben Sie sich eine Mission. Sorgen Sie dafür, dass die Menschen Sie kennen.

248

38 - Ändern Sie die Welt

Aber wenn Sie als Software-Entwickler in einem Land mit hohen Personalkosten arbeiten wollen, müssen Sie mit einer Mission zur Arbeit kommen. Sie müssen etwas ändern, aber nicht nur sich selbst oder Ihre Arbeit (das wird als selbstverständlich vorausgesetzt). Sie müssen Ihr Team, Ihre Organisation oder Ihr Unternehmen sichtbar verändern. Die Änderung kann klein sein. Vielleicht tragen Sie die Fackel des Unit-Testings weiter und pflanzen bewährte Testpraktiken in die Herzen der ungebildeten Massen des Programmierer-Pools Ihres Unternehmens. Die Änderung kann auch größer sein, wie etwa die Einführung einer radikal neuen Technologie, um Systeme besser, billiger und schneller zu entwickeln. Sie tun diese Dinge, weil Sie sich innerlich dazu getrieben fühlen. Sie können nicht danebenstehen und zusehen, wie die Menschen in Ihrem Unternehmen Dinge tun, die man besser tun könnte; und Sie müssen dies ändern. Natürlich werden Sie, wenn Sie die Welt verändern wollen, zwangsläufig einige Leute verärgern. Das ist in Ordnung, solange Ihre Absichten lauter sind. Stoßen Sie nicht gleich jeden vor den Kopf, aber bemühen Sie sich auch nicht, niemandem auf die Füße zu treten. Wenn Sie einigen Leuten tatsächlich auf die Nerven gehen, können Sie sich wenigstens mit der Tatsache trösten, dass diese nie wieder fragen werden: »Was macht er (oder sie)?« Wenn Sie nicht wissen, auf welchen Kreuzzug Sie ziehen wollen, haben Sie wahrscheinlich keinen. Wenn Sie nicht bereits aktiv versuchen, Ihr Zeichen zu setzen, werden Sie wahrscheinlich keines setzen.

Umsetzung 1. Legen Sie einen Katalog der Kreuzzüge an, deren Zeuge Sie persönlich bei der Arbeit geworden sind. Denken Sie an die Menschen, mit denen Sie gearbeitet haben, die sich verhielten, als

Umsetzung 250

wären sie auf einer Mission. Denken Sie an die engagiertesten und effizientesten Leute, die Sie während Ihrer beruflichen Laufbahn kennen gelernt haben. Was waren ihre Missionen? Fällt Ihnen eine dieser Missionen ein, die fehl am Platze war? Wo ist die Grenze zwischen Getriebensein und Fanatismus? Haben Sie Menschen kennen gelernt, die diese Grenze überschritten haben?

KAPITEL 39

Verschaffen Sie sich Gehör

ie Ideen, die wir bis jetzt behandelt haben, sind ziemlich

D

konservativ und konzentrieren sich darauf, Anerkennung für die Arbeit zu finden, die Sie an Ihrem Arbeitsplatz leis-

ten. Wenn Sie in Ihrem jetzigen Unternehmen anerkannt und befördert werden oder sogar angestellt bleiben wollen, sind die Themen, die wir angesprochen haben, für Sie entscheidend wichtig. Doch wie langweilig! Die Welt ändert sich. Wenn Sie ihr Ihren Stempel aufdrücken wollen, müssen Sie größer denken als IT-Arbeiter oder Leute von gestern. Auch wenn Ihr kurzfristiges Karriereziel darin besteht, von einem Stufe-23-Programmierer zu einem Stufe-24-Programmanalytiker befördert zu werden, müssen Sie als Programmierer heute über Ihre nächste Beförderung und sogar über Ihre jetzige Arbeitsstelle hinausdenken. Weiten Sie Ihren Blick. Sehen Sie sich selbst nicht als Programmierer in einem speziellen Unternehmen - schließlich ist es unwahrscheinlich, dass Sie für immer an demselben Ort arbeiten werden - , sondern als aktives Mitglied einer Branche. Sie sind ein Handwerker oder ein Künstler. Sie haben etwas beizutragen, was über die Kostenabrechnungsanwendung hinausgeht, die Sie für eine Perso-

252

3g - Verschaffen Sie sich Gehör

nalabteilung entwickeln, oder die Bugs, die Sie in dem Kundendienstprogramm Ihres Unternehmens korrigieren müssen. Unternehmen wollen Experten einstellen. Während Sie mit einem Lebenslauf mit einer soliden Liste von geleisteten Projekten Ihre Erfahrung nachweisen können, haben Sie in einem Einstellungsgespräch die besten Karten, wenn der Interviewer bereits von Ihnen gehört hat. Es ist besonders vorteilhaft, wenn er bereits Artikel oder Bücher von Ihnen gelesen oder Sie auf einer Konferenz als Vortragsredner erlebt hat. Würden Sie nicht die Person einstellen wollen, die das Grundlagenwerk über die Technologie oder Methodologie geschrieben hat, die Sie einzuführen versuchen? In meinem früheren Leben als professioneller Saxophonist spielte ich oft in den Clubs rund um die Beale Street in Memphis. Als ich in die Computer-Branche wechselte, bemerkte ich viele Ähnlichkeiten zwischen den Methoden, sich in der Musik- und der ComputerBranche einen Namen zu machen. Wenn man als Musiker Arbeit finden wollte, galten folgende Erkenntnisse: •

(Dies ist die wichtigste.) Der beste Saxophonist bekommt nicht immer den Gig.

•

Mit wem man gespielt hat, ist mindestens so wichtig wie die Qualität seines Spiels. Als Musiker ist man so cool wie die Leute, mit denen man umgeht.

•

Manchmal werden die besseren Musiker gar nicht in Betracht gezogen, weil jeder annimmt, sie wären beschäftigt, oder zu sehr eingeschüchtert ist, um zu fragen.

•

Musiker sind vernetzt. Wenn Ihr soziales/musikalisches Netzwerk endet, bevor es jemanden erreicht, ist es sehr unwahrscheinlich, dass Sie jemals aufgefordert werden, mit der bestimmten Person zu spielen, solange nicht eine vermittelnde Verbindung hergestellt wird.

In der Computer-Branche läuft es genauso. Es gibt kein objektives System, um Software-Entwickler zu beurteilen und einzustellen. Gut zu sein ist wichtig, aber es reicht nicht, um seine Ziele zu errei-

Verschaffen Sie sich Gehör

2 53

chen. Unsere Branche ist ähnlich groß wie die Musikbranche. Sie ist ein großes komplexes Netz von Menschen, die vielfältig miteinander verbunden sind. An je mehr Stellen Sie in das Netzwerk eingebunden sind, desto größer sind Ihre Chancen, eine Verbindung zu dem perfekten Job herzustellen oder einen Karrieresprung zu machen. Wenn Sie sich auf das Unternehmen beschränken, für das Sie arbeiten, schränken Sie zugleich die Anzahl Ihrer möglichen Verbindungen ernsthaft ein. Welche besseren Möglichkeiten gibt es, als etwas zu veröffentlichen und öffentliche Vorträge zu halten, um seinen Namen bekannt zu machen und sich Gehör zu verschaffen? Wie kann also aus dem unbekannten Programmierer Hans Schmitz ein anerkannter Autor und dann ein begehrter Vortragsredner werden? Beginnen Sie im Web. Lesen Sie zunächst Weblogs. Lernen Sie, wie die Weblog-Syndizierung funktioniert, und melden Sie sich bei einem Aggregator an. Wenn Sie nicht wissen, was Sie lesen sollten, denken Sie an Ihre technischen Lieblingsautoren und suchen Sie sie im Web. Wahrscheinlich haben diese Autoren ein Weblog. Abonnieren Sie den betreffenden Feed und die Feeds der Leute, mit denen er verlinkt ist. Im Laufe der Zeit wird die Liste Ihrer Feeds immer länger werden, wenn Sie Weblogs lesen und den Links zu den Weblogs folgen, die andere Leute geschrieben haben. Veröffentlichen Sie dann Ihr eigenes Weblog. Es gibt viele kostenlose Services, die Weblogs hosten. Es ist unglaublich einfach. Beginnen Sie, über die Geschichten in Ihrem Aggregator zu schreiben (und Links zu ihnen herzustellen), die Sie interessant finden. Während Sie schreiben und sich verlinlcen, werden Sie feststellen, dass das Weblog-Universum selbst ein soziales Netzwerk ist - ein Mikrokosmos eines Karrierenetzwerks, das Sie im Begriff sind aufzubauen. Ihre Gedanken werden im Laufe der Zeit in den Feed-Aggregatoren anderer Menschen auftauchen, die sich für die gleichen Themen interessieren, die über Sie schreiben und Ihre Ideen weiterverbreiten.

254 Das Weblog ist ein Übungsfeld. Schreiben Sie im Web so, als würden Sie eine Meinungsspalte für Ihr Lieblingsmagazin schreiben. Üben Sie sich in der Kunst des Schreibens. Ihre Fähigkeiten werden zunehmen und Ihr Selbstvertrauen wird wachsen. Ihre Veröffentlichungen im Web dienen auch als Arbeitsbelege, die Sie für den nächsten Schritt verwenden können. Nachdem Sie jetzt in Ihrem eigenen Forum schreiben, können Sie Ihre Texte ebenso gut auf Community-Websites, in Magazinen oder sogar in Büchern veröffentlichen. Da im Web ein Portfolio Ihrer Schreibfähigkeiten zur Verfügung steht, verfügen Sie über ein umfangreiches Beispielmaterial, auf das Sie für Artikel oder ein Buchangebot zurückgreifen können. Wenn Sie dafür sorgen, dass Sie gedruckt werden, wächst Ihr Netzwerk. Je mehr Sie schreiben, desto mehr Gelegenheiten zu schreiben erhalten Sie. Und all das führt zu der Gelegenheit, Vorträge auf Konferenzen zu halten. So wie Sie im Web leicht einen Einstieg in Ihre Karriere als Autor gefunden haben, können Sie Ihre Karriere als Vortragsredner in den Meetings Ihrer ortsansässigen Entwicklergruppen beginnen. Wenn Sie ein .NET-Typ sind, bereiten Sie eine Präsentation für die ortsansässige Gruppe der Microsoft-Entwickler vor. Als Linux-Programmierer sprechen Sie vor Ihrer Linux-Benutzergruppe. Auch das Reden wird durch Üben besser. Bereiten Sie diese Vorträge gründlich vor. Nehmen Sie sie nicht auf die leichte Schulter. Obwohl Sie nur zu einer kleinen Gruppe in Ihrer Heimatstadt sprechen, ist es doch der Ort, an dem Sie leben und arbeiten. Eine wirklich gute Leistung bleibt (letztlich) nicht unbelohnt. Wenn Sie diesen Reden vor lokalen Benutzergruppen das angemessene Maß an Aufmerksamkeit widmen, werden Sie feststellen, dass sie sich letztlich nicht von denen auf den großen Branchen-Konferenzen unterscheiden. Dies sind offensichtlich die nächsten logischen Schritte. In Anbetracht der vielen Möglichkeiten, Ihre Namen bekannt zu machen und Ihrer Stimme Gehör zu verschaffen, hier der wichtigste Tipp: Beginnen Sie, bevor Sie glauben, dazu bereit zu sein.

Umsetzung 250

250

Die meisten Menschen verkaufen sich unter Wert. Sie haben etwas zu lehren. Sie werden sich niemals hundertprozentig bereit fühlen; deswegen können Sie genauso gut auch jetzt anfangen.

Umsetzung 1. Wenn Sie nicht bereits ein Weblog haben, legen Sie sofort eins an. Besuchen Sie einen der vielen kostenlosen Weblog-Hoster und richten Sie Ihr Weblog ein. Erstellen Sie dann auf Ihrem Computer eine neue Textdatei. Legen Sie in dieser Datei eine Liste der möglichen Themen für Ihr Weblog an. Dies sind die künftigen Artikel, die Sie schreiben werden. Beschränken Sie sich nicht auf epische Ideen. Sammeln Sie möglichst Ideen, über die Sie in zehn oder zwanzig Minuten schreiben können. Hören Sie auf, wenn die Liste zehn Einträge lang ist. (Wenn Sie inspiriert sind, sollten Sie natürlich weitermachen.) Speichern Sie die Datei, aber lassen Sie sie geöffnet. Wenn Sie den Computer neu starten, öffnen Sie die Datei erneut. Sie haben drei Wochen Zeit. Wählen Sie jeden Tag einen Punkt aus der Liste aus und schreiben Sie einen Artikel. Denken Sie nicht zu gründlich darüber nach. Schreiben Sie ihn einfach und veröffentlichen Sie ihn. Fügen Sie in die Artikel Links zu anderen Weblogs mit ähnlichen Artikeln ein. Wenn Sie Ihre Liste lesen, um das Thema des Tages auszuwählen, können Sie weitere Ideen in die Liste eintragen. Wählen Sie nach den drei Wochen Ihre beiden Lieblingsartikel aus und reichen Sie sie bei Benutzer-moderierten News-Sites wie Digg oder Reddit ein. Wenn immer noch Ideen auf Ihrer Liste stehen, schreiben Sie weiter.

KAPITEL

39

Sich zum Markenzeichen machen

ine Marke aufzubauen, besteht aus zwei Teilaufgaben: Ers-

E

tens müssen Sie etwas Bemerkenswertes leisten. Zweitens müssen Sie dafür sorgen, dass diese Leistung positiv besetzt

ist. Aufmerksamkeit und Respekt. Wenn wir heute ein Hakenkreuz sehen, denken wir an Hitler und Nazi-Deutschland. Aus der Perspektive, ein Markenzeichen zu schaffen, ist dies sehr gut für die Nazis. Sie haben die erste Teilaufgabe des Markenaufbaus gelöst: Aufmerksamkeit. Aber normale, geistig gesunde Menschen haben extrem negative Assoziationen, wenn sie Dinge sehen, die mit dem Holocaust zu tun haben. Deshalb sind die Nazis letztlich bei der zweiten Teilaufgabe, Respekt zu erwerben, kläglich gescheitert. Tatsächlich hat Hitler das Hakenkreuz von den Hindus gestohlen und damit ein Verbrechen begangen, dass alle Unternehmen, denen ihre Marken am Herzen liegen, tunlichst zu vermeiden suchen. Für die Hindus, die das Vorrecht auf die Swastika (oder swasti) beanspruchen, ist das Hakenkreuz ein glückverheißendes Symbol des Wohlergehens. Aber heute ist dieses spirituelle Symbol in der ganzen westlichen Welt besudelt. Hohe Aufmerksamkeit und geringer Respekt. Das

umgekehrte

Beispiel

liefert

Charlie

Wood

(www.charlie-

wood.us). Charlie ist ein unglaublicher Sänger, Liedermacher und

28

40 - Sich zum Markenzeichen machen

5

Hammond-B3-Orgel-Spieler in Memphis, Tennessee. Er spielt an fünf Abenden der Woche in einem Club auf der Beale Street. Jeder kennt ihn oder hat von ihm gehört und weiß, wie erstaunlich er ist. Alle schauen zu ihm auf. Er gilt als unglaublich talentierter Rhythmand-Blues-Musiker. Aber so gut wie niemand weiß, wer er überhaupt ist. Keine Aufmerksamkeit und viel Respekt. Was Sie wollen, ist sowohl Aufmerksamkeit als auch Respekt. Ihr Name ist Ihr Markenzeichen.

Merksatz Ihr Name ist Ihr Markenzeichen.

Dieser ganze Teil des Buches beschäftigt sich damit, wie Sie sowohl Anerkennung als auch Respekt erwerben können. Genau in diesem Absatz sollten Sie lernen, dass die Kombination dieser beiden Eigenschaften ein Aktivposten ist, den zu erwerben und zu schützen sich lohnt. Im Gegensatz zu einer großen, verängstigten Marketingabteilung eines Unternehmens, das Studenten verklagt, weil sie auf ihren Websites ohne Erlaubnis ein Logo oder einen Spruch des Unternehmens verwendet haben, müssen Sie nicht zu viel Zeit darauf verwenden, ihr Markenzeichen vor anderen Leuten zu schützen. Die größte Gefahr für Ihr Markenzeichen geht von Ihnen selbst aus. Verwässern Sie nicht, wofür Sie stehen. Achten Sie sorgfältig darauf, wo Sie Ihren Namen auftauchen lassen. Arbeiten Sie nicht an lausigen Projekten. Senden Sie keine lausigen E-Mails an große Empfängergruppen. Veröffentlichen Sie keine lausigen Weblog-Einträge, die das ganze Internet lesen kann. Verhalten Sie sich nicht wie ein Idiot. Niemand mag Idioten, selbst wenn sie diese Bezeichnung verdienen.

Umsetzung 250

Merksatz Google vergisst nie.

Was am wichtigsten ist: Vergessen Sie nicht, dass die Dinge, die Sie freiwillig tun und mit denen Sie sich befassen, einen nachhaltigen Einfluss darauf haben, was Ihr Name für die Menschen bedeutet. Und da heute so viele Interaktionen über das Internet auf öffentlichen Foren, Websites und Mailing-Listen erfolgen, sind zahlreiche Ihrer Aktionen öffentlich zugänglich und gespeichert, indiziert und suchbar - für immer. Vielleicht vergessen Sie, aber Google vergisst nie. Schützen Sie Ihre Marke mit aller Kraft. Schützen Sie sie vor sich selbst. Sie ist das Einzige, was Sie haben.

Umsetzung i. Googeln Sie nach sich selbst. - Suchen Sie bei Google nach Ihrem vollen Namen in Anführungszeichen. Schauen Sie sich die ersten vier Seiten der Ergebnisse an (falls die Liste tatsächlich so lang sein sollte). Was könnte jemand über Sie erschließen, wenn er nur den Links auf den ersten vier Seiten der Google-Ergebnisse folgen würde? Sind Sie überhaupt auf den ersten vier Seiten der Suchergebnisse nach Ihrem Namen präsent? Schätzen Sie das Bild, das von Ihnen auf diesen vier ersten Seiten gezeichnet wird? Führen Sie dieselbe Suche erneut aus, doch achten Sie diesmal besonders auf Gespräche in Foren und Mailing-Listen. Sind Sie ein Idiot?

KAPITEL 39

Veröffentlichen Sie Ihren Code

tellen Sie sich vor, wie viel einfacher es wäre, einen Job zu

S

finden, wenn es Unternehmen gäbe, die sich bereits auf Soft-

ware verlassen, die Sie geschrieben haben. Sie könnten

sagen: »Oh, Sie benutzen Nifty++? Ich kann Ihnen dabei helfen -

ich habe es geschrieben.« Das würde den Ausschlag geben. Interviewer und Personalchefs würden sich an Sie erinnern. Das ist es, was Sie wollen. Noch vor einem Jahrzehnt hätte diese Idee, so wundervoll sie sich anhört, kaum Resonanz auf den Markt gefunden. Sie hätten zunächst für ein kommerzielles Software-Unternehmen arbeiten müssen, und Ihre Referenzen wären an die Produkte gebunden gewesen, an deren Entwicklung Sie bei diesem Unternehmen beteiligt waren. Doch die Dinge haben sich geändert. Sie müssen nicht mehr für die großen Jungs arbeiten, um bekannte Software mit einem Markennamen zu entwickeln. Heute gibt es einen weiteren Vertriebskanal: Open Source. OpenSource-Software ist im Mainstream angekommen. Wenn IT-Abteilungen neue Projekte beginnen, diskutieren sie heute nicht mehr darüber, ob sie die Software selbst erstellen oder kaufen sollen, sondern ob sie sie selbst erstellen oder kaufen oder herunterladen sollen. Auch wenn es sich nicht um komplette Anwendungen handelt, ent-

262

4i - Veröffentlichen Sie Ihren Code

wickeln sich Frameworks, von kleinen Bibliotheken bis hin zu ausgewachsenen Anwendungs-Containern,

die unter

Open-Source-

Lizenzen veröffentlicht werden, immer mehr zu De-facto-Standards. Und die Leute, die diese Software entwickeln, sind meistenteils Leute wie Sie. Sie sitzen an ihren Abenden und Wochenenden zu Hause und arbeiten an der Software, weil sie ihnen am Herzen liegt. Sicher, es gibt auch einige von Unternehmen finanzierte Anstrengungen, um Open-Source-Produkte zu erstellen oder zu unterstützen. Doch die Mehrzahl der Open-Source-Entwicklungen werden von unabhängigen Entwicklern als Hobby geleistet.

Merksatz Jeder kann Rails verwenden. Wenige können sich Rails Contributor nennen.

Obwohl viele dieser Entwickler einfach Spaß an der Sache haben und ihre Ideen ausdrücken wollen, gibt es auch hier einige echte Anreize. Sie arbeiten sich in der sozialen Kette einer Gemeinschaft nach oben. Sie schaffen sich einen Namen. Sie erwerben in der Branche eine Reputation. Auch wenn Sie es nicht absichtlich tun, vermarkten Sie sich dabei selbst. Abgesehen davon, sich selbst einen Namen zu machen, zeigen Ihre Beiträge zu Open-Source-Software, dass Sie Ihre Arbeit lieben. Selbst wenn ein Unternehmen von Ihrer Software noch nicht gehört hat oder sie nicht einsetzt, macht die Tatsache, dass Sie sie erstellt und veröffentlicht haben, bereits einen wesentlichen Unterschied. Betrachten Sie es folgendermaßen: Wenn Sie einen Software-Entwickler suchen, würden Sie lieber jemand einstellen, der seinen normalen Achtstundentag absolviert und dann nach Hause geht und fernsieht? Oder würden Sie jemand vorziehen, der die Entwicklung von Software so liebt, dass er auch in seiner Freizeit und an Wochenenden am liebsten Programme schreibt?

2634i-Veröffentlichen Sie Ihren Code

Open-Source-Beiträge demonstrieren Fähigkeiten. Wenn Sie echten Code schreiben und zu einem echten Projekt beitragen, hat dies in Ihrem Lebenslauf viel mehr Gewicht als die Aussage, Sie würden eine Technologie kennen. Jeder kann Rails oder Nant in seinen Lebenslauf schreiben. Sehr wenige können Rails Contributor oder Nant Committer schreiben. Ein Open-Source-Projekt zu leiten, kann sehr viel mehr als technische Fähigkeiten demonstrieren. Man braucht Führungsqualitäten und muss diverse andere Funktionen wie etwa Release Management, Dokumentation oder Produkt- und

Community-Support

beherrschen, u m eine Gemeinschaft u m das Projekt herum aufzubauen. Und wenn Sie diese Dinge - in Ihrer Freizeit als Hobby erfolgreich bewältigen, heben Sie sich erstaunlich stark von den meisten anderen Leuten ab, die um dieselben Jobs konkurrieren. Die meisten Unternehmen können ihre Entwickler nicht dafür bezahlen, all diese Dinge zu erledigen, geschweige denn gut zu erledigen. Die meisten können nicht einmal ihre Entwickler dafür bezahlen, einige dieser Aufgaben gut zu erledigen. Z u zeigen, dass Sie diese Aufgaben nicht nur beherrschen, sondern dass sie Ihnen so sehr am Herzen liegen, dass Sie sie kostenlos erledigen, beweist ein unglaubliches Maß an Initiative. Wenn Sie etwas wirklich Nützliches erstellen, könnten Sie sogar berühmt werden. Sie könnten in einem kleinen technischen Gebiet berühmt werden - beispielsweise unter Rails-Leuten. Oder wenn Sie Glück haben, können Sie selbst außerhalb der Geek Community wirldich berühmt werden, wie etwa Linus Torvalds oder ... nun ja, eben wie Linus. Selbst wenn Sie nicht ganz berühmt sind, werden Sie durch die Veröffentlichung Ihres Codes definitiv berühmter. Wenn Ruhm bedeutet, dass viele Leute wissen, wer Sie sind, dann sind Sie automatisch umso berühmter, je mehr Leute wissen, wer Sie sind. Und die Open-Source-Community ist ein weltweites Netzwerk von Leuten, die auf ihrer Suche nach Code im Web auf Ihre Software stoßen, sie installieren und benutzen können. Dabei erfah-

264

4i - Veröffentlichen Sie Ihren Code

ren diese Leute auch, wer Sie sind; und je mehr sich Ihre Software verbreitet, desto bekannter wird Ihr Name und desto größer wird Ihre Reputation. Das ist es, worum es beim Marketing geht. Das ist es, was Sie wollen.

Umsetzung 1. Stuart Halloway (thinkrelevance.com) bietet auf Konferenzen einen Workshop an, den er als »Refactotum« bezeichnet. Falls Sie Gelegenheit haben, empfehle ich Ihnen nachdrücklich die Teilnahme. Die Stoßrichtung ist etwa wie folgt: Wählen Sie eine Komponente Open-Source-Software mit Unit-Tests aus. Lassen Sie die Unit-Tests durch einen Code Coverage Analyzer laufen. Ermitteln Sie den am wenigsten getesteten Teil des Systems und schreiben Sie Tests, um die Testabdeckung dieses Codes zu verbessern. Ungetesteter Code ist oft untestbarer Code. Refaktorisieren Sie, um den Code testbarer zu machen. Reichen Sie Ihre Änderungen als Patch ein. Das Schöne an diesem Prozess ist: Er ist messbar und kann schnell erledigt werden. Es gibt keine Entschuldigung, es nicht zu probieren.

KAPITEL 39

Bemerkenswert sein

m traditionellen Marketing-Curriculum werden die vier Ps des Marketings betont: Produkt, Preis, Promotion und Platzierung. Dahinter steht die Idee, dass ein Marketing-Plan komplett ist, wenn er alle vier Kategorien abdeckt. Dabei haben alle vier Kategorien gleiches Gewicht. Doch worin besteht das Ziel des Marketings? Sein Zweck besteht darin, eine Verbindung zwischen dem Produzenten und Konsumenten eines Produktes oder Dienstes herzustellen. Diese Verbindung beginnt damit, dass sich die Konsumenten der Existenz eines Produktes bewusst werden. Der traditionelle Mechanismus, diese so genannte Awareness zu schaffen, bedient sich der Promotion (Verkaufsförderung), einschließlich Anzeigen, Werbung und Fortbildungsseminare. Vor Kurzem hat die Marketing-Welt ihre Aufmerksamkeit auf das so genannte virale Marketing gelenkt, das mit Mundpropaganda arbeitet. Virales Marketing findet dann statt, wenn eine Idee oder ein Konzept bemerkenswert genug ist, dass die Konsumenten es von sich aus von einer Person zur nächsten weitergeben. Es verbreitet sich wie ein Virus, wobei jeder infizierte Konsument potenziell viele andere ebenfalls infiziert.

266

42 - Bemerkenswert sein

Virales Marketing wird als Instrument nicht nur deswegen bevorzugt, weil es einfach teuer ist, gedruckte Werbung zu versenden oder Werbespots im Fernsehen zu kaufen, sondern weil Konsumenten ihren Freunden mehr trauen als Werbespots und Werbebriefen. Es ist wahrscheinlicher, dass sie etwas kaufen, von dem sie durch einen Arbeitskollegen erfahren, als durch ein Pamphlet, das aus ihrer Wochenend-Zeitung herausfällt. In seinem Buch Purple Cow [Godc>3] drückt Marketing-Meister Seth Godin das Ganze durch eine Tautologie aus: Die beste Methode, Konsumenten dazu zu veranlassen, Bemerkungen über ihr Produkt zu machen, besteht darin, ihr

Produkt

bemerkenswerter

zu

machen. Godin geht so weit zu behaupten, die traditionellen vier Ps hätten ausgedient und die Konsumenten seien immun gegen die alten Streuen-und-beten-Strategien des Massen-Marketings geworden. Die einzige Methode, aus der Masse herauszuragen, besteht seiner Meinung nach darin, wirklich herausragend zu sein. An dieser Stelle fangen zynische Leser an zu applaudieren. Das ganze Marketing-Gewäsch sei nichts im Vergleich zur Durchsetzungskraft eines bemerkenswerten Satzes von Fähigkeiten. Doch bevor Sie jetzt sagen: »Ich hab's Ihnen gleich gesagt«, sollten wir uns wahrscheinlich über die Definition von bemerkenswert unterhalten. Bemerkenswert bedeutet definitiv nicht dasselbe wie gut. Normalerweise sind bemerkenswerte Produkte gut. Aber Produkte, die gut sind, sind selten bemerkenswert. Bemerkenswert zu sein, bedeutet, dass etwas Aufmerksamkeit verdient. Sie werden kein bemerkenswerter Software-Entwickler, indem Sie einfach besser sind als alle anderen Software-Entwickler aus Ihrem Bekanntenkreis. U m einige Ticks besser zu sein als jemand anderer, reicht nicht aus, um Ihre Reputation wie ein Virus zu verbreiten. Falls jemand fragen sollte, können Sie vielleicht ein hervorragendes Zeugnis vorweisen. Doch bemerkenswert zu sein bedeutet, dass die Leute über Sie reden, bevor Sie Ihre Zeugnisse herausholen.

Bemerkenswert sein

267

U m bemerkenswert zu sein, müssen Sie sich signifikant von den anderen Leuten in Ihrer Umgebung unterscheiden. Viele Strategien der Selbstvermarktung, die in diesem Kapitel beschrieben werden, zielen darauf ab, sich bemerkenswerter zu machen. Erfolgreiche Open-Source-Software zu veröffentlichen, Bücher und Artikel zu schreiben und auf Konferenzen Vorträge zu halten, trägt alles dazu bei, Sie bemerkenswerter zu machen.

Merksatz Demonstriere oder stirb!

Wenn Sie den letzten Satz noch einmal lesen, werden Sie feststellen, dass alle Einträge in dieser nicht erschöpfenden Liste eines gemeinsam haben: Bei allen müssen Sie etwas tun, um bemerkenswerter zu werden. Vielleicht sind Sie der Klügste oder Schnellste, aber nur etwas zu sein, ist nicht gut genug. Sie müssen etwas tun. Godin verwendet den Ausdruck Lila Kuh (Purple Cow), um uns daran zu erinnern, was erforderlich ist, um bemerkenswert zu sein. Nicht die beste Kuh; nicht die milchreichste Kuh; und auch nicht die schönste Kuh. Dagegen würde eine lila Kuh in einer Herde der besten, milchreichsten und schönsten Kühe herausragen. Es wäre wahrscheinlich die lila Kuh, über die Sie sprechen würden, wenn Sie dieser Herde begegneten. Was können Sie tun, um als Person mit Ihren Leistungen wie die lila Kuh herauszuragen? Eignen Sie sich nicht einfach ein Thema an - schreiben Sie ein Buch darüber. Schreiben Sie Code-Generatoren, die aus einem ehemals eine Woche dauernden Prozess einen FünfMinuten-Prozess machen. Anstatt (nur) den Respekt Ihrer Kollegen zu erwerben, werden Sie in Ihrer Stadt zur anerkanntesten Autorität für die Technologie Ihrer Wahl, indem Sie Seminare und Workshops abhalten. Nehmen Sie bei Ihrem nächsten Projekt eine für vorher undenkbar gehaltene Aufgabe in Angriff.

268

42 - Bemerkenswert sein

Geben Sie sich nicht damit zufrieden, nur der Beste im Haufen zu sein. Seien Sie die Person und tun Sie Dinge, über die die Menschen nicht nicht sprechen können.

Umsetzung i. Beginnen Sie klein; versuchen Sie, in Ihrem gegenwärtigen Projekt oder am Arbeitsplatz etwas Bemerkenswertes zu tun. Sie können etwa damit experimentieren, eine bemerkenswerte Produktivität zu erreichen. Projektpläne enthalten oft einen größeren Zeitpuffer. Suchen Sie eine Aufgabe, von der jeder glaubt, sie würde eine Woche dauern, und erledigen Sie sie an einem Tag. Machen Sie Überstunden, falls erforderlich. Sie müssen aus Überstunden keine Gewohnheit machen, aber dies ist ein Experiment. Erledigen Sie die Arbeit in einer bemerkenswert kurzen Zeit. Beobachten Sie, ob die anderen »Bemerkungen machen«. Falls nein, warum nicht? Falls ja, in welcher Form? Passen Sie die Variablen an und probieren Sie es erneut.

KAPITEL 39

Beziehungen herstellen

A

ls junger Jazz-Saxophonist in Arkansas wurde ich oft gefragt: »Übrigens, kennen Sie Chris?« Ich kannte Chris nicht. Chris war offensichtlich der andere High-School-Teen-

ager in Arkansas, der ernsthaft Jazz-Musiker werden wollte. Deshalb stellten Leute, die mich trafen, offensichtlich eine Verbindung zwischen uns her und nahmen an, wir hätten uns durch unsere für High-School-Schüler sehr untypische Liebe zum Jazz getroffen. In einem Sommer hatte ich die Gelegenheit, das Count Basie JazzOrchestra bei einem Open-Air-Auftritt in einem Amphitheater am Ufer des Arkansas River zu hören. Aufgrund einer Mischung aus guter Stimmung und einem für mich uncharakteristischen Mut landete ich schließlich baclcstage und unterhielt mich mit den Musikern, bevor sie weiterzogen. Ich war nie sehr gesprächig, deshalb war es wirklich eine schicksalhafte Wendung. Als ich im Hintergrund mit einem der Saxophonisten des Orchesters plauderte, kam ein anderer junger Kerl dazu und schaltete sich in unser Gespräch ein. Nach fünf oder zehn Minuten fuhr die Band weg, und wir blieben beide alleine stehen. »Bist du Chris/Chad?«, fragten wir gleichzeitig. In den folgenden Jahren verbrachte ich viel meiner Freizeit mit Chris. Ich erfuhr bald, dass Chris über das seltene Talent verfügte,

270

43 - Beziehungen herstellen

die besten Musiker der Stadt kennen zu lernen. Er war nur ein High-School-Schüler. Aber er spielte bereits in Gigs und trat als Ersatz für den angesehensten Jazz-Pianisten von Little Rock auf. Chris war - besonders für sein Alter - ziemlich gut, aber so gut war er auch wieder nicht. Ich brauchte nicht lange, um zu verstehen, was passierte. Wir besuchten, manchmal mehrmals pro Woche, Clubs, in denen JazzMusik gespielt wurde. Für einen introvertierten Typen wie mich war es immer eine etwas unangenehme Erfahrung, weil Chris wie ein Uhrwerk mitten im Satz aufstand und mich einfach sitzen ließ, um mit einem der Band-Mitglieder zu sprechen, wenn die Band gerade Pause machte. Er war wie ein Roboter. Ich muss zugeben, dass es mich ein wenig krank machte, ihn zu beobachten. Er war so vorhersagbar. Ging er diesen armen Musikern nicht auf die Nerven? Um Himmels willen, schließlich machten sie Pause. Sie wollten sicher nicht mit diesem blöden Kid reden! So zurückgelassen musste ich ihm entweder folgen oder alleine unbehaglich warten. Gelegentlich, an Tagen, an denen ich einfach nicht die Energie hatte, entschied ich mich für Letzteres. Doch meistens folgte ich Chris und versuchte so zu tun, als gehörte ich dazu. Zu meiner Überraschung schienen die Musiker es in ihrer Pause normalerweise zu genießen, mit Chris - und sogar mit mir - zu sprechen. Er war penetrant wie der Teufel und fragte immer, ob er bei der Band mitspielen könnte, egal wie unpassend mir dies erschien. Er bat die Musiker auch um Unterrichtsstunden, was bedeutete, dass er sie zu Hause besuchte, sich Musik anhörte und mit ihnen über Jazz-Improvisation plauderte. Gelegentlich wurde ich mitgeschleppt und hatte dasselbe Gefühl wie bei den Pausen nämlich dass ich mich aufdrängte. Aber offensichtlich war ich derjenige, der die Beziehungen, die Chris zu diesen Musikern entwickelte, falsch einschätzte. Er bekam echte, bezahlte Gigs mit wirklich guten Musikern. Ich war nur der Typ, der mit ihm abhing. Er war mein Verbindungsmann zu den

Beziehungen herstellen

271

besten Musikern der Stadt. Der einzige Unterschied zwischen uns war, dass er mehr aus sich herausging. Im Laufe der Jahre wurde aus Chris durch seine Strategie, »der Schlechteste zu sein«, kombiniert mit der Fähigkeit, sich unverfroren anderen Menschen aufzudrängen, ein unglaublicher Pianist. Tatsächlich erzwang er sich so Gelegenheiten, mit einigen wirklich berühmten Jazz-Musikern zu spielen. Ich war dagegen immer noch der Typ, den er kannte. Er zog mich mit in einige dieser bekannteren Gigs hinein, aber das Ziehen ging immer von ihm aus - niemals umgekehrt. Seit damals habe ich dasselbe Muster auch bei Leuten in anderen Gemeinschaften gesehen: in der klassischen Musik, in der American Tibetan Buddhist Community, bei der Software-Entwicklung und sogar in den Grenzen eines einzelnen Büros. Chris bezeichnete es als »making the hang« (etwa »den Aufhänger finden«, »sich anheften oder anklammern«), was es für mich nur noch abstoßender machte. Aber die kurze Version der Geschichte lautet: Wirklich gute Leute haben nichts dagegen, dass Sie sie kennen lernen wollen. Menschen werden gerne geschätzt, und sie reden gern über Themen, die ihnen am Herzen liegen. Die Tatsache, dass sie der Profi oder der Guru oder der Führer oder der bekannte Autor sind, ändert nichts daran, dass sie Menschen sind und gerne mit anderen Menschen umgehen.

Merksatz Angst schiebt sich zwischen uns und die Profis.

U m von mir selbst zu reden (und von dort zu extrapolieren): Die ernsteste Barriere zwischen uns Sterblichen und den Leuten, die wir bewundern, ist unsere eigene Furcht. Sich an kluge, wohl-vernetzte Leute zu halten, von denen Sie etwas lernen können oder die Ihnen helfen können, Arbeit zu finden, ist möglicherweise die beste

272

43 - Beziehungen herstellen

Methode, sich selbst zu verbessern; doch die meisten haben Angst, es auszuprobieren. Teil einer eng geknüpften professionellen Community zu sein, ist seit fahren die Methode, wie Musiker, Künstler und andere Fachleute stark geblieben sind und ihr jeweiliges Gewerbe weiterentwickelt haben. Die Gurus sind die Superknoten in den sozialen und professionellen Netzwerken. Um eine Verbindung herzustellen, braucht es nur etwas weniger Bescheidenheit. Natürlich sollten Sie nicht einfach ziellos anfangen, diese Leuten zu bequasseln. Offensichtlich sollten Sie Menschen aussuchen, mit denen Sie etwas gemeinsam haben. Vielleicht haben Sie einen einflussreichen Artikel gelesen, den jemand geschrieben hat. Sie könnten ihm eigene Arbeiten zum selben Thema zeigen und um seinen Input bitten. Vielleicht haben Sie auch eine Software-Schnittstelle zu einem System eines anderen Entwicklers geschrieben. Dies ist eine großartige und legitime Methode, eine Beziehung zu jemandem aufzubauen. Natürlich können Sie Beziehungen sowohl online als auch persönlich herstellen. Eine dauerhafte Beziehung ist eine dauerhafte Beziehung. Die Helden der Software-Welt leben überall auf dem Globus. Dasselbe gilt für die Musikindustrie, obwohl Sie nicht selbstverständlich annehmen dürfen, alle Musiker per E-Mail zu erreichen. Deshalb neigt die Musikwelt eher dazu, lokal professionelle Gruppen zu bilden, während Software-Entwickler den Vorteil haben, einander leicht zu erreichen, egal wo sie sich gerade befinden. Dadurch ist es leicht, nicht nur die Gurus in Ihrer Heimatstadt zu erreichen, sondern die Gurus zu erreichen, Punkt. Einige der einflussreichsten Denker der Software-Entwicklung sind leicht per E-Mail oder sogar per Echtzeit-Chat erreichbar. Die Geschichte, die mich dazu gebracht hat, dieses Buch zu schreiben, begann tatsächlich mit einer E-Mail über eine Ruby-Bibliothek an einen ihrer Veröffentlicher, gefolgt von vielen Gesprächen per Online-Chat. Obwohl ich etwas ängstlich war, diese ursprüngliche E-Mail zu senden, verärgerte ich Dave damit nicht zu sehr; und deshalb lesen Sie jetzt meine Wörter. Danke, Chris.

Umsetzung 250

Umsetzung 1. Wählen Sie eines Ihrer Lieblingsprogramme aus und senden Sie eine E-Mail an ihren Entwickler. Beginnen Sie damit, ihm oder ihr für die Software zu danken. Machen Sie dann einen Vorschlag, stellen Sie eine Frage oder unternehmen Sie einen anderen Versuch, eine zwischenmenschliche Beziehung zu ihm/ihr herzustellen. Bitten Sie u m eine Art von Antwort. Wenn die Software kostenlos oder Open Source ist, bieten Sie an, in irgendeiner Weise zu helfen. 2. Denken Sie an jemanden in Ihrer Nähe, den Sie bewundern oder von dem Sie lernen möchten. Suchen Sie nach einer Situation, in der Sie die Person treffen können (das Treffen einer Benutzergruppe oder eine Rede sind gute Gelegenheiten), und zwingen Sie sich dazu, ein Gespräch zu beginnen, selbst wenn Sie sich dabei unbehaglich fühlen - insbesondere, wenn Sie sich dabei unbehaglich fühlen.

Könnten wir nicht einfach ... von Stephen Akers Jeder, der längere Erfahrungen in der Arbeitswelt hat, kennt den laufenden Kampf zwischen der Informationstechnologie (IT) und den geschäftlichen Abteilungen eines Unternehmens. Die Konflikte basieren fast immer auf Missverständnissen, Fehlkommunikation und falsch verstandenen Erwartungen. Die Probleme kommen fast täglich durch verschiedene Stereotype zum Ausdruck, die von beiden Parteien verwendet werden. Die von den IT-Leuten meistgehasste Phrase lautet: »Könnten wir nicht einfach ...?« Beispiele gibt es zuhauf: Könnten wir nicht einfach diese Arbeit outsourcen? Könnten wir nicht einfach mehr Entwickler auf dieses Projekt ansetzen? Könnten wir nicht einfach das tun, was wir beim letzten Mal gemacht haben?

274

43 - Beziehungen herstellen

Könnten wir nicht einfach die Anwendung schneller machen? Könnten wir nicht einfach eine neue Datenbank anlegen? Das Problem ist: Viele Leute in der IT konzentrieren sich bei dieser Phase reflexartig auf das Wort einfach. Es vermittelt ihnen das Gefühl, als ob die anderen Abteilungen ihre Anfrage als offensichtlich, trivial und leicht realisierbar betrachten. Ein Scheitern bei der Implementierung würde deshalb anzeigen, dass die IT unfähig wäre, selbst die einfachsten Aufgaben zu erledigen, und deshalb wahrscheinlich ersetzt werden sollte. Deswegen lautet die übliche Antwort auf solche Anfragen oft: »Nein.« Die IT möchte, dass die anderen Abteilungen erkennen, dass ihre Vorschläge nicht nur komplex und schwierig umzusetzen, sondern grundsätzlich eine schlechte Idee sind. Und darin liegt der Konflikt. Letztlich ziehen die anderen Abteilungen mit dem Gefühl davon, die IT würde immer nur ablehnen, während die IT den Eindruck gewinnt, die anderen Abteilungen hätten überhaupt keine Ahnung, was in der IT gemacht wird. Genauso dachte ich früher. Meiner Meinung nach brauchte das Unternehmen dringend jemandem außerhalb der IT, der wirklich wusste, was diese tat. Deshalb beschloss ich an einem bestimmten Punkt meiner Karriere, die IT zu verlassen und mich dem Geschäftsbetrieb zuzuwenden. Ich erwartete ohne Selbstzweifel, dass meine Projekte rauschende Erfolge werden würden, weil ich wusste, wie die Dinge richtig getan werden mussten. Es ist schon komisch, die sich unsere Pläne nicht immer so entwickeln, wie wir es erwartet haben. Obwohl ich in dem Geschäftsbetriebsteam Erfolg hatte, war ich nicht die Art von Überflieger, der zu sein ich erwartet hatte.

Umsetzung 250

Stattdessen stellte ich fest, dass ich selbst noch viel lernen musste. Zum Beispiel: 1. Es gibt echte kommerzielle Faktoren, die fast jedes Projekt einschränken. Diese Einschränkungen erfordern manchmal, dass man eine weniger als perfekte technische Lösung implementiert. 2. Die Zeitvorgaben, die vom Geschäftsbetrieb vorgeschlagen werden, sind oft nicht so willkürlich, wie sie zu sein scheinen. Oft kann der Abgabetermin einer Lösung Auswirkungen auf andere Projekte oder sogar die Performance des Unternehmens haben. Nachdem ich diese Lektionen gelernt hatte, erkannte ich, dass die IT sich auf den falschen Teil der Aussage »Könnten wir nicht einfach ...« konzentriert hatte. Das maßgebliche Wort in der Aussage ist in Wirklichkeit das wir. Dieses Wort impliziert, dass sich das Geschäft an die IT wendet, weil die IT für den Gesamterfolg seines Teams ebenso entscheidend ist wie andere Abteilungen. Diese wenden sich an die IT, weil sie Hilfe brauchen, um eine Lösung zu entwickeln, die zum Erfolg des Unternehmens beiträgt. Wenn Sie also beim nächsten Mal diese gefürchtete Phrase hören, unterdrücken Sie Ihren Drang, »Nein« zu sagen. Konzentrieren Sie sich auf das Wort wir, und sagen Sie zuversichtlich: »Ja, wir könnten mehr Entwickler für das Projekt abstellen, aber das wäre keine gute Idee, und zwar aus folgenden Gründen ...« Doch lassen Sie es dabei nicht bewenden. Es reicht nicht aus, nur die eigene Position zu erklären. Sie müssen tiefer graben, um herauszufinden, unter welchen kommerziellen Einschränkungen das Unternehmen operiert. Im Laufe der Zeit werden Sie dadurch Ihre Kenntnisse des Geschäftsbereiches ausbauen und die zu lösenden Probleme

26

43 - Beziehungen herstellen

7

besser einschätzen können. Wenn Sie dieses Verständnis mit Ihrer technischen Expertise kombinieren, sagen Sie nicht immer nur »Nein«, sondern werden zu einem Partner, den das Geschäft kaum missen möchte. Stephen Akers ist Vizepräsident für Informationstechnologie bei Genscape, Inc.

Teil 5

Auf der Höhe der Zeit bleiben

Erinnern Sie sich an einen Popstar namens Tiffany (kein Nachname) aus den i98oern? Sie zählte zu den besten der Top Forty und wurde damals laufend im Radio gespielt. Sie hatte riesigen Erfolg und war für kurze Zeit überall bekannt. Wann haben Sie das letzte Mal (falls überhaupt) irgendetwas über sie gehört? Ich vermute, dass Sie sich nicht daran erinnern können. Ich jedenfalls kann es nicht. Tiffany hatte alles, was erforderlich war, um in den 8oern ein Hit zu sein - zumindest für kurze Zeit. Dann kamen die 90er und Tiffany war megaout. Offensichtlich änderte sie sich, falls sie es überhaupt versuchte, nicht schnell genug, um die Zuneigung - oder wenigstens die Aufmerksamkeit - ihrer Fans zu halten. Der Geschmack der Nation wandelte sich von Kaugummi zu Grunge, und plötzlich war Tiffany Geschichte. Dasselbe kann Ihnen in Ihrer Karriere passieren. Der Prozess in diesem Buch ist eine Schleife, die sich so lange wiederholt, bis Sie in Rente gehen. Erforschen, investieren, ausführen, vermarkten, wiederholen. Verbringen Sie zu viel Zeit in einer Iteration der Schleife, laufen Sie Gefahr, plötzlich überflüssig zu werden.

Es kann Sie anschleichen, wenn Sie nicht ausdrücklich aufpassen. Und wenn Sie sich überraschen lassen, ist es zu spät. Tiffany hatte wahrscheinlich keine Ahnung, dass Grunge das nächste große Ding sein würde. Sie konzentrierte sich voll darauf, ein Kaugummi-Popstar für Teenager zu sein; und als die Grunge-Musik die Top Forty übernahm, war sie unumkehrbar aus der Mode gekommen. Dieser Teil wird Ihnen zeigen, wie Sie es vermeiden können, ein Ein-Hit-Wunder zu werden.

KAPITEL 39

Bereits überholt

iele von uns fühlen sich von der IT-Branche angezogen, weil sich die Dinge laufend ändern. Es ist eine aufregende und frische Arbeitsumgebung. Es gibt immer etwas Neues zu lernen. Doch auf der Kehrseite steht die entmutigende Tatsache, dass Ihre schwer erworbenen Investitionen in Technologie-spezifisches Wissen schneller an Wert verlieren als ein neuer Volkswagen. Der heutige neueste Schrei ist der überholte Schrott von morgen. Seine Lebensdauer im Regal ist begrenzt. In Leading the Revolution [Hamo2] schreibt Gary Hamel darüber, wie die amtierenden Leiter in einer beliebigen Branche selbstzufrieden werden und aufgrund ihrer Selbstzufriedenheit blinde Flecken entwickeln, je erfolgreicher Ihr Unternehmen ist, desto größer ist die Gefahr, dass Sie mit Ihrem Geschäftsmodell bequem werden. Dann können Sie unglaublich leicht von Unternehmen angegriffen werden, die nach Ihnen kommen und mit einer radikalen Idee selbst wenn sie dumm sein sollte - Ihr wundervolles gewinnbringendes Geschäftsmodell wie einen alten, abgetragenen Sweater in einer Disco aussehen lassen könnten. Dies gilt jedenfalls für die Wahl von Technologien. Wenn Sie die führende Technologie einer bestimmten Zeit gemeistert haben, wie etwa J2EE oder .NET zu der

28o

44 - Bereits überholt

Zeit, als dieses Buch veröffentlicht wurde, befinden Sie sich möglicherweise in einer außerordentlich komfortablen Situation. Es ist der Ort, an dem Profite gemacht werden, nicht wahr? Jede Jobvermittlungs-Website und Stellenanzeige in der Zeitung bestätigt Ihre Entscheidung. Vorsicht. Erfolg gebiert Hybris, Hybris gebiert Trägheit. Wellen wie J2EE scheinen nie zu enden. Aber irgendwann lösen sich alle Wellen entweder auf oder treffen auf eine Küste. Z u viel Komfort über eine zu lange Zeit könnte dazu führen, dass Sie wehrlos werden und sich fragen, was Sie in einer Nicht-j2EE-Welt tun sollten. Doch davon abgesehen: Der Tod von COBOL wurde auch schon seit Jahrzehnten immer wieder vorhergesagt. Jede neue dominierende Technologie wird als »das COBOL des 21. Jahrhunderts« oder ähnlich bezeichnet. Heute trägt Java diesen Titel. So sehr ich es auch hasse, COBOL-Code anzufassen, zu sehen oder auch nur in meiner Nähe zu haben, ist es doch ein echtes Kompliment, Java als das COBOL des 21. Jahrhunderts zu bezeichnen. Und so gerne viele von uns sehen würden, dass COBOL verschwindet, ist es doch immer noch da und funktioniert bereits seit langer Zeit. COBOL-Programmierer haben eine ganze Karriere lang mit COBOL gearbeitet. Das will in dieser Branche, die sonst an Achterbahnfahrten gewöhnt ist, wirklich etwas heißen. Es ist schwer zu sagen, ob eine gleichartige Investition in der heutigen Wirtschaft funktionieren würde. Die Geschichte von COBOL ist die Ausnahme - nicht die Regel. Wenige Technologien bieten eine dauerhafte Plattform für Anstellungen. Ich will damit nicht sagen, dass Sie kündigen und Ihr Mainstream-Wissen vergessen sollten. Das wäre unverantwortlich. Ich will sagen, dass Sie mit Ihrem Wissen, je mehr dieses im Mainstream verankert ist, umso eher riskieren, in der technologischen Steinzeit zurückzubleiben. Wir haben alle die Extrapolation von Moores Gesetz gehört, wonach sich die Rechnerleistung alle 18 Monate verdoppelt. Unabhängig

Bereits überholt

281

davon, ob diese Zahl genau stimmt, ist es leicht zu sehen, dass die Technologie immer noch mit grob derselben Rate fortschreitet wie 1965, als der Intel-Ingenieur George Moore sein Gesetz formulierte. Und diese Fortschritte der Hardware-Pferdestärken haben ganz neue Möglichkeiten der Software-Entwicklung geschaffen. Computer-Leistung verdoppelt sich. Wenn die Technologie so schnell voranschreitet, passiert so viel gleichzeitig, dass eine einzelne Person damit nicht Schritt halten kann. Selbst wenn Ihre Fähigkeiten vollkommen auf der Höhe der Zeit sind, ist es beinahe zu spät, wenn Sie nicht bereits fast fertig damit sind, sich das »Nächste Große Ding« anzueignen. Sie können der gegenwärtigen Welle voraus sein und der nächsten bereits nachhinken. In einer solchen Umgebung wird das Timing sehr wichtig. Sie müssen mit der Einsicht beginnen, dass Sie, selbst wenn Sie an der Vorderfront der heutigen Welle arbeiten, wahrscheinlich bereits der nächsten hinterherhinken. Da das Timing alles bedeutet, sollten Sie bei Ihrer Weiterbildung anfangen vorauszudenken. Was wird in zwei Jahren möglich sein, das jetzt noch nicht möglich ist? Was wäre, wenn Festplattenspeicher so billig wäre, dass er praktisch kostenlos wäre? Was wäre, wenn Prozessoren doppelt so schnell wären? Welche Optimierungen wären dann überflüssig? Welchen Einfluss haben diese Fortschritte darauf, was der nächste Hit sein wird? Ja, es hat etwas von einem Glücksspiel. Aber es ist ein Spiel, das Sie definitiv verlieren werden, wenn Sie nicht spielen. Der schlimmste Fall ist, dass Sie zusätzlich etwas gelernt haben werden, das auf Ihren Job in zwei Jahren nicht direkt anwendbar ist. Deshalb stehen Sie sich immer noch besser, wenn Sie vorausblicken und ein derartiges Risiko eingehen. Der beste Fall ist, dass Sie der Kurve vorausbleiben und Ihren Status als Experte in führenden neuen Technologien behalten werden. Vorauszuschauen und gezielt Ihre Fähigkeiten zu entwickeln, kann den Unterschied bedeuten, ein Blinder oder ein Visionär zu sein.

28o

28o 44 - Bereits überholt

Umsetzung i. Reservieren Sie jede Woche eine bestimmte Zeit, um sich mit den neuesten Entwicklungen vertraut zu machen. Nehmen Sie sich wenigstens zwei Stunden pro Woche Zeit, um neue Technologien zu erforschen, und beginnen Sie, den Umgang mit ihnen zu lernen. Arbeiten Sie praktisch mit diesen neuen Technologien. Erstellen Sie einfache Anwendungen. Erstellen Sie mit diesen neuen Technologien Prototypen Ihrer Projekte, die mit dem gegenwärtigen Technologien erstellt worden sind, um die Unterschiede kennen zu lernen und zu erfahren, was die neuen Technologien möglich machen. Setzen Sie diese Aufgabe auf Ihren Zeitplan. Versäumen Sie diese Aufgabe nicht.

KAPITEL 39

Sie haben Ihren Job bereits verloren

er Job, für den Sie angestellt wurden, existiert nicht mehr.

D

Sie bekommen vielleicht immer noch Ihren Gehaltsscheck. Sie schaffen vielleicht immer noch einen Mehrwert. Viel-

leicht machen Sie sogar Ihren Arbeitgeber ekstatisch glücklich. Aber Sie haben Ihren Job bereits verloren. Sicher ist nur, dass alles sich ändert. Die Wirtschaft wandelt sich. Arbeitsplätze werden ins Ausland und wieder zurück verlagert. Unternehmen versuchen herauszufinden, wie sie sich anpassen können. In unserer Branche haben die Dinge ihr Gleichgewicht noch nicht gefunden. Unsere Branche verhält sich wie ein linkischer Heranwachsender in der Pubertät. Linkisch, hässlich und von Jahr zu Jahr und von Tag zu Tag verschieden. Deshalb sollten Sie, wenn Sie als Programmierer eingestellt wurden, sich nicht als Programmierer sehen. Besser gesagt: Betrachten Sie sich nicht mehr als Programmierer. Erledigen Sie Ihre Arbeit, aber richten Sie sich nicht zu bequem in dieser Rolle ein. Finden Sie sich möglichst nicht mit Ihrer Identität als Programmierer ab. Oder als Designer. Oder als Tester. Tatsächlich ist es nicht mehr sicher (als ob es das je gewesen wäre!), sich zu stark mit dem Job zu identifizieren, für den Sie eingestellt wurden. Wenn sich Ihr Umfeld wandelt und sich der Kontext Ihrer

284

45 - Sie haben Ihren Job bereits verloren

Arbeit laufend verschiebt, erzeugt das Anhaften an Ihrem Job eine ungesunde Dissonanz, die sich auf Ihre Arbeit überträgt. Vielleicht leisten Sie gerade als Möchte-gern-Programmierer

Arbeit, die

eigentlich von einem Projektmanager erledigt werden sollte; und zwar nicht besonders gut.

Merksatz Sie sind nicht Ihr Job.

Damals, bevor Sie Ihren Job verloren haben, hatten Sie vielleicht Pläne. Vielleicht sahen Sie bereits Ihren kontinuierlichen Aufstieg durch die Ränge des Unternehmens vom Programmierer über den Designer zur Rolle des Architekten, die Ihnen als Belohnung zustand. Sie konnten Ihre gesamte Karriere die Managementkette hinauf sehen - vom Architekten weiter zum Analytiker und zum Teamleiter. Aber Sie haben Ihren Job bereits verloren und Ihre Pläne haben sich geändert. Sie werden sich auch in Zukunft ändern. Jeden Tag. Es ist gut, Ambitionen zu haben, aber setzen Sie nicht zu stark auf Visionen, die weit in die Zukunft reichen. Sie können es sich nicht leisten, mit einem Tunnelblick auf Ziele zu schauen, die zu weit in der Zukunft liegen. Wenn Sie ein bewegliches Ziel treffen wollen, nehmen Sie nicht das Ziel selbst ins Visier. Sie zielen auf einen Punkt, an dem sich das Ziel wahrscheinlich befinden wird. Der Weg von hier nach dort ist nicht mehr eine gerade Linie. Es ist bestenfalls ein Bogen, aber höchstwahrscheinlich irgendeine Schlangenlinie.

Umsetzung 1. Wenn Sie Programmierer sind, versuchen Sie, ein oder zwei Tage lang Ihren Job so zu leisten, als wären Sie ein Tester oder ein Projektmanager. Welche vielen Rollen könnten Sie von Tag zu Tag spielen, an die Sie nie ausdrücklich gedacht haben? Legen

Umsetzung 250

250

Sie eine Liste an und üben Sie diese Rollen versuchsweise aus etwa einen Tag pro Rolle. Möglicherweise ändert sich dadurch nicht einmal der Output Ihrer normalen Arbeit, aber Sie lernen Ihre Arbeit aus einer anderen Perspektive kennen.

KAPITEL 39

Weg ohne Ziel

ines der größten Probleme von Amerika besteht darin, dass es

E

eine zielorientierte Gesellschaft ist. Wir sind eine Nation von Menschen, die sich immer auf das Ergebnis eines Prozesses

konzentrieren, egal, ob es sich um einen Lernprozess, die eigene Karriere oder sogar eine Autofahrt handelt. Wir sind so auf das Ergebnis fixiert, dass wir vergessen, uns die Umwelt auf dem Weg dorthin zu betrachten. Wenn man darüber nachdenkt, ist die Fixierung auf Ergebnisse logisch genau das Gegenteil davon, worauf wir unsere Zeit verwenden sollten. Normalerweise verbringt man seine meiste Zeit damit, Dinge zu tun, und nur einen kleinen Teil damit, tatsächlich Ziele zu erreichen. Ein Beispiel: Wenn Sie Software entwickeln, verbringen Sie Ihre gesamte Zeit mit dem Entwicklungsprozess, nicht mit dem tatsächlichen Ereignis, bei dem die fertige Software plötzlich am Ende des Prozesses auftaucht. Dasselbe gilt für Ihre Karriere. Das Hauptgewicht Ihrer Karriere sind nicht die Beförderungen oder Gehaltserhöhungen. Es ist die Zeit, in der Sie auf diese Ziele hinarbeiten. Oder noch wichtiger: Es ist die Zeit, die Sie unabhängig von diesen Beförderungen mit der Arbeit verbringen.

288

46 - Weg ohne Ziel

Wenn dies der Kern Ihres Arbeitslebens - der eigentlichen Arbeit ist, sind Sie bereits an Ihrem Ziel angekommen. Ihr normales zielorientiertes, auf Ergebnisse ausgerichtetes Denken führt Sie nur von einem Ziel zum nächsten. Es hat kein logisches Ende. Die meisten von uns erkennen nicht, dass der Weg das Ziel ist. Zurück zum Beispiel der Software-Entwicklung: Es ist leicht, sich auf die Auslieferung des Codes zu fixieren, den Sie gerade entwickeln. Ihr Kunde braucht eine Webanwendung, und Sie konzentrieren sich darauf, diese Anwendung fertigzustellen. Doch eine lebendige Anwendung ist niemals »fertig«. Ein Release führt zum nächsten. Eine zu starke Fixierung auf das Endprodukt lenkt uns von dem wirklichen Deliverable ab: eine fortlaufende und nachhaltige Arbeit an einer neuen Entität.

Merksatz Konzentrieren Sie sich auf das Tun, nicht auf das Fertigsein.

Wenn Sie sich auf das Ziel fokussieren, vergessen Sie leicht, den Prozess, den Weg dorthin, gut zu bewältigen. Und schlechte Prozesse bringen schlechte Produkte hervor. Vielleicht erfüllt das Produkt seine Mindestanforderungen, aber innen wird es hässlich sein. Sie haben für ein kurzfristiges Endziel optimiert, nicht für die unvermeidliche, fortlaufende künftige Weiterentwicklung des Produkts. Schlechte Prozesse bringen nicht nur schlechte Produkte hervor, sondern schlechte Produkte führen ihrerseits zu schlechten Prozessen. Wenn Sie erst einmal eines dieser Produkte haben, die im Inneren chaotisch sind, passen sich Ihre Prozesse diesem Chaos an. Die zerbrochenen Fenster Ihres Produkts führen zu zerbrochenen Fenstern bei Ihrem Prozess. Es ist ein Teufelskreis. Anstatt also laufend zu fragen: »Sind wir schon angekommen? Sind wir schon angekommen?«, sollten Sie erkennen, dass die einzige

Umsetzung 250

250

gesunde Antwort lautet: »Ja.« Wie Sie Ihren Weg gehen, ist wichtig - nicht das Ziel.

Umsetzung 1. In seinem Buch The Miracle of Mindfulness [Han99] macht Thich Naht Hanh einen Vorschlag: Wenn Sie das nächste Mal den Abwasch erledigen, spülen Sie das Geschirr nicht, um fertig zu werden. Versuchen Sie, die Erfahrung des Abwaschens zu genießen. Denken Sie nicht daran, fertig zu werden. Konzentrieren Sie sich auf den Akt des Abwaschens selbst. Geschirr abzuwaschen, ist eine Alltagstätigkeit, die fast niemand schätzt.

Software-Entwickler müssen während eines

durch-

schnittlichen Arbeitstages zahlreiche ähnlich langweilige Fleißaufgaben erledigen, etwa ihre Tagesberichte schreiben oder Ausgaben festhalten. Wenn Sie beim nächsten Mal eine solche Aufgabe erledigen müssen, probieren Sie, ob Sie sich auf die Aufgabe selbst konzentrieren können, anstatt gehetzt zu versuchen, schnell fertig zu werden.

KAPITEL 39

Machen Sie sich eine Karte

m »Wartungsmodus« gleitet man leicht in eine bestimmte Rolle und macht einfach immer so weiter. Als Software-Entwickler haben Sie diese Erfahrung mit Systemen gemacht. Wenn Sie eine Anwendung oder Bibliothek warten, die von anderen Entwicklern benutzt wird, bleibt diese in einem Bug-Fix-Modus (oder schlimmer) stecken, wenn Sie nicht einen soliden Plan für künftige Funktionen ausgearbeitet haben. Sie verbessern zwar hier und da etwas, weil der Anwender dies wünscht oder weil Sie es brauchen; doch normalerweise erreicht der Code einen stabilen Zustand, in dem Sie ihn äußerst selten ändern, weil Sie ihn für fertig halten. Aber eine lebendige Anwendung ist niemals fertig, es sei denn, sie soll bald ausgemustert werden. Dasselbe gilt für Sie und Ihre Karriere. Wenn Sie die Branche nicht verlassen wollen, brauchen Sie eine Straßenkarte. Wenn Microsoft Windows 3.1 als fertiges Produkt betrachtet hätte, würden heute alle mit Macintoshs arbeiten. Wenn die Apache-Entwickler ihren Webserver mit Version 1.0 als fertig betrachtet hätten, hätten sie nicht die heutige erdrückende Marktdominanz erreicht. Die Straßenkarte Ihrer persönlichen Weiterentwicklung ist das Mittel, an dem Sie Ihren Fortschritt messen können. Wenn Sie jeden Tag ins Büro gehen und hauptsächlich an denselben Dingen arbei-

2g2

47 - Machen Sie sich eine Karte

ten, ändert sich die Szenerie um Sie herum nicht. Sie müssen einige etwas weiter voneinander entfernte Wegemarken abstecken, damit Sie auch erkennen, dass Sie tatsächlich vorangekommen sind, wenn Sie diese Marken erreichen. Hier sind diese Marken die verschiedenen Aspekte Ihres Könnens. Solange Sie diese Marken nicht tatsächlich abstecken und einen Plan aufstellen, können Sie nicht über den nächsten Punkt am Horizont hinaussehen. In den Kapiteln 2 und 3 haben Sie erfahren, wie Sie Ihren Karriereweg gezielt anpacken und in Ihre professionellen Fähigkeiten investieren können. Auch wenn es dort scheinbar um eine einmalige Wahl der richtigen Investition ging, sollte jede Entscheidung in ein größeres Ganzes eingebettet sein. Jeden Satz neuer Kenntnisse oder Fähigkeiten ähnlich wie eine einzelne Funktion in einer Anwendung zu betrachten, setzt den passenden Kontext. Eine Anwendung mit nur einer einzigen Funktion ist wohl etwas dürftig. Darüber hinaus verwirrt eine Anwendung ihre Anwender, wenn ihre Funktionen nicht zusammenpassen. Ist dies ein Adressbuch oder eine Chat-Anwendung?

Ist dies ein Spiel oder ein Webbrowser? Eine

persönliche Straßenkarte hilft Ihnen nicht nur, sich in die richtige Richtung weiterzuentwickeln, sondern vermittelt Ihnen auch ein größeres Bild Ihres Potenzials insgesamt. Sie kann Ihnen zeigen, dass keine einzige Funktion für sich isoliert dasteht. Jede neue Investition ist Teil eines größeren Ganzen. Einige Funktionen passen wunderbar zusammen. Bei anderen muss ein potenzieller Arbeitgeber zu große gedankliche Sprünge leisten. Habe ich es mit einem Systemadministrator oder einem Grafikdesigner zu tun? Sitzt vor mir ein Anwendungsarchitekt oder ein Gurujur die Qualitätssicherung? Obwohl es definitiv in Ordnung ist, sich diverse Fähigkeiten anzueignen - es erweitert Ihr Denken - , sollten Sie auch an die Geschichte denken, die Ihr Satz von Fähigkeiten erzählt. Ohne Straßenkarte könnte Ihre Geschichte eher wie ein Roman von Jack Kerouac aussehen als wie ein in sich konsistenter Satz logisch ver-

Umsetzung 250

wandter Fähigkeiten. Ohne Straßenkarte kommen Sie möglicherweise sogar vom Weg ab.

Umsetzung i. Bevor Sie eine Karte Ihres künftigen Wegs entwerfen, könnte es ermutigend und informierend sein, eine Karte Ihrer früheren Stationen zu erstellen. Nehmen Sie sich Zeit, um ausdrücklich eine Zeitleiste Ihrer Karriere darzustellen. Zeigen Sie, wo Sie angefangen haben, welche Jobs Sie gehabt haben und über welche Fähigkeiten Sie an jedem Meilenstein verfügt haben. Halten Sie fest, wo Sie nur schrittweise vorangekommen und wo Sie größere Sprünge gemacht haben. Achten Sie auf die durchschnittliche Zeitdauer bis zur jeweils nächsten größeren Beförderung. Benutzen Sie diese Karte als Input, um einen Blick auf Ihre zukünftige Karriere zu werfen. Sie können sich selbst realistischere Ziele setzen, wenn Sie ein klares Bild Ihrer historischen Fortschritte haben. Halten Sie diese historische Karte auf dem Laufenden. Sie eignet sich hervorragend, den eigenen Fortschritt auf dem Weg zu neuen Zielen zu reflektieren.

KAPITEL 39

Beobachten Sie den Markt

ie wären dumm, wenn Sie Ihr Geld in Aktien mit stark

S

schwankenden Kursen investierten und dann den Kursver-

lauf nicht beobachteten. Selbst wenn Sie sich gründlich

informiert haben und Ihre Investitionen ganz gezielt ausgewählt haben, ist der Markt ungewiss. Bei Geldanlagen gibt es kein Schließen-und-Vergessen. Selbst wenn der Kurs einer Aktie gegenwärtig steigt, können Sie nicht sicher sein, dass er morgen nicht wieder fällt. Sie könnten auch eine Gelegenheit verpassen. Vielleicht finden Sie eine wirklich sichere Anlage, die Ihnen pro Jahr eine Rendite von zehn Prozent bringt. Das hört sich ziemlich gut an, solange der Rest des Marktes nicht plötzlich sehr viel mehr als zehn Prozent erzielt. Ihre Hauptanlage von heute ist selbst bei laufenden konstanten Erträgen im Vergleich zu den künftigen Möglichkeiten möglicherweise nicht besonders beeindruckend. Wenn Sie nicht auf die sich ändernden Marktbedingungen achten, könnten Sie Geld verlieren oder Gelegenheiten verpassen, Geld zu verdienen. Dasselbe gilt für Investitionen in Ihr Wissen. Heute ist Java eine konservative Anlage. Was könnte sich ändern, damit dies nicht mehr gilt? Wie könnten Sie erfahren, ob sich das geändert hat?

296

48 - Beobachten Sie den Markt

Was passiert beispielsweise, wenn es plötzlich Anzeichen gäbe, dass die Existenz von Sun Microsystems ernsthaft gefährdet wäre? Sun hat in den letzten Jahren seine Marktführerschaft verloren, und Java ist kein offener Standard. Obwohl Java heute Open Source ist, wird seine Weiterentwicklung von Sun kontrolliert. Ein sterbendes Sun könnte jederzeit versuchen, in letzter Minute aus seiner Sprache und Ihrer virtuellen Maschine ein Profitcenter zu machen. Es könnte die Java-Sprache durch inkompatible Änderungen fragmentieren und so eine branchenweite Panik auslösen. (A.d.Ü.: Prophetische Aussagen. 2 0 0 9 wurde Sun Microsystems von Oracle übernommen.

Die Java Community rätselt immer noch über die

Zukunft von Java; Stand Juli 2009.) Wenn Sie beim Codieren bis über die Ohren mit dem Kopf in Ihrem Monitor stecken, erfahren Sie möglicherweise von diesen Entwicklungen erst, wenn es zu spät ist. Plötzlich befinden Sie sich in einem Arbeitsmarkt, auf dem Ihre Fähigkeiten erheblich abgewertet sind. Diese hypothetische Situation ist unwahrscheinlich, aber etwas Derartiges könnte jederzeit passieren. Noch wahrscheinlicher ist, dass Sie, zufrieden mit Ihrer gegenwärtigen Arbeit und Ihrem gegenwärtigen Satz von Fähigkeiten, in einer seligen Dummheit verharrend, das »Nächste Große Ding«, das da auf Sie zudonnert, überhaupt nicht bemerken. Vor etwa zehn Jahren wären Sie überrascht gewesen herauszufinden, dass objektorientierte Sprachen mit Garbage Collection eines der wichtigsten Themen werden würden. Doch es gab definitiv Anzeichen, die Sie hätten bemerken können, wenn Sie nur darauf geachtet hätten. Wer weiß, was in zehn Jahren ab heute das »Nächste Große Ding« sein wird? Sie müssen Augen und Ohren offen halten. Verfolgen Sie die Technologie-Nachrichten, sowohl auf der geschäftlichen als auch auf der rein technischen Seite, und achten Sie auf Entwicklungen, die Wellen auslösen könnten. Tim O'Reilly von O'Reilly and Associates (tim.oreilly.com) drückt dies folgendermaßen aus: Beobachte die

Umsetzung 250

Alpha-Geeks! Alpha-Geeks sind die Superhacker, die immer an der blutigsten Spitze der blutigen Schneide zu finden sind - zumindest bei ihren Hobby-Aktivitäten. Tims Rat, den ich seitdem in der Wildnis beachtet habe, ist folgendermaßen zu interpretieren: Wenn Sie solche Leute ausmachen und beobachten können, womit sie sich beschäftigen, können Sie einen kleinen Blick auf das erhaschen, was in ein oder zwei Jahren wirklich wichtig sein wird. Es ist verblüffend, wie gut das funktioniert.

Merksatz Beobachten Sie die Alpha-Geeks.

Doch wie immer Sie die Sache anpacken, müssen Sie immer daran denken, dass im Technologie-Sektor eine Investition, die heute ertragreich ist, in Zukunft keine gute Investition mehr sein wird. Und wenn Sie die Stimmung des Marktes beobachten, könnte er eine Überraschung für Sie parat haben, und zwar eine Art von Überraschung, die Sie überhaupt nicht schätzen.

Umsetzung i. Versuchen Sie, im Laufe des nächsten Jahres ein Alpha-Geek zu werden. Oder hängen Sie sich wenigstens an einen dran.

KAPITEL 39

Dieser fette Mann im Spiegel

nglücklicherweise habe ich Übergewicht, und zwar schon

U

seit langer Zeit. Doch als ich in Indien lebte, verlor ich sehr

viel Gewicht. Das lag zum Teil an der Ernährung, zum Teil

an einem regelmäßigen Training, doch hauptsächlich daran, dass ich krank wurde. Nach meiner Rückkehr in die Vereinigten Staaten nahm ich langsam wieder zu. Enttäuscht schrieb ich mich in einem Fitnessstudio ein und nahm einen Fitnesstrainer. Das Gewicht ging

wieder zurück. Ich habe mehrere dieser Fluktuationen durchgemacht. Das Faszinierende daran ist, dass ich nicht wirklich weiß, wann ich zunehme oder abnehme. Ich erkenne es nur daran, wenn mich jemand darauf anspricht oder meine Kleidung plötzlich nicht mehr passt. Meine Frau sieht mich jeden Tag und erkennt es deshalb auch nicht. Und in den Vereinigten Staaten sprechen andere Menschen im Allgemeinen nicht davon, wenn Sie zunehmen. Im Gegensatz zu Indien. Ich erkenne es nicht, weil ich mich zu oft sehe. Wenn man permanent mit einer Sache umgeht, erkennt man eigentlich nur sehr schnelle Änderungen. Wenn Sie einer Pflanze beim

Blühen

zuschauen, bemerken Sie Änderungen erst nach langer Zeit. Doch gehen Sie zwei Tage weg und schauen dann wieder nach, ist die Änderung offensichtlich.

300

49 ~ Dieser fette Mann im Spiegel

Dasselbe Phänomen können Sie bei Ihrer Karriere beobachten. Die Veränderungen vollziehen sich unmerklich. Das ist das Problem. Sie könnten sich selbst jeden Tag in Ihrem metaphorischen Spiegel betrachten und nicht die kleinste Änderung bemerken. Sie scheinen genauso gut angepasst zu sein wie zuvor. Sie scheinen genauso konkurrenzfähig zu sein wie zuvor. Ihre Fähigkeiten scheinen so aktuell zu sein wie zuvor. Dann plötzlich passt Ihnen eines Tages Ihr Job (oder Ihre Branche) nicht mehr. Zunächst fühlen Sie sich einfach unwohl, aber Sie haben bereits einen kritischen Punkt erreicht, an dem Sie entweder schnell handeln müssen oder sich eine neue (metaphorische) Hose kaufen müssen. Bei Änderungen des Körpergewichts kann man sich wiegen; deshalb ist es ziemlich leicht, Fortschritte (oder, wie in meinem Fall, mangelnde Fortschritte) zu messen. Leider gibt es keine derartige Waage, um die Marktgängigkeit Ihrer Fähigkeiten als Software-Entwickler zu messen. Wäre es anders, könnten Sie sich auf diese Waage setzen und Gehaltsschecks generieren. Deshalb brauchen Sie ein eigenes Messsystem. Man kann eigenen Fortschritt einfach messen, indem man vertrauenswürdige Dritte fragt. Ein Mentor oder ein nahestehender Kollege kann Ihnen helfen, Ihre Position objektiver einzuschätzen. Sie könnten mit ihm Ihre Fähigkeiten als Software-Entwickler, Projektleiter, Kommunikator, Teammitglied oder einen anderen Aspekt Ihrer Persönlichkeit diskutieren. Bei GE gibt es einen Prozess, der als 360-Degree-Review

(360-Grad-Beurteilung) bezeichnet wird und

der diese Idee formalisiert. Er ermutigt Mitarbeiter, Kollegen, Manager und interne Kunden um Feedback zu bitten. Die Bezeichnung dieses Prozessors ist ein typisches Beispiel für Unternehmenschinesisch. Doch der Prozess selbst ist eine großartige Möglichkeit zu erfahren, wie man selbst als Mitarbeiter aus verschiedenen Perspektiven gesehen wird.

Dieser fette Mann im Spiegel

301

Merksatz Entwickler, beurteile dich selbst.

Die wichtigste Funktion dieses alleine oder mit fremder Hilfe ausgeführten Prozesses besteht darin, seine blinden Flecken aufzudecken. Sie müssen nicht alle beseitigen. Sie müssen nur wissen, wo Sie blinde Flecken haben. Ohne diese Kenntnis bleiben Sie blind, was Ihre blinden Flecken angeht. Und diese Blindheit ist die Ursache dafür, dass Sie von schlimmen Dingen überrascht werden. Schlimme Dinge werden passieren; deshalb ist es besser, sie kommen zu sehen. Selbst wenn Sie Ihre Fähigkeiten mit einer magischen Waage wiegen und bewerten könnten, müssten Sie diese Waage tatsächlich benutzen. Planen Sie deshalb Ihre Beurteilungen. Sie (als Person) reflektieren Ihre Arbeit nur, wenn Sie die Zeit für die Reflexion ausdrücklich festlegen. Einfach zu sagen: »Vergessen Sie nicht, um Feedback zu bitten«, ist als Botschaft nicht nachdrücklich genug. Wenn Sie mit einem Kalenderprogramm arbeiten, das Erinnerungen in Pop-up-Fenstern anzeigt, verabreden Sie sich mit sich selbst, um diese Selbstbewertungen durchzuführen. Legen Sie zunächst ein Messsystem fest und tragen Sie es dann in den Zeitplan ein. Wenn es kein fester Bestandteil Ihres Arbeitslebens wird, werden Sie es nicht tun. Wenn Ihr Unternehmen bereits mit derartigen Prozessen arbeitet, schreiben Sie ihn nicht als Marotte der Personalabteilung ab. Nehmen Sie ihn ernst und sorgen Sie dafür, dass Sie seine Ergebnisse sinnvoll für sich umsetzen. Vielleicht ist der Prozess an Ihrem Arbeitsplatz unzulänglich implementiert, doch das entwertet nicht die Gründe (oder wenigstens die ursprünglichen Gründe) für seine Durchführung. Wenn Sie Ihr System eingerichtet und in Ihren normalen Arbeitsablauf eingeplant haben, müssen Sie schließlich seine Ergebnisse

302

4 9 ~ Dieser fette Mann im Spiegel

schriftlich festhalten. Verwahren Sie die Begutachtung in Reichweite. Wiederholen und überarbeiten Sie sie regelmäßig. Wenn Sie diesen Prozess der Selbstbewertung an ein körperliches Artefakt binden, machen Sie es konkret. Lassen Sie nicht zu, dass sich die Obsoleszenz anschleicht wie Hosen, die von Tag zu Tag schleichend enger werden.

Umsetzung i. Machen Sie eine 360-Grad-Beurteilung. •

Legen Sie eine Liste der vertrauenswürdigen Leute an, die Sie zwanglos um Feedback bitten können. Die Liste sollte vorzugsweise Repräsentanten Ihrer Kollegen, Kunden und Vorgesetzten

(sowie

Ihrer

Untergebenen,

falls

zutreffend)

umfassen. •

Legen Sie eine weitere Liste mit etwa zehn Eigenschaften an, die Ihrer Meinung nach wichtige Maßstäbe für Ihre berufliche Arbeit sind.

•

Wandeln Sie diese Liste in einen Fragebogen um. Bitten Sie die Teilnehmer, Sie anhand des Fragebogens in jeder einzelnen Eigenschaft zu bewerten. Fügen Sie auch die Frage hinzu: »Was hätte ich fragen sollen?«

•

Verteilen Sie den Fragebogen an Personen auf der Liste aus dem ersten Schritt. Bitten Sie Ihre Gutachter, konstruktive Kritik zu üben. Sie brauchen ein ehrliches Feedback - keine Schmeicheleien.

Wenn Sie die ausgefüllten Fragebogen zurückbekommen haben, lesen Sie alle durch. Stellen Sie eine Liste der Aktionen zusammen, die Sie aufgrund der Ergebnisse durchführen wollen. Wenn Sie den richtigen Leuten die richtigen Fragen gestellt haben, gibt es auf jeden Fall einige Punkte, bei denen Sie aktiv werden können. Teilen Sie das Ergebnis Ihres Fragebogens Ihren Gutachtern mit - nicht die Antworten, sondern die Ände-

Umsetzung 250

rungen, die Sie aufgrund der Ergebnisse planen. Vergessen Sie nicht, ihnen zu danken. Wiederholen Sie diesen Prozess gelegentlich. 2. Beginnen Sie, ein Journal zu führen. Es könnte ein Weblog (siehe Kapitel 39, Verschaffen Sie sich Gehör) oder ein persönliches Tagebuch sein. Schreiben Sie auf, woran Sie arbeiten, was Sie lernen und was Sie über die Branche denken. Wenn Sie das Journal eine Zeit lang geführt haben, lesen Sie Ihre älteren Einträge noch einmal durch. Sind Sie immer noch derselben Meinung? Hören Sie sich naiv an? Wie sehr haben Sie sich geändert?

Die südindische AfFenfalle

n Ztn and the Art ofMotorcycle Maintenance [Piroo] erzählt Robert Pirsig eine aufschlussreiche Geschichte, wie die Menschen in Südindien Affen fingen. Ich weiß nicht, ob sie wahr ist, aber sie enthält eine nützliche Lektion. Deshalb erzähle ich sie nach. Die Leute in Südindien wurden im Laufe der Jahre immer wieder von Affen geplagt und

entwickelten

deshalb eine raffinierte

Methode, sie zu fangen. Sie gruben ein schmales langes Loch in den Boden und benutzten dann ein etwas längeres Objekt, um den Boden des Loches auszuweiten. Dann schütteten sie Reis in den breiteren Teil am Boden des Lochs. Affen essen gern. Tatsächlich ist dies der Hauptgrund für ihre Aufdringlichkeit. Sie springen auf Autos oder riskieren es, durch große Gruppen von Menschen zu flitzen und ihnen das Essen direkt aus der Hand zu reißen. Die Leute in Indien sind sich dessen schmerzlich bewusst. (Glauben Sie mir, es ist überraschend irritierend, friedlich in einem Park zu stehen und plötzlich von einem heranrasenden Malcaken etwas aus der Hand gerissen zu bekommen.) Laut Pirsig waren die Affen natürlich neugierig. Sie entdeckten den Reis in den Löchern und streckten ihre Arme tief bis zum Boden hinein. Dann umklammerten sie gierig so viel Reis wie möglich und machten dabei eine Faust. Ihre Fäuste passten zwar in die größere

306

50 - Die südindische Affenfalle

Öffnung am Boden des Loches, aber sein Schacht war so schmal, dass die Affen ihre Faust nicht herausziehen konnten. Sie saßen fest. Natürlich hätten sie das Futter einfach loslassen können und wären frei gewesen. Aber auf der Werteskala der Affen hatte Futter einen sehr hohen Wert. Tatsächlich schätzen sie es so, dass sie sich nicht zwingen können, es loszulassen. Sie klammerten den Reis fest, bis er entweder aus dem Boden kommt oder sie bei dem Versuch, ihn herauszuziehen, umkommen. Normalerweise passierte Letzteres zuerst. Pirsig erzählt diese Geschichte, um ein Konzept zu illustrieren, das er als Wertestarrheit bezeichnet. Wertestarrheit liegt vor, wenn man an den Wert einer Sache so stark glaubt, dass man sie nicht mehr objektiv infrage stellen kann. Die Affen schätzten den Reis so hoch ein, dass sie, wenn sie gezwungen waren, zwischen dem Reis und Gefangenschaft oder Tod zu wählen, nicht erkennen konnten, dass der Verzicht auf den Reis für sie in dem Moment das Richtige gewesen wäre. In der Geschichte stehen die Affen wirklich dumm da, aber die meisten Menschen haben ihre eigenen Äquivalente zum Reis. Wenn Sie gefragt würden, ob es eine gute Idee wäre, verhungernde Kinder in Entwicklungsländern zu ernähren, würden Sie wahrscheinlich ohne Nachdenken mit »Ja« antworten. Wenn jemand versuchte, mit Ihnen über dieses Thema zu diskutieren, würden Sie ihn für verrückt halten. Dies ist ein Beispiel für Wertestarrheit. Sie glauben an diese eine Sache so stark, dass Sie sich nicht einmal vorstellen können, nicht daran zu glauben. Klar, nicht alle Werte, denen wir rigide verhaftet sind, sind schlecht. Für die meisten Menschen ist die Religion (oder ihr Fehlen) ebenfalls ein Satz unbeugsamer persönlicher Überzeugungen und Werte. Aber nicht alle rigide verfochtenen Werte sind gut. Außerdem sind manche Dinge unter gewissen Umständen gut, aber unter anderen Umständen weniger gut.

30850-Die südindische Affenfalle

Merksatz Rigide Werte machen Sie zerbrechlich.

Beispielsweise ist es leicht, sich an technologische Entscheidungen zu klammern. Dies gilt insbesondere, wenn die Technologie unserer Wahl zu den Außenseitern gehört. Wir lieben die Technologie so sehr und räumen dem Kampf um ihren Einsatz einen so hohen Rang auf unserer Werteskala ein, dass wir jede Gelegenheit als eine Schlacht betrachten, die zu schlagen sich lohnt - selbst wenn wir etwas propagieren, das ganz offensichtlich die falsche Wahl wäre. Ein Musterbeispiel (von dem ich mich wahrscheinlich selbst nicht ausschließen kann) bildet die Gemeinde der übereifrigen LinuxFans. Viele Linux-Anwender würden Linux am liebsten auf jedem Desktop jedes Empfangstisches, jedes Büroangestellten und jedes Vorstands installieren, ohne Rücksicht auf die Tatsache, dass Linux bei der Bedienungsfreundlichkeit (Usability) vielen kommerziellen Software-Paketen, die für ein kommerzielles Betriebssystem verfügbar sind, einfach nicht das Wasser reichen kann. Sie machen sich zum Narren und Ihre Kunden unglücklich, wenn Sie die richtige Software bei den falschen Leuten installieren. Sie können nur schwer feststellen, ob Sie Gewicht verlieren, weil Sie sich selbst jeden Tag sehen. Wertestarrheit funktioniert genauso. Da wir unsere Karriere jeden Tag leben, ist es leicht, bei den eigenen Karriereentscheidungen eine Werterigidität zu entwickeln. Wir wissen, was funktioniert hat, und tun weiterhin dasselbe. Vielleicht wollten Sie immer ins Management befördert werden und halten deswegen an diesem Ziel fest, egal wie sehr Sie es lieben, einfach nur zu programmieren. Die Technologie Ihrer Wahl kann auch veralten, so dass Sie plötzlich ohne Plattform dastehen. Wie der Frosch in einem Topf Wasser, das langsam erhitzt wird, befinden Sie sich plötzlich in einer unhaltbaren Situation. Mitte der 1990er Jahre war Novell NetWare

308

50 - Die südindische Affenfalle

die Plattform, u m Datei- und Druckdienste in einem Unternehmen zur Verfügung zu stellen. Novell war damals mit seinem DirectoryServices-Produkt seiner Zeit weit voraus; konkurrierende Technologien wurden von Kennern allenfalls belächelt. Das Produkt von Novell dominierte den Markt, und man konnte sich nur schwer vorstellen, dass sich die Gezeiten ändern könnten. Kein einziges Ereignis zeigte deutlich an, dass Novell gegen Microsoft verlor. Microsoft veröffentlichte niemals ein magisches Active Directory Release, bei dem alle staunend gesagt hätten: »Wow! Zeit, NetWare zu vergessen!« Aber der Markt kippte um, und das ehemals technologisch führende NetWare entwickelte sich langsam zu einer

Legacy-Technologie.

Für

viele

NetWare-Administratoren

kochte das Wasser bereits, bevor sie überhaupt erkannten, dass der Topf warm war. Egal, ob es um die Richtung geht, in der sich Ihre Karriere bewegt, oder ob Sie bestimmte Technologien propagieren und Ihre Zeit in sie investieren - achten Sie immer auf Affenfallen. Ihre ursprünglich gezielt getroffene Entscheidung könnte Ihre letzte Hand voll Reis sein, die Sie ergreifen, bevor Ihre Karriere zu Tode geprügelt wird.

Umsetzung 1.

Suchen Sie Ihre Affenfallen. - An welchen Annahmen halten Sie rigide fest? Welche Werte bestimmen Ihre täglichen Aktionen, ohne dass Ihnen das überhaupt bewusst ist? Legen Sie eine Tabelle mit zwei Spalten, »Karriere« und »Technologie«, an. Listen Sie unter jeder Überschrift die Werte auf, die Sie für unbeugsam wahr halten. Ein Beispiel: Was haben Sie unter »Karriere« immer für eine Ihrer Stärken gehalten? Oder für eine Schwäche? Wie lautet Ihr Karriereziel (»Ich möchte Vorstandsvorsitzender werden!«)? Welche Wege führen zu diesem Ziel? Geben Sie in der Spalte »Technologie« an, was Sie an den Technologien am meisten schätzen, in die zu investieren Sie sich ent-

Umsetzung 250

schieden haben. Was sind die für eine Entscheidung wichtigsten Attribute einer Technologie? Wie erstellen Sie ein skalierbares System? Welches ist die produktivste Umgebung für die Software-Entwicklung? Was sind die besten und schlechtesten Plattformen im Allgemeinen? Wenn Sie das Gefühl haben, Ihre Liste sei ziemlich vollständig, gehen Sie alle Einträge einzeln durch. Kehren Sie im Geiste jede Aussage um. Was wäre, wenn das Gegenteil wahr wäre? Spielen Sie den Advocatus Diaboli. Fordern Sie jede Zusicherung ehrlich heraus. Dies ist eine Liste Ihrer Schwachpunkte oder Verletzlichkeiten. 2. Kenne deinen Feind. - Wählen Sie die Technologie aus, die Sie am meisten hassen, und entwickeln Sie damit ein Projekt. Entwickler neigen dazu, sich konkurrierenden Lagern zuordnen: .NET gegen J2EE oder Unix gegen Windows. Wählen Sie sich ein leichtes Projekt aus und versuchen Sie, in der gehassten Technologie eine großartige Anwendung zu erstellen. Haben Sie sich Java verschrieben, zeigen Sie diesen .NETTypen, wie ein richtiger Entwickler ihre Plattform benutzt! Bestenfalls lernen Sie, dass die gehasste Technologie gar nicht so schlecht ist und man mit ihr tatsächlich guten Code entwickeln kann. Außerdem verfügen Sie über eine (zugegebenermaßen unterentwickelte) neue Fähigkeit, die Sie möglicherweise in der Zukunft zu Ihrem Nutzen einsetzen können. Schlimmstenfalls ist dies für Sie eine Übungssitzung, und Sie können Ihre Argumente besser unterfüttern.

Keine Karriereplanung nach dem Wasserfallmodell

A

m Anfang dieses Jahrtausends fand in der Software-Branche eine anfänglich kleine Rebellion statt. Für eine Gruppe

von Experten für Software-Entwicklung schälte sich ein

Muster heraus, warum Software-Projekte Erfolg hatten oder scheiterten. In einer Branche, in der mehr Software-Projekte scheiterten als Erfolg hatten, glaubten sie, eine Möglichkeit entdeckt zu haben, die Erfolgsquote zu verbessern. Die Gruppe bezeichnete sich selbst als die Agile Alliance. In der Branche herrschte damals die Überzeugung vor, die einzig mögliche Methode,

Software-Projekte zu entwickeln,

bestünde

darin, einem Top-Down-Prozess zu folgen, der rigoros geplant und kontrolliert wurde. Danach würden Analysten die Anforderungen in umfangreichen Dokumenten festlegen, Architekten würden daraus Architekturen ableiten. Dies würde an Designer weitergegeben, die daraus detaillierte Designs schufen. Diese Designs würden dann an Entwickler

weitergereicht,

die

Designs

in

Programmcode

in

irgendeiner Programmiersprache umsetzten. Schließlich würde der Code nach Monaten (und manchmal Jahren) der Anstrengung integriert und an eine Testgruppe weitergegeben werden, die verifizieren sollte, dass die Anwendung zur Auslieferung bereit wäre.

312 ]

5 1 ~ Keine Karriereplanung nach dem Wasserfallmodell

Manchmal funktionierte eine Variante dieses Prozesses. Wenn jeder bereits am Anfang des Projekts jedes erforderliche Detail kannte, konnte mit dieser Art der strengen Planung eine gute durchdachte, qualitätskontrollierte Software erstellt werden. Doch meistens wissen die Entwickler nicht im Detail, was ein großes Projekt eigentlich alles leisten soll. Je größer und komplexer ein Projekt ist, desto weniger wahrscheinlich können sich die Verantwortlichen jede Funktion so detailgenau vorstellen, um eine Spezifikation zu erstellen. Diese Art von Prozess ist ein Wasserfallprozess. Heutzutage wird diese Bezeichnung fast universell als Synonym für einen schlechten Prozess verwendet. Die Mitglieder der Agile Alliance erkannten, dass der schwergewichtige Prozess, den die meisten Unternehmen damals einsetzten, zwar zu einer getesteten und gründlich dokumentierten Software führte, diese jedoch nicht immer das tat, was die Software-Anwender wollten. Die Rebellion bestand darin, eine Familie agiler Methoden zu entwickeln. Dabei handelte es sich u m Software-Entwicklungsprozesse, die Änderungen erleichtern sollten. Im Vorfeld wurde weniger geplant und designt. Software ist plastisch, deshalb kann es billig sein, sie zu ändern. Die agilen Methoden akzeptierten den Wandel als konstanten Bestandteil der Software-Entwicklung und passten die Prozesse so an, dass Änderungen möglichst billig und leicht durchgeführt werden konnten. Heute hört sich das alles offensichtlich an. Doch damals war die Einführung agiler Prozesse heftig umstritten und wurde heiß diskutiert. Denn in der Theorie ist die Idee einer rigorosen detaillierten Planung offensichtlich richtig. Doch in der Praxis funktioniert sie nicht. A m Anfang meiner Konversion zu den agilen Methoden (insbesondere Extreme Programming) begann ich, alles durch die Linse der agilen Entwicklung zu betrachten. Es zeigte sich, dass die maßgeblichen Kräfte und Motive nicht nur für die Software-Entwicklung, sondern allgemeiner gelten. Wann immer ich ein komplexes Pro-

313

]

51

~

Keine Karriereplanung nach dem Wasserfallmodell

blem lösen musste, war ein interaktiver, änderungsfreundlicher Lösungsansatz für mich weniger stressreich und effizienter. Doch irgendwie brauchte ich sehr lange, u m zu erkennen, dass das komplexeste (stressreichste und wichtigste) Projekt, das ich jemals managen musste, meine Karriere war. Ich hatte meine Karriere vorher wie ein Software-Wasserfallprojekt konzipiert. Und dieselben Probleme, die bei Software-Projekten auftauchten, begannen sich auch bei mir und in meiner Karriere zu zeigen. Ich war auf dem Weg zu einem erfolgreichen Vorstandsmitglied oder Chief Information Officer (Hauptleiter der Datenverarbeitung und Kommunikation). Ich hatte auf diesem Weg ziemlichen Erfolg und war schnell die Stufen vom Programmier-Neuling über den Software-Architekten, den Manager bis zum Projektleiter hochgestiegen und konnte mir leicht vorstellen, auf dieser Karriereleiter weiter nach oben zu steigen. Doch so erfolgreich ich auch gewesen sein mochte, nagte an mir doch immer das Gefühl, dass mir meine Arbeit nicht gefiel. Tatsächlich gefiel mir ein Job umso weniger, je erfolgreicher ich war. Ich tat mir dasselbe an wie die schwergewichtigen Prozesse ihren Kunden: Ich leistete ausgezeichnete Arbeit, mir eine Karriere zu liefern, die ich nicht wollte. Es wollte mir erst nicht in den Kopf, aber die Lösung eines solchen Problems besteht einfach darin, die eigene Karriere zu ändern. Das kann vieles bedeuten. Für mich bedeutete es, mich wieder viel intensiver mit Technologien zu beschäftigen, die überhaupt erst meine Begeisterung für die Branche der Informationstechnologie geweckt hatten. Für andere aus meinem Bekanntenkreis hatte es bedeutet, aus der Systemadministration in die Software-Entwicklung zu gehen, aus einer fremden Branche in die Computer-Programmierung einzusteigen oder sogar den Beruf ganz an den Nagel zu hängen und etwas anderes zu tun, was sie liebten. Wie bei der Software-Entwicklung müssen die Kosten für eine Änderung nicht hoch sein. Sicher, es ist natürlich nicht leicht, sich

314

]

5 1 ~ Keine Karriereplanung nach dem Wasserfallmodell

vom Software-Tester zum Rechtsanwalt zu entwickeln. Aber der Wechsel vom Management zur Programmierung oder umgekehrt ist nicht allzu schwer. Es ist auch nicht schwer, ein anderes Unternehmen zu finden, in dem man arbeiten kann, oder in eine andere Stadt zu ziehen. Und im Gegensatz zu, sagen wir, einen Wolkenkratzer zu bauen, erfordert ein Wechsel der Karriere nicht, dass Sie alles wegwerfen, was Sie bereits getan haben. Im Moment verbringe ich meine Tage damit, in Ruby zu programmieren; aber meine Erfahrungen als Manager oder beim Aufbau eines Offshore-Entwicklungszentrums bleiben relevant und helfen mir bei meiner jetzigen Arbeit. Meine Arbeitgeber und Kunden verstehen und nutzen dies. Wichtig ist, dass Sie erkennen, dass Änderungen in Ihrer Karriere nicht nur möglich, sondern notwendig sind. Als Software-Entwickler würden Sie nie etwas entwickeln wollen, was Ihr Kunde nicht haben möchte. Agile Methoden helfen Ihnen, Derartiges zu vermeiden. Dasselbe gilt für Ihre Karriere. Setzen Sie sich große Ziele, aber führen Sie auf Ihrem Weg dahin laufend Korrekturen durch. Lernen Sie aus der Erfahrung, und ändern Sie Ihre Ziele, während Sie auf dem Weg sind. Schließlich ist ein glücklicher Kunde alles, was wir wollen (insbesondere da wir bei der Planung unserer Karriere unsere eigenen Kunden sind) - nicht eine erfüllte Anforderung.

KAPITEL 39

Besser als gestern

inen Fehler zu beheben, ist (normalerweise) einfach. Etwas ist

E

defekt. Sie wissen, dass es defekt ist, weil jemand den Fehler gemeldet hat. Wenn Sie den Fehler reproduzieren können,

korrigieren Sie ihn einfach, indem Sie die Fehlfunktion beseitigen und verifizieren, dass er nicht mehr reproduzierbar ist. Wenn doch alle Probleme so einfach wären! Doch nicht jedes Problem oder jede Herausforderung lässt sich so leicht lösen. Die meisten wichtigen Herausforderungen im Leben manifestieren sich als große, unüberwindbare, formlose Klumpen eines möglichen Misserfolgs. Dies gilt sowohl für die Software-Ent-

wicklung als auch das Karriere-Management und sogar für den Lebensstil und die Gesundheit. Ein komplexes und mit Fehlern verseuchtes System muss überarbeitet werden. Ihre Karriere stagniert seit längerer Zeit. Da Sie beim Programmieren ständig am Computer sitzen, gerät Ihr Körper immer mehr außer Form. Diese Probleme sind alle viel größer und schwieriger zu beheben als ein Programmfehler. Sie können nicht einfach so korrigiert werden. Sie sind komplex, schwierig zu messen und setzen sich aus vielen kleinen verschiedenen Lösungen zusammen - von denen einige nicht funktionieren!

3

i6

52 - Besser als gestern

Wegen dieser Komplexität lassen wir uns von größeren Problemen leicht demotivieren und wenden unsere Aufmerksamkeit stattdessen Dingen zu, die leichter zu messen und schneller zu beheben sind. Dies ist der Grund, warum wir Dinge aufschieben. Das Aufschieben erzeugt Schuldgefühle. Bei Schuldgefühlen fühlen wir uns noch schlechter. Wenn wir uns noch schlechter fühlen, schieben wir noch mehr auf. Ein Teufelskreis! Wie ich in Kapitel 49, Dieser fette Mann im Spiegel, erwähnte, bemühe ich mich, solange ich mich zurückerinnern kann, in Form zu kommen und zu bleiben. Wenn man schrecklich außer Form ist, ist schon allein das Konzept, »einfach wieder in Form zu kommen«, tatsächlich nicht leicht zu begreifen, geschweige denn, in die Praxis umzusetzen. Und um die Sache noch schwerer zu machen: Wenn Sie daran arbeiten, Ihre Form zu verbessern, können Sie nicht sofort, ja nicht einmal nach einer Woche, erkennen, dass sich überhaupt etwas geändert hat. Tatsächlich könnten Sie den ganzen Tag damit verbringen, in Form zu kommen, und haben eine Woche später möglicherweise immer noch nichts vorzuweisen. Diese Art der Demotivation kann Sie mit voller Wucht anspringen und zur Aufgabe zwingen, bevor Sie überhaupt angefangen haben. Vor Kurzem habe ich mich ernsthaft mit genau diesem Problem auseinandergesetzt: ins Fitnessstudio gehen, besser essen - und alles was dazugehört. Aber selbst wenn ich das Programm ernsthaft durchziehe, sind kaum Ergebnisse zu sehen. Als ich mich kürzlich abends in meiner Demotivation suhlte, postete mein Freund Erik Kastner eine Message auf der Social Messaging Site Twitter. Sie hatte folgenden Text: Helfen Sie mir, meinen $%!' in Form zu bekommen ...fragen Sie mich einmal pro Tag: »War heute besser als gestern?« (Training / Ernährung) - heute: JA! Als ich dies las, erkannte ich, dass dies das Ticket war, um in Form zu kommen. Ich kannte es von den großen Problemen, die ich in

Besser als gestern

317

meinem Leben erfolgreich gelöst hatte. Das Geheimnis besteht darin, sich darauf zu konzentrieren, das, was auch immer man zu verbessern versucht, heute besser zu machen als gestern. Das ist alles. Es ist einfach. Und Erik folgend, ist es möglich, begeistert wirkliche, greifbare Schritte auf ein fernes Ziel hin zu unternehmen. Vor Kurzem habe ich an einer der komplexesten, hässlichsten Rubyon-Rails-Anwendungen gearbeitet, die mir jemals untergekommen sind. Wir hatten sie von einem anderen Entwickler als Beratungsprojekt geerbt. Einige Schlüsselfunktionen mussten noch implementiert und zahlreiche Bugs und Performance-Probleme behoben werden. Der Code war unglaublich chaotisch. Das Unternehmen hatte weder Zeit noch Mittel, das System von Grund auf neu entwickeln zu lassen, obwohl dies der reinste Wegwerf-Code war. Deshalb schleppten wir uns von einer kleinen Korrektur zur nächsten, alles dauerte viel länger als erwartet. A m Anfang schien sich diese Monstrosität einer Codebasis nie auflösen zu wollen. Die Arbeit war ermüdend und freudlos. Doch im Laufe der Zeit liefen die Fehlerkorrekturen schneller und die einst unakzeptable Performance der Anwendung besserte sich merklich. Wie kam es dazu? Wir hatten einfach beschlossen, die Codebasis jeden Tag ein wenig besser als am Tag zuvor zu machen. Manchmal refaktorisierten wir eine lange Methode in mehrere kleine, wohl-benannte Methoden. Manchmal entfernten wir nicht zu dem Objektmodell passende Vererbungshierarchien. Manchmal korrigierten wir einfach einen seit Langem defekten Unit-Test. Aber da wir diese Änderungen schrittweise durchführten, »kosteten« sie uns praktisch nichts. Eine Methode zu refaktorisieren, dauert normalerweise nicht länger, als sich eine weitere Tasse Kaffee zu holen oder mit einem Kollegen über die neuesten Nachrichten zu plaudern. Und kleine Verbesserungen wirken motivierend; denn der Unterschied in diesem einen verbesserten Aspekt ist nach der Änderung sofort sichtbar.

3

i8

52 - Besser als gestern

Doch nicht alle inkrementellen Änderungen sind gleich im Ganzen merklich. Wenn Sie an Ihrem Arbeitsplatz mehr Anerkennung anstreben oder gesünder werden wollen, führen die einzelnen täglichen Verbesserungen oft nicht direkt zu greifbaren Ergebnissen. Wie ich bereits ausgeführt habe, wirken aus diesem Grund die meisten großen, schwierigen Ziele dieser Art so demotivierend. Deshalb ist es bei diesen Zielen wichtig, nicht darüber nachzudenken, ob Sie dem Ziel täglich näher gekommen sind. Sie sollten sich stattdessen bemühen, sich heute ein wenig mehr anzustrengen als gestern. Ich kann beispielsweise nicht dafür garantieren, dass ich heute weniger fett bin als gestern, aber ich kann kontrollieren, ob ich heute mehr für mein Abnehmen tue. Und wenn ich dies tue, darf ich zu Recht mit meinem Handeln zufrieden sein. Diese fortlaufende, messbare Verbesserung meiner Aktionen befreit mich von dem Zyklus aus Schuld und Aufschieberei, vor dem die meisten letztlich kapitulieren, wenn sie versuchen, »Große Wichtige Dinge« zu erreichen. Sie müssen auch über kleine Mengen »besser« glücklich sein. Einen Test mehr zu schreiben als gestern, bringt Sie dem Ziel näher, »sich beim Unit-Testing zu verbessern«. Wenn Sie bei null begonnen haben, ist ein zusätzlicher Test pro Tag eine dauerhaft erreichbare Rate. Und wenn Sie nicht mehr besser als gestern sein können, werden Sie feststellen, dass Sie »sich jetzt beim Unit-Testing verbessert haben«. Dann ist es nicht mehr erforderlich, dieselben Verbesserungen zu erzielen. Wenn Sie dagegen beschlossen haben, am ersten Tag Ihres Verbesserungsplans von null auf 50 Tests zu gehen, wäre der erste Tag sehr schwierig, und zu einem zweiten Tag würde es wahrscheinlich nie kommen. Beschränken Sie sich deshalb auf kleine und inkrementelle, aber konsequent täglich durchgeführte Verbesserungen. Kleine Verbesserungen verringern auch die Kosten des Misserfolgs. Wenn Sie einen Tag verpassen, haben Sie für morgen einfach eine neue Ausgangslinie.

Umsetzung 250

Diese einfache Maxime hat einen weiteren großartigen Aspekt: Sie können sie sowohl auf taktische (kurzfristige) Ziele, wie etwa die Beendigung eines Projekts oder die Bereinigung einer SoftwareKomponente, als auch auf langfristige, allgemeine und sehr hohe Ziele anwenden. Haben Sie heute bessere Maßnahmen ergriffen, um Ihre Karriere zu verbessern, als gestern? Stellen Sie einen weiteren Kontakt her, reichen Sie ein Patch bei einem Open-Source-Projekt ein, schreiben Sie einen einsichtsvollen Post und veröffentlichen Sie ihn in Ihrem Weblog. Helfen Sie in einem technischen Forum Ihres Fachgebiets einer Person mehr als gestern. Wenn Sie jeden Tag nur ein wenig besser daran arbeiten, sich selbst zu verbessern, als gestern, werden Sie feststellen, dass das andernfalls überwältigend riesige Vorhaben, eine bemerkenswerte Karriere aufzubauen, greifbarer wird.

Umsetzung i. Erstellen Sie eine Liste mit schwierigen oder komplexen Verbesserungen, die Sie gerne realisieren möchten. Sie können persönliche oder berufliche Aufgaben wählen. Es ist in Ordnung, wenn diese Liste ziemlich lang ist. Denken Sie jetzt bei jedem Punkt auf dieser Liste darüber nach, was Sie heute tun könnten, um sich oder diesen Eintrag besser als gestern zu machen. Schauen Sie sich morgen diese Liste erneut an. War gestern besser als der Tag zuvor? Wie können Sie es heute besser machen? Machen Sie dasselbe am nächsten Tag. Tragen Sie diese Übung in Ihren Kalender ein. Denken Sie jeden Morgen zwei Minuten darüber nach.

Sich selbstständig machen

n stressreichen Zeiten denke ich gerne an meine Tage in einem Großunternehmen zurück. Ich war in ein Büro oder Kubikel und eine dicke, flauschige, vielschichtige Managementhierarchie eingebettet. Wir machten damals unsere Witze darüber, dass sich eine gerissene Person in einem großen Unternehmen durchmogeln könnte, ohne überhaupt irgendetwas zu erledigen. Wenn ein Projekt nicht fertig wurde, gab es in den meisten Fällen genügend andere Leute in genügend anderen Schichten der Hierarchie, auf die die Schuld verteilt werden konnte. Kaum jemand konnte deshalb feststellen, wo die Dinge schiefgegangen waren. Und das galt nicht nur für Misserfolge. Brauchten Dinge länger, als notwendig gewesen wäre, vernebelte die Komplexität der Organisation die Gründe so weit, dass niemand wirklich eine Ahnung hatte, wie lange ein Projekt wirklich hätte dauern dürfen. Deshalb können Sie sich in einem Job in einem großen Unternehmen an Tagen, an denen Sie wirklich keine Lust haben, Gas zu geben, zurücklehnen und beispielsweise eine Weile im Web surfen. Oder früher nach Hause gehen. Oder einen Tag krankfeiern. Wenn ich auch viel am Leben in einem Großunternehmen auszusetzen habe, so hat es doch definitiv seine Vorteile.

322

53 - Sich selbstständig machen

Das Problem ist, dass Sie durch das Sicherheitsnetz der Unternehmenshierarchie gebremst werden. Wenn Sie sich unter dem Schutzmantel der Mittelmäßigkeit verbergen können, mit dem sich die meisten Geschäftsbereiche eines Unternehmens umgeben, haben Sie kaum einen Anreiz, Herausragendes zu leisten. Selbst im Allgemeinen wohl meinende Menschen erliegen der Verlockung einer erholsamen Rast in der Oase von YouTube oder auf den Websites ihrer Lieblings-Comics. (Wenn Sie zufällig nach einer solchen Website suchen, probieren Sie es mit http://toothpastefordinner.com; ich habe mich dort schon viele Stunden köstlich amüsiert.) Als selbstständiger Auftragnehmer müssen Sie lernen, sich zu vermarkten. Ihre Entscheidungen für einen bestimmten Geschäftsbereich oder eine Technologie müssen sich ständig im Markt bewähren. In einem Großunternehmen findet die Arbeit irgendwie den Weg zu Ihnen. Doch wenn Sie selbstständig sind, laufen Ihnen die Kunden nicht automatisch zu. Sie müssen sie aktiv suchen. Und nachdem Sie sie gefunden haben, müssen Sie sie auch noch davon überzeugen, dass es sich für sie lohnt, Sie zu bezahlen. Sie müssen auch entscheiden, wie Sie den Wert Ihrer Arbeit einschätzen. Ist das, was Sie tun, 50 € pro Stunde wert? Oder kostet es 250 €? Wie wollen Sie Ihre Rechnungen bezahlen? Wie können Sie das Geld rechtfertigen, das Sie Ihrer Meinung nach wert sind? Sind Sie überhaupt wirklich so viel wert, wie Sie meinen? Sich selbstständig zu machen, ist schwer. Ihre gesamten Fähigkeiten als Profi werden einem Praxistest unterzogen. Vielleicht sind Sie noch nicht dazu bereit. Die gute Nachricht ist: Es ist keine Allesoder-nichts-Entscheidung. Sie können es als persönliches Entwicklungsprojekt angehen und sich Ihren Markt in Ihrer Freizeit suchen. Setzen Sie sich das Ziel, einen Vertrag zu bestimmten Konditionen abzuschließen und Ihren ersten glücklichen Kunden zu gewinnen. Arbeiten Sie abends oder an Wochenenden. (Doch bitte arbeiten Sie nicht tagsüber in Ihrem Kubikel an Ihrem Arbeitsplatz an diesem Auftrag!) Sie werden viel lernen, ohne Ihr Sicherheits-

32453-Sich selbstständig machen

netz zu verlieren. Schlimmstenfalls überarbeiten Sie sich für einige Wochen, scheitern bei einem Projekt und kehren mit einem neuen Gefühl der Wertschätzung für Ihren sicheren Arbeitsplatz in Ihr komfortables Kubikel zurück. Bestenfalls haben Sie einen riesigen Erfolg, lieben die Arbeit und begeben sich auf einen Abschnitt Ihres Weges zu einer befriedigenden Karriere und finanziellem Erfolg. Mein Rezensent Sammy Larbi schlägt eine andere Alternative vor, sich selbstständig zu machen. Wenn Sie gegenwärtig für ein großes Unternehmen arbeiten, sollten Sie erwägen, bei einem kleineren zu arbeiten. Wenn Sie für ein anerkanntes Unternehmen arbeiten, sollten Sie ein Startup ausprobieren. In einem kleinen Startup können Sie das Beste aus beiden Welten bekommen: einen Vollzeitjob mit Gehalt und die Herausforderung, direkt mit den ungefilterten Problemen Ihres Geschäftsfeldes zu kämpfen.

Neugier ist eine Stärke von Mike Clark Meine Eltern würden Ihnen sagen, dass ich ein neugieriges Kind war. Ich stellte zahlreiche Fragen, las alles, was mir in die Finger kam, und lernte, wie die Dinge funktionierten, indem ich sie auseinandernahm. Wie sich zeigte, war dies nicht nur eine Entwicklungsphase - ich bin nie aus dieser unstillbaren Neugier herausgewachsen. Es ist leicht zu übersehen, aber ich glaube, Neugier kann eine Stärke sein. Manchmal muss man nur ein wenig üben, u m sie zu entwickeln. Rückblickend kann ich mehrere Ereignisse identifizieren, die meiner Karriere hauptsächlich deswegen eine andere Richtung gaben, weil ich meiner Neugier folgte. Mit den folgenden Beispielen hoffe ich, Sie dazu zu ermutigen, mehr auf Ihre eigene Neugier zu hören:

324

53 - Sich selbstständig machen

Ich hätte nie gedacht, Programmierer zu werden. Ich war immer von Flugzeugen und Raumschiffen fasziniert. Deswegen schien mir ein Studium als Luftfahrtingenieur an der Embry-Riddle Aeronautical University die logische Entscheidung zu sein. Doch nach etwa einem Jahr angestrengter Arbeit entdeckte ich, dass die Leute in der Informatik-Abteilung sehr viel mehr Spaß hatten. Im Zuge eines neu geschaffenen

Studiengangs

wendeten

sie

die

Informatik

auf

Probleme der Luftfahrttechnik an. Meine Neugier für Computer war in der High School geweckt worden, aber ich hatte eine Karriere als Programmierer niemals wirklich in Erwägung gezogen. Deswegen verbrachte ich meine Zeit zunehmend mit den Computer-Geeks. Ich wollte wissen, was sie eigentlich machten. Es dauerte nicht lange, bis ich meinen Studiengang wechselte, im Nachhinein eine meiner besten Entscheidungen überhaupt. Die Kurse waren immer noch anspruchsvoll, aber ich liebte jede Minute. Aus meiner anfänglichen Neugier wurde schnell eine Leidenschaft für das Programmieren. Sie führte mich dazu, mich um ein Praktikum bei der NASA zu bewerben und kopfüber in meine Software-Karriere zu springen. Und bis heute unterschätze ich niemals den potenziellen Nutzen, herauszufinden, woran meine Mit-Geeks aus Liebe zur Sache arbeiten. Wann immer es irgendwo bequem wird und ich mit einer Sache sehr vertraut werde (was für mich immer auch mit Langeweile verbunden ist), weiß ich, dass es Zeit ist, etwas Neues zu probieren. Nachdem ich viele Jahre lang eingebettete Software in der Raumfahrtindustrie geschrieben hatte, war ich mit C und C++ sehr vertraut. Etwa zu der Zeit weckte die Web-Programmierung meine Neugier, und zwar hauptsächlich deswegen, weil sie sich von der Programmierung ein-

32653-Sich selbstständig machen

gebetteter Systeme radikal unterschied. Leider hatte das Projekt, an dem wir tagsüber arbeiteten, keinen Zugriff auf das Web (es war supergeheim). Deshalb lernte ich an meinen Abenden und Wochenenden, Software für das Web zu schreiben. Aus dieser Hackerei in meiner Freizeit ergab sich irgendwann eine Gelegenheit, an einem neuen Java-Projekt zu arbeiten. Das führte letztlich dazu, dass ich webbasierte Java-Anwendungen für viele weitere Projekte ... und Arbeitgeber entwickelte. Meine Neugier für die Web-Entwicklung war der Katalysator, meine Fähigkeiten zu diversifizieren, was sich letztlich als gute Wendung meiner Karriere herausstellte. Ich lernte Ruby und Rails aus einer Laune heraus. In Ruby zu programmieren, machte Spaß und vermittelte mir eine neue Art und Weise, über das Programmieren zu denken. Rails leistete dasselbe für Web-Anwendungen. Ich hatte damals keine Kunden, die mich für Arbeit in Ruby oder Rails bezahlten, aber das war nicht wirklich wichtig. Ich war neugierig und konnte einfach nicht anders. Ich arbeitete einige Stunden weniger für Geld und setzte mich in dieser Zeit lieber intensiv mit Ruby und Rails auseinander. Damals wusste ich noch nicht, dass ich Anfang 2005 die Gelegenheit erhalten würde, eine der ersten kommerziellen Rails-Anwendungen zu erstellen, und von Dave Thomas eingeladen werden würde, ihm bei seinem Rails-Buch zu helfen. Wieder hatte meine Neugier über eine neue Technologie einen weiteren erfolgreichen Abschnitt meiner Karriere eingeleitet. Doch Technologien sind nicht alles. Die geschäftlichen Aspekte sind für mich ebenfalls interessant. Deshalb machte ich mich als Berater selbstständig und gründete ein Schulungsunternehmen (The Pragmatic Studio). Neugierig, was zur

326

53 - Sich selbstständig machen

Leitung eines Kleinunternehmens erforderlich ist, erwarb ich zahlreiche neue Fähigkeiten: Verkauf, Marketing, Kundendienst usw. Das große Ganze zu sehen hat mir geholfen, ein besserer Programmierer zu werden. Also: Worauf sind Sie wirklich neugierig? Versuchen Sie, sich eine Weile lang von Ihren Interessen leiten zu lassen. Wer weiß, wo Sie landen? Mike Clark ist selbstständiger

Berater/Programmierer.

Genießen Sie es!

ber ich sage dir: Wenn du mit aller Kraft an der Erfüllung des

A

tiefsten Traums der Erde arbeitest, der dir zugeteilt wurde, als er

geboren wurde, dann empfindest du echte Liebe zum Leben; und

das Leben durch Arbeit zu lieben, heißt, in sein innerstes Geheimnis ein-

geweiht zu sein. Kahlil Gibran, Der Prophet Wenn Sie als Software-Entwickler so weit gekommen sind, dass Sie sich den Luxus leisten können, tatsächlich über die weitere Richtung Ihrer Karriere nachzudenken, meinen Glückwunsch! Sie dürfen sich sehr glücklich schätzen. Es gibt viele Kulturen, in denen die Möglichkeit, zu entscheiden, womit man seinen Lebensunterhalt verdienen möchte, ein großes, nur wenigen Leuten vorbehaltenes Privileg ist. Als Software-Entwickler müssen Sie sich wahrscheinlich keine Sorgen um Ihr Geld für Wohnung und Nahrung machen. Sie hätten auch eine von vielen anderen Karrieren wählen können, aber diese ist aufregend. Sie ist kreativ. Sie erfordert tiefes Nachdenken und belohnt Sie mit dem Gefühl, etwas tun zu können, das sich die meisten Leute, denen Sie tagtäglich begegnen, nicht einmal vorstellen können. Vielleicht sorgen wir uns um unseren nächsten Karriereschritt, unseren Einfluss, die Anerkennung am Arbeitsplatz

328

54 - Genießen Sie es!

oder in der Branche, doch nüchtern betrachtet, haben wir es wirklich gut getroffen. Software-Entwicklung ist sowohl herausfordernd als auch belohnend. Sie ist kreativ wie eine Kunstform, aber (im Gegensatz zu Kunst) bringt sie einen konkreten, messbaren Mehrwert hervor. Software-Entwicklung macht Spaß! Die wichtigste Lektion aus meiner Karriere als Software-Entwickler lautet letztlich: Nicht, womit Sie Ihren Lebensunterhalt verdienen oder was Sie haben, ist wichtig. Wichtig ist, wie Sie diese Dinge akzeptieren. Ihre innere Einstellung ist maßgebend. Ähnlich wie die richtige Karriere müssen Sie Befriedigung suchen und sich absichtlich für sie entscheiden.

Quellen

•

[Becoo] Kent Beck. Extreme Programming

Explained:

Embrace

Change. Addison-Wesley, Reading, MA, 2 0 0 0 . (Extreme Programming, Addison-Wesley, 2003) •

[C0U96] Douglas Coupland. Microserfs. Regan Books, New York, 1 9 9 6 . (Mikrosklaven, Hoffmann und Campe, 1996)

•

[DL99] Tom Demarco und Timothy Lister. Peopleware: Productive Projects and Teams. Dorset House, New York, 2. Auflage, 1 9 9 9 . (Wien wartet auf Dich!, Hanser, 1999)

•

[GHJV95] Erich Gamma, Richard Helm, Ralph Johnson und John Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, Reading, MA, 1995. (Entwurfsmuster:

Elemente

wiederverwendbarer

objektorientierter

Software,

Addison-Wesley, 2009) •

[Godc>3] Seth Godin. Purple Cow: Transform Your Business by Being Remarkable. Portfolio, 2003. (Purple Cow. So infizieren Sie Ihre Zielgruppe durch Virales Marketing, Campus, 2004)

•

[Hamo2] Gary Hamel. Leading the Revolution: How to Thrive in Turbulent Times by Making Innovation a Way of Life. Reprint 2 0 0 2 . (Wettlauf um die Zukunft, Ueberreuter Wirtschaft, 1997)

33° •

Quellen

[Han99] Thich Nhat Hanh. The Miracle of Mindfulness. Beacon Press, 1 9 9 9 . (Das Wunder der Achtsamkeit, Theseus, 2006)

•

[HToo] Andrew Hunt und David Thomas. The Pragmatic Programmer: From Journeyman to Master. Addison-Wesley, Reading, MA, 2 0 0 0 . (Der Pragmatische Programmierer, Hanser, 2003)

•

[Piroo] Robert M. Pirsig. Zen and the Art of Motorcycle Maintenance: An Inquiry into Values. Perennial Classics, Nachdruck, 2 0 0 0 . (Zen und die Kunst ein Motorrad zu warten: Ein Versuch über Werte, Fischer Taschenbuch, 29. Auflage, 2006)

•

[SÜ99] Steven A. Silbiger. The Ten-DayMBA:

A

Step-By-Step

Guide To Mastering The Skills Taught In America's Top Business Schools. Quill, 1 9 9 9 .

Danksagungen

ur Dave Thomas und Andy Hunt konnten mich dazu bringen, ein Buch zu schreiben. Ihr Buch The Pragmatic Programmer [HToo] diente für mich als Katalysator, der meine Arbeit inspiriert hat, seit ich es zum ersten Mal gelesen hatte. Ohne die Ermutigung und Anleitung von Dave hätte ich mir nicht zugetraut, dieses Buch zu schreiben. Susannah Pfalzer lektorierte die zweite Auflage des Buches. Doch sie tat viel mehr. Sie inspirierte mich, trieb mich an, ermutigte mich und hielt mich durch ihre Geduld und ihre Fähigkeit, im richtigen Moment genau das Richtige zu sagen, um mich zu motivieren, auf Kurs. Ohne Susannah wäre das Buch immer noch eine chaotische Sammlung halb ausgegorener Ideen. David Heinemeier Hansson schrieb das Vorwort. Seine Karriere als Partner von 37signals und als Schöpfer von Rails ist ein glänzendes Beispiel für die Ideen dieses Buches. Ich hatte auch das Glück, Beiträge von bemerkenswerten Leuten zu bekommen, die ich während meiner beruflichen Laufbahn kennen gelernt habe. Ich danke Stephen Akers, James Duncan Davidson, Vik Chadha, Mike Clark, Patrick Collison und Tom Preston-Werner dafür, dass sie mich und die Leser meines Buches inspiriert haben.

N

Mehrere Kritiker lieferten mir ein ausgezeichnetes Feedback zu den Entwürfen der zweiten Auflage. Es ist immer wieder überraschend, wie falsch die erste Version eines Kapitels sein kann und wie sie durch eine gute Rezension verbessert werden kann. Mein Dank gilt Sammy Larbi, Bryan Dyck, Bob Martin, Kent Beck, Alan Francis, Jared Richardson, Rieh Downie und Erik Kastner. Juliet Thomas lektorierte die frühen Entwürfe der ersten Auflage dieses Buches. Ihre Begeisterung und Perspektive vermittelten mir wesentliche Einsichten. Und die Kritiker der ersten Auflage lieferten mir erstaunlich viel Feedback: Carey Boaz, Karl Brophey, Brandon Campbell, Vik Chadha, Mauro Cicio, Mark Donoghue, Pat Eyler, Ben Goodwin, Jacob Harris, Adam Keys, Steve Morris,

332

Danksagungen

Bill Nall, Wesley Reiz, Avik Sengupta, Kent Spillner, Sandesh Tattitali, Craig Utley, Greg Vaughn und Peter W. A. Wood. Durch ihre Anregungen ist dieses Buch viel besser geworden, und ich kann ihnen gar nicht genug für ihre Zeit, ihre Energie und ihre Einsichten danken. Die Ideen in diesem Buch gehen auf die Anregungen vieler Leute zurück, mit denen ich im Laufe der Jahre offiziell und inoffiziell zusammengearbeitet habe. Sie hörten mir zu, sie lehrten mich oder standen mir für Gespräche zur Verfügung. Mein Dank gilt Donnie Webb, Ken Smith, Walter Hoehn, James McMurry, Carey Boaz, David Alan Black, Mike Clark, Nicole Clark, Vik Chadha, Avi Bryant, Rieh Kilmer, Steve Akers, Mark Gardener, Ryan Ownens, Tom Copeland, Dave Craine, John Athayde, Marcel Molina, Erik Kastner, Bruce Williams, David Heinemeier Hansson, Ali Sareea und Jim Weirich. Dank auch an meine Eltern für ihre dauerhafte Unterstützung. Und am wichtigsten natürlich: Dank an meine Frau Kelly, ohne die sich das Ganze nicht gelohnt hätte.

Frederick P. Brooks

Vom Mythos des Mann-Monats Essays über Software-Engineering

Nur wenige Bücher über das Projektmanagement bei Software haben sich als so einflussreich und zeitlos gültig erwiesen wie Der Mythos vom MannMonat: Fred Brooks bietet hier mit einem Mix aus harten Fakten und provokanten Ideen jedem tiefe Einsichten, der komplexe Projekte zu managen hat. Die Essays in diesem Buch stellen die Quintessenz seiner Erfahrungen als Projektmanager erst für die Hardware der IBM/360-Computerfamilie, dann als Leiter der Entwicklung des - wahrhaft gigantischen - Betriebssystems OS/360 dar. Brooks hat nun, 20 Jahre nach Erscheinen des Originals, seine ursprünglichen Vorstellungen und Visionen noch einmal überdacht, sie um neue Erkenntnisse und Ratschläge bereichert. Dieses Buch ist ein Muss sowohl für Kenner seiner Arbeiten als auch Leser, die Brooks nun zum ersten Mal entdecken. Die zusätzlichen Kapitel enthalten erstens eine auf den Punkt gebrachte Zusammenfassung aller Gedanken und Beweisführungen des Originals, inklusive

Probekapitel und Infos erhalten Sie unter:

www.it-fachportal.de/1355

des Brooks'schen Gesetzes:"Das Hinzufügen von Arbeitskräften zu einem verspäteten Projekt erhöht die Verspätung." Zweitens finden Sie hier eine kritische Würdigung seiner Argumentationen im Licht von 20 Jahren Weiterentwicklung nicht nur auf dem Gebiet des Software Engineerings. Drittens enthält dieses Buch einen Reprint des zum Klassiker gewordenen, 1986 veröffentlichten Papiers: „Keine Silberkugeln" und schließlich die Antwort auf die Frage, was aus der 1986 aufgestellten Behauptung geworden ist, dass es „auch in den nächsten 10 Jahren keine Silberkugeln geben wird". Frederick P. Brooks ist der Träger des A.M. Turing Award der ACM im Jahre 1999 - der Auszeichnung mit dem höchsten Prestige, die es im Computerbereich gibt. Er erhielt diesen Preis insbesondere für seine „bahnbrechenden Beiträge zur Architektur von Computern, Betriebssysteme und auf dem Gebiet des Software Engineering".

ISBN 978-3-8266-1355-5

Martin Fowler

Patterns für Enterprise Application-Architekturen

Mit Beiträgen von: David Rice Matthew Foemmel Edward Hieatt Robert Mee Randy Stafford

Durch neue Technologien wurde die Erstellungvon Unternehmensanwendungen revolutioniert. Plattformen wie Java oder .NET haben sich dabei etabliert. Mit Hilfe dieser neuen Technologien sind Sie zwar in der Lage, mächtige Applikationen zu entwickeln diese sind aber häufig nur sehr schwierig zu implementieren. Viele Enterprise-Applikationen sind fehlerhaft, weil der dahinter stehenden Architektur nicht genügend Aufmerksamkeit gewidmet wurde.

Patterns für Enterprise

Application-Architekturen

ist exakt aus diesem Grund geschrieben worden. Der Herausgeber Martin fowler, eine Koryphäe des objektorientierten Designs, stellte fest, dass trotz des rasanten Wandels in der IT-Technologie - von Smalltalk zu CORBA zu Java zu .NET-dieselben fundamentalen Design-Prinzipien angewandt werden können. Mit der Unterstützung vieler erfahrener Experten arbeitete Fowler mehr als 40 wiederver-

Probekapitel und Infos erhalten Sie unter:

www.it-fachportal.de/1355

wendbare Lösungen in Patterns ein, die plattformunabhängig zur Erstellung von Unternehmensanwendungen genutzt werden können. Dieses beeindruckende Handbuch beinhaltet eigentlich zwei Bücher: Der erste Teil bietet dem Leser ein Tutorial zur Entwicklung von Unternehmensanwendungen. Im zweiten Teil finden Sie eine umfassende Referenz der behandelten Patterns. Zu jedem Pattern gibt es exakte Informationen bezüglich des Einsatzes und der Implementierung, sowie detaillierten Code in Java und C#. Zahlreiche erläuternde UML-Diagramme veranschaulichen den jeweiligen Lösungsweg. Dieses Buch vermittelt Ihnen das Wissen, welches Sie brauchen, um die passenden architektonischen Grundentscheidungen für eine Enterprise-Applikation zu treffen und das richtige, bewahrte Pattern einzusetzen.

ISBN 978-3-8266-1378-4

Sebastian Kübeck

Software Sanierung Weiterentwicklung, Testen und Refactoring bestehender Software Weiterentwickeln bestehender Systeme ohne vorhandene Tests Bestehenden Code mit Tests absichern Maßnahmen zur Verbesserung der Qualität

Es erscheint möglicherweise seltsam, den Begriff »Sanierung« in Zusammenhang mit Software zu verwenden. Es gibt in der Softwareentwicklung jedoch ein Phänomen, das dem physischen Verschleiß in seiner Auswirkung nahekommt: Mit zunehmendem Alter wird es immer schwieriger und teurer, Software an geänderte Gegebenheiten anzupassen. Früher oder später führt kein Weg an einer Sanierung Ihres Bestandssystems vorbei - sofern keine ausreichende automatisierte Testabdeckung dafür vorhanden ist. Mit den in diesem Buch beschriebenen Techniken können Sie die geforderte Testabdeckung nachziehen und den Code so weit verbessern, dass Sie diese ständigen Veränderungen auch längerfristig durchhalten können. Die beschriebenen Methoden haben nachweislich in vielen Projekten Verbesserungen in Bezug auf die Qualität und Produktivität der Entwicklung gebracht. Sie sind mit etwas Übung leicht zu erlernen, so dass sie auch von weniger erfahrenen Entwicklern angewendet werden können. Dieses Buch ist vor allem für Praktiker geschrieben, so dass der Autor besonderes Augenmerk auf aussagekräftige Beispiele legt. Die Beispiele sind in

Probekapitel und Infos erhalten Sie unter:

www.it-fachportal.de/1355

Java implementiert, so dass Programmierkenntnisse in Java vorausgesetzt werden.

Testen Sie, ob Ihre Software sanierungsbedürftig ist: 1. Treten häufig Fehler auf und ziehen Maßnahmen zur Fehlerbehebung öfter Folgefehler nach sich? 2. Verbringen Programmierer viel Zeit mit der Fehlersuche? 3. Ist der Quellcode für Programmierer schwer verständlich? 4. Sind Änderungen umständlich umzusetzen und treten dabei häufig Fehler auf? 5. Haben Sie keine automatisierten Tests oder eine geringe Testabdeckung? 6. Setzen Sie selten oder nie Refactoring ein, um die Software an neue Gegebenheiten anzupassen? Wenn Sie mindestens eine dieser Fragen mit »Ja« beantworten müssen, ist Ihre Software wahrscheinlich sanierungsbedürftig. Dann sollten Sie unbedingt mit den im Buch beschriebenen Techniken die Qualität Ihrer Software verbessern, um langfristig produktiver arbeiten zu können.

ISBN 978-3-8266-5072-7

Robert C. Martin

Clean Code Refactoring, Patterns, Testen und Techniken für sauberen Code

Kommentare, Formatierung, Strukturierung Fehler-Handling und Unit-Tests Zahlreiche Fallstudien, Best Practices, Heuristiken und Code Smells Selbst schlechter Code kann funktionieren. Aber w e n n der Code nicht sauber ist, kann er ein Entwicklungsunternehmen in die Knie zwingen. Jedes Jahr gehen unzählige Stunden und beträchtliche Ressourcen verloren, weil Code schlecht geschrieben ist. Aber das muss nicht sein. Mit Clean Code präsentiert Ihnen der bekannte Software-Experte Robert C. Martin ein revolutionäres Paradigma, mit dem er Ihnen aufzeigt, w i e Sie guten Code schreiben und schlechten Code überarbeiten. Zusammen mit seinen Kollegen von Object Mentor destilliert er die besten Praktiken der agilen Entwicklung von sauberem Code zu einem einzigartigen Buch. So können Sie sich die Erfahrungswerte der Meister der Software-Entwicklung aneignen, die aus Ihnen einen besseren Programmierer machen werden - anhand konkreter Fallstudien, die im Buch detailliert durchgearbeitet werden. Sie werden in diesem Buch sehr viel Code lesen. Und Sie werden aufgefordert, darüber nachzudenken, was an diesem Code richtig und falsch ist. Noch wichtiger: Sie werden Probekapitel und Infos erhalten Sie unter:

www.it-fachportal.de/1355

herausgefordert, Ihre professionellen Werte und Ihre Einstellung zu Ihrem Beruf zu überprüfen. Clean Code besteht aus drei Teilen: Der erste Teil beschreibt die Prinzipien, Patterns und Techniken, die zum Schreiben von sauberem Code benötigt werden. Der zweite Teil besteht aus mehreren, zunehmend komplexeren Fallstudien. An jeder Fallstudie wird aufgezeigt, wie Code gesäubert wird - wie eine mit Problemen behaftete Code-Basis in eine solide und effiziente Form umgewandelt wird. Der dritte Teil enthält den Ertrag und den Lohn der praktischen Arbeit: ein umfangreiches Kapitel mit Best Practices, Heuristiken und Code Smells, die bei der Erstellung der Fallstudien zusammengetragen wurden. Das Ergebnis ist eine Wissensbasis, die beschreibt, w i e wir denken, wenn wir Code schreiben, lesen und säubern. Dieses Buch ist ein Muss für alle Entwickler, Software-Ingenieure, Projektmanager, TeamLeiter oder Systemanalytiker, die daran interessiert sind, besseren Code zu produzieren.

ISBN 978-3-8266-5548-7

mitp Dieses Buch ist ein inspirierender Wegweiser für Programmierer und Softwareentwickler. Chad Fowler zeig! Ihnen, wie Sie sich nachhaltig persönlich weiterentwickeln können, um Ihre eigene berufliche Laufbahn erfolgreich zu gestalten und Schritt für Schritt Ihre eigenen Ziele zu verfolgen und zu realisieren. Wenn die Softwareentwicklung für Sie eine Leidenschaft ist, dann werden Sie mit diesem Buch lernen, wie es Ihnen gelingt, Ihre Fähigkeiten bestmöglich zu entfalten und in Ihrer beruflichen Laufbahn Anerkennung und Erfolg zu erlangen. Chad Fowler berichtet aus eigener Erfahrung, worauf es im Beruf ankommt, und macht Ihnen deutlich, dass Sie Ihre berufliche Entwicklung nicht dem Zufall überlassen, sondern selbst in die Hand nehmen sollten. Dies erfordert Nachdenken, Handeln und die Bereitschaft, einen eingeschlagenen Weg zu ändern. Wählen Sie den Markt und die Technologien, mit denen Sie sich beschäftigen, gezielt und bewusst aus. Investieren Sie in Ihre eigenen Fähigkeiten. Lernen Sie, wie Sie Ihre Fähigkeiten wie ein Produkt behandeln und vermarkten müssen, um damit erfolgreich zu sein. Sie werden erfahren, wie Sie Ihre Situation selber positiv beeinflussen und verbessern können. Chad Fowler gibt Ihnen praktische Anleitungen und für jeden umsetzbare Methoden an die Hand und erläutert Ihnen die notwendigen Schritte, die für Sie wichtig sind, um die eigenen Wünsche und Fähigkeiten zu erkennen, weiterzuentwickeln und diese auch gut verkaufen zu können. Beispielhafte Laufbahnen erfolgreicher Softwareentwickler zeigen Ihnen, wie es andere geschafft haben. Mit diesem Buch kann jeder seine persönliche Entwicklung ganz individuell gestalten. Es wird Ihr Leben, Ihre Einstellungen und Ihre Motivation positiv verändern! Und Sie werden Erfolg damit haben! Chad Fowler ist ein international bekannter Softwareentwickler, Trainer, Manager und Redner. Er arbeitet als CTO bei InfoEhter, Inc. Er ist darüber hinaus Mitorganisator der Konferenzen RubyConf, RailsConf und RailsConf Europe sowie Autor zahlreicher Bücher. „Das Großartige an diesem Buch ist, dass es zahlreiche Handlungsanweisungen enthält - Dinge, die ich tun kann. Es macht deutlich, dass die Verantwortung für meine Situation dort liegt, wo sie hingehört - bei mir. Dieses Buch arbeitet heraus, was ich heute tun kann. Und morgen. Und im Rest meiner beruflichen Laufbahn." Kent Beck, Programmierer „Knapp sechs Monate, bevor ich dieses Buch las, stand ich kurz davor, meinen Beruf zu wechseln. Mehrere Zufälle brachten mich dazu, nicht nur bei der Softwareentwicklung zu bleiben, sondern aus ihr eine Leidenschaft zu machen, die ich wirklich meistern wollte. Dabei diente mir dieses Buch mit seiner gesunden Prise Inspiration als Wegweiser zu meinen Zielen." Sammy labri, Chief Spaghetti Coder

ISBN 978-3-8266-13SS-5

Probekapitel und Infos e r M e n Sie unter: info@!t-fachpor«al.de www.it-fachportal.de

IDI €

19,95