HACKER UND MALER

Mai 2003

(Dieser Aufsatz basiert auf einem Gastvortrag an der Harvard University, der einen früheren Vortrag an der Northeastern University einbezog.)

Als ich mein Informatikstudium abgeschlossen hatte, ging ich auf eine Kunstschule, um Malerei zu studieren. Viele Leute schienen überrascht, dass jemand, der sich für Computer interessiert, auch an Malerei interessiert ist. Sie schienen zu denken, dass Hacking und Malen sehr unterschiedliche Arten von Arbeit sind - dass Hacking kalt, präzise und methodisch ist, und dass Malen der frenetische Ausdruck eines primitiven Impulses ist.

Beide dieser Bilder sind falsch. Hacking und Malen haben viel gemeinsam. Tatsächlich sind Hacker und Maler unter all den verschiedenen Menschentypen, die ich kenne, am ähnlichsten.

Was Hacker und Maler gemeinsam haben, ist, dass sie beide Schöpfer sind. Zusammen mit Komponisten, Architekten und Schriftstellern versuchen Hacker und Maler, gute Dinge zu schaffen. Sie betreiben keine Forschung per se, aber 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 gar nicht gibt. Informatik ist eine Mischung von lose zusammenhängenden Bereichen, die durch einen Zufall der Geschichte zusammengewürfelt wurden, wie Jugoslawien.

An dem einen Ende haben Sie Leute, die eigentlich Mathematiker sind, aber das, was sie tun, Informatik nennen, damit sie DARPA-Zuschüsse bekommen können. In der Mitte haben Sie Leute, die an etwas wie der Naturgeschichte von Computern arbeiten - sie studieren zum Beispiel das Verhalten von Algorithmen zum Routing von Daten durch Netzwerke. Und dann haben Sie auf der anderen Seite 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 würden Mathematiker, Physiker und Architekten alle in der gleichen Abteilung sein müssen.

Manchmal wird das, was die Hacker tun, "Softwaretechnik" genannt, aber dieser Begriff ist genauso irreführend. Gute Softwaredesigner sind keine Ingenieure, genauso wenig wie 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 es zu tun ist.

Was und Wie sollten nicht zu sehr getrennt werden. Sie riskieren Ärger, wenn Sie versuchen, zu entscheiden, was zu tun ist, ohne zu verstehen, wie es zu tun ist. Aber Hacking kann sicher mehr sein als nur die Entscheidung, wie eine bestimmte Spezifikation umgesetzt werden soll. Im Idealfall geht es darum, die Spezifikation selbst zu erstellen - auch wenn sich herausstellt, dass der beste Weg dazu darin besteht, sie umzusetzen.

Vielleicht wird sich "Informatik" eines Tages, wie Jugoslawien, in seine Bestandteile auflösen. Das wäre vielleicht eine gute Sache. Vor allem, wenn es die Unabhängigkeit meiner Heimat, des Hackings, bedeuten würde.

Die Bündelung all dieser verschiedenen Arbeitsformen in einer einzigen Abteilung mag administrativ praktisch sein, aber intellektuell ist es verwirrend. Das ist der andere Grund, warum ich den Namen "Informatik" nicht mag. Streng genommen tun die Leute in der Mitte etwas, das einer experimentellen Wissenschaft ähnelt. Aber die Leute an den beiden Enden, die Hacker und die Mathematiker, betreiben tatsächlich keine Wissenschaft.

Die Mathematiker scheinen davon nicht gestört zu sein. Sie machen fröhlich weiter mit dem Beweisen von Theoremen wie die anderen Mathematiker in der Mathematikabteilung und merken wahrscheinlich bald nicht mehr, dass das Gebäude, in dem sie arbeiten, außen "Informatik" steht. Aber für die Hacker ist diese Bezeichnung ein Problem. Wenn das, was sie tun, Wissenschaft genannt wird, haben sie das Gefühl, sie müssten sich auch wissenschaftlich verhalten.

Im besten Fall sind die Artikel nur eine Formalität. Hacker schreiben coole Software und schreiben dann einen Artikel darüber, und der Artikel wird zu einem Stellvertreter für die Leistung, die durch die Software repräsentiert wird. Aber oft führt dieser Missklang zu Problemen. Es ist leicht, vom Bau schöner Dinge abzukommen und hässliche Dinge zu bauen, die besser für Forschungsarbeiten geeignet sind.

Leider sind schöne Dinge nicht immer die besten Themen für Artikel. Erstens muss die Forschung originell sein - und wie jeder weiß, der eine Doktorarbeit geschrieben hat, ist der sicherste Weg, Neuland zu betreten, ein Stück Land zu besetzen, das niemand haben will. Zweitens muss die Forschung substanziell sein - und unbeholfene Systeme liefern knackigere Artikel, weil man über die Hindernisse schreiben kann, die man überwinden muss, um die Dinge zu erledigen. Nichts liefert knackigere Probleme als der falsche Ausgangspunkt. Der größte Teil der KI ist ein Beispiel für diese Regel; wenn man annimmt, dass Wissen als Liste von Prädikatenlogikausdrücken dargestellt werden kann, deren Argumente abstrakte Konzepte repräsentieren, wird man viele Artikel darüber schreiben müssen, wie man das zum Laufen bringt. Wie Ricky Ricardo 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 bereits Existierendem vorzunehmen oder bestehende Ideen auf eine leicht neue Art und Weise zu kombinieren. Diese Art von Arbeit ist schwer in einem Forschungsartikel zu vermitteln.

Warum beurteilen Universitäten und Forschungslabore Hacker also weiterhin anhand von Veröffentlichungen? Aus dem gleichen Grund, aus dem "Studierfähigkeit" mit einfachen standardisierten Tests gemessen wird oder die Produktivität von Programmierern an Codezeilen. Diese Tests sind leicht anzuwenden, und es gibt nichts Verlockenderen als einen einfachen Test, der halbwegs funktioniert.

Das, was Hacker wirklich tun wollen, nämlich schöne Software zu entwerfen, zu messen, wäre viel schwieriger. Man braucht ein gutes Gespür für Design, um gutes Design zu beurteilen. Und es gibt keinen Zusammenhang, außer möglicherweise einen negativen, 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 setzen sich schöne Dinge durch, und hässliche Dinge werden verworfen. Leider können die Zeiträume länger sein als ein Menschenleben. Samuel Johnson sagte, es brauche hundert Jahre, bis sich der Ruf eines Schriftstellers eingependelt habe. Man muss warten, bis die einflussreichen Freunde des Schriftstellers gestorben sind und dann alle ihre Anhänger.

Ich denke, Hacker müssen sich damit abfinden, dass der Anteil des Zufalls an ihrem Ruf sehr groß ist. Darin unterscheiden sie sich nicht von anderen Schöpfern. Tatsächlich haben sie sogar Glück im Vergleich. Der Einfluss der Mode ist im Hacking nicht annähernd so groß wie in der Malerei.

Es gibt Schlimmeres, als dass Leute dein Werk missverstehen. Eine größere Gefahr ist, dass du dein eigenes Werk missverstehst. Verwandte Fachgebiete sind es, wo du nach Ideen suchst. Wenn du dich in der Informatik-Abteilung befindest, besteht die natürliche Versuchung zu glauben, dass Hacking die angewandte Version dessen ist, wovon die theoretische Informatik die Theorie ist. Die ganze Zeit, in der ich im Graduiertenstudium war, hatte ich ein unangenehmes Gefühl im Hinterkopf, dass ich mehr Theorie wissen sollte und dass es sehr nachlässig von mir war, all diesen Kram 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 Berechenbarkeit ungefähr genauso gut verstehen wie Maler die Chemie der Farben. Du musst wissen, wie man Zeit- und Platzkomplexität berechnet und was Turing-Vollständigkeit ist. Du möchtest vielleicht auch zumindest das Konzept einer Zustandsmaschine im Hinterkopf behalten, für den Fall, dass du einen Parser oder eine Reguläre-Ausdrücke-Bibliothek schreiben musst. Maler müssen tatsächlich viel mehr über Farbchemie wissen als das.

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

Zum Beispiel wurde mir im Studium beigebracht, dass man ein Programm vollständig auf Papier ausarbeiten sollte, bevor man sich auch nur in die Nähe eines Computers begibt. Ich habe festgestellt, dass ich nicht so programmiere. Ich fand, dass ich gerne vor einem Computer programmiere, nicht auf einem Blatt Papier. Noch schlimmer, anstatt geduldig ein vollständiges Programm aufzuschreiben und mich zu versichern, dass es korrekt ist, tendierte ich dazu, einfach Code auszuspucken, der hoffnungslos kaputt war, und ihn dann nach und nach in Form zu bringen. Debugging, so wurde mir beigebracht, war eine Art Endlauf, bei dem man Tippfehler und Übersehen erwischte. Bei der Art, wie ich arbeitete, schien Programmieren aus Debugging zu bestehen.

Lange Zeit fühlte ich mich schlecht deswegen, genauso wie ich mich früher schlecht gefühlt habe, weil ich den Bleistift nicht so hielt, wie sie es mir in der Grundschule beigebracht hatten. Wenn ich nur zu den anderen Machern, den Malern oder den Architekten, hinübergeschaut hätte, hätte ich erkannt, dass es einen Namen für das, was ich tat, gibt: Skizzieren. Soweit ich sehen kann, war die Art, wie sie mir im Studium beibrachten zu programmieren, völlig falsch. Man sollte Programme entwickeln, während man sie schreibt, genau wie Schriftsteller, Maler und Architekten es tun.

Die Erkenntnis, dass dem so ist, hat echte Auswirkungen auf das Softwaredesign. Das bedeutet, dass eine Programmiersprache vor allem formbar sein sollte. Eine Programmiersprache dient dazu, Programme zu denken, nicht dazu, Programme auszudrücken, die man sich bereits ausgedacht hat. Sie sollte ein Bleistift sein, kein Kugelschreiber. Statische Typisierung wäre eine gute Idee, wenn die Leute tatsächlich Programme so schreiben würden, wie sie es mir im Studium beigebracht haben. Aber so schreiben keine der Hacker, die ich kenne, ihre Programme. Wir brauchen eine Sprache, die es uns erlaubt zu kritzeln, zu verwischen und zu verschmieren, keine Sprache, in der du mit einer Tasse voller Typen auf dem Knie sitzen und höfliche Konversation mit einer strengen alten Tante von einem Compiler führen musst.

Um beim Thema statische Typisierung zu bleiben: Wenn man sich mit den Machern identifiziert, rettet man sich vor einem anderen Problem, das die Wissenschaften heimsucht: Mathematik-Neid. Jeder in den Wissenschaften glaubt im Geheimen, dass Mathematiker klüger sind als er selbst. Ich denke, Mathematiker glauben das auch. Jedenfalls ist das Ergebnis, dass Wissenschaftler dazu neigen, ihre Arbeit so mathematisch wie möglich aussehen zu lassen.

In einem Fach wie Physik richtet das wahrscheinlich nicht allzu viel Schaden an, aber je weiter man sich von den Naturwissenschaften entfernt, desto größer wird das Problem. Eine Seite voller Formeln sieht einfach so beeindruckend aus. (Tipp: Für zusätzliche Beeindruckung verwende griechische Variablen.) Und so besteht eine große Versuchung, an Problemen zu arbeiten, die man formal behandeln kann, anstatt an Problemen, die zum Beispiel wichtig sind.

Wenn sich Hacker mit anderen Machern wie Schriftstellern und Malern identifizieren würden, hätten sie nicht mit Mathematik-Neid zu kämpfen. Schriftsteller und Maler leiden nicht darunter. Sie haben das Gefühl, etwas völlig Anderes zu tun. Genauso wie Hacker, denke ich.

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

Das habe ich selbst erst vor Kurzem herausgefunden. Als Yahoo Viaweb gekauft hat, fragten sie mich, was ich tun möchte. Ich hatte die Geschäftsseite nie sehr gemocht und sagte, dass ich einfach hacken möchte. Als ich bei Yahoo ankam, stellte ich fest, dass Hacking für sie bedeutete, Software zu implementieren, nicht sie zu entwerfen. Programmierer wurden als Techniker angesehen, die die Visionen (wenn man das so nennen will) 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 für die Leute, die ein Unternehmen leiten, schwierig, diese herauszufinden. Also anstatt die Zukunft der Software einem brillanten Hacker anzuvertrauen, richten die meisten Unternehmen die Dinge so ein, dass sie von einem Ausschuss entworfen wird und die Hacker sie nur noch implementieren.

Wenn du irgendwann Geld verdienen möchtest, denk daran, denn das ist einer der Gründe, warum Startups gewinnen. Große Unternehmen wollen die Standardabweichung der Designergebnisse verringern, weil sie Katastrophen vermeiden wollen. Aber wenn du Schwingungen dämpfst, verlierst du die hohen Punkte genauso wie die niedrigen. 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 du also einen Weg finden kannst, dich in einen Designkrieg mit einem Unternehmen zu begeben, das groß genug ist, dass seine Software von Produktmanagern entworfen wird, werden sie niemals mit dir Schritt halten können. Diese Gelegenheiten sind nicht leicht zu finden, allerdings. Es ist schwierig, ein großes Unternehmen in einen Designkrieg zu verwickeln, genauso wie es schwierig ist, einen Gegner in einem Nahkampf in einer Burg anzugreifen. Es wäre ziemlich einfach, einen besseren Textverarbeiter als Microsoft Word zu schreiben, aber Microsoft würde, geschützt durch das Betriebssystemmonopol ihrer Burg, wahrscheinlich nicht einmal bemerken, wenn du das tätest.

Der Ort, an dem man Designkriege führt, sind neue Märkte, in denen noch niemand Befestigungen errichtet hat. Dort kann man große Gewinne erzielen, indem man einen mutigen Designansatz wählt und dieselben Leute sowohl das Produkt entwerfen als auch umsetzen lässt. Microsoft selbst hat dies zu Beginn getan. Auch Apple und Hewlett-Packard haben das so gemacht. Ich vermute, dass fast jedes erfolgreiche Start-up so vorgeht.

Eine Möglichkeit, großartige Software zu entwickeln, besteht also darin, ein eigenes Start-up zu gründen. Es gibt jedoch zwei Probleme damit. Zum einen muss man in einem Start-up so viel mehr tun, als nur Software zu schreiben. Bei Viaweb betrachtete ich mich als glücklich, wenn ich ein Viertel der Zeit hacken konnte. Und die Dinge, die ich die anderen drei Viertel der Zeit tun musste, reichten von lästig bis furchteinflößend. Ich habe dafür einen Maßstab, denn ich musste einmal eine Vorstandssitzung verlassen, um einige Füllungen machen zu lassen. Ich erinnere mich, wie ich im Zahnarztstuhl saß und auf den Bohrer wartete, und das Gefühl hatte, Urlaub zu machen.

Das andere Problem mit Start-ups ist, dass es nur wenig Überschneidung zwischen der Art von Software gibt, die Geld einbringt, und der Art, die interessant zu programmieren ist. Programmiersprachen sind interessant zu schreiben, und Microsofts erstes Produkt war tatsächlich eine, aber niemand wird heute noch 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 sehen sich mit diesem Problem konfrontiert. Die Preise werden durch Angebot und Nachfrage bestimmt, und es gibt einfach nicht so viel Nachfrage nach Dingen, die Spaß machen zu bearbeiten, wie es sie für Dinge gibt, die die banalen Probleme individueller Kunden lösen. Auftritte in Off-Broadway-Stücken bezahlen nicht so gut wie das Tragen eines Gorillakostüms im Stand eines Unternehmens auf einer Messe. Das Schreiben von Romanen bringt nicht so viel ein wie das Schreiben von Werbetexten für Abfallzerkleinerer. Und das Hacken von Programmiersprachen bringt nicht so viel ein wie das Herausfinden, wie man eine Altdatenbank 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 Brotjob. Dieser Begriff stammt ursprünglich von Musikern, die nachts auftreten. Allgemeiner bedeutet er, dass man eine Art von Arbeit hat, mit der man Geld verdient, und eine andere, die man aus Leidenschaft betreibt.

Fast alle Macher haben zu Beginn ihrer Karriere Brotjobs. Maler und Schriftsteller tun das notorisch. Wenn man Glück hat, kann man einen Brotjob finden, der eng mit der eigentlichen Arbeit verwandt ist. Musiker arbeiten oft in Plattenläden. Ein Hacker, der an einer Programmiersprache oder einem Betriebssystem arbeitet, könnte ebenfalls einen Brotjob finden, bei dem er diese nutzt. [1]

Wenn ich sage, dass die Antwort darin besteht, dass Hacker Brotjobs haben und in ihrer Freizeit an schöner Software arbeiten, schlage ich das nicht als neue Idee vor. Darum geht es bei Open-Source-Hacking. 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 irgendein Arbeitgeber zögern würde, Hackern das Arbeiten an Open-Source-Projekten zu erlauben. Bei Viaweb hätten wir gezögert, jemanden einzustellen, der das nicht tut. Wenn wir Programmierer interviewt haben, war das Wichtigste für uns, an welcher Art von Software sie in ihrer Freizeit arbeiten. Man kann nichts wirklich gut machen, wenn man es nicht liebt, und wenn man Spaß am Hacken hat, wird man unweigerlich an eigenen Projekten arbeiten. [2]

Da Hacker eher Macher als Wissenschaftler sind, sollten wir bei der Suche nach Metaphern nicht in den Wissenschaften, sondern unter anderen Arten von Machern suchen. Was kann uns die Malerei über das Hacken lehren?

Eines der Dinge, die wir von der Malerei lernen oder zumindest bestätigen können, ist, wie man lernt zu hacken. Man lernt malen hauptsächlich, indem man es tut. Genauso ist es beim Hacken. Die meisten Hacker lernen nicht durch Computerkurse an der Universität zu hacken. Sie lernen es, indem sie im Alter von 13 Jahren eigene Programme schreiben. Selbst in Universitätskursen lernt man hauptsächlich durch Hacken. [3]

Da Maler eine Spur von Arbeiten hinterlassen, kann man beobachten, wie sie durch Tun lernen. Wenn man die Arbeiten eines Malers in chronologischer Reihenfolge betrachtet, stellt man fest, dass jedes Gemälde auf Dingen aufbaut, die in früheren Arbeiten gelernt wurden. Wenn es in einem Gemälde etwas gibt, das sehr gut funktioniert, findet man in einem früheren Gemälde oft eine Version 1 davon in kleinerer Form.

Ich glaube, die meisten Macher arbeiten so. Auch Schriftsteller und Architekten scheinen es so zu machen. Vielleicht wäre es gut, wenn Hacker sich mehr wie Maler verhalten und regelmäßig von vorne anfangen würden, anstatt jahrelang an einem Projekt weiterzuarbeiten und zu versuchen, alle ihre späteren Ideen als Überarbeitungen einzubauen.

Die Tatsache, dass Hacker das Hacken durch Tun lernen, ist ein weiteres Zeichen dafür, wie unterschiedlich Hacken von den Wissenschaften ist. Wissenschaftler lernen Wissenschaft nicht durch Tun, sondern durch Laborarbeit und Übungsaufgaben. Wissenschaftler beginnen damit, Arbeiten zu reproduzieren, die andere bereits für sie getan haben. Irgendwann kommen sie dann zu dem Punkt, an dem sie Originalarbeiten leisten können. Hacker hingegen machen von Anfang an Originalarbeiten, die nur sehr schlecht sind. Hacker fangen also originell an und werden gut, während Wissenschaftler gut anfangen und originell werden.

Der andere Weg, auf dem Macher lernen, ist durch Beispiele. Für einen Maler ist ein Museum eine Referenzbibliothek von Techniken. Seit Jahrhunderten ist es Teil der traditionellen Ausbildung von Malern, die Werke großer Meister zu kopieren, denn das Kopieren zwingt einen dazu, genau hinzuschauen, wie ein Gemälde gemacht ist.

Auch Schriftsteller machen das. Benjamin Franklin lernte zu schreiben, indem er die Hauptpunkte in den Essays von Addison und Steele zusammenfasste und dann versuchte, sie nachzuahmen. Raymond Chandler tat dasselbe mit Kriminalgeschichten.

Hacker können ebenfalls durch das Betrachten guter Programme lernen zu programmieren - nicht nur, was sie tun, sondern auch den Quellcode. Einer der weniger bekannten Vorteile der Open-Source-Bewegung ist, dass sie es leichter gemacht hat, programmieren zu lernen. 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 auch dieser war nicht Open Source. Die meisten Leute, die den Quellcode lasen, taten dies in illegalen Fotokopien von John Lions' Buch, das zwar 1977 geschrieben, aber erst 1996 veröffentlicht werden durfte.

Ende des Inhalts.

Ein weiteres Beispiel, das wir aus der Malerei übernehmen können, ist die Art und Weise, wie Gemälde durch schrittweise Verfeinerung geschaffen werden. 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 erweisen sich die ursprünglichen Pläne als falsch. Unzählige Gemälde, wenn man sie mit Röntgenstrahlen betrachtet, erweisen sich als solche, bei denen Gliedmaßen verschoben oder Gesichtsmerkmale neu angepasst 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 sein werden. Es ist besser, dies von vornherein zuzugeben und Programme so zu schreiben, dass sich die Spezifikationen im Fluge ändern lassen.

(Die Struktur großer Unternehmen macht es ihnen schwer, dies zu tun, so dass hier ein weiterer Bereich ist, in dem Start-ups einen Vorteil haben.)

Inzwischen weiß vermutlich jeder um die Gefahr der vorzeitigen Optimierung. Ich denke, wir sollten genauso besorgt über die vorzeitige Gestaltung sein - 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, da man sich nicht von vornherein auf bestimmte Datenrepräsentationen festlegen muss. Aber der Schlüssel zur Flexibilität ist meiner Meinung nach, 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ßes 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, setzte er einen Wacholderbuschhinter ihren Kopf. Darin malte er sorgfältig jedes einzelne Blatt. Viele Maler hätten vielleicht gedacht, das ist nur etwas, um ihren Kopf einzurahmen. 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. Unerbittlich.

Unerbittlichkeit gewinnt, weil im Aggregat unsichtbare Details sichtbar werden. Wenn die Leute an dem Porträt von Ginevra de Benci vorbeigehen, wird ihre Aufmerksamkeit oft sofort von ihm gefesselt, noch bevor sie das Etikett lesen und sehen, dass es Leonardo da Vinci signiert ist. 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 die Schönheit. Wenn man in gute Software hineinschaut, findet man, dass auch Teile, die niemand je sehen soll, schön sind. Ich behaupte nicht, dass ich großartige Software schreibe, aber ich weiß, dass ich, wenn es um Code geht, auf eine Weise handle, die mich für verschreibungspflichtige Medikamente qualifizieren würde, wenn ich im Alltag genauso vorgehen würde. Es treibt mich in den Wahnsinn, wenn ich Code sehe, der schlecht eingerückt ist oder hässliche Variablennamen verwendet.

Wenn ein Hacker nur ein Implementierer wäre, der eine Spezifikation in Code umsetzt, könnte er sich einfach von einem Ende zum anderen durcharbeiten, wie jemand, der einen Graben aushäbt. 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 bist du von einem neuen Projekt so begeistert, dass du sechzehn Stunden am Tag daran arbeiten möchtest. Andere Male scheint nichts interessant zu sein.

Um gute Arbeit zu leisten, musst du diese Zyklen berücksichtigen, denn sie werden davon beeinflusst, wie du darauf reagierst. Wenn du in einem Auto mit Schaltgetriebe einen Berg hochfährst, musst du manchmal den Kupplungspedal etwas loslassen, um ein Stottern zu vermeiden. Zurückziehen kann auch verhindern, dass der Ehrgeiz stottert. Sowohl beim Malen als auch beim Hacking gibt es einige Aufgaben, die furchtbar ehrgeizig sind, und andere, die beruhigend routinemäßig sind. Es ist eine gute Idee, einige einfache Aufgaben für Momente aufzuheben, in denen man sonst stottern würde.

Beim Hacking kann das buchstäblich bedeuten, Fehler aufzusparen. Ich mag das Debuggen: Es ist der einzige Moment, in dem Hacking so geradlinig ist, wie die Leute denken. Du hast ein völlig eingeschränktes Problem und musst 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 beibringen, wie wir unsere eigene Arbeit managen, sondern auch, wie wir zusammenarbeiten. Viel große Kunst der Vergangenheit ist das Werk mehrerer Hände, auch wenn nur ein Name an der Wand im Museum steht. Leonardo war Lehrling in der Werkstatt von Verrocchio und malte einen der Engel in seinem Taufe Christi. Das war eher die Regel als 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, die zusammen an einem Gemälde gearbeitet haben, nie an denselben Teilen gearbeitet. Es war üblich, dass der Meister die Hauptfiguren malte und Assistenten die anderen und den Hintergrund. Aber es gab nie jemanden, der über die Arbeit eines anderen gemalt hat.

Ich denke, dies ist das richtige Modell für die Zusammenarbeit in der Software auch. Nicht zu weit treiben. Wenn ein Stück Code von drei oder vier verschiedenen Leuten bearbeitet wird, von denen keiner wirklich der Besitzer ist, wird es wie ein Gemeinschaftsraum enden. Es wird sich trist und verlassen anfühlen und Kruste ansetzen. Der richtige Weg zur Zusammenarbeit ist meiner Meinung nach, Projekte in scharf definierte Module zu unterteilen, von denen jedes einen eindeutigen Besitzer hat, und die Schnittstellen zwischen ihnen so sorgfältig zu gestalten und, wenn möglich, so zu artikulieren wie Programmiersprachen.

Wie die Malerei ist die meiste Software für ein menschliches Publikum bestimmt. 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 Nutzers zu sehen.

Als ich ein Kind war, wurde mir ständig 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 zu tun, was ich wollte. Das hat der Empathie natürlich einen schlechten Ruf eingebracht, und ich habe mich darauf konzentriert, sie nicht zu kultivieren.

Junge, wie falsch lag ich da. Es stellt sich heraus, dass es praktisch das Geheimnis des Erfolgs ist, die Dinge aus der Sichtweise anderer Menschen zu betrachten. Das bedeutet nicht unbedingt, selbstaufopfernd zu sein. Ganz im Gegenteil. Zu verstehen, wie jemand anderes die Dinge sieht, impliziert nicht, dass du in seinem Interesse handeln wirst; in manchen Situationen - im Krieg zum Beispiel - willst du 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 sie brauchen. Fast alle der größten Gemälde sind Gemälde von Menschen, zum Beispiel, weil Menschen das sind, wofür sich Menschen interessieren.

Empathie ist wahrscheinlich der einzelne wichtigste Unterschied zwischen einem guten Hacker und einem großartigen. Manche Hacker sind ziemlich schlau, aber wenn es um Empathie geht, sind sie praktisch Solipsisten. Es ist für solche Menschen schwierig, großartige Software zu entwerfen [5], weil sie sich nicht in die Sichtweise des Nutzers versetzen können.

Eine Möglichkeit, wie gut Menschen Empathie zeigen, ist es zu beobachten, wie sie eine technische Frage für jemanden ohne technischen Hintergrund erklären. Wir kennen wahrscheinlich alle Menschen, 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 erzeugen." 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. Also um gute Software zu schreiben, musst du verstehen, wie wenig Nutzer verstehen. Sie werden an die Software herantreten, ohne vorbereitet zu sein, und sie muss das tun, was sie vermuten, dass sie tut, denn sie werden das Handbuch nicht lesen. Das beste System, das ich in dieser Hinsicht je gesehen habe, war der ursprüngliche Macintosh, 1985. Es tat, was Software fast nie tut: es funktionierte einfach. [6]

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

Programme sollten für Menschen geschrieben werden, um gelesen zu werden, und nur nebenbei für Maschinen, um ausgeführt zu werden.

Du musst nicht nur Empathie für deine Nutzer haben, sondern auch für deine Leser. Es liegt in deinem Interesse, denn du wirst einer von ihnen sein. Manch ein Hacker hat ein Programm geschrieben, nur um bei der Rückkehr dazu sechs Monate später festzustellen, dass er keine Ahnung hat, wie es funktioniert. Ich kenne mehrere Leute, die Perl nach solchen Erfahrungen geschworen haben. [7]

Mangel an Empathie wird mit Intelligenz in Verbindung gebracht, bis zu dem Punkt, dass es in manchen Kreisen sogar eine Art Mode dafür gibt. Aber ich glaube nicht, dass es eine Korrelation gibt. Du kannst in Mathematik und den Naturwissenschaften gut abschneiden, ohne Empathie lernen zu müssen, und Menschen in diesen Bereichen tendieren dazu, intelligent zu sein, so dass die beiden Eigenschaften miteinander in Verbindung gebracht wurden. Aber es gibt auch jede Menge dumme Menschen, die schlecht in Empathie sind. Hör dir nur die Leute an, die in Talkshows anrufen. Sie fragen, was auch immer sie fragen, auf eine so umständliche Art und Weise, dass die Moderatoren die Frage oft für sie umformulieren müssen.

Also, wenn Hacking wie Malerei und Schreiben funktioniert, ist es dann genauso cool? Schließlich hast du nur ein Leben. Du könntest 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 bei Prestige. Es ist wie das Licht eines fernen Sterns. Malerei hat jetzt Prestige, weil es großartige Arbeiten gibt, die Menschen vor fünfhundert Jahren geschaffen haben. Zu der Zeit dachte niemand, dass diese Gemälde so wichtig sind, wie wir sie heute sehen. Es wäre für die Menschen damals sehr seltsam gewesen, dass Federico da Montefeltro, der Herzog von Urbino, hauptsächlich dafür bekannt sein würde, dass er eine Nase in einem Gemälde von Piero della Francesca hat.

Also, während ich zugebe, dass Hacking nicht so cool erscheint wie Malerei jetzt, sollten wir bedenken, dass Malerei selbst in ihren Glanzzeiten nicht so cool erschien, wie sie es heute tut.

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

und trieb das Medium so weit, dass jeder Dramatiker seit ihm in seinem Schatten stehen muss. Albrecht Dürer tat dasselbe mit dem Kupferstich, und Jane Austen mit dem Roman.

Immer wieder sehen wir dasselbe Muster. Ein neues Medium erscheint, und die Menschen sind so aufgeregt darüber, dass sie die meisten seiner Möglichkeiten in den ersten beiden Generationen erkunden. Hacking scheint sich in dieser Phase zu befinden.

Malerei war zu Leonardos Zeit nicht so cool, wie seine Arbeit dazu beigetragen hat, sie cool zu machen. Wie cool Hacking sich herausstellen wird, 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 haben mag, ist die Tatsache, dass sie den besten Nebenjob getötet hat. Die meisten der großen Maler in der Geschichte haben sich durch das Malen von Porträts über Wasser gehalten.

[2] Mir wurde gesagt, dass Microsoft Mitarbeiter davon abhält, in ihrer Freizeit an Open-Source-Projekten mitzuarbeiten, auch wenn sie das wollen. Aber so viele der besten Hacker arbeiten jetzt an Open-Source- Projekten, dass der Haupteffekt dieser Politik sein mag, dass sie keine erstklassigen Programmierer einstellen können.

[3] Was du in der Uni über Programmierung lernst, ist ähnlich wie was du über Bücher oder Kleidung oder Dates lernst: Welchen schlechten Geschmack du in der Highschool hattest.

[4] Hier ist ein Beispiel für angewandte Empathie. Bei Viaweb, wenn wir uns zwischen zwei Alternativen nicht entscheiden konnten, haben wir uns gefragt, was unsere Konkurrenz am meisten hassen würde? Zu einem Zeitpunkt hatte ein Konkurrent eine Funktion in ihre Software aufgenommen, die im Grunde nutzlos war, aber da es eine der wenigen war, die wir nicht hatten, machten sie viel Aufhebens darüber in der Fachpresse. Wir hätten versuchen können zu erklären, dass die Funktion nutzlos ist, aber wir entschieden, dass es unseren Konkurrenten mehr ärgern würde, wenn wir sie einfach selbst implementieren, also hackten wir am selben Nachmittag unsere eigene Version zusammen.

[5] Außer Textbearbeitungsprogramme und Compiler. Hacker brauchen keine Empathie, um diese zu entwerfen, weil sie selbst typische Nutzer sind.

[6] Nun ja, fast. Sie haben den verfügbaren Arbeitsspeicher etwas überschritten, was zu lästigem Festplattenwechsel führte, aber das konnte innerhalb weniger Monate durch den Kauf eines zusätzlichen Laufwerks behoben werden.

[7] Der Weg, Programme leicht lesbar zu machen, besteht nicht darin, sie mit Kommentaren vollzustopfen. Ich würde Abelson und Sussmans Zitat noch einen Schritt weiter gehen. Programmiersprachen sollten so konzipiert sein, dass sie Algorithmen ausdrücken und nur nebenbei den Computern zeigen, wie man sie ausführt. Eine gute Programmiersprache sollte besser dafür geeignet sein, Software zu erklären als Englisch. Sie sollten nur dann Kommentare verwenden, wenn es eine Art Flickwerk gibt, das Sie die Leser warnen müssen, so wie es auf einer Straße nur Pfeile auf Teilen mit unerwartet scharfen Kurven gibt.

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, hier zu sprechen.