HACKER UND MALER

Mai 2003

(Dieser Essay stammt aus einem Gastvortrag an der Harvard-Universität, der eine frühere Rede an der Northeastern beinhaltete.)

Als ich mein Studium der Informatik abgeschlossen hatte, ging ich an die Kunstschule, um Malerei zu studieren. Viele Menschen schienen überrascht zu sein, dass jemand, der sich für Computer interessiert, auch an Malerei interessiert sein könnte. Sie schienen zu denken, dass Hacking und Malerei sehr unterschiedliche Arten von Arbeit sind – dass Hacking kalt, präzise und methodisch ist, während Malerei der frenetische Ausdruck eines urtümlichen Triebs ist.

Beide Bilder sind falsch. Hacking und Malerei haben viel gemeinsam. Tatsächlich gehören Hacker und Maler zu den ähnlichsten Menschen, die ich kenne.

Was Hacker und Maler gemeinsam haben, ist, dass sie beide Macher sind. Zusammen mit Komponisten, Architekten und Schriftstellern versuchen Hacker und Maler, gute Dinge zu schaffen. Sie betreiben nicht per se Forschung, aber wenn sie im Laufe des Schaffens guter Dinge 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 schwach verwandten Bereichen, die durch einen historischen Zufall zusammengeworfen wurden, wie Jugoslawien. Am einen Ende gibt es Menschen, die wirklich Mathematiker sind, aber das, was sie tun, Informatik nennen, um DARPA-Stipendien zu erhalten. In der Mitte gibt es Menschen, die an etwas wie der Naturgeschichte von Computern arbeiten – sie studieren das Verhalten von Algorithmen zur Datenübertragung durch Netzwerke, zum Beispiel. Und am anderen Ende gibt es die Hacker, die versuchen, interessante Software zu schreiben, und für die Computer nur ein Medium des Ausdrucks sind, so wie Beton für Architekten oder Farbe für Maler. Es ist, als ob Mathematiker, Physiker und Architekten alle im gleichen Fachbereich sein müssten.

Manchmal wird das, was die Hacker tun, "Software-Engineering" genannt, aber dieser Begriff ist ebenso irreführend. Gute Software-Designer sind nicht mehr Ingenieure 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 macht.

Was und wie sollten nicht zu stark getrennt werden. Sie fordern Probleme heraus, wenn Sie versuchen, zu entscheiden, was zu tun ist, ohne zu verstehen, wie man es macht. Aber Hacking kann sicherlich mehr sein, als nur zu entscheiden, wie man eine Spezifikation umsetzt. Im besten Fall ist es, die Spezifikation zu erstellen – obwohl sich herausstellt, dass der beste Weg, dies zu tun, darin besteht, sie umzusetzen.

Vielleicht wird eines Tages "Informatik", wie Jugoslawien, in ihre Einzelteile zerlegt. Das könnte eine gute Sache sein. Besonders wenn es Unabhängigkeit für mein Heimatland, das Hacking, bedeuten würde.

All diese verschiedenen Arten von Arbeiten in einem Fachbereich zusammenzufassen, mag administrativ praktisch sein, aber es ist verwirrend intellektuell. Das ist der andere Grund, warum ich den Namen "Informatik" nicht mag. Man könnte argumentieren, dass die Menschen in der Mitte etwas wie eine experimentelle Wissenschaft betreiben. Aber die Menschen an beiden Enden, die Hacker und die Mathematiker, betreiben tatsächlich keine Wissenschaft.

Die Mathematiker scheinen sich darüber nicht zu stören. Sie machen sich fröhlich an die Arbeit, um Theoreme zu beweisen, wie die anderen Mathematiker im Mathematikbereich, und hören wahrscheinlich bald auf, zu bemerken, dass das Gebäude, in dem sie arbeiten, außen "Informatik" steht. Aber für die Hacker ist dieses Etikett ein Problem. Wenn das, was sie tun, Wissenschaft genannt wird, fühlen sie sich, als müssten sie wissenschaftlich handeln. Anstatt das zu tun, was sie wirklich tun wollen, nämlich schöne Software zu entwerfen, haben Hacker an Universitäten und Forschungslabors das Gefühl, sie müssten Forschungsarbeiten schreiben.

Im besten Fall sind die Arbeiten nur eine Formalität. Hacker schreiben coole Software und schreiben dann ein Papier darüber, und das Papier wird zu einem Stellvertreter für die Leistung, die durch die Software repräsentiert wird. Aber oft führt diese Diskrepanz zu Problemen. Es ist leicht, sich von der Schaffung schöner Dinge wegzubewegen und hässliche Dinge zu schaffen, die geeignetere Themen für Forschungsarbeiten sind.

Leider sind schöne Dinge nicht immer die besten Themen für Arbeiten. Nummer eins, Forschung muss originell sein – und wie jeder, der eine Doktorarbeit geschrieben hat, weiß, ist der beste Weg, sicherzustellen, dass man unberührtes Terrain erkundet, ein Stück Boden zu beanspruchen, das niemand will. Nummer zwei, Forschung muss substanziell sein – und umständliche Systeme liefern gehaltvollere Arbeiten, weil man über die Hindernisse schreiben kann, die man überwinden muss, um Dinge zu erledigen. Nichts liefert gehaltvolle Probleme wie der Ausgangspunkt mit den falschen Annahmen. Der Großteil der KI ist ein Beispiel für diese Regel; wenn man annimmt, dass Wissen als Liste von Prädikatslogik-Ausdrücken dargestellt werden kann, deren Argumente abstrakte Konzepte repräsentieren, hat man viele Papiere zu schreiben, wie man das zum Laufen bringt. Wie Ricky Ricardo früher sagte: "Lucy, du hast viel zu erklären."

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

Warum beurteilen Universitäten und Forschungslabors Hacker weiterhin nach Veröffentlichungen? Aus demselben Grund, aus dem "scholastische Eignung" durch einfältige standardisierte Tests gemessen wird, oder die Produktivität von Programmierern in Zeilen Code gemessen wird. Diese Tests sind leicht anzuwenden, und es gibt nichts so Verlockendes wie einen einfachen Test, der irgendwie funktioniert.

Zu messen, was Hacker tatsächlich versuchen zu tun, schöne Software zu entwerfen, wäre viel schwieriger. Man braucht ein gutes Gestaltungsgefühl, um gutes Design zu beurteilen. Und es gibt keine Korrelation, außer möglicherweise einer negativen, zwischen der Fähigkeit der Menschen, gutes Design zu erkennen, und ihrem Vertrauen, dass sie es können.

Der einzige externe Test ist die Zeit. Im Laufe der Zeit tendieren schöne Dinge dazu, zu gedeihen, und hässliche Dinge tendieren dazu, verworfen zu werden. Leider können die Zeiträume, die damit verbunden sind, länger sein als menschliche Lebenszeiten. Samuel Johnson sagte, es dauere hundert Jahre, bis der Ruf eines Schriftstellers konvergiert. Man muss warten, bis die einflussreichen Freunde des Schriftstellers sterben, und dann, bis alle ihre Anhänger sterben.

Ich denke, Hacker müssen sich einfach damit abfinden, dass ein großer zufälliger Faktor in ihren Ruf einfließt. In dieser Hinsicht unterscheiden sie sich nicht von anderen Machern. Tatsächlich sind sie im Vergleich dazu glücklich. Der Einfluss der Mode ist im Hacking nicht annähernd so groß wie in der Malerei.

Es gibt Schlimmeres, als wenn Menschen Ihre Arbeit missverstehen. Eine schlimmere Gefahr ist, dass Sie Ihre Arbeit selbst missverstehen. Verwandte Bereiche sind der Ort, an dem Sie nach Ideen suchen. Wenn Sie sich im Fachbereich Informatik befinden, gibt es eine natürliche Versuchung zu glauben, dass Hacking die angewandte Version dessen ist, was die theoretische Informatik die Theorie ist. Während meiner gesamten Zeit im Graduiertenstudium hatte ich ein unangenehmes Gefühl im Hinterkopf, dass ich mehr Theorie wissen sollte, und dass es sehr nachlässig von mir war, all diese Dinge innerhalb von drei Wochen nach der Abschlussprüfung vergessen zu haben.

Jetzt erkenne ich, dass ich falsch lag. Hacker müssen die Theorie der Berechnung ungefähr so gut verstehen wie Maler die Chemie der Farben verstehen müssen. Man muss wissen, wie man Zeit- und Raumkomplexität berechnet und über Turing-Vollständigkeit Bescheid weiß. Man möchte sich vielleicht auch zumindest das Konzept einer Zustandsmaschine merken, falls man einen Parser oder eine reguläre Ausdrucksbibliothek schreiben muss. Maler müssen in der Tat deutlich mehr über die Chemie der Farben wissen als das.

Ich habe festgestellt, dass die besten Ideenquellen nicht die anderen Bereiche sind, die das Wort "Computer" in ihren Namen haben, sondern die anderen Bereiche, die von Machern bewohnt werden. Die Malerei war eine viel reichhaltigere Ideenquelle als die Theorie der Berechnung.

Zum Beispiel wurde mir im College beigebracht, dass man ein Programm vollständig auf Papier ausarbeiten sollte, bevor man sich auch nur einem Computer nähert. Ich stellte fest, dass ich nicht auf diese Weise programmierte. Ich stellte fest, dass ich es mochte, vor einem Computer zu sitzen, nicht vor einem Stück Papier. Schlimmer noch, anstatt geduldig ein vollständiges Programm zu schreiben und mir zu versichern, dass es korrekt war, neigte ich dazu, einfach Code zu produzieren, der hoffnungslos kaputt war, und ihn allmählich in Form zu bringen. Debugging, so wurde mir beigebracht, war eine Art letzter Durchgang, bei dem man Tippfehler und Versäumnisse entdeckte. So wie ich arbeitete, schien es, als bestünde Programmierung aus Debugging.

Lange Zeit fühlte ich mich schlecht dabei, genau wie ich mich einmal schlecht fühlte, weil ich meinen Bleistift nicht so hielt, wie sie es mir in der Grundschule beigebracht hatten. Hätte ich nur zu den anderen Machern, den Malern oder den Architekten, geschaut, 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 sie mir im College das Programmieren beigebracht haben, völlig falsch. Man sollte Programme so entwickeln, wie man sie schreibt, genauso wie es Schriftsteller, Maler und Architekten tun.

Das zu erkennen hat echte Auswirkungen auf das Softwaredesign. Das bedeutet, dass eine Programmiersprache vor allem formbar sein sollte. Eine Programmiersprache ist zum Nachdenken über Programme gedacht, nicht zum Ausdrücken von Programmen, die man bereits gedacht hat. Sie sollte ein Bleistift, nicht ein Stift sein. Statische Typisierung wäre eine gute Idee, wenn die Leute tatsächlich Programme so schreiben würden, wie sie es mir im College beigebracht haben. Aber so schreibt keiner der Hacker, die ich kenne, Programme. Wir brauchen eine Sprache, die es uns ermöglicht, zu kritzeln und zu verwischen und zu verschmieren, nicht eine Sprache, bei der man mit einer Teetasse voller Typen auf dem Schoß sitzen und höfliche Gespräche mit einer strengen alten Tante namens Compiler führen muss.

Während wir gerade beim Thema statische Typisierung sind, wird uns die Identifikation mit den Machern vor einem anderen Problem bewahren, das die Wissenschaften plagt: Mathe-Neid. Jeder in den Wissenschaften glaubt heimlich, dass Mathematiker schlauer sind als sie. Ich denke, Mathematiker glauben das auch. Jedenfalls führt das dazu, dass Wissenschaftler dazu neigen, ihre Arbeit so mathematisch wie möglich erscheinen zu lassen. In einem Bereich wie der Physik schadet das wahrscheinlich nicht viel, aber je weiter man sich von den Naturwissenschaften entfernt, desto mehr wird es zu einem Problem.

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

Wenn Hacker sich mit anderen Machern identifizieren würden, wie Schriftstellern und Maler, würden sie sich nicht verleitet fühlen, dies zu tun. Schriftsteller und Maler leiden nicht unter Mathe-Neid. Sie haben das Gefühl, dass sie etwas völlig Unabhängiges tun. Das sind Hacker, denke ich, auch.

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

Ich habe das selbst erst vor kurzem entdeckt. Als Yahoo Viaweb kaufte, fragten sie mich, was ich tun wollte. Ich hatte nie viel für die geschäftliche Seite übrig und sagte, dass ich einfach hacken wollte. Als ich zu Yahoo kam, stellte ich fest, dass das, was Hacking für sie bedeutete, die Implementierung von Software war, nicht deren Design. Programmierer wurden als Techniker angesehen, die die Visionen (wenn das das Wort ist) der Produktmanager in Code übersetzten.

Das scheint der Standardplan in großen Unternehmen zu sein. Sie tun es, weil es die Standardabweichung des Ergebnisses verringert. Nur ein kleiner Prozentsatz von Hackern kann tatsächlich Software entwerfen, und es ist für die Leute, die ein Unternehmen leiten, schwer, diese herauszufinden. Anstatt 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 das Design umsetzen.

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 Sie Schwingungen dämpfen, verlieren Sie die Hochpunkte ebenso wie die Tiefpunkte. Das ist für große Unternehmen kein Problem, denn sie gewinnen nicht, indem sie großartige Produkte herstellen. Große Unternehmen gewinnen, indem sie weniger schlecht sind als andere große Unternehmen.

Wenn Sie also einen Weg finden können, in einen Designkrieg mit einem Unternehmen einzutreten, das groß genug ist, dass seine Software von Produktmanagern entworfen wird, werden sie niemals mit Ihnen Schritt halten können. Diese Gelegenheiten sind jedoch nicht leicht zu finden. Es ist schwer, ein großes Unternehmen in einen Designkrieg zu verwickeln, genauso wie es schwer ist, einen Gegner in einer Burg im Nahkampf zu bekämpfen. Es wäre ziemlich einfach, einen besseren Textverarbeiter als Microsoft Word zu schreiben, zum Beispiel, aber Microsoft, innerhalb der Burg ihres Betriebssystemmonopols, würde wahrscheinlich nicht einmal bemerken, wenn Sie es tun würden.

Der Ort, um Designkriege zu führen, sind neue Märkte, in denen noch niemand es geschafft hat, irgendwelche Befestigungen zu errichten. Dort können Sie groß gewinnen, indem Sie den mutigen Ansatz für das Design wählen und die gleichen Personen sowohl das Produkt entwerfen als auch umsetzen. Microsoft selbst tat dies zu Beginn. Das tat auch Apple. Und Hewlett-Packard. Ich vermute, fast jedes erfolgreiche Startup hat das getan.

Eine Möglichkeit, großartige Software zu erstellen, besteht darin, Ihr eigenes Startup zu gründen. Es gibt jedoch zwei Probleme damit. Eines ist, dass Sie in einem Startup so viel mehr tun müssen, als nur Software zu schreiben. Bei Viaweb hielt ich mich für glücklich, wenn ich ein Viertel der Zeit hacken konnte. Und die Dinge, die ich in den anderen drei Vierteln der Zeit tun musste, reichten von mühsam bis beängstigend. 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, dass ich im Zahnarztstuhl saß, auf die Bohrmaschine wartete und mich fühlte, als wäre ich im Urlaub.

Das andere Problem mit Startups ist, dass es nicht viel Überlappung zwischen der Art von Software gibt, die Geld einbringt, und der Art, die interessant zu schreiben ist. Programmiersprachen sind interessant zu schreiben, und Microsofts erstes Produkt war eine, in der Tat, aber niemand wird jetzt für Programmiersprachen bezahlen. Wenn Sie Geld verdienen wollen, sind Sie 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, die Spaß machen, 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 Gorillakostüm in einem Stand auf einer Messe zu stehen. Romane zu schreiben, zahlt sich nicht so gut aus wie Werbetexte für Müllentsorgungsanlagen zu schreiben. Und Programmiersprachen zu hacken, zahlt sich nicht so gut aus wie herauszufinden, wie man die Legacy-Datenbank eines Unternehmens mit ihrem Webserver verbindet.

Ich denke, die Antwort auf dieses Problem, im Fall von Software, ist ein Konzept, das fast allen Machern bekannt ist: der Tagesjob. Dieser Ausdruck begann mit Musikern, die nachts auftreten. Allgemeiner bedeutet es, dass Sie eine Art von Arbeit haben, die Sie für Geld tun, und eine andere aus Liebe.

Fast alle Macher haben in den frühen Phasen ihrer Karriere Tagesjobs. Maler und Schriftsteller tun dies notorisch. Wenn Sie Glück haben, können Sie einen Tagesjob bekommen, der eng mit Ihrer eigentlichen Arbeit verbunden ist. Musiker scheinen oft in Plattenläden zu arbeiten. Ein Hacker, der an einer Programmiersprache oder einem Betriebssystem arbeitet, könnte ebenfalls in der Lage sein, einen Tagesjob zu bekommen, in dem er es nutzt. [1]

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

Es scheint mir überraschend, dass ein Arbeitgeber zögern würde, Hackern zu erlauben, an Open-Source-Projekten zu arbeiten. Bei Viaweb wären wir zögerlich gewesen, jemanden einzustellen, der das nicht tat. Als wir Programmierer interviewten, war das Hauptaugenmerk darauf, welche Art von Software sie in ihrer Freizeit schrieben. Man kann nichts wirklich gut machen, es sei denn, man liebt es, und wenn man gerne hackt, wird man unweigerlich an eigenen Projekten arbeiten. [2]

Da Hacker Macher sind und keine Wissenschaftler, ist der richtige Ort, um nach Metaphern zu suchen, nicht in den Wissenschaften, sondern unter anderen Arten von Machern. Was kann die Malerei uns über Hacking lehren?

Eine Sache, die wir aus dem Beispiel der Malerei lernen oder zumindest bestätigen können, ist, wie man hacken lernt. Man lernt zu malen, indem man es hauptsächlich tut. Gleiches gilt für das Hacken. Die meisten Hacker lernen nicht, zu hacken, indem sie Hochschulkurse in Programmierung belegen. Sie lernen zu hacken, indem sie im Alter von dreizehn Jahren eigene Programme schreiben. Selbst in Hochschulklassen lernt man hauptsächlich durch Hacken. [3]

Da Maler eine Spur von Arbeit hinterlassen, können Sie beobachten, wie sie durch Tun lernen. Wenn Sie die Arbeiten eines Malers in chronologischer Reihenfolge betrachten, werden Sie feststellen, dass jedes Gemälde auf Dingen aufbaut, die in früheren Gemälden gelernt wurden. Wenn es in einem Gemälde etwas gibt, das sehr gut funktioniert, können Sie normalerweise Version 1 davon in kleinerer Form in einem früheren Gemälde finden.

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 Grund auf neu zu beginnen, anstatt jahrelang an einem Projekt zu arbeiten und zu versuchen, all ihre späteren Ideen als Überarbeitungen zu integrieren.

Die Tatsache, dass Hacker lernen, zu hacken, indem sie es tun, ist ein weiteres Zeichen dafür, wie unterschiedlich Hacking von den Wissenschaften ist. Wissenschaftler lernen Wissenschaft nicht, indem sie sie tun, sondern indem sie Labore und Aufgaben lösen. Wissenschaftler beginnen mit Arbeiten, die perfekt sind, im Sinne dessen, dass sie nur versuchen, Arbeiten zu reproduzieren, die jemand anderes bereits für sie erledigt hat. Schließlich erreichen sie den Punkt, an dem sie originelle Arbeiten leisten können. Während Hacker von Anfang an originelle Arbeiten leisten; sie sind einfach nur sehr schlecht. Hacker beginnen also originell und werden gut, während Wissenschaftler gut beginnen und originell werden.

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 ist es Teil der traditionellen Ausbildung von Malern, die Werke der großen Meister zu kopieren, weil das Kopieren einen zwingt, genau hinzusehen, wie ein Gemälde gemacht wird.

Schriftsteller tun dies ebenfalls. Benjamin Franklin lernte zu schreiben, indem er die Punkte in den Essays von Addison und Steele zusammenfasste und dann versuchte, sie nachzuvollziehen. Raymond Chandler tat dasselbe mit Detektivgeschichten.

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

Ein weiteres Beispiel, das wir 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. Allmählich werden die Details ausgefüllt. Aber es ist nicht nur ein Prozess des Ausfüllens. Manchmal stellt sich heraus, dass die ursprünglichen Pläne fehlerhaft sind. Zahlreiche Gemälde, wenn man sie in Röntgenaufnahmen betrachtet, stellen sich als solche heraus, die Gliedmaßen haben, die verschoben wurden, oder Gesichtszüge, die neu justiert wurden.

Hier ist ein Fall, in dem wir von der Malerei lernen können. Ich denke, Hacking sollte auch so funktionieren. Es ist unrealistisch, zu erwarten, dass die Spezifikationen für ein Programm perfekt sind. Man ist besser dran, wenn man dies von Anfang an zugibt und Programme so schreibt, dass die Spezifikationen unterwegs geändert werden können.

(Die Struktur großer Unternehmen macht es ihnen schwer, dies zu tun, also ist hier ein weiterer Ort, an dem Startups einen Vorteil haben.)

Jeder weiß mittlerweile vermutlich über die Gefahr der vorzeitigen Optimierung Bescheid. Ich denke, wir sollten uns ebenso um vorzeitiges Design sorgen – zu früh zu entscheiden, was ein Programm tun sollte.

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

Das klingt wie ein Paradoxon, aber ein großartiges Gemälde muss besser sein, als es sein muss. Zum Beispiel, als Leonardo das Porträt von Ginevra de Benci in der National Gallery malte, stellte er einen Wacholderbusch hinter ihren Kopf. Darüber malte er sorgfältig jedes einzelne Blatt. Viele Maler hätten gedacht, das ist nur etwas, das man in den Hintergrund setzen kann, um ihren Kopf zu rahmen. Niemand wird so genau darauf schauen.

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

Unermüdlichkeit gewinnt, denn im Aggregat werden unsichtbare Details sichtbar. Wenn Menschen am Porträt von Ginevra de Benci vorbeigehen, wird ihre Aufmerksamkeit oft sofort darauf gelenkt, noch bevor sie das Etikett lesen und bemerken, dass es von Leonardo da Vinci stammt. All diese unsichtbaren Details kombinieren sich zu etwas, das einfach atemberaubend ist, wie tausend kaum hörbare Stimmen, die alle im Einklang singen.

Große Software erfordert ebenfalls eine fanatische Hingabe an Schönheit. Wenn Sie in gute Software schauen, werden Sie feststellen, dass Teile, die niemand jemals sehen soll, ebenfalls schön sind. Ich behaupte nicht, dass ich großartige Software schreibe, aber ich weiß, dass ich mich in Bezug auf Code so verhalte, dass ich anspruchsberechtigt für verschreibungspflichtige Medikamente wäre, wenn ich das alltägliche Leben auf die gleiche Weise angehen würde. Es macht mich verrückt, Code zu sehen, der schlecht eingerückt ist, oder der hässliche Variablennamen verwendet.

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

Im Hacking, wie in der Malerei, kommt die Arbeit in Zyklen. Manchmal ist man von einem neuen Projekt so begeistert, dass man sechzehn Stunden am Tag daran arbeiten möchte. Zu anderen Zeiten scheint nichts interessant zu sein.

Um gute Arbeit zu leisten, muss man diese Zyklen berücksichtigen, denn sie werden davon beeinflusst, wie man auf sie reagiert. Wenn man ein Auto mit Schaltgetriebe an einem Hügel fährt, muss man manchmal die Kupplung loslassen, um ein Abwürgen zu vermeiden. Das Loslassen kann ebenfalls verhindern, dass die Ambition ins Stocken gerät. In der Malerei und im Hacking gibt es einige Aufgaben, die erschreckend ehrgeizig sind, und andere, die tröstlich routiniert sind. Es ist eine gute Idee, einige einfache Aufgaben für Momente aufzusparen, in denen man sonst ins Stocken geraten würde.

Im Hacking kann das wörtlich bedeuten, Bugs aufzusparen. Ich mag Debugging: Es ist der eine Moment, in dem Hacking so unkompliziert ist, wie die Leute denken, dass es ist. Man hat ein völlig eingeschränktes Problem, und alles, was man tun muss, ist, es zu lösen. Ihr Programm soll x tun. Stattdessen tut es y. Wo geht es schief? Man weiß, dass man am Ende gewinnen wird. 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. Ein Großteil der großen Kunst der Vergangenheit ist das Werk mehrerer Hände, obwohl es im Museum nur einen Namen an der Wand daneben geben mag. Leonardo war ein Lehrling in der Werkstatt von Verrocchio und malte einen der Engel in seinem Taufe Christi. So etwas war die Regel, nicht die Ausnahme. Michelangelo wurde als besonders engagiert angesehen, weil er darauf bestand, alle Figuren an der Decke der Sixtinischen Kapelle selbst zu malen.

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

Ich denke, das ist das richtige Modell für Zusammenarbeit in Software auch. Man sollte es nicht zu weit treiben. Wenn ein Stück Code von drei oder vier verschiedenen Personen bearbeitet wird, von denen keine wirklich Eigentümer ist, wird es am Ende wie ein Gemeinschaftsraum sein. Es wird tendenziell trostlos und verlassen wirken und sich mit Unrat ansammeln. Der richtige Weg zur Zusammenarbeit, denke ich, besteht darin, Projekte in scharf definierte Module zu unterteilen, von denen jedes einen bestimmten Eigentümer hat, und mit Schnittstellen zwischen ihnen, die ebenso sorgfältig gestaltet sind und, wenn möglich, so artikuliert 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 Perspektive des Benutzers zu sehen.

Als ich ein Kind war, wurde mir immer gesagt, ich solle die Dinge aus der Perspektive 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 machte es mir zur Aufgabe, sie nicht zu kultivieren.

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

Die meisten Macher schaffen Dinge für ein menschliches Publikum. Und um ein Publikum zu erreichen, muss man verstehen, was es braucht. Fast alle großartigen Gemälde sind Gemälde von Menschen, zum Beispiel, weil Menschen das sind, was Menschen interessiert.

Empathie ist wahrscheinlich der wichtigste Unterschied zwischen einem guten Hacker und einem großartigen. Einige Hacker sind ziemlich klug, aber wenn es um Empathie geht, sind sie praktisch Solipsisten. Es fällt solchen Menschen schwer, großartige Software zu entwerfen [5], weil sie nicht in der Lage sind, die Dinge aus der Perspektive des Benutzers zu sehen.

Eine Möglichkeit, zu erkennen, wie gut Menschen in Empathie sind, besteht darin, sie zu beobachten, wie sie jemandem ohne technischen Hintergrund eine technische Frage erklären. Wir kennen wahrscheinlich alle Menschen, die, obwohl sie sonst klug 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 die Benutzer verstehen. Sie werden ohne Vorbereitung auf die Software zukommen, und sie sollte besser das tun, was sie vermuten, dass sie es tun wird, denn sie werden das Handbuch nicht lesen. Das beste System, das ich je in dieser Hinsicht gesehen habe, war der ursprüngliche Macintosh von 1985. Er tat, was Software fast nie tut: Sie funktionierte einfach. [6]

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

Programme sollten für Menschen geschrieben werden, um sie zu lesen, und nur zufällig für Maschinen, um sie auszuführen.

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 festzustellen, dass sie sechs Monate später keine Ahnung haben, wie es funktioniert. Ich kenne mehrere Leute, die nach solchen Erfahrungen von Perl Abstand genommen haben. [7]

Mangelnde Empathie wird mit Intelligenz in Verbindung gebracht, bis zu dem Punkt, dass es sogar in einigen Kreisen eine Art Mode dafür gibt. Aber ich glaube nicht, dass es eine Korrelation gibt. Man kann in Mathe und den Naturwissenschaften gut abschneiden, ohne Empathie lernen zu müssen, und Menschen in diesen Bereichen sind tendenziell klug, sodass die beiden Eigenschaften in Verbindung gebracht wurden. Aber es gibt viele dumme Menschen, die auch schlecht in Empathie sind. Hören Sie sich nur die Menschen an, die mit Fragen in Talkshows anrufen. Sie stellen ihre Fragen so umständlich, dass die Moderatoren oft die Frage für sie umformulieren müssen.

Wenn Hacking also wie Malerei und Schreiben funktioniert, ist es dann auch so cool? Immerhin hat man nur ein Leben. Man könnte es genauso gut damit verbringen, an etwas Großartigem zu arbeiten.

Leider ist die Frage schwer zu beantworten. Es gibt immer eine große Zeitverzögerung im Prestige. Es ist wie Licht von einem fernen Stern. Die Malerei hat jetzt Prestige, weil großartige Arbeiten, die Menschen vor fünfhundert Jahren geleistet haben. Zu der Zeit dachte niemand, dass diese Gemälde so wichtig waren, wie wir es heute tun. Es hätte den Menschen damals sehr seltsam erschienen, dass Federico da Montefeltro, der Herzog von Urbino, eines Tages hauptsächlich als der Typ mit der seltsamen Nase in einem Gemälde von Piero della Francesca bekannt sein würde.

Während ich also zugebe, dass Hacking jetzt nicht so cool erscheint wie Malerei, sollten wir daran denken, dass die Malerei selbst in ihren Glanzzeiten nicht so cool erschien, wie sie es jetzt tut.

Was wir mit einiger Zuversicht sagen können, ist, dass dies die Glanzzeiten des Hackings sind. In den meisten Bereichen wird die großartige Arbeit früh geleistet. Die zwischen 1430 und 1500 geschaffenen Gemälde sind immer noch unerreicht. Shakespeare trat auf, als das professionelle Theater geboren wurde,

und drängte 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 dasselbe Muster. Ein neues Medium erscheint, und die Menschen sind so begeistert davon, dass sie die meisten seiner Möglichkeiten in den ersten paar Generationen erkunden. Hacking scheint sich jetzt in dieser Phase zu befinden.

Die Malerei war zu Leonardos Zeiten nicht so cool, wie seine Arbeit es half, sie zu machen. Wie cool Hacking sich herausstellt, wird davon abhängen, was wir mit diesem neuen Medium tun können.

Anmerkungen

[1] Der größte Schaden, den die Fotografie der Malerei zugefügt hat, könnte die Tatsache sein, dass sie den besten Tagesjob getötet hat. Die meisten der großen Maler in der Geschichte haben sich durch Porträtmalerei unterstützt.

[2] Mir wurde gesagt, dass Microsoft Mitarbeiter davon abhält, zu Open-Source-Projekten beizutragen, selbst in ihrer Freizeit. Aber so viele der besten Hacker arbeiten jetzt an Open-Source- Projekten, dass die Hauptwirkung dieser Politik möglicherweise darauf abzielt, sicherzustellen, dass sie keine erstklassigen Programmierer einstellen können.

[3] Was man im College über Programmierung lernt, ist viel wie was man über Bücher oder 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ürde unseren Konkurrenten am meisten ärgern? Zu einem bestimmten Zeitpunkt fügte ein Konkurrent eine Funktion zu seiner Software hinzu, die im Grunde nutzlos war, aber da es eine der wenigen war, die sie hatten, die wir nicht hatten, machten sie viel darüber 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 umsetzen, also hackten wir an diesem 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 viel unangenehmes Disk-Swapping verursachte, aber das konnte innerhalb weniger Monate durch den Kauf eines zusätzlichen Disk-Laufwerks behoben werden.

[7] Der Weg, um Programme leicht lesbar zu machen, besteht nicht darin, sie mit Kommentaren zu überladen. Ich würde Abelson und Sussmans Zitat einen Schritt weiterführen. Programmiersprachen sollten so gestaltet sein, dass sie Algorithmen ausdrücken, und nur zufällig, um den Computern zu sagen, wie sie sie ausführen sollen. Eine gute Programmiersprache sollte besser sein, um Software zu erklären als Englisch. Man sollte nur Kommentare benötigen, wenn es eine Art von Kludge gibt, über die man die Leser warnen muss, so wie es auf einer Straße nur Pfeile an Stellen mit unerwartet scharfen Kurven gibt.

Danke an Trevor Blackwell, Robert Morris, Dan Giffin und Lisa Randall für das Lesen von Entwürfen davon, und an Henry Leitner und Larry Finkelstein für die Einladung, zu sprechen.