HACKERS ET PEINTRES

Mai 2003

(Cet essai est tiré d’une conférence donnée à Harvard, qui intégrait une conférence antérieure à Northeastern.)

Après avoir terminé mes études supérieures en informatique, je suis allé à l'école des beaux-arts pour étudier la peinture. Beaucoup de gens semblaient surpris qu'une personne intéressée par les ordinateurs puisse également s'intéresser à la peinture. Ils semblaient penser que le hacking et la peinture étaient des types de travail très différents, que le hacking était froid, précis et méthodique, et que la peinture était l'expression frénétique d'un besoin primaire.

Ces deux images sont fausses. Le hacking et la peinture ont beaucoup en commun. En fait, de tous les types de personnes que j'ai connus, les hackers et les peintres sont parmi ceux qui se ressemblent le plus.

Les hackers et les peintres ont en commun d'être des créateurs. Tout comme les compositeurs, les architectes et les écrivains, ils s'efforcent de créer de bonnes choses. Ils ne font pas de la recherche à proprement parler, mais s'ils découvrent une nouvelle technique en essayant de créer de bonnes choses, c'est tant mieux.

Je n'ai jamais aimé le terme « informatique ». La principale raison pour laquelle je ne l'aime pas, c'est qu'il n'existe pas. L'informatique est un fourre-tout de domaines vaguement liés, réunis par un accident de l'histoire, comme la Yougoslavie. À une extrémité, vous avez des gens qui sont de vrais mathématiciens, mais qui appellent ce qu'ils font de l'informatique pour pouvoir obtenir des subventions de la DARPA. Au milieu, vous avez des gens qui travaillent sur quelque chose comme l'histoire naturelle des ordinateurs, en étudiant le comportement des algorithmes pour acheminer les données sur les réseaux, par exemple. Et puis, à l'autre extrémité, vous avez les hackers, qui essaient d'écrire des logiciels intéressants, et pour qui les ordinateurs ne sont qu'un moyen d'expression, comme le béton l'est pour les architectes ou la peinture pour les peintres. C'est comme si les mathématiciens, les physiciens et les architectes devaient tous être dans le même département.

On appelle parfois ce que font les hackers « ingénierie logicielle », mais ce terme est tout aussi trompeur. Les bons concepteurs de logiciels ne sont pas plus des ingénieurs que les architectes. La frontière entre architecture et ingénierie n’est pas clairement définie, mais elle existe. Elle se situe entre le quoi et le comment : les architectes décident quoi faire et les ingénieurs déterminent comment le faire.

Il ne faut pas trop séparer le quoi et le comment. Vous vous attirerez des ennuis si vous essayez de décider quoi faire sans comprendre comment le faire. Mais le hacking peut certainement être bien plus que simplement décider comment implémenter une spécification. Dans le meilleur des cas, il s'agit de créer la spécification, même si le meilleur moyen d'y parvenir est de l'implémenter.

Peut-être qu'un jour, comme la Yougoslavie, l'informatique sera divisée en ses différentes composantes. Ce serait une bonne chose. Surtout si cela signifiait l'indépendance de mon pays natal, le hacking.

Regrouper tous ces différents types de travaux dans un seul département peut être pratique sur le plan administratif, mais cela peut être déroutant sur le plan intellectuel. C'est l'autre raison pour laquelle je n'aime pas le terme « informatique ». On peut dire que les gens du milieu font quelque chose qui ressemble à de la science expérimentale. Mais les gens aux deux extrémités, les hackers et les mathématiciens, ne font pas vraiment de science.

Les mathématiciens ne semblent pas s'en préoccuper. Ils se mettent à prouver des théorèmes avec plaisir, comme les autres mathématiciens du département de mathématiques, et ne remarquent probablement pas rapidement que le bâtiment dans lequel ils travaillent porte la mention « informatique ». Mais pour les hackers, cette étiquette pose problème. Si ce qu'ils font est qualifié de science, ils ont le sentiment qu'ils devraient agir de manière scientifique. Ainsi, au lieu de faire ce qu'ils veulent vraiment faire, c'est-à-dire concevoir de beaux logiciels, les hackers des universités et des laboratoires de recherche ont le sentiment qu'ils devraient rédiger des articles de recherche.

Dans le meilleur des cas, les documents ne sont qu'une formalité. Les hackers écrivent des logiciels intéressants, puis rédigent un article à leur sujet, et l'article devient un substitut de la réussite représentée par le logiciel. Mais souvent, cette inadéquation cause des problèmes. Il est facile de s'éloigner de la construction de belles choses pour se tourner vers la construction de choses laides qui constituent des sujets plus appropriés pour des articles de recherche.

Malheureusement, les belles choses ne sont pas toujours les meilleurs sujets pour un article. Premièrement, la recherche doit être originale – et comme le sait quiconque a écrit une thèse de doctorat, le meilleur moyen d’être sûr d’explorer un territoire vierge est de jalonner un terrain dont personne ne veut. Deuxièmement, la recherche doit être substantielle – et les systèmes difficiles donnent lieu à des articles plus consistants, car vous pouvez écrire sur les obstacles que vous devez surmonter pour faire avancer les choses. Rien ne donne autant de problèmes consistants que de commencer avec de mauvaises hypothèses. La plupart des cas d’IA sont un exemple de cette règle : si vous supposez que la connaissance peut être représentée comme une liste d’expressions logiques de prédicats dont les arguments représentent des concepts abstraits, vous aurez beaucoup d’articles à écrire sur la façon de faire fonctionner cela. Comme le disait Ricky Ricardo : « Lucy, tu as beaucoup d’explications à donner. »

La meilleure façon de créer quelque chose de beau consiste souvent à apporter de subtiles modifications à quelque chose qui existe déjà ou à combiner des idées existantes d'une manière légèrement nouvelle. Ce genre de travail est difficile à exprimer dans un article de recherche.

Alors pourquoi les universités et les laboratoires de recherche continuent-ils à juger les hackers en fonction de leurs publications ? Pour la même raison que les « aptitudes scolaires » sont mesurées par des tests standardisés simplistes, ou que la productivité des programmeurs est mesurée en lignes de code. Ces tests sont faciles à appliquer, et rien n'est plus tentant qu'un test facile qui fonctionne.

Il serait beaucoup plus difficile de mesurer ce que les hackers essaient réellement de faire, à savoir concevoir de beaux logiciels. Il faut un bon sens du design pour juger un bon design. Et il n'y a pas de corrélation, sauf peut-être négative , entre la capacité des gens à reconnaître un bon design et leur confiance en eux.

Le seul test externe est le temps. Avec le temps, les belles choses ont tendance à prospérer, et les choses laides ont tendance à être abandonnées. Malheureusement, le temps nécessaire peut être plus long que la durée d'une vie humaine. Samuel Johnson a dit qu'il fallait cent ans pour que la réputation d'un écrivain converge. Il faut attendre que les amis influents de l'écrivain meurent, puis que tous ses disciples meurent.

Je pense que les hackers doivent se résigner à ce que leur réputation soit en grande partie aléatoire. En cela, ils ne sont pas différents des autres créateurs. En fait, ils ont de la chance en comparaison. L'influence de la mode n'est pas aussi grande dans le hacking que dans la peinture.

Il y a pire que de voir les gens mal comprendre votre travail. Le pire, c’est que vous-même vous mépreniez sur votre travail. C’est dans les domaines connexes que vous allez chercher des idées. Si vous vous trouvez dans le département d’informatique, il est naturel de croire, par exemple, que le piratage informatique est la version appliquée de ce dont l’informatique théorique est la théorie. Pendant toute la durée de mes études supérieures, j’avais le sentiment désagréable que je devais en savoir plus sur la théorie et que c’était une grande négligence de ma part d’avoir oublié tout cela trois semaines avant l’examen final.

Maintenant, je me rends compte que je me suis trompé. Les hackers ont besoin de comprendre la théorie du calcul à peu près autant que les peintres ont besoin de comprendre la chimie de la peinture. Vous devez savoir comment calculer la complexité temporelle et spatiale et la complétude de Turing. Vous devriez également vous rappeler au moins du concept de machine à états, au cas où vous auriez à écrire un analyseur ou une bibliothèque d'expressions régulières. En fait, les peintres doivent se souvenir de bien plus de choses sur la chimie de la peinture que cela.

J'ai découvert que les meilleures sources d'idées ne sont pas les autres domaines qui ont le mot « ordinateur » dans leur nom, mais les autres domaines habités par des créateurs. La peinture a été une source d'idées bien plus riche que la théorie du calcul.

Par exemple, on m’a appris à l’université qu’il fallait concevoir un programme entièrement sur papier avant même de m’approcher d’un ordinateur. J’ai découvert que je ne programmais pas de cette façon. J’ai découvert que j’aimais programmer assis devant un ordinateur, pas sur une feuille de papier. Pire encore, au lieu d’écrire patiemment un programme complet et de m’assurer qu’il était correct, j’avais tendance à simplement débiter du code désespérément cassé et à le mettre progressivement en forme. On m’a appris que le débogage était une sorte de passe finale où l’on repérait les fautes de frappe et les oublis. De la façon dont je travaillais, il me semblait que la programmation consistait à déboguer.

Pendant longtemps, je me suis senti mal à ce sujet, tout comme je me suis senti mal à l'aise de ne pas tenir mon crayon comme on m'avait appris à le faire à l'école primaire. Si j'avais seulement regardé les autres créateurs, les peintres ou les architectes, j'aurais compris qu'il y avait un nom pour ce que je faisais : dessiner. Pour autant que je sache, la façon dont on m'a appris à programmer à l'université était complètement fausse. Vous devez comprendre les programmes au fur et à mesure que vous les écrivez, tout comme le font les écrivains, les peintres et les architectes.

Comprendre cela a de réelles implications pour la conception de logiciels. Cela signifie qu'un langage de programmation doit, avant tout, être malléable. Un langage de programmation sert à penser des programmes, pas à exprimer des programmes auxquels vous avez déjà pensé. Il doit être un crayon, pas un stylo. Le typage statique serait une bonne idée si les gens écrivaient réellement des programmes comme ils m'ont appris à le faire à l'université. Mais ce n'est pas ainsi que les hackers que je connais écrivent des programmes. Nous avons besoin d'un langage qui nous permette de griffonner, de barbouiller et de barbouiller, pas d'un langage dans lequel vous devez vous asseoir avec une tasse de thé de types en équilibre sur vos genoux et avoir une conversation polie avec une vieille tante stricte d'un compilateur.

Puisque nous parlons de typage statique, s'identifier aux créateurs nous épargnera un autre problème qui afflige les sciences : l'envie des mathématiciens. Tout le monde dans les sciences croit secrètement que les mathématiciens sont plus intelligents qu'eux. Je pense que les mathématiciens le croient aussi. En tout cas, le résultat est que les scientifiques ont tendance à rendre leur travail aussi mathématique que possible. Dans un domaine comme la physique, cela ne fait probablement pas beaucoup de mal, mais plus on s'éloigne des sciences naturelles, plus cela devient un problème.

Une page de formules semble tout simplement impressionnante. (Astuce : pour plus d'impressionnant, utilisez des variables grecques.) Il est donc très tentant de travailler sur des problèmes que vous pouvez traiter de manière formelle, plutôt que sur des problèmes qui sont, par exemple, importants.

Si les hackers s'identifiaient à d'autres créateurs, comme les écrivains et les peintres, ils ne seraient pas tentés de faire cela. Les écrivains et les peintres ne souffrent pas de jalousie mathématique. Ils ont l'impression de faire quelque chose qui n'a aucun rapport avec le sujet. C'est aussi le cas des hackers, je pense.

Si les universités et les laboratoires de recherche empêchent les hackers de faire le travail qu'ils souhaitent faire, peut-être leur place est-elle dans les entreprises. Malheureusement, la plupart des entreprises ne laissent pas non plus les hackers faire ce qu'ils veulent. Les universités et les laboratoires de recherche obligent les hackers à devenir des scientifiques, et les entreprises les obligent à devenir des ingénieurs.

Je n’ai découvert cela que récemment. Lorsque Yahoo a racheté Viaweb, ils m’ont demandé ce que je voulais faire. Je n’avais jamais vraiment aimé le côté commercial et je leur ai répondu que je voulais juste pirater. Lorsque je suis arrivé chez Yahoo, j’ai découvert que pour eux, pirater signifiait implémenter des logiciels, pas les concevoir. Les programmeurs étaient considérés comme des techniciens qui traduisaient les visions (si c’est le mot) des chefs de produit en code.

Cela semble être le plan par défaut dans les grandes entreprises. Elles le font parce que cela diminue l'écart type du résultat. Seul un petit pourcentage de hackers peut réellement concevoir un logiciel, et il est difficile pour les dirigeants d'une entreprise de les identifier. Ainsi, au lieu de confier l'avenir du logiciel à un hacker brillant, la plupart des entreprises font en sorte que le logiciel soit conçu par un comité, et les hackers se contentent de mettre en œuvre la conception.

Si vous voulez gagner de l'argent à un moment donné, souvenez-vous de cela, car c'est l'une des raisons pour lesquelles les startups gagnent. Les grandes entreprises veulent réduire l'écart type des résultats de conception car elles veulent éviter les catastrophes. Mais lorsque vous amortissez les oscillations, vous perdez les points hauts comme les points bas. Ce n'est pas un problème pour les grandes entreprises, car elles ne gagnent pas en fabriquant de bons produits. Les grandes entreprises gagnent en étant moins nulles que les autres grandes entreprises.

Si vous parvenez à trouver un moyen de vous engager dans une guerre de conception avec une entreprise suffisamment grande pour que ses logiciels soient conçus par des chefs de produit, elle ne pourra jamais vous suivre. Ces opportunités ne sont cependant pas faciles à trouver. Il est difficile d'engager une grande entreprise dans une guerre de conception, tout comme il est difficile d'engager un adversaire dans un combat au corps à corps dans un château. Il serait assez facile de créer un meilleur traitement de texte que Microsoft Word, par exemple, mais Microsoft, dans le château de son monopole sur les systèmes d'exploitation, ne s'en apercevrait probablement même pas.

Les guerres de design se déroulent sur les nouveaux marchés, où personne n'a encore réussi à établir de fortifications. C'est là que l'on peut gagner gros en adoptant une approche audacieuse en matière de design et en faisant appel aux mêmes personnes pour concevoir et mettre en œuvre le produit. Microsoft l'a fait au début. Apple aussi. Et Hewlett-Packard. Je pense que presque toutes les startups à succès l'ont fait.

Une façon de créer un logiciel de qualité est de créer sa propre start-up. Mais cela pose deux problèmes. Le premier est que dans une start-up, il faut faire beaucoup plus que simplement écrire des logiciels. Chez Viaweb, je me considérais chanceux si je devais pirater un quart du temps. Et les tâches que je devais effectuer les trois quarts restants étaient fastidieuses, voire terrifiantes. J'ai un point de référence pour cela, car j'ai dû quitter une réunion du conseil d'administration pour me faire soigner des caries. Je me souviens m'être assis sur la chaise du dentiste, en attendant la fraise, et avoir l'impression d'être en vacances.

L’autre problème des startups est qu’il n’y a pas beaucoup de points communs entre le type de logiciel qui rapporte de l’argent et celui qui est intéressant à écrire. Les langages de programmation sont intéressants à écrire, et le premier produit de Microsoft en était un, en fait, mais personne ne veut payer pour des langages de programmation aujourd’hui. Si vous voulez gagner de l’argent, vous avez tendance à être obligé de travailler sur des problèmes trop complexes pour que quiconque puisse les résoudre gratuitement.

Tous les créateurs sont confrontés à ce problème. Les prix sont déterminés par l'offre et la demande, et la demande pour des choses amusantes est moins forte que pour des choses qui résolvent les problèmes banals des clients individuels. Jouer dans des pièces off-Broadway n'est pas aussi bien payé que de porter un costume de gorille sur le stand d'un salon professionnel. Écrire des romans n'est pas aussi bien payé que rédiger des publicités pour des broyeurs à déchets. Et pirater des langages de programmation n'est pas aussi bien payé que de comprendre comment connecter la base de données héritée d'une entreprise à son serveur Web.

Je pense que la réponse à ce problème, dans le cas des logiciels, est un concept connu de presque tous les créateurs : le travail de jour. Cette expression a commencé avec les musiciens, qui se produisent la nuit. Plus généralement, cela signifie qu'il y a un type de travail que vous faites pour l'argent, et un autre par amour.

Presque tous les créateurs ont un emploi au début de leur carrière. Les peintres et les écrivains le font notoirement. Si vous avez de la chance, vous pouvez obtenir un emploi en lien étroit avec votre véritable travail. Les musiciens semblent souvent travailler dans des magasins de disques. Un hacker travaillant sur un langage de programmation ou un système d'exploitation peut également être en mesure d'obtenir un emploi en l'utilisant. [1]

Quand je dis que la solution est que les hackers aient un emploi à temps plein et travaillent en parallèle sur de beaux logiciels, je ne propose pas cela comme une idée nouvelle. C'est exactement ce qu'est le hacking open source. Ce que je dis, c'est que l'open source est probablement le bon modèle, car il a été confirmé indépendamment par tous les autres développeurs.

Il me paraît surprenant qu'un employeur soit réticent à laisser des hackers travailler sur des projets open source. Chez Viaweb, nous aurions été réticents à embaucher quelqu'un qui ne le ferait pas. Lorsque nous avons interviewé des programmeurs, la principale chose qui nous intéressait était le type de logiciel qu'ils écrivaient pendant leur temps libre. Vous ne pouvez rien faire de vraiment bien si vous n'aimez pas ça, et si vous aimez pirater, vous travaillerez inévitablement sur vos propres projets. [2]

Les hackers étant des créateurs plutôt que des scientifiques, il n’est pas judicieux de chercher des métaphores dans les sciences, mais parmi d’autres types de créateurs. Que peut nous apprendre d’autre la peinture sur le hacking ?

Une chose que nous pouvons apprendre, ou du moins confirmer, de l'exemple de la peinture est comment apprendre à pirater. On apprend à peindre principalement en le faisant. Il en va de même pour le hacking. La plupart des hackers n'apprennent pas à pirater en suivant des cours de programmation à l'université. Ils apprennent à pirater en écrivant leurs propres programmes à l'âge de treize ans. Même dans les cours universitaires, on apprend à pirater principalement en pirateant. [3]

Comme les peintres laissent derrière eux une trace de travail, vous pouvez les voir apprendre en faisant. Si vous regardez le travail d'un peintre dans l'ordre chronologique, vous constaterez que chaque tableau s'appuie sur des éléments appris dans les précédents. Lorsqu'il y a quelque chose dans un tableau qui fonctionne très bien, vous pouvez généralement en trouver une version 1 sous une forme plus petite dans un tableau antérieur.

Je pense que la plupart des créateurs travaillent de cette façon. Les écrivains et les architectes semblent faire de même. Il serait peut-être bon que les hackers se comportent davantage comme des peintres et recommencent régulièrement à zéro, au lieu de continuer à travailler pendant des années sur un seul projet et d'essayer d'intégrer toutes leurs idées ultérieures sous forme de révisions.

Le fait que les hackers apprennent à pirater en le faisant est un autre signe de la différence entre le hacking et les sciences. Les scientifiques n'apprennent pas la science en le faisant, mais en faisant des travaux pratiques et en résolvant des problèmes. Les scientifiques commencent par faire un travail parfait, dans le sens où ils essaient simplement de reproduire le travail que quelqu'un d'autre a déjà fait pour eux. Finalement, ils arrivent au point où ils peuvent faire un travail original. Alors que les hackers, dès le début, font un travail original, mais c'est très mauvais. Donc les hackers commencent par être originaux et deviennent bons, et les scientifiques commencent par être bons et deviennent originaux.

L’autre façon d’apprendre des peintres est de s’inspirer d’exemples. Pour un peintre, un musée est une bibliothèque de référence de techniques. Depuis des centaines d’années, copier les œuvres des grands maîtres fait partie de l’éducation traditionnelle des peintres, car copier vous oblige à observer de près la manière dont un tableau est réalisé.

Les écrivains font la même chose. Benjamin Franklin a appris à écrire en résumant les points des essais d’Addison et de Steele, puis en essayant de les reproduire. Raymond Chandler a fait la même chose avec les romans policiers.

Les hackers, eux aussi, peuvent apprendre à programmer en observant de bons programmes, non seulement ce qu'ils font, mais aussi le code source. L'un des avantages les moins connus du mouvement open source est qu'il a facilité l'apprentissage de la programmation. Quand j'ai appris à programmer, nous devions nous fier principalement aux exemples contenus dans les livres. Le seul gros morceau de code disponible à l'époque était Unix, mais même celui-ci n'était pas open source. La plupart des gens qui lisaient le code source le lisaient dans des photocopies illicites du livre de John Lions, qui, bien qu'écrit en 1977, n'a pas été autorisé à être publié avant 1996.

Un autre exemple que l'on peut prendre en peinture est la façon dont les tableaux sont créés par affinement progressif. Les tableaux commencent généralement par une esquisse. Les détails se remplissent peu à peu. Mais il ne s'agit pas simplement d'un processus de remplissage. Parfois, les plans originaux se révèlent erronés. D'innombrables tableaux, lorsqu'on les regarde aux rayons X, se révèlent avoir des membres qui ont été déplacés ou des traits du visage qui ont été réajustés.

Voici un cas où nous pouvons apprendre de la peinture. Je pense que le hacking devrait également fonctionner de cette façon. Il n'est pas réaliste de s'attendre à ce que les spécifications d'un programme soient parfaites. Il est préférable de l'admettre dès le départ et d'écrire des programmes de manière à ce que les spécifications puissent changer à la volée.

(La structure des grandes entreprises rend cela difficile pour elles, c'est donc un autre domaine dans lequel les startups ont un avantage.)

Tout le monde connaît sans doute désormais les dangers d'une optimisation prématurée. Je pense que nous devrions nous inquiéter tout autant de la conception prématurée, c'est-à-dire de la décision prématurée de ce que doit faire un programme.

Les bons outils peuvent nous aider à éviter ce danger. Un bon langage de programmation doit, comme la peinture à l'huile, permettre de changer facilement d'avis. Le typage dynamique est ici un avantage car vous n'avez pas à vous engager à l'avance sur des représentations de données spécifiques. Mais la clé de la flexibilité, je pense, est de rendre le langage très abstrait . Le programme le plus facile à modifier est celui qui est très court.

Cela peut paraître paradoxal, mais un grand tableau doit être meilleur que ce qu'il doit être. Par exemple, lorsque Léonard de Vinci a peint le portrait de Ginevra de Benci à la National Gallery, il a placé un buisson de genévrier derrière sa tête. Il a soigneusement peint chaque feuille. De nombreux peintres auraient pu penser qu'il s'agissait simplement d'un élément à mettre en arrière-plan pour encadrer sa tête. Personne ne l'examinerait d'aussi près.

Pas Léonard de Vinci. L'effort qu'il mettait à travailler sur une partie d'un tableau ne dépendait pas du tout de l'attention qu'il attendait de quelqu'un. Il était comme Michael Jordan. Implacable.

L'acharnement l'emporte car, mis ensemble, des détails invisibles deviennent visibles. Lorsque les gens passent devant le portrait de Ginevra de Benci, leur attention est souvent immédiatement attirée par celui-ci, avant même qu'ils ne regardent l'étiquette et ne remarquent qu'il est écrit Léonard de Vinci. Tous ces détails invisibles se combinent pour produire quelque chose de tout simplement époustouflant, comme un millier de voix à peine audibles chantant toutes en harmonie.

De même, un bon logiciel requiert une dévotion fanatique à la beauté. Si vous regardez à l'intérieur d'un bon logiciel, vous découvrez que des parties que personne n'est censé voir sont également belles. Je ne prétends pas écrire de bons logiciels, mais je sais que lorsqu'il s'agit de code, je me comporte d'une manière qui me rendrait éligible à des médicaments sur ordonnance si j'abordais la vie quotidienne de la même manière. Cela me rend fou de voir du code mal indenté ou qui utilise des noms de variables laids.

Si un hacker n'était qu'un simple exécutant, transformant une spécification en code, il pourrait alors se frayer un chemin d'un bout à l'autre comme quelqu'un qui creuse un fossé. Mais si le hacker est un créateur, nous devons prendre en compte l'inspiration.

En hacking, comme en peinture, le travail se fait par cycles. Parfois, on s'enthousiasme pour un nouveau projet et on veut y travailler seize heures par jour. D'autres fois, rien ne semble intéressant.

Pour bien travailler, vous devez tenir compte de ces cycles, car ils sont affectés par la façon dont vous y réagissez. Lorsque vous conduisez une voiture à transmission manuelle sur une pente, vous devez parfois relâcher l'embrayage pour éviter de caler. Le fait de relâcher l'embrayage peut également empêcher l'ambition de caler. En peinture comme en bricolage, certaines tâches sont terriblement ambitieuses, et d'autres sont confortablement routinières. C'est une bonne idée de garder certaines tâches faciles pour les moments où vous risqueriez autrement de caler.

En hacking, cela peut littéralement signifier enregistrer des bugs. J'aime le débogage : c'est le seul moment où le hacking est aussi simple que les gens le pensent. Vous avez un problème totalement limité, et tout ce que vous avez à faire est de le résoudre. Votre programme est censé faire x. Au lieu de cela, il fait y. Où se passe-t-il un problème ? Vous savez que vous allez gagner à la fin. C'est aussi relaxant que de peindre un mur.

L'exemple de la peinture peut nous apprendre non seulement à gérer notre propre travail, mais aussi à travailler ensemble. Une grande partie des grandes œuvres d'art du passé sont le fruit du travail de plusieurs mains, même si un seul nom peut être inscrit sur le mur voisin du musée. Léonard de Vinci était apprenti dans l'atelier de Verrocchio et peignit l'un des anges de son Baptême du Christ . Ce genre de chose était la règle, pas l'exception. Michel-Ange était considéré comme particulièrement dévoué pour avoir insisté pour peindre lui-même toutes les figures du plafond de la chapelle Sixtine.

Autant que je sache, lorsque des peintres travaillaient ensemble sur un tableau, ils ne travaillaient jamais sur les mêmes parties. Il était courant que le maître peigne les personnages principaux et que les assistants peignent les autres et l'arrière-plan. Mais il n'y avait jamais un peintre qui peignait sur le travail d'un autre.

Je pense que ce modèle est également adapté à la collaboration dans le domaine des logiciels. Il ne faut pas aller trop loin. Lorsqu'un morceau de code est piraté par trois ou quatre personnes différentes, dont aucune n'en est réellement propriétaire, il finit par ressembler à une salle commune. Il aura tendance à paraître lugubre et abandonné, et à accumuler des déchets. La bonne façon de collaborer, à mon avis, est de diviser les projets en modules bien définis, chacun ayant un propriétaire précis, et avec des interfaces entre eux aussi soigneusement conçues et, si possible, aussi articulées que des langages de programmation.

Comme la peinture, la plupart des logiciels sont destinés à un public humain. Les hackers, comme les peintres, doivent donc faire preuve d'empathie pour réaliser un travail vraiment remarquable. Il faut être capable de voir les choses du point de vue de l'utilisateur.

Quand j'étais enfant, on me disait toujours de regarder les choses du point de vue de quelqu'un d'autre. En pratique, cela signifiait toujours faire ce que quelqu'un d'autre voulait, au lieu de ce que je voulais. Cela donnait bien sûr une mauvaise réputation à l'empathie, et je me suis efforcée de ne pas la cultiver.

J'avais tort. Il s'avère que regarder les choses du point de vue des autres est pratiquement le secret du succès. Cela ne signifie pas nécessairement faire preuve de sacrifice personnel. Loin de là. Comprendre la façon dont quelqu'un d'autre voit les choses n'implique pas que vous agirez dans son intérêt ; dans certaines situations, en temps de guerre par exemple, vous voulez faire exactement le contraire. [4]

La plupart des créateurs créent des œuvres pour un public humain. Et pour captiver un public, il faut comprendre ses besoins. Presque tous les plus grands tableaux sont des peintures de personnes, par exemple, parce que ce sont les personnes qui intéressent les gens.

L'empathie est probablement la différence la plus importante entre un bon hacker et un excellent hacker. Certains hackers sont très intelligents, mais en matière d'empathie, ils sont pratiquement solipsistes. Il est difficile pour ces personnes de concevoir de bons logiciels [5], car elles ne peuvent pas voir les choses du point de vue de l'utilisateur.

Une façon de savoir si les gens sont doués en empathie est de les observer expliquer une question technique à quelqu'un qui n'a pas de formation technique. Nous connaissons probablement tous des gens qui, bien qu'intelligents par ailleurs, sont tout simplement ridiculement mauvais dans ce domaine. Si quelqu'un leur demande lors d'un dîner ce qu'est un langage de programmation, ils répondront quelque chose comme « Oh, un langage de haut niveau est ce que le compilateur utilise comme entrée pour générer du code objet. » Un langage de haut niveau ? Un compilateur ? Un code objet ? Quelqu'un qui ne sait pas ce qu'est un langage de programmation ne sait évidemment pas non plus ce que sont ces choses.

Une partie du travail des logiciels consiste à s'expliquer eux-mêmes. Pour écrire un bon logiciel, il faut donc comprendre à quel point les utilisateurs ne comprennent pas grand-chose. Ils vont accéder au logiciel sans préparation, et il a intérêt à faire ce qu'ils pensent qu'il fera, car ils ne liront pas le manuel. Le meilleur système que j'ai jamais vu à cet égard était le Macintosh original, en 1985. Il faisait ce que les logiciels ne font presque jamais : il fonctionnait, tout simplement. [6]

Le code source doit lui aussi s'expliquer de lui-même. Si je pouvais faire en sorte que les gens se souviennent d'une seule citation sur la programmation, ce serait celle qui se trouve au début de Structure et interprétation des programmes informatiques.

Les programmes devraient être écrits pour que les gens puissent les lire, et seulement accessoirement pour que les machines puissent les exécuter.

Vous devez faire preuve d'empathie non seulement envers vos utilisateurs, mais aussi envers vos lecteurs. C'est dans votre intérêt, car vous serez l'un d'eux. De nombreux hackers ont écrit un programme pour découvrir, six mois plus tard, qu'ils n'avaient aucune idée de son fonctionnement. Je connais plusieurs personnes qui ont renoncé à Perl après de telles expériences. [7]

Le manque d'empathie est associé à l'intelligence, au point que c'est même devenu une mode dans certains endroits. Mais je ne pense pas qu'il y ait de corrélation. On peut réussir en mathématiques et en sciences naturelles sans avoir à apprendre l'empathie, et les gens dans ces domaines ont tendance à être intelligents, donc les deux qualités sont devenues associées. Mais il y a beaucoup de gens stupides qui sont également mauvais en empathie. Écoutez simplement les gens qui appellent pour poser des questions dans les talk-shows. Ils posent ce qu'ils veulent de manière si détournée que les animateurs doivent souvent reformuler la question à leur place.

Alors, si le hacking fonctionne comme la peinture et l'écriture, est-ce aussi cool ? Après tout, on n'a qu'une seule vie. Autant la passer à travailler sur quelque chose de génial.

Malheureusement, il est difficile de répondre à cette question. Le prestige est toujours très éloigné dans le temps. C'est comme la lumière d'une étoile lointaine. La peinture a aujourd'hui du prestige en raison du travail remarquable accompli il y a cinq cents ans. À l'époque, personne ne pensait que ces peintures étaient aussi importantes qu'aujourd'hui. Il aurait semblé très étrange aux gens de l'époque que Federico da Montefeltro, le duc d'Urbino, soit un jour surtout connu comme le type au nez étrange dans un tableau de Piero della Francesca.

Même si j'admets que le piratage informatique ne semble pas aussi cool que la peinture aujourd'hui, nous devons nous rappeler que la peinture elle-même ne semblait pas aussi cool à son apogée qu'elle l'est aujourd'hui.

Ce que l'on peut dire avec une certaine certitude, c'est que nous vivons à l'époque de la gloire du piratage informatique. Dans la plupart des domaines, les grands travaux sont réalisés très tôt. Les peintures réalisées entre 1430 et 1500 sont encore inégalées. Shakespeare est apparu au moment même où le théâtre professionnel était en train de naître,

et a poussé le médium si loin que tous les dramaturges depuis ont dû vivre dans son ombre. Albrecht Dürer a fait de même avec la gravure, et Jane Austen avec le roman.

Nous observons sans cesse le même schéma. Un nouveau média apparaît et les gens sont tellement enthousiasmés qu'ils explorent la plupart de ses possibilités au cours des deux premières générations. Le piratage informatique semble être dans cette phase actuellement.

À l'époque de Léonard de Vinci, la peinture n'était pas aussi cool que son travail l'a fait croire. Le degré de popularité du piratage informatique dépendra de ce que nous pourrons faire avec ce nouveau média.

Remarques

[1] Le plus grand tort que la photographie ait causé à la peinture est peut-être le fait qu’elle a tué le meilleur métier de la journée. La plupart des grands peintres de l’histoire ont vécu de la peinture de portraits.

[2] On m'a dit que Microsoft décourageait ses employés de contribuer à des projets open source, même pendant leur temps libre. Mais tant de hackers parmi les meilleurs travaillent désormais sur des projets open source que le principal effet de cette politique pourrait être de s'assurer qu'ils ne pourront pas embaucher de programmeurs de premier ordre.

[3] Ce que vous apprenez sur la programmation à l’université ressemble beaucoup à ce que vous apprenez sur les livres, les vêtements ou les rencontres : quel mauvais goût vous aviez au lycée.

[4] Voici un exemple d'empathie appliquée. Chez Viaweb, si nous ne pouvions pas choisir entre deux alternatives, nous nous demandions ce que nos concurrents détesteraient le plus. À un moment donné, un concurrent a ajouté à son logiciel une fonctionnalité qui était fondamentalement inutile, mais comme c'était l'une des rares fonctionnalités que nous n'avions pas, il en a fait grand cas dans la presse spécialisée. Nous aurions pu essayer d'expliquer que la fonctionnalité était inutile, mais nous avons décidé que cela agacerait davantage notre concurrent si nous l'implémentions nous-mêmes, alors nous avons créé notre propre version cet après-midi-là.

[5] À l'exception des éditeurs de texte et des compilateurs. Les hackers n'ont pas besoin d'empathie pour les concevoir, car ils sont eux-mêmes des utilisateurs typiques.

[6] Enfin, presque. Ils ont dépassé quelque peu la RAM disponible, ce qui a entraîné de nombreux problèmes d'échange de disques, mais cela pourrait être résolu en quelques mois en achetant un lecteur de disque supplémentaire.

[7] Pour rendre les programmes faciles à lire, il ne faut pas les bourrer de commentaires. Je vais même plus loin que la citation d'Abelson et Sussman. Les langages de programmation doivent être conçus pour exprimer des algorithmes, et seulement accessoirement pour indiquer aux ordinateurs comment les exécuter. Un bon langage de programmation doit être plus efficace que l'anglais pour expliquer les logiciels. Vous ne devez avoir besoin de commentaires que lorsqu'il y a un problème dont vous devez avertir les lecteurs, tout comme sur une route, il n'y a de flèches que sur les parties qui présentent des virages serrés inattendus.

Merci à Trevor Blackwell, Robert Morris, Dan Giffin et Lisa Randall pour avoir lu les brouillons de cet article, ainsi qu’à Henry Leitner et Larry Finkelstein pour m’avoir invité à prendre la parole.