EIN PROGRAMM IM KOPF HALTEN

August 2007

Ein guter Programmierer, der intensiv an seinem eigenen Code arbeitet, kann ihn in seinem Kopf halten, so wie ein Mathematiker ein Problem, an dem er arbeitet. Mathematiker beantworten Fragen nicht, indem sie sie auf Papier ausarbeiten, wie es Schüler gelehrt werden. Sie tun mehr in ihren Köpfen: Sie versuchen, einen Problemraum so gut zu verstehen, dass sie ihn durchwandern können, wie man sich an das Haus erinnert, in dem man aufgewachsen ist. Im Idealfall ist Programmieren dasselbe. Sie halten das ganze Programm in Ihrem Kopf und können es nach Belieben manipulieren.

Das ist besonders wertvoll zu Beginn eines Projekts, denn anfangs ist es am wichtigsten, das, was man tut, ändern zu können. Nicht nur, um das Problem auf eine andere Weise zu lösen, sondern um das Problem, das man löst, zu ändern.

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

Es ist nicht einfach, ein Programm in den Kopf zu bekommen. Wenn Sie ein Projekt ein paar Monate lang verlassen, kann es Tage dauern, bis Sie es bei der Rückkehr wirklich wieder verstehen. Selbst wenn Sie aktiv an einem Programm arbeiten, kann es eine halbe Stunde dauern, bis es sich in Ihren Kopf geladen hat, wenn Sie mit der Arbeit beginnen. Und das ist im besten Fall. Normale Programmierer, die unter typischen Bürobedingungen arbeiten, erreichen diesen Zustand nie. Oder um es dramatischer auszudrücken: Normale Programmierer, die unter typischen Bürobedingungen arbeiten, verstehen die Probleme, die sie lösen, nie wirklich.

Selbst die besten Programmierer haben nicht immer das ganze Programm, an dem sie arbeiten, in ihren Köpfen geladen. Aber es gibt Dinge, die Sie tun können, um zu helfen:

Vermeiden Sie Ablenkungen. Ablenkungen sind für viele Arten von Arbeit schlecht, aber besonders schlecht für das Programmieren, da Programmierer oft an der Grenze dessen arbeiten, was sie im Detail handhaben können.

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

Seltsamerweise können geplante Ablenkungen schlimmer sein als ungeplante. Wenn Sie wissen, dass Sie in einer Stunde ein Treffen haben, fangen Sie gar nicht erst an, etwas Schwieriges zu bearbeiten.

Arbeiten Sie in langen Zeitspannen. Da es einen festen Kostenfaktor gibt, jedes Mal wenn Sie mit einem Programm zu arbeiten beginnen, ist es effizienter, in ein paar langen Sitzungen zu arbeiten als in vielen kurzen. Irgendwann werden Sie natürlich dumm, weil Sie müde sind. Das variiert von Person zu Person. Ich habe von Leuten gehört, die 36 Stunden am Stück gehackt haben, aber das Längste, was ich je geschafft habe, sind etwa 18 Stunden, und am besten arbeite ich in Blöcken von maximal 12 Stunden.

Das Optimum ist nicht die Grenze dessen, was Sie physisch aushalten können. Es gibt auch Vorteile, ein Projekt aufzuteilen. Manchmal finden Sie, wenn Sie nach einer Pause zu einem Problem zurückkehren, dass Ihr Unterbewusstsein eine Antwort für Sie bereitgelegt hat.

Verwenden Sie prägnante Sprachen. Leistungsfähigere [1] Programmiersprachen machen Programme kürzer. Und Programmierer scheinen Programme zumindest teilweise in der Sprache zu denken, die sie zum Schreiben verwenden. Je prägnanter die Sprache, desto kürzer das Programm und desto leichter ist es, es im Kopf zu behalten.

Sie können den Effekt einer leistungsfähigen Sprache verstärken, indem Sie einen Stil namens Bottom-up-Programmierung verwenden, bei dem Sie Programme in mehreren Schichten schreiben, wobei die unteren als Programmiersprachen für die darüberliegenden dienen. Wenn Sie das richtig machen, müssen Sie 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 Vorteile, auch wenn es das nicht täte: Um ein Programm vollständig neu zu schreiben, müssen Sie es vollständig verstehen, so dass es keinen besseren Weg gibt, es in Ihren 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. Besonders am Anfang; ein Prototyp ist ein Gespräch mit sich selbst. Und wenn Sie für sich selbst schreiben, haben Sie andere Prioritäten. Wenn Sie für andere Leute schreiben, möchten Sie den Code vielleicht nicht zu dicht machen. Manche Teile eines Programms sind am leichtesten zu lesen, wenn Sie die Dinge ausbreiten, wie in einem einführenden Lehrbuch. Wenn Sie jedoch Code schreiben, um ihn leicht in Ihren Kopf zu laden, ist es möglicherweise am besten, auf Kürze zu setzen.

Arbeiten Sie in kleinen Gruppen. Wenn Sie ein Programm in Ihrem Kopf manipulieren, hört Ihre Sicht meist an den Rändern des Codes auf, den Sie besitzen. Andere Teile verstehen Sie nicht so gut und, was noch wichtiger ist, können Sie nicht so frei mit ihnen umgehen. Je kleiner also die Zahl der Programmierer, desto vollständiger kann ein Projekt mutieren. Wenn es nur einen Programmierer gibt, wie es oft am Anfang der Fall ist, können Sie umfassende Neugestaltungen vornehmen.

Lassen Sie nicht mehrere Personen denselben Codeabschnitt bearbeiten. Sie verstehen den Code anderer Leute nie so gut wie Ihren eigenen. Egal, wie gründlich Sie ihn gelesen haben, Sie haben ihn nur gelesen, nicht geschrieben. Wenn also ein Stück Code von mehreren Autoren geschrieben wird, versteht ihn keiner von ihnen so gut wie ein einzelner Autor.

Und natürlich können Sie einen Code, an dem andere arbeiten, nicht sicher umgestalten. Es ist nicht nur so, dass Sie um Erlaubnis fragen müssten. Sie lassen sich selbst gar nicht erst in solche Gedanken ein. Code mit mehreren Autoren umzugestalten, ist wie Gesetze zu ändern; Code umzugestalten, den Sie allein kontrollieren, ist wie eine andere Interpretation eines mehrdeutigen Bildes zu sehen.

Wenn Sie mehrere Leute an einem Projekt arbeiten lassen wollen, teilen Sie es in Komponenten auf und geben Sie jede an eine Person.

Fangen Sie klein an. Ein Programm wird leichter in Ihren Kopf zu bekommen, je vertrauter Sie damit werden. Sie können Teile als Black Boxes behandeln, sobald Sie sicher sind, dass Sie sie vollständig erkundet haben. Wenn Sie jedoch gerade erst mit einem Projekt beginnen, müssen Sie alles sehen. Wenn Sie mit einem zu großen Problem beginnen, schaffen Sie es vielleicht nie ganz, es zu umfassen. Wenn Sie also ein großes, komplexes Programm schreiben müssen, ist der beste Weg vielleicht nicht, einen Spezifikationstext dafür zu schreiben, sondern einen Prototyp, der nur einen Teilbereich des Problems löst. Egal welche Vorteile das Planen hat, sie werden oft von den Vorteilen übertroffen, ein Programm im Kopf halten zu können.

Es ist erstaunlich, wie oft Programmierer diese acht Punkte versehentlich treffen. Jemand hat eine Idee für ein neues Projekt, aber weil es nicht offiziell genehmigt ist, muss er es in seiner Freizeit machen - was sich als produktiver erweist, weil es keine Ablenkungen gibt. Angetrieben von seiner Begeisterung für das neue Projekt arbeitet er stundenlang am Stück daran. Da es zunächst nur ein Experiment ist, verwendet er statt einer "Produktions"-Sprache eine bloße "Skript"-Sprache - die tatsächlich viel leistungsfähiger ist. Er schreibt das Programm mehrmals komplett neu; das wäre für ein offizielles Projekt nicht zu rechtfertigen, aber das ist eine Arbeit der Liebe und er möchte, dass es perfekt ist. Und da es außer ihm niemand sehen wird, lässt er jegliche Kommentare weg, bis auf die Art von Notizen für sich selbst. Er arbeitet zwangsläufig in einer kleinen Gruppe, weil er entweder noch niemandem sonst von der Idee erzählt hat oder sie so aussichtslos erscheint, dass niemand sonst daran arbeiten darf. Selbst wenn es eine Gruppe gibt, könnten sie nicht mehrere Leute an demselben 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 auch klein ist; er möchte einfach einen coolen Hack ausprobieren.

Noch erstaunlicher sind die Anzahl offiziell genehmigter Projekte, die es schaffen, alle acht Dinge falsch zu machen. Tatsächlich sieht es fast so aus, als würden sie absichtlich versuchen, alles falsch zu machen. In gewisser Weise tun sie das auch. Eine der definierenden Eigenschaften von Organisationen, seit es sie gibt, ist es, Individuen als austauschbare Teile zu behandeln. Das funktioniert gut für parallelisierbare Aufgaben wie Kriege führen. Für den Großteil der Geschichte konnte eine gut gedrillt Armee professioneller Soldaten zuverlässig eine Armee individueller Krieger besiegen, 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, von individuellem Genie abhängig zu sein, ablehnen, es ist eine Tautologie. Es ist Teil der Definition einer Organisation, das nicht zu tun. Unseres derzeitigen Konzepts von Organisation zumindest.

Vielleicht könnten wir eine neue Art von Organisation definieren, die die Bemühungen von Individuen kombiniert, ohne zu verlangen, dass sie austauschbar sind. Streng genommen ist ein Markt eine solche Form der Organisation, auch wenn es genauer wäre, einen Markt als Grenzfall zu beschreiben - als das, was man standardmäßig erhält, wenn Organisation nicht möglich ist.

Wahrscheinlich werden wir bestenfalls eine Art Hack machen, indem wir die Programmierbereiche einer Organisation anders arbeiten lassen als den Rest. Vielleicht ist die optimale Lösung für große Unternehmen, Ideen gar nicht erst selbst zu entwickeln, sondern sie einfach [2] zu kaufen. Aber unabhängig davon, was die Lösung am Ende sein wird, ist der erste Schritt, das Problem zu erkennen. Es gibt einen Widerspruch in der Formulierung "Softwareunternehmen". Die beiden Wörter ziehen in entgegengesetzte Richtungen. Jeder gute Programmierer in einer großen Organisation wird damit im Widerspruch stehen, denn Organisationen sind darauf ausgelegt, das zu verhindern, wonach Programmierer streben.

Gute Programmierer schaffen es trotzdem, eine Menge zu erledigen. Aber oft erfordert es praktisch einen Akt der Rebellion gegen die Organisationen, die sie beschäftigen. Vielleicht hilft es, wenn mehr Leute verstehen, dass die Art und Weise, wie Programmierer sich verhalten, durch die Anforderungen ihrer Arbeit bestimmt wird. Es liegt nicht daran, dass sie unverantwortlich sind, dass sie in langen Schüben arbeiten, in denen sie alle anderen Verpflichtungen vernachlässigen, direkt mit dem Programmieren beginnen, anstatt zuerst Spezifikationen zu schreiben, und Code umschreiben, der bereits funktioniert. Es liegt nicht daran, dass sie unfreundlich sind, dass sie es vorziehen, allein zu arbeiten, oder Leute, die ihren Kopf zur Tür hereinstecken, um hallo zu sagen, anknurren. Diese scheinbar zufällige Sammlung von lästigen Angewohnheiten hat eine einzige Erklärung: die Macht, ein Programm im Kopf zu halten.

Ob das Verständnis dieser Zusammenhänge großen Organisationen helfen kann, ist fraglich. Aber es kann sicher ihren Wettbewerbern helfen. Der schwächste Punkt großer Unternehmen ist, dass sie es Einzelprogrammierern nicht erlauben, großartige Arbeit zu leisten. Wenn Sie also ein kleines Start-up sind, ist das der Punkt, an dem Sie sie angreifen können. Übernehmen Sie die Art von Problemen, die in einem einzigen 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.