Die Zeit-Ökonomie des Programmierers

Stefan - 7. September 2007

Ich halte Paul Graham für einen der interessantesten Köpfe in der Webszene. Graham wurde bekannt als der Kopf von Viaweb, einem Online-Tool zur Erstellung von Webshops. Viaweb startete 1995 und wurde drei Jahre später an Yahoo verkauft. Seither widmet er sich seinem eigenen VC-Unternehmen und veröffentlicht hin und wieder Beiträge aus dem Grenzbereich von (Web-)Programmierung und Business.

Sein aktueller Artikel geht im Detail auf die Arbeitsphasen und die effiziente Nutzung von Zeit durch Programmierer ein – und auf die Dinge, die einer effizienten Nutzung entgegenstehen können.

Der zentrale Punkt von Grahams Argumentation ist, dass Programmierer, die an einem Projekt arbeiten, den gesamten Code im Kopf haben. Natürlich nicht jede einzelne Zeile, aber das gesamte Code-Layout: Welche Klassen habe ich? Welche Beziehungen haben diese Klassen zueinander? Wo ist welche Funktionalität versteckt? Nur so kann ein Programmierer wirklich gut arbeiten, denn um ein gutes Stück Software zu entwickeln, reicht es nicht, jeweils nur das präsent zu haben, was der Bildschirm gerade anzeigt.

Viele Entwickler scheinen aber genau damit (was der Schirm zeigt) ihre Probleme zu haben. Denn warum wollen sie immer größere Bildschirme haben? Ein Fensterchen hier, ein Fensterchen da – ich habe oft genug den Eindruck, dass für manchen Programmierer der (möglichst große) Bildschirm als Ersatz für seinen Kopf dient. So ganz nach dem alten Kalauer: Was man nicht im Kopf hat, muss man auf dem Bildschirm haben. Aber auch noch so viele Infos, die eine IDE zeigt, ersetzen nicht den Gesamtzusammenhang, der sich im Kopf des Entwicklers befinden und aktiviert sein muss. So wie ja auch einem Computer der Code auf der Festplatte nichts nutzt, sondern erst ins RAM geladen, also aktiviert werden muss.

Dieses Vergegenwärtigen der großen und kleinen Zusammenhänge innerhalb eines Programmierprojekts benötigt Zeit. Offenbar muss unser Gehirn erst in den verschiedenen Langzeitspeichern nachsehen und die jeweils benötigten Infos in unser menschliches RAM laden. Ich erinnere mich, dass mich dieser langwierige Aufbau des Zustands vor etlichen Jahren, als ich mein erstes größeres Software-Projekt anging, regelmäßig in die Nähe des Wahnsinns getrieben hat. Ich konnte nicht verstehen, wieso ich oft genug planlos rumsurfte oder die nutzlosesten Dinge anstellte, anstatt mich voller Elan auf die spannende Arbeit zu stürzen. Erst Jahre später hatte ich mein Aha-Erlebnis, als ich Joel Spolskys Ausführungen dazu las:

Sometimes I just can’t get anything done. Sure, I come into the office, putter around, check my email every ten seconds, read the web, even do a few brainless tasks like paying the American Express bill. But getting back into the flow of writing code just doesn’t happen.

Plötzlich verstand ich, dass es nicht meine Faulheit oder Unfähigkeit war, sondern dass derartiges Verhalten das Normalste der Welt für einen Entwickler ist. Es kann Stunden dauern, bis ich den Zeitpunkt finde, der geeignet ist, diesen komplexen Zustand in meinem Kopf aufzubauen. Bis ich „in the zone“ bin, wie Spolsky das formuliert. Sobald ich aber in der „Zone“ bin, diesen Zustand der absoluten Konzentration erreicht habe, bin ich auch produktiv für drei, mindestens.

Als ich während des Studiums, zu Zeiten der sich anbahnenden Bubble 1.0, für eine Münchner Webagentur programmierte, verbrachte ich oft den halben Tag damit, mich mit Kollegen zu unterhalten oder rumzusurfen. Manchmal war bereits Nachmittag, bis ich richtig in Fahrt kam. Trotzdem schaffte ich in den sich dann anschließenden wenigen Stunden oft mehr wegzuarbeiten als so mancher Entwickler, der den ganzen Tag stur in seine Kiste starrte. Eine ähnliche Erfahrung hatte ich bereits im Studium gemacht. Etliche Kommilitonen schwörten auf ihre Lerngruppen; ich hingegen hasste diese Kaffeekränzchen mit begleitendem Physikgelaber wie die Pest. Das Ergebnis war, dass ich in wenigen, aber sehr konzentrierten Wochen, mehr lernte, als manche Kumpels über Monate hinweg.

Heute weiß ich: „In der Zone“ zu sein, ist das A und O für jeden „Wissensarbeiter“. Und da es so schwierig ist, diesen Zustand zu erreichen, müssen wir alles unternehmen, dass wir möglichst lange darin verharren. Jede noch so kleine Störung kann dabei tödlich sein für unsere „Zone“. Egal ob ein Kunde sich nach dem Stand des Projekts erkundigt oder der Kollege fragt, wohin denn der Locher verschwunden sei – jede Störung wirft den Entwickler aus seiner „Zone“. Noch schlimmer aber sind Störungen, von denen wir wissen, dass sie anstehen: Das für Nachmittag anberaumte Meeting etwa oder, noch schlimmer, der bevorstehende Anruf (von dem man aber nicht weiß, wann genau er kommen wird) verhindern effektiv, dass ich überhaupt diesen Zustand höchster Konzentration erreiche.

Oddly enough, scheduled distractions may be worse than unscheduled ones. If you know you have a meeting in an hour, you don’t even start working on something hard. (Paul Graham)

Gute Programmierer kennen die damit zusammenhängenden Probleme, zumindest instinktiv; bewusst ist es dem einen oder anderen womöglich nicht. Für Nicht-Entwickler aber ist das oftmals vollkommen unverständlich. Wer nie, oder nur sehr selten, in diesem Zustand höchster Konzentration arbeitet, dem leuchtet nicht ein, dass ein fünfminütiges Telefonat nicht einfach fünf Minuten Zeit kostet, sondern dabei unter Umständen Stunden verloren gehen. Umgekehrt ist es fast noch schlimmer. Ein Programmierer, der sich in der „Zone“ befindet, vergisst außen rum alles: Essen, Trinken, rechtzeitig Feierabend zu machen oder den wichtigen Kunden zurückzurufen.

Deshalb kann ich mich auch mit den ach so hippen „agilen“ Entwicklungsmethoden wie etwa Pair Programming nicht anfreunden. Gut, dass es da auch anderen Leuten so geht. Natürlich sitz auch ich hin und wieder mit einem anderen Programmierer gemeinsam am Bildschirm; dann geht’s aber genau um ein kleines, klar umrissenes Problem, das zu lösen ist. Ansonsten stört die unmittelbare Anwesenheit eines zweiten Entwicklers die notwendige Konzentration. Und nur mit der entsprechenden Konzentration ist es möglich, ein Problem ganz zu verstehen, wie Paul Graham verdeutlich:

it’s only when you have your code in your head that you really understand the problem.

Weiterer Lesestoff, alles auf Englisch:
Joel on Software: Where do These People Get Their (Unoriginal) Ideas?
Joel on Software: Human Task Switches Considered Harmful
Steve Yegge: Good Agile, Bad Agile

Abgelegt in: BusinessWeb Development

6 Kommentare:

Das kommt mir doch alles so bekannt vor 🙂

Sehr schöner Text! Nur hätte ich auch noch gerne ein paar Tips bekommen wie ich schneller in die „Zone“ gelange.

ich glaube da muss jeder seinen eigenen weg finden …
viel glück 😉

[…] vom 9 September 2007 12:19 It is done when it is done Stefan spricht mir aus der Seele. (Anspruchsvolle Projekt-) Programmierung ist halt auch in gewisser Weise […]

schön geschrieben. gilt nicht nur für Programmierer, sondern kenne ich, wenn ein sonstiges Problem gelöst werden muss. Man will entscheiden, könnte es auch, aber der Bauch sagt, dass es noch nicht reif ist. Einige Tage später, beim Duschen, Laufen oder kurz vorm Einschlafen ist es einfach da. Dann aufstehen, aufschreiben – geschafft. Dauert oft Tage, manchmal Wochen.

[…] Programmieren ist eine anstrengende Sache. Schön, dass sich mal jemand die Mühe gemacht hat, die Störfaktoren für Aussenstehende zusammenzufassen. […]

Schreibe einen Kommentar
benötigt
benötigt (wird nicht angezeigt)
optional

Suchen