Geweldige Hackers | undefined | Essays van Paul Graham

Wil je een startup beginnen? Krijg financiering van Y Combinator.

Juli 2004

(Dit essay is gebaseerd op een lezing op Oscon 2004.)

Aantal maanden geleden heb ik een nieuw boek afgerond, en in recensies zie ik steeds woorden als "provocerend" en "controversieel" terugkomen. Om nog maar te zwijgen van "idioot".

Ik wilde het boek niet controversieel maken. Ik probeerde het efficiënt te maken. Ik wilde mensen hun tijd niet verspillen door dingen te vertellen die ze al wisten. Het is efficiënter om ze gewoon de diffs te geven. Maar ik vermoed dat dat een alarmerend boek zal opleveren.

Edisons

Er is geen controverse over welk idee het meest controversieel is: de suggestie dat welvaartsverschillen misschien niet zo'n groot probleem zijn als we denken.

Ik heb in het boek niet gezegd dat welvaartsverschillen op zich een goede zaak zijn. Ik zei dat het in sommige situaties een teken van goede dingen kan zijn. Een bonzende hoofdpijn is geen goede zaak, maar het kan een teken zijn van een goede zaak - bijvoorbeeld dat je weer bij bewustzijn komt na een klap op je hoofd.

Welvaartsverschillen kunnen een teken zijn van productiviteitsverschillen. (In een samenleving van één zijn ze identiek.) En dat is vrijwel zeker een goede zaak: als je samenleving geen productiviteitsverschillen heeft, is dat waarschijnlijk niet omdat iedereen Thomas Edison is. Het is waarschijnlijk omdat je geen Thomas Edisons hebt.

In een laaggeletterde samenleving zie je niet veel productiviteitsverschillen. Als je een stam nomaden hebt die stokken verzamelt voor een vuur, hoeveel productiever is de beste stokverzamelaar dan de slechtste? Een factor twee? Terwijl als je mensen een complex gereedschap zoals een computer geeft, de variatie in wat ze ermee kunnen doen enorm is.

Dat is geen nieuw idee. Fred Brooks schreef er in 1974 over, en de studie die hij aanhaalde werd gepubliceerd in 1968. Maar ik denk dat hij de verschillen tussen programmeurs onderschatte. Hij schreef over productiviteit in regels code: de beste programmeurs kunnen een gegeven probleem in een tiende van de tijd oplossen. Maar wat als het probleem niet gegeven is? In programmeren, net als in veel andere gebieden, is het moeilijke deel niet het oplossen van problemen, maar het beslissen welke problemen op te lossen. Verbeelding is moeilijk te meten, maar in de praktijk domineert het de soort productiviteit die wordt gemeten in regels code.

Productiviteit varieert op elk gebied, maar er zijn er weinig waarin het zo sterk varieert. De verschillen tussen programmeurs zijn zo groot dat het een verschil in soort wordt. Ik denk echter niet dat dit iets intrinsieks aan programmeren is. Op elk gebied vergroot technologie productiviteitsverschillen. Ik denk dat wat er in programmeren gebeurt, gewoon is dat we veel technologische hefboomwerking hebben. Maar op elk gebied wordt de hefboom langer, dus de variatie die we zien is iets dat steeds meer gebieden na verloop van tijd zullen zien. En het succes van bedrijven, en landen, zal steeds meer afhangen van hoe ze ermee omgaan.

Als productiviteitsverschillen toenemen met technologie, dan zal de bijdrage van de meest productieve individuen niet alleen onevenredig groot zijn, maar ook daadwerkelijk groeien met de tijd. Wanneer je het punt bereikt waarop 90% van de output van een groep wordt gecreëerd door 1% van zijn leden, verlies je veel als iets (of het nu Vikingaanvallen of centrale planning zijn) hun productiviteit naar het gemiddelde trekt.

Als we het meeste uit hen willen halen, moeten we deze bijzonder productieve mensen begrijpen. Wat motiveert hen? Wat hebben ze nodig om hun werk te doen? Hoe herken je ze? Hoe krijg je ze om voor jou te komen werken? En dan is er natuurlijk de vraag, hoe word je er zelf een?

Meer dan Geld

Ik ken een handvol super-hackers, dus ik ging zitten en dacht na over wat ze gemeen hebben. Hun bepalende kwaliteit is waarschijnlijk dat ze echt graag programmeren. Gewone programmeurs schrijven code om de rekeningen te betalen. Geweldige hackers zien het als iets dat ze voor de lol doen, en waar ze blij mee zijn dat mensen hen ervoor willen betalen.

Geweldige programmeurs worden soms gezegd onverschillig te staan tegenover geld. Dit is niet helemaal waar. Het is waar dat alles waar ze echt om geven is het doen van interessant werk. Maar als je genoeg geld verdient, kun je werken aan wat je wilt, en om die reden worden hackers aangetrokken door het idee om echt veel geld te verdienen. Maar zolang ze nog elke dag moeten opdagen voor werk, geven ze meer om wat ze daar doen dan om hoeveel ze ervoor betaald krijgen.

Economisch gezien is dit een feit van het grootste belang, omdat het betekent dat je geweldige hackers niet hoeft te betalen wat ze waard zijn. Een geweldige programmeur kan tien of honderd keer productiever zijn dan een gewone, maar hij zal zichzelf gelukkig prijzen als hij drie keer zoveel betaald krijgt. Zoals ik later zal uitleggen, is dit deels omdat geweldige hackers niet weten hoe goed ze zijn. Maar het is ook omdat geld niet het belangrijkste is wat ze willen.

Wat willen hackers? Zoals alle ambachtslieden, houden hackers van goed gereedschap. Sterker nog, dat is een understatement. Goede hackers vinden het ondraaglijk om slecht gereedschap te gebruiken. Ze weigeren simpelweg te werken aan projecten met de verkeerde infrastructuur.

Bij een startup waar ik ooit werkte, hing een advertentie van IBM aan ons prikbord. Het was een foto van een AS400, en de kop luidde, geloof ik, "hackers verachten het". [1]

Wanneer je beslist welke infrastructuur je voor een project gebruikt, neem je niet alleen een technische beslissing. Je neemt ook een sociale beslissing, en dit kan belangrijker zijn dan de technische. Als je bedrijf bijvoorbeeld wat software wil schrijven, kan het een verstandige keuze lijken om het in Java te schrijven. Maar als je een taal kiest, kies je ook een gemeenschap. De programmeurs die je kunt aannemen om aan een Java-project te werken, zullen niet zo slim zijn als degenen die je zou kunnen krijgen om aan een project in Python te werken. En de kwaliteit van je hackers is waarschijnlijk belangrijker dan de taal die je kiest. Hoewel, eerlijk gezegd, het feit dat goede hackers de voorkeur geven aan Python boven Java je iets zou moeten vertellen over de relatieve verdiensten van die talen.

Zakelijke types geven de voorkeur aan de meest populaire talen omdat ze talen als standaarden beschouwen. Ze willen het bedrijf niet inzetten op Betamax. Het ding met talen is echter dat het niet alleen standaarden zijn. Als je bits over een netwerk moet verplaatsen, gebruik dan zeker TCP/IP. Maar een programmeertaal is niet zomaar een formaat. Een programmeertaal is een expressiemedium.

Ik heb gelezen dat Java zojuist Cobol heeft ingehaald als de meest populaire taal. Als standaard kun je niet meer wensen. Maar als expressiemedium kun je veel beter doen. Van alle geweldige programmeurs die ik me kan bedenken, ken ik er maar één die vrijwillig in Java zou programmeren. En van alle geweldige programmeurs die ik me kan bedenken die niet voor Sun werken, op Java, ken ik er nul.

Geweldige hackers staan er ook over het algemeen op om open-source software te gebruiken. Niet alleen omdat het beter is, maar omdat het hen meer controle geeft. Goede hackers eisen controle. Dit is een deel van wat hen goede hackers maakt: als iets kapot is, moeten ze het repareren. Je wilt dat ze dit gevoel hebben over de software die ze voor je schrijven. Je zou niet verrast moeten zijn als ze hetzelfde voelen over het besturingssysteem.

Een paar jaar geleden vertelde een venture capitalist vriend me over een nieuwe startup waar hij bij betrokken was. Het klonk veelbelovend. Maar de volgende keer dat ik hem sprak, zei hij dat ze hadden besloten hun software op Windows NT te bouwen, en net een zeer ervaren NT-ontwikkelaar hadden aangenomen om hun technisch directeur te worden. Toen ik dit hoorde, dacht ik, deze jongens zijn gedoemd. Eén, de CTO kon geen eersteklas hacker zijn, want om een eminente NT-ontwikkelaar te worden, had hij NT vrijwillig moeten gebruiken, meerdere keren, en ik kon me niet voorstellen dat een geweldige hacker dat zou doen; en twee, zelfs als hij goed was, zou hij moeite hebben om iemand goeds aan te nemen om voor hem te werken als het project op NT gebouwd moest worden. [2]

De Laatste Grens

Na software is de belangrijkste tool voor een hacker waarschijnlijk zijn kantoor. Grote bedrijven denken dat de functie van kantoorruimte de rang uitdrukt. Maar hackers gebruiken hun kantoren voor meer dan dat: ze gebruiken hun kantoor als een plek om in te denken. En als je een technologiebedrijf bent, zijn hun gedachten je product. Dus het laten werken van hackers in een lawaaierige, afleidende omgeving is als een verffabriek waar de lucht vol roet zit.

De strip Dilbert zegt veel over cubicles, en met goede reden. Alle hackers die ik ken, verachten ze. Het enkele vooruitzicht om onderbroken te worden, is genoeg om hackers te weerhouden van het werken aan moeilijke problemen. Als je echt werk wilt verzetten in een kantoor met cubicles, heb je twee opties: thuis werken, of vroeg of laat komen, of in het weekend, wanneer niemand anders er is. Realiseren bedrijven niet dat dit een teken is dat er iets kapot is? Een kantooromgeving hoort iets te zijn dat je helpt te werken, niet iets waar je tegenin werkt.

Bedrijven als Cisco zijn er trots op dat iedereen daar een cubicle heeft, zelfs de CEO. Maar ze zijn niet zo geavanceerd als ze denken; duidelijk zien ze kantoorruimte nog steeds als een statussymbool. Merk ook op dat Cisco erom bekend staat heel weinig productontwikkeling in eigen huis te doen. Ze krijgen nieuwe technologie door de startups te kopen die het hebben gecreëerd - waar de hackers waarschijnlijk ergens rustig konden werken.

Eén groot bedrijf dat begrijpt wat hackers nodig hebben, is Microsoft. Ik zag ooit een wervingsadvertentie voor Microsoft met een grote foto van een deur. Werk voor ons, was de premisse, en we geven je een plek om te werken waar je daadwerkelijk werk kunt verzetten. En weet je, Microsoft is opmerkelijk onder grote bedrijven in die zin dat ze software in eigen huis kunnen ontwikkelen. Niet goed, misschien, maar goed genoeg.

Als bedrijven willen dat hackers productief zijn, moeten ze kijken naar wat ze thuis doen. Thuis kunnen hackers de dingen zelf regelen zodat ze het meeste gedaan krijgen. En als ze thuis werken, werken hackers niet in lawaaierige, open ruimtes; ze werken in kamers met deuren. Ze werken op gezellige, buurtachtige plekken met mensen om hen heen en ergens om te lopen wanneer ze iets moeten overdenken, in plaats van in glazen dozen op kilometers parkeerplaatsen. Ze hebben een bank waarop ze kunnen dutten als ze moe zijn, in plaats van in coma aan hun bureau te zitten en te doen alsof ze werken. Er is geen ploeg mensen met stofzuigers die elke avond tijdens de piekuren van het hacken door de ruimte raast. Er zijn geen vergaderingen of, God verhoede, bedrijfsuitjes of teambuilding-oefeningen. En als je kijkt naar wat ze op die computer doen, zul je zien dat het mijn eerdere opmerkingen over gereedschap bevestigt. Ze moeten misschien Java en Windows gebruiken op het werk, maar thuis, waar ze zelf kunnen kiezen, vind je ze waarschijnlijk eerder Perl en Linux gebruiken.

Inderdaad, deze statistieken over Cobol of Java als de meest populaire taal kunnen misleidend zijn. Wat we zouden moeten bekijken, als we willen weten welke tools het beste zijn, is wat hackers kiezen wanneer ze vrij kunnen kiezen - dat wil zeggen, in hun eigen projecten. Als je die vraag stelt, ontdek je dat open-source besturingssystemen al een dominante marktaandeel hebben, en de nummer één taal is waarschijnlijk Perl.

Interessant

Naast goed gereedschap willen hackers interessante projecten. Wat maakt een project interessant? Nou, duidelijk sexy applicaties zoals stealth-vliegtuigen of special effects software zouden interessant zijn om aan te werken. Maar elke applicatie kan interessant zijn als het nieuwe technische uitdagingen met zich meebrengt. Dus het is moeilijk te voorspellen welke problemen hackers zullen waarderen, omdat sommige pas interessant worden wanneer de mensen die eraan werken een nieuw soort oplossing ontdekken. Vóór ITA (die de software achter Orbitz schreef), dachten de mensen die aan zoekopdrachten voor vliegtuigtarieven werkten waarschijnlijk dat het een van de meest saaie toepassingen was die je je kon voorstellen. Maar ITA maakte het interessant door het probleem op een ambitieuzere manier te herdefiniëren.

Ik denk dat hetzelfde gebeurde bij Google. Toen Google werd opgericht, was de heersende opvatting onder de zogenaamde portals dat zoeken saai en onbelangrijk was. Maar de jongens bij Google dachten niet dat zoeken saai was, en daarom doen ze het zo goed.

Dit is een gebied waar managers een verschil kunnen maken. Net als een ouder die tegen een kind zegt: ik wed dat je je hele kamer niet in tien minuten kunt opruimen, kan een goede manager soms een probleem herdefiniëren als een interessanter probleem. Steve Jobs lijkt hier bijzonder goed in te zijn, deels simpelweg door hoge eisen te stellen. Er waren veel kleine, goedkope computers vóór de Mac. Hij herdefinieerde het probleem als: maak er een die mooi is. En dat dreef de ontwikkelaars waarschijnlijk harder dan welk wortel of stok dan ook.

Ze leverden zeker. Toen de Mac voor het eerst verscheen, hoefde je hem niet eens aan te zetten om te weten dat hij goed zou zijn; je kon het aan de behuizing zien. Een paar weken geleden liep ik door de straten van Cambridge, en in iemands vuilnis zag ik wat leek op een Mac-draagtas. Ik keek erin, en daar lag een Mac SE. Ik droeg hem naar huis en sloot hem aan, en hij startte op. Het blije Macintosh-gezicht, en toen de finder. Mijn God, het was zo simpel. Het was net als... Google.

Hackers werken graag voor mensen met hoge eisen. Maar het is niet genoeg om alleen maar veeleisend te zijn. Je moet aandringen op de juiste dingen. Wat meestal betekent dat je zelf een hacker moet zijn. Ik heb af en toe artikelen gezien over hoe je programmeurs moet managen. Eigenlijk zouden er twee artikelen moeten zijn: één over wat te doen als je zelf een programmeur bent, en één over wat te doen als je dat niet bent. En het tweede kan waarschijnlijk worden samengevat in twee woorden: geef het op.

Het probleem is niet zozeer het dagelijkse management. Echt goede hackers zijn praktisch zelf-managend. Het probleem is, als je geen hacker bent, kun je niet zeggen wie de goede hackers zijn. Een vergelijkbaar probleem verklaart waarom Amerikaanse auto's zo lelijk zijn. Ik noem het de design paradox. Je zou denken dat je je producten mooi kunt maken door gewoon een geweldige ontwerper in te huren om ze te ontwerpen. Maar als je zelf geen goede smaak hebt, hoe herken je dan een goede ontwerper? Per definitie kun je het niet aan zijn portfolio zien. En je kunt niet afgaan op de prijzen die hij heeft gewonnen of de banen die hij heeft gehad, omdat in design, net als in de meeste gebieden, die de neiging hebben om gedreven te worden door mode en schmoezen, met daadwerkelijke vaardigheid een verre derde plaats. Er is geen ontkomen aan: je kunt een proces dat bedoeld is om mooie dingen te produceren niet managen zonder te weten wat mooi is. Amerikaanse auto's zijn lelijk omdat Amerikaanse autofabrikanten worden gerund door mensen met slechte smaak.

Veel mensen in dit land beschouwen smaak als iets ongrijpbaars, of zelfs frivools. Dat is het geen van beide. Om design te sturen, moet een manager de meest veeleisende gebruiker van de producten van een bedrijf zijn. En als je echt goede smaak hebt, kun je, zoals Steve Jobs doet, het tevredenstellen van jou het soort probleem maken waar goede mensen graag aan werken.

Vervelende Kleine Problemen

Het is vrij gemakkelijk om te zeggen welke soorten problemen niet interessant zijn: die waarbij je in plaats van een paar grote, duidelijke problemen op te lossen, een heleboel vervelende kleine problemen moet oplossen. Een van de ergste soorten projecten is het schrijven van een interface voor een stuk software dat vol bugs zit. Een andere is wanneer je iets moet aanpassen aan de complexe en slecht gedefinieerde behoeften van een individuele klant. Voor hackers zijn dit soort projecten de dood van duizend sneden.

Het onderscheidende kenmerk van vervelende kleine problemen is dat je er niets van leert. Het schrijven van een compiler is interessant omdat het je leert wat een compiler is. Maar het schrijven van een interface voor een buggy stuk software leert je niets, omdat de bugs willekeurig zijn. [3] Dus het is niet alleen fastidieus dat goede hackers vervelende kleine problemen vermijden. Het is meer een kwestie van zelfbehoud. Werken aan vervelende kleine problemen maakt je dom. Goede hackers vermijden het om dezelfde reden dat modellen cheeseburgers vermijden.

Natuurlijk hebben sommige problemen inherent dit karakter. En vanwege vraag en aanbod betalen ze bijzonder goed. Dus een bedrijf dat een manier vond om geweldige hackers aan vervelende problemen te laten werken, zou zeer succesvol zijn. Hoe zou je dat doen?

Eén plek waar dit gebeurt, is in startups. Bij onze startup hadden we Robert Morris die als systeembeheerder werkte. Dat is als de Rolling Stones laten spelen op een bar mitswa. Je kunt dat soort talent niet inhuren. Maar mensen zullen elke hoeveelheid sleurwerk doen voor bedrijven waarvan ze de oprichters zijn. [4]

Grotere bedrijven lossen het probleem op door het bedrijf op te splitsen. Ze krijgen slimme mensen om voor hen te werken door een aparte R&D-afdeling op te richten waar werknemers niet direct aan de vervelende kleine problemen van klanten hoeven te werken. [5] In dit model functioneert de onderzoeksafdeling als een mijn. Ze produceren nieuwe ideeën; misschien kan de rest van het bedrijf ze gebruiken.

Je hoeft misschien niet zo ver te gaan. Bottom-up programmeren suggereert een andere manier om het bedrijf op te splitsen: laat de slimme mensen werken als gereedschapsmakers. Als je bedrijf software maakt om x te doen, laat dan een groep tools bouwen voor het schrijven van software van dat type, en een andere die deze tools gebruikt om de applicaties te schrijven. Op deze manier kun je misschien slimme mensen 99% van je code laten schrijven, maar ze toch bijna net zo afgeschermd houden van gebruikers als in een traditionele onderzoeksafdeling. De gereedschapsmakers zouden gebruikers hebben, maar dat zouden alleen de eigen ontwikkelaars van het bedrijf zijn. [6]

Als Microsoft deze aanpak zou gebruiken, zou hun software niet zoveel beveiligingslekken hebben, omdat de minder slimme mensen die de daadwerkelijke applicaties schrijven geen low-level dingen zouden doen zoals geheugen toewijzen. In plaats van Word direct in C te schrijven, zouden ze grote Lego-blokken van Word-taal aan elkaar koppelen. (Duplo, geloof ik, is de technische term.)

Klumpen

Naast interessante problemen, houden goede hackers van andere goede hackers. Geweldige hackers hebben de neiging om samen te klonteren - soms spectaculair, zoals bij Xerox Parc. Je zult dus geen goede hackers aantrekken in een lineaire verhouding tot hoe goed je een omgeving voor hen creëert. De neiging om te klonteren betekent dat het meer lijkt op het kwadraat van de omgeving. Dus het is winnaar neemt alles. Op elk gegeven moment zijn er maar ongeveer tien of twintig plekken waar hackers het liefst willen werken, en als je er niet een van bent, zul je niet alleen minder geweldige hackers hebben, maar nul.

Het hebben van geweldige hackers is op zichzelf niet genoeg om een bedrijf succesvol te maken. Het werkt goed voor Google en ITA, die momenteel twee van de hotspots zijn, maar het hielp Thinking Machines of Xerox niet. Sun had een goede run voor een tijdje, maar hun bedrijfsmodel is een neerwaartse lift. In die situatie kunnen zelfs de beste hackers je niet redden.

Ik denk echter dat, alle andere dingen gelijk, een bedrijf dat geweldige hackers kan aantrekken een enorm voordeel zal hebben. Er zijn mensen die het hier niet mee eens zullen zijn. Toen we in de jaren negentig rond de tafel gingen bij durfkapitaalfirma's, vertelden verschillende ons dat softwarebedrijven niet wonnen door geweldige software te schrijven, maar door merk, en het domineren van kanalen, en het doen van de juiste deals.

Ze leken dit echt te geloven, en ik denk dat ik weet waarom. Ik denk dat veel VCs, althans onbewust, op zoek zijn naar de volgende Microsoft. En natuurlijk, als Microsoft je model is, moet je niet zoeken naar bedrijven die hopen te winnen door geweldige software te schrijven. Maar VCs vergissen zich door te zoeken naar de volgende Microsoft, omdat geen enkele startup de volgende Microsoft kan zijn, tenzij een ander bedrijf zich op het juiste moment bereid verklaart om te buigen en de volgende IBM te worden.

Het is een vergissing om Microsoft als model te gebruiken, omdat hun hele cultuur voortkomt uit die ene gelukkige doorbraak. Microsoft is een slecht datapunt. Als je ze weggooit, ontdek je dat goede producten inderdaad de markt winnen. Waar VCs naar zouden moeten zoeken, is de volgende Apple, of de volgende Google.

Ik denk dat Bill Gates dit weet. Wat hem zorgen baart over Google is niet de kracht van hun merk, maar het feit dat ze betere hackers hebben. [7]

Erkenning

Dus wie zijn de geweldige hackers? Hoe weet je wanneer je er een ontmoet? Dat blijkt erg moeilijk te zijn. Zelfs hackers kunnen het niet zeggen. Ik ben er nu vrij zeker van dat mijn vriend Trevor Blackwell een geweldige hacker is. Je hebt misschien op Slashdot gelezen hoe hij zijn eigen Segway maakte. Het opmerkelijke aan dit project was dat hij alle software op één dag schreef (overigens in Python).

Voor Trevor is dat normaal. Maar toen ik hem voor het eerst ontmoette, dacht ik dat hij een complete idioot was. Hij stond in het kantoor van Robert Morris en brabbelde tegen hem over iets, en ik herinner me dat ik achter hem stond en Robert wanhopige gebaren maakte om deze gek uit zijn kantoor te jagen, zodat we konden gaan lunchen. Robert zegt dat hij Trevor aanvankelijk ook verkeerd inschatte. Blijkbaar, toen Robert hem voor het eerst ontmoette, was Trevor net begonnen met een nieuw plan waarbij hij alles over elk aspect van zijn leven opschreef op een stapel indexkaarten, die hij overal bij zich droeg. Hij was ook net uit Canada aangekomen, had een sterk Canadees accent en een mullet.

Het probleem wordt gecompliceerd door het feit dat hackers, ondanks hun reputatie van sociale onoplettendheid, soms veel moeite doen om slim over te komen. Toen ik op de universiteit zat, hing ik af en toe rond in het MIT AI Lab. Het was in het begin een beetje intimiderend. Iedereen sprak er zo snel. Maar na een tijdje leerde ik de truc van snel spreken. Je hoeft niet sneller te denken; gebruik gewoon twee keer zoveel woorden om alles te zeggen.

Met deze hoeveelheid ruis in het signaal is het moeilijk om goede hackers te herkennen als je ze ontmoet. Ik kan het, zelfs nu, niet zeggen. Je kunt het ook niet aan hun cv's zien. Het lijkt erop dat de enige manier om een hacker te beoordelen is door ermee samen te werken aan iets.

En dit is de reden dat high-tech gebieden alleen rond universiteiten ontstaan. Het actieve ingrediënt hier zijn niet zozeer de professoren als wel de studenten. Startups groeien rond universiteiten omdat universiteiten veelbelovende jonge mensen samenbrengen en ze aan dezelfde projecten laten werken. De slimmen leren wie de andere slimmen zijn, en samen bedenken ze nieuwe projecten.

Omdat je een geweldige hacker niet kunt herkennen zonder ermee samen te werken, kunnen hackers zelf niet weten hoe goed ze zijn. Dit geldt tot op zekere hoogte in de meeste gebieden. Ik heb gemerkt dat mensen die geweldig zijn in iets, niet zozeer overtuigd zijn van hun eigen grootsheid als wel verbijsterd zijn over waarom iedereen anders zo incompetent lijkt.

Maar het is voor hackers bijzonder moeilijk om te weten hoe goed ze zijn, omdat het moeilijk is om hun werk te vergelijken. Dit is in de meeste andere gebieden gemakkelijker. Op de honderd meter weet je binnen 10 seconden wie het snelst is. Zelfs in de wiskunde lijkt er een algemene consensus te zijn over welke problemen moeilijk op te lossen zijn, en wat een goede oplossing is. Maar hacken is als schrijven. Wie kan zeggen welke van de twee romans beter is? Zeker niet de auteurs.

Met hackers, althans, kunnen andere hackers het wel zeggen. Dat komt omdat, in tegenstelling tot romanschrijvers, hackers samenwerken aan projecten. Als je via het netwerk een paar moeilijke problemen bij iemand kunt neerleggen, leer je vrij snel hoe hard ze terugslaan. Maar hackers kunnen zichzelf niet aan het werk zien. Dus als je een geweldige hacker vraagt hoe goed hij is, zal hij vrijwel zeker antwoorden: ik weet het niet. Hij is niet alleen bescheiden. Hij weet het echt niet.

En niemand van ons weet het, behalve over mensen met wie we daadwerkelijk hebben samengewerkt. Wat ons in een vreemde situatie brengt: we weten niet wie onze helden zouden moeten zijn. De hackers die beroemd worden, worden beroemd door willekeurige PR-ongelukken. Af en toe moet ik een voorbeeld van een geweldige hacker geven, en ik weet nooit wie ik moet gebruiken. De eerste namen die me te binnen schieten, zijn altijd mensen die ik persoonlijk ken, maar het lijkt flauw om ze te gebruiken. Dus, denk ik, misschien moet ik Richard Stallman, of Linus Torvalds, of Alan Kay, of iemand die beroemd is, zeggen. Maar ik heb geen idee of deze jongens geweldige hackers zijn. Ik heb nooit met hen aan iets gewerkt.

Als er een Michael Jordan van hacken bestaat, weet niemand het, inclusief hijzelf.

Cultivatie

Tot slot, de vraag waar alle hackers zich over hebben afgevraagd: hoe word je een geweldige hacker? Ik weet niet of het mogelijk is om jezelf er een te maken. Maar het is zeker mogelijk om dingen te doen die je dom maken, en als je jezelf dom kunt maken, kun je jezelf waarschijnlijk ook slim maken.

De sleutel tot een goede hacker zijn, kan zijn om te werken aan wat je leuk vindt. Als ik denk aan de geweldige hackers die ik ken, is één ding dat ze gemeen hebben de extreme moeilijkheid om ze te laten werken aan iets waar ze geen zin in hebben. Ik weet niet of dit oorzaak of gevolg is; het kan beide zijn.

Om iets goed te doen, moet je er van houden. Dus voor zover je hacken kunt behouden als iets waar je van houdt, zul je het waarschijnlijk goed doen. Probeer het gevoel van verwondering te behouden dat je had over programmeren op 14-jarige leeftijd. Als je bang bent dat je huidige baan je hersens aan het rotten is, is dat waarschijnlijk zo.

De beste hackers zijn natuurlijk meestal slim, maar dat geldt voor veel gebieden. Is er een kwaliteit die uniek is voor hackers? Ik vroeg het aan enkele vrienden, en het belangrijkste dat ze noemden was nieuwsgierigheid. Ik had altijd aangenomen dat alle slimme mensen nieuwsgierig waren - dat nieuwsgierigheid simpelweg de eerste afgeleide van kennis was. Maar blijkbaar zijn hackers bijzonder nieuwsgierig, vooral naar hoe dingen werken. Dat is logisch, want programma's zijn in feite gigantische beschrijvingen van hoe dingen werken.

Verschillende vrienden noemden het concentratievermogen van hackers - hun vermogen, zoals een van hen het uitdrukte, om "alles buiten hun eigen hoofd uit te schakelen". Ik heb dit zeker gemerkt. En ik heb verschillende hackers horen zeggen dat ze na het drinken van zelfs maar een halve liter bier helemaal niet meer kunnen programmeren. Dus misschien vereist hacken een speciale concentratie. Misschien kunnen geweldige hackers een grote hoeveelheid context in hun hoofd laden, zodat wanneer ze naar een regel code kijken, ze niet alleen die regel zien, maar het hele programma eromheen. John McPhee schreef dat Bill Bradley's succes als basketballer deels te danken was aan zijn buitengewone perifere zicht. "Perfect" zicht betekent ongeveer 47 graden verticaal perifeer zicht. Bill Bradley had 70; hij kon de basket zien terwijl hij naar de vloer keek. Misschien hebben geweldige hackers een vergelijkbaar aangeboren vermogen. (Ik bedrieg door een zeer dichte taal te gebruiken, die het veld verkleint.)

Dit zou het verschil in de kijk op cubicles kunnen verklaren. Misschien hebben de mensen die verantwoordelijk zijn voor faciliteiten, omdat ze geen concentratie hebben die verstoord kan worden, geen idee dat werken in een cubicle voor een hacker voelt als het hebben van je hersens in een blender. (Terwijl Bill, als de geruchten over autisme waar zijn, maar al te goed weet.)

Een verschil dat ik heb opgemerkt tussen geweldige hackers en slimme mensen in het algemeen, is dat hackers meer politiek incorrect zijn. Voor zover er een geheime handdruk is onder goede hackers, is het wanneer ze elkaar goed genoeg kennen om meningen te uiten die hen door het grote publiek tot de dood zouden veroordelen. En ik kan zien waarom politieke incorrectheid een nuttige eigenschap zou zijn bij programmeren. Programma's zijn erg complex en, althans in de handen van goede programmeurs, erg vloeiend. In dergelijke situaties is het nuttig om de gewoonte te hebben om aannames te bevragen.

Kun je deze kwaliteiten cultiveren? Ik weet het niet. Maar je kunt ze in ieder geval niet onderdrukken. Dus hier is mijn beste poging tot een recept. Als het mogelijk is om jezelf een geweldige hacker te maken, is de manier om dat te doen misschien door de volgende deal met jezelf te sluiten: je hoeft nooit aan saaie projecten te werken (tenzij je familie anders verhongert), en in ruil daarvoor sta je jezelf nooit toe om een halfslachtig werk te doen. Alle geweldige hackers die ik ken lijken die deal te hebben gesloten, hoewel geen van hen er misschien enige keuze in had.

Noten

[1] Eerlijk gezegd moet ik zeggen dat IBM degelijke hardware maakt. Ik schreef dit op een IBM laptop.

[2] Ze bleken inderdaad gedoemd te zijn. Ze sloten een paar maanden later hun deuren.

[3] Ik denk dat dit is wat mensen bedoelen als ze het over de "zin van het leven" hebben. Op het eerste gezicht lijkt dit een vreemd idee. Het leven is geen expressie; hoe zou het een zin kunnen hebben? Maar het kan een kwaliteit hebben die veel op zin lijkt. In een project als een compiler moet je veel problemen oplossen, maar de problemen vallen allemaal in een patroon, als in een signaal. Terwijl wanneer de problemen die je moet oplossen willekeurig zijn, ze als ruis lijken.

[4] Einstein werkte op een gegeven moment aan het ontwerpen van koelkasten. (Hij had aandelen.)

[5] Het is moeilijk om precies te zeggen wat onderzoek inhoudt in de computerwereld, maar als eerste benadering is het software die geen gebruikers heeft.

Ik denk niet dat publicatie de reden is waarom de beste hackers in onderzoeksafdelingen willen werken. Ik denk dat het voornamelijk is dat ze geen driegesprek hoeven te hebben met een productmanager over problemen met het integreren van de Koreaanse versie van Word 13.27 met de pratende paperclip.

[6] Iets soortgelijks gebeurt al heel lang in de bouwsector. Toen je een paar honderd jaar geleden een huis liet bouwen, bouwden de lokale aannemers alles erin. Maar steeds vaker assembleren aannemers componenten die door iemand anders zijn ontworpen en geproduceerd. Dit heeft, net als de komst van desktop publishing, mensen de vrijheid gegeven om op rampzalige manieren te experimenteren, maar het is zeker efficiënter.

[7] Google is veel gevaarlijker voor Microsoft dan Netscape was. Waarschijnlijk gevaarlijker dan welk bedrijf dan ook ooit is geweest. Niet in de laatste plaats omdat ze vastbesloten zijn te vechten. Op hun vacaturepagina zeggen ze dat een van hun "kernwaarden" is "Don't be evil." Van een bedrijf dat sojaolie of mijnbouwapparatuur verkoopt, zou zo'n verklaring slechts excentriek zijn. Maar ik denk dat wij allemaal in de computerwereld herkennen waar dit een oorlogsverklaring aan is gericht.

Dank aan Jessica Livingston, Robert Morris en Sarah Harlin voor het lezen van eerdere versies van deze lezing.