I Grandi Hacker

Questa è la traduzione, pubblicata con il suo consenso, di un saggio di Paul Graham (Great Hackers)
Un ringraziamento ad Orlando, Ombretta e Stefano per il peer review: l’aiuto e` loro, ma le parti brutte sono mie — nel caso aveste suggerimenti, mandatemi una mail.
La pubblico oggi, come per celebrare il compleanno numero 35 di Internet. :)

I Grandi hacker

Luglio 2004

(Questo saggio deriva da un talk tenuto ad Oscon 2004)

Pochi mesi fa ho finito un nuovo libro, e continuo a notare nelle recensioni parole come "provocante" e "controverso". Per tacere di "idiota".

Non volevo che il libro risultasse controverso. Stavo cercando di renderlo efficiente: non voglio far perdere tempo alla gente raccontando loro cose che già sanno, è più efficiente fornire loro le differenze, ma suppongo che questo renda il libro allarmante.

Gli Edison

Non c’è dubbio su quale idea sia più controversa: il suggerimento che la variazione di ricchezza possa non essere un problema così grande come pensiamo.

Nel libro non ho detto che la variazione di ricchezza sia una buona cosa in se. Ho detto che in alcune situazioni potrebbe essere segno di qualcosa di buono. Un violento mal di testa non è una cosa buona, ma potrebbe essere segnale di qualcosa di positivo — per esempio, che state tornando coscienti dopo essere stati colpiti in testa.

Una variazione di ricchezza può essere il segno di una variazione di produttività (in una società di una persona, sono identiche). E quello è quasi certamente un buon segno: se la vostra società non ha alcuna variazione di produttività, è probabilmente perché non tutti sono Thomas Edison. Probabilmente è perché non avete nessun Thomas Edison.

In una società a basso contenuto di tecnologia non vedrete una gran variazione di produttività. Se avete una tribù di nomadi che raccoglie legna per il fuoco, quanto sarà più produttivo il miglior raccoglitore rispetto al peggiore? Un fattore di due? Quando invece date alle persone uno strumento complesso come un computer, la variazione in quello che ci possono fare è enorme.

Non è un’idea nuova. Fred Brooks ne parlava nel 1974, e lo studio che citava era stato pubblicato nel 1968. Ritengo però che avesse sottostimato la variazione tra i programmatori; Brooks scriveva della produttività in linee di codice: i migliori programmatori possono risolvere un dato problema in un decimo del tempo. Ma cosa succede se il problema non è dato? Nella programmazione, come in molti campi, la parte difficile non è tanto risolvere i problemi, quanto decidere quale problema risolvere. L’immaginazione è difficile da misurare, ma in pratica determina la produttività che viene misurata in linee di codice.

La produttività varia in ogni campo, ma ce ne sono alcuni in cui varia moltissimo. La variazione tra i programmatori è talmente grande che diventa una differenza di classe. Non credo che sia qualcosa di intrinseco alla programmazione, perché in ogni campo la tecnologia moltiplica le differenze di produttività. Penso che quello che sta accadendo nella programmazione sia semplicemente che abbiamo una grande leva tecnologica, ed in ogni campo la leva stia diventando sempre più lunga: la variazione che stiamo vedendo ora è qualcosa che sempre più campi vedranno man mano che passa il tempo. Il successo delle aziende, e delle nazioni, dipenderà sempre più da come si confronteranno con questo.

Se la variazione di produttività aumenta con la tecnologia, allora il contributo degli individui più produttivi non sarà solamente ampio in modo sproporzionato, ma aumenterà con il passare del tempo. Quando si arriva al punto in cui il 90% del prodotto di un gruppo viene creato dall’ 1% dei suoi membri, se qualcosa (le invasioni vichinghe, o la pianificazione centralizzata) abbassa la loro produttività verso la media è una tragedia.

Se vogliamo ottenere il massimo da loro, dobbiamo capire queste persone così produttive. Cosa li motiva? Di cosa hanno bisogno per fare il loro lavoro? Come li si riconosce? Come li si convince a venire a lavorare per noi? E poi ovviamente c’è la Domanda: come si diventa uno di loro?

Più del denaro

Conosco una manciata di super-hacker, così mi sono seduto a pensare cosa potessero avere in comune. Ciò che li contraddistingue probabilmente è il loro amore per la programmazione. I programmatori comuni scrivono codice per pagare le bollette. I grandi hacker pensano alla programmazione come qualcosa che fanno per divertimento, e sono deliziati dal trovare qualcuno che li paga per farlo.

A volte si dice che i grandi programmatori siano indifferenti al denaro. Non è vero. E` vero che l’unica cosa che interessa loro è fare un lavoro interessante. Ma se guadagnate abbastanza, riuscirete a lavorare su qualunque cosa vogliate, ed è quella la ragione per cui gli hacker sono attratti dall’idea di guadagnare grandi somme di denaro. Ma finché devono presentarsi al lavoro tutti i giorni sono più interessati a cosa devono fare che a quanto vengono pagati per farlo.

Dal punto di vista economico questo fatto è di una enorme importanza, dato che significa che non dovrete assolutamente pagare i grandi hacker quello che valgono. Un grande programmatore potrebbe essere dieci o cento volte più produttivo di uno comune, ma si sentirà già fortunato ad essere pagato tre volte tanto. Come spiegherò più avanti, questo è dovuto parzialmente al fatto che i grandi hacker non sanno quanto sono bravi. Ma è anche perché il denaro non è la cosa che desiderano di più.

Cosa vogliono gli hacker? Come a tutti gli artigiani, agli hacker piacciono i buoni strumenti. In realtà, la questione è limitativa, descritta in questi termini: sarebbe meglio dire che i buoni hacker trovano insopportabile usare cattivi strumenti. Semplicemente si rifiuteranno di lavorare su progetti con l’infrastruttura sbagliata.

In una startup per cui ho lavorato una volta, una delle cose appese in bacheca era una pubblicità di IBM. Raffigurava un AS400, ed il titolo credo dicesse "gli hacker lo detestano"[1].

Quando decidete quale infrastruttura utilizzare per un progetto, non state semplicemente prendendo una decisione tecnica. State prendendo anche una decisione sociale, e potrebbe essere la più importante delle due. Per esempio, se la vostra compagnia vuole scrivere un software, potrebbe sembrare una scelta prudente farlo in Java. Ma quando scegliete un linguaggio state anche scegliendo una comunità. I programmatori che potrete assumere per lavorare su un progetto in Java non saranno così svegli come quelli che potreste avere per lavorare su un progetto in Python. E la qualità dei vostri hacker conta probabilmente di più del linguaggio che scegliete. Anche se, francamente, il fatto che i buoni hacker preferiscano Python a Java dovrebbe dirvi qualcosa in merito a questi due linguaggi.

Chi ha un approccio commerciale tende a preferire i linguaggi più popolari perché li vedono come degli standard. Non vogliono scommettere la loro azienda sul Betamax. Il problema con i linguaggi, però, è che non sono semplicemente degli standard. Se dovete spostare bit in una rete, è ovvio che userete TCP/IP. Ma un linguaggio di programmazione non è semplicemente un formato. Un linguaggio è un mezzo di espressione.

Ho letto che Java ha sorpassato Cobol come il linguaggio più popolare. Come standard, non potreste desiderare di meglio. Ma come mezzo di espressione si può fare molto meglio. Di tutti i grandi programmatori che conosco solamente uno programmerebbe volentieri in Java. Ma tra tutti i grandi programmatori che mi vengono in mente che non lavorano per Sun su Java, neanche uno.

I grandi hacker generalmente insistono anche per usare software open source. Non solo perché è meglio, ma perché da loro più controllo. I buoni hacker insistono sul controllo, è una parte di quello che li rende buoni hacker: quando qualcosa non va, sentono il bisogno di sistemarlo. Quello che volete è che abbiano lo stesso approccio al software che stanno scrivendo per voi. Non dovreste essere sorpresi quando si sentono nello stesso modo nei confronti del sistema operativo.

Un paio di anni fa un amico investitore mi raccontò di una nuova startup nella quale era coinvolto. Sembrava promettente, ma la volta successiva che gli parlai disse che avevano deciso di scrivere il loro software su Windows NT, e che avevano appena assunto uno sviluppatore NT molto esperto come responsabile tecnico. Quando sentii questo pensai "questi sono condannati". Primo, il responsabile non poteva essere un grande hacker, perché per diventare un brillante sviluppatore NT avrebbe dovuto utilizzare NT volontariamente e più volte, e non riesco ad immaginare un grande hacker farlo; secondo, anche se fosse stato bravo avrebbe avuto i suoi problemi ad assumere qualcuno bravo a lavorare per lui visto che il progetto doveva essere sviluppato su NT.[2]

L’ultima frontiera

Dopo il software il più importante strumento di un hacker è probabilmente il suo ufficio. Le grandi compagnie pensano che la dimensione degli uffici abbia lo scopo di rappresentare la gerarchia. Ma gli hacker usano il loro ufficio per più di questo: per loro l’ufficio è un posto dove pensare. E se siete una società di tecnologia, i loro pensieri sono il vostro prodotto. E` per questo motivo che far lavorare gli hacker in un ambiente rumoroso e pieno di distrazioni è come avere una fabbrica di vernici dove l’aria è piena di fuliggine.

I fumetti di Dilbert hanno molto da dire sui cubicoli, e con buona ragione. Tutti gli hacker che conosco li detestano. La semplice prospettiva di venire interrotti è sufficiente a scoraggiarli dal lavorare su problemi difficili. Se si vuole riuscire a fare del lavoro vero in un ufficio con i cubicoli, ci sono due opzioni: lavorare a casa, o arrivare presto/tardi/nel fine settimana, quando non c’è in giro nessuno. Le aziende non si rendono conto che questo è il segno che c’è qualcosa che non va? Ci si aspetta che l’ambiente dell’ufficio sia un posto dove lavorare, non dove lavorare nonostante tutto.

Le aziende come Cisco sono orgogliose del fatto che chiunque abbia un cubicolo, persino il CEO. Ma non sono cosi avanti come pensano; ovviamente vedono ancora lo spazio in ufficio come un segno del rango. Da notare che Cisco è famosa per fare molto poco sviluppo dei prodotti in casa. Ottengono nuova tecnologia comprando le startup che l’hanno creata — dove si presume che gli hacker avessero un posto tranquillo dove lavorare.

Una grande azienda che capisce di cosa abbiano bisogno gli hacker è Microsoft. Una volta vidi una pubblicità per l’assunzione con una grande foto di una porta. Lavora per noi, era la premessa, e noi ti daremo un posto di lavoro dove lavorare sul serio. E sapete, Microsoft è particolare tra le grandi aziende, nel senso che sanno sviluppare software in casa. Non bene, magari, ma abbastanza bene.

Se le aziende vogliono che gli hacker siano produttivi, devono guardare a cosa fanno a casa. A casa, gli hacker possono sistemarsi le cose in modo da fare il massimo. Quando sono a casa, gli hacker non lavorano in open space rumorosi; lavorano in stanze, con le porte. Lavorano in posti confortevoli e raccolti con gente intorno e un posto dove camminare quando devono riflettere, non in scatole di vetro in mezzo a chilometri quadrati di parcheggi. Hanno un divano su cui fare un pisolino quando sono stanchi, invece che stare seduti in coma alla propria scrivania facendo finta di lavorare. Non ci sono gruppi di persone con aspirapolveri che ruggiscono ogni sera, durante le prime ore utili per l’hacking. Non ci sono riunioni o (Dio ci scampi!) ritiri aziendali, o esercizi per compattare i gruppi. E quando guardate cosa fanno sul loro computer, quello che vedete rafforza quello che dicevo in precedenza a proposito degli strumenti. Possono dover usare Windows e Java al lavoro, ma a casa, dove possono scegliere in autonomia, è più probabile che li troviate ad usare Perl e Linux.

In effetti, queste statistiche sulla popolarità di Cobol o Java possono indurre in errore. Quello che dovremmo guardare, se volessimo sapere quali sono gli strumenti migliori, è cosa scelgono gli hacker quando sono liberi di farlo — cioè per i loro progetti. Quando vi fate questa domanda ciò che scoprite è che i sistemi operativi open source hanno una parte dominante del mercato e che il linguaggio numero uno è probabilmente Perl.

Interessante

Insieme a buoni strumenti, gli hacker vogliono progetti interessanti. Cosa rende interessante un progetto? Beh, ovviamente è interessante lavorare su applicazioni chiaramente fighe come aerei fantasma o software per effetti speciali, ma ogni applicazione può essere interessante se propone sfide tecniche nuove. Per questo è difficile predire quali problemi piaceranno agli hacker, perché alcuni diventano interessanti solamente quando la gente che ci lavora scopre un nuovo tipo di soluzione. Prima della ITA (che ha scritto il software dietro a Orbitz), la gente che lavorava alle ricerche delle tariffe aeree probabilmente pensava fosse una delle applicazioni più noiose che si potessero immaginare. La ITA però l’ha resa interessante ridefinendo il problema in modo più ambizioso.

Penso che a Google sia accaduta la stessa cosa: quando è stata fondata il pensiero comune tra i cosiddetti portali era che la ricerca fosse noiosa e poco importante. I ragazzi in Google non pensavano che fosse noiosa, ed è il motivo per cui la fanno cosí bene.

Questa è un’area dove i manager possono fare la differenza. Come i genitori dicono ad un figlio "scommetto che non puoi sistemare la tua stanza in 10 minuti", un buon manager a volte può ridefinire un problema in modo più interessante. Pare che Steve Jobs sia particolarmente bravo in questo, in parte avendo semplicemente alti standard. C’erano un sacco di computer piccoli ed economici prima del Mac. Lui ha ridefinito il problema così: facciamone uno bellissimo. Questo ha spinto gli sviluppatori più di quanto qualsiasi bastone o carota potessero fare.

Ce l’hanno sicuramente fatta. Quando apparve il primo Mac, non dovevate accenderlo per sapere che era un buon prodotto, potevate dirlo dal case. Poche settimane fa stavo camminando per la strada a Cambridge, ed ho visto nella spazzatura quello che sembrava essere il contenitore per il trasporto di un Mac. Ci ho guardato dentro, e c’era un Mac SE. L’ho portato a casa e attaccato all’alimentazione, ed è partito. La faccina felice Macintosh, e poi il Finder. Mio Dio, è stato così semplice… è stato come… Google.

Agli hacker piace lavorare per gente con standard alti. Peró essere esigenti non è abbastanza. Dovete insistere sulle cose giuste, il che di solito significa che dovete essere un hacker anche voi. Ho visto svariati articoli su come gestire i programmatori, ma in realtà ce ne dovrebbero essere solamente due: uno su come fare se siete un programmatore anche voi, e l’altro se non lo siete. Il secondo potrebbe probabilmente condensato in una parola: rinunciate.

Il problema non è tanto nella gestione quotidiana, gli hacker veramente bravi si gestiscono praticamente da soli. Il problema è che se non siete un hacker non potete capire chi sono i bravi hacker. Un problema simile spiega perché le macchine americane siano cosi brutte. Io lo chiamo il "paradosso del design". Potete credere di poter fare prodotti bellissimi semplicemente assumendo un grande designer per progettarli, ma se non avete buon gusto come pensate di riconoscere un buon designer? Per definizione, non potete giudicare dai suoi lavori passati. Non potete giudicare nemmeno dai premi che ha vinto o dei lavori che ha fatto – dato che il design, come molti campi, è guidato prima dalla moda e dal passaparola e solo molto dopo dalla effettiva abilità. Non c’è modo di aggirare il problema: non potete gestire un processo che deve produrre cose bellissime senza sapere cosa sia il bello. Le auto americane sono brutte perché le case automobilistiche americane sono guidate da persone con cattivo gusto.

Molte persone in questo paese [gli Stati Uniti, NdT] pensano al buon gusto come qualcosa di elusivo, o addirittura frivolo. Non è nessuna delle due cose. Per orientare il design un manager deve essere l’utente più esigente dei prodotti aziendali. E se avete ottimo gusto potete, come Steve Jobs, trarre soddisfazione dal tipo di problemi a cui quelli bravi amano dedicarsi.

Piccoli problemi fastidiosi

E` abbastanza facile dire quali siano i problemi non interessanti: quelli dove invece che risolvere pochi problemi grandi e chiari bisogna risolverne tanti piccoli. Uno dei progetti peggiori tipicamente è scrivere un’interfaccia ad un software che è pieno di bug. Un altro è dover personalizzare qualcosa per i bisogni confusi e mal definiti del cliente. Per gli hacker questo tipo di progetti sono una morte lenta.

La caratteristica distintiva dei piccoli problemi fastidiosi è che non si impara nulla da loro. Scrivere un compilatore è interessante perché permette di capire cosa sia un compilatore. Ma scrivere un’interfaccia ad un software malfunzionante non fa imparare nulla, perché i bug sono casuali.[3] Non è il fastidio che spinge i buoni hacker ad evitare i piccoli problemi fastidiosi, ma l’autoconservazione. Lavorare su problemi piccoli e fastidiosi rende stupidi. I buoni hacker li evitano per lo stesso motivo per cui le modelle evitano McDonald’s.

In alcuni problemi, ovviamente, questa caratteristica è intrinseca – e per via della legge sulla domanda e l’offerta, pagano particolarmente bene. Un’azienda che riuscisse a trovare un modo di spingere i grandi hacker a lavorare su problemi noiosi avrebbe grande successo. Come fare?

Uno dei posti dove questo accade è nelle startup. Nella nostra abbiamo avuto Robert Morris come amministratore di sistema. è come avere i Rolling Stones a suonare alla festa della Cresima: non potete assumere quel tipo di talento. Ma gli individui faranno ogni genere di orribile lavoro per un’azienda di cui sono i fondatori.[4]

Le aziende più grandi risolvono il problema separando i reparti. Trattengono la gente valida creando dipartimenti di ricerca e sviluppo dove gli impiegati non devono lavorare direttamente sui piccoli problemi fastidiosi dei clienti.[5] In questo modello, i dipartimenti di ricerca funzionano come una miniera. Producono nuove idee; forse il resto dell’azienda riuscirà ad usarle.

Magari non c’è bisogno di arrivare a questi estremi. La programmazione ‘bottom-up‘ suggerisce un altro modo di dividere l’azienda: far produrre alla gente valida gli strumenti. Se la vostra azienda produce un software per fare la cosa X, si può costruire un gruppo che scrive strumenti software di quel tipo e un altro che usa questi strumenti per scrivere le applicazioni. In questo modo potreste riuscire a far scrivere alle persone sveglie il 99% del vostro codice, però tenendole separate dagli utenti quanto lo sarebbero in un dipartimento di ricerca tradizionale. Gli sviluppatori di strumenti avrebbero i loro utenti, ma sarebbero soltanto gli altri sviluppatori interni all’azienda.[6]

Se Microsoft usasse questo approccio, il loro software non sarebbe pieno di buchi di sicurezza, perché un numero inferiore di persone valide che scrivono le applicazioni farebbe lavori di basso livello come allocare memoria. Invece che scrivere Word direttamente in C, incastrerebbero grandi blocchi di Lego in linguaggio-Word. (Credo che il termine tecnico sia Duplo).

Ammassi

Insieme ai problemi interessanti, quello che piace agli hacker sono gli altri buoni hacker. I grandi hacker tendono ad ammassarsi, a volte in modo spettacolare come allo Xerox Parc. Per questo non attrarrete hacker in modo linearmente proporzionale all’ambiente che creerete per loro. La tendenza all’aggregazione porta a credere che sia più dipendente dalla radice quadrata dell’ambiente, quindi è una situazione dove il vincitore prende tutto. In ogni istante, ci sono solamente una decina o una ventina di posti dove gli hacker vorrebbero lavorare, e se il vostro non è uno di questi non avrete solamente meno grandi hacker. Non ne avrete nessuno.

Avere validi hacker non è un motivo sufficiente da solo a rendere la vostra una azienda di successo. Funziona bene per Google o la ITA, che sono i punti caldi di questo momento, ma nel passato non ha aiutato la Thinking Machines o la Xerox. La Sun ha avuto un buon successo per un po’, ma il loro modello di business è un ascensore verso il basso: in quella situazione non ti possono salvare neanche i migliori hacker.

Penso però che a parità di condizioni, una società che possa attrarre validi hacker avrà un grande vantaggio. Ci sono persone che non condividono questa visione: quando stavamo cercando finanziamenti negli anni ’90 molti ci dissero che le aziende di software non si imponevano scrivendo grande software, ma attraverso il marchio, la dominazione dei canali e facendo gli accordi giusti.

Pare ci credessero veramente, e penso di sapere perché. Perché quello che un sacco di finanziatori stanno cercando, almeno inconsciamente, è la prossima Microsoft. Ovviamente se Microsoft è il vostro modello non state cercando aziende che sperano di avere successo scrivendo grande software. Il problema è che i finanziatori sbagliano a cercare la prossima Microsoft, perché nessuna startup lo potrà essere a meno che qualche altra compagnia non sia disposta a piegarsi al momento giusto e diventare la prossima IBM.

E` un errore usare Microsoft come modello, perché la loro intera cultura deriva da un solo colpo fortunato. Microsoft è fuori dalla media, se la eliminate vi renderete conto che sono i buoni prodotti tendono ad avere successo sul mercato. Quello che gli investitori dovrebbero cercare è la prossima Apple, oppure la prossima Google.

Credo che Bill Gates sappia tutto questo; quello che lo spaventa di Google non è la potenza del loro marchio, ma il fatto che ha hacker migliori.[7]

Riconoscimento

Quindi chi sono i grandi hacker? Come capite quando ne incontrate uno? Questo è un problema davvero difficile, persino gli hacker non lo sanno. Sono abbastanza sicuro che il mio amico Trevor Blackwell sia un grande hacker. Forse avete letto su Slashdot come si è costruito la sua Segway.

La parte notevole del progetto è che si è scritto tutto il software in un giorno (in Python, incidentalmente). Per Trevor è normale. Quando lo incontrai per la prima volta però mi sembrò un idiota totale. Era nell’ufficio di Robert Morris balbettando cose senza senso, e ricordo che stavo dietro di lui facendo gesti disperati a Robert di scacciare questo scemo dal suo ufficio così che potessimo andare a pranzo. Anche Robert dice che l’aveva giudicato male all’inizio: pare che quando lo incontrò per la prima volta, Trevor avesse appena iniziato a scrivere ogni aspetto della sua vita su un pacco di schede che portava sempre con sé. Era anche appena arrivato dal Canada, aveva un forte accento e portava il mullet.

Il problema è complicato dal fatto che gli hacker, nonostante la loro reputazione di indifferenza per le regole sociali, a volte mettono un sacco di impegno nel sembrare vincenti. Quando ero all’università bazzicavo dalle parti del laboratorio di Intelligenza Artificiale del MIT, e all’inizio ero piuttosto intimidito: tutti parlavano velocissimi. Dopo un po’ imparai il trucco: non è necessario pensare più velocemente, basta usare il doppio delle parole per dire qualunque cosa.

Con questa quantità di rumore rispetto al segnale è difficile riconoscere i grandi hacker quando li si incontra. Io non ci riesco neanche adesso; non si può neanche giudicare dai loro curriculum, sembra che l’unico modo sia lavorare assieme a loro su qualcosa.

Questa è la ragione per cui le aree ad alta tecnologia sono concentrate vicino alle università: l’ingrediente non sono tanto i docenti, quanto gli studenti. Le startup nascono vicino alle università perché queste ultime riuniscono persone giovani e promettenti e le fanno lavorare insieme sugli stessi progetti: quelli validi imparano a riconoscersi a vicenda e creano nuovi progetti insieme.

Proprio perché l’unico modo di distinguere un grande hacker è lavorarci insieme, loro stessi non sono in grado di giudicare quanto sono bravi. Questo è vero fino ad un certo punto in molti campi. Ho scoperto che le persone che sono brave in qualcosa, più che essere convinte della loro grandezza sono confuse dal fatto che tutti gli altri sembrano incompetenti. Loro stessi pensano generalmente di essere stupidi e pigri, che il loro cervello funziona nel modo giusto un giorno su dieci, e che è solo questione di tempo prima che li scoprano.

Quello che è particolarmente difficile è scoprire quanto bravi siano perché è difficile confrontare il loro lavoro. In altri campi è molto più semplice: sui 100 metri, il più veloce si scopre in 10 secondi. Anche in matematica sembra esserci un consenso comune su quali siano i problemi di difficile soluzione e di cosa sia una buona soluzione. Ma l’hacking è come la scrittura, chi può dire quale sia il migliore di due romanzi? Sicuramente non gli autori.

Tra gli hacker, almeno, altri hacker possono giudicare. Questo perché al contrario degli scrittori, gli hacker collaborano sui progetti, e quando si butta qualche problema difficile al di là dalla rete, si impara piuttosto in fretta quanto duramente torna indietro. Però gli hacker non riescono a guardarsi al lavoro, quindi quando chiedete ad un grande hacker quanto bravo sia, quasi certamente vi risponderà che non lo sa. Non sta semplicemente facendo il modesto. Non lo sa veramente.

Non lo sa nessuno di noi, a parte di gente con la quale abbiamo lavorato. Questo ci mette in una strana situazione: non sappiamo chi debbano essere i nostri eroi. Gli hacker che diventano famosi tendono a diventarlo per strani casi di pubbliche relazioni. Quando devo fare un esempio di un grande hacker, non so mai chi usare. I primi nomi che mi vengono in mente tendono ad essere quelli di persone che conosco personalmente, però è brutto citarli. Così, penso, magari devo citare Richard Stallman, o Linus Torvalds, o Alan Kay, o qualcuno di famoso come loro. Però non ho idea se queste persone siano grandi hacker, non ho mai lavorato con loro su nulla.

Se esiste un Michael Jordan dell’hacking nessuno lo sa, compreso lui.

Coltivazione

Infine, la domanda che tutti gli hacker si sono fatti: come si diventa un grande hacker? Non so se sia possibile diventarlo. Quello che so di certo è che certamente si possono fare cose che ti rendono stupido, e se puoi renderti stupido, ti puoi anche rendere intelligente.

La chiave per essere un buon hacker potrebbe essere nel lavorare su quello che ci piace. Quando penso ai grandi hacker che conosco, una cosa che hanno in comune è l’estrema difficoltà nel farli lavorare su qualcosa quando non vogliono. Non so se questa sia la causa o l’effetto; potrebbe essere entrambi.

Per fare qualcosa bene bisogna amarla. Perciò finché potete preservare l’hacking come qualcosa che amate, è probabile che lo farete bene. Cercate di mantenere il senso di stupore che avevate per la programmazione a 14 anni. Se siete preoccupati che il vostro attuale lavoro vi stia facendo marcire il cervello, probabilmente è vero.

I migliori hacker tendono ad essere intelligenti, naturalmente, ma questo è vero in molti campi. C’è una qualche qualità che è unica degli hacker? Ho chiesto ad alcuni amici, e la prima cosa che hanno menzionato tutti è stata la curiosità. Ho sempre immaginato che la gente sveglia fosse curiosa – quella curiosità è semplicemente la derivata prima della conoscenza. Però apparentemente gli hacker sono particolarmente curiosi, specialmente di come funzionano le cose. In effetti ha senso, visto che i programmi sono in effetti grandi descrizioni di come funzionano le cose.

Diversi amici hanno citato l’abilità degli hacker di concentrarsi, l’abilità, come qualcuno l’ha definita, di "spegnere tutto quello che è fuori dalle loro teste". Questo l’ho notato sicuramente. Ho anche sentito svariati hacker sostenere che non sanno più programmare anche solo dopo aver bevuto mezza birra. L’hacking quindi richiede forse una speciale abilità di concentrazione. Forse i grandi hacker riescono a caricare una grande quantità di contesto nella loro testa, così che quando guardano una linea di codice non vedono solamente quella linea, ma l’intero programma intorno ad essa. John McPhee scrisse che il successo di Bill Bradley nella pallacanestro era dovuto parzialmente alla sua straordinaria visione periferica. Una vista "perfetta" significa avere circa 47 gradi di visione periferica verticale. Bill Bradley ne aveva 70: poteva vedere il canestro quando stava guardando il pavimento. Forse i grandi hacker hanno una simile innata abilità. (Baro, usando un linguaggio molto denso cio che è dato per scontato.)

Potete coltivare queste qualità? Non saprei. Però potete almeno non reprimerle. Questo è il mio migliore tentativo per darvi una ricetta; se è possibile diventare grandi hacker, il modo di farlo potrebbe essere fare questo patto con voi stessi: non dovrete mai lavorare su progetti noiosi (a meno che la vostra famiglia non muoia di fame altrimenti) e in cambio non vi permetterete mai di fare un lavoro a metà. Tutti i grandi hacker che conosco pare abbiano accettato questo patto, anche se forse nessuno di loro ha avuto la possibilità di scegliere.

Note

  1. In verità, devo dire che l’IBM costruisce dell’hardware decente. Ho scritto questo saggio su un portatile IBM. [e sullo stesso hardware e` stato tradotto, NdT]
  2. Si scoprì che lo erano. Chiusero pochi mesi più tardi.
  3. Credo che sia questo ciò che la gente intende quando parlano del "significato della vita". Facendoci caso, pare una strana idea. La vita non è un’espressione: come potrebbe avere un significato? Però potrebbe avere una qualità che assomiglia molto ad un significato. In un progetto come un compilatore, sarà necessario risolvere un sacco di problemi, ma tutti ricadranno in uno schema, come un segnale. Al contrario, quando i problemi che andranno risolti saranno casuali, sembreranno rumore.
  4. Einstein ad un certo punto lavorò disegnando frigoriferi (aveva delle azioni).
  5. è difficile dire cosa esattamente costituisca ricerca nel mondo dei computer, ma come prima approssimazione è il software che non ha utenti.
  6. Non credo che sia la sua pubblicazione che fa desiderare agli hacker di lavorare nei laboratori di ricerca. Credo che sia principalmente il non dover andare in riunione per tre ore con un product manager a parlare dei problemi di integrazione della graffetta parlante con la versione 13.27 di Word in coreano.
  7. Qualcosa di simile è accaduta per molto tempo nell’industria delle costruzioni. In una casa costruita duecento anni fa, i costruttori integravano tutto. Con il passare del tempo i costruttori assemblano sempre più componenti disegnati e realizzati da qualcun altro. Questo, come l’arrivo del desktop publishing, ha dato alla gente la libertà di sperimentare in modi disastrosi, però è certamente più efficiente.
  8. Google è molto più pericoloso per Microsoft di quanto non fosse Netscape. Probabilmente più pericoloso di quanto non sia mai stata nessuna altra compagnia, ma non perché siano determinati a combattere. Sulla pagina con le offerte di lavoro, dicono che uno dei loro valori chiave è "Don’t be evil" ["non essere cattivi" NdT]. In un’azienda che vendesse olio di soia o attrezzi da miniera, un’affermazione di questo tipo sarebbe quanto meno eccentrica. Credo però che tutti noi nel mondo dei computer sappiamo riconoscere per chi possa essere una dichiarazione di guerra simile. [Microsoft è nota anche come "The Evil Empire", ovvero l'Impero del Male - NdT].