Hacker und Maler

Home

Original von Paul Graham, im Mai 2003

Sponsored by affordable papers by experts

Aus dem Amerikanischen von Alexander Zrim


(Dieser Essay geht aus einer Gastvorlesung in Harvard hervor, welche wiederum Ideen aus einem vorhergehenden Vortrag am Northeastern beinhaltete)

Als ich mein Doktoratsstudium der Informatik abschloss, ging ich an eine Kunstakademie, um Malerei zu studieren. Viele Leute schienen davon überrascht zu sein, dass sich jemand der sich für Computer interessiert auch für Malerei interessieren kann. Sie schienen zu denken, dass es sich bei Hacken und Malen um unterschiedliche Arten von Arbeit handle - dass Hacken kalt, präzise und methodisch sei, und Malen der frenetische Ausdruck eines Urtriebes.

Diese Bilder sind beide falsch; Hacken und Malen haben viel gemeinsam. Tatsächlich ähneln sich Hacker und Maler von allen unterschiedlichen Arten von Personen die ich kennen gelernt habe am meisten.

Gemeinsam haben Hacker und Maler, dass sie beide Schöpfer [AdÜ: der im Original verwendete Begriff "maker" mag bestimmt weniger opulente Assoziationen hervorrufen] sind. Wie Komponisten, Architekten und Schriftsteller versuchen Hacker sowie Maler, gute Gegenstände herzustellen. Sie betreiben an sich keine Forschung; wenn sie jedoch beim Versuch, gute Gegenstände herzustellen, eine neue Technik entdecken - um so besser.


Ich konnte den englischen Begriff für Informatik, "computer science" (Computerwissenschaft), noch nie leiden. Der Hauptgrund dafür ist, dass es so etwas einfach nicht gibt. Informatik ist ein Sammelsurium dürftig zusammengehöriger Gebiete, die wie Jugoslawien durch historischen Zufall zusammengewürfelt wurden. Am einen Ende hat man Leute, die in Wirklichkeit Methematiker sind; das was sie tun aber Informatik nennen, damit sie Subventionen der DARPA erhalten können. In der Mitte hat man Leute, die an so etwas wie der Naturgeschichte der Computer arbeiten; beispielsweise wird hier das Verhalten von Data-Routing-Algorithmen für Netzwerke erforscht. Und schließlich hat man am anderen Extrem die Hacker; sie versuchen interessante Software zu schreiben - für sie sind Computer nur ein Ausdrucksmedium, wie es Beton für Architekten ist, oder Malfarbe für Maler. Es ist, als ob Mathematiker, Physiker und Architekten alle in derselben Abteilung sein müssten.

Manchmal wird die Tätigkeit von Hackern "Software Engineering" genannt; diese Bezeichnung ist aber genau so irreführend. Gute Software Designer sind genau so wenig Ingeniere wie Architekten es sind. Die Grenze zwischen Architektur und Ingenieurskunst ist nicht klar definiert, aber sie ist vorhanden. Sie verläuft zwischen dem Was und dem Wie: Architekten entscheiden, was zu tun ist und Ingenieure finden heraus, wie es zu tun ist.

Das Was und das Wie sollten nicht zu weit voneinander getrennt gehalten werden. Wenn man versucht zu entscheiden, was man tun soll, ohne zu verstehen, wie man es erledigt, fordert man Schwierigkeiten heraus. Aber Hacken kann bestimmt mehr sein, als lediglich zu entscheiden, wie man eine Spezifikation implementiert. In höchster Form ist es das Erstellen der Spezifikation - obwohl es sich herausstellt, dass der beste Weg dafür ist, sie zu implementieren.


Vielleicht wird die "Computerwissenschaft" eines Tages - wie Jugoslawien - in ihre Einzelteile aufgebrochen werden. Das könnte eine gute Sache sein; vor Allem, wenn es Unabhängigkeit für das Hacken, mein Heimatland, bedeuten würde.

Das Zusammenbündeln all dieser verschiedenen Arten von Arbeit in eine Abteilung mag vielleicht verwaltungstechnisch bequem sein, intellektuell hingegen ist es verwirrend. Das ist der andere Grund, warum ich den Begriff "Computerwissenschaft" nicht mag. Man könnte mit Recht behaupten, dass die Leute in der Mitte etwas wie eine experimentelle Wissenschaft betreiben. Die Leute an beiden Enden hingegen - die Hacker und die Mathematiker - betreiben nicht wirklich Wissenschaft.

Die Mathematiker scheint das nicht weiter zu stören. Sie machen sich wie die anderen Mathematiker drüben in der Mathematik-Abteilung fröhlich daran, Sätze zu beweisen und merken vermutlich schon bald nicht mehr, dass draußen am Gebäude, in dem sie arbeiten, Informatik steht. Für die Hacker jedoch ist diese Beschriftung ein Problem. Wenn das was sie tun Wissenschaft genannt wird, finden sie, dass sie sich auch wissenschaftlich verhalten sollten. Daher finden Hacker in Universitäten und Forschungseinrichtungen, dass sie Forschungsarbeiten schreiben sollten, anstatt das zu tun, was sie wirklich tun wollen: schöne Software entwerfen.

Im günstigsten Fall sind diese Arbeiten nur eine Formalität. Hacker schreiben coole Software und schreiben dann eine Arbeit darüber - und die Arbeit vertritt die durch die Software dargestellte Errungenschaft. Das verursacht aber oft Probleme. Es ist leicht, vom Erstellen schöner Gegenstände abzukommen - hin zum Erstellen hässlicher Gegenstände, die dafür passender als Thema einer Forschungsarbeit sind.

Unglücklicherweise geben schöne Gegenstände nicht immer die besten Themen für eine Forschungsarbeit ab. Erstens muss Forschung neuartige Themen behandeln - und wie jeder weiß, der eine Dissertation geschrieben hat, ist der beste Weg um sicher zu gehen, dass man jungfräuliches Gebiet erkundet, ein Gebiet abzustecken, dass sonst niemand haben will. Zweitens muss Forschung substanziell sein - und schwerfällige Systeme ergeben gehaltvollere Forschungsarbeiten, weil man dabei über die Hindernisse schreiben kann, die man zu bewältigen hat, damit man überhaupt etwas erledigen kann. Nichts ergibt gehaltvollere Probleme, als dass man mit den falschen Annahmen anfängt. Der Großteil der KI ist ein Beispiel dieser Regel; wenn man annimmt, dass Wissen als eine Liste prädikatenlogischer Ausdrücke dargestellt werden kann, deren Argumente abstrakte Konzepte darstellen, wird man eine Menge Forschungsarbeiten darüber zu schreiben haben, wie das funktionieren kann. Wie Ricky Ricardo zu sagen pflegte: "Lucy, you got a lot of explaining to do." [AdÜ: Diesen mit starkem hispanischen Akzent vorgetragenen Ausspruch warf Sr. Ricardo in der Fünfzigerjahre-Sitcom "I Love Lucy" stets seiner Frau an den Kopf, wenn sie sich durch ihre übermäßigen Ambitionen mal wieder in Schwierigkeiten gebracht hatte. Im deutschsprachigen Raum wird diese Anspielung wohl eher nicht so gut ankommen]

Schöne Gegenstände werden oft hergestellt, indem man an etwas bereits Vorhandenem subtile Änderungen vornimmt, oder indem man vorhandene Ideen in einer leicht neuen Art kombiniert. Solche Tätigkeiten sind in einer Forschungsarbeit schwer auszudrücken.


Warum also beurteilen Universitäten und Forschungseinrichtungen Hacker noch immer nach ihren Veröffentlichungen? Aus demselben Grund, aus dem die akademische Eignung durch schlichte, standardisierte Tests festgestellt wird, oder die Produktivität von Programmierern in Codezeilen. Diese Tests sind einfach durchzuführen - und es ist nichts so verlockend wie ein einfacher Test, der so irgendwie funktioniert.

Was Hacker tatsächlich versuchen - schöne Software zu entwerfen - wäre viel schwieriger zu messen. Um gutes Design beurteilen zu können, benötigt man ein gutes Gespür für Design. Und zwischen der Fähigkeit von Leuten, gutes Design zu erkennen und ihrer Zuversicht, dass sie es können, gibt es (außer vielleicht einer negativen) keine Korrelation.

Die einzige Überprüfungsmöglichkeit für Außenstehende dazu ist Zeit. Mit der Zeit neigen schöne Gegenstände dazu, zu gedeihen und hässliche Gegenstände dazu, fallengelassen zu werden. Unglücklicherweise können die benötigten Zeitdauern länger als Menschenleben sein. Samuel Johnson sagte, dass es hundert Jahre dauere, bis sich der endgültige Ruf eines Schriftstellers gebildet hat. Man müsse warten, bis alle einflussreichen Freunde des Schriftstellers gestorben sind, und dann bis alle ihre Anhänger gestorben sind.

Ich denke, Hacker müssen sich einfach mit einer großen Zufallskomponente in ihrem Ruf abfinden. Dabei unterscheiden sie sich nicht von anderen Schöpfern. Tatsächlich sind sie vergleichsweise gut dran. Beim Hacken ist der Einfluss der Mode nicht annähernd so groß wie in der Malerei.


Es gibt Schlimmeres, als dass die eigene Arbeit von anderen Leuten missverstanden wird. Eine größere Gefahr ist, dass man seine Arbeit selbst missversteht. Nach neuen Ideen sieht man sich in benachbarten Disziplinen um. Wenn man sich in der Informatik-Abteilung befindet, gibt es eine natürliche Verlockung zu glauben, dass Hacken einfach die Anwendung von theoretischer Informatik ist. Meine ganze Studienzeit lang hatte ich das unangenehme Gefühl im Hinterkopf, dass ich mehr Theorie beherrschen sollte, und dass es sehr nachlässig von mir war, dieses ganze Zeug innerhalb von drei Wochen nach der Abschlussprüfung schon wieder vergessen zu haben.

Nun weiß ich, dass ich damit falsch lag. Hacker müssen von Berechenbarkeitstheorie ungefähr soviel verstehen, wie Maler von Malfarbenchemie. Man muss wissen, wie man Laufzeit- und Speichernutzungs-Verhalten berechnet und über Turing-Vollständigkeit bescheid wissen. Vielleicht will man sich auch wenigstens an das Konzept eines Zustandsautomaten erinnern können, falls man mal einen Parser oder eine Bibliothek für Regular Expressions schreiben muss. Tatsächlich müssen Maler vergleichsweise eine ganze Menge mehr über Malfarbenchemie im Kopf haben.

Ich habe entdeckt, dass die besten Quellen von Ideen nicht die anderen Disziplinen sind, in deren Beschreibungen das Wort "Computer" vorkommt, sondern die anderen Disziplinen, die von Schöpfern bevölkert werden. Die Malerei war eine weit ertragreichere Quelle von Ideen als die Berechnungstheorie.

Im College wurde mir beispielsweise beigebracht, dass man ein Programm vollständig am Papier austüfteln soll, bevor man sich dann überhaupt erst einem Computer nähert. Es hatte sich herausgestellt, dass ich so nicht arbeitete. Ich hatte herausgefunden, dass ich beim Programmieren gerne vor einem Computer saß, und nicht vor einem Blatt Papier. Schlimmer noch - anstatt geduldig ein Programm vollständig fertigzuschreiben und mich davon zu vergewissern, dass es korrekt war, neigte ich dazu, einfach hoffnungslos kaputten Code auszuspucken und ihn dann schrittweise zurechtzuklopfen. Mir wurde beigebracht, dass es sich beim Debuggen um einen Schlussdurchlauf handelt, bei dem man Tipp- und Flüchtigkeitsfehler ausbesserte. So wie ich arbeitete, hatte es den Anschein, dass Programmieren geradezu aus Debuggen besteht.

Lange Zeit fühlte ich mich nicht wohl dabei, so wie ich mich einst nicht wohl dabei fühlte, meinen Bleistift nicht so zu halten, wie man es mir in der Grundschule beigebracht hatte. Wenn ich damals nur einen Blick zu den anderen Schöpfern - den Malern, oder den Architekten - geworfen hätte, wäre mir klar geworden, dass es einen Namen für das was ich tat gab: Skizzieren. Soweit ich das beurteilen kann, war die Art, wie mir im College zu Programmieren beigebracht wurde, ganz falsch. Man sollte ein Programm austüfteln, während man es schreibt - genau so wie es Schriftsteller, Maler und Architekten tun.

Diese Feststellung hat konkrete Auswirkungen auf das Software Design. Es bedeutet, dass eine Programmiersprache zuvorderst formbar sein sollte. Eine Programmiersprache ist dazu da, um über Programme nachzudenken und nicht um Programme auszudrücken, über die man bereits nachgedacht hat. Sie sollte ein Bleistift sein, und kein Kugelschreiber. Wenn die Leute tatsächlich so programmieren würden, wie man mir im College beigebracht hat, wäre statische Typisierung eine nette Idee. Aber kein Hacker, den ich kenne, schreibt Programme auf diese Weise. Wir brauchen eine Sprache, die uns Kritzeln, Verwischen und Verschmieren lässt - und keine Sprache, bei der man wie bei einer Tea-Party sitzend eine Tasse Typen auf den Knien halten muss, während man sich höflich mit einer strengen, alten Compiler-Tante unterhält.


Da wir uns gerade mit statischer Typisierung beschäftigen: dass wir uns mit anderen Schöpfern identifizieren, schützt uns vor noch einem anderen Problem, dass die Wissenschaften belastet: Mathe-Neid. Alle wissenschaftlich Tätigen glauben heimlich, dass Mathematiker klüger sind als sie. Ich denke, dass die Mathematiker das auch glauben. Jedenfalls resultiert das darin, dass Wissenschaftler danach streben, ihre Arbeit so mathematisch wie möglich aussehen zu lassen. In einer Disziplin wie der Physik richtet das vermutlich nicht viel Schaden an; je weiter man sich jedoch von den Naturwissenschaften entfernt, desto mehr wird das zu einem Problem.

Eine Seite voller Formeln sieht einfach so eindrucksvoll aus. (Tipp: griechische Variablen für noch mehr Eindruck verwenden) Deshalb ist die Versuchung groß, an formal behandelbaren Themen zu arbeiten, anstatt an Problemen die, sagen wir mal, wichtig sind.

Hacker würden sich nicht versucht fühlen so zu handeln, wenn sie sich mit anderen Schöpfern, wie Schriftstellern oder Malern, identifizieren würden. Schriftsteller und Maler leiden nicht an Mathe-Neid. Es kommt ihnen vor, als würden sie etwas vollkommen anderes tun. So wie es (so glaube ich) auch Hacker tun.


Wenn Hacker von Universitäten und Forschungseinrichtungen daran gehindert werden, der von ihnen gewünschten Art von Arbeit nachzugehen, ist der Platz für sie möglicherweise in Firmen. Unglücklicherweise lassen die meisten Firmen Hacker ebenfalls nicht das tun, was sie wollen. Universitäten und Forschungseinrichtungen zwingen Hacker, Wissenschaftler zu sein - Firmen zwingen sie, Ingenieure zu sein.

Ich habe das selbst erst vor kurzem herausgefunden. Als Yahoo Viaweb [AdÜ: Viaweb war ein E-Commerce-Startup, das uA vom Autor mitgegründet wurde] kaufte, wurde ich gefragt, was ich tun wollte. Ich konnte die geschäftliche Seite noch nie besonders leiden und sagte, dass ich einfach hacken wollte. Als ich bei Yahoo anfing, kam ich drauf, dass Hacken für sie bedeutete, Software zu implementieren und nicht zu designen. Programmierer wurden als Techniker angesehen, die die Visionen (falls das das richtige Wort dafür ist) von Produktmanagern in Code übersetzten.

In großen Firmen scheint das die standardmäßige Vorgehensweise zu sein. Sie machen es so, weil es die Standardabweichung des Ergebnisses verringert. Tatsächlich kann nur ein geringer Anteil der Hacker Software entwerfen, und es ist für Leute, die Firmen betreiben, schwer, diese herauszufinden. Also vertrauen die meisten Firmen die Zukunft der Software nicht einem großartigen Hacker an, sondern richten es so ein, dass sie von einem Komitee entworfen wird und die Hacker das Design ausschließlich implementieren.

Wenn man irgendwann mal Geld machen will, sollte man sich das merken - es ist nämlich einer der Gründe, warum Startups gewinnen. Große Firmen wollen die Standardabweichung der Ergebnisse des Designs verringern, weil sie Katastrophen vermeiden wollen. Wenn man Schwingungen dämpft, verliert man aber die hohen Punkte genauso wie die niedrigen. Für große Firmen ist das kein Problem, weil sie nicht gewinnen, indem sie tolle Produkte herstellen. Große Firmen gewinnen, indem sie einfach etwas weniger beschissen sind, als andere große Firmen.

Wenn man also einen Weg findet, eine genügend große Firma, die ihre Software von Produktmanagern entwerfen lässt, in einen Design-Krieg zu verwickeln, können sie niemals mit einem mithalten. Diese Gelegenheiten sind allerdings nicht einfach zu finden. Große Firmen in einen Design-Krieg zu verwickeln ist schwer - genau so wie es schwer ist, einen Gegner der sich in einer Burg verschanzt zum Nahkampf zu bewegen. Es wäre wohl ziemlich einfach, beispielsweise eine bessere Textverarbeitung als Microsoft Word zu schreiben; Microsoft würde es aber vermutlich in der Burg ihres Betriebssystemmonopols nicht einmal bemerken, wenn man das tun würde.

Design-Kriege werden in neuen Märkten ausgefochten, wo es noch niemand geschafft hat, irgendwelche Befestigungen zu errichten. Hier kann man im großen Stil gewinnen, indem man den kühnen Design-Ansatz nimmt und dieselben Leute das Produkt entwerfen und implementieren lässt. Microsoft hat das zu Beginn selbst gemacht. So wie Apple. Und Hewlett-Packard. So wie fast jedes erfolgreiche Startup, vermute ich.


Eine Möglichkeit, großartige Software zu erstellen, ist also, ein eigenes Startup zu gründen. Dabei gibt es allerdings zwei Probleme. Eines davon ist, dass man in einem Startup so viel Anderes als Software-Schreiben zu tun hat. Bei Viaweb habe ich mich glücklich geschätzt, wenn ich ein Viertel der Zeit hacken konnte. Die Dinge, die ich in den anderen drei Vierteln der Zeit zu erledigen hatte, bewegten sich zwischen ermüdenden und wirklich schrecklichen. Ich habe einen handfesten Bezug dazu, da ich einmal eine Vorstandssitzung verlassen musste, um ein paar Füllungen machen zu lassen. Ich erinnere mich, dass ich mich im Zahnarztstuhl zurücklehnte, auf den Bohrer wartete und mich dabei fühlte, als wäre ich auf Urlaub.

Das andere Problem mit Startups ist, dass es bei der Art von Software, die Geld einbringt, und der Art, die interessant zu schreiben ist, nicht viel Übereinstimmungen gibt. Programmiersprachen sind interessant zu schreiben - tatsächlich war Microsofts erstes Produkt eine -, aber niemand wird heutzutage für Programmiersprachen etwas bezahlen. Wenn man Geld machen will, wird man gezwungen sein, an Problemen zu arbeiten, die zu eklig sind, als dass sie jemand umsonst lösen würde.

Alle Schöpfer sehen sich diesem Problem ausgesetzt. Preise werden durch Angebot und Nachfrage festgelegt, und es gibt einfach nicht so viel Nachfrage für Sachen, an denen es Spaß macht zu arbeiten, als es für Sachen gibt, die die prosaischen Probleme der einzelnen Kunden lösen. In Off-Broadway-Stücken aufzutreten bringt einfach nicht so viel Geld ein, wie bei irgendeiner Verkaufsveranstaltung ein Gorillakostüm zu tragen. Romane schreiben bringt einfach nicht so viel Geld ein, wie Werbetexte für Müllabfuhren zu schreiben. Und an Programmiersprachen zu Hacken bringt einfach nicht so viel Geld ein, wie herauszufinden, wie man die Legacy-Datenbank irgendeiner Firma mit ihrem Webserver verbinden kann.


Ich glaube, dass die Antwort auf dieses Problem - im Falle von Software - ein beinahe allen Schöpfern bekanntes Konzept ist: der Day-Job. Dieser Ausdruck wurde von Musikern, die ja nachts auftreten, geprägt. Allgemeiner heißt das, dass man eine Art von Arbeit hat, die man für Geld erledigt, und eine andere nur zum Spaß an der Freude.

Beinahe alle Schöpfer haben am Anfang ihrer Karriere Day-Jobs. Bei Malern und Schriftstellern ist das offensichtlich. Wenn man Glück hat, kann man einen Day-Job bekommen, der sehr nah an der richtigen Arbeit ist. Musiker scheinen oft in Plattenläden zu arbeiten. Ein Hacker, der an einer Programmiersprache oder einem Betriebssystem arbeitet, könnte ebenso an einen Day-Job gelangen, bei denen er diese verwendet. [1]

Ich schlage es keinesfalls als neue Idee vor, wenn ich behaupte, dass es für Hacker die Antwort ist, einen Day-Job zu haben, und nebenher an schöner Software zu arbeiten. Darum geht es nämlich bei Open Source Hacken ausschließlich. Was ich behaupte, ist, dass es sich bei Open Source vermutlich um das richtige Modell handelt, da es von all den anderen Schöpfern unabhängig bestätigt wurde.

Es überrascht mich, dass Arbeitgeber ihre Hacker nur widerwillig an Open Source Projekten arbeiten lassen. Bei Viaweb würden wir jemanden, der das nicht macht, nur widerwillig einstellen. Bei Bewerbungsgesprächen mit Programmierern war das, worauf wir uns am meisten konzentriert haben, was für Software sie in ihrer Freizeit schreiben. Wenn man etwas nicht liebt, kann man einfach nicht richtig gut darin sein - und wenn man es liebt zu Hacken, dann wird man unausweichlich an eigenen Projekten arbeiten. [2]


Da Hacker eher Schöpfer als Wissenschaftler sind, ist der richtige Platz um nach Metaphern zu suchen nicht in den anderen Wissenschaften, sondern unter anderen Arten von Schöpfern. Was kann uns die Malerei sonst noch über Hacken beibringen?

Etwas, das wir vom Beispiel Malerei lernen - oder zumindest bestätigen - können, ist, wie man das Hacken erlernt. Malen lernt man hauptsächlich, indem man es tut. Detto fürs Hacken. Die meisten Hacker lernen nicht zu hacken, indem sie Universitätskurse in Programmieren belegen. Sie lernen zu hacken, indem sie als Dreizehnjährige eigene Programme schreiben. Sogar in Universitätskursen lernt man hauptsächlich zu hacken indem man einfach hackt. [3]

Maler kann man gut beim Learning by Doing beobachten, da sie eine Spur von Werken hinter sich lassen. Wenn man sich das Werk eines Malers in chronologischer Reihenfolge ansieht, entdeckt man, dass jedes Gemälde auf Dingen aufbaut, die in den vorhergehenden erlernt wurden. Wenn sich in einem Gemälde etwas befindet, das sehr gut passt, kann man Version 1 davon gewöhnlicherweise in kleinerer Form in einem früheren Gemälde finden.

So arbeiten, denke ich, die meisten Schöpfer. Schriftsteller und Architekten scheinen es ebenfalls zu tun. Vielleicht wäre es gut für Hacker, mehr wie Maler zu handeln und regelmäßig von vorne anzufangen, anstatt jahrelang an einem Projekt weiterzuarbeiten und zu versuchen, alle ihren späteren Ideen als Verbesserungen einzubauen.

Die Tatsache, dass Hacker Hacken lernen, indem sie es tun, ist ein weiteres Anzeichen dafür, wie verschieden Hacken von den Wissenschaften ist. Wissenschaftler erlernen Wissenschaft nicht indem sie sie ausüben, sondern indem sie in Laboratorien Übungsaufgaben bewältigen. Wissenschaftler beginnen damit, perfekte Arbeit zu erledigen - im Sinne, dass sie einfach versuchen, Arbeit zu reproduzieren, die jemand anderes bereits für sie erledigt hat. Schließlich kommen sie dann am Punkt an, and dem sie neuartige, originelle Arbeit leisten können. Hacker hingegen leisten von Anfang an originelle Arbeit - nur ist sie sehr mies. Hacker beginnen also originell und werden dann gut und Wissenschaftler beginnen gut und werden dann originell.


Die andere Art für Schöpfer zu lernen ist durch Beispiele. Für einen Maler ist ein Museum eine Referenzbibliothek von Techniken. Jahrhundertelang war es Teil einer traditionellen Malerausbildung, die Werke der großen Meister zu kopieren, da man dabei gezwungen wird, sich genau anzusehen, wie ein Gemälde erstellt wurde.

Auch Schriftsteller machen das. Benjamin Franklin lernte zu schreiben, indem er die Argumente in den Aufsätzen von Addison und Steele zusammenfasste und dann versuchte, sie zu reproduzieren. Dasselbe tat Raymond Chandler mit Detektivgeschichten.

Hacker können ebenfalls Programmieren lernen, indem sie sich gute Programme ansehen - nicht nur, was sie machen, sondern auch deren Quellcode. Dass die Open Source-Bewegung es einfacher gemacht hat, Programmieren zu lernen, ist einer ihrer weniger propagierten Nutzen. Als ich lernte, zu programmieren, waren wir hauptsächlich auf Beispiele in Büchern angewiesen. Der einzige große Brocken Code damals war Unix, aber nicht mal das war Open Source. Die meisten Leute, die den Quellcode lasen, lasen ihn in Schwarzkopien von John Lions Buch, das vor 1996 nicht veröffentlicht werden durfte, obwohl es 1977 geschrieben wurde.


Ein weiteres Beispiel, das wir von der Malerei beziehen können, ist die Art, dass Gemälde durch schrittweise Verfeinerung hergestellt werden. Gemälde fangen gewöhnlicherweise mit einer Skizze an. Die Details werden schrittweise eingefügt. Es ist aber nicht lediglich ein Prozess des Einfügens. Manchmal stellen sich die ursprünglichen Pläne als fehlerhaft heraus. Unzählige Gemälde - so stellt sich heraus, wenn man sie unter Röntgenstrahlen betrachtet - weisen entfernte Gliedmaßen auf, oder später angepasste Gesichtszüge.

Hier haben wir einen Fall, wo wir von der Malere lernen können. Ich glaube, dass Hacken auch so funktionieren sollte. Anzunehmen, dass die Spezifikationen für ein Programm perfekt sind, ist unrealistisch. Man ist besser dran, wenn man sich das im Voraus eingesteht und Programme so schreibt, dass den Spezifikationen gestattet, sich on the fly zu ändern.

(Die Struktur großer Firmen macht ihnen das schwer, deshalb haben wir hier eine weitere Begebenheit, wo Startups einen Vorteil haben.)

Mittlerweile weiß vermutlich jeder um die Gefahr der vorzeitigen Optimierung. Ich glaube, wir sollten uns genauso um vorzeitiges Design - wenn man zu früh entscheidet, was ein Programm machen soll - Sorgen machen.

Die richtigen Tools können uns helfen, diese Gefahr zu vermeiden. Eine gute Programmiersprache sollte es einem wie Ölfarbe einfach machen, seine Meinung zu ändern. Dynamische Typisierung ist hier ein Vorteil, da man sich nicht im vornherein auf bestimmte Datenrepräsentationen festlegen muss. Der Schlüssel zur Flexibilität ist allerdings meiner Meinung nach, die Sprache sehr abstrakt zu machen. Das am einfachsten zu verändernde Programm ist ein sehr kurzes.


Es hört sich wie ein Paradoxon an, aber ein großartiges Gemälde muss besser sein, als es sein muss. Ein Beispiel: Als Leonardo das Portrait von Ginevra de Benci in der Nationalgallerie [AdÜ: gemeint ist die National Gallery of Art, Washington DC] malte, platzierte er hinter ihrem Kopf einen Wacholderstrauch. Darin malte er sorgfältig jedes einzelne Blatt. Viele Maler mögen sich gedacht haben: Der ist doch nur etwas, was man im Hintergrund platziert, um ihren Kopf zu umrahmen. Niemand wird sich den so genau ansehen.

Aber nicht Leonardo. Wie hart er an einem Teil eines Gemäldes arbeitete, hing überhaupt nicht davon ab, wie genau er von anderen annahm, dass sie ihn ansehen würden. Er war wie Michael Jordan. Unnachgiebig.

Unnachgiebigkeit gewinnt, weil nicht wahrgenommene Details zusammengenommen sichtbar werden. Wenn Leute beim Gemälde von Ginevra de Benci vorbeikommen, wird ihre Aufmerksamkeit oft direkt davon gefangen genommen, noch bevor sie auf das zugehörige Schild sehen, und bemerken, dass Leonardo da Vinci drauf steht. Alle diese nicht wahrgenommenen Details verbinden sich, um etwas zu erzeugen, das einfach überwältigend ist - wie tausende kaum hörbare Stimmen, die alle einstimmig singen.

Gleichermaßen benötigt großartige Software eine fanatische Hingabe zur Schönheit. Wenn man in großartige Software hinein sieht, merkt man, dass Teile, die von niemandem gesehen werden sollen, ebenfalls schön sind. Ich behaupte nicht, dass ich großartige Software schreibe, aber ich weiß, dass ich mich - wenn es sich um Code handelt - dermaßen benehme, dass es mich anfällig für verschreibungspflichtige Medikamente machte, würde ich mich im alltäglichen Leben so verhalten. Es macht mich wahnsinnig, Code zu sehen, der schlecht eingerückt ist, oder hässliche Variablennamen verwendet.


Wenn ein Hacker bloß ein Implementierer wäre, der eine Spezifikation in Code verwandelt, dann könnte er sich auch von einem Ende zum anderen durcharbeiten, wie jemand, der einen Graben aushebt. Wenn der Hacker aber ein Schöpfer ist, dann müssen wir Inspiration mit einbeziehen.

Beim Hacken kommt, wie beim Malen, die Arbeit in Zyklen. Manchmal wird man ganz aufgeregt über ein neues Projekt und will sechzehn Stunden am Tag daran arbeiten. Ein anderes Mal scheint gar nichts interessant zu sein.

Um gute Arbeit zu leisten, muss man diese Zyklen mit einbeziehen, weil sie davon beeinflusst werden, wie man auf sie reagiert. Wenn man auf einem Berg mit einem Auto mit manueller Schaltung fährt, muss man manchmal die Finger von der Kupplung lassen, um den Motor nicht abzuwürgen. Ein solches "die Finger davon lassen" kann ebenso dazu dienen, Ehrgeiz abzuwürgen. Beim Malen und Hacken gleichermaßen gibt es einige Tätigkeiten, die erschreckend ehrgeizig sind, und andere, beruhigend gewöhnliche. Es ist eine gute Idee, einige einfache Tätigkeiten für Momente aufzusparen, an denen man sich sonst abwürgen könnte.

Beim Hacken kann das buchstäblich bedeuten, Bugs aufzusparen. Ich mag Debugging: Es handelt sich dabei um die einzige Zeit, bei der Hacken so geradlinig ist, wie es sich die Leute vorstellen. Man hat ein vollkommen eingeschränktes Problem, und alles was man zu tun hat, ist, es zu lösen. Das Programm soll x machen. Stattdessen macht es y. Wo geht dabei was schief? Man weiß, dass man letztendlich gewinnen wird. Es ist so entspannend, wie eine Mauer anzumalen.


Das Beispiel Malerei kann uns nicht nur beibringen, wie wir unsere eigene Arbeit einteilen, sondern auch wie man zusammenarbeitet. Viele der großen Kunstwerke der Vergangenheit stellen die Arbeit vieler Hände dar, obwohl neben ihnen an der Museumswand nur ein Name steht. Leonardo war ein Lehrling in Verrocchios Werkstatt und malte einen der Engel in dessen "Taufe Christi". So was war die Regel, nicht die Ausnahme. Michelangelo wurde dafür, dass er darauf bestand, alle Figuren an der Decke der Sixtinischen Kapelle selber zu malen, als besonders engagiert angesehen.

Wenn Maler gemeinsam an einem Gemälde arbeiteten, arbeiteten sie - so weit ich weiß - nie an denselben Teilen. Für gewöhnlich arbeitete der Meister an den Hauptfiguren und die Assistenten arbeiteten an den anderen und dem Hintergrund. Niemals aber übermalte jemand die Arbeit eines anderen. [AdÜ: dem Übersetzer - obwohl kunsthistorisch nicht über die Maßen bewandert - liegen hier andere Informationen vor. So pflegte beispielsweise Rubens bei großformatigen Auftragsarbeiten kleine Ölskizzen anzufertigen, die er dann die Mitarbeiter seiner Werkstatt auf die große Leinwand übertragen ließ; dem so entstandenen Gemälde verpasste er als großer Meister dann häufig den letzten Schliff, indem er weniger gelungene Stellen höchstpersönlich überarbeitete. Ohne die richtigen "Tools" (in diesem Fall die flexible Ölfarbe) wäre diese Vorgehensweise natürlich nicht denkbar gewesen.]

Ich glaube, das ist auch bei Software das richtige Modell für Zusammenarbeit. Das sollte man allerdings nicht zu weit treiben. Wenn ein Stück Code von drei oder vier verschiedenen Leuten bearbeitet wird, von denen es niemand wirklich gehört, wird es letztendlich werden wie ein Gemeinschaftsraum. Es wird eher trostlos und verlassen anmuten und überflüssiger Müll [AdÜ: im Original "cruft", ein schönes Jargon-Wort, das ebenfalls unnötigen Programmcode meint] wird sich darin ansammeln. Der richtige Weg zusammenzuarbeiten ist, so glaube ich, Projekte in scharf definierte Module mit genau bestimmten Eigentümern zu unterteilen, mit Schnittstellen zwischen ihnen, die sorgfältig entworfen wurden, und - wenn möglich - so deutlich und ausdrucksstark wie Programmiersprachen sind.


Wie in der Malerei ist die meiste Software für ein menschliches Publikum bestimmt. Und deshalb müssen Hacker - wie Maler - Einfühlungsvermögen aufweisen, um wirklich großartige Arbeit vollbringen zu können. Man muss die Dinge aus der Sichtweise des Benutzers sehen können.

Als ich ein Kind war, wurde mir immer gesagt, dass ich die Dinge aus der Sichtweise von jemand anderem sehen sollte. Was das in der Praxis immer bedeutete, war, dass ich anstelle von etwas das ich tun wollte, etwas tun sollte, das jemand anderer wollte. Das hat das Einfühlungsvermögen bei mir natürlich in Verruf gebracht, und ich erklärte es mir zum Prinzip, es sich bei mir nicht ausbilden zu lassen.

Da bin ich aber ganz schön falsch gelegen. Es stellt sich heraus, dass das Annehmen der Sichtweise anderer auf die Dinge praktisch das Geheimnis des Erfolges ist. Das bedeutet nicht notwendigerweise, selbstaufopfernd zu sein. Weit davon entfernt. Dass man versteht, wie jemand anders die Dinge sieht, bedeutet nicht, dass man in seinem Interesse handeln wird; in einigen Situationen - beispielsweise im Krieg - will man genau das Gegenteil machen. [4]

Die meisten Schöpfer stellen Gegenstände für ein menschliches Publikum her. Und um ein Publikum für sich gewinnen, muss man verstehen, was es benötigt. Zum Beispiel bilden beinahe alle der großartigsten Gemälde Menschen ab, weil Menschen das sind, wofür sich Menschen nun mal interessieren.

Einfühlungsvermögen ist vermutlich der wichtigste Unterschied zwischen einem guten Hacker und einem großartigen. Einige Hacker sind ziemlich klug, aber wenn es um Einfühlungsvermögen geht, sind sie praktisch Solipsisten. Für solche Leute ist es schwer, großartige Software zu entwerfen [5], weil sie die Dinge nicht aus der Sichtweise des Benutzers sehen können.

Eine Möglichkeit um herauszufinden, wie gut es um das Einfühlungsvermögen von Leuten bestellt ist, ist, sie dabei zu beobachten, wie sie jemandem ohne technischen Background eine technische Frage erklären. Wir kennen vermutlich alle Leute, die - obwohl sonst klug - einfach amüsant schlecht darin sind. Wenn sie jemand auf einer Dinner-Party fragt, was eine Programmiersprache ist, würden sie etwas sagen wie: "Oh, eine high-level Sprache ist das, was der Compiler als Input verwendet, um Objektcode zu erzeugen." High-level Sprache? Compiler? Ojektcode? Jemand, der nicht weiß, was eine Programmiersprache ist, weiß offensichtlich auch nicht was diese Dinge sind.

Zu dem was Software tun muss, gehört auch, sich selbst zu erklären. Um gute Software zu schreiben, muss man also verstehen, wie wenig Benutzer verstehen. Sie werden der Software ohne Vorbereitung gegenüber treten, und sie sollte besser das tun, von dem die Benutzer annehmen, was es tut, weil sie die Gebrauchsanweisung nicht lesen werden. Das in dieser Hinsicht beste System, das ich jemals gesehen habe, war der ursprüngliche Macintosh, um 1985. Er hat getan, was Software fast nie tut: er hat einfach funktioniert. [6]

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

So müssen Programme geschrieben werden, damit Menschen sie lesen, und nur nebenbei, damit Maschinen sie ausführen.

[AdÜ: Ein weiteres Zitat aus dem Einführungsabschnitt dieses sehr schönen Buches stellt passender Weise sehr gut den Grundgedanken dieses Essays dar: "Der Art und Weise, wie wir das Thema angehen, liegt die Überzeugung zugrunde, dass "Computerwissenschaft" keine Wissenschaft ist, und dass ihre besondere Bedeutung wenig mit Computern zu tun hat. Die Computerrevolution ist eine Revolution unserer Art zu denken und auszudrücken, was wir denken."]

Man muss nicht nur Einfühlungsvermögen für seine User aufweisen können, sondern auch für seine Leser. Das liegt im eigenen Interesse, weil man selbst einer von ihnen sein wird. So mancher Hacker hat schon ein Programm geschrieben, nur um beim Wiederansehen sechs Monate später herauszufinden, dass er keine Ahnung hat, wie es funktioniert. Ich kenne mehrere Leute, die nach solchen Erfahrungen Perl abgeschworen haben. [7]

Ein Mangel an Einfühlungsvermögen wird mit Intelligenz in Zusammenhang gebracht, und das bis zu einem Grad, dass sich diese Ansicht in einigen Gebieten sogar als besonders schick und passend etabliert hat. Aber ich glaube nicht, dass es da einen Zusammenhang gibt. Man kann gut in Mathematik und Naturwissenschaften sein, ohne sich Einfühlungsvermögen anzueignen, und Leute in diesen Disziplinen scheinen klug zu sein, also ist es dazu gekommen, dass diese beiden Eigenschaften miteinander in Verbindung gebracht werden. Allerdings gibt es genug dumme Leute, die gleichfalls kein Einfühlungsvermögen haben. Man muss sich doch nur mal die Leute anhören, die in Talkshows anrufen, um Fragen zu stellen. Egal was sie auch fragen, sie fragen es in derart undurchsichtiger Weise, dass die Talkmaster die Phrase für sie oft umformulieren müssen.


Wenn also Hacken so funktioniert wie Malerei und Schriftstellerei - ist es auch genauso cool? Schließlich hat man nur ein Leben. Und das möchte man wohl auch damit verbringen, an etwas großartigem zu arbeiten.

Diese Frage ist unglücklicherweise schwer zu beantworten. Beim Prestige gibt es immer eine große zeitliche Verzögerung. Es ist wie Licht von einem weit entfernten Stern. Die Malerei hat jetzt Prestige, weil Leute vor fünfhundert Jahren großartige Arbeit vollbracht haben. Zu dieser Zeit dachte niemand, dass diese Gemälde so wichtig sind, wie wir sie heute empfinden. Es wäre den Leuten der damaligen Zeit sehr sonderbar vorgekommen, dass Federico da Montefeltro - der Herzog von Urbino - eines Tages hauptsächlich als der Kerl mit der seltsamen Nase in einem Gemälde von Piero della Francesca bekannt sein sollte.

Obwohl ich also zugebe, dass Hacken jetzt nicht so cool wie Malen zu sein scheint, sollten wir uns daran erinnern, dass die Malerei selber in ihren ruhmreichen Tagen nicht so cool zu sein schien wie jetzt.

Was wir mit einiger Zuversicht sagen können, ist, dass dies die ruhmreichen Tage des Hackens sind. In den meisten Disziplinen geschieht die meiste großartige Arbeit gleich zu Beginn. Die zwischen 1430 und 1500 gefertigten Gemälde sind noch immer unübertroffen. Shakespeare tauchte auf, als das professionelle Theater gerade geboren wurde und trieb das Medium so weit, dass seither jeder Dramatiker in seinem Schatten leben musste. Albrecht Dürer tat dasselbe mit dem Kupferstich, und Jane Austen mit dem Roman.

Immer wieder sehen wir das gleiche Muster. Ein neues Medium taucht auf, und die Leute sind so aufgeregt darüber, dass sie in den ersten paar Generationen die meisten seiner Möglichkeiten ausforschen. Hacken scheint jetzt in dieser Phase zu sein.

Malen war zu Leonardos Zeiten nicht so cool, wie es durch den Beitrag seines Werks erst geworden ist. Als wie cool sich Hacken herausstellen wird, wird davon abhängen, was wir mit diesem neuen Medium machen können. In gewisser Weise ist die zeitliche Verzögerung von Coolness ein Vorteil. Wenn man jetzt jemanden trifft, der einen Compiler schreibt, oder an einem Unix-Kernel hackt, weiß man wenigstens, dass er es nicht nur macht, um Mädels aufzureißen.



Anmerkungen

[1] Der größte Schaden, den die Fotografie der Malerei zugefügt hat, könnte die Tatsache sein, dass sie den besten Day-Job ausgelöscht hat. Die meisten der großen Maler in der Geschichte erhielten sich, indem sie Portraits malten.

[2] Mir wurde gesagt, dass Microsoft seinen Mitarbeitern davon abrät, an Open Source Projekten zu arbeiten - auch in deren Freizeit. Allerdings arbeiten jetzt so viele der besten Hacker an Open Source Projekten, dass die Hauptauswirkung dieser Strategie sein könnte, dass sie sicher gehen können, keine erstklassigen Programmierer einzustellen.

[3] Was man auf der Universität über Programmieren lernt, ähnelt stark dem, was man über Bücher, oder Kleidung, oder Ausgehen lernt: was für einen schlechten Geschmack man in der Mittelschule hatte.

[4] Hier ist ein Beispiel in angewandtem Einfühlungsvermögen. Wenn wir uns bei Viaweb nicht zwischen zwei Alternativen entscheiden konnten, fragten wir uns, was unsere Konkurrenz denn am meisten hassen würde. Einmal fügte ein Konkurrent ein prinzipiell nutzloses Feature zu dessen Software hinzu; aber weil es eines der wenigen war, die sie hatten und wir nicht, machten sie in der Fachpresse darum viel Aufsehen. Wir hätten zu erklären versuchen können, dass das Feature nutzlos war, entschieden uns aber, dass es unseren Konkurrenten mehr ärgern würde, wenn wir es einfach selber implementierten, also hackten wir an diesem Nachmittag unsere eigene Version.

[5] Außer Texteditoren und Compiler. Hacker benötigen kein Einfühlungsvermögen, um diese zu entwerfen, weil sie selbst typische Benutzer sind.

[6] Nun - beinahe. Die Macs überschritten den verfügbaren Arbeitsspeicher etwas, was viel unbequemes Disk-Swapping verursachte, aber das konnte innerhalb weniger Monate durch den Kauf eines zusätzlichen Laufwerks behoben werden.

[7] Man macht Programme nicht lesbarer, indem man sie mit Kommentaren vollstopft. Ich würde einen Schritt über das Zitat von Abelson und Sussman [AdÜ: die Autoren des oben erwähnten "Struktur und Interpretation von Computerprogrammen] hinaus gehen. So müssen Programmiersprachen entworfen werden, um Algorithmen auszudrücken, und nur nebenher um Maschinen zu sagen, wie sie sie ausführen sollen. Eine gute Programmiersprache sollte zum Erklären von Software besser geeignet sein als Englisch [oder irgendeine andere natürliche Sprache]. Man sollte Kommentare nur dann benötigen, wenn es eine Art Trickserei [AdÜ: Im Original "kludge"] gibt, vor der man den Leser warnen muss, wie auch auf einer Straße nur an den Stellen mit unerwartet starken Kurven Pfeile als Warnhinweis angebracht sind.