Hackers en Schilders

Mei 2003

(Dit essay is gebaseerd op een gastcollege aan Harvard, dat een eerdere lezing aan Northeastern bevatte.)

Toen ik afstudeerde in computerwetenschappen ging ik naar de kunstacademie om schilderen te studeren. Veel mensen leken verrast dat iemand die geïnteresseerd was in computers, ook geïnteresseerd zou zijn in schilderen. Ze leken te denken dat hacken en schilderen heel verschillende soorten werk waren-- dat hacken koud, precies en methodisch was, en dat schilderen de koortsachtige uiting was van een oerdrang.

Beide beelden zijn onjuist. Hacken en schilderen hebben veel gemeen. Sterker nog, van alle verschillende soorten mensen die ik heb gekend, zijn hackers en schilders de meest gelijkende.

Wat hackers en schilders gemeen hebben, is dat ze allebei makers zijn. Samen met componisten, architecten en schrijvers, proberen hackers en schilders goede dingen te maken. Ze doen niet aan onderzoek per se, hoewel het des te beter is als ze in de loop van het proberen goede dingen te maken een nieuwe techniek ontdekken.

Ik heb de term "computerwetenschappen" nooit leuk gevonden. De belangrijkste reden dat ik het niet leuk vind, is dat het niet bestaat. Computerwetenschappen is een verzameling zwak gerelateerde gebieden die door een historisch toeval bij elkaar zijn gegooid, zoals Joegoslavië. Aan de ene kant heb je mensen die echt wiskundigen zijn, maar wat ze doen computerwetenschappen noemen zodat ze DARPA-subsidies kunnen krijgen. In het midden heb je mensen die werken aan iets als de natuurlijke historie van computers-- bijvoorbeeld het bestuderen van het gedrag van algoritmen voor het routeren van gegevens door netwerken. En dan aan de andere kant heb je de hackers, die interessante software proberen te schrijven, en voor wie computers slechts een medium van expressie zijn, net zoals beton voor architecten of verf voor schilders. Het is alsof wiskundigen, natuurkundigen en architecten allemaal in dezelfde afdeling moesten zitten.

Soms wordt wat de hackers doen "software engineering" genoemd, maar deze term is net zo misleidend. Goede softwareontwerpers zijn niet meer ingenieurs dan architecten dat zijn. De grens tussen architectuur en engineering is niet scherp gedefinieerd, maar hij is er wel. Hij valt tussen wat en hoe: architecten beslissen wat te doen, en ingenieurs bedenken hoe het te doen.

Wat en hoe mogen niet te gescheiden worden gehouden. Je vraagt om problemen als je probeert te beslissen wat te doen zonder te begrijpen hoe het te doen. Maar hacken kan zeker meer zijn dan alleen beslissen hoe een specificatie te implementeren. Op zijn best is het het creëren van de specificatie-- hoewel blijkt dat de beste manier om dat te doen, het implementeren ervan is.

Misschien wordt "computerwetenschappen" op een dag, net als Joegoslavië, opgesplitst in zijn onderdelen. Dat zou een goede zaak kunnen zijn. Vooral als het onafhankelijkheid betekende voor mijn geboorteland, hacken.

Het bundelen van al deze verschillende soorten werk in één afdeling is misschien administratief handig, maar intellectueel verwarrend. Dat is de andere reden waarom ik de naam "computerwetenschappen" niet leuk vind. Je zou kunnen zeggen dat de mensen in het midden iets doen dat lijkt op experimentele wetenschap. Maar de mensen aan beide uiteinden, de hackers en de wiskundigen, doen eigenlijk geen wetenschap.

De wiskundigen lijken hier niet door gehinderd te worden. Ze gaan vrolijk aan de slag met het bewijzen van stellingen zoals de andere wiskundigen op de wiskundeafdeling, en waarschijnlijk houden ze er binnenkort mee op te merken dat het gebouw waarin ze werken aan de buitenkant "computerwetenschappen" vermeldt. Maar voor de hackers is dit label een probleem. Als wat ze doen wetenschap wordt genoemd, hebben ze het gevoel dat ze zich wetenschappelijk moeten gedragen. Dus in plaats van te doen wat ze echt willen doen, namelijk het ontwerpen van mooie software, hebben hackers op universiteiten en onderzoekslaboratoria het gevoel dat ze onderzoeksartikelen moeten schrijven.

In het beste geval zijn de artikelen slechts een formaliteit. Hackers schrijven coole software en schrijven er vervolgens een artikel over, en het artikel wordt een plaatsvervanger voor de prestatie die de software vertegenwoordigt. Maar vaak veroorzaakt deze mismatch problemen. Het is gemakkelijk om af te dwalen van het bouwen van mooie dingen naar het bouwen van lelijke dingen die geschiktere onderwerpen zijn voor onderzoeksartikelen.

Helaas zijn mooie dingen niet altijd de beste onderwerpen voor artikelen. Ten eerste moet onderzoek origineel zijn-- en zoals iedereen die een proefschrift heeft geschreven weet, is de manier om er zeker van te zijn dat je onontgonnen terrein verkent, het claimen van een stuk grond dat niemand wil. Ten tweede moet onderzoek substantieel zijn-- en onhandige systemen leveren vlezigere artikelen op, omdat je kunt schrijven over de obstakels die je moet overwinnen om dingen gedaan te krijgen. Niets levert vlezigere problemen op dan beginnen met de verkeerde aannames. Het grootste deel van AI is een voorbeeld van deze regel; als je aanneemt dat kennis kan worden weergegeven als een lijst van predicaatlogische expressies waarvan de argumenten abstracte concepten vertegenwoordigen, zul je veel artikelen moeten schrijven over hoe je dit werkend krijgt. Zoals Ricky Ricardo vroeger zei: "Lucy, you got a lot of explaining to do."

De manier om iets moois te creëren is vaak door subtiele aanpassingen te maken aan iets dat al bestaat, of door bestaande ideeën op een iets nieuwe manier te combineren. Dit soort werk is moeilijk over te brengen in een onderzoeksartikel.

Dus waarom blijven universiteiten en onderzoekslaboratoria hackers beoordelen op publicaties? Om dezelfde reden dat "academische geschiktheid" wordt gemeten met simpele gestandaardiseerde tests, of de productiviteit van programmeurs wordt gemeten in regels code. Deze tests zijn gemakkelijk toe te passen, en er is niets zo verleidelijk als een gemakkelijke test die enigszins werkt.

Het meten van wat hackers daadwerkelijk proberen te doen, het ontwerpen van mooie software, zou veel moeilijker zijn. Je hebt een goed gevoel voor design nodig om goed design te beoordelen. En er is geen correlatie, behalve mogelijk een negatieve correlatie, tussen het vermogen van mensen om goed design te herkennen en hun vertrouwen dat ze dat kunnen.

De enige externe test is tijd. Na verloop van tijd hebben mooie dingen de neiging te gedijen, en lelijke dingen hebben de neiging te worden weggegooid. Helaas kunnen de hoeveelheden tijd die ermee gemoeid zijn langer zijn dan mensenlevens. Samuel Johnson zei dat het honderd jaar duurde voordat de reputatie van een schrijver convergeerde. Je moet wachten tot de invloedrijke vrienden van de schrijver sterven, en daarna tot al hun volgelingen sterven.

Ik denk dat hackers zich er gewoon bij moeten neerleggen dat er een grote willekeurige component in hun reputatie zit. Daarin verschillen ze niet van andere makers. Sterker nog, ze hebben geluk in vergelijking. De invloed van mode is lang niet zo groot in hacken als in schilderen.

Er zijn ergere dingen dan dat mensen je werk verkeerd begrijpen. Een groter gevaar is dat je zelf je werk verkeerd begrijpt. Gerelateerde velden zijn waar je naar ideeën zoekt. Als je je op de computerwetenschappelijke afdeling bevindt, is er een natuurlijke verleiding om bijvoorbeeld te geloven dat hacken de toegepaste versie is van waar theoretische computerwetenschappen de theorie van is. Al die tijd dat ik op de universiteit zat, had ik een ongemakkelijk gevoel in de achterhoofd dat ik meer theorie moest kennen, en dat het erg nalatig van me was om al die dingen binnen drie weken na het eindexamen te zijn vergeten.

Nu realiseer ik me dat ik het mis had. Hackers hoeven de rekentheorie ongeveer net zoveel te begrijpen als schilders verfchemie moeten begrijpen. Je moet weten hoe je tijd- en ruimtecomplexiteit berekent en over Turing-volledigheid. Je wilt misschien ook tenminste het concept van een toestandsautomaat onthouden, voor het geval je een parser of een reguliere expressiebibliotheek moet schrijven. Schilders moeten in feite veel meer onthouden over verfchemie dan dat.

Ik heb gemerkt dat de beste bronnen van ideeën niet de andere gebieden zijn die het woord "computer" in hun naam hebben, maar de andere gebieden die bewoond worden door makers. Schilderen is een veel rijkere bron van ideeën geweest dan de rekentheorie.

Ik kreeg bijvoorbeeld op de universiteit te horen dat men een programma volledig op papier moest uitwerken voordat men zelfs maar in de buurt van een computer kwam. Ik merkte dat ik niet op die manier programmeerde. Ik merkte dat ik het leuk vond om te programmeren terwijl ik voor een computer zat, niet voor een stuk papier. Erger nog, in plaats van geduldig een compleet programma uit te schrijven en mezelf ervan te verzekeren dat het correct was, had ik de neiging om gewoon code uit te spugen die hopeloos defect was, en deze geleidelijk in vorm te slaan. Debuggen, zo werd me geleerd, was een soort laatste ronde waarin je typfouten en vergissingen opving. De manier waarop ik werkte, leek het programmeren te bestaan uit debuggen.

Lange tijd voelde ik me hier slecht over, net zoals ik me vroeger slecht voelde dat ik mijn potlood niet vasthield zoals ze me op de basisschool hadden geleerd. Als ik alleen maar had gekeken naar de andere makers, de schilders of de architecten, zou ik hebben gerealiseerd dat er een naam was voor wat ik deed: schetsen. Voor zover ik kan nagaan, was de manier waarop ze me op de universiteit leerden programmeren helemaal verkeerd. Je moet programma's bedenken terwijl je ze schrijft, net zoals schrijvers en schilders en architecten dat doen.

Dit realiseren heeft echte implicaties voor softwareontwerp. Het betekent dat een programmeertaal bovenal kneedbaar moet zijn. Een programmeertaal is om programma's te bedenken, niet om programma's uit te drukken die je al hebt bedacht. Het moet een potlood zijn, geen pen. Statische typering zou een prima idee zijn als mensen programma's daadwerkelijk zouden schrijven zoals ze me op de universiteit leerden. Maar zo schrijven geen van de hackers die ik ken programma's. We hebben een taal nodig die ons laat krabbelen en vlekken en smeren, geen taal waarin je moet zitten met een kopje thee met types op je knie en beleefde gesprekken moet voeren met een strenge oude tante van een compiler.

Nu we het toch over statische typering hebben, jezelf identificeren met de makers zal ons redden van nog een probleem dat de wetenschappen teistert: wiskunde-jaloezie. Iedereen in de wetenschappen gelooft in het geheim dat wiskundigen slimmer zijn dan zij. Ik denk dat wiskundigen dit ook geloven. Hoe dan ook, het resultaat is dat wetenschappers hun werk zo wiskundig mogelijk proberen te laten lijken. Op een gebied als natuurkunde doet dit waarschijnlijk niet veel kwaad, maar hoe verder je van de natuurwetenschappen afkomt, hoe groter het probleem wordt.

Een pagina met formules ziet er gewoon zo indrukwekkend uit. (Tip: voor extra indruk, gebruik Griekse variabelen.) En dus is er een grote verleiding om te werken aan problemen die je formeel kunt behandelen, in plaats van aan problemen die bijvoorbeeld belangrijk zijn.

Als hackers zich zouden identificeren met andere makers, zoals schrijvers en schilders, zouden ze deze neiging niet voelen. Schrijvers en schilders lijden niet aan wiskunde-jaloezie. Ze hebben het gevoel dat ze iets compleet anders doen. Dat hebben hackers ook, denk ik.

Als universiteiten en onderzoekslaboratoria hackers ervan weerhouden het soort werk te doen dat ze willen doen, is de plek voor hen misschien in bedrijven. Helaas laten de meeste bedrijven hackers ook niet doen wat ze willen. Universiteiten en onderzoekslaboratoria dwingen hackers om wetenschappers te zijn, en bedrijven dwingen hen om ingenieurs te zijn.

Ik heb dit zelf pas vrij recent ontdekt. Toen Yahoo Viaweb kocht, vroegen ze me wat ik wilde doen. Ik had de zakelijke kant nooit erg leuk gevonden, en zei dat ik gewoon wilde hacken. Toen ik bij Yahoo kwam, ontdekte ik dat hacken voor hen betekende software implementeren, niet ontwerpen. Programmeurs werden gezien als technici die de visies (als dat het woord is) van productmanagers in code vertaalden.

Dit lijkt het standaardplan in grote bedrijven te zijn. Ze doen dit omdat het de standaarddeviatie van de uitkomst vermindert. Slechts een klein percentage hackers kan daadwerkelijk software ontwerpen, en het is moeilijk voor de mensen die een bedrijf runnen om deze te kiezen. Dus in plaats van de toekomst van de software toe te vertrouwen aan één briljante hacker, richten de meeste bedrijven het zo in dat het door een commissie wordt ontworpen, en de hackers implementeren alleen het ontwerp.

Als je op een gegeven moment geld wilt verdienen, onthoud dit dan, want dit is een van de redenen waarom startups winnen. Grote bedrijven willen de standaarddeviatie van ontwerpuitkomsten verminderen omdat ze rampen willen vermijden. Maar als je oscillaties dempt, verlies je ook de hoogtepunten. Dit is geen probleem voor grote bedrijven, want ze winnen niet door geweldige producten te maken. Grote bedrijven winnen door minder slecht te zijn dan andere grote bedrijven.

Dus als je een manier kunt bedenken om in een ontwerp-oorlog te gaan met een bedrijf dat groot genoeg is dat hun software door productmanagers wordt ontworpen, zullen ze je nooit kunnen bijhouden. Deze kansen zijn echter niet gemakkelijk te vinden. Het is moeilijk om een groot bedrijf in een ontwerp-oorlog te betrekken, net zoals het moeilijk is om een tegenstander binnen een kasteel te betrekken in een hand-tot-hand gevecht. Het zou bijvoorbeeld vrij gemakkelijk zijn om een betere tekstverwerker te schrijven dan Microsoft Word, maar Microsoft, binnen het kasteel van hun besturingssysteemmonopolie, zou het waarschijnlijk niet eens opmerken als je dat deed.

De plek om ontwerp-oorlogen te voeren is in nieuwe markten, waar nog niemand erin is geslaagd vestigingen te vestigen. Daar kun je groot winnen door de gedurfde aanpak van ontwerp te kiezen, en dezelfde mensen zowel het product te laten ontwerpen als implementeren. Microsoft deed dit zelf aan het begin. Dat deden Apple ook. En Hewlett-Packard. Ik vermoed dat bijna elke succesvolle startup dat heeft gedaan.

Dus een manier om geweldige software te bouwen is om je eigen startup te beginnen. Er zijn echter twee problemen. Eén is dat je in een startup zoveel meer moet doen dan alleen software schrijven. Bij Viaweb beschouwde ik mezelf als gelukkig als ik een kwart van de tijd kon hacken. En de dingen die ik de andere driekwart van de tijd moest doen, varieerden van vervelend tot angstaanjagend. Ik heb hiervoor een benchmark, want ik moest ooit een bestuursvergadering verlaten om wat gaatjes te laten vullen. Ik herinner me dat ik achterover leunde in de tandartsstoel, wachtend op de boor, en het voelde als vakantie.

Het andere probleem met startups is dat er niet veel overlap is tussen het soort software dat geld oplevert en het soort dat interessant is om te schrijven. Programmeertalen zijn interessant om te schrijven, en Microsoft's eerste product was er een, maar niemand betaalt nu voor programmeertalen. Als je geld wilt verdienen, word je gedwongen te werken aan problemen die te vies zijn om door iemand gratis op te lossen.

Alle makers worden geconfronteerd met dit probleem. Prijzen worden bepaald door vraag en aanbod, en er is gewoon niet zoveel vraag naar dingen waar het leuk is om aan te werken als naar dingen die de alledaagse problemen van individuele klanten oplossen. Acteren in off-Broadway-stukken betaalt gewoon niet zo goed als het dragen van een gorilla-pak in de stand van iemand op een beurs. Romans schrijven betaalt niet zo goed als het schrijven van advertentieteksten voor afvalverwerkers. En programmeertalen hacken betaalt niet zo goed als het uitzoeken hoe je de legacy-database van een bedrijf verbindt met hun webserver.

Ik denk dat het antwoord op dit probleem, in het geval van software, een concept is dat bekend is bij bijna alle makers: de dagelijkse baan. Deze uitdrukking begon bij muzikanten, die 's nachts optreden. Meer in het algemeen betekent het dat je één soort werk doet voor geld, en een ander voor liefde.

Bijna alle makers hebben vroeg in hun carrière een dagelijkse baan. Schilders en schrijvers doen dat notoir. Als je geluk hebt, kun je een dagelijkse baan krijgen die nauw aansluit bij je echte werk. Muzikanten lijken vaak in platenzaken te werken. Een hacker die aan een programmeertaal of besturingssysteem werkt, zou op dezelfde manier een dagelijkse baan kunnen krijgen waarin hij het gebruikt. [1]

Als ik zeg dat het antwoord is dat hackers een dagelijkse baan hebben en in de vrije tijd aan mooie software werken, stel ik dit niet voor als een nieuw idee. Dit is waar open-source hacken over gaat. Wat ik zeg is dat open-source waarschijnlijk het juiste model is, omdat het onafhankelijk is bevestigd door alle andere makers.

Het lijkt me verrassend dat elke werkgever terughoudend zou zijn om hackers te laten werken aan open-source projecten. Bij Viaweb zouden we terughoudend zijn geweest om iemand aan te nemen die dat niet deed. Toen we programmeurs interviewden, was het belangrijkste waar we om gaven, wat voor soort software ze in hun vrije tijd schreven. Je kunt niets echt goed doen, tenzij je ervan houdt, en als je van hacken houdt, zul je onvermijdelijk aan je eigen projecten werken. [2]

Omdat hackers makers zijn in plaats van wetenschappers, is de juiste plek om metaforen te zoeken niet in de wetenschappen, maar onder andere soorten makers. Wat kan schilderen ons nog meer leren over hacken?

Eén ding dat we kunnen leren, of op zijn minst bevestigen, uit het voorbeeld van schilderen is hoe we moeten leren hacken. Je leert schilderen grotendeels door het te doen. Idem dito voor hacken. De meeste hackers leren niet hacken door collegecursussen programmeren te volgen. Ze leren hacken door op dertienjarige leeftijd hun eigen programma's te schrijven. Zelfs in collegeklassen leer je grotendeels hacken door te hacken. [3]

Omdat schilders een spoor van werk achterlaten, kun je ze zien leren door te doen. Als je het werk van een schilder in chronologische volgorde bekijkt, zul je merken dat elk schilderij voortbouwt op dingen die in eerdere schilderijen zijn geleerd. Wanneer er iets in een schilderij zit dat heel goed werkt, kun je daar meestal versie 1 van vinden in een kleinere vorm in een eerder schilderij.

Ik denk dat de meeste makers zo werken. Schrijvers en architecten lijken dat ook te doen. Misschien zouden hackers zich meer als schilders moeten gedragen, en regelmatig opnieuw beginnen, in plaats van jarenlang aan één project te werken, en al hun latere ideeën als revisies te proberen op te nemen.

Het feit dat hackers leren hacken door het te doen, is nog een teken van hoe anders hacken is dan de wetenschappen. Wetenschappers leren geen wetenschap door het te doen, maar door labs en opgaven te doen. Wetenschappers beginnen met werk dat perfect is, in de zin dat ze gewoon proberen werk te reproduceren dat iemand anders al voor hen heeft gedaan. Uiteindelijk komen ze op het punt dat ze origineel werk kunnen doen. Terwijl hackers vanaf het begin origineel werk doen; het is gewoon erg slecht. Dus hackers beginnen origineel en worden goed, en wetenschappers beginnen goed en worden origineel.

De andere manier waarop makers leren, is van voorbeelden. Voor een schilder is een museum een referentiebibliotheek van technieken. Honderden jaren lang is het onderdeel geweest van de traditionele opleiding van schilders om de werken van de grote meesters te kopiëren, omdat kopiëren je dwingt om nauwkeurig te kijken naar de manier waarop een schilderij is gemaakt.

Schrijvers doen dit ook. Benjamin Franklin leerde schrijven door de punten in de essays van Addison en Steele samen te vatten en ze vervolgens te proberen te reproduceren. Raymond Chandler deed hetzelfde met detectiveverhalen.

Hackers kunnen op dezelfde manier leren programmeren door naar goede programma's te kijken-- niet alleen naar wat ze doen, maar ook naar de broncode. Een van de minder bekende voordelen van de open-source beweging is dat het het gemakkelijker heeft gemaakt om te leren programmeren. Toen ik leerde programmeren, moesten we ons voornamelijk verlaten op voorbeelden in boeken. Het enige grote stuk code dat destijds beschikbaar was, was Unix, maar zelfs dit was geen open source. De meeste mensen die de broncode lazen, lazen het in illegale fotokopieën van John Lions' boek, dat hoewel geschreven in 1977, pas in 1996 mocht worden gepubliceerd.

Nog een voorbeeld dat we uit het schilderen kunnen halen, is de manier waarop schilderijen worden gemaakt door geleidelijke verfijning. Schilderijen beginnen meestal met een schets. Geleidelijk worden de details ingevuld. Maar het is niet louter een proces van invullen. Soms blijken de oorspronkelijke plannen onjuist te zijn. Talloze schilderijen, als je ze in röntgenfoto's bekijkt, blijken ledematen te hebben die zijn verplaatst of gelaatstrekken die zijn aangepast.

Hier is een geval waarin we van schilderen kunnen leren. Ik denk dat hacken ook op deze manier zou moeten werken. Het is onrealistisch om te verwachten dat de specificaties voor een programma perfect zullen zijn. Je kunt beter toegeven dat je dit van tevoren weet, en programma's schrijven op een manier die veranderingen in specificaties on-the-fly toestaat.

(De structuur van grote bedrijven maakt dit voor hen moeilijk, dus hier hebben startups nog een voordeel.)

Iedereen weet nu waarschijnlijk van het gevaar van voortijdige optimalisatie. Ik denk dat we net zo bezorgd moeten zijn over voortijdige ontwerp-- te vroeg beslissen wat een programma moet doen.

De juiste tools kunnen ons helpen dit gevaar te vermijden. Een goede programmeertaal moet, net als olieverf, het gemakkelijk maken om van gedachten te veranderen. Dynamische typering is hier een winst omdat je niet vooraf specifieke datarepresentaties hoeft vast te leggen. Maar de sleutel tot flexibiliteit, denk ik, is om de taal erg abstract te maken. Het gemakkelijkste programma om te veranderen is een programma dat erg kort is.

Dit klinkt als een paradox, maar een geweldig schilderij moet beter zijn dan het hoeft te zijn. Toen Leonardo bijvoorbeeld het portret van Ginevra de Benci in de National Gallery schilderde, plaatste hij een jeneverbesstruik achter haar hoofd. Daarin schilderde hij zorgvuldig elk individueel blad. Veel schilders zouden hebben gedacht: dit is gewoon iets om op de achtergrond te zetten om haar hoofd te omlijsten. Niemand zal er zo nauwkeurig naar kijken.

Niet Leonardo. Hoe hard hij ook werkte aan een deel van een schilderij, hing helemaal niet af van hoe nauwkeurig hij verwachtte dat iemand ernaar zou kijken. Hij was als Michael Jordan. Meedogenloos.

Meedogenloosheid wint omdat, in totaal, ongeziene details zichtbaar worden. Wanneer mensen langs het portret van Ginevra de Benci lopen, wordt hun aandacht er vaak onmiddellijk door getrokken, zelfs voordat ze het etiket lezen en merken dat er Leonardo da Vinci op staat. Al die ongeziene details combineren om iets te produceren dat gewoon verbluffend is, als duizend nauwelijks hoorbare stemmen die allemaal in harmonie zingen.

Geweldige software vereist evenzo een fanatieke toewijding aan schoonheid. Als je naar goede software kijkt, zul je zien dat delen die niemand ooit zou moeten zien, ook mooi zijn. Ik beweer niet dat ik geweldige software schrijf, maar ik weet dat als het op code aankomt, ik me gedraag op een manier die me in aanmerking zou brengen voor medicijnen op recept als ik het dagelijks leven op dezelfde manier zou benaderen. Het drijft me tot waanzin om code te zien die slecht is ingesprongen, of die lelijke variabelenamen gebruikt.

Als een hacker slechts een implementator was, die een specificatie omzette in code, dan kon hij er gewoon van het ene uiteinde naar het andere doorheen werken als iemand die een greppel graaft. Maar als de hacker een maker is, moeten we rekening houden met inspiratie.

In hacken, net als in schilderen, komt werk in cycli. Soms raak je enthousiast over een nieuw project en wil je er zestien uur per dag aan werken. Andere keren lijkt niets interessant.

Om goed werk te doen, moet je rekening houden met deze cycli, omdat ze worden beïnvloed door hoe je erop reageert. Als je in een auto met handgeschakelde versnelling op een heuvel rijdt, moet je soms de koppeling loslaten om te voorkomen dat de motor afslaat. Loslaten kan ambitie evenzo voorkomen dat hij afslaat. Zowel in schilderen als in hacken zijn er taken die angstaanjagend ambitieus zijn, en andere die geruststellend routinematig zijn. Het is een goed idee om gemakkelijke taken te bewaren voor momenten waarop je anders zou stilvallen.

In hacken kan dit letterlijk betekenen dat je bugs opspaart. Ik hou van debuggen: het is het enige moment dat hacken zo rechttoe rechtaan is als mensen denken dat het is. Je hebt een totaal beperkt probleem, en alles wat je hoeft te doen is het oplossen. Je programma zou x moeten doen. In plaats daarvan doet het y. Waar gaat het mis? Je weet dat je uiteindelijk zult winnen. Het is net zo ontspannend als een muur schilderen.

Het voorbeeld van schilderen kan ons niet alleen leren hoe we ons eigen werk moeten beheren, maar ook hoe we moeten samenwerken. Veel van de grote kunst uit het verleden is het werk van meerdere handen, hoewel er misschien maar één naam naast staat in het museum. Leonardo was een leerling in het atelier van Verrocchio en schilderde een van de engelen in diens Doop van Christus. Dit soort dingen was de regel, geen uitzondering. Michelangelo werd als bijzonder toegewijd beschouwd omdat hij erop stond alle figuren op het plafond van de Sixtijnse Kapel zelf te schilderen.

Voor zover ik weet, werkten schilders nooit aan dezelfde delen als ze samen aan een schilderij werkten. Het was gebruikelijk dat de meester de belangrijkste figuren schilderde en assistenten de andere en de achtergrond. Maar je had nooit één man die over het werk van een ander heen schilderde.

Ik denk dat dit ook het juiste model is voor samenwerking in software. Duw het niet te ver. Wanneer een stuk code door drie of vier verschillende mensen wordt gehackt, waarvan niemand het echt bezit, zal het eindigen als een gemeenschappelijke ruimte. Het zal somber en verlaten aanvoelen, en cruft verzamelen. De juiste manier om samen te werken, denk ik, is om projecten op te splitsen in scherp gedefinieerde modules, elk met een duidelijke eigenaar, en met interfaces ertussen die net zo zorgvuldig zijn ontworpen en, indien mogelijk, net zo gearticuleerd als programmeertalen.

Net als schilderen is de meeste software bedoeld voor een menselijk publiek. En dus moeten hackers, net als schilders, empathie hebben om echt geweldig werk te doen. Je moet dingen vanuit het perspectief van de gebruiker kunnen zien.

Toen ik een kind was, werd me altijd gezegd dat ik dingen vanuit het perspectief van iemand anders moest bekijken. Wat dit in de praktijk altijd betekende, was doen wat iemand anders wilde, in plaats van wat ik wilde. Dit gaf empathie natuurlijk een slechte naam, en ik nam me voor het niet te cultiveren.

Jongens, wat had ik het mis. Het blijkt dat dingen vanuit het perspectief van anderen bekijken praktisch het geheim van succes is. Het betekent niet noodzakelijk zelfopoffering. Lang niet. Begrijpen hoe iemand anders dingen ziet, impliceert niet dat je in zijn belang zult handelen; in sommige situونnen-- in oorlog, bijvoorbeeld-- wil je precies het tegenovergestelde doen. [4]

De meeste makers maken dingen voor een menselijk publiek. En om een publiek te boeien, moet je begrijpen wat ze nodig hebben. Bijna alle grootste schilderijen zijn bijvoorbeeld schilderijen van mensen, omdat mensen zijn waar mensen in geïnteresseerd zijn.

Empathie is waarschijnlijk het belangrijkste verschil tussen een goede hacker en een geweldige. Sommige hackers zijn behoorlijk slim, maar als het op empathie aankomt, zijn ze praktisch solipsistisch. Het is moeilijk voor zulke mensen om geweldige software te ontwerpen [5], omdat ze dingen niet vanuit het perspectief van de gebruiker kunnen zien.

Een manier om te beoordelen hoe goed mensen zijn in empathie, is door ze een technische vraag te laten uitleggen aan iemand zonder technische achtergrond. We kennen waarschijnlijk allemaal mensen die, hoewel anders slim, hier gewoon komisch slecht in zijn. Als iemand hen op een etentje vraagt wat een programmeertaal is, zullen ze iets zeggen als "Oh, een high-level taal is wat de compiler gebruikt als input om objectcode te genereren." High-level taal? Compiler? Objectcode? Iemand die niet weet wat een programmeertaal is, weet dit soort dingen duidelijk ook niet.

Een deel van wat software moet doen, is zichzelf uitleggen. Dus om goede software te schrijven, moet je begrijpen hoe weinig gebruikers begrijpen. Ze zullen de software zonder voorbereiding benaderen, en het kan maar beter doen wat ze ervan raden, want ze zullen de handleiding niet lezen. Het beste systeem dat ik ooit in dit opzicht heb gezien, was de originele Macintosh, in 1985. Het deed wat software bijna nooit doet: het werkte gewoon. [6]

Broncode moet ook zichzelf uitleggen. Als ik mensen zover kon krijgen dat ze slechts één citaat over programmeren onthouden, zou het degene zijn aan het begin van Structure and Interpretation of Computer Programs.

Programs should be written for people to read, and only incidentally for machines to execute.

Je moet niet alleen empathie hebben voor je gebruikers, maar ook voor je lezers. Het is in je eigen belang, want je zult er zelf een van zijn. Menig hacker heeft een programma geschreven om er vervolgens zes maanden later achter te komen dat hij geen idee heeft hoe het werkt. Ik ken verschillende mensen die na zulke ervaringen gezworen hebben Perl te mijden. [7]

Gebrek aan empathie wordt geassocieerd met intelligentie, tot het punt dat er zelfs een soort mode voor is op sommige plaatsen. Maar ik denk niet dat er enige correlatie is. Je kunt goed presteren in wiskunde en natuurwetenschappen zonder empathie te hoeven leren, en mensen in deze velden zijn doorgaans slim, dus de twee kwaliteiten zijn geassocieerd geraakt. Maar er zijn ook genoeg domme mensen die slecht zijn in empathie. Luister maar naar de mensen die vragen stellen op praatprogramma's. Ze stellen wat ze ook vragen op zo'n indirecte manier dat de hosts de vraag vaak voor hen moeten herformuleren.

Dus, als hacken werkt als schilderen en schrijven, is het dan net zo cool? Je leeft tenslotte maar één keer. Je kunt het maar beter besteden aan iets geweldigs.

Helaas is de vraag moeilijk te beantwoorden. Er is altijd een grote tijdvertraging in prestige. Het is als licht van een verre ster. Schilderen heeft nu prestige vanwege het geweldige werk dat mensen vijfhonderd jaar geleden deden. Destijds dachten niemand dat deze schilderijen zo belangrijk waren als wij vandaag de dag. Het zou voor mensen uit die tijd heel vreemd hebben geleken dat Federico da Montefeltro, de hertog van Urbino, op een dag vooral bekend zou staan als de man met de vreemde neus in een schilderij van Piero della Francesca.

Dus hoewel ik toegeef dat hacken nu niet zo cool lijkt als schilderen, moeten we niet vergeten dat schilderen zelf in zijn gloriedagen niet zo cool leek als nu.

Wat we met enige zekerheid kunnen zeggen, is dat dit de gloriedagen van hacken zijn. Op de meeste gebieden wordt het geweldige werk vroeg gedaan. De schilderijen gemaakt tussen 1430 en 1500 zijn nog steeds onovertroffen. Shakespeare verscheen net toen het professionele theater werd geboren, en duwde het medium zo ver dat elke toneelschrijver sindsdien in zijn schaduw heeft moeten leven. Albrecht Durer deed hetzelfde met gravure, en Jane Austen met de roman.

Steeds weer zien we hetzelfde patroon. Een nieuw medium verschijnt, en mensen zijn er zo enthousiast over dat ze de meeste mogelijkheden ervan in de eerste paar generaties verkennen. Hacken lijkt zich nu in deze fase te bevinden.

Schilderen was in Leonardo's tijd niet zo cool als zijn werk het hielp maken. Hoe cool hacken uiteindelijk zal blijken te zijn, hangt af van wat we met dit nieuwe medium kunnen doen.

Noten

[1] De grootste schade die fotografie aan het schilderen heeft toegebracht, is misschien wel het feit dat het de beste dagbaan heeft gedood. De meeste grote schilders in de geschiedenis onderhielden zichzelf door portretten te schilderen.

[2] Mij is verteld dat Microsoft werknemers ontmoedigt om bij te dragen aan open-source projecten, zelfs in hun vrije tijd. Maar zoveel van de beste hackers werken nu aan open-source projecten dat het belangrijkste effect van dit beleid kan zijn dat ze geen eersteklas programmeurs kunnen aannemen.

[3] Wat je op de universiteit leert over programmeren is veel als wat je leert over boeken of kleding of daten: welke slechte smaak je had op de middelbare school.

[4] Hier is een voorbeeld van toegepaste empathie. Bij Viaweb, als we niet konden kiezen tussen twee alternatieven, vroegen we: wat zouden onze concurrenten het meest haten? Op een gegeven moment voegde een concurrent een functie toe aan hun software die in wezen nutteloos was, maar omdat het een van de weinige was die wij niet hadden, maakten ze er veel reclame voor in de vakpers. We hadden kunnen proberen uit te leggen dat de functie nutteloos was, maar we besloten dat het onze concurrent meer zou irriteren als we het zelf implementeerden, dus hackten we die middag onze eigen versie in elkaar.

[5] Behalve tekst editors en compilers. Hackers hebben geen empathie nodig om deze te ontwerpen, omdat ze zelf typische gebruikers zijn.

[6] Nou ja, bijna. Ze schoten enigszins over de beschikbare RAM heen, wat veel ongemakkelijk schijfswappen veroorzaakte, maar dit kon binnen een paar maanden worden opgelost door een extra schijfstation te kopen.

[7] De manier om programma's gemakkelijk leesbaar te maken, is niet door ze vol te proppen met commentaar. Ik zou het citaat van Abelson en Sussman een stap verder nemen. Programmeertalen moeten worden ontworpen om algoritmen uit te drukken, en slechts incidenteel om computers te vertellen hoe ze moeten worden uitgevoerd. Een goede programmeertaal zou beter moeten zijn in het uitleggen van software dan Engels. Je zou alleen commentaar nodig moeten hebben als er een soort kludge is waar je lezers voor moet waarschuwen, net zoals er op een weg alleen pijlen zijn op delen met onverwacht scherpe bochten.

Dank aan Trevor Blackwell, Robert Morris, Dan Giffin en Lisa Randall voor het lezen van concepten hiervan, en aan Henry Leitner en Larry Finkelstein voor het uitnodigen om te spreken.