EIN PROGRAMM IM KOPF BEHALTEN

August 2007

Ein guter Programmierer, der intensiv an seinem eigenen Code arbeitet, kann ihn im Kopf behalten, so wie ein Mathematiker ein Problem, an dem er arbeitet. Mathematiker beantworten Fragen nicht, indem sie sie auf Papier ausarbeiten, wie es Schulkindern beigebracht wird. Sie tun mehr im Kopf: Sie versuchen, einen Problembereich so gut zu verstehen, dass sie ihn umrunden können, so wie man in der Erinnerung an das Haus umrundet, in dem man aufgewachsen ist. Im besten Fall ist das beim Programmieren genauso. Man behält das ganze Programm im Kopf und kann es nach Belieben manipulieren.

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

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

Es ist nicht einfach, sich ein Programm einzuprägen. Wenn Sie ein Projekt für ein paar Monate liegen lassen, kann es Tage dauern, bis Sie es wieder wirklich verstehen, wenn Sie wieder damit anfangen. Selbst wenn Sie aktiv an einem Programm arbeiten, kann es eine halbe Stunde dauern, bis es in Ihren Kopf gelangt, wenn Sie jeden Tag mit der Arbeit beginnen. Und das ist im besten Fall so. Gewöhnliche Programmierer, die unter typischen Bürobedingungen arbeiten, geraten 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 im Kopf, an dem sie arbeiten. 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 die Programmierung, da Programmierer dazu neigen, an der Grenze der Details zu arbeiten, die sie bewältigen können.

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

Merkwürdigerweise können geplante Ablenkungen schlimmer sein als ungeplante. Wenn Sie wissen, dass Sie in einer Stunde ein Meeting haben, fangen Sie erst gar nicht an, an etwas Schwierigem zu arbeiten.

Arbeiten Sie in langen Abschnitten. Da es jedes Mal, wenn Sie mit der Arbeit an einem Programm beginnen, feste Kosten gibt, ist es effizienter, in wenigen langen Sitzungen zu arbeiten als in vielen kurzen. Natürlich kommt irgendwann der Punkt, an dem Sie dumm werden, weil Sie müde sind. Das ist von Person zu Person unterschiedlich. Ich habe von Leuten gehört, die 36 Stunden am Stück hacken, aber das Höchste, was ich jemals geschafft habe, waren etwa 18, und ich arbeite am besten in Abschnitten von nicht mehr als 12 Stunden.

Das Optimum ist nicht die Grenze, die Sie körperlich ertragen können. Das Aufbrechen eines Projekts hat sowohl Vorteile als auch Nachteile. Manchmal, wenn Sie nach einer Pause zu einem Problem zurückkehren, stellen Sie fest, dass Ihr Unterbewusstsein eine Antwort für Sie hinterlassen hat.

Verwenden Sie prägnante Sprachen. Leistungsfähigere Programmiersprachen machen Programme kürzer. Und Programmierer scheinen zumindest teilweise in der Sprache über Programme nachzudenken, in der sie sie schreiben. Je prägnanter die Sprache, desto kürzer das Programm und desto einfacher ist es, es zu laden und im Gedächtnis zu behalten.

Sie können die Wirkung einer leistungsstarken Sprache verstärken, indem Sie einen Stil namens Bottom-Up-Programmierung verwenden. Dabei schreiben Sie Programme in mehreren Schichten, wobei die unteren Schichten als Programmiersprachen für die darüber liegenden Schichten fungieren. Wenn Sie dies 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 auch Vorteile, wenn das nicht der Fall wäre: Sie müssen ein Programm vollständig verstehen, um es neu schreiben zu können, also gibt es keinen besseren Weg, sich ein Programm einzuprägen.

Schreiben Sie wiederlesbaren 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 schreiben, möchten Sie den Code vielleicht nicht zu dicht machen. Einige Teile eines Programms sind vielleicht am einfachsten zu lesen, wenn Sie die Dinge verteilen, wie bei einem Einführungslehrbuch. Wenn Sie hingegen Code schreiben, der sich leicht wieder ins Gedächtnis einprägen lässt, ist es vielleicht am besten, sich für Kürze zu entscheiden.

Arbeiten Sie in kleinen Gruppen. Wenn Sie ein Programm im Kopf manipulieren, endet Ihr Blick meist am Rand des Codes, der Ihnen gehört. Andere Teile verstehen Sie nicht so gut und, was noch wichtiger ist, bei denen Sie sich keine Freiheiten nehmen können. Je kleiner also die Anzahl der Programmierer ist, desto umfassender kann sich ein Projekt verändern. Wenn es nur einen Programmierer gibt, was anfangs oft der Fall ist, können Sie umfassende Neugestaltungen vornehmen.

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

Und natürlich können Sie etwas, an dem andere arbeiten, nicht ohne Risiko neu gestalten. Es geht nicht nur darum, dass Sie um Erlaubnis fragen müssten. Sie erlauben sich nicht einmal, an solche Dinge zu denken. Code mit mehreren Autoren neu zu gestalten ist wie eine Gesetzesänderung; Code neu zu gestalten, über den Sie allein die Kontrolle haben, ist wie die andere Interpretation eines mehrdeutigen Bildes zu sehen.

Wenn Sie mehrere Personen an einem Projekt arbeiten lassen möchten, teilen Sie es in Komponenten auf und delegieren Sie jede Komponente an eine Person.

Fangen Sie klein an. Ein Programm lässt sich leichter im Kopf behalten, wenn Sie sich damit vertraut machen. Sie können anfangen, Teile als Black Boxes zu behandeln, sobald Sie sich sicher sind, dass Sie sie vollständig erkundet haben. Aber wenn Sie zum ersten Mal mit der Arbeit an einem Projekt beginnen, sind Sie gezwungen, alles zu sehen. Wenn Sie mit einem zu großen Problem beginnen, werden Sie es möglicherweise nie ganz erfassen können. Wenn Sie also ein großes, komplexes Programm schreiben müssen, ist der beste Weg, damit zu beginnen, möglicherweise nicht, eine Spezifikation dafür zu schreiben, sondern einen Prototyp zu schreiben, der einen Teil des Problems löst. Was auch immer die Vorteile der Planung sind, sie werden oft durch die Vorteile aufgewogen, ein Programm im Kopf behalten zu können.

Es ist bemerkenswert, wie oft Programmierer es durch Zufall schaffen, alle acht Punkte zu erfüllen. Jemand hat eine Idee für ein neues Projekt, aber weil es nicht offiziell genehmigt ist, muss er es außerhalb der Arbeitszeiten umsetzen – was sich als produktiver erweist, da es keine Ablenkungen gibt. Angetrieben von seiner Begeisterung für das neue Projekt arbeitet er viele Stunden am Stück daran. Da es zunächst nur ein Experiment ist, verwendet er statt einer „Produktionssprache“ eine einfache „Skriptsprache“ – die tatsächlich viel leistungsfähiger ist. Er schreibt das Programm mehrmals komplett neu; das wäre bei einem offiziellen Projekt nicht vertretbar, aber dies ist eine Arbeit aus Liebe und er möchte, dass es perfekt ist. Und da niemand außer ihm es sehen wird, lässt er alle Kommentare außer den Notizen für sich selbst weg. Er arbeitet notgedrungen in einer kleinen Gruppe, weil er entweder noch niemandem von der Idee erzählt hat oder sie so wenig erfolgversprechend erscheint, dass niemand sonst daran arbeiten darf. Selbst wenn es eine Gruppe gibt, können nicht mehrere Personen denselben Code bearbeiten, da sich dieser zu schnell ändert. Und das Projekt beginnt klein, weil die Idee zunächst klein ist ; er hat nur einen coolen Hack, den er ausprobieren möchte.

Noch erstaunlicher ist die Anzahl offiziell genehmigter Projekte, die es schaffen, alle acht Dinge falsch zu machen. Wenn man sich ansieht, wie in den meisten Organisationen Software geschrieben wird, ist es fast so, als würden sie absichtlich versuchen, Dinge falsch zu machen. In gewissem Sinne ist das auch so. Eines der bestimmenden Merkmale von Organisationen, seit es sie gibt, ist, Individuen als austauschbare Teile zu behandeln. Dies funktioniert gut bei Aufgaben, die sich besser parallelisieren lassen, wie etwa Kriege führen. Die meiste Zeit der Geschichte konnte man sich darauf verlassen, dass eine gut ausgebildete Armee von Berufssoldaten eine Armee von Einzelkämpfern schlagen würde, egal wie tapfer diese waren. Aber Ideen zu haben, ist nicht sehr parallelisierbar. Und das ist es, was Programme sind: Ideen.

Es ist nicht nur wahr, dass Organisationen die Vorstellung nicht mögen, von der Genialität Einzelner abhängig zu sein, es ist eine Tautologie. Es ist Teil der Definition einer Organisation, dies nicht zu tun. Zumindest unseres aktuellen Organisationskonzepts.

Vielleicht könnten wir eine neue Art von Organisation definieren, die die Anstrengungen einzelner Menschen bündelt, ohne dass diese austauschbar sein müssen. Ein Markt ist wohl eine solche Organisationsform, obwohl es vielleicht genauer wäre, einen Markt als Sonderfall zu beschreiben – als das, was man standardmäßig bekommt, wenn Organisation nicht möglich ist.

Das Beste, was wir tun können, ist wahrscheinlich eine Art Trick, beispielsweise die Programmierteile einer Organisation anders arbeiten zu lassen als den Rest. Vielleicht besteht die optimale Lösung für große Unternehmen darin, nicht einmal zu versuchen, Ideen intern zu entwickeln, sondern sie einfach zu kaufen . Aber egal, wie die Lösung aussehen wird, der erste Schritt besteht darin, zu erkennen, dass es ein Problem gibt. Schon der Ausdruck „Softwareunternehmen“ enthält einen Widerspruch. Die beiden Wörter ziehen in entgegengesetzte Richtungen. Jeder gute Programmierer in einer großen Organisation wird damit nicht klarkommen, denn Organisationen sind so konzipiert, dass sie das verhindern, wonach Programmierer streben.

Gute Programmierer schaffen es trotzdem, eine Menge zu erledigen. Aber oft ist dazu praktisch ein Akt der Rebellion gegen die Organisationen erforderlich, in denen sie beschäftigt sind. Vielleicht würde es helfen, wenn mehr Menschen verstehen würden, dass das Verhalten von Programmierern von den Anforderungen ihrer Arbeit bestimmt wird. Es liegt nicht an ihrer Verantwortungslosigkeit, dass sie in langen Arbeitsphasen arbeiten, in 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 liegt nicht an ihrer Unfreundlichkeit, dass sie lieber allein arbeiten oder Leute anknurren, die ihren Kopf zur Tür hereinstecken, um Hallo zu sagen. Diese scheinbar zufällige Ansammlung lästiger Angewohnheiten hat eine einzige Erklärung: die Macht, ein Programm im Kopf zu behalten.

Ob dieses Verständnis großen Organisationen helfen kann oder nicht, ihren Konkurrenten kann es auf jeden Fall helfen. Die größte Schwäche großer Unternehmen ist, dass sie einzelne Programmierer keine großartige Arbeit leisten lassen. Wenn Sie also ein kleines Startup sind, ist dies der richtige Ort, um sie anzugreifen. Nehmen Sie sich der 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 der Entwürfe.