HACKER UND MALER

Mai 2003

(Dieser Aufsatz basiert auf einem Gastvortrag in Harvard, in den ein früherer Vortrag an der Northeastern University einfloss.)

Nach meinem Informatik-Abschluss ging ich auf die Kunsthochschule, um Malerei zu studieren. Viele Leute schienen überrascht, dass jemand, der sich für Computer interessierte, auch an Malerei interessiert war. Sie schienen zu denken, dass Hacken und Malen zwei völlig verschiedene Arten von Arbeit seien – dass Hacken kalt, präzise und methodisch sei und dass Malen der rasende Ausdruck eines urtümlichen Drangs sei.

Beide dieser Bilder sind falsch. Hacken und Malen haben viel gemeinsam. Tatsächlich sind sich Hacker und Maler von allen Menschentypen, die ich kenne, am ähnlichsten.

Hacker und Maler haben gemeinsam, dass sie beide Macher sind. Genau wie Komponisten, Architekten und Schriftsteller versuchen Hacker und Maler, gute Dinge zu schaffen. Sie betreiben zwar keine Forschung an sich, aber wenn sie im Zuge ihres Versuchs, gute Dinge zu schaffen, eine neue Technik entdecken, umso besser.

Ich mochte den Begriff „Informatik“ noch nie. Der Hauptgrund dafür ist, dass es so etwas gar nicht gibt. Die Informatik ist eine Wundertüte aus lose miteinander verbundenen Bereichen, die durch einen Zufall der Geschichte zusammengewürfelt wurden, wie zum Beispiel Jugoslawien. Am einen Ende gibt es Leute, die eigentlich Mathematiker sind, aber das, was sie tun, Informatik nennen, damit sie DARPA-Zuschüsse bekommen. In der Mitte gibt es Leute, die an so etwas wie der Naturgeschichte der Computer arbeiten – sie untersuchen beispielsweise das Verhalten von Algorithmen zur Datenweiterleitung durch Netzwerke. Und am anderen Ende gibt es die Hacker, die versuchen, interessante Software zu schreiben, und für die Computer nur ein Ausdrucksmittel sind, wie Beton für Architekten oder Farbe für Maler. Es ist, als müssten Mathematiker, Physiker und Architekten alle in derselben Abteilung sein.

Manchmal wird die Arbeit der Hacker als „Software-Engineering“ bezeichnet, aber dieser Begriff ist genauso irreführend. Gute Software-Designer sind ebenso wenig Ingenieure wie Architekten. Die Grenze zwischen Architektur und Engineering ist nicht scharf definiert, aber sie ist da. Sie verläuft 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 gehalten werden. Sie fangen sich Ärger ein, wenn Sie versuchen zu entscheiden, was zu tun ist, ohne zu wissen, wie es geht. Aber Hacken kann durchaus mehr sein, als nur zu entscheiden, wie eine Spezifikation implementiert wird. Im besten Fall erstellt es die Spezifikation – obwohl sich herausgestellt hat, dass die beste Art, dies zu tun, darin besteht, sie zu implementieren.

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

Die Bündelung all dieser unterschiedlichen Arbeiten in einer Abteilung mag administrativ praktisch sein, ist aber intellektuell verwirrend. Das ist der andere Grund, warum mir der Name „Informatik“ nicht gefällt. Man könnte argumentieren, dass die Leute in der Mitte so etwas wie eine experimentelle Wissenschaft betreiben. Aber die Leute an beiden Enden, die Hacker und die Mathematiker, betreiben eigentlich keine Wissenschaft.

Die Mathematiker scheint das nicht zu stören. Sie machen sich fröhlich an die Arbeit und beweisen Theoreme wie die anderen Mathematiker in der Mathematikabteilung, und werden wahrscheinlich bald nicht mehr bemerken, dass an dem Gebäude, in dem sie arbeiten, „Informatik“ steht. Für die Hacker ist dieses Etikett jedoch ein Problem. Wenn das, was sie tun, als Wissenschaft bezeichnet wird, haben sie das Gefühl, sie müssten wissenschaftlich vorgehen. Anstatt also das zu tun, was sie wirklich tun wollen, nämlich schöne Software zu entwickeln, haben Hacker an Universitäten und Forschungslaboren das Gefühl, sie sollten Forschungsarbeiten schreiben.

Im besten Fall sind die Papiere 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 die Software darstellt. Aber oft führt diese Diskrepanz zu Problemen. Es ist leicht, vom Bauen schöner Dinge abzuweichen und hässliche Dinge zu bauen, die geeignetere Themen für Forschungspapiere darstellen.

Leider sind schöne Dinge nicht immer die besten Themen für Aufsätze. Erstens muss die Forschung originell sein – und wie jeder, der schon einmal eine Doktorarbeit geschrieben hat, weiß, kann man sicher sein, dass man Neuland betritt, indem man ein Stück Land absteckt, das niemand haben will. Zweitens muss die Forschung substanziell sein – und schwierige Systeme führen zu gehaltvolleren Aufsätzen, weil man über die Hindernisse schreiben kann, die man überwinden muss, um etwas zu erledigen. Nichts führt zu gehaltvollen Problemen mehr, als von den falschen Annahmen auszugehen. Ein Großteil der KI ist ein Beispiel für diese Regel; wenn man davon ausgeht, dass Wissen als Liste prädikatenlogischer Ausdrücke dargestellt werden kann, deren Argumente abstrakte Konzepte darstellen, wird man eine Menge Aufsätze darüber schreiben müssen, wie man das hinbekommt. Wie Ricky Ricardo immer sagte: „Lucy, du hast eine Menge zu erklären.“

Um etwas Schönes zu schaffen, muss man oft subtile Änderungen an etwas Vorhandenem vornehmen oder vorhandene Ideen auf eine leicht neue Art und Weise kombinieren. Diese Art von Arbeit lässt sich in einer Forschungsarbeit nur schwer vermitteln.

Warum beurteilen Universitäten und Forschungslabors Hacker also weiterhin anhand ihrer Veröffentlichungen? Aus demselben Grund, aus dem die „schulische Begabung“ durch einfache standardisierte Tests gemessen wird oder die Produktivität von Programmierern anhand von Codezeilen. Diese Tests sind einfach anzuwenden und nichts ist verlockender als ein einfacher Test, der einigermaßen funktioniert.

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

Der einzige äußere Test ist die Zeit. Im Laufe der Zeit gedeihen schöne Dinge und hässliche Dinge werden weggeworfen. Leider kann die dafür benötigte Zeit länger sein als ein Menschenleben. Samuel Johnson sagte, es dauere hundert Jahre, bis sich der Ruf eines Schriftstellers festige. Man muss warten, bis die einflussreichen Freunde des Schriftstellers sterben und dann alle seine Anhänger.

Ich denke, Hacker müssen sich damit abfinden, dass ihr Ruf zu einem großen Teil vom Zufall abhängt. Darin unterscheiden sie sich nicht von anderen Machern. Im Vergleich haben sie sogar Glück. Der Einfluss der Mode ist beim Hacken nicht annähernd so groß wie in der Malerei.

Es gibt schlimmere Dinge, als wenn die Leute Ihre Arbeit missverstehen. Eine noch größere Gefahr besteht darin, dass Sie Ihre Arbeit selbst missverstehen. Ideen suchen Sie in verwandten Bereichen. Wenn Sie beispielsweise in der Informatikabteilung arbeiten, besteht die natürliche Versuchung zu glauben, dass Hacking die angewandte Version dessen ist, wovon die theoretische Informatik die Theorie ist. Während meines gesamten Studiums hatte ich das unangenehme Gefühl im Hinterkopf, dass ich mehr Theorie wissen sollte und dass es sehr nachlässig von mir war, das alles drei Wochen vor der Abschlussprüfung wieder vergessen zu haben.

Jetzt ist mir klar, dass ich mich geirrt habe. Hacker müssen die Theorie der Berechnung ungefähr so gut verstehen wie Maler die Chemie von Farben. Sie müssen wissen, wie man Zeit- und Raumkomplexität berechnet und wie Turing-Vollständigkeit funktioniert. Sie sollten sich vielleicht auch zumindest das Konzept einer Zustandsmaschine merken, falls Sie einen Parser oder eine Bibliothek für reguläre Ausdrücke schreiben müssen. Maler müssen sich tatsächlich noch viel mehr über die Chemie von Farben merken.

Ich habe festgestellt, dass die besten Ideenquellen nicht die anderen Bereiche sind, die das Wort „Computer“ in ihrem Namen haben, sondern die anderen Bereiche, in denen Macher tätig sind. Die Malerei war eine viel reichere Ideenquelle als die Computertheorie.

So wurde mir beispielsweise im College beigebracht, dass man ein Programm zuerst komplett auf Papier ausarbeiten sollte, bevor man sich überhaupt an einen Computer setzt. Ich stellte fest, dass ich nicht auf diese Weise programmierte. Ich stellte fest, dass ich lieber vor einem Computer saß und nicht vor einem Stück Papier. Schlimmer noch: Anstatt geduldig ein vollständiges Programm zu schreiben und mich zu vergewissern, dass es richtig war, neigte ich dazu, einfach Code auszuspucken, der hoffnungslos fehlerhaft war, und ihn nach und nach in Form zu bringen. Debuggen, so wurde mir beigebracht, war eine Art letzter Durchgang, bei dem man Tippfehler und Versehen entdeckte. So wie ich arbeitete, schien es, als bestünde Programmieren aus Debuggen.

Lange Zeit habe ich mich deswegen schlecht gefühlt, so wie ich mich einst schlecht gefühlt habe, weil ich meinen Bleistift nicht so gehalten habe, wie man es mir in der Grundschule beigebracht hat. Wenn ich nur zu den anderen Machern, den Malern oder den Architekten hinübergeschaut hätte, wäre mir klar geworden, dass es einen Namen für das gab, was ich tat: Skizzieren. Soweit ich das beurteilen kann, war die Art, wie man mir im College das Programmieren beigebracht hat, völlig falsch. Man sollte Programme beim Schreiben entwickeln, so wie es Schriftsteller, Maler und Architekten tun.

Diese Erkenntnis hat echte Auswirkungen auf die Softwareentwicklung. Es bedeutet, dass eine Programmiersprache vor allem formbar sein sollte. Eine Programmiersprache ist dazu da, sich Programme auszudenken , nicht um 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 College beigebracht haben. Aber keiner der Hacker, die ich kenne, schreibt so. Wir brauchen eine Sprache, die uns kritzeln und verwischen lässt, und keine Sprache, in der man mit einer Teetasse voller Typen auf dem Schoß sitzen und höfliche Gespräche mit einer strengen alten Tante von einem Compiler führen muss.

Wenn wir schon beim Thema statische Typisierung sind, wird uns die Identifikation mit den Machern vor einem weiteren Problem bewahren, das die Wissenschaften plagt: dem Mathematikneid. Jeder in der Wissenschaft glaubt insgeheim, dass Mathematiker schlauer sind als sie selbst. Ich glaube, Mathematiker glauben das auch. Jedenfalls führt das dazu, dass Wissenschaftler dazu neigen, ihre Arbeit so mathematisch wie möglich aussehen zu lassen. In einem Bereich wie der Physik schadet das wahrscheinlich nicht viel, aber je weiter man sich von den Naturwissenschaften entfernt, desto problematischer wird es.

Eine Seite mit Formeln sieht einfach so beeindruckend aus. (Tipp: Verwenden Sie griechische Variablen, um die Wirkung noch zu verstärken.) Daher ist die Versuchung groß, an Problemen zu arbeiten, die Sie formal behandeln können, statt an Problemen, die beispielsweise wichtig sind.

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

Wenn Universitäten und Forschungslabore Hacker davon abhalten, die Arbeit zu verrichten, die sie tun möchten, sind sie vielleicht eher in Unternehmen aufgehoben. 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.

Ich selbst habe das erst vor kurzem entdeckt. Als Yahoo Viaweb kaufte, fragten sie mich, was ich machen wolle. Ich hatte die geschäftliche Seite nie besonders gemocht und sagte, ich wolle einfach nur hacken. Als ich zu Yahoo kam, stellte ich fest, dass Hacken für sie das Implementieren von Software bedeutete, nicht das Entwerfen. Programmierer wurden als Techniker angesehen, die die Visionen (wenn man das so sagen kann) von Produktmanagern in Code übersetzten.

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

Wenn Sie irgendwann einmal Geld verdienen möchten, denken Sie daran, denn das ist einer der Gründe, warum Startups gewinnen. Große Unternehmen wollen die Standardabweichung der Designergebnisse verringern, um Katastrophen zu vermeiden. Wenn Sie jedoch Schwingungen dämpfen, verlieren Sie sowohl die Hochpunkte als auch die Tiefpunkte. Für große Unternehmen ist das 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, in einen Designkrieg mit einem Unternehmen zu geraten, das so groß ist, dass seine Software von Produktmanagern entwickelt wird, wird dieses niemals mit Ihnen mithalten können. Solche Gelegenheiten sind allerdings nicht leicht zu finden. Es ist schwierig, ein großes Unternehmen in einen Designkrieg zu verwickeln, genauso wie es schwierig ist, einen Gegner in einer Burg im Nahkampf zu bekämpfen. Es wäre ziemlich einfach, beispielsweise ein besseres Textverarbeitungsprogramm als Microsoft Word zu schreiben, aber Microsoft würde es in der Burg seines Betriebssystemmonopols wahrscheinlich nicht einmal bemerken, wenn Sie es täten.

Der Ort, an dem Designkriege ausgetragen werden, sind neue Märkte, in denen es noch niemandem gelungen ist, Festungen zu errichten. Dort kann man große Erfolge erzielen, wenn man beim Design mutig vorgeht und dieselben Leute das Produkt entwerfen und implementieren lässt. Microsoft selbst hat das zu Beginn getan. Apple auch. Und Hewlett-Packard. Ich vermute, fast jedes erfolgreiche Startup hat das getan.

Eine Möglichkeit, großartige Software zu entwickeln, besteht darin, ein eigenes Startup zu gründen. Das bringt allerdings zwei Probleme mit sich. Erstens muss man in einem Startup so viel mehr tun als nur Software zu schreiben. Bei Viaweb war ich froh, wenn ich ein Viertel der Zeit hacken durfte. Und die Dinge, die ich in den anderen drei Vierteln der Zeit tun musste, reichten von langweilig bis furchterregend. Ich habe einen Maßstab dafür, denn einmal musste ich eine Vorstandssitzung verlassen, um Löcher füllen zu lassen. Ich erinnere mich, wie ich im Zahnarztstuhl saß, auf den Bohrer wartete und mich fühlte, als wäre ich im Urlaub.

Das andere Problem bei Startups ist, dass es kaum Überschneidungen zwischen der Art von Software gibt, mit der man Geld verdienen kann, und der Art, die interessant zu schreiben ist. Programmiersprachen sind interessant zu schreiben, und Microsofts erstes Produkt war tatsächlich eine solche, aber heute will niemand mehr für Programmiersprachen bezahlen. Wer Geld verdienen will, ist in der Regel gezwungen, an Problemen zu arbeiten, die zu kompliziert sind, als dass sie jemand umsonst lösen könnte.

Alle Hersteller stehen vor diesem Problem. Die Preise werden durch Angebot und Nachfrage bestimmt, und es gibt einfach nicht so viel Nachfrage nach Dingen, an denen man Spaß hat, wie nach Dingen, die die alltäglichen Probleme einzelner Kunden lösen. In Off-Broadway-Stücken zu spielen, ist einfach nicht so lukrativ wie in einem Gorillakostüm an einem Messestand aufzutreten. Romane zu schreiben ist nicht so lukrativ wie Werbetexte für Müllentsorgungsanlagen zu schreiben. Und Programmiersprachen zu hacken ist nicht so lukrativ wie herauszufinden, wie man die alte Datenbank einer Firma mit ihrem Webserver verbindet.

Ich denke, die Antwort auf dieses Problem ist im Fall von Software ein Konzept, das fast allen Machern bekannt ist: der Tagesjob. Dieser Begriff stammt von Musikern, die nachts auftreten. Allgemeiner ausgedrückt bedeutet er, dass man eine Art von Arbeit des Geldes wegen und eine andere aus Liebe verrichtet.

Fast alle Macher haben zu Beginn ihrer Karriere einen Tagesjob. Maler und Schriftsteller tun das 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 einen Tagesjob damit bekommen. [1]

Wenn ich sage, dass die Antwort darin besteht, dass Hacker einen normalen Job haben und nebenher an toller Software arbeiten, dann schlage ich das nicht als neue Idee vor. Darum geht es beim Open-Source-Hacking. Was ich sagen will, ist, dass Open Source wahrscheinlich das richtige Modell ist, weil es von allen anderen Herstellern unabhängig bestätigt wurde.

Es überrascht mich, dass ein Arbeitgeber zögern würde, Hacker an Open-Source-Projekten arbeiten zu lassen. Bei Viaweb hätten wir nur ungern jemanden eingestellt, der das nicht getan hätte. Als wir Programmierer interviewten, war uns am wichtigsten, welche Art von Software sie in ihrer Freizeit geschrieben hatten. 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, sollte man Metaphern nicht in den Wissenschaften suchen, sondern bei anderen Machern. Was kann uns die Malerei sonst noch über Hacker lehren?

Eine Sache, die wir aus dem Beispiel der Malerei lernen oder zumindest bestätigen können, ist, wie man das Hacken lernt. Malen lernt man hauptsächlich dadurch, dass man es tut. Das Gleiche gilt für das Hacken. Die meisten Hacker lernen das Hacken nicht, indem sie an der Uni Programmierkurse belegen. Sie lernen das Hacken, indem sie im Alter von dreizehn Jahren eigene Programme schreiben. Sogar in Collegekursen lernt man das Hacken hauptsächlich durch Hacken. [3]

Da Maler eine Werkspur hinterlassen, können Sie ihnen beim Lernen durch Tun zusehen. Wenn Sie sich die Arbeit eines Malers in chronologischer Reihenfolge ansehen, werden Sie feststellen, dass jedes Gemälde auf Dingen aufbaut, die in früheren Gemälden gelernt wurden. Wenn etwas in einem Gemälde sehr gut funktioniert, können Sie Version 1 davon normalerweise in kleinerer Form in einem früheren Gemälde finden.

Ich denke, die meisten Macher arbeiten so. Autoren und Architekten scheinen das auch zu tun. Vielleicht wäre es gut, wenn Hacker sich mehr wie Maler verhielten und regelmäßig von vorne beginnen würden, statt jahrelang an einem Projekt weiterzuarbeiten und zu versuchen, alle ihre späteren Ideen in Überarbeitungen einzubauen.

Die Tatsache, dass Hacker das Hacken durchs Tun lernen, ist ein weiteres Zeichen dafür, wie sehr sich Hacken von den Wissenschaften unterscheidet. Wissenschaftler lernen die Wissenschaft nicht durchs Tun, sondern durch Laborarbeit und Problemlösungen. Wissenschaftler beginnen mit perfekter Arbeit, in dem Sinne, dass sie nur versuchen, die Arbeit zu reproduzieren, die jemand anderes bereits für sie erledigt hat. Irgendwann kommen sie an den Punkt, an dem sie originelle Arbeit leisten können. Hacker hingegen leisten von Anfang an originelle Arbeit, die nur sehr schlecht ist. Hacker beginnen also originell und werden gut, und Wissenschaftler beginnen gut und werden originell.

Künstler lernen auch anhand von Beispielen. 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, denn das Kopieren zwingt einen dazu, sich die Entstehung eines Gemäldes genau anzuschauen.

Auch Schriftsteller tun dies. Benjamin Franklin lernte das Schreiben, indem er die Punkte in den Essays von Addison und Steele zusammenfasste und dann versuchte, sie wiederzugeben. Raymond Chandler tat dasselbe mit Kriminalromanen.

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

Ein weiteres Beispiel aus der Malerei 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. Bei unzähligen Gemälden stellt sich auf Röntgenbildern heraus, dass Gliedmaßen verschoben oder Gesichtszüge neu angeordnet wurden.

Hier ist ein Fall, in dem wir vom Malen lernen können. Ich denke, Hacken sollte auch so funktionieren. Es ist unrealistisch zu erwarten, dass die Spezifikationen für ein Programm perfekt sind. Sie sind besser dran, wenn Sie dies von vornherein zugeben und Programme so schreiben, dass sich die Spezifikationen spontan ändern können.

(Großunternehmen fällt dies aufgrund ihrer Struktur schwer, sodass Startups auch hier im Vorteil sind.)

Mittlerweile ist sich vermutlich jeder der Gefahren einer voreiligen Optimierung bewusst. Ich denke, wir sollten uns genauso viele Sorgen um voreilige Entwürfe machen – wenn wir zu früh entscheiden, was ein Programm tun soll.

Die richtigen Werkzeuge können uns helfen, diese Gefahr zu vermeiden. Eine gute Programmiersprache sollte es, wie Ölfarbe, leicht machen, seine Meinung zu ändern. Dynamische Typisierung ist hier ein Vorteil, weil man sich nicht von vornherein auf bestimmte Datendarstellungen festlegen muss. Aber der Schlüssel zur Flexibilität liegt meiner Meinung nach darin, 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 beispielsweise das Porträt von Ginevra de Benci in der Nationalgalerie malte, platzierte er einen Wacholderbusch hinter ihrem Kopf. Darin malte er sorgfältig jedes einzelne Blatt. Viele Maler dachten vielleicht, das sei nur etwas, das man in den Hintergrund stellt, um ihren Kopf einzurahmen. Niemand wird es sich so genau ansehen.

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

Die Unerbittlichkeit siegt, denn in der Gesamtheit werden unsichtbare Details sichtbar. Wenn Menschen an dem Porträt von Ginevra de Benci vorbeigehen, wird ihre Aufmerksamkeit oft sofort davon gefesselt, noch bevor sie auf das Etikett schauen und bemerken, dass dort Leonardo da Vinci steht. All diese unsichtbaren Details ergeben zusammen etwas einfach Atemberaubendes, wie tausend kaum hörbare Stimmen, die alle im Einklang singen.

Tolle Software erfordert ebenfalls eine fanatische Hingabe an Schönheit. Wenn Sie sich das Innere guter Software ansehen, werden Sie feststellen, dass Teile, die niemand jemals sehen sollte, auch schön sind. Ich behaupte nicht, dass ich tolle Software schreibe, aber ich weiß, dass ich mich beim Coden 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, Code zu sehen, der schlecht eingerückt ist oder hässliche Variablennamen verwendet.

Wäre ein Hacker bloßer Implementierer, der eine Spezifikation in Code umsetzt, könnte er sich 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 Hacken verläuft die Arbeit, genau wie beim Malen, in Zyklen. Manchmal ist man von einem neuen Projekt begeistert und möchte sechzehn Stunden am Tag daran arbeiten. Ein anderes Mal scheint nichts interessant zu sein.

Um gute Arbeit zu leisten, müssen Sie diese Zyklen berücksichtigen, denn sie werden davon beeinflusst, wie Sie darauf reagieren. Wenn Sie ein Auto mit manueller Schaltung einen Berg hinauffahren, müssen Sie manchmal die Kupplung loslassen, um ein Abwürgen zu vermeiden. Das Loslassen kann ebenso verhindern, dass der Ehrgeiz ins Stocken gerät. Sowohl beim Malen als auch beim Hacken gibt es einige Aufgaben, die furchterregend ehrgeizig sind, und andere, die beruhigende Routine sind. Es ist eine gute Idee, einige einfache Aufgaben für Momente aufzuheben, in denen Sie sonst ins Stocken geraten würden.

Beim Hacken kann das buchstäblich bedeuten, Fehler zu sammeln. Ich mag das Debuggen: Das ist der einzige Fall, in dem Hacken so unkompliziert ist, wie die Leute denken. Sie haben ein völlig eingeschränktes Problem und müssen es nur lösen. Ihr Programm soll x tun. Stattdessen tut es y. Wo läuft es schief? Sie wissen, dass Sie am Ende gewinnen werden. 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. Viele der großen Kunstwerke der Vergangenheit sind das Werk mehrerer Hände, auch wenn im Museum vielleicht nur ein Name an der Wand daneben steht. Leonardo war Lehrling in der Werkstatt von Verrocchio und malte einen der Engel in dessen Taufe Christi . So etwas 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ß, haben Maler, wenn sie gemeinsam an einem Gemälde gearbeitet haben, nie an denselben Teilen gearbeitet. Es war üblich, dass der Meister die Hauptfiguren malte und die Assistenten die anderen Figuren und den Hintergrund. Aber es kam nie vor, dass einer die Arbeit eines anderen übermalte.

Ich denke, dies ist auch das richtige Modell für die Zusammenarbeit im Softwarebereich. Übertreiben Sie es nicht. Wenn ein Stück Code von drei oder vier verschiedenen Leuten gehackt wird, von denen keiner wirklich Eigentümer ist, wird es am Ende wie ein Gemeinschaftsraum. Es wird sich trostlos und verlassen anfühlen und Müll ansammeln. Die richtige Art der Zusammenarbeit besteht meiner Meinung nach darin, Projekte in klar definierte Module aufzuteilen, jedes mit einem eindeutigen Eigentümer und mit Schnittstellen zwischen ihnen, die so sorgfältig entworfen und, wenn möglich, so artikuliert sind wie Programmiersprachen.

Wie Gemälde 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. Sie müssen in der Lage sein, die Dinge aus der Sicht des Benutzers zu sehen.

Als Kind wurde mir immer gesagt, ich solle die Dinge aus der Perspektive eines anderen betrachten. In der Praxis bedeutete das immer, das zu tun, was jemand anderes wollte, statt das, was ich wollte. Das brachte Empathie natürlich in Verruf, und ich legte Wert darauf, sie nicht zu kultivieren.

Junge, lag ich falsch. Es stellt sich heraus, dass es praktisch das Erfolgsgeheimnis ist, die Dinge aus der Sicht anderer Leute zu betrachten. Das bedeutet nicht unbedingt, aufopfernd zu sein. Ganz im Gegenteil. Zu verstehen, wie jemand anderes die Dinge sieht, bedeutet nicht, dass man in seinem Interesse handelt; in manchen Situationen – im Krieg zum Beispiel – möchte man genau das Gegenteil tun. [4]

Die meisten Künstler fertigen Dinge für ein menschliches Publikum. Und um ein Publikum zu fesseln, muss man verstehen, was es braucht. Fast alle großen Gemälde sind beispielsweise Gemälde von Menschen, weil Menschen das sind, woran sich die Menschen interessieren.

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

Eine Möglichkeit, herauszufinden, wie gut Menschen Empathie verspüren, besteht darin, ihnen dabei zuzuschauen, wie sie jemandem ohne technischen Hintergrund eine technische Frage erklären. Wir alle kennen wahrscheinlich Leute, die zwar ansonsten klug sind, aber einfach lächerlich schlecht darin sind. Wenn sie jemand bei einer Dinnerparty fragt, was eine Programmiersprache ist, werden sie so etwas sagen wie: „Oh, eine höhere Programmiersprache ist das, was der Compiler als Eingabe verwendet, um Objektcode zu generieren.“ Höhere Programmiersprache? Compiler? Objektcode? Jemand, der nicht weiß, was eine Programmiersprache ist, weiß offensichtlich auch nicht, was diese Dinge sind.

Software muss sich unter anderem selbst erklären. Um gute Software zu schreiben, muss man also verstehen, wie wenig die Benutzer verstehen. Sie werden sich der Software ohne Vorbereitung nähern, und sie sollte besser das tun, was sie erwarten, denn sie werden das Handbuch nicht lesen. Das beste System, das ich in dieser Hinsicht je gesehen habe, war der ursprüngliche Macintosh von 1985. Er tat, was Software fast nie tut: Er funktionierte einfach. [6]

Auch Quellcode sollte sich selbst erklären. Wenn ich die Leute dazu bringen könnte, sich nur ein Zitat über das Programmieren zu merken, dann wäre es das am Anfang von „Struktur und Interpretation von Computerprogrammen“.

Programme sollten so geschrieben werden, dass sie von Menschen gelesen werden können und nur nebenbei für die Ausführung durch Maschinen.

Sie müssen nicht nur Empathie für Ihre Benutzer, sondern auch für Ihre Leser haben. Das liegt in Ihrem Interesse, denn Sie werden einer von ihnen sein. So mancher Hacker hat ein Programm geschrieben, nur um sechs Monate später festzustellen, dass er keine Ahnung hat, wie es funktioniert. Ich kenne mehrere Leute, die nach solchen Erfahrungen Perl abgeschworen haben. [7]

Mangelnde Empathie wird mit Intelligenz in Verbindung gebracht, und mancherorts ist sie sogar in Mode gekommen. Aber ich glaube nicht, dass da ein Zusammenhang besteht. Man kann in Mathematik und Naturwissenschaften gut sein, ohne Empathie lernen zu müssen, und die Leute in diesen Bereichen sind in der Regel intelligent, also werden diese beiden Eigenschaften miteinander in Verbindung gebracht. Aber es gibt auch viele dumme Leute, denen es an Empathie mangelt. Hören Sie sich nur die Leute an, die in Talkshows anrufen und Fragen stellen. Sie stellen ihre Fragen so umständlich, dass die Moderatoren die Frage oft umformulieren müssen.

Wenn Hacken also genauso cool ist wie Malen und Schreiben? Schließlich hat man nur ein Leben. Man kann es genauso gut damit verbringen, an etwas Großartigem zu arbeiten.

Leider ist diese Frage schwer zu beantworten. Prestige entsteht immer erst mit einer großen zeitlichen Verzögerung. Es ist wie Licht von einem fernen Stern. Malerei hat heute Prestige, weil die Menschen vor fünfhundert Jahren großartige Arbeit geleistet haben. Damals hielt niemand diese Gemälde für so wichtig wie wir heute. Es wäre den Leuten damals sehr merkwürdig vorgekommen, dass Federico da Montefeltro, der Herzog von Urbino, eines Tages vor allem als der Typ mit der seltsamen Nase auf einem Gemälde von Piero della Francesca bekannt sein würde.

Auch wenn ich zugebe, dass Hacken heute nicht mehr so cool ist wie Malen, sollten wir doch bedenken, dass die Malerei selbst in ihren Glanzzeiten nicht so cool war wie heute.

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 zwischen 1430 und 1500 entstandenen Gemälde sind noch immer unübertroffen. Shakespeare erschien gerade, als das professionelle Theater geboren wurde,

und hat das Medium so weit vorangetrieben, dass jeder Dramatiker seitdem in seinem Schatten leben 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 Leute sind so begeistert davon, dass sie die meisten seiner Möglichkeiten in den ersten paar Generationen erkunden. Hacking scheint sich derzeit in dieser Phase zu befinden.

Zu Leonardos Zeiten war die Malerei nicht so cool, wie seine Werke sie machten. Wie cool Hacking wird, hängt davon ab, was wir mit diesem neuen Medium machen können.

Hinweise

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

[2] Mir wurde gesagt, dass Microsoft seine Mitarbeiter davon abhält, an Open-Source-Projekten mitzuarbeiten, auch nicht in ihrer Freizeit. Aber mittlerweile arbeiten so viele der besten Hacker an Open-Source-Projekten, dass der Haupteffekt dieser Politik darin bestehen könnte, sicherzustellen, dass sie keine erstklassigen Programmierer mehr einstellen können.

[3] Was Sie im College über das Programmieren lernen, ähnelt dem, was Sie über Bücher, Kleidung oder Dating lernen: welchen schlechten Geschmack Sie in der High School hatten.

[4] Hier ist ein Beispiel für angewandte Empathie. Wenn wir uns bei Viaweb nicht zwischen zwei Alternativen entscheiden konnten, fragten wir uns, was unsere Konkurrenten am meisten hassen würden. Einmal fügte ein Konkurrent seiner Software eine Funktion hinzu, die im Grunde nutzlos war, aber da es eine der wenigen war, die sie hatten und wir nicht, machten sie in der Fachpresse viel Aufhebens darum. 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 implementierten, also hackten wir noch am selben Nachmittag unsere eigene Version zusammen.

[5] Ausgenommen hiervon sind Texteditoren und Compiler. Für deren Entwicklung benötigen Hacker keine Empathie, da sie selbst typische Benutzer sind.

[6] Naja, fast. Sie überschritten den verfügbaren Arbeitsspeicher etwas, was zu vielen umständlichen Festplattenwechseln führte, aber dies könnte innerhalb weniger Monate durch den Kauf eines zusätzlichen Festplattenlaufwerks behoben werden.

[7] Programme lassen sich nicht leicht lesen, indem man sie mit Kommentaren vollstopft. Ich würde das Zitat von Abelson und Sussman noch einen Schritt weiter führen. Programmiersprachen sollten so gestaltet sein, dass sie Algorithmen ausdrücken, und nur nebenbei Computern sagen, wie sie diese ausführen sollen. Eine gute Programmiersprache sollte Software besser erklären können als Englisch. Kommentare sollten nur dann nötig sein, wenn es irgendeine Art von Klischee gibt, vor dem man die Leser warnen muss, so wie es auf einer Straße nur Pfeile auf Abschnitten mit unerwartet scharfen Kurven gibt.

Mein Dank geht an Trevor Blackwell, Robert Morris, Dan Giffin und Lisa Randall für das Lesen der Entwürfe und an Henry Leitner und Larry Finkelstein für die Einladung zum Vortrag.