Les Grands Hackers | Essais de Paul Graham

Envie de lancer une startup ? Faites-vous financer par Y Combinator.

Juillet 2004

(Cet essai est tiré d'une conférence donnée à Oscon 2004.)

Il y a quelques mois, j'ai terminé un nouveau livre, et dans les critiques, je ne cesse de remarquer des mots comme « provocateur » et « controversé ». Sans parler de « stupide ».

Je n'avais pas l'intention de rendre le livre controversé. J'essayais de le rendre efficace. Je ne voulais pas faire perdre leur temps aux gens en leur racontant des choses qu'ils savaient déjà. Il est plus efficace de leur donner simplement les diffs. Mais je suppose que cela est voué à produire un livre alarmant.

Edisons

Il n'y a pas de controverse sur l'idée la plus controversée : la suggestion que la variation de la richesse pourrait ne pas être un problème aussi important que nous le pensons.

Je n'ai pas dit dans le livre que la variation de la richesse était en soi une bonne chose. J'ai dit que dans certaines situations, cela pouvait être le signe de bonnes choses. Un mal de tête lancinant n'est pas une bonne chose, mais cela peut être le signe d'une bonne chose – par exemple, que vous reprenez connaissance après avoir reçu un coup sur la tête.

La variation de la richesse peut être le signe d'une variation de la productivité. (Dans une société d'un seul individu, elles sont identiques.) Et cela est presque certainement une bonne chose : si votre société n'a aucune variation de productivité, ce n'est probablement pas parce que tout le monde est Thomas Edison. C'est probablement parce que vous n'avez pas de Thomas Edison.

Dans une société peu technologique, on ne voit pas beaucoup de variation de productivité. Si vous avez une tribu de nomades ramassant des bâtons pour un feu, à quel point le meilleur ramasseur de bâtons sera-t-il plus productif que le pire ? Un facteur de deux ? Alors que lorsque vous donnez aux gens un outil complexe comme un ordinateur, la variation de ce qu'ils peuvent en faire est énorme.

Ce n'est pas une idée nouvelle. Fred Brooks en a parlé en 1974, et l'étude qu'il a citée a été publiée en 1968. Mais je pense qu'il a sous-estimé la variation entre les programmeurs. Il a écrit sur la productivité en lignes de code : les meilleurs programmeurs peuvent résoudre un problème donné en un dixième du temps. Mais que se passe-t-il si le problème n'est pas donné ? En programmation, comme dans de nombreux domaines, le plus difficile n'est pas de résoudre les problèmes, mais de décider quels problèmes résoudre. L'imagination est difficile à mesurer, mais en pratique, elle domine le type de productivité mesurée en lignes de code.

La productivité varie dans tous les domaines, mais il y en a peu où elle varie autant. La variation entre les programmeurs est si grande qu'elle devient une différence de nature. Je ne pense pas que ce soit quelque chose d'intrinsèque à la programmation, cependant. Dans tous les domaines, la technologie amplifie les différences de productivité. Je pense que ce qui se passe en programmation, c'est simplement que nous avons un grand levier technologique. Mais dans tous les domaines, le levier s'allonge, de sorte que la variation que nous observons est quelque chose que de plus en plus de domaines verront avec le temps. Et le succès des entreprises et des pays dépendra de plus en plus de la manière dont ils y feront face.

Si la variation de productivité augmente avec la technologie, alors la contribution des individus les plus productifs sera non seulement disproportionnellement grande, mais augmentera réellement avec le temps. Lorsque vous atteignez le point où 90 % de la production d'un groupe est créée par 1 % de ses membres, vous perdez énormément si quelque chose (que ce soient des raids vikings ou une planification centrale) ramène leur productivité à la moyenne.

Si nous voulons en tirer le meilleur parti, nous devons comprendre ces personnes particulièrement productives. Qu'est-ce qui les motive ? De quoi ont-ils besoin pour faire leur travail ? Comment les reconnaître ? Comment les amener à venir travailler pour vous ? Et puis bien sûr, il y a la question : comment en devenir un ?

Plus que de l'argent

Je connais une poignée de super-hackers, alors je me suis assis et j'ai réfléchi à ce qu'ils ont en commun. Leur qualité distinctive est probablement qu'ils aiment vraiment programmer. Les programmeurs ordinaires écrivent du code pour payer les factures. Les grands hackers considèrent cela comme quelque chose qu'ils font pour le plaisir, et ils sont ravis de constater que les gens les paieront pour cela.

On dit parfois que les grands programmeurs sont indifférents à l'argent. Ce n'est pas tout à fait vrai. Il est vrai que tout ce qui les intéresse vraiment est de faire un travail intéressant. Mais si vous gagnez suffisamment d'argent, vous pouvez travailler sur ce que vous voulez, et pour cette raison, les hackers sont attirés par l'idée de gagner de très grandes sommes d'argent. Mais tant qu'ils doivent se présenter au travail tous les jours, ils se soucient plus de ce qu'ils y font que de combien ils sont payés pour cela.

Économiquement, c'est un fait de la plus haute importance, car cela signifie que vous n'avez pas à payer les grands hackers à la hauteur de leur valeur. Un grand programmeur pourrait être dix ou cent fois plus productif qu'un programmeur ordinaire, mais il s'estimera heureux d'être payé trois fois plus. Comme je l'expliquerai plus tard, c'est en partie parce que les grands hackers ne savent pas à quel point ils sont bons. Mais c'est aussi parce que l'argent n'est pas la principale chose qu'ils désirent.

Que veulent les hackers ? Comme tous les artisans, les hackers aiment les bons outils. En fait, c'est un euphémisme. Les bons hackers trouvent insupportable d'utiliser de mauvais outils. Ils refuseront simplement de travailler sur des projets avec une infrastructure inadéquate.

Dans une startup pour laquelle j'ai travaillé, l'une des choses affichées sur notre tableau d'affichage était une publicité d'IBM. C'était une image d'un AS400, et le titre disait, je crois, « les hackers le méprisent. » [1]

Lorsque vous décidez quelle infrastructure utiliser pour un projet, vous ne prenez pas seulement une décision technique. Vous prenez également une décision sociale, et celle-ci est peut-être la plus importante des deux. Par exemple, si votre entreprise veut écrire un logiciel, il pourrait sembler judicieux de l'écrire en Java. Mais lorsque vous choisissez un langage, vous choisissez aussi une communauté. Les programmeurs que vous pourrez embaucher pour travailler sur un projet Java ne seront pas aussi intelligents que ceux que vous pourriez obtenir pour travailler sur un projet écrit en Python. Et la qualité de vos hackers compte probablement plus que le langage que vous choisissez. Bien que, franchement, le fait que les bons hackers préfèrent Python à Java devrait vous dire quelque chose sur les mérites relatifs de ces langages.

Les gens d'affaires préfèrent les langages les plus populaires parce qu'ils considèrent les langages comme des standards. Ils ne veulent pas parier l'entreprise sur Betamax. Le truc avec les langages, cependant, c'est qu'ils ne sont pas seulement des standards. Si vous devez transférer des bits sur un réseau, utilisez absolument TCP/IP. Mais un langage de programmation n'est pas seulement un format. Un langage de programmation est un moyen d'expression.

J'ai lu que Java vient de dépasser Cobol comme langage le plus populaire. En tant que standard, on ne pourrait pas souhaiter mieux. Mais en tant que moyen d'expression, on pourrait faire beaucoup mieux. De tous les grands programmeurs auxquels je peux penser, je n'en connais qu'un seul qui programmerait volontairement en Java. Et de tous les grands programmeurs auxquels je peux penser qui ne travaillent pas pour Sun, sur Java, je n'en connais aucun.

Les grands hackers insistent aussi généralement pour utiliser des logiciels open source. Non seulement parce que c'est mieux, mais parce que cela leur donne plus de contrôle. Les bons hackers insistent sur le contrôle. C'est en partie ce qui en fait de bons hackers : quand quelque chose est cassé, ils ont besoin de le réparer. Vous voulez qu'ils ressentent la même chose pour le logiciel qu'ils écrivent pour vous. Vous ne devriez pas être surpris s'ils ressentent la même chose pour le système d'exploitation.

Il y a quelques années, un ami capital-risqueur m'a parlé d'une nouvelle startup dans laquelle il était impliqué. Cela semblait prometteur. Mais la fois suivante où je lui ai parlé, il a dit qu'ils avaient décidé de construire leur logiciel sur Windows NT, et venaient d'embaucher un développeur NT très expérimenté pour être leur directeur technique (CTO). Quand j'ai entendu cela, j'ai pensé : ces gars sont condamnés. Premièrement, le CTO ne pouvait pas être un hacker de premier ordre, car pour devenir un éminent développeur NT, il aurait dû utiliser NT volontairement, plusieurs fois, et je ne pouvais pas imaginer un grand hacker faire cela ; et deuxièmement, même s'il était bon, il aurait du mal à embaucher quelqu'un de bon pour travailler pour lui si le projet devait être construit sur NT. [2]

La dernière frontière

Après le logiciel, l'outil le plus important pour un hacker est probablement son bureau. Les grandes entreprises pensent que la fonction de l'espace de bureau est d'exprimer le rang. Mais les hackers utilisent leurs bureaux pour plus que cela : ils utilisent leur bureau comme un lieu pour penser. Et si vous êtes une entreprise technologique, leurs pensées sont votre produit. Donc, faire travailler les hackers dans un environnement bruyant et distrayant, c'est comme avoir une usine de peinture où l'air est plein de suie.

La bande dessinée Dilbert a beaucoup à dire sur les cubicles, et avec raison. Tous les hackers que je connais les méprisent. La simple perspective d'être interrompu suffit à empêcher les hackers de travailler sur des problèmes difficiles. Si vous voulez accomplir un travail réel dans un bureau avec des cubicles, vous avez deux options : travailler à la maison, ou venir tôt ou tard, ou le week-end, quand personne d'autre n'est là. Les entreprises ne réalisent-elles pas que c'est le signe que quelque chose ne va pas ? Un environnement de bureau est censé être quelque chose qui vous aide à travailler, pas quelque chose malgré lequel vous travaillez.

Des entreprises comme Cisco sont fières que tout le monde y ait un cubicle, même le PDG. Mais elles ne sont pas aussi avancées qu'elles le pensent ; manifestement, elles considèrent toujours l'espace de bureau comme un insigne de rang. Notez également que Cisco est célèbre pour faire très peu de développement de produits en interne. Ils obtiennent de nouvelles technologies en achetant les startups qui les ont créées – où, vraisemblablement, les hackers avaient un endroit calme pour travailler.

Une grande entreprise qui comprend ce dont les hackers ont besoin est Microsoft. J'ai vu une fois une publicité de recrutement pour Microsoft avec une grande image d'une porte. Travaillez pour nous, était la prémisse, et nous vous donnerons un endroit où vous pourrez réellement travailler. Et vous savez, Microsoft est remarquable parmi les grandes entreprises en ce qu'ils sont capables de développer des logiciels en interne. Pas bien, peut-être, mais suffisamment bien.

Si les entreprises veulent que les hackers soient productifs, elles devraient regarder ce qu'ils font à la maison. À la maison, les hackers peuvent organiser les choses eux-mêmes pour être le plus efficaces possible. Et quand ils travaillent à la maison, les hackers ne travaillent pas dans des espaces bruyants et ouverts ; ils travaillent dans des pièces avec des portes. Ils travaillent dans des endroits confortables, de type quartier, avec des gens autour et un endroit où se promener quand ils ont besoin de réfléchir, au lieu de boîtes de verre situées au milieu d'hectares de parkings. Ils ont un canapé sur lequel ils peuvent faire une sieste quand ils sont fatigués, au lieu de rester dans le coma à leur bureau, faisant semblant de travailler. Il n'y a pas d'équipe de personnes avec des aspirateurs qui rugissent chaque soir pendant les heures de pointe du hacking. Il n'y a pas de réunions ou, Dieu nous en préserve, de séminaires d'entreprise ou d'exercices de team-building. Et quand vous regardez ce qu'ils font sur cet ordinateur, vous constaterez que cela renforce ce que j'ai dit plus tôt sur les outils. Ils peuvent être obligés d'utiliser Java et Windows au travail, mais à la maison, où ils peuvent choisir eux-mêmes, vous êtes plus susceptible de les trouver utilisant Perl et Linux.

En effet, ces statistiques sur Cobol ou Java étant les langages les plus populaires peuvent être trompeuses. Ce que nous devrions regarder, si nous voulons savoir quels sont les meilleurs outils, c'est ce que les hackers choisissent quand ils peuvent choisir librement – c'est-à-dire dans leurs propres projets. Lorsque vous posez cette question, vous constatez que les systèmes d'exploitation open source ont déjà une part de marché dominante, et le langage numéro un est probablement Perl.

Intéressant

Outre de bons outils, les hackers veulent des projets intéressants. Qu'est-ce qui rend un projet intéressant ? Eh bien, évidemment, des applications ouvertement sexy comme les avions furtifs ou les logiciels d'effets spéciaux seraient intéressantes à développer. Mais toute application peut être intéressante si elle pose de nouveaux défis techniques. Il est donc difficile de prédire quels problèmes les hackers aimeront, car certains ne deviennent intéressants que lorsque les personnes qui y travaillent découvrent un nouveau type de solution. Avant ITA (qui a écrit le logiciel à l'intérieur d'Orbitz), les personnes travaillant sur les recherches de tarifs aériens pensaient probablement que c'était l'une des applications les plus ennuyeuses imaginables. Mais ITA l'a rendue intéressante en redéfinissant le problème d'une manière plus ambitieuse.

Je pense que la même chose s'est produite chez Google. Lorsque Google a été fondé, la sagesse conventionnelle parmi les soi-disant portails était que la recherche était ennuyeuse et sans importance. Mais les gars de Google ne pensaient pas que la recherche était ennuyeuse, et c'est pourquoi ils la font si bien.

C'est un domaine où les managers peuvent faire la différence. Comme un parent disant à un enfant : « Je parie que tu ne peux pas nettoyer toute ta chambre en dix minutes », un bon manager peut parfois redéfinir un problème comme étant plus intéressant. Steve Jobs semble être particulièrement doué pour cela, en partie simplement en ayant des standards élevés. Il y avait beaucoup de petits ordinateurs peu coûteux avant le Mac. Il a redéfini le problème comme suit : en faire un qui soit beau. Et cela a probablement poussé les développeurs plus fort que n'importe quelle carotte ou bâton n'aurait pu le faire.

Ils ont certainement livré. Quand le Mac est apparu pour la première fois, vous n'aviez même pas besoin de l'allumer pour savoir qu'il serait bon ; vous pouviez le dire d'après son boîtier. Il y a quelques semaines, je marchais dans la rue à Cambridge, et dans les poubelles de quelqu'un, j'ai vu ce qui semblait être une sacoche de transport Mac. J'ai regardé à l'intérieur, et il y avait un Mac SE. Je l'ai ramené à la maison et l'ai branché, et il a démarré. Le visage heureux du Macintosh, puis le Finder. Mon Dieu, c'était si simple. C'était juste comme... Google.

Les hackers aiment travailler pour des gens avec des standards élevés. Mais il ne suffit pas d'être exigeant. Il faut insister sur les bonnes choses. Ce qui signifie généralement que vous devez être un hacker vous-même. J'ai vu des articles occasionnels sur la façon de gérer les programmeurs. En réalité, il devrait y avoir deux articles : un sur ce qu'il faut faire si vous êtes vous-même programmeur, et un sur ce qu'il faut faire si vous ne l'êtes pas. Et le second pourrait probablement être condensé en deux mots : abandonnez.

Le problème n'est pas tant la gestion quotidienne. Les très bons hackers sont pratiquement autonomes. Le problème est que, si vous n'êtes pas un hacker, vous ne pouvez pas dire qui sont les bons hackers. Un problème similaire explique pourquoi les voitures américaines sont si laides. J'appelle cela le paradoxe du design. Vous pourriez penser que vous pourriez rendre vos produits beaux simplement en engageant un grand designer pour les concevoir. Mais si vous n'avez pas vous-même bon goût, comment allez-vous reconnaître un bon designer ? Par définition, vous ne pouvez pas le dire d'après son portfolio. Et vous ne pouvez pas vous fier aux prix qu'il a gagnés ou aux emplois qu'il a occupés, car dans le design, comme dans la plupart des domaines, ceux-ci ont tendance à être dictés par la mode et le réseautage, la capacité réelle étant loin derrière. Il n'y a pas d'échappatoire : vous ne pouvez pas gérer un processus destiné à produire de belles choses sans savoir ce qu'est la beauté. Les voitures américaines sont laides parce que les constructeurs automobiles américains sont dirigés par des gens de mauvais goût.

Beaucoup de gens dans ce pays considèrent le goût comme quelque chose d'insaisissable, voire de frivole. Ce n'est ni l'un ni l'autre. Pour diriger le design, un manager doit être l'utilisateur le plus exigeant des produits d'une entreprise. Et si vous avez vraiment bon goût, vous pouvez, comme Steve Jobs, faire en sorte que vous satisfaire devienne le genre de problème sur lequel les bonnes personnes aiment travailler.

Petits problèmes désagréables

Il est assez facile de dire quels types de problèmes ne sont pas intéressants : ceux où, au lieu de résoudre quelques grands problèmes clairs, vous devez résoudre beaucoup de petits problèmes désagréables. L'un des pires types de projets est d'écrire une interface pour un logiciel plein de bugs. Un autre est lorsque vous devez personnaliser quelque chose pour les besoins complexes et mal définis d'un client individuel. Pour les hackers, ce genre de projets est la mort par mille coupures.

La caractéristique distinctive des petits problèmes désagréables est que vous n'en apprenez rien. Écrire un compilateur est intéressant parce que cela vous apprend ce qu'est un compilateur. Mais écrire une interface pour un logiciel bogué ne vous apprend rien, car les bugs sont aléatoires. [3] Ce n'est donc pas seulement la minutie qui pousse les bons hackers à éviter les petits problèmes désagréables. C'est plus une question d'auto-préservation. Travailler sur de petits problèmes désagréables vous rend stupide. Les bons hackers l'évitent pour la même raison que les mannequins évitent les cheeseburgers.

Bien sûr, certains problèmes ont intrinsèquement ce caractère. Et en raison de l'offre et de la demande, ils sont particulièrement bien rémunérés. Ainsi, une entreprise qui trouverait un moyen d'amener de grands hackers à travailler sur des problèmes fastidieux aurait beaucoup de succès. Comment feriez-vous ?

Un endroit où cela se produit est dans les startups. Dans notre startup, nous avions Robert Morris travaillant comme administrateur système. C'est comme faire jouer les Rolling Stones à une bar-mitsvah. Vous ne pouvez pas embaucher ce genre de talent. Mais les gens feront n'importe quelle quantité de travail ingrat pour les entreprises dont ils sont les fondateurs. [4]

Les grandes entreprises résolvent le problème en partitionnant l'entreprise. Elles attirent des personnes intelligentes en établissant un département de R&D séparé où les employés n'ont pas à travailler directement sur les petits problèmes désagréables des clients. [5] Dans ce modèle, le département de recherche fonctionne comme une mine. Ils produisent de nouvelles idées ; peut-être que le reste de l'entreprise pourra les utiliser.

Vous n'aurez peut-être pas à aller à cet extrême. La programmation ascendante suggère une autre façon de partitionner l'entreprise : faire travailler les personnes intelligentes comme fabricants d'outils. Si votre entreprise crée un logiciel pour faire x, ayez un groupe qui construit des outils pour écrire des logiciels de ce type, et un autre qui utilise ces outils pour écrire les applications. De cette façon, vous pourriez réussir à faire écrire 99 % de votre code par des personnes intelligentes, tout en les gardant presque aussi isolées des utilisateurs qu'elles le seraient dans un département de recherche traditionnel. Les fabricants d'outils auraient des utilisateurs, mais ce ne seraient que les propres développeurs de l'entreprise. [6]

Si Microsoft utilisait cette approche, leur logiciel ne serait pas si plein de failles de sécurité, car les personnes moins intelligentes écrivant les applications réelles ne feraient pas de choses de bas niveau comme l'allocation de mémoire. Au lieu d'écrire Word directement en C, elles assembleraient de gros blocs Lego de langage Word. (Duplo, je crois, est le terme technique.)

Regroupement

Outre les problèmes intéressants, ce que les bons hackers aiment, ce sont les autres bons hackers. Les grands hackers ont tendance à se regrouper – parfois de manière spectaculaire, comme au Xerox Parc. Vous n'attirerez donc pas de bons hackers en proportion linéaire de la qualité de l'environnement que vous créez pour eux. La tendance à se regrouper signifie que c'est plus comme le carré de l'environnement. C'est donc le vainqueur qui prend tout. À tout moment, il n'y a qu'une dizaine ou une vingtaine d'endroits où les hackers veulent le plus travailler, et si vous n'en faites pas partie, vous n'aurez pas seulement moins de grands hackers, vous en aurez zéro.

Avoir de grands hackers ne suffit pas, en soi, à rendre une entreprise prospère. Cela fonctionne bien pour Google et ITA, qui sont deux des points chauds actuels, mais cela n'a pas aidé Thinking Machines ou Xerox. Sun a eu une bonne période, mais leur modèle économique est un ascenseur descendant. Dans cette situation, même les meilleurs hackers ne peuvent pas vous sauver.

Je pense, cependant, que toutes choses égales par ailleurs, une entreprise capable d'attirer de grands hackers aura un avantage énorme. Il y a des gens qui ne seraient pas d'accord avec cela. Lorsque nous faisions le tour des sociétés de capital-risque dans les années 1990, plusieurs nous ont dit que les entreprises de logiciels ne gagnaient pas en écrivant de superbes logiciels, mais par la marque, la domination des canaux et la conclusion des bonnes affaires.

Ils semblaient vraiment le croire, et je pense savoir pourquoi. Je pense que ce que beaucoup de VCs recherchent, du moins inconsciemment, c'est le prochain Microsoft. Et bien sûr, si Microsoft est votre modèle, vous ne devriez pas chercher des entreprises qui espèrent gagner en écrivant de superbes logiciels. Mais les VCs se trompent en cherchant le prochain Microsoft, car aucune startup ne peut être le prochain Microsoft à moins qu'une autre entreprise ne soit prête à se plier au bon moment et à être le prochain IBM.

C'est une erreur d'utiliser Microsoft comme modèle, car toute leur culture découle de ce coup de chance. Microsoft est un mauvais point de données. Si vous les excluez, vous constatez que les bons produits ont tendance à gagner sur le marché. Ce que les VCs devraient chercher, c'est le prochain Apple, ou le prochain Google.

Je pense que Bill Gates le sait. Ce qui l'inquiète à propos de Google, ce n'est pas la puissance de leur marque, mais le fait qu'ils ont de meilleurs hackers. [7]

Reconnaissance

Alors, qui sont les grands hackers ? Comment savoir quand vous en rencontrez un ? Cela s'avère très difficile. Même les hackers ne peuvent pas le dire. Je suis maintenant assez sûr que mon ami Trevor Blackwell est un grand hacker. Vous avez peut-être lu sur Slashdot comment il a fabriqué son propre Segway. La chose remarquable à propos de ce projet est qu'il a écrit tout le logiciel en une journée (en Python, d'ailleurs).

Pour Trevor, c'est tout à fait normal. Mais quand je l'ai rencontré pour la première fois, je pensais que c'était un idiot complet. Il était debout dans le bureau de Robert Morris, lui parlant de tout et de rien, et je me souviens être resté derrière lui, faisant des gestes frénétiques à Robert pour qu'il chasse ce fou de son bureau afin que nous puissions aller déjeuner. Robert dit qu'il a aussi mal jugé Trevor au début. Apparemment, quand Robert l'a rencontré pour la première fois, Trevor venait de commencer un nouveau système qui consistait à noter tout sur tous les aspects de sa vie sur une pile de fiches, qu'il transportait partout avec lui. Il venait également d'arriver du Canada, et avait un fort accent canadien et une coupe mulet.

Le problème est aggravé par le fait que les hackers, malgré leur réputation d'insouciance sociale, mettent parfois beaucoup d'efforts à paraître intelligents. Quand j'étais aux études supérieures, je traînais parfois au MIT AI Lab. C'était un peu intimidant au début. Tout le monde y parlait si vite. Mais après un certain temps, j'ai appris l'astuce de parler vite. Vous n'avez pas besoin de penser plus vite ; utilisez simplement deux fois plus de mots pour tout dire.

Avec cette quantité de bruit dans le signal, il est difficile de reconnaître les bons hackers quand vous les rencontrez. Je ne peux pas le faire, même maintenant. Vous ne pouvez pas non plus le dire d'après leurs CV. Il semble que la seule façon de juger un hacker est de travailler avec lui sur quelque chose.

Et c'est la raison pour laquelle les zones de haute technologie n'apparaissent qu'autour des universités. L'ingrédient actif ici n'est pas tant les professeurs que les étudiants. Les startups se développent autour des universités parce que les universités rassemblent de jeunes gens prometteurs et les font travailler sur les mêmes projets. Les plus intelligents apprennent qui sont les autres intelligents, et ensemble ils concoctent de nouveaux projets qui leur sont propres.

Parce que vous ne pouvez pas reconnaître un grand hacker si ce n'est en travaillant avec lui, les hackers eux-mêmes ne peuvent pas dire à quel point ils sont bons. C'est vrai dans une certaine mesure dans la plupart des domaines. J'ai constaté que les personnes qui sont excellentes dans quelque chose ne sont pas tant convaincues de leur propre grandeur que mystifiées par la raison pour laquelle tout le monde semble si incompétent.

Mais il est particulièrement difficile pour les hackers de savoir à quel point ils sont bons, car il est difficile de comparer leur travail. C'est plus facile dans la plupart des autres domaines. Au cent mètres, vous savez en 10 secondes qui est le plus rapide. Même en mathématiques, il semble y avoir un consensus général sur les problèmes difficiles à résoudre et ce qui constitue une bonne solution. Mais le hacking est comme l'écriture. Qui peut dire lequel de deux romans est le meilleur ? Certainement pas les auteurs.

Avec les hackers, du moins, les autres hackers peuvent le dire. C'est parce que, contrairement aux romanciers, les hackers collaborent sur des projets. Lorsque vous devez résoudre quelques problèmes difficiles sur le net avec quelqu'un, vous apprenez assez vite à quel point ils les résolvent en retour. Mais les hackers ne peuvent pas s'observer au travail. Donc, si vous demandez à un grand hacker à quel point il est bon, il répondra presque certainement : « Je ne sais pas. » Il n'est pas seulement modeste. Il ne sait vraiment pas.

Et aucun de nous ne le sait, sauf pour les personnes avec qui nous avons réellement travaillé. Ce qui nous met dans une situation étrange : nous ne savons pas qui devraient être nos héros. Les hackers qui deviennent célèbres ont tendance à le devenir par des accidents aléatoires de relations publiques. Occasionnellement, j'ai besoin de donner un exemple de grand hacker, et je ne sais jamais qui utiliser. Les premiers noms qui me viennent à l'esprit ont toujours tendance à être des personnes que je connais personnellement, mais cela semble boiteux de les utiliser. Alors, je pense, peut-être devrais-je dire Richard Stallman, ou Linus Torvalds, ou Alan Kay, ou quelqu'un de célèbre comme ça. Mais je n'ai aucune idée si ces gars sont de grands hackers. Je n'ai jamais travaillé avec eux sur quoi que ce soit.

S'il existe un Michael Jordan du hacking, personne ne le sait, y compris lui.

Cultivation

Enfin, la question que tous les hackers se posent : comment devenir un grand hacker ? Je ne sais pas s'il est possible de le devenir soi-même. Mais il est certainement possible de faire des choses qui vous rendent stupide, et si vous pouvez vous rendre stupide, vous pouvez probablement aussi vous rendre intelligent.

La clé pour être un bon hacker est peut-être de travailler sur ce que vous aimez. Quand je pense aux grands hackers que je connais, une chose qu'ils ont en commun est l'extrême difficulté de les faire travailler sur quoi que ce soit qu'ils ne veulent pas. Je ne sais pas si c'est une cause ou un effet ; cela peut être les deux.

Pour bien faire quelque chose, il faut l'aimer. Donc, dans la mesure où vous pouvez préserver le hacking comme quelque chose que vous aimez, vous êtes susceptible de bien le faire. Essayez de garder le sens de l'émerveillement que vous aviez pour la programmation à 14 ans. Si vous craignez que votre emploi actuel ne vous pourrisse le cerveau, c'est probablement le cas.

Les meilleurs hackers ont tendance à être intelligents, bien sûr, mais c'est vrai dans beaucoup de domaines. Y a-t-il une qualité unique aux hackers ? J'ai demandé à des amis, et la première chose qu'ils ont mentionnée était la curiosité. J'avais toujours supposé que toutes les personnes intelligentes étaient curieuses – que la curiosité était simplement la première dérivée de la connaissance. Mais apparemment, les hackers sont particulièrement curieux, surtout de savoir comment les choses fonctionnent. Cela a du sens, car les programmes sont en fait de gigantesques descriptions de la façon dont les choses fonctionnent.

Plusieurs amis ont mentionné la capacité de concentration des hackers – leur capacité, comme l'a dit l'un d'eux, à « ignorer tout ce qui se passe en dehors de leur tête ». J'ai certainement remarqué cela. Et j'ai entendu plusieurs hackers dire qu'après avoir bu ne serait-ce qu'une demi-bière, ils ne peuvent plus programmer du tout. Alors peut-être que le hacking exige une capacité spéciale de concentration. Peut-être que les grands hackers peuvent charger une grande quantité de contexte dans leur tête, de sorte que lorsqu'ils regardent une ligne de code, ils ne voient pas seulement cette ligne mais tout le programme autour d'elle. John McPhee a écrit que le succès de Bill Bradley en tant que joueur de basket-ball était en partie dû à sa vision périphérique extraordinaire. Une vision « parfaite » signifie environ 47 degrés de vision périphérique verticale. Bill Bradley en avait 70 ; il pouvait voir le panier en regardant le sol. Peut-être que les grands hackers ont une capacité innée similaire. (Je triche en utilisant un langage très dense, ce qui réduit le terrain.)

Cela pourrait expliquer le désaccord concernant les cubicles. Peut-être que les responsables des installations, n'ayant aucune concentration à briser, n'ont aucune idée que travailler dans un cubicle donne à un hacker l'impression d'avoir le cerveau dans un mixeur. (Alors que Bill, si les rumeurs d'autisme sont vraies, le sait bien trop bien.)

Une différence que j'ai remarquée entre les grands hackers et les personnes intelligentes en général est que les hackers sont plus politiquement incorrects. Dans la mesure où il existe un signe de reconnaissance secret parmi les bons hackers, c'est lorsqu'ils se connaissent suffisamment bien pour exprimer des opinions qui les feraient lapider par le grand public. Et je peux voir pourquoi l'incorrection politique serait une qualité utile en programmation. Les programmes sont très complexes et, du moins entre les mains de bons programmeurs, très fluides. Dans de telles situations, il est utile d'avoir l'habitude de remettre en question les hypothèses.

Pouvez-vous cultiver ces qualités ? Je ne sais pas. Mais vous pouvez au moins ne pas les réprimer. Voici donc ma meilleure tentative de recette. S'il est possible de devenir un grand hacker, la façon de le faire pourrait être de passer le marché suivant avec vous-même : vous n'aurez jamais à travailler sur des projets ennuyeux (à moins que votre famille ne meure de faim autrement), et en retour, vous ne vous permettrez jamais de faire un travail bâclé. Tous les grands hackers que je connais semblent avoir fait ce marché, bien qu'aucun d'entre eux n'ait peut-être eu le choix en la matière.

Notes

[1] Pour être juste, je dois dire qu'IBM fabrique du matériel décent. J'ai écrit ceci sur un ordinateur portable IBM.

[2] Ils se sont effectivement avérés condamnés. Ils ont fermé quelques mois plus tard.

[3] Je pense que c'est ce que les gens veulent dire quand ils parlent du « sens de la vie ». À première vue, cela semble une idée étrange. La vie n'est pas une expression ; comment pourrait-elle avoir un sens ? Mais elle peut avoir une qualité qui ressemble beaucoup à un sens. Dans un projet comme un compilateur, vous devez résoudre beaucoup de problèmes, mais les problèmes suivent tous un schéma, comme dans un signal. Alors que lorsque les problèmes que vous devez résoudre sont aléatoires, ils ressemblent à du bruit.

[4] Einstein a un jour travaillé à la conception de réfrigérateurs. (Il avait des parts.)

[5] Il est difficile de dire exactement ce qui constitue la recherche dans le monde informatique, mais en première approximation, c'est un logiciel qui n'a pas d'utilisateurs.

Je ne pense pas que ce soit la publication qui pousse les meilleurs hackers à vouloir travailler dans les départements de recherche. Je pense que c'est principalement le fait de ne pas avoir à passer une réunion de trois heures avec un chef de produit sur les problèmes d'intégration de la version coréenne de Word 13.27 avec le trombone parlant.

[6] Quelque chose de similaire se produit depuis longtemps dans l'industrie de la construction. Lorsque vous faisiez construire une maison il y a quelques centaines d'années, les constructeurs locaux y construisaient tout. Mais de plus en plus, ce que font les constructeurs est d'assembler des composants conçus et fabriqués par quelqu'un d'autre. Cela a, comme l'arrivée de la publication assistée par ordinateur, donné aux gens la liberté d'expérimenter de manière désastreuse, mais c'est certainement plus efficace.

[7] Google est bien plus dangereux pour Microsoft que ne l'était Netscape. Probablement plus dangereux que toute autre entreprise ne l'a jamais été. Non seulement parce qu'ils sont déterminés à se battre. Sur leur page d'offres d'emploi, ils disent que l'une de leurs « valeurs fondamentales » est « Ne soyez pas malveillants ». De la part d'une entreprise vendant de l'huile de soja ou de l'équipement minier, une telle déclaration serait simplement excentrique. Mais je pense que nous tous, dans le monde informatique, reconnaissons contre qui c'est une déclaration de guerre.

Remerciements à Jessica Livingston, Robert Morris et Sarah Harlin pour la relecture des versions antérieures de cette conférence.