HACKER UND MALER

Mai 2003

(Dieser Essay basiert auf einer Gastvorlesung an der Harvard University, die eine frühere Rede an der Northeastern University einbezog.)

Als ich mein Studium der Informatik abgeschlossen hatte, ging ich an eine Kunsthochschule, um Malerei zu studieren. Viele Leute waren überrascht, dass jemand, der sich für Computer interessiert, sich auch für Malerei interessiert. Sie schienen zu denken, dass Hacken und Malen sehr unterschiedliche Arten von Arbeit sind - dass Hacken kalt, präzise und methodisch ist und dass Malen der frenetische Ausdruck eines Urbedürfnisses ist.

Beide Bilder sind falsch. Hacken und Malen haben viel Gemeinsamkeiten. Tatsächlich sind Hacker und Maler unter all den verschiedenen Arten von Menschen, die ich kenne, diejenigen, die sich am meisten ähneln.

Was Hacker und Maler gemeinsam haben, ist, dass sie beide Macher sind. Neben Komponisten, Architekten und Schriftstellern versuchen Hacker und Maler, gute Dinge zu schaffen. Sie betreiben keine Forschung im eigentlichen Sinne, obwohl sie, wenn sie im Laufe des Versuchs, gute Dinge zu schaffen, eine neue Technik entdecken, umso besser.

Ich habe den Begriff "Informatik" nie gemocht. Der Hauptgrund, warum ich ihn nicht mag, ist, dass es so etwas nicht gibt. Informatik ist ein Sammelsurium von lose miteinander verbundenen Bereichen, die durch einen Zufall der Geschichte zusammengeworfen wurden, wie Jugoslawien. An einem Ende haben Sie Leute, die eigentlich Mathematiker sind, aber das, was sie tun, Informatik nennen, damit sie DARPA-Stipendien bekommen. In der Mitte haben Sie Leute, die an etwas wie der Naturgeschichte von Computern arbeiten - sie untersuchen das Verhalten von Algorithmen für die Weiterleitung von Daten durch Netzwerke, zum Beispiel. Und dann am anderen Ende haben Sie die Hacker, die versuchen, interessante Software zu schreiben, und für die Computer nur ein Ausdrucksmittel sind, wie Beton für Architekten oder Farbe für Maler. Es ist, als ob Mathematiker, Physiker und Architekten alle in derselben Abteilung sein müssten.

Manchmal wird das, was die Hacker tun, "Software-Engineering" genannt, aber dieser Begriff ist genauso irreführend. Gute Software-Designer sind keine Ingenieure mehr als Architekten. Die Grenze zwischen Architektur und Ingenieurwesen ist nicht scharf definiert, aber sie ist da. Sie liegt zwischen dem Was und dem Wie: Architekten entscheiden, was zu tun ist, und Ingenieure finden heraus, wie man es tut.

Was und Wie sollten nicht zu sehr getrennt werden. Sie fordern Ärger heraus, wenn Sie versuchen, zu entscheiden, was zu tun ist, ohne zu verstehen, wie man es tut. Aber Hacken kann sicherlich mehr sein als nur zu entscheiden, wie man eine Spezifikation implementiert. Im besten Fall ist es die Erstellung der Spezifikation - obwohl es sich herausstellt, dass der beste Weg, dies zu tun, darin besteht, sie zu implementieren.

Vielleicht wird "Informatik" eines Tages, wie Jugoslawien, in seine Bestandteile zerfallen. Das könnte eine gute Sache sein. Vor allem, wenn es die Unabhängigkeit meines Heimatlandes, des Hackens, bedeuten würde.

Die Bündelung all dieser verschiedenen Arten von Arbeit in einer Abteilung mag administrativ bequem sein, aber sie ist intellektuell verwirrend. Das ist der andere Grund, warum ich den Namen "Informatik" nicht mag. Man könnte argumentieren, dass die Leute in der Mitte etwas wie eine experimentelle Wissenschaft betreiben. Aber die Leute an beiden Enden, die Hacker und die Mathematiker, betreiben keine eigentliche Wissenschaft.

Die Mathematiker scheinen sich davon nicht zu stören. Sie setzen sich gerne hin und beweisen Theoreme wie die anderen Mathematiker in der Mathematik-Abteilung, und hören wahrscheinlich bald auf zu bemerken, dass das Gebäude, in dem sie arbeiten, "Informatik" auf der Außenseite steht. Aber für die Hacker ist diese Bezeichnung ein Problem. Wenn das, was sie tun, Wissenschaft genannt wird, fühlen sie sich gezwungen, sich wissenschaftlich zu verhalten. Anstatt also das zu tun, was sie wirklich tun wollen, nämlich schöne Software zu entwerfen, fühlen sich Hacker an Universitäten und Forschungslaboren gezwungen, Forschungsarbeiten zu schreiben.

Im besten Fall sind die Arbeiten nur eine Formalität. Hacker schreiben coole Software und schreiben dann einen Artikel darüber, und der Artikel wird zum Stellvertreter für die Leistung, die durch die Software repräsentiert wird. Aber oft führt diese Diskrepanz zu Problemen. Es ist leicht, vom Bau schöner Dinge zum Bau hässlicher Dinge abzudriften, die geeignetere Themen für Forschungsarbeiten darstellen.

Leider sind schöne Dinge nicht immer die besten Themen für Arbeiten. Erstens muss Forschung originell sein - und wie jeder weiß, der eine Doktorarbeit geschrieben hat, ist der Weg, um sicherzugehen, dass man Neuland betritt, darin, ein Stück Land abzustecken, das niemand will. Zweitens muss Forschung substantiell sein - und unbeholfene Systeme liefern fleischigere Arbeiten, weil man über die Hindernisse schreiben kann, die man überwinden muss, um etwas zu erreichen. Nichts liefert fleischige Probleme wie der Beginn mit den falschen Annahmen. Der Großteil der KI ist ein Beispiel für diese Regel; wenn man annimmt, dass Wissen als eine Liste von Prädikatenlogik-Ausdrücken dargestellt werden kann, deren Argumente abstrakte Konzepte repräsentieren, hat man eine Menge Arbeiten zu schreiben, wie man das zum Laufen bringt. Wie Ricky Ricardo früher zu sagen pflegte: "Lucy, du hast eine Menge zu erklären."

Der Weg, etwas Schönes zu schaffen, besteht oft darin, subtile Veränderungen an etwas vorzunehmen, das bereits existiert, oder bestehende Ideen auf eine leicht neue Art und Weise zu kombinieren. Diese Art von Arbeit ist schwer zu vermitteln in einer Forschungsarbeit.

Warum beurteilen Universitäten und Forschungslabore Hacker also weiterhin anhand von Publikationen? Aus dem gleichen Grund, aus dem "scholastic aptitude" durch simple standardisierte Tests gemessen wird, oder die Produktivität von Programmierern in Codezeilen gemessen wird. Diese Tests sind einfach anzuwenden, und nichts ist so verlockend wie ein einfacher Test, der irgendwie funktioniert.

Das zu messen, was Hacker tatsächlich versuchen zu tun, nämlich schöne Software zu entwerfen, wäre viel schwieriger. Man braucht ein gutes Designverständnis, um gutes Design zu beurteilen. Und es gibt keine Korrelation, außer möglicherweise eine negative Korrelation, zwischen der Fähigkeit von Menschen, gutes Design zu erkennen, und ihrem Selbstvertrauen, dass sie es können.

Der einzige externe Test ist die Zeit. Im Laufe der Zeit neigen schöne Dinge dazu, zu gedeihen, und hässliche Dinge dazu, verworfen zu werden. Leider können die Zeiträume, die dafür benötigt werden, länger sein als die menschliche Lebensdauer. Samuel Johnson sagte, dass es hundert Jahre dauerte, bis der Ruf eines Schriftstellers konvergierte. Man muss warten, bis die einflussreichen Freunde des Schriftstellers sterben, und dann, bis all ihre Anhänger sterben.

Ich denke, Hacker müssen sich damit abfinden, dass ihr Ruf eine große zufällige Komponente hat. Darin unterscheiden sie sich nicht von anderen Machern. Tatsächlich haben sie im Vergleich dazu Glück. Der Einfluss der Mode ist im Hacking nicht annähernd so groß wie in der Malerei.

Es gibt schlimmere Dinge, als dass die Leute Ihr Werk missverstehen. Eine größere Gefahr ist, dass Sie Ihr Werk selbst missverstehen. Verwandte Bereiche sind die Orte, an denen Sie nach Ideen suchen. Wenn Sie sich in der Informatik- Abteilung befinden, besteht die natürliche Versuchung, zum Beispiel zu glauben, dass Hacken die angewandte Version dessen ist, wovon die theoretische Informatik die Theorie ist. Die ganze Zeit, als ich im Studium war, hatte ich ein ungutes Gefühl im Hinterkopf, dass ich mehr Theorie wissen sollte, und dass es sehr fahrlässig von mir war, all das Zeug innerhalb von drei Wochen nach der Abschlussprüfung vergessen zu haben.

Jetzt erkenne ich, dass ich mich geirrt habe. Hacker müssen die Theorie der Berechnung ungefähr so gut verstehen wie Maler die Chemie von Farbe. Man muss wissen, wie man Zeit und Raumkomplexität berechnet und etwas über Turing-Vollständigkeit. Man sollte sich vielleicht auch an mindestens das Konzept einer Zustandsmaschine erinnern, falls man einen Parser oder eine reguläre Ausdrucksbibliothek schreiben muss. Maler müssen tatsächlich viel mehr über die Chemie von Farbe wissen als das.

Ich habe festgestellt, dass die besten Quellen für Ideen nicht die anderen Bereiche sind, die das Wort "Computer" in ihrem Namen tragen, sondern die anderen Bereiche, die von Machern bewohnt werden. Die Malerei war eine viel reichere Quelle für Ideen als die Theorie der Berechnung.

Zum Beispiel wurde mir im College beigebracht, dass man ein Programm vollständig auf Papier ausarbeiten sollte, bevor man überhaupt an einen Computer geht. Ich stellte fest, dass ich nicht auf diese Weise programmierte. Ich stellte fest, dass ich gerne programmierte, während ich vor einem Computer saß, nicht vor einem Blatt Papier. Schlimmer noch, anstatt geduldig ein vollständiges Programm zu schreiben und mir zu versichern, dass es korrekt war, neigte ich dazu, einfach Code auszustoßen, der hoffnungslos kaputt war, und ihn nach und nach in Form zu bringen. Debugging, so wurde mir beigebracht, war eine Art letzter Durchlauf, bei dem man Tippfehler und Übersehenes auffing. So wie ich arbeitete, schien es, als ob Programmieren aus Debugging bestand.

Lange Zeit fühlte ich mich schlecht dabei, genauso wie ich mich einmal schlecht fühlte, weil ich meinen Bleistift nicht so hielt, wie man es mir in der Grundschule beigebracht hatte. Wenn ich nur auf die anderen Macher, die Maler oder die Architekten, geschaut hätte, hätte ich erkannt, dass es einen Namen für das gab, was ich tat: Skizzieren. Soweit ich das beurteilen kann, war die Art und Weise, wie man mir im College das Programmieren beigebracht hat, völlig falsch. Man sollte Programme ausarbeiten, während man sie schreibt, genau wie Schriftsteller, Maler und Architekten.

Die Erkenntnis hat reale Auswirkungen auf das Software-Design. Sie bedeutet, dass eine Programmiersprache vor allem verformbar sein sollte. Eine Programmiersprache ist für das Denken von Programmen, nicht für das Ausdrücken von Programmen, die man sich bereits ausgedacht hat. Sie sollte ein Bleistift sein, nicht ein Stift. Statische Typisierung wäre eine gute Idee, wenn die Leute tatsächlich Programme so schreiben würden, wie man es mir im College beigebracht hat. Aber so schreiben keine der Hacker, die ich kenne, Programme. Wir brauchen eine Sprache, die uns das Kritzeln, Verschmieren und Vermalen erlaubt, keine Sprache, in der man mit einer Tasse Tee mit Typen auf dem Schoß sitzen und höfliche Gespräche mit einer strengen alten Tante eines Compilers führen muss.

Solange wir schon beim Thema statische Typisierung sind, wird uns die Identifizierung mit den Machern vor einem weiteren Problem bewahren, das die Wissenschaften plagt: Mathematik-Neid. Jeder in den Wissenschaften glaubt insgeheim, dass Mathematiker klüger sind als sie. Ich denke, Mathematiker glauben das auch. Jedenfalls führt dies dazu, dass Wissenschaftler dazu neigen, ihre Arbeit so mathematisch wie möglich aussehen zu lassen. In einem Bereich wie der Physik tut das wahrscheinlich nicht viel Schaden, aber je weiter man sich von den Naturwissenschaften entfernt, desto mehr zu einem Problem wird es.

Eine Seite voller Formeln sieht einfach so beeindruckend aus. (Tipp: Für zusätzliche Eindrucksvollheit griechische Variablen verwenden.) Und so besteht eine große Versuchung, an Problemen zu arbeiten, die man formal behandeln kann, anstatt an Problemen, die, sagen wir, wichtig sind.

Wenn sich Hacker mit anderen Machern identifizieren würden, wie Schriftstellern und Malern, würden sie nicht versucht sein, das zu tun. Schriftsteller und Maler leiden nicht unter Mathematik-Neid. Sie haben das Gefühl, etwas völlig anderes zu tun. So ist es auch mit Hackern, denke ich.

Wenn Universitäten und Forschungslabore Hacker daran hindern, die Art von Arbeit zu tun, die sie tun wollen, ist der Ort für sie vielleicht in Unternehmen. Leider lassen die meisten Unternehmen Hacker auch nicht das tun, was sie wollen. Universitäten und Forschungslabore zwingen Hacker dazu, Wissenschaftler zu sein, und Unternehmen zwingen sie dazu, Ingenieure zu sein.

Ich selbst habe das erst vor kurzem entdeckt. Als Yahoo Viaweb kaufte, fragten sie mich, was ich tun wollte. Ich hatte nie die Geschäftsseite besonders gemocht und sagte, dass ich einfach nur hacken wollte. Als ich zu Yahoo kam, stellte ich fest, dass Hacken für sie bedeutete, Software zu implementieren, nicht zu entwerfen. Programmierer wurden als Techniker angesehen, die die Visionen (wenn das das richtige Wort ist) von Produktmanagern in Code umsetzten.

Das scheint der Standardplan in großen Unternehmen zu sein. Sie tun es, weil es die Standardabweichung des Ergebnisses verringert. Nur ein kleiner Prozentsatz der Hacker kann tatsächlich Software entwerfen, und es ist schwer für die Leute, die ein Unternehmen leiten, diese herauszupicken. Anstatt also die Zukunft der Software einem brillanten Hacker anzuvertrauen, richten die meisten Unternehmen die Dinge so ein, dass sie von einem Komitee entworfen wird, und die Hacker lediglich die Gestaltung implementieren.

Wenn Sie irgendwann Geld verdienen wollen, denken Sie daran, denn das ist einer der Gründe, warum Startups gewinnen. Große Unternehmen wollen die Standardabweichung der Design-Ergebnisse verringern, weil sie Katastrophen vermeiden wollen. Aber wenn man Schwingungen dämpft, verliert man die Hochpunkte genauso wie die Tiefpunkte. Das ist kein Problem für große Unternehmen, weil sie nicht durch die Herstellung großartiger Produkte gewinnen. Große Unternehmen gewinnen, indem sie weniger schlecht sind als andere große Unternehmen.

Wenn Sie also einen Weg finden, in einen Design-Krieg mit einem Unternehmen zu geraten, das groß genug ist, dass seine Software von Produktmanagern entworfen wird, werden sie nie in der Lage sein, mit Ihnen Schritt zu halten. Diese Möglichkeiten sind jedoch nicht leicht zu finden. Es ist schwer, ein großes Unternehmen in einen Design-Krieg zu verwickeln, genauso wie es schwer ist, einen Gegner innerhalb einer Burg im Nahkampf zu bekämpfen. Es wäre ziemlich einfach, einen besseren Textverarbeitungsprogramm als Microsoft Word zu schreiben, zum Beispiel, aber Microsoft, innerhalb der Burg ihres Betriebssystem-Monopols, würde wahrscheinlich nicht einmal bemerken, wenn Sie das tun würden.

Der Ort, an dem man Design-Kriege führen kann, sind neue Märkte, in denen noch niemand es geschafft hat, irgendwelche Festungen zu errichten. Dort kann man groß gewinnen, indem man den mutigen Ansatz beim Design verfolgt und die gleichen Leute sowohl das Design als auch die Implementierung des Produkts übernehmen lässt. Microsoft selbst hat das am Anfang getan. Apple auch. Und Hewlett-Packard. Ich vermute, dass fast jedes erfolgreiche Startup das getan hat.

Eine Möglichkeit, großartige Software zu bauen, ist, ein eigenes Startup zu gründen. Allerdings gibt es zwei Probleme damit. Das eine ist, dass man in einem Startup so viel mehr tun muss, als nur Software zu schreiben. Bei Viaweb hielt ich mich glücklich, wenn ich ein Viertel der Zeit mit Hacken verbringen konnte. Und die Dinge, die ich in den anderen drei Vierteln der Zeit tun musste, reichten von langweilig bis erschreckend. Ich habe einen Maßstab dafür, denn ich musste einmal eine Vorstandssitzung verlassen, um mir einige Löcher füllen zu lassen. Ich erinnere mich, wie ich im Zahnarztstuhl saß, auf den Bohrer wartete und das Gefühl hatte, im Urlaub zu sein.

Das andere Problem mit Startups ist, dass es nicht viel Überschneidung zwischen der Art von Software gibt, die Geld verdient, und der Art, die interessant zu schreiben ist. Programmiersprachen sind interessant zu schreiben, und Microsofts erstes Produkt war tatsächlich eine, aber niemand wird jetzt für Programmiersprachen bezahlen. Wenn man Geld verdienen will, ist man gezwungen, an Problemen zu arbeiten, die zu unangenehm sind, als dass jemand sie kostenlos lösen könnte.

Alle Macher stehen vor diesem Problem. Die Preise werden durch Angebot und Nachfrage bestimmt, und es gibt einfach nicht so viel Nachfrage nach Dingen, an denen es Spaß macht zu arbeiten, wie nach Dingen, die die alltäglichen Probleme einzelner Kunden lösen. In Off-Broadway-Stücken zu spielen, zahlt sich einfach nicht so gut aus, wie in einem Gorilla-Kostüm in einem Stand auf einer Messe zu stehen. Romane zu schreiben, zahlt sich nicht so gut aus, wie Werbetexte für Müllschlucker zu schreiben. Und das Hacken von Programmiersprachen zahlt sich nicht so gut aus, wie herauszufinden, wie man die Legacy-Datenbank eines Unternehmens mit seinem Webserver verbindet.

Ich denke, die Antwort auf dieses Problem, im Fall von Software, ist ein Konzept, das fast allen Machern bekannt ist: der Nebenjob. Dieser Ausdruck entstand bei Musikern, die nachts auftreten. Im Allgemeinen bedeutet er, dass man eine Art von Arbeit hat, die man für Geld macht, und eine andere, die man aus Liebe macht.

Fast alle Macher haben zu Beginn ihrer Karriere Nebenjobs. Maler und Schriftsteller tun das bekanntermaßen. Wenn man Glück hat, kann man einen Nebenjob bekommen, der eng mit seiner eigentlichen Arbeit zusammenhängt. Musiker arbeiten oft in Plattenläden. Ein Hacker, der an einer Programmiersprache oder einem Betriebssystem arbeitet, könnte ebenfalls einen Nebenjob bekommen, bei dem er diese verwendet. [1]

Wenn ich sage, dass die Antwort für Hacker darin besteht, Nebenjobs zu haben und nebenbei an schöner Software zu arbeiten, dann schlage ich das nicht als neue Idee vor. Das ist es, worum es beim Open-Source-Hacking geht. Was ich sage ist, dass Open-Source wahrscheinlich das richtige Modell ist, weil es unabhängig von allen anderen Machern bestätigt wurde.

Es überrascht mich, dass jeder Arbeitgeber zögern würde, Hacker an Open-Source-Projekten arbeiten zu lassen. Bei Viaweb wären wir zögerlich gewesen, jemanden einzustellen, der das nicht getan hätte. Als wir Programmierer interviewten, ging es uns vor allem darum, welche Art von Software sie in ihrer Freizeit schrieben. Man kann nichts wirklich gut machen, wenn man es nicht liebt, und wenn man es liebt zu hacken, wird man unweigerlich an eigenen Projekten arbeiten. [2]

Da Hacker eher Macher als Wissenschaftler sind, ist der richtige Ort, um nach Metaphern zu suchen, nicht in den Wissenschaften, sondern bei anderen Arten von Machern. Was kann uns die Malerei noch über das Hacken lehren?

Eines, was wir aus dem Beispiel der Malerei lernen oder zumindest bestätigen können, ist, wie man das Hacken lernt. Man lernt Malen vor allem, indem man es tut. Das Gleiche gilt für das Hacken. Die meisten Hacker lernen nicht, zu hacken, indem sie College-Kurse in Programmierung belegen. Sie lernen, zu hacken, indem sie im Alter von dreizehn Jahren eigene Programme schreiben. Selbst in College-Kursen lernt man vor allem durch Hacken, zu hacken. [3]

Da Maler eine Spur von Arbeit hinterlassen, kann man ihnen beim Lernen durch Tun zusehen. Wenn man sich die Werke eines Malers in chronologischer Reihenfolge ansieht, stellt man fest, dass jedes Gemälde auf Dingen aufbaut, die in früheren Gemälden gelernt wurden. Wenn etwas in einem Gemälde sehr gut funktioniert, findet man normalerweise Version 1 davon in einer kleineren Form in einem früheren Gemälde.

Ich denke, die meisten Macher arbeiten so. Schriftsteller und Architekten scheinen das auch zu tun. Vielleicht wäre es gut für Hacker, sich mehr wie Maler zu verhalten und regelmäßig von vorne anzufangen, anstatt jahrelang an einem Projekt zu arbeiten und zu versuchen, all ihre späteren Ideen als Revisionen einzubauen.

Die Tatsache, dass Hacker das Hacken durch Tun lernen, ist ein weiteres Zeichen dafür, wie unterschiedlich das Hacken von den Wissenschaften ist. Wissenschaftler lernen die Wissenschaft nicht durch Tun, sondern durch Experimente und Übungsaufgaben. Wissenschaftler beginnen mit Arbeiten, die perfekt sind, in dem Sinne, dass sie nur versuchen, Arbeiten zu reproduzieren, die jemand anderes bereits für sie erledigt hat. Irgendwann kommen sie an den Punkt, an dem sie originelle Arbeit leisten können. Während Hacker von Anfang an originelle Arbeit leisten; sie ist nur sehr schlecht. So beginnen Hacker originell und werden gut, und Wissenschaftler beginnen gut und werden originell.

Die andere Art, wie Macher lernen, ist durch Beispiele. Für einen Maler ist ein Museum eine Referenzbibliothek für Techniken. Seit Hunderten von Jahren gehört es zur traditionellen Ausbildung von Malern, die Werke der großen Meister zu kopieren, weil das Kopieren einen zwingt, sich die Art und Weise, wie ein Gemälde gemacht ist, genau anzusehen.

Schriftsteller tun das auch. Benjamin Franklin lernte Schreiben, indem er die Punkte in den Essays von Addison und Steele zusammenfasste und dann versuchte, sie zu reproduzieren. Raymond Chandler tat dasselbe mit Detektivgeschichten.

Hacker können ebenfalls lernen, zu programmieren, indem sie sich gute Programme ansehen - nicht nur, was sie tun, sondern auch den Quellcode. Einer der weniger bekannten Vorteile der Open-Source-Bewegung ist, dass es einfacher geworden ist, Programmieren zu lernen. Als ich Programmieren lernte, mussten wir uns hauptsächlich auf Beispiele in Büchern verlassen. Der einzige große Code-Block, der damals verfügbar war, war Unix, aber auch dieser war nicht Open Source. Die meisten Leute, die den Quellcode lasen, lasen ihn in illegalen Fotokopien von John Lions' Buch, das zwar 1977 geschrieben wurde, aber erst 1996 veröffentlicht werden durfte.

Ein weiteres Beispiel, das wir uns aus der Malerei nehmen können, ist die Art und Weise, wie Gemälde durch schrittweise Verfeinerung entstehen. Gemälde beginnen normalerweise mit einer Skizze. Nach und nach werden die Details ausgefüllt. Aber es ist nicht nur ein Prozess des Ausfüllens. Manchmal erweisen sich die ursprünglichen Pläne als falsch. Unzählige Gemälde, wenn man sie in Röntgenbildern betrachtet, haben Gliedmaßen, die verschoben wurden, oder Gesichtszüge, die neu angepasst wurden.

Hier ist ein Fall, in dem wir von der Malerei lernen können. Ich denke, das Hacken sollte auch so funktionieren. Es ist unrealistisch zu erwarten, dass die Spezifikationen für ein Programm perfekt sind. Man ist besser dran, wenn man das von vornherein zugibt und Programme so schreibt, dass sich die Spezifikationen im laufenden Betrieb ändern lassen.

(Die Struktur großer Unternehmen macht es ihnen schwer, das zu tun, daher haben Startups hier einen weiteren Vorteil.)

Jeder weiß inzwischen vermutlich von der Gefahr der vorzeitigen Optimierung. Ich denke, wir sollten uns genauso Sorgen um vorzeitiges Design machen - zu früh zu entscheiden, was ein Programm tun soll.

Die richtigen Werkzeuge können uns helfen, diese Gefahr zu vermeiden. Eine gute Programmiersprache sollte, wie Ölfarbe, es leicht machen, seine Meinung zu ändern. Dynamische Typisierung ist hier ein Gewinn, weil man sich nicht von vornherein auf bestimmte Datenrepräsentationen festlegen muss. Aber der Schlüssel zur Flexibilität liegt meiner Meinung nach darin, die Sprache sehr abstrakt zu machen. Das einfachste Programm, das man ändern kann, ist eines, das sehr kurz ist.

Das klingt nach einem Paradoxon, aber ein großartiges Gemälde muss besser sein, als es sein muss. Als Leonardo zum Beispiel das Porträt von Ginevra de Benci in der National Gallery malte, setzte er einen Wacholderbusch hinter ihren Kopf. Darin malte er sorgfältig jedes einzelne Blatt. Viele Maler hätten vielleicht gedacht, das ist nur etwas, das man in den Hintergrund stellt, um ihren Kopf zu rahmen. Niemand wird so genau hinschauen.

Nicht Leonardo. Wie hart er an einem Teil eines Gemäldes arbeitete, hing überhaupt nicht davon ab, wie genau er erwartete, dass jemand es sich ansehen würde. Er war wie Michael Jordan. Unerbittlich.

Unerbittlichkeit gewinnt, weil im Aggregat unsichtbare Details sichtbar werden. Wenn Leute an dem Porträt von Ginevra de Benci vorbeigehen, wird ihre Aufmerksamkeit oft sofort darauf gelenkt, noch bevor sie auf das Etikett schauen und bemerken, dass es Leonardo da Vinci heißt. All diese unsichtbaren Details verbinden sich zu etwas, das einfach atemberaubend ist, wie tausend kaum hörbare Stimmen, die alle im Gleichklang singen.

Große Software erfordert ebenfalls eine fanatische Hingabe an Schönheit. Wenn man in gute Software hineinschaut, stellt man fest, dass auch Teile, die niemand jemals sehen soll, schön sind. Ich behaupte nicht, dass ich großartige Software schreibe, aber ich weiß, dass ich mich, wenn es um Code geht, so verhalte, dass ich für verschreibungspflichtige Medikamente in Frage käme, wenn ich mich im Alltag genauso verhalten würde. Es macht mich verrückt, Code zu sehen, der schlecht eingerückt ist oder hässliche Variablennamen verwendet.

Wenn ein Hacker nur ein Implementierer wäre, der eine Spezifikation in Code umwandelt, dann könnte er sie einfach von einem Ende zum anderen durcharbeiten, wie jemand, der einen Graben gräbt. Aber wenn der Hacker ein Schöpfer ist, müssen wir die Inspiration berücksichtigen.

Beim Hacken, wie beim Malen, kommt die Arbeit in Zyklen. Manchmal ist man begeistert von einem neuen Projekt und möchte sechzehn Stunden am Tag daran arbeiten. Manchmal scheint nichts interessant zu sein.

Um gute Arbeit zu leisten, muss man diese Zyklen berücksichtigen, weil sie davon beeinflusst werden, wie man darauf reagiert. Wenn man ein Auto mit Schaltgetriebe an einem Hügel fährt, muss man manchmal die Kupplung lösen, um ein Abwürgen zu vermeiden. Das Lösen kann ebenfalls verhindern, dass die Ambitionen zum Stillstand kommen. Sowohl beim Malen als auch beim Hacken gibt es einige Aufgaben, die erschreckend ehrgeizig sind, und andere, die beruhigend routinemäßig sind. Es ist eine gute Idee, sich ein paar einfache Aufgaben für Momente aufzusparen, in denen man sonst zum Stillstand kommen würde.

Beim Hacken kann das buchstäblich bedeuten, Fehler zu speichern. Ich mag Debugging: Es ist das einzige Mal, dass Hacken so geradlinig ist, wie die Leute denken. Man hat ein völlig eingeschränktes Problem, und man muss es nur lösen. Dein Programm soll x tun. Stattdessen tut es y. Wo geht es schief? Du weißt, dass du am Ende gewinnen wirst. Es ist so entspannend wie das Streichen einer Wand.

Das Beispiel der Malerei kann uns nicht nur lehren, wie wir unsere eigene Arbeit managen, sondern auch, wie wir zusammenarbeiten können. Viele der großen Kunstwerke der Vergangenheit sind das Werk mehrerer Hände, obwohl vielleicht nur ein Name an der Wand daneben im Museum steht. Leonardo war ein Lehrling in der Werkstatt von Verrocchio und malte einen der Engel in seiner Taufe Christi. Solche Dinge waren die Regel, nicht die Ausnahme. Michelangelo galt als besonders engagiert, weil er darauf bestand, alle Figuren an der Decke der Sixtinischen Kapelle selbst zu malen.

Soweit ich weiß, haben Maler, wenn sie gemeinsam an einem Gemälde gearbeitet haben, nie an denselben Teilen gearbeitet. Es war üblich, dass der Meister die Hauptfiguren malte und die Assistenten die anderen und den Hintergrund malten. Aber man hatte nie einen Kerl, der über die Arbeit eines anderen malte.

Ich denke, das ist das richtige Modell für die Zusammenarbeit in der Software auch. Treibt es nicht zu weit. Wenn ein Stück Code von drei oder vier verschiedenen Leuten gehackt wird, von denen keiner wirklich Eigentümer ist, wird es am Ende wie ein Gemeinschaftsraum aussehen. Es wird dazu neigen, sich trostlos und verlassen anzufühlen und Schmutz anzuhäufen. Der richtige Weg, um zusammenzuarbeiten, ist meiner Meinung nach, Projekte in scharf definierte Module aufzuteilen, die jeweils einen eindeutigen Eigentümer haben, und mit Schnittstellen zwischen ihnen, die so sorgfältig entworfen und, wenn möglich, so artikuliert sind wie Programmiersprachen.

Wie die Malerei ist die meiste Software für ein menschliches Publikum gedacht. Und so müssen Hacker, wie Maler, Empathie haben, um wirklich großartige Arbeit zu leisten. Man muss in der Lage sein, die Dinge aus der Sicht des Benutzers zu sehen.

Als Kind wurde mir immer gesagt, ich solle die Dinge aus der Sicht eines anderen betrachten. Was das in der Praxis immer bedeutete, war, das zu tun, was jemand anderes wollte, anstatt das, was ich wollte. Das gab der Empathie natürlich einen schlechten Ruf, und ich legte Wert darauf, sie nicht zu kultivieren.

Mann, lag ich falsch. Es stellt sich heraus, dass es praktisch das Geheimnis des Erfolgs ist, die Dinge aus der Sicht anderer Menschen zu betrachten. Es bedeutet nicht unbedingt, selbstlos zu sein. Ganz im Gegenteil. Zu verstehen, wie jemand anderes die Dinge sieht, impliziert nicht, dass man in seinem Interesse handelt; in manchen Situationen - im Krieg zum Beispiel - möchte man genau das Gegenteil tun. [4]

Die meisten Macher machen Dinge für ein menschliches Publikum. Und um ein Publikum zu fesseln, muss man verstehen, was es braucht. Fast alle der größten Gemälde sind zum Beispiel Gemälde von Menschen, weil Menschen das sind, woran Menschen interessiert sind.

Empathie ist wahrscheinlich der wichtigste Unterschied zwischen einem guten und einem großartigen Hacker. Manche Hacker sind ziemlich intelligent, aber wenn es um Empathie geht, sind sie praktisch Solipsisten. Es ist für solche Leute schwer, großartige Software zu entwerfen [5], weil sie die Dinge nicht aus der Sicht des Benutzers sehen können.

Eine Möglichkeit, um zu beurteilen, wie gut Menschen in Empathie sind, ist, ihnen zuzusehen, wie sie einem technisch Unkundigen eine technische Frage erklären. Wir kennen wahrscheinlich alle Leute, die, obwohl sie ansonsten intelligent sind, einfach komisch schlecht darin sind. Wenn jemand sie auf einer Dinnerparty fragt, was eine Programmiersprache ist, werden sie etwas sagen wie „Oh, eine Hochsprache ist das, was der Compiler als Eingabe verwendet, um Objektcode zu generieren.“ Hochsprache? Compiler? Objektcode? Jemand, der nicht weiß, was eine Programmiersprache ist, weiß offensichtlich auch nicht, was diese Dinge sind.

Ein Teil dessen, was Software tun muss, ist, sich selbst zu erklären. Um also gute Software zu schreiben, muss man verstehen, wie wenig Benutzer verstehen. Sie werden ohne Vorbereitung an die Software herangehen, und sie sollte besser das tun, was sie vermuten, weil sie das Handbuch nicht lesen werden. Das beste System, das ich in dieser Hinsicht je gesehen habe, war der ursprüngliche Macintosh im Jahr 1985. Er tat, was Software fast nie tut: Er funktionierte einfach. [6]

Auch Quellcode sollte sich selbst erklären. Wenn ich die Leute dazu bringen könnte, sich nur ein Zitat über Programmierung zu merken, dann wäre es das am Anfang von Structure and Interpretation of Computer Programs.

Programme sollten für Menschen geschrieben werden, und nur nebenbei für Maschinen zur Ausführung.

Man muss Empathie nicht nur für seine Benutzer, sondern auch für seine Leser haben. Es liegt in Ihrem Interesse, denn Sie werden einer von ihnen sein. Viele Hacker haben ein Programm geschrieben, nur um bei der Rückkehr zu ihm sechs Monate später festzustellen, dass sie keine Ahnung haben, wie es funktioniert. Ich kenne mehrere Leute, die nach solchen Erfahrungen Perl abgeschworen haben. [7]

Mangelnde Empathie wird mit Intelligenz in Verbindung gebracht, so sehr, dass es an manchen Orten sogar eine Art Mode dafür gibt. Aber ich glaube nicht, dass es eine Korrelation gibt. Man kann in Mathematik und Naturwissenschaften gut sein, ohne Empathie lernen zu müssen, und die Leute in diesen Bereichen sind in der Regel intelligent, so dass die beiden Eigenschaften in Verbindung gebracht wurden. Aber es gibt auch viele dumme Leute, die schlecht in Empathie sind. Hören Sie sich einfach die Leute an, die mit Fragen in Talkshows anrufen. Sie stellen, was auch immer sie fragen, auf so umständliche Weise, dass die Moderatoren die Frage oft für sie umformulieren müssen.

Wenn Hacking also wie Malen und Schreiben funktioniert, ist es dann genauso cool? Schließlich hat man nur ein Leben. Man könnte es ja auch damit verbringen, an etwas Großem zu arbeiten.

Leider ist die Frage schwer zu beantworten. Es gibt immer eine große zeitliche Verzögerung beim Prestige. Es ist wie das Licht eines fernen Sterns. Malerei hat jetzt Prestige wegen der großartigen Arbeit, die Menschen vor fünfhundert Jahren geleistet haben. Damals hielt niemand diese Gemälde für so wichtig wie wir heute. Es wäre den Menschen damals sehr seltsam vorgekommen, dass Federico da Montefeltro, der Herzog von Urbino, eines Tages vor allem als der Typ mit der seltsamen Nase in einem Gemälde von Piero della Francesca bekannt sein würde.

Auch wenn ich zugebe, dass Hacking jetzt nicht so cool aussieht wie Malerei, sollten wir uns daran erinnern, dass Malerei in ihren Glanzzeiten nicht so cool aussah wie heute.

Was wir mit einiger Sicherheit sagen können, ist, dass dies die Glanzzeiten des Hackings sind. In den meisten Bereichen wird die große Arbeit frühzeitig geleistet. Die Gemälde, die zwischen 1430 und 1500 entstanden sind, sind immer noch unübertroffen. Shakespeare erschien gerade, als das professionelle Theater entstand,

und schob das Medium so weit, dass jeder Dramatiker seitdem in seinem Schatten leben musste. Albrecht Dürer tat dasselbe mit der Gravur und Jane Austen mit dem Roman.

Immer wieder sehen wir das gleiche Muster. Ein neues Medium erscheint, und die Leute sind so begeistert davon, dass sie in den ersten beiden Generationen die meisten seiner Möglichkeiten erforschen. Hacking scheint sich jetzt in dieser Phase zu befinden.

Malerei war in Leonardos Zeit nicht so cool, wie seine Arbeit dazu beigetragen hat, sie zu machen. Wie cool Hacking sich herausstellt, hängt davon ab, was wir mit diesem neuen Medium machen können.

Anmerkungen

[1] Der größte Schaden, den die Fotografie der Malerei zugefügt hat, mag die Tatsache sein, dass sie den besten Tagesjob ausgelöscht hat. Die meisten der großen Maler der Geschichte haben sich durch das Malen von Porträts ernährt.

[2] Mir wurde gesagt, dass Microsoft Mitarbeiter davon abrät, zu Open-Source-Projekten beizutragen, selbst in ihrer Freizeit. Aber so viele der besten Hacker arbeiten an Open-Source- Projekten, dass die Hauptwirkung dieser Politik sein könnte, dass sie keine erstklassigen Programmierer einstellen können.

[3] Was man im College über Programmieren lernt, ist ähnlich wie das, was man über Bücher, Kleidung oder Dating lernt: welchen schlechten Geschmack man in der High School hatte.

[4] Hier ist ein Beispiel für angewandte Empathie. Bei Viaweb, wenn wir uns nicht zwischen zwei Alternativen entscheiden konnten, fragten wir, was würden unsere Konkurrenten am meisten hassen? An einem Punkt fügte ein Konkurrent eine Funktion zu seiner Software hinzu, die im Grunde genommen nutzlos war, aber da sie eine der wenigen war, die sie hatten, die wir nicht hatten, machten sie viel daraus in der Fachpresse. Wir hätten versuchen können, zu erklären, dass die Funktion nutzlos war, aber wir entschieden, dass es unseren Konkurrenten mehr ärgern würde, wenn wir sie einfach selbst implementieren würden, also hackten wir an einem Nachmittag unsere eigene Version zusammen.

[5] Außer Texteditoren und Compilern. Hacker brauchen keine Empathie, um diese zu entwerfen, weil sie selbst typische Benutzer sind.

[6] Nun, fast. Sie haben den verfügbaren RAM etwas überschritten, was zu viel unnötigem Datenaustausch führte, aber dies konnte innerhalb weniger Monate durch den Kauf eines zusätzlichen Laufwerks behoben werden.

[7] Der Weg, um Programme lesbar zu machen, ist nicht, sie mit Kommentaren zu füllen. Ich würde Abelson und Sussman's Zitat noch einen Schritt weiterführen. Programmiersprachen sollten so konzipiert sein, dass sie Algorithmen ausdrücken, und nur nebenbei Computern sagen, wie sie sie ausführen sollen. Eine gute Programmiersprache sollte besser geeignet sein, Software zu erklären als Englisch. Man sollte nur Kommentare benötigen, wenn es eine Art von Patch gibt, vor dem man die Leser warnen muss, genau wie auf einer Straße nur Pfeile an Stellen mit unerwartet scharfen Kurven angebracht sind.

Danke an Trevor Blackwell, Robert Morris, Dan Giffin und Lisa Randall für das Lesen von Entwürfen dieses Textes, und an Henry Leitner und Larry Finkelstein für die Einladung zum Vortrag.