EIN PROGRAMM IM KOPF HALTEN

August 2007

Ein guter Programmierer, der intensiv an seinem eigenen Code arbeitet, kann ihn im Kopf halten, 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 in ihren Köpfen: Sie versuchen, einen Problembereich so gut zu verstehen, dass sie ihn umhergehen können, wie man sich an die Erinnerung an das Haus erinnert, in dem man aufgewachsen ist. In seiner besten Form ist Programmierung dasselbe. Man hält das gesamte Programm im Kopf und kann es nach Belieben manipulieren.

Das ist besonders wertvoll zu Beginn eines Projekts, denn anfangs ist das Wichtigste, in der Lage zu sein, das, was man tut, zu ändern. 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 erkunden. Es ist also nur dann, wenn Sie Ihren Code im Kopf haben, dass Sie das Problem wirklich verstehen.

Es ist nicht einfach, ein Programm in den Kopf zu bekommen. Wenn Sie ein Projekt für ein paar Monate verlassen, kann es Tage dauern, es wirklich wieder zu verstehen, wenn Sie zurückkehren. Selbst wenn Sie aktiv an einem Programm arbeiten, kann es eine halbe Stunde dauern, um es jeden Tag in Ihren Kopf zu laden, wenn Sie mit der Arbeit beginnen. 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 geladen. Aber es gibt Dinge, die Sie tun können, um zu helfen:

Ablenkungen vermeiden. Ablenkungen sind schlecht für viele Arten von Arbeit, aber besonders schlecht für Programmierung, weil Programmierer dazu neigen, am Limit 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 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 Meeting haben, beginnen Sie nicht einmal, an etwas Schwierigerem zu arbeiten.

In langen Abschnitten arbeiten. Da es jedes Mal, wenn Sie mit der Arbeit an einem Programm beginnen, eine 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 Sie dumm werden, weil Sie müde sind. Das variiert von Person zu Person. Ich habe von Menschen gehört, die 36 Stunden am Stück hacken, aber das meiste, was ich jemals geschafft habe, sind etwa 18, und ich arbeite am besten in Abschnitten von nicht mehr als 12.

Das Optimum ist nicht das Limit, das Sie physisch ertragen können. Es gibt einen Vorteil sowie einen Nachteil, ein Projekt aufzuteilen. Manchmal, wenn Sie nach einer Pause zu einem Problem zurückkehren, stellen Sie fest, dass Ihr Unterbewusstsein eine Antwort für Sie bereitgehalten hat.

Verwenden Sie prägnante Sprachen. Mächtigere programmiersprachen machen Programme kürzer. Und Programmierer scheinen Programme zumindest teilweise in der Sprache zu denken, die sie verwenden, um sie zu schreiben. Je prägnanter die Sprache, desto kürzer das Programm, und desto einfacher ist es, es in Ihrem Kopf zu laden und zu behalten.

Sie können den Effekt einer mächtigen 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über liegenden fungieren. Wenn Sie das richtig machen, müssen Sie nur die oberste Schicht in Ihrem Kopf behalten.

Halten Sie Ihr Programm ständig in Überarbeitung. Ein Programm neu zu schreiben, führt oft zu einem saubereren Design. Aber es hätte Vorteile, selbst wenn es das nicht täte: Sie müssen ein Programm vollständig verstehen, um es neu zu schreiben, also gibt es keinen besseren Weg, um es in Ihren Kopf zu laden.

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 beim Schreiben für sich selbst haben Sie andere Prioritäten. Wenn Sie für andere Menschen schreiben, möchten Sie möglicherweise den Code nicht zu dicht machen. Einige Teile eines Programms sind möglicherweise am einfachsten zu lesen, wenn Sie die Dinge aufteilen, wie in einem einführenden Lehrbuch. Während es, wenn Sie Code schreiben, um ihn leicht wieder in Ihren Kopf zu laden, am besten sein kann, auf Kürze zu setzen.

Arbeiten Sie in kleinen Gruppen. Wenn Sie ein Programm in Ihrem Kopf manipulieren, neigt Ihre Sicht dazu, an der Grenze des Codes zu stoppen, den Sie besitzen. Andere Teile verstehen Sie nicht so gut und, was noch wichtiger ist, können Sie sich nicht erlauben, damit zu experimentieren. Je kleiner die Anzahl der Programmierer, desto vollständiger kann sich ein Projekt verändern. Wenn es nur einen Programmierer gibt, wie es oft zu Beginn der Fall ist, können Sie umfassende Neugestaltungen vornehmen.

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

Und natürlich können Sie etwas, an dem andere arbeiten, nicht sicher neu gestalten. Es ist nicht nur so, dass Sie um Erlaubnis fragen müssten. Sie lassen sich nicht einmal auf solche Dinge ein. Code mit mehreren Autoren neu zu gestalten, ist wie Gesetze zu ändern; Code, den Sie allein kontrollieren, neu zu gestalten, 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 geben Sie jede an eine Person.

Klein anfangen. Ein Programm wird einfacher, es im Kopf zu halten, je vertrauter Sie damit werden. Sie können beginnen, Teile als schwarze Kästen zu behandeln, sobald Sie sich sicher fühlen, dass Sie sie vollständig erkundet haben. Aber wenn Sie zum ersten Mal an einem Projekt arbeiten, 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 es möglicherweise am besten, nicht mit einer Spezifikation zu beginnen, sondern einen Prototyp zu schreiben, der einen Teil 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 auffällig, wie oft Programmierer zufällig alle acht Punkte erreichen. Jemand hat eine Idee für ein neues Projekt, aber da es nicht offiziell genehmigt ist, muss er es in seiner Freizeit tun – was sich als produktiver herausstellt, weil es keine Ablenkungen gibt. Getrieben 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 anstelle einer "Produktions"-Sprache eine bloße "Skriptsprache" – die in der Tat viel mächtiger ist. Er schreibt das Programm mehrere Male komplett neu; das wäre für ein offizielles Projekt nicht gerechtfertigt, aber dies ist eine Herzensangelegenheit und er möchte, dass es perfekt ist. Und da es niemand außer ihm 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 wenigversprechend erscheint, dass niemand sonst daran arbeiten darf. Selbst wenn es eine Gruppe gibt, könnten sie nicht mehrere Personen denselben Code bearbeiten lassen, weil er sich zu schnell ändert, als dass das möglich wäre. Und das Projekt beginnt klein, weil die Idee klein ist; er hat nur einen coolen Hack, den er ausprobieren möchte.

Noch auffälliger ist die Anzahl der offiziell genehmigten Projekte, die es schaffen, alle acht Dinge falsch zu machen. Tatsächlich, wenn man sich ansieht, wie Software in den meisten Organisationen geschrieben wird, ist es fast so, als würden sie absichtlich versuchen, Dinge falsch zu machen. In gewissem Sinne tun sie das. Eine der definierenden Eigenschaften von Organisationen, seit es solche gibt, ist, Individuen als austauschbare Teile zu behandeln. Das funktioniert gut für parallelisierbare Aufgaben, wie Kriege zu führen. In der meisten Geschichte konnte man sich auf eine gut trainierte Armee professioneller Soldaten verlassen, um eine Armee individueller Krieger zu besiegen, egal wie tapfer sie 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, nicht mögen, es ist eine Tautologie. Es ist Teil der Definition einer Organisation, dies nicht zu tun. Zumindest von unserem aktuellen Konzept einer Organisation.

Vielleicht könnten wir eine neue Art von Organisation definieren, die die Bemühungen von Individuen kombiniert, ohne dass sie austauschbar sein müssen. Man könnte argumentieren, dass ein Markt eine solche Form von Organisation ist, obwohl es genauer sein könnte, 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 das Beste tun, was wir können, ist eine Art Hack, wie die Programmierabteilungen einer Organisation anders arbeiten zu lassen als der Rest. Vielleicht ist die optimale Lösung, dass große Unternehmen nicht einmal versuchen, Ideen intern zu entwickeln, sondern sie einfach kaufen. Aber unabhängig davon, wie die Lösung aussieht, ist der erste Schritt zu erkennen, dass es ein Problem gibt. Es gibt einen Widerspruch in dem Ausdruck "Softwareunternehmen." Die beiden Wörter ziehen in entgegengesetzte Richtungen. Jeder gute Programmierer in einer großen Organisation wird mit ihr in Konflikt stehen, weil Organisationen darauf ausgelegt sind, das zu 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 Menschen verstehen, dass das Verhalten von Programmierern von den Anforderungen der Arbeit, die sie tun, bestimmt wird. Es ist nicht, weil sie verantwortungslos sind, dass sie in langen Schüben arbeiten, während denen sie alle anderen Verpflichtungen ignorieren, direkt ins Programmieren eintauchen, 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 dass sie Menschen anknurren, die ihren Kopf zur Tür hereinstecken, um Hallo zu sagen. Diese scheinbar willkürliche Ansammlung von nervigen Gewohnheiten hat eine einzige Erklärung: die Macht, ein Programm im Kopf zu halten.

Ob das Verständnis davon großen Organisationen helfen kann oder nicht, es kann sicherlich ihren Wettbewerbern helfen. Der schwächste Punkt in großen Unternehmen ist, dass sie einzelnen Programmierern nicht erlauben, großartige Arbeit zu leisten. Wenn Sie also ein kleines Start-up sind, ist dies der Ort, um sie anzugreifen. Nehmen Sie sich die Art von Problemen vor, 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 davon.