30.1.2012

Netzwerkprodukte (32)

(Themenanfang)

One reason programmers dislike meetings so much is that they're on a different type of schedule from other people. Meetings cost them more.

There are two types of schedule, which I'll call the manager's schedule and the maker's schedule. The manager's schedule is for bosses. It's embodied in the traditional appointment book, with each day cut into one hour intervals. You can block off several hours for a single task if you need to, but by default you change what you're doing every hour.

[…]

Most powerful people are on the manager's schedule. It's the schedule of command. But there's another way of using time that's common among people who make things, like programmers and writers. They generally prefer to use time in units of half a day at least. You can't write or program well in units of an hour. That's barely enough time to get started.

(Paul Graham: Maker's Schedule, Manager's Schedule[1]).

Die Arbeit eines Programmierers besteht keinesfalls darin, eine Zeile Sourcecode an die andere zu fügen, um am Ende des Tages eine bestimmte Funktionalität fertig zu haben, die der Compiler dann – womöglich noch über Nacht – in lauffähige Maschinensprache übersetzt. Der Prozeß dieser Arbeit ist wesentlich komplizierter und unberechenbarer, als ein Außenstehender wohl vermutet.

Eine Zeile Code darf – zunächst auf syntaktischer Ebene - keinen einzigen Fehler aufweisen. Das führt dazu, daß man immer wieder den Compiler anwirft, um die Syntax von ihm überprüfen zu lassen. Auch erfahrene Programmierer müssen sehr aufmerksam hinschauen, wenn der Compiler seine Fehlermeldungen ausspuckt: dort wurde statt einem Komma ein Doppelpunkt gesetzt; an anderer Stelle eine Klammer zuviel oder zuwenig; woanders kennt der Compiler eine Referenz auf ein externes Symbol nicht, weil man vergessen hat, es zu deklarieren, usw.usf. Meist wird man nach wenigen Minuten aus der „eigentlichen“ Arbeit, dem ursprünglichen Gedankenfluß, herausgeworfen, und muß etwas korrigieren.

Selbst wenn der Compiler mit dem einverstanden ist, was im Sourcecode steht, ist nicht gesagt, daß dieser tut, was er soll. Man übersetzt wieder und wieder das komplette Programm, läßt es laufen, und testet es. Im besten Fall kann man automatisierte Tests abfeuern. Nicht selten muß man jedoch im Debugger den eben geschriebenen Code mehr als nur einmal Zeile für Zeile durchgehen, unter immer neuen Ausgangsbedingungen – die man im schlimmsten Fall im Userinterface des laufenden Programms erst herstellen muß.

Schreiben von Code und der Test, ob er korrekt ist, geht also Hand in Hand – auf verschiedenen Ebenen, aber fast immer in relativ kurzen Zyklen. Wenn man mit einem Problem beschäftigt ist, das auch nur triviale Komplexität aufweist, braucht man jedoch eine ganze Reihe solcher Zyklen, um es letztlich zu lösen. Wenn man ununterbrochen arbeiten kann, ist es möglich, die einzelnen Ebenen im Kurzzeitgedächtnis zu behalten. Während der Compiler die Syntax checkt, kann man kurz darüber nachdenken, wie die nächste Zeile Code aussehen müßte, und kann sie gleich hinschreiben, wenn der Compilerlauf erfolgreich war. Schon dann ist es ärgerlich, wenn man erst dumme Schnitzer ausbessern muß, wie etwa den falsch geschriebenen Namen einer Variablen[2].

Jede längere Unterbrechung bedeutet dann, daß man sich bei der Wiederaufnahme der Arbeit nur noch an die Sachen erinnert, die im Langzeitgedächtnis gelandet sind – und da ist man dann auf einer ganz anderen, mitunter sehr frustrierenden Ebene unterwegs, weil das, was man gerade noch gewußt hat, verloren ist, obwohl man sich genau daran erinnert, daß man es eben noch wußte. Um auf sie zurück geworfen zu werden, reicht oft schon eine Ablenkung von wenigen Minuten – von einem ein- oder mehrstündigen Meeting ganz zu schweigen.

  1. [1] Es lohnt sich sehr, in Grahams Sammlung von Essays ein wenig zu stöbern. „Hackers and Painters” ist mE. ein Klassiker, den jeder kennen sollte, der sich für die Kunst der Programmierung interessiert.
  2. [2] Das ist übrigens mE. ein zentraler Grund, warum Tools bei der Programmentwicklung eine gewichtige Rolle spielen, die schon im Vorfeld darauf hinweisen, daß man sich gerade verschreibt – und ein Grund dafür, daß die Rechtschreibprüfung in Textverarbeitungen ausnahmslos so vorzüglich funktioniert (die Programmierer haben hier aus purem Eigeninteresse gute Arbeit geleistet).

(Kommentarfunktion z.Zt. deaktiviert.)