Ein Programm im Kopf behalten | undefined

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 Schulkinder lernen. Sie tun mehr in ihren Köpfen: Sie versuchen, einen Problemraum so gut zu verstehen, dass sie ihn umrunden können, so wie man den Speicher des Hauses umrunden kann, in dem man aufgewachsen ist. Im besten Fall ist Programmieren dasselbe. Man behält das gesamte Programm im Kopf und kann es nach Belieben manipulieren.

Das ist besonders wertvoll zu Beginn eines Projekts, denn anfangs ist es am wichtigsten, ändern zu können, was man tut. Nicht nur, um das Problem auf 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. Erst wenn Sie Ihren Code im Kopf haben, verstehen Sie das Problem wirklich.

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, bis Sie es bei der Rückkehr wieder richtig verstehen. Selbst wenn Sie aktiv an einem Programm arbeiten, kann es eine halbe Stunde dauern, bis es jeden Tag beim Arbeitsbeginn in Ihren Kopf geladen ist. Und das ist im besten Fall. Gewöhnliche Programmierer, die unter typischen Bürobeschäftigungen arbeiten, geraten nie in diesen Modus. Oder drastischer ausgedrückt: Gewöhnliche Programmierer, die unter typischen Bürobeschäftigungen arbeiten, verstehen die Probleme, die sie lösen, nie wirklich.

Selbst die besten Programmierer haben nicht immer das gesamte Programm, an dem sie arbeiten, im Kopf. 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, 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 löschen.

Seltsamerweise können geplante Ablenkungen schlimmer sein als ungeplante. Wenn Sie wissen, dass Sie in einer Stunde eine Besprechung haben, beginnen Sie nicht einmal mit etwas Schwierigem.

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 als in vielen kurzen zu arbeiten. 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 Leuten gehört, die 36 Stunden am Stück gehackt haben, aber das meiste, was ich je geschafft habe, sind etwa 18 Stunden, und ich arbeite am besten in Blöcken von nicht mehr als 12 Stunden.

Das Optimum ist nicht die Grenze, die Sie physisch ertragen können. Es gibt sowohl Vorteile als auch Kosten, ein Projekt zu unterbrechen. Manchmal, wenn Sie nach einer Pause zu einem Problem zurückkehren, stellen Sie fest, dass Ihr Unterbewusstsein eine Antwort für Sie bereitgelegt hat.

Verwenden Sie prägnante Sprachen. Leistungsfähigere Programmiersprachen machen Programme kürzer. Und Programmierer scheinen Programme zumindest teilweise in der Sprache zu denken, 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.

Sie können die Wirkung 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 oberen dienen. Wenn Sie dies richtig machen, müssen Sie nur die oberste Schicht im Kopf behalten.

Schreiben Sie Ihr Programm immer wieder neu. Das Umschreiben eines Programms führt oft zu einem saubereren Design. Aber es hätte Vorteile, auch wenn es das nicht täte: Sie müssen ein Programm vollständig verstehen, um es neu zu schreiben, daher gibt es keinen besseren Weg, 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 ist ein Prototyp 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. Einige Teile eines Programms sind vielleicht am einfachsten zu lesen, wenn Sie die Dinge wie in einem Einführungstext ausbreiten. Wenn Sie jedoch Code schreiben, um ihn leicht in Ihren Kopf zu laden, ist Kürze vielleicht am besten.
Arbeiten Sie in kleinen Gruppen. Wenn Sie ein Programm im Kopf manipulieren, hört Ihre Vorstellungskraft tendenziell am Rand des Codes auf, den Sie besitzen. Andere Teile verstehen Sie nicht so gut und, was noch wichtiger ist, Sie können keine Freiheiten damit nehmen. Je kleiner die Anzahl der Programmierer, desto vollständiger kann ein Projekt mutieren. Wenn es nur einen Programmierer gibt, wie es anfangs oft der Fall ist, können Sie allumfassende Neugestaltungen vornehmen.
Lassen Sie nicht mehrere Personen am selben Code arbeiten. 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 ein Code von mehreren Autoren geschrieben wurde, versteht keiner von ihnen ihn so gut wie ein einzelner Autor.

Und natürlich können Sie nichts sicher neu gestalten, woran andere Leute arbeiten. Es ist nicht nur so, dass Sie um Erlaubnis bitten müssten. Sie lassen sich nicht einmal solche Dinge einfallen. Code mit mehreren Autoren neu zu gestalten ist wie Gesetze zu ändern; Code neu zu gestalten, den Sie allein kontrollieren, ist wie die 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 jedem eine.

Fangen Sie klein an. Ein Programm wird leichter im Kopf zu behalten, wenn Sie sich damit vertraut machen. Sie können Teile als Black Boxes behandeln, sobald Sie sich sicher sind, dass Sie sie vollständig erforscht 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, können Sie es vielleicht nie ganz erfassen. Wenn Sie also ein großes, komplexes Programm schreiben müssen, ist der beste Weg, damit zu beginnen, vielleicht nicht, eine Spezifikation dafür zu schreiben, sondern einen Prototyp, der einen Teil des Problems löst. Welche Vorteile auch immer die Planung hat, sie werden oft von den Vorteilen übertroffen, ein Programm im Kopf behalten zu können.

Es ist bemerkenswert, wie oft Programmierer zufällig alle acht Punkte treffen. 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 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 sich zunächst nur um ein Experiment handelt, verwendet er anstelle einer "Produktionssprache" nur eine "Skriptsprache" – die tatsächlich weitaus 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 niemand außer ihm es sehen wird, lässt er alle Kommentare weg, außer denen zur Selbstnotiz. Er arbeitet zwangsläufig in einer kleinen Gruppe, weil er die Idee entweder noch niemandem erzählt hat oder sie so vielversprechend erscheint, dass niemand anderes daran arbeiten darf. Selbst wenn es eine Gruppe gibt, könnten sie nicht mehrere Leute am selben Code arbeiten lassen, da er sich dafür zu schnell ändert. Und das Projekt beginnt klein, weil die Idee anfangs klein ist; er hat nur einen coolen Hack, den er ausprobieren möchte.

Noch bemerkenswerter ist die Anzahl der offiziell genehmigten Projekte, die alle acht Dinge falsch machen. Tatsächlich ist es, wenn man sich ansieht, wie Software in den meisten Organisationen geschrieben wird, fast so, als ob sie bewusst versuchen würden, die Dinge falsch zu machen. In gewissem Sinne tun sie das. Eine der definierenden Eigenschaften von Organisationen, seit es sie gibt, ist die Behandlung von Individuen als austauschbare Teile. Das funktioniert gut für stärker parallelisierbare Aufgaben, wie Kriege führen. Für den größten Teil der Geschichte konnte eine gut ausgebildete Armee von Berufssoldaten eine Armee von Einzelkämpfern besiegen, egal wie tapfer sie waren. Aber Ideen zu haben ist nicht sehr parallelisierbar. Und das sind Programme: Ideen.

Es ist nicht nur so, dass Organisationen die Idee, von individuellem Genie abhängig zu sein, ablehnen, es ist eine Tautologie. Es gehört zur Definition einer Organisation, dies nicht zu tun. Zumindest zu unserem derzeitigen Organisationsverständnis.

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

Wahrscheinlich ist das Beste, was wir tun können, eine Art Hack, wie z. B. die Programmierungsteile einer Organisation anders zu gestalten als den Rest. Vielleicht ist die optimale Lösung für große Unternehmen, Ideen gar nicht erst intern zu entwickeln, sondern sie einfach zu kaufen. Aber unabhängig davon, was die Lösung sein wird, 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 im Widerspruch stehen, denn Organisationen sind darauf ausgelegt, das zu verhindern, was Programmierer anstreben.

Gute Programmierer schaffen es trotzdem, viel 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 das Verhalten von Programmierern von den Anforderungen der Arbeit bestimmt wird, die sie tun. Es ist nicht, weil sie unverantwortlich sind, dass sie in langen Schüben arbeiten, in denen sie alle anderen Verpflichtungen vernachlässigen, sich direkt in die Programmierung stürzen, anstatt zuerst Spezifikationen zu schreiben, und Code umschreiben, der bereits funktioniert. Es ist nicht, weil sie unfreundlich sind, dass sie lieber allein arbeiten oder Leute knurrend abweisen, die ihren Kopf zur Tür hereinstecken, um Hallo zu sagen. Diese scheinbar zufällige Sammlung von ärgerlichen Gewohnheiten hat eine einzige Erklärung: die Kraft, ein Programm im Kopf zu behalten.

Ob das Verständnis dafür großen Organisationen hilft oder nicht, es kann sicherlich ihren Konkurrenten helfen. Der schwächste Punkt großer Unternehmen ist, dass sie einzelnen Programmierern keine großartige Arbeit leisten lassen. 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 vor, die in einem großen Gehirn gelöst werden müssen.

Vielen Dank 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.