EIN PROGRAMM IM KOPF BEHALTEN

August 2007

Ein guter Programmierer, der intensiv an seinem eigenen Code arbeitet, kann ihn in seinem Kopf behalten, so wie ein Mathematiker ein Problem behält, an dem er arbeitet. Mathematiker beantworten Fragen nicht, indem sie sie auf Papier ausarbeiten, wie es Schulkindern beigebracht wird. Sie tun mehr in ihren Köpfen: Sie versuchen, einen Problemraum so gut zu verstehen, dass sie darin herumlaufen können, so wie man sich im Gedächtnis des Hauses bewegen kann, in dem man aufgewachsen ist. Im besten Fall ist Programmieren dasselbe. Man hält das gesamte Programm im Kopf und kann es nach Belieben manipulieren.

Das ist besonders wertvoll am Anfang eines Projekts, weil es zunächst am wichtigsten ist, in der Lage zu sein, das zu ändern, was man tut. Nicht nur, um das Problem auf eine andere Weise zu lösen, sondern um das Problem zu ändern, das man löst.

Ihr Code ist Ihr Verständnis des Problems, das Sie erforschen. Daher verstehen Sie das Problem erst dann wirklich, wenn Sie Ihren Code im Kopf haben.

Es ist nicht einfach, ein Programm in den Kopf zu bekommen. Wenn man ein Projekt für ein paar Monate liegen lässt, kann es Tage dauern, bis man es wirklich wieder versteht, wenn man zu ihm zurückkehrt. Selbst wenn man aktiv an einem Programm arbeitet, kann es eine halbe Stunde dauern, bis es in den Kopf geladen ist, wenn man jeden Tag mit der Arbeit beginnt. Und das ist im besten Fall. Gewöhnliche Programmierer, die unter typischen Bürobedingungen arbeiten, gelangen nie in diesen Modus. Oder um es dramatischer auszudrücken: Gewöhnliche Programmierer, die unter typischen Bürobedingungen arbeiten, verstehen die Probleme, die sie lösen, nie wirklich.

Selbst die besten Programmierer haben nicht immer das gesamte Programm, an dem sie arbeiten, in ihren Köpfen. Aber es gibt Dinge, die man tun kann, um sich zu helfen:

Ablenkungen vermeiden. Ablenkungen sind schlecht für viele Arten von Arbeit, aber besonders schlecht für das Programmieren, weil Programmierer dazu neigen, am Limit der Details zu arbeiten, die sie bewältigen können.

Die Gefahr einer Ablenkung hängt nicht von ihrer Dauer ab, sondern davon, wie sehr sie das Gehirn durcheinanderbringt. Ein Programmierer kann das Büro verlassen und sich ein Sandwich holen, ohne den Code im Kopf zu verlieren. Aber die falsche Art von Unterbrechung kann das Gehirn in 30 Sekunden auslöschen.

Seltsamerweise können geplante Ablenkungen schlimmer sein als ungeplante. Wenn man weiß, dass man in einer Stunde ein Meeting hat, fängt man nicht einmal an, an etwas Schwierigem zu arbeiten.

In langen Abschnitten arbeiten. Da es jedes Mal, wenn man mit der Arbeit an einem Programm beginnt, feste Kosten gibt, ist es effizienter, in wenigen langen Sitzungen zu arbeiten als in vielen kurzen. Es wird natürlich einen Punkt geben, an dem man dumm wird, weil man müde ist. Das variiert von Person zu Person. Ich habe von Leuten gehört, die 36 Stunden am Stück gehackt haben, aber das meiste, was ich je geschafft habe, waren etwa 18, und ich arbeite am besten in Abschnitten von nicht mehr als 12.

Das Optimum ist nicht die Grenze, die man physisch aushalten kann. Es gibt sowohl einen Vorteil als auch einen Nachteil, ein Projekt zu unterbrechen. Manchmal findet man, wenn man nach einer Pause zu einem Problem zurückkehrt, dass das Unterbewusstsein eine Antwort für einen bereitgelegt hat.

Kurzgefasste Sprachen verwenden. Mehr leistungsstarke Programmiersprachen machen Programme kürzer. Und Programmierer scheinen sich Programme zumindest teilweise in der Sprache vorzustellen, in der sie sie schreiben. Je prägnanter die Sprache, desto kürzer das Programm und desto einfacher ist es, es in den Kopf zu laden und dort zu behalten.

Man kann die Wirkung einer leistungsstarken Sprache verstärken, indem man einen Stil verwendet, der als Bottom-up-Programmierung bezeichnet wird, bei dem man Programme in mehreren Schichten schreibt, wobei die unteren Schichten als Programmiersprachen für die oberen dienen. Wenn man das richtig macht, muss man nur die oberste Schicht im Kopf behalten.

Schreiben Sie Ihr Programm immer wieder neu. Das Neuschreiben eines Programms führt oft zu einem saubereren Design. Aber es hätte auch dann Vorteile, wenn es das nicht täte: Man muss ein Programm vollständig verstehen, um es neu zu schreiben, daher gibt es keinen besseren Weg, um es in den Kopf zu bekommen.

Schreiben Sie lesbaren Code. Alle Programmierer wissen, dass es gut ist, lesbaren Code zu schreiben. Aber Sie selbst sind der wichtigste Leser. Vor allem am Anfang; ein Prototyp ist ein Gespräch mit sich selbst. Und wenn man für sich selbst schreibt, hat man andere Prioritäten. Wenn man für andere Leute schreibt, möchte man den Code vielleicht nicht zu dicht machen. Einige Teile eines Programms lassen sich am einfachsten lesen, wenn man die Dinge verteilt, wie in einem einführenden Lehrbuch. Wenn man hingegen Code schreibt, um ihn leicht in den Kopf laden zu können, ist es vielleicht am besten, auf Kürze zu setzen.

Arbeiten Sie in kleinen Gruppen. Wenn man ein Programm im Kopf manipuliert, neigt die eigene Sicht dazu, am Rande des eigenen Codes aufzuhören. Andere Teile versteht man nicht so gut, und was noch wichtiger ist, man kann sich keine Freiheiten mit ihnen nehmen. Je kleiner die Anzahl der Programmierer ist, desto vollständiger kann sich ein Projekt verändern. Wenn es nur einen Programmierer gibt, wie es oft am Anfang der Fall ist, kann man umfassende Neugestaltungen vornehmen.

Lassen Sie nicht mehrere Personen gleichzeitig am selben Codeteil arbeiten. Man versteht den Code anderer Leute nie so gut wie den eigenen. Egal wie gründlich man ihn gelesen hat, man hat ihn nur gelesen, nicht geschrieben. Wenn ein Codeteil also von mehreren Autoren geschrieben wird, versteht keiner von ihnen ihn so gut wie ein einzelner Autor.

Und natürlich kann man etwas, an dem andere Leute arbeiten, nicht sicher neu gestalten. Es ist nicht nur so, dass man um Erlaubnis fragen müsste. Man lässt sich solche Dinge nicht einmal denken. Die Neugestaltung von Code mit mehreren Autoren ist wie das Ändern von Gesetzen; die Neugestaltung von Code, den man allein kontrolliert, ist wie das Sehen der anderen Interpretation eines mehrdeutigen Bildes.

Wenn man mehrere Leute an einem Projekt arbeiten lassen möchte, teilt man es in Komponenten auf und gibt jeder Person eine.

Fangen Sie klein an. Ein Programm wird leichter im Kopf zu behalten, wenn man sich mit ihm vertraut macht. Man kann anfangen, Teile als Black Boxes zu behandeln, sobald man sich sicher ist, dass man sie vollständig erforscht hat. Aber wenn man zum ersten Mal an einem Projekt arbeitet, ist man gezwungen, alles zu sehen. Wenn man mit einem zu großen Problem beginnt, kann es sein, dass man es nie ganz erfassen kann. Wenn man also ein großes, komplexes Programm schreiben muss, ist es vielleicht nicht der beste Weg, eine Spezifikation dafür zu schreiben, sondern einen Prototyp zu schreiben, der eine Teilmenge des Problems löst. Was auch immer die Vorteile der Planung sind, sie werden oft von den Vorteilen übertroffen, ein Programm im Kopf behalten zu können.

Es ist bemerkenswert, wie oft Programmierer es schaffen, alle acht Punkte zufällig zu treffen. Jemand hat eine Idee für ein neues Projekt, aber weil es nicht offiziell genehmigt ist, muss er es in der Freizeit machen - was sich als produktiver erweist, weil es keine Ablenkungen gibt. Angetrieben von seiner Begeisterung für das neue Projekt arbeitet er viele Stunden am Stück daran. Weil es zunächst nur ein Experiment ist, verwendet er statt einer "Produktions"-Sprache eine bloße "Skriptsprache" - die in Wirklichkeit viel leistungsfähiger ist. Er schreibt das Programm mehrmals komplett neu; das wäre für ein offizielles Projekt nicht zu rechtfertigen, aber dies ist eine Liebesarbeit und er möchte, dass es perfekt ist. Und da es außer ihm niemand sehen wird, lässt er alle Kommentare außer den Notizen für sich selbst weg. Er arbeitet zwangsläufig in einer kleinen Gruppe, weil er entweder noch niemandem von der Idee erzählt hat oder sie so wenig vielversprechend erscheint, dass niemand sonst daran arbeiten darf. Selbst wenn es eine Gruppe gibt, könnten sie nicht mehrere Leute gleichzeitig am selben Code arbeiten lassen, weil er sich zu schnell ändert, als dass das möglich wäre. Und das Projekt beginnt klein, weil die Idee zunächst klein ist; er hat einfach nur einen coolen Hack, den er ausprobieren möchte.

Noch bemerkenswerter ist die Anzahl der offiziell genehmigten Projekte, die es schaffen, alle acht Dinge falsch zu machen. Wenn man sich die Art und Weise ansieht, wie Software in den meisten Organisationen geschrieben wird, ist es fast so, als ob sie absichtlich versuchen würden, Dinge falsch zu machen. In gewisser Weise tun sie das auch. Eine der bestimmenden Eigenschaften von Organisationen, seit es solche gibt, ist es, Individuen als austauschbare Teile zu behandeln. Das funktioniert gut bei stärker parallelisierbaren Aufgaben, wie z. B. dem Führen von Kriegen. In den meisten Teilen der Geschichte konnte man sich darauf verlassen, dass eine gut ausgebildete Armee von Berufssoldaten eine Armee von Einzelkämpfern schlägt, egal wie tapfer diese waren. Aber Ideen zu haben, ist nicht sehr parallelisierbar. Und das sind Programme: Ideen.

Es ist nicht nur wahr, dass Organisationen die Idee ablehnen, von individuellem Genie abhängig zu sein, es ist eine Tautologie. Es ist Teil der Definition einer Organisation, das nicht zu tun. Zumindest unseres aktuellen Begriffs von Organisation.

Vielleicht könnten wir eine neue Art von Organisation definieren, die die Bemühungen von Einzelpersonen kombiniert, ohne dass diese austauschbar sein müssen. Ein Markt ist wohl eine solche Form der Organisation, obwohl es vielleicht genauer ist, einen Markt als einen degenerierten Fall zu beschreiben - als das, was man standardmäßig erhält, wenn Organisation nicht möglich ist.

Wahrscheinlich werden wir es mit einer Art Hack schaffen, indem wir die Programmierteile einer Organisation anders funktionieren lassen als den Rest. Vielleicht ist die optimale Lösung, dass große Unternehmen nicht einmal versuchen, Ideen im eigenen Haus zu entwickeln, sondern sie einfach kaufen. Aber unabhängig davon, wie die Lösung aussehen wird, der erste Schritt ist, sich bewusst zu machen, dass es ein Problem gibt. Der Ausdruck "Softwareunternehmen" ist ein Widerspruch in sich. Die beiden Wörter ziehen in entgegengesetzte Richtungen. Jeder gute Programmierer in einer großen Organisation wird mit ihr im Widerspruch stehen, weil Organisationen so konzipiert sind, dass sie verhindern, was Programmierer anstreben.

Gute Programmierer schaffen es trotzdem, viel zu erreichen. Aber oft erfordert es praktisch einen Akt der Rebellion gegen die Organisationen, die sie beschäftigen. Vielleicht hilft es, wenn mehr Leute verstehen, dass das Verhalten von Programmierern von den Anforderungen der Arbeit abhängt, die sie leisten. Es ist nicht, weil sie unverantwortlich sind, dass sie in langen Fressorgien arbeiten, bei denen sie alle anderen Verpflichtungen ignorieren, sich direkt ins Programmieren stürzen, anstatt zuerst Spezifikationen zu schreiben, und Code neu schreiben, der bereits funktioniert. Es ist nicht, weil sie unfreundlich sind, dass sie es vorziehen, allein zu arbeiten oder Leute anzuknurren, die ihren Kopf zur Begrüßung in die Tür stecken. Diese scheinbar zufällige Sammlung von nervigen Gewohnheiten hat eine einzige Erklärung: die Macht, ein Programm im Kopf zu behalten.

Ob das Verständnis dieser Tatsache großen Organisationen helfen kann oder nicht, es kann ihren Konkurrenten sicherlich helfen. Die schwächste Stelle in großen Unternehmen ist, dass sie einzelnen Programmierern nicht erlauben, großartige Arbeit zu leisten. Wenn Sie also ein kleines Startup sind, ist dies der Ort, an dem Sie sie angreifen können. Nehmen Sie sich die Art von Problemen an, die in einem großen Gehirn gelöst werden müssen.

Danke an Sam Altman, David Greenspan, Aaron Iba, Jessica Livingston, Robert Morris, Peter Norvig, Lisa Randall, Emmett Shear, Sergei Tsarev, und Stephen Wolfram für das Lesen von Entwürfen dieses Textes.