Das GTD Gen bei Programmierern

Das ‘GTD’ Gen

Software Entwickler gibt es in allen Ausprägungen. Ich kann das beurteilen, weil ich selber jahrelang Software geschrieben habe, und ja, ich gestehe, es auch heute noch leidenschaftlich gerne tue. Es ist so ein bisschen wie mit dem Fahrradfahren. Man verlernt es nie ganz, und an einem sonnigen Tag holt man den Drahtesel dann ans Tageslicht, Reifen aufpumpen und los geht’s ;)

Gute Software-Entwickler von heute sind jedoch eher mit Profi Radfahrern zu vergleichen. Nein, ich meine nicht, dass sie sich mit Eigenblut dopen dopen ;) . Ich meine, dass sie ständig auf dem neuesten Stand bleiben müssen, um auch alle Möglichkeiten einer modernen Programmiersprache auszunutzen. Schaut man zum Beispiel auf das Microsoft .net Framework, so reden wir von ca. 30.000 mitgelieferten Klassen (Schätzungen gehen bis zu 35.000 !!!). Offensichtlich kann man die nicht alle kennen. Dies passt also bestimmt nicht mehr in meine Hobby-Liga der Software Programmierung.

Aber ich weiche vom Thema ab. Es geht ums GTD Gen.

GTD = Get Things Done

Ich gestehe, ich habe mir den Namen des Gens selber ausgedacht und es ist auch noch nicht wissenschaftlich nachgewiesen worden. Aber es ist vorhanden. Bei einigen mehr bei anderen weniger ;) .

Worum geht’s dabei? Programmieren ist für viele Programmierer eine Funktion aus effizientem Code und Skalierbarkeit des Ergebnisses. Es ist eine (nicht leichte) Aufgabe, diese beiden Parameter optimal für ein neues Projekt auszubalancieren. Ein Software Architekt sollte einem das Skalierbarkeitsproblem abnehmen. Aber die sind teuer und nicht in jedem kleinen Projekt vorhanden.

Also selbst ist der Mann/Frau.  Es gibt allerdings noch einen dritten Parameter in der Softwareprogrammierung. Ein statischer, leider.  Die Zeit.  Sozusagen

public static DateTime time;

Also, die Zeit, die für ein Projekt vorgesehen wurde.

Und hier endlich kommt mein GTD Gen zum Vorschein. Es ist wichtig, eine effiziente Software zu entwickeln, mit schnellen Antwortzeiten und schlankem Software-Framework. Es ist auch wichtig, eine skalierbare Architektur zu haben, sodass man im Zweifelsfall, wenn das selbst programmierte Social Network zum Facebook Killer avanciert und es von 100 Hits pro Tag auf 1.000.000 wächst, nicht 4 Wochen vom Netz gehen muss, weil man nochmal ‘was dran rum programmieren muss’ ;) . Aber wie oft ist das nächste Projekt der Facebook-Killer?
Zugegeben, das weiß man nicht immer im Voraus, aber die Zusatzsoftware zum Buchhaltungsprogramm des örtlichen Steuerberaters wird nun einmal aller Voraussicht nach kein weltweiter Renner. In einem solchen Falle, wird der Parameter ‘Skalierbarkeit’ in den Hintergrund treten müssen (zumindestens sollte er das imho).

Ich habe in meiner Laufbahn schon mit vielen Programmierern gearbeitet. Teams in Deutschland, aber auch im Ausland. Autodidakten genauso wie promovierte Mathematik/IT/Betriebswirtschaftsabsolventen. Ich habe da keine Präferenzen, weil das Get Things Done Gen offensichtlich eine Einstellungssache ist und keine Wissenssache. In den letzten 15 Jahren habe ich Menschen kennengelernt, die offensichtlich das absolute Fachwissen in ihrem Softwarebereich haben. Leute die wahrscheinlich all die tausende .net Framework Klassen kennen (und zwar mit Vornamen) . Leute die aus dem Stand ein bis zwei Bücher darüber schreiben könnten (und manche die dies schon getan haben).
Viele von diesen Programmieren haben es dann, im Tagesgeschäft sozusagen, nicht geschafft ein Projekt abzuschließen. Auch nicht, nachdem sie ein bis zweimal die Projektzeit verlängert haben.
Sie Programmieren immer weiter – immer kompliziertere Spiralen und setzen die ‘Goldkante’ des Codes oben drauf. Nur fertig, fertig werden sie nicht.  Manche haben es nie geschafft, und das Projekt wurde ohne sie weitergeführt :( .

Diese Programmierer können in großen Teams sehr nützlich sein, um sozusagen die grobe Richtung vorzugeben. Als lebende .net Libary. Als Hort des Wissens. Richtig integriert und richtig geführt, sind sie eine sehr wichtige Ergänzung in mittleren bis großen Teams. In kleinen Projekten können sie jedoch verhängnisvolle Verzögerungen herbeiführen.

Dagegen gibt es die Pragmatiker, die es einfach immer wieder schaffen, Berge von Aufgaben in der angegebenen Zeit abzuarbeiten und damit den Betrieb am Laufen halten. Die haben das GTD Gen. Aber Achtung. Nur schnell fertig werden reicht leider auch nicht. Wenn’s am Ende so aussieht, dass jemand ein halbes Jahr später Wochen und Monate braucht, um durch den Spagetti-Code zu steigen.
Der richtige Mix ist wichtig. Fachwissen unbedingt, aber das Geschick, dieses Fachwissen pragmatisch und situationsgerecht anzuwenden.

Die PS auf die Straße bringen

Am Ende des Tages ist es wichtig, die geplante Software im veranschlagten Zeitraum abzuliefern. Das heißt mitnichten, dass man an Funktionalität (fällt dem Kunden sowieso auf) oder effizientem Code (fällt ihm nicht so schnell auf) oder an Skalierbarkeit sparen sollte. Man muss die Parameter einfach den Gegebenheiten anpassen. Das Stück Software was dazu benutzt wird um Daten von einem Green Mile* System auf ein neues System zu migrieren, muss nicht skalierbar sein. Es wird nach getaner Arbeit sowieso weggeschmissen. Verstehen Sie was ich meine?

Der GTD enhanced developer ;) zeichnet sich auch dadurch aus, dass er, meist ohne Aufforderung, versucht seinen Task fertig zu bekommen. Wenn die normale Zeit nicht ausreicht, ist er derjenige der als letzter im Büro sitzt und ‘den Karren aus dem Dreck zieht’. Er ist teamfähig und fragt auch um Hilfe und Rat, aber er kriegt sein Pensum geschafft (und häufig das von einem oder zwei Kollegen mit ;) )  Eine unschätzbare Ressource.

Wie erkenne ich nun, ob ein Programmierer das GTD Gen hat oder nicht? Dies ist sehr schwierig ist die Antwort. Nach meiner Erfahrung hat dies weder etwas mit dem Studienabschluss noch mit einem sympathischen (oder unsympathischen) Wesen zu tun. In meinem nächsten Blog stelle ich ein Verfahren vor, wie man vielleicht schon bei einem Einstellungstest das GTD Gen nachweisen kann ;)

Nach meiner Erfahrung sind GTD Programmierer eher zurückhaltend als extrovertiert. Es zeigt sich letztendlich in den Projekten. Man tendiert dazu, sich auf die Probleme in Projekten zu konzentrieren, dabei übersieht man schnell die Kollegin mit dem GTD Gen, weil die ja eben keine Probleme hat.

Aber genau die sind es, die gefordert und gefördert werden sollten. Also, Augen auf beim nächsten Projekt. Vielleicht sehen Sie ja das GTD Gen ;)

(* Green Mile: Als Green Mile System wurde bei einem meiner Arbeitgeber Systeme bezeichnet, die abgeschaltet werden sollten. Über Geschmack lässt sich bekanntlich streiten ;) )

Share and Enjoy:
  • Digg
  • del.icio.us
  • Facebook
  • Google
  • E-mail this story to a friend!
  • LinkedIn
  • MySpace
  • Netvibes
  • ThisNext
  • TwitThis
  • Yahoo! Buzz
  • MisterWong.DE
  • Webnews.de
  • Blogosphere News

Ein Kommentar zu Das GTD Gen bei Programmierern

Einen Kommentar schreiben

 

 

 

Diese HTML-Tags können verwendet werden

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>