MacBook Meets Schneewittchen

0

Zu kaufen bei Etsy, gefunden durch Terry Chay. Wer Schneewittchen nicht mag, findet über die Google Produktsuche oder bei Etsy noch eine Menge andere.

Verbotene Wörter

3

Vor kurzem hat mir Frank von einem Team erzählt, in dem man auf Fragen nur mit drei Antworten reagieren darf: „Ja.”, „Nein.” und „Ich weiß nicht.”. Sätze wie „Das sollte so funktionieren.” oder „Wenn alles glatt geht, müsste das klappen.” sind in diesem Team verboten.

Das wollte ich mal zum Anlass nehmen, eine Liste von Wörtern und Redewendungen aufzustellen, die ich (zumindest im Berufsleben) nicht mehr hören möchte, besonders wenn es um Aufwand, Lösungen oder Termine geht.

sollten”, „müssten”, etc.

Der Konjunktiv ist der Feind einer jeden Projektplanung. Meistens verrät er einem nicht, unter welchen Bedingungen ein Arbeitspaket rechtzeitig fertig wird, oder unter welchen Bedingungen der Code wie erwartet funktioniert. Wenn Sie den Konjunktiv im Berufsleben hören, dann nehmen Sie so schnell wie möglich Reißaus.

sollen

Sollen” ist der kleine Bruder von „sollten” aber fast genau so schlimm. Was machen Sie, wenn Sie in einem Anforderungsdokument einen Satz wie „Die Antwortzeit des Service soll unter 200 Millisekunden liegen.” vorfinden? Ist das eine freundliche Bitte oder eine zwingende Anforderung? Was passiert, wenn diese Anforderung nicht erfüllt wird? Beim Einsatz des Verbs „sollen” bewegen Sie sich in einer Grauzone.

einfach”, „nur”, etc.

In der Software-Entwicklung gilt nicht „Weil einfach einfach einfach ist.”. Zwei Situationen sind fast nie identisch, das heißt, wenn heute etwas funktioniert hat, haben Sie keine Gewißheit, dass es morgen genau so funktioniert. Die Vokabeln „einfach” oder „nur” werden meistens eingesetzt, um einen Sachverhalt zu verharmlosen oder die Komplexität zu verstecken. Wenn Sie diese Wörter hören, dann schauen Sie besser genau so hin. Aber vielleicht sehe ich das einfach nur zu eng.

prinzipiell”, „eigentlich”, „normalerweise

Ist der aktuelle Fall der Normalfall, oder wird jetzt gerade gegen das Prinzip verstoßen? Ich möchte nicht wissen, wann ein Arbeitspaket unter anderen Umständen eigentlich fertig wird, sondern wann genau in diesem konkreten Fall mit der Fertigstellung des Arbeitspaketes zu rechnen ist. Vor Jahren habe ich mit einem guten Freund gearbeitet, dessen Shop-Projekt monatelang „normalerweise nächste Woche fertig werden sollte”.

Was ist daran schlecht?

Warum möchte ich diese Wörter nicht hören? Sie machen es mir schwer, zu reagieren. Wenn das Projekt normalerweise pünktlich fertig gestellt werden sollte, dann sagt mir das das selbe, als würde das Projekt wahrscheinlich nicht rechtzeitig fertig und damit bin ich wieder genau so schlau wie vorher.

Ein „Wir hatten Probleme mit den Unit-Tests und werden nicht zum geplanten Termin fertig. Es dauert eine Woche länger.” zeigt mir klar, woran ich bin und ermöglicht mir (und dem Team) Maßnahmen zu ergreifen. Es geht hier um Verbindlichkeit, die nötig ist, um entsprechend reagieren zu können. Ob dies bedeutet, einfach Funktionalitäten außen vor zu lassen, um den Termin zu halten, oder stattdessen den Termin zu verschieben, hängt vom Projekt ab.

Aber warum hört man diese Wörter trotzdem so oft, wenn es darum geht, einen Termin zu bestätigen oder frühzeitig abzusagen? Meistens möchte man damit schlechte Nachrichten vermeiden und hofft, den Termin doch noch irgendwie zu halten. Damit wird die schlechte Nachricht in den meisten Fällen jedoch nur verschleppt, wenn der Termin nicht doch noch, wie durch ein Wunder, gehalten werden kann.

Wie kann man es verhindern?

Erschießen Sie nicht den Überbringer der schlechten Nachricht und schaffen Sie eine Kultur, in der man eigene Fehler zugeben und schlechte Nachrichten überbringen kann, ohne mit Sanktionen rechnen zu müssen. Belohnen Sie Verbindlichkeit und signalisieren Sie so, dass es Ihnen lieber ist, früh die schmerzhafte Wahrheit zu erfahren, anstatt sich lange in trügerischer Sicherheit zu wiegen.

Probieren Sie einfach, dann sollte das eigentlich auch in Ihrem Team funktionieren.

Der McNuggetini

1

Da ist’s zum ersten Mal schade, dass ich keinen Alkohol trinke, das schlägt sogar einen Rootbeer-Float. Link via @phpmatesme.

Jeder ist entbehrlich – außer John Rambo

2

In Rambo II – Der Auftrag wird John Rambo von seinem ehemaligen Vorgesetzten aus dem Gefängnis (in das man in nach Rambo – First Blood gesteckt hat) geholt und nach Vietnam geschickt. Dort soll er Photos von Kriegsgefangenen machen, die auch viele Jahre nach dem Vietnamkrieg dort festgehalten und gefoltert werden.

Unterstützt wird John Rambo dabei von der Vietnamesin Co Bao, in die er sich während seines Einsatzes verliebt und von Captain Vinh getötet wird. Rambo schwört Rache und befreit die Kriegsgefangenen unter Einsatz seines eigenen Lebens aus den Klauen des Vietcong.

Vor ihrem Tod führen Rambo und Co Bao die folgende Unterhaltung.

Rambo: „Ach weißt Du, ich bin entbehrlich.”
Co Bao: „Was bedeutet entbehrlich?”
Rambo: „Das ist so, als wenn man zu einer Party eingeladen wird, und dann nicht hingeht. Es spielt einfach keine Rolle.”
Co Bao: „Rambo, Du bist nicht entbehrlich.”

John Rambo ist also nicht entbehrlich. Doch was hat er davon? Immer wieder, wenn es Probleme gibt, muss Rambo sein Leben einsetzen, um diese Probleme zu lösen. Was das aus ihm gemacht hat, sieht man sehr gut im ersten Film der Rambo Reihe: In First Blood kommt Rambo aus dem Krieg zurück in eine Kleinstadt und ist so traumatisiert, dass er sich vom Sheriff provozieren läßt und einen Kleinkrieg anfängt. Am Ende des Films wird er von der Armee eingesperrt und erst wieder auf freien Fuß gesetzt, als man ihn bei einem Todeskommando braucht. Ähnlich ergeht es Rambo in den Jahren danach, statt Vietnam muss er in Rambo III nach Afghanistan. Selbst als er sich in „John Rambo” einen Altersruhesitz in Thailand aufbauen möchte, und wirklich keinen Ärger mehr sucht, kommt er nicht zur Ruhe. Stattdessen muss er eine Gruppe Missionare aus Burma retten, die nicht auf ihn hören wollten. Sein Leben wiederholt sich immer wieder.

Viele Software-Entwickler wollen so sein, wie John Rambo: unentbehrlich. Sie sind glücklich, wenn sie die einzigen sind, die wissen, wie man mit einer bestimmten Datenbank oder einer Legacy-Applikation umgeht. Wenn es Probleme mit dieser Datenbank oder dieser Anwendung gibt, dann muss man beim einzigen Entwickler vorsprechen, der sich damit auskennt und ihn bitten, diese Probleme zu lösen. Wenn man so manchen „unentbehrlichen” Entwickler reden hört, dann lassen sich diese Probleme auch nur, wie von John Rambo, unter „Einsatz des eigenen Lebens” lösen.

Auch wenn es anfänglich schmeichelt, immer dann gerufen zu werden, wenn es Probleme gibt, bringt diese Unentbehrlichkeit auch negative Seiten mit sich. Einem solchen Entwickler wird die Möglichkeit genommen, sich weiter zu entwickeln. Er bleibt auf der aktuellen Position sitzen, weil er ab und zu an dieser Stelle dringend gebraucht wird. So wie Rambo in Friedenseiten langsam zu einem Relikt aus alten Zeiten wird, geht es auch diesen Entwicklern. Und wenn die Systeme des Entwicklers sterben, so stirbt auch der Entwickler mit ihnen. Und wie John Rambo in Thailand, möchte ein Entwickler sich später einmal neu orientieren. So lange er in seinem alten Job nicht entbehrlich geworden ist, wird er dort immer zu jeder Tages- und Nachtzeit gerufen werden.

Falls Sie also ein „unentbehrlicher” Entwickler sind, lauet mein Rat an Sie: „Seien Sie nicht John Rambo, machen Sie sich entbehrlich.

Mauna Loa – Macadamia Nuts

0

Entdeckt in Kailua-Kona auf Big Island. In Deutschland zu beziehen über HawaiianSun.de.

Dringlich vs Wichtig

4

Wenn Sie ein Team oder eine Abteilung von Software-Entwicklern leiten, dann landen jeden Tag eine unglaubliche Menge an Todos auf Ihrem Tisch. Das Tagesgeschäft wird erdrückend und Sie sind nicht mehr in der Lage, die strategische Planung zu machen, die eigentlich eine Ihrer Hauptaufgaben sein sollte. Sie müssen also das Tagesgeschäft reduzieren, aber wie entscheiden Sie, welche Aufgaben Sie selbst erledigen und welche Sie delegieren?
Machen Sie doch dazu das, was vor Ihnen schon Dwight D. Eisenhower (Präsident der Vereinigten Staaten von Amerika von 1953 bis 1961) gemacht hat und wenden Sie das Eisenhower-Prinzip an.

Bei diesem Prinzip prüfen Sie für jede Aufgabe, die es zu erledigen gilt, wie wichtig und wie dringlich diese ist. Doch bedeutet dringlich und wichtig nicht das selbe? Sehen Sie sich dazu die folgenden Definitionen der Begriffe an.

Dringlichkeit: die Notwendigkeit, eine wichtige Handlung kurzfristig zu erledigen, also die (zeitliche) Priorität.

Wichtigkeit: die schwerwiegende (wichtige) Bedeutung eines Gegenstandes.

Die Dringlichkeit einer Aufgabe bezieht sich also auf die Zeit, die zur Verfügung steht, um die Aufgabe zu erledigen, während sich die Wichtigkeit der Aufgabe immer auf den Inhalt der Aufgabe bezieht. Wenn Sie auf die Toilette müssen, so ist das meistens eine dringliche Angelegenheit, es kann hier schnell zu spät sein und dann noch auf die Toilette zu gehen, bringt Ihnen keinen Nutzen mehr. Einen guten Schulabschluss zu schaffen ist eine wichtige Aufgabe, die auch noch Nutzen bringt, wenn Sie sie ein oder zwei Jahre später abschließen, als dies geplant war.

Das Eisenhower-Prinzip

Wenn Sie nun Ihre Aufgaben nach deren Dringlichkeit und Wichtigkeit bewertet haben, dann nehmen Sie sich das folgende Koordinatensystem vor und platzieren Ihre Aufgaben auf den Achsen wichtig und dringlich.

Jede Ihrer Aufgaben sollte nun einem der Bereiche A-D zugerdnet worden sein. Manche Aufgaben sind wichtig aber nicht dringlich, manche sind dringlich jedoch nicht wichtig, manche sind beides und so einige sind wahrscheinlich weder wichtig noch dringlich. Mit dieser Einteilung ist die Entscheidung leicht, wie mit den einzelnen Aufgaben verfahren werden soll.

A-Aufgaben: Diese Aufgaben sind wichtig und sie müssen schnell erledigt werden. Das bedeutet, Sie erledigen die Aufgaben sofort und selbst. Die Delegation und die Kontrolle der Aufgabe würden zu viel Zeit beanspruchen.

B-Aufgaben: Diese Aufgaben sind wichtig, jedoch nicht dringlich. Definieren Sie schon jetzt, wann Sie diese Aufgaben erledigen werden und tragen Sie sich einen Blocker in Ihren Kalender ein. Stellen Sie auch sicher, dass Sie die Aufgaben zum geplanten Termin erledigen.

C-Aufgaben: Diese Aufgaben müssen schnell erledigt werden, es sind aber keine wichtigen Aufgaben. Delegieren Sie sie! Das sind genau die Aufgaben, die Sie von den wichtigen B-Aufgaben abhalten, wodurch diese plötzlich neben wichtig auch noch dringlich sind. Also sorgen Sie dafür, dass die C-Aufgaben von jemand anderem erledigt werden.

D-Aufgaben: Diese Aufgaben sind weder wichtig, noch dringlich. Das bedeutet also, sie bringen keinen Nutzen. Diese Aufgaben werden also weder sofort noch später erledigt, sondern gehören einfach nur in den Papierkorb.

Wenn Sie Ihre Aufgaben regelmäßig mit dem Eisenhower-Prinzip priorisieren, dann können Sie sicher sein, dass Sie Ihre Zeit und die Zeit Ihrer Mitarbeiter sinnvoll einsetzen. Besonders hervorheben möchte ich hierbei das regelmäßige Priorisieren: Wichtige Aufgaben, die letzte Woche nicht dringlich waren, werden es wahrscheinlich werden, wenn Sie nicht bearbeitet werden.

R2D2 Projector

0

Heute gibt’s ausnahmsweise etwas, das (noch) nicht in meinem Wohnzimmer steht. Danke an Wiegi für den Link.

Kleine Schritte sind besser als keine Schritte

1

Eigentlich hatte unter diesem Titel geplant, einen Eintrag über die Pfadfinder-Regel zu schreiben, die Robert C. „Uncle Bob” Martin in seinem Buch Clean Code vorstellt:

Leave the campground cleaner than you found it.

Genau an dem Tag, als ich den Eintrag schreiben wollte, kamen mir jedoch Nils und Holger zuvor. Mein erster Impuls war, meinen Eintrag einfach zu löschen und das Thema zu den Akten zu legen. Doch Schritt für Schritt (wer findet hier den Wortwitz?) bin ich wieder zu der Idee zurück gekehrt.

Die Überschrift „Kleine Schritte sind besser als keine Schritte” war das Motto von Willy Brandt (dt. Bundeskanzler von 1969 bis 1974), der damit seine Ostpolitik der langsamen Annäherung beschrieben hat.

Willy Brandt hat bei diesem Zitat sicher nicht an Uncle Bob, Coding Standards und kleine Refactorings gedacht. Sehr viele Entwickler, die sich die Pfadfinder Regel auf die Fahne schreiben, beschränken diese jedoch zu stark auf den Quellcode und wenden diese nicht ganzheitlich auf die eigene Arbeit und das Umfeld an. Richtig aufgefallen ist mir das auch erst in den letzten Wochen, in denen ich ausführlich mit Holger über Clean Code und die Einührung der Prinzipien in unseren Teams gesprochen habe.

Wenn Willy Brandt diese Regel auf eine Ostpolitik angewandt hat und damit eine Annäherung an Polen und die damalige Sowjetunion damit geschafft hat, dann sollten wir diese Regel auch in unserem täglichen Arbeitsumfeld anwenden können.

Ein gutes Beispiel ist, dass ich auf Konferenzen, auf denen ich über Clean Code, Testgetriebene Entwicklung und eine Menge andere „gute Dinge” geredet habe, am Ende immer gefragt werde, wie man diese in Teams einführt. Für die Teilnehmer sieht das immer nach einem großen Schritt aus, ein Team, das kein Verständnis für eine geminesame Code-Basis, Qualität und Entwicklungsmethodik hat, in ein Team zu transformieren, das bei der Entwicklung und der Pflege des Codes harmonisiert. Meine Antwort ist auch hier immer die selbe: Man muss es in kleinen Schritten angehen. Sie werden es nicht schaffen, das Bewußtsein für neue Entwicklungsmethodiken bei allen Teammitgliedern sofort zu wecken, also wecken Sie es bei einem und schauen Sie, wie es sich danach entwickelt.

Ähnlich verhält es sich bei der klassischen Beförderung vom Entwickler zum Leiter eines Entwicklungsteam. Sie können planen, wie Sie als perfekter Teamleiter sein könnten und diesen Plan dann in einem Jahr umsetzen. Oder Sie fangen morgen an und erledigen eine Teilaufgabe Ihres neuen Jobs mit Bravour und gehen dann die nächste an.

Sei es also ein neues Projekt oder ein neuer Job, der eine große Veränderung bedeutet, so ist der erfolgsversprechende Weg der, der mit vielen kleinen Schritten auf ein Ziel führt, das sich vielleicht sogar während des Wegs verändert.

Und wäre das nicht zu dramatisch für das Ende eines Blog-Artikels, würde ich jetzt schreiben:

Danke Willy Brandt. Danke Uncle Bob. Danke Holger.

Axolotl Roadkill

1

Helene Hegemann ist erst 17 Jahre alt. Ihr Lebenslauf liest sich, als wäre sie schon weit über 30. Sie kann bereits auf das Theaterstück „Ariel 15” zurückblicken, das im Ballhaus Ost aufgeführt und als Hörspiel adaptiert wurde, war Drehbuchautorin und Regisseurin des Films „Torpedo”, der es letzten Sommer in die deutschen Kinos geschafft hat und hat im Episodenfilm „Deutschland 09” als Schauspielerin mitgewirkt.

Mit „Axolotl Roadkill” ist im Ullstein Verlag jetzt ihr erstes Buch erschienen. Darin geht es um die 16 jährige Mifti, die bei Ihren wohlstandsverwahrlosten Halbgeschwistern lebt, seit ihre Mutter gestorben ist. Mifti nimmt Drogen und streift durch die alternative Berliner Partyszene, statt in die Schule zu gehen. Nach eigener Aussage durchläuft sie gerade eine extrem negative Entwicklung.

Ich hatte die knapp 200 Seiten des Buches in nicht mal vier Tagen durch. Nicht jedoch, weil das Buch so fesselnd war, sondern weil ich immer auf den Sinn des Buches gewartet habe und unbedingt wissen wollte, ob sich noch so etwas wie eine klassische Handlung einstellt. Während man liest, weiß man nie so recht, ob das, was Helene Hegemann gerade beschreibt, wirklich passiert oder nur eine Wahnvorstellung in Miftis Phantasie ist.

Auch wenn mir ein Ziel und ein tieferer (zumindest für mich verständlicher) Sinn gefehlt hat, so wird das Buch nicht langweilig, da es einen plötzlich mit scharfen Beobachtungen und ebenso scharf gezeichneten Szenen oder Dialogen überrascht:

Er erklärt mir, dass der Song Hey hey, my my die Verbindung zwischen Altrock und Punk darstellt und es nach allgemeingültigen Standards als absolut hinterwäldlerisch gilt, dem Wort >Techno< das Wort >Kultur< anzuhängen und das Ganze mit einer sich als alternativ betrachtenden Jugendbewegung in Verbindung zu bringen, anstatt mit Prolldiskotheken für Besserverdienende. Ecstasy, Techno und sich selbst als eine Grenzen sprengende Übereinkunft zu betrachten sei Neunziger, so wie Koksen Achtziger sei und so wie gelocktes Haar das neue glatte Haar ist.

Ich habe in diesem Buch Kombinationen von Wörtern und Bildern gelesen, die ich noch in keinem anderen Buch vorgefunden habe und die ich einer 17 jährigen nicht zugetraut hätte. Leider treibt Helene Hegemann das manchmal so auf die Spitze, dass das Buch stellenweise fast nicht mehr lesbar ist.

Wer Philip Roth liest, oder auch Freude am Tod des Bunny Munro hatte, dem kann ich Axolotl Roadkill empfehlen. Wer eher auf eine klare und lineare Handlung und Entspannung beim Lesen aus ist, der sollte wohl besser die Finger davon lassen.

Eines ist für mich bei diesem Buch sehr positiv: Ich weiß bis heute nicht, ob ich die Finger davon hätte lassen sollen, oder nicht.

Hip Hop Not For PHP

0

Da im Moment jeder einen Blog-Eintrag zu HipHop schreibt, kann ich mich da natürlich nicht rausnehmen und blogge bei der Gelegenheit mal eines meiner Lieblings-Hip-Hop-Videos:

Streng genommen ist das ja wahrscheinlich noch nicht mal Hip Hop sondern Rap. Und ein Hip Hop Fan bin ich eigentlich auch nicht.

Falls jemand meine Meinung zu HipHop For PHP hören möchte, ist die ganz einfach:

Facebook hatte ein Problem, Facebook hat das Problem gelöst. Jetzt stellt Facebook die Lösung noch jedem zur Verfügung, der sie nutzen möchte. So funktioniert Open Source. Also ist alles bestens.

Ich werde es wohl nicht nutzen, ich hab’ andere Probleme als Facebook.

nach oben