Hacker und Maler

Mai 2003

(Dieser Aufsatz basiert auf einem Gastvortrag an der Harvard University, der eine frühere Rede an der Northeastern University enthielt.)

Als ich mein Studium der Informatik abgeschlossen hatte, ging ich an eine Kunsthochschule, um Malerei zu studieren. Viele Leute schienen überrascht, dass jemand, der sich für Computer interessierte, sich auch für Malerei interessieren würde. Sie schienen zu denken, dass Hacking und Malerei sehr unterschiedliche Arten von Arbeit seien – dass Hacking kalt, präzise und methodisch sei und dass Malerei der frenetische Ausdruck eines urzeitlichen Triebs sei.

Beide Bilder sind falsch. Hacking und Malerei haben viel gemeinsam. Tatsächlich sind von allen verschiedenen Arten von Menschen, die ich gekannt habe, Hacker und Maler unter den ähnlichsten.

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 erschaffen. Sie betreiben keine Forschung per se, obwohl es umso besser ist, wenn sie im Zuge des Versuchs, gute Dinge zu erschaffen, eine neue Technik entdecken.

Ich mochte den Begriff „Informatik“ nie. Der Hauptgrund, warum ich ihn nicht mag, ist, dass es so etwas nicht gibt. Informatik ist eine Sammelstelle von lose verbundenen Bereichen, die durch einen historischen Zufall zusammengefürt wurden, wie Jugoslawien. Am einen Ende gibt es Leute, die wirklich Mathematiker sind, aber das, was sie tun, Informatik nennen, damit sie DARPA-Zuschüsse erhalten können. In der Mitte gibt es Leute, die an etwas wie der Naturgeschichte von Computern arbeiten – zum Beispiel das Verhalten von Algorithmen zur Weiterleitung von Daten durch Netzwerke untersuchen. Und dann gibt es am anderen Extrem die Hacker, die interessante Software schreiben wollen 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 Hacker tun, als „Software-Engineering“ bezeichnet, 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 existiert. Sie liegt zwischen Was und Wie: Architekten entscheiden, was zu tun ist, und Ingenieure finden heraus, wie es zu tun ist.

Was und Wie sollten nicht zu sehr getrennt werden. Man holt sich Ärger ein, wenn man versucht zu entscheiden, was zu tun ist, ohne zu verstehen, wie es zu tun ist. Aber Hacking kann sicherlich mehr sein als nur zu entscheiden, wie eine Spezifikation implementiert wird. Im besten Fall ist es die Erstellung der Spezifikation – obwohl sich herausstellt, dass der beste Weg, dies zu tun, die Implementierung ist.

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

Die Bündelung all dieser verschiedenen Arbeitsarten in einer Abteilung mag administrativ praktisch sein, aber intellektuell verwirrend. Das ist der andere Grund, warum ich den Namen „Informatik“ nicht mag. Wohl tun die Leute in der Mitte so etwas wie eine experimentelle Wissenschaft. Aber die Leute an beiden Enden, die Hacker und die Mathematiker, betreiben keine Wissenschaft.

Die Mathematiker scheinen sich dadurch nicht gestört zu fühlen. Sie machen sich fröhlich daran, Theoreme zu beweisen, wie die anderen Mathematiker in der Mathematikabteilung, und hören wahrscheinlich bald auf zu bemerken, dass auf dem Gebäude, in dem sie arbeiten, außen „Informatik“ steht. Aber für die Hacker ist dieses Label ein Problem. Wenn das, was sie tun, Wissenschaft genannt wird, fühlen sie sich, als ob sie sich wissenschaftlich verhalten sollten. Anstatt also das zu tun, was sie wirklich wollen, nämlich schöne Software zu entwerfen, fühlen sich Hacker an Universitäten und Forschungslabors, als ob sie Forschungsarbeiten schreiben sollten.

Im besten Fall sind die Arbeiten nur eine Formalität. Hacker schreiben coole Software und dann eine Arbeit darüber, und die Arbeit wird zu einem Stellvertreter für die Leistung, die die Software repräsentiert. Aber oft verursacht diese Nichtübereinstimmung Probleme. Es ist leicht, vom Erstellen schöner Dinge zum Erstellen hässlicher Dinge abzugleiten, die sich besser für Forschungsarbeiten eignen.

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, besteht der Weg, sicherzustellen, dass man unbekanntes Terrain erforscht, darin, ein Stück Land zu beanspruchen, das niemand will. Zweitens muss Forschung 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 gehaltvollere Probleme als der Start mit falschen Annahmen. Der Großteil der KI ist ein Beispiel für diese Regel; wenn man davon ausgeht, dass Wissen als Liste von Prädikatenlogikausdrücken dargestellt werden kann, deren Argumente abstrakte Konzepte darstellen, wird man viele Arbeiten darüber schreiben müssen, wie man dies zum Funktionieren bringt. Wie Ricky Ricardo zu sagen pflegte: „Lucy, du hast viel zu erklären.“

Der Weg, etwas Schönes zu erschaffen, 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 in einer Forschungsarbeit zu vermitteln.

Warum also bewerten Universitäten und Forschungslabors Hacker weiterhin nach Veröffentlichungen? Aus demselben Grund, warum „schulische Eignung“ durch simple standardisierte Tests gemessen wird oder die Produktivität von Programmierern in Codezeilen gemessen wird. Diese Tests sind einfach anzuwenden, und es gibt nichts Verlockenderes als einen einfachen Test, der irgendwie funktioniert.

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

Der einzige externe Test ist die Zeit. Mit der Zeit neigen schöne Dinge dazu, zu gedeihen, und hässliche Dinge dazu, aussortiert zu werden. Leider können die benötigten Zeiträume länger sein als menschliche Lebensspannen. Samuel Johnson sagte, es dauere hundert Jahre, bis sich der Ruf eines Schriftstellers gefestigt habe. Man muss warten, bis die einflussreichen Freunde des Schriftstellers gestorben sind, und dann, bis alle ihre Anhänger gestorben sind.

Ich denke, Hacker müssen sich einfach damit abfinden, dass ihre Reputation eine große zufällige Komponente hat. In dieser Hinsicht unterscheiden sie sich nicht von anderen Machern. Tatsächlich haben sie im Vergleich Glück. Der Einfluss von Mode ist beim Hacking nicht annähernd so groß wie beim Malen.

Es gibt Schlimmeres, als dass Leute deine Arbeit missverstehen. Eine schlimmere Gefahr ist, dass du selbst deine Arbeit missverstehst. Verwandte Gebiete sind die Orte, an denen man nach Ideen sucht. Wenn man sich in der Informatikabteilung wiederfindet, gibt es eine natürliche Versuchung zu glauben, dass Hacking zum Beispiel die angewandte Version dessen ist, wovon die theoretische Informatik die Theorie ist. Die ganze Zeit, die ich im Graduiertenstudium verbrachte, hatte ich ein unbehagliches Gefühl im Hinterkopf, dass ich mehr Theorie wissen sollte und dass es sehr nachlässig von mir war, all das Zeug drei Wochen nach der Abschlussprüfung vergessen zu haben.

Jetzt erkenne ich, dass ich mich geirrt habe. Hacker müssen die Berechenbarkeitstheorie ungefähr so sehr verstehen, wie Maler Farbchemie verstehen müssen. Man muss wissen, wie man Zeit- und Raumkomplexität berechnet und etwas über Turing-Vollständigkeit. Man möchte vielleicht auch zumindest das Konzept einer Zustandsmaschine im Gedächtnis behalten, falls man einen Parser oder eine reguläre Ausdrucksbibliothek schreiben muss. Maler müssen tatsächlich viel mehr über Farbchemie wissen als das.

Ich habe festgestellt, dass die besten Ideenquellen nicht die anderen Gebiete sind, die das Wort „Computer“ in ihren Namen tragen, sondern die anderen Gebiete, in denen Macher leben. Malerei war eine viel reichhaltigere Quelle für Ideen als die Berechenbarkeitstheorie.

Zum Beispiel wurde mir im College beigebracht, dass man ein Programm vollständig auf Papier ausarbeiten sollte, bevor man sich überhaupt einem Computer nähert. Ich fand, dass ich nicht so programmierte. Ich fand, dass ich es mochte, vor einem Computer zu programmieren, nicht vor einem Stück Papier. Schlimmer noch, anstatt geduldig ein vollständiges Programm zu schreiben und sicherzustellen, dass es korrekt war, neigte ich dazu, einfach hoffnungslos fehlerhaften Code auszuspucken und ihn allmählich in Form zu bringen. Debugging, so wurde mir beigebracht, sei eine Art letzter Durchgang, bei dem man Tippfehler und Versäumnisse aufdeckt. So wie ich arbeitete, schien Programmieren aus Debugging zu bestehen.

Lange Zeit fühlte ich mich deswegen schlecht, so 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 geschaut, den Malern oder Architekten, hätte ich erkannt, dass das, was ich tat, einen Namen hatte: Skizzieren. Soweit ich das beurteilen kann, war die Art, wie sie mir im College das Programmieren beibrachten, völlig falsch. Man sollte Programme entwickeln, während man sie schreibt, genau wie Schriftsteller, Maler und Architekten es tun.

Diese Erkenntnis hat reale Auswirkungen auf das Software-Design. Sie bedeutet, dass eine Programmiersprache vor allem formbar sein sollte. Eine Programmiersprache dient dazu, über Programme nachzudenken, nicht dazu, bereits durchdachte Programme auszudrücken. Sie sollte ein Bleistift sein, kein Füller. Statische Typisierung wäre eine gute Idee, wenn die Leute Programme tatsächlich so schreiben würden, wie sie es mir im College beigebracht haben. Aber so schreiben keine der Hacker, die ich kenne, Programme. Wir brauchen eine Sprache, die es uns erlaubt zu kritzeln, zu verschmieren und zu verwischen, keine Sprache, in der man mit einer Tasse Tee voller Typen auf dem Knie sitzen und höflich mit einer strengen alten Tante von einem Compiler plaudern muss.

Wo wir gerade beim Thema statische Typisierung sind: Die Identifikation mit den Machern wird uns vor einem weiteren Problem bewahren, das die Wissenschaften plagt: Mathe-Neid. Jeder in den Wissenschaften glaubt heimlich, dass Mathematiker klüger sind als sie. Ich glaube, Mathematiker glauben das auch. Auf jeden Fall führt dies dazu, dass Wissenschaftler dazu neigen, ihre Arbeit so mathematisch wie möglich aussehen zu lassen. In einem Bereich wie der Physik schadet dies wahrscheinlich nicht viel, aber je weiter man sich von den Naturwissenschaften entfernt, desto mehr wird es zu einem Problem.

Eine Seite mit Formeln sieht einfach so beeindruckend aus. (Tipp: Für zusätzlichen Eindruck 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 zum Beispiel wichtig sind.

Wenn Hacker sich mit anderen Machern identifizieren würden, wie Schriftstellern und Malern, würden sie diese Versuchung nicht verspüren. Schriftsteller und Maler leiden nicht unter Mathe-Neid. Sie haben das Gefühl, etwas völlig anderes zu tun. Das tun Hacker meiner Meinung nach auch.

Wenn Universitäten und Forschungslabors Hacker davon abhalten, die Art von Arbeit zu tun, die sie tun wollen, ist vielleicht das Unternehmen der richtige Ort für sie. Leider erlauben die meisten Unternehmen Hackern auch nicht, das zu tun, was sie wollen. Universitäten und Forschungslabors zwingen Hacker, Wissenschaftler zu sein, und Unternehmen zwingen sie, Ingenieure zu sein.

Das habe ich selbst erst vor kurzem entdeckt. Als Yahoo Viaweb kaufte, fragten sie mich, was ich tun wollte. Ich mochte die geschäftliche Seite nie sehr und sagte, ich wollte nur hacken. Als ich zu Yahoo kam, stellte ich fest, dass Hacking für sie bedeutete, Software zu implementieren, nicht zu entwerfen. Programmierer wurden als Techniker angesehen, die die Visionen (wenn man es so nennen kann) von Produktmanagern in Code umsetzten.

Das scheint der Standardplan in großen Unternehmen zu sein. Sie tun dies, 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, schwierig, diese auszuwählen. Anstatt also die Zukunft der Software einem brillanten Hacker anzuvertrauen, richten die meisten Unternehmen es so ein, dass sie von einem Komitee entworfen wird, und die Hacker implementieren nur den Entwurf.

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 Oszillationen dämpft, verliert man auch die Höhepunkte. Das ist für große Unternehmen kein Problem, weil sie nicht gewinnen, 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, sich in einen Design-Krieg mit einem Unternehmen einzulassen, das groß genug ist, dass seine Software von Produktmanagern entworfen wird, werden sie Ihnen nie nachkommen können. Diese Gelegenheiten sind jedoch nicht leicht zu finden. Es ist schwierig, ein großes Unternehmen in einen Design-Krieg zu verwickeln, genauso wie es schwierig ist, einen Gegner in einer Burg im Nahkampf zu verwickeln. Es wäre zum Beispiel ziemlich einfach, einen besseren Textverarbeitungsprozessor als Microsoft Word zu schreiben, aber Microsoft würde ihn innerhalb der Burg seines Betriebssystemmonopols wahrscheinlich nicht einmal bemerken, wenn Sie es täten.

Der Ort, um Design-Kriege zu führen, sind neue Märkte, in denen noch niemand Befestigungen errichten konnte. Dort können Sie groß gewinnen, indem Sie den kühnen Ansatz für das Design wählen und dieselben Leute sowohl das Produkt entwerfen als auch implementieren lassen. Microsoft selbst hat dies am Anfang getan. Ebenso Apple. Und Hewlett-Packard. Ich vermute, fast jedes erfolgreiche Startup.

Eine Möglichkeit, großartige Software zu entwickeln, ist also, ein eigenes Startup zu gründen. Es gibt jedoch zwei Probleme damit. Erstens muss man bei einem Startup so viel mehr tun, als nur Software zu schreiben. Bei Viaweb betrachtete ich mich als Glückspilz, wenn ich ein Viertel der Zeit hacken konnte. Und die Dinge, die ich die restlichen drei Viertel der Zeit tun musste, reichten von mühsam bis erschreckend. Ich habe dafür einen Maßstab, denn ich musste einmal eine Vorstandssitzung verlassen, um mir Karies füllen zu lassen. Ich erinnere mich, wie ich im Behandlungsstuhl saß, auf den Bohrer wartete und mich fühlte, als wäre ich im Urlaub.

Das andere Problem bei Startups ist, dass es nicht viel Überschneidung zwischen der Art von Software, die Geld einbringt, und der, die interessant zu schreiben ist, gibt. 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 sie jemand kostenlos lösen würde.

Alle Macher stehen vor diesem Problem. 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. Das Schauspielern in Off-Broadway-Stücken zahlt sich einfach nicht so gut aus wie das Tragen eines Gorillakostüms in einem Messestand. Das Schreiben von Romanen zahlt sich nicht so gut aus wie das Schreiben von Werbetexten für Müllentsorgungssysteme. Und das Hacken von Programmiersprachen zahlt sich nicht so gut aus wie das Herausfinden, wie man die Legacy-Datenbank eines Unternehmens mit seinem Webserver verbindet.

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

Fast alle Macher haben früh in ihrer Karriere Nebenjobs. Maler und Schriftsteller tun dies 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 es benutzt. [1]

Wenn ich sage, dass die Antwort darin besteht, dass Hacker Nebenjobs haben und nebenbei an schöner Software arbeiten, 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 von allen anderen Machern unabhängig bestätigt wurde.

Es überrascht mich, dass jeder Arbeitgeber zögern würde, Hackern die Arbeit an Open-Source-Projekten zu erlauben. Bei Viaweb wären wir zögerlich, jemanden einzustellen, der das nicht tut. Als wir Programmierer interviewten, war das Wichtigste, was uns interessierte, welche Art von Software sie in ihrer Freizeit schrieben. Man kann nichts wirklich gut machen, wenn man es nicht liebt, und wenn man gerne hackt, wird man zwangsläufig an eigenen Projekten arbeiten. [2]

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

Eine Sache, die wir aus dem Beispiel der Malerei lernen können, oder zumindest bestätigen können, ist, wie man das Hacken lernt. Man lernt Malen hauptsächlich durch Tun. Dito für Hacking. Die meisten Hacker lernen das Hacken nicht, indem sie College-Kurse in Programmierung belegen. Sie lernen das Hacken, indem sie im Alter von dreizehn Jahren eigene Programme schreiben. Selbst in College-Kursen lernt man das Hacken hauptsächlich durch Hacking. [3]

Da Maler eine Spur von Arbeit hinterlassen, kann man ihnen beim Lernen zusehen. Wenn man die Arbeit eines Malers in chronologischer Reihenfolge betrachtet, stellt man fest, dass jedes Gemälde auf Dingen aufbaut, die in früheren gelernt wurden. Wenn etwas in einem Gemälde sehr gut funktioniert, findet man es normalerweise in einer früheren Version in kleinerer 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 all ihre späteren Ideen als Überarbeitungen einzubauen.

Die Tatsache, dass Hacker durch Tun lernen, ist ein weiteres Zeichen dafür, wie sehr sich Hacking von den Wissenschaften unterscheidet. Wissenschaftler lernen Wissenschaft nicht durch Tun, sondern durch Labore und Übungsaufgaben. Wissenschaftler beginnen mit perfekter Arbeit, in dem Sinne, dass sie versuchen, Arbeit zu reproduzieren, die jemand anderes bereits für sie erledigt hat. Schließlich erreichen sie den Punkt, an dem sie originelle Arbeit leisten können. Während Hacker von Anfang an originelle Arbeit leisten; sie ist nur sehr schlecht. Hacker beginnen also 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 Jahrhunderten gehört es zur traditionellen Ausbildung von Malern, die Werke der großen Meister zu kopieren, denn Kopieren zwingt einen, genau auf die Art und Weise zu achten, wie ein Gemälde entsteht.

Das tun auch Schriftsteller. Benjamin Franklin lernte schreiben, indem er die Punkte in den Essays von Addison und Steele zusammenfasste und dann versuchte, sie zu reproduzifizieren. 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 bekannten Vorteile der Open-Source-Bewegung ist, dass sie das Programmierenlernen erleichtert hat. Als ich programmieren lernte, mussten wir uns hauptsächlich auf Beispiele in Büchern verlassen. Der einzige große Codeblock, der damals verfügbar war, war Unix, aber selbst das war kein 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 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 mit Röntgenstrahlen betrachtet, zeigen Gliedmaßen, die verschoben wurden, oder Gesichtszüge, die neu angeordnet 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. Es ist besser, wenn man das von vornherein zugibt und Programme so schreibt, dass Spezifikationen im laufenden Betrieb geändert werden können.

(Die Struktur großer Unternehmen macht dies für sie schwierig, daher ist hier ein weiterer Punkt, an dem Startups einen Vorteil haben.)

Jeder kennt inzwischen vermutlich die 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, das Ändern der Meinung erleichtern. Dynamische Typisierung ist hier ein Gewinn, weil man sich nicht im Voraus auf bestimmte Datenrepräsentationen festlegen muss. Aber der Schlüssel zur Flexibilität ist meiner Meinung nach, die Sprache sehr abstrakt zu machen. Das am einfachsten zu ändernde Programm ist eines, das sehr kurz ist.

Das klingt paradox, 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 Wacholderstrauch hinter ihren Kopf. Darin malte er sorgfältig jedes einzelne Blatt. Viele Maler hätten gedacht: Das ist nur etwas für den Hintergrund, um ihren Kopf einzurahmen. Niemand wird es so genau betrachten.

Nicht Leonardo. Wie sehr er sich um einen Teil eines Gemäldes bemühte, hing überhaupt nicht davon ab, wie genau er erwartete, dass jemand es betrachten würde. Er war wie Michael Jordan. Unnachgiebig.

Unnachgiebigkeit gewinnt, weil sich ungesehene Details in der Summe sichtbar machen. Wenn Leute am Porträt von Ginevra de Benci vorbeigehen, werden sie oft sofort davon gefesselt, noch bevor sie das Etikett lesen und bemerken, dass dort Leonardo da Vinci steht. All diese ungesehenen Details ergeben zusammen etwas, das einfach atemberaubend ist, wie tausend kaum hörbare Stimmen, die alle im Einklang singen.

Großartige Software erfordert ebenfalls eine fanatische Hingabe an Schönheit. Wenn man sich gute Software ansieht, 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, wenn es um Code geht, mich so verhalte, dass ich Anspruch auf verschreibungspflichtige Medikamente hätte, wenn ich das alltägliche Leben auf die gleiche Weise angehen würde. Es macht mich verrückt, schlecht eingerückten Code zu sehen oder hässliche Variablennamen zu verwenden.

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

Beim Hacking, 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 ist nichts interessant.

Um gute Arbeit zu leisten, muss man diese Zyklen berücksichtigen, da sie davon beeinflusst werden, wie man auf sie reagiert. Wenn man ein Auto mit Schaltgetriebe an einem Hang fährt, muss man manchmal die Kupplung loslassen, um ein Abwürgen zu vermeiden. Das Loslassen kann ebenso den Ehrgeiz vor dem Abwürgen bewahren. 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, einige einfache Aufgaben für Momente aufzusparen, in denen man sonst abwürgen würde.

Beim Hacking kann dies buchstäblich bedeuten, Fehler aufzusparen. Ich debugge gerne: Es ist die einzige Zeit, in der Hacking so geradlinig ist, wie die Leute denken. Man hat ein völlig eingeschränktes Problem, und alles, was man tun muss, ist, es zu lösen. Dein 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 verwalten, sondern auch, wie wir zusammenarbeiten. Viel von der großen Kunst der Vergangenheit ist das Werk mehrerer Hände, obwohl nur ein Name daneben an der Wand im Museum stehen mag. Leonardo war ein Lehrling in der Werkstatt von Verrocchio und malte einen der Engel in dessen Taufe Christi. Diese Art von Arbeit war 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ß, arbeiteten Maler, wenn sie gemeinsam an einem Gemälde arbeiteten, nie an denselben Teilen. Es war üblich, dass der Meister die Hauptfiguren malte und Assistenten die anderen und den Hintergrund. Aber man hatte nie einen Mann, der über die Arbeit eines anderen malte.

Ich denke, das ist auch das richtige Modell für die Zusammenarbeit in der Software. Treiben Sie es nicht zu weit. Wenn ein Code-Stück von drei oder vier verschiedenen Leuten gehackt wird, von denen keiner es wirklich besitzt, wird es wie ein Gemeinschaftsraum enden. Es wird sich wahrscheinlich trostlos und verlassen anfühlen und Müll ansammeln. Die richtige Art der Zusammenarbeit ist meiner Meinung nach, Projekte in scharf definierte Module zu unterteilen, jedes mit einem eindeutigen Besitzer und mit Schnittstellen dazwischen, die so sorgfältig entworfen und, wenn möglich, so artikuliert sind wie Programmiersprachen.

Wie Malerei ist auch die meiste Software für ein menschliches Publikum bestimmt. Und so müssen Hacker, wie Maler, Empathie besitzen, um wirklich großartige Arbeit zu leisten. Man muss Dinge aus der Sicht des Benutzers sehen können.

Als ich ein Kind war, wurde mir immer gesagt, ich solle 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 nahm mir vor, sie nicht zu kultivieren.

Junge, war ich falsch. Es stellt sich heraus, dass das Betrachten von Dingen aus der Sicht anderer Menschen praktisch das Geheimnis des Erfolgs ist. Es bedeutet nicht unbedingt, selbstlos zu sein. Weit gefehlt. Zu verstehen, wie jemand anderes Dinge sieht, bedeutet nicht, dass man in seinem Interesse handelt; in manchen Situationen – zum Beispiel im Krieg – möchte man genau das Gegenteil tun. [4]

Die meisten Macher stellen Dinge für ein menschliches Publikum her. Und um ein Publikum zu fesseln, muss man verstehen, was es braucht. Fast alle größten Gemälde sind zum Beispiel Gemälde von Menschen, 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. Für solche Leute ist es schwierig, großartige Software zu entwerfen [5], weil sie die Dinge nicht aus der Sicht des Benutzers sehen können.

Eine Möglichkeit, das Ausmaß der Empathie von Menschen zu beurteilen, ist, ihnen zuzusehen, wie sie jemandem ohne technischen Hintergrund eine technische Frage erklären. Wir kennen wahrscheinlich alle Leute, die, obwohl sie ansonsten klug sind, darin einfach komisch schlecht sind. Wenn sie auf einer Dinnerparty gefragt werden, was eine Programmiersprache ist, sagen sie etwas wie: „Oh, eine High-Level-Sprache ist das, was der Compiler als Eingabe verwendet, um Objektcode zu generieren.“ High-Level-Sprache? 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 mit der Software ohne Vorbereitung auf sie zukommen, und sie sollte besser das tun, was sie vermuten, dass sie es tun wird, 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 das, 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 zum Lesen 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 deinem Interesse, weil du einer von ihnen sein wirst. Viele Hacker haben ein Programm geschrieben, nur um festzustellen, dass sie sechs Monate später, als sie darauf zurückkamen, keine Ahnung hatten, wie es funktioniert. Ich kenne mehrere Leute, die nach solchen Erfahrungen geschworen haben, Perl abzuschwören. [7]

Empathiemangel ist mit Intelligenz verbunden, bis zu dem Punkt, dass es an manchen Orten sogar eine gewisse Modeerscheinung dafür gibt. Aber ich glaube nicht, dass es eine Korrelation gibt. Man kann in Mathematik und Naturwissenschaften gut abschneiden, ohne Empathie lernen zu müssen, und Menschen in diesen Bereichen sind tendenziell klug, sodass die beiden Eigenschaften miteinander verbunden sind. Aber es gibt auch viele dumme Leute, die schlecht in Empathie sind. Hören Sie sich einfach die Leute an, die bei Talkshows anrufen. Sie stellen, was auch immer sie fragen, auf so umständliche Weise, dass die Gastgeber die Frage oft für sie umformulieren müssen.

Wenn Hacking also wie Malen und Schreiben funktioniert, ist es dann so cool? Schließlich hat man nur ein Leben. Man kann 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 beim Prestige. Es ist wie Licht von einem fernen Stern. Malerei hat jetzt Prestige wegen großartiger Werke, die Menschen vor fünfhundert Jahren geschaffen haben. Damals dachten die Leute nicht, dass diese Gemälde so wichtig waren, wie wir sie heute betrachten. Es wäre den Leuten 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.

Obwohl ich also zugebe, dass Hacking zu seiner Glanzzeit nicht so cool erscheint wie Malerei, sollten wir uns daran erinnern, dass Malerei selbst zu ihrer Glanzzeit nicht so cool erschien wie heute.

Was wir mit einiger Sicherheit sagen können, ist, dass dies die Glanzzeit des Hackens ist. In den meisten Bereichen werden die großartigen Werke früh geleistet. Die Gemälde aus der Zeit zwischen 1430 und 1500 sind immer noch unübertroffen. Shakespeare erschien gerade, als das professionelle Theater geboren wurde, und trieb das Medium so weit voran, dass jeder nachfolgende Dramatiker 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 Leute sind so begeistert davon, dass sie in den ersten paar Generationen die meisten seiner Möglichkeiten erkunden. Hacking scheint sich jetzt in dieser Phase zu befinden.

Malerei war zu Leonardos Zeiten nicht so cool, wie seine Arbeit sie machte. Wie cool Hacking sein wird, hängt davon ab, was wir mit diesem neuen Medium tun können.

Anmerkungen

[1] Der größte Schaden, den die Fotografie der Malerei zugefügt hat, ist vielleicht die Tatsache, dass sie den besten Nebenjob getötet hat. Die meisten großen Maler der Geschichte verdienten ihren Lebensunterhalt mit Porträtmalerei.

[2] Mir wurde gesagt, dass Microsoft seine 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 darin bestehen könnte, sicherzustellen, dass sie keine erstklassigen Programmierer einstellen können.

[3] Was man im College über Programmierung lernt, ist viel wie das, was man über Bücher oder Kleidung oder Verabredungen 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 hassen? Zu einem Zeitpunkt fügte ein Konkurrent seinem Software eine Funktion hinzu, die im Grunde nutzlos war, aber da sie eine der wenigen war, 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 am 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 überschritten den verfügbaren RAM etwas, was zu viel unbequemen Festplattenwechseln führte, aber das konnte innerhalb weniger Monate durch den Kauf eines zusätzlichen Laufwerks behoben werden.

[7] Der Weg, Programme lesbar zu machen, besteht nicht darin, sie mit Kommentaren zu überladen. Ich würde das Zitat von Abelson und Sussman noch weiter treiben. Programmiersprachen sollten so konzipiert sein, dass sie Algorithmen ausdrücken, und nur nebenbei, um Computern zu sagen, wie sie ausgeführt werden sollen. Eine gute Programmiersprache sollte besser zur Erklärung von Software geeignet sein als Englisch. Man sollte nur Kommentare benötigen, wenn es eine Art von Kludge gibt, vor der man die Leser warnen muss, so wie auf einer Straße Pfeile nur an Stellen mit unerwartet scharfen Kurven angebracht sind.

Dank 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 zum Sprechen.