Hackers et Peintres

Mai 2003

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

Quand j'ai terminé mes études supérieures en informatique, je suis allé à l'école d'art pour étudier la peinture. Beaucoup de gens semblaient surpris qu'une personne intéressée par les ordinateurs s'intéresse aussi à 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'une pulsion primale.

Ces deux images sont fausses. Le hacking et la peinture ont beaucoup en commun. En fait, de tous les différents types de personnes que j'ai connus, les hackers et les peintres sont parmi les plus similaires.

Ce que les hackers et les peintres ont en commun, c'est qu'ils sont tous deux des créateurs. Avec les compositeurs, les architectes et les écrivains, ce que les hackers et les peintres essaient de faire, c'est de créer de bonnes choses. Ils ne font pas de recherche en soi, même si, en essayant de créer de bonnes choses, ils découvrent une nouvelle technique, tant mieux.

Je n'ai jamais aimé le terme « science informatique ». La principale raison pour laquelle je ne l'aime pas est qu'une telle chose n'existe pas. La science informatique est un fourre-tout de domaines faiblement liés, réunis par un accident de l'histoire, comme la Yougoslavie. D'un côté, vous avez des gens qui sont vraiment des mathématiciens, mais qui appellent ce qu'ils font de la science informatique pour obtenir des subventions de la DARPA. Au milieu, vous avez des gens qui travaillent sur quelque chose comme l'histoire naturelle des ordinateurs — étudiant le comportement des algorithmes pour acheminer des données à travers les réseaux, par exemple. Et puis à l'autre extrême, vous avez les hackers, qui essaient d'écrire des logiciels intéressants, et pour qui les ordinateurs ne sont qu'un médium d'expression, comme le béton 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.

Parfois, ce que font les hackers est appelé « ingénierie logicielle », mais ce terme est tout aussi trompeur. Les bons concepteurs de logiciels ne sont pas plus des ingénieurs que ne le sont les architectes. La frontière entre l'architecture et l'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 trouvent comment le faire.

Le quoi et le comment ne devraient pas être trop séparés. Vous vous exposez à des problèmes si vous essayez de décider quoi faire sans comprendre comment le faire. Mais le hacking peut certainement être plus que simplement décider comment implémenter un cahier des charges. À son meilleur, c'est créer le cahier des charges — bien qu'il s'avère que la meilleure façon de le faire est de l'implémenter.

Peut-être qu'un jour la « science informatique » sera, comme la Yougoslavie, divisée en ses parties constitutives. Cela pourrait être une bonne chose. Surtout si cela signifiait l'indépendance pour ma terre natale, le hacking.

Regrouper tous ces différents types de travail dans un seul département peut être pratique administrativement, mais c'est déroutant intellectuellement. C'est l'autre raison pour laquelle je n'aime pas le nom « science informatique ». On pourrait soutenir que les gens du milieu font quelque chose qui ressemble à une science expérimentale. Mais les gens aux deux extrémités, les hackers et les mathématiciens, ne font pas réellement de la science.

Les mathématiciens ne semblent pas s'en soucier. Ils se mettent joyeusement au travail pour prouver des théorèmes comme les autres mathématiciens du département de mathématiques, et cessent probablement vite de remarquer que le bâtiment dans lequel ils travaillent porte l'inscription « science informatique » à l'extérieur. Mais pour les hackers, cette étiquette est un problème. Si ce qu'ils font est appelé science, cela leur donne l'impression 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 se sentent obligés d'écrire des articles de recherche.

Dans le meilleur des cas, les articles ne sont qu'une formalité. Les hackers écrivent des logiciels géniaux, puis écrivent un article à leur sujet, et l'article devient un substitut de l'accomplissement représenté par le logiciel. Mais souvent, ce décalage cause des problèmes. Il est facile de s'éloigner de la création de belles choses pour construire des choses laides qui sont des sujets plus appropriés pour des articles de recherche.

Malheureusement, les belles choses ne font pas toujours les meilleurs sujets d'articles. Premièrement, la recherche doit être originale — et comme quiconque a écrit une thèse de doctorat le sait, la façon de s'assurer que l'on explore un territoire vierge est de délimiter un terrain que personne ne veut. Deuxièmement, la recherche doit être substantielle — et les systèmes maladroits donnent des articles plus substantiels, car on peut écrire sur les obstacles qu'il faut surmonter pour faire avancer les choses. Rien ne génère de problèmes plus substantiels que de partir de mauvaises hypothèses. La majeure partie de l'IA est un exemple de cette règle ; si vous supposez que la connaissance peut être représentée comme une liste d'expressions de logique des 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 Ricky Ricardo disait : « Lucy, tu as beaucoup d'explications à donner. »

La façon de créer quelque chose de beau est souvent de faire des ajustements subtils à quelque chose qui existe déjà, ou de combiner des idées existantes d'une manière légèrement nouvelle. Ce genre de travail est difficile à transmettre dans un article de recherche.

Alors, pourquoi les universités et les laboratoires de recherche continuent-ils de juger les hackers par leurs publications ? Pour la même raison que l'« aptitude scolaire » est mesurée 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 il n'y a rien de plus tentant qu'un test facile qui fonctionne plus ou moins.

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

Le seul test externe est le temps. Avec le temps, les belles choses ont tendance à prospérer, et les choses laides ont tendance à être écartées. Malheureusement, les durées impliquées peuvent être plus longues que la 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 leurs disciples meurent.

Je pense que les hackers doivent simplement se résigner à avoir une composante aléatoire importante dans leur réputation. 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 d'avoir des gens qui ne comprennent pas votre travail. Un danger pire est de mal comprendre soi-même son propre travail. Les domaines connexes sont là où l'on va chercher des idées. Si vous vous trouvez dans le département d'informatique, il y a une tentation naturelle de croire, par exemple, que le hacking est la version appliquée de ce dont l'informatique théorique est la théorie. Pendant tout le temps où j'étais aux études supérieures, j'avais une sensation inconfortable au fond de mon esprit que je devais connaître plus de théorie, et qu'il était très négligent de ma part d'avoir oublié tout cela dans les trois semaines suivant l'examen final.

Maintenant, je réalise que je me trompais. Les hackers ont besoin de comprendre la théorie de la computation à peu près autant que les peintres ont besoin de comprendre la chimie des pigments. Vous devez savoir comment calculer la complexité temporelle et spatiale et ce qu'est la complétude de Turing. Vous voudrez peut-être aussi vous souvenir au moins du concept de machine à états, au cas où vous auriez à écrire un analyseur syntaxique ou une bibliothèque d'expressions régulières. Les peintres doivent en fait se souvenir de bien plus de choses sur la chimie des pigments que cela.

J'ai trouvé 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 de la computation.

Par exemple, on m'a appris à l'université qu'il fallait concevoir un programme entièrement sur papier avant même d'approcher un ordinateur. J'ai constaté que je ne programmais pas de cette façon. J'ai constaté que j'aimais programmer assis devant un ordinateur, pas 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 à cracher du code désespérément défectueux, et à le remettre progressivement en forme. Le débogage, m'a-t-on appris, était une sorte de passe finale où l'on corrigeait les fautes de frappe et les oublis. La façon dont je travaillais, il semblait que la programmation consistait en du débogage.

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

Réaliser cela a de réelles implications pour la conception de logiciels. Cela signifie qu'un langage de programmation devrait, avant tout, être malléable. Un langage de programmation sert à penser des programmes, pas à exprimer des programmes que vous avez déjà pensés. Il devrait être un crayon, pas un stylo. Le typage statique serait une excellente idée si les gens écrivaient réellement des programmes comme on me l'a appris à 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 gribouiller, de barbouiller et d'étaler, pas d'un langage où il faut s'asseoir avec une tasse de types équilibrée sur vos genoux et faire la conversation polie avec une vieille tante stricte de compilateur.

Pendant que nous sommes sur le sujet du typage statique, s'identifier aux créateurs nous sauvera d'un autre problème qui afflige les sciences : la jalousie des maths. 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 vous vous éloignez des sciences naturelles, plus cela devient un problème.

Une page de formules a l'air tellement impressionnante. (Astuce : pour plus d'impression, utilisez des variables grecques.) Et donc il y a une grande tentation de travailler sur des problèmes que l'on peut traiter formellement, plutôt que sur des problèmes qui sont, disons, 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 des maths. Ils ont l'impression de faire quelque chose de complètement sans rapport. Les hackers aussi, je pense.

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

Je n'ai découvert cela moi-même que très récemment. Quand Yahoo a acheté Viaweb, ils m'ont demandé ce que je voulais faire. Je n'avais jamais beaucoup aimé le côté commercial, et j'ai dit que je voulais juste hacker. Quand je suis arrivé chez Yahoo, j'ai découvert que pour eux, hacker 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 juste) 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 des logiciels, 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 organisent les choses de manière à ce qu'il soit conçu par un comité, et les hackers ne font qu'implémenter le design.

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 diminuer l'écart-type des résultats de conception parce qu'elles veulent éviter les désastres. Mais quand vous amortissez les oscillations, vous perdez les points hauts aussi bien que les points bas. Ce n'est pas un problème pour les grandes entreprises, car elles ne gagnent pas en créant de super produits. Les grandes entreprises gagnent en étant moins mauvaises que les autres grandes entreprises.

Donc, si vous pouvez trouver un moyen d'entrer en guerre de design avec une entreprise suffisamment grande pour que son logiciel soit conçu par des chefs de produit, elles ne pourront jamais vous suivre. Ces opportunités ne sont cependant pas faciles à trouver. Il est difficile d'engager une grande entreprise dans une guerre de design, tout comme il est difficile d'engager un adversaire à l'intérieur d'un château dans un combat au corps à corps. Il serait assez facile d'écrire un meilleur traitement de texte que Microsoft Word, par exemple, mais Microsoft, au sein du château de son monopole de système d'exploitation, ne le remarquerait probablement même pas si vous le faisiez.

Le lieu pour mener des guerres de design est dans les nouveaux marchés, où personne n'a encore réussi à établir de fortifications. C'est là que vous pouvez gagner gros en adoptant une approche audacieuse du design, et en ayant les mêmes personnes qui conçoivent et implémentent le produit. Microsoft l'a fait au début. Apple aussi. Et Hewlett-Packard. Je soupçonne que presque toutes les startups à succès l'ont fait.

Donc, une façon de construire de super logiciels est de créer votre propre startup. Il y a cependant deux problèmes à cela. Le premier est que dans une startup, vous devez faire tellement de choses en plus d'écrire des logiciels. Chez Viaweb, je me considérais chanceux si je pouvais hacker un quart du temps. Et les choses que je devais faire les trois autres quarts du temps allaient de l'ennuyeux au terrifiant. J'ai une référence pour cela, car j'ai dû un jour quitter une réunion de conseil d'administration pour me faire soigner des caries. Je me souviens m'être assis sur le fauteuil du dentiste, attendant la fraise, et avoir eu l'impression d'être en vacances.

L'autre problème avec les startups est qu'il n'y a pas beaucoup de chevauchement 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 paiera pour des langages de programmation maintenant. Si vous voulez gagner de l'argent, vous avez tendance à être forcé de travailler sur des problèmes trop désagréables pour que quiconque les résolve gratuitement.

Tous les créateurs sont confrontés à ce problème. Les prix sont déterminés par l'offre et la demande, et il n'y a tout simplement pas autant de demande pour les choses amusantes à travailler que pour les choses qui résolvent les problèmes quotidiens des clients individuels. Jouer dans des pièces de théâtre off-Broadway ne rapporte tout simplement pas autant que de porter un costume de gorille sur le stand de quelqu'un lors d'un salon professionnel. Écrire des romans ne rapporte pas autant que d'écrire des textes publicitaires pour des broyeurs de déchets. Et hacker des langages de programmation ne rapporte pas autant que de trouver 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 gagne-pain. Cette expression a commencé avec les musiciens, qui se produisent la nuit. Plus généralement, cela signifie que vous avez un type de travail que vous faites pour l'argent, et un autre par amour.

Presque tous les créateurs ont un gagne-pain 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 gagne-pain étroitement lié à votre vrai 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 pourrait de même obtenir un gagne-pain en l'utilisant. [1]

Quand je dis que la réponse est que les hackers aient un gagne-pain, et travaillent sur de beaux logiciels à côté, je ne propose pas cela comme une nouvelle idée. C'est de cela qu'il s'agit dans 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 créateurs.

Il me semble surprenant qu'un employeur hésite à laisser les hackers travailler sur des projets open-source. Chez Viaweb, nous aurions hésité à embaucher quiconque ne le faisait pas. Lorsque nous interviewions des programmeurs, la principale chose qui nous importait était le type de logiciel qu'ils écrivaient pendant leur temps libre. Vous ne pouvez rien faire de vraiment bien à moins de l'aimer, et si vous aimez hacker, vous travaillerez inévitablement sur vos propres projets. [2]

Parce que les hackers sont des créateurs plutôt que des scientifiques, le bon endroit pour chercher des métaphores n'est pas 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 à hacker. On apprend à peindre principalement en le faisant. Idem pour le hacking. La plupart des hackers n'apprennent pas à hacker en suivant des cours de programmation à l'université. Ils apprennent à hacker en écrivant leurs propres programmes à l'âge de treize ans. Même dans les cours universitaires, on apprend à hacker principalement en hackant. [3]

Parce que les peintres laissent une trace de leur travail derrière eux, vous pouvez les voir apprendre en faisant. Si vous regardez le travail d'un peintre par ordre chronologique, vous constaterez que chaque tableau s'appuie sur des choses apprises dans les précédents. Quand il y a quelque chose dans un tableau qui fonctionne très bien, vous pouvez généralement en trouver la 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 le faire aussi. Peut-être serait-il bon que les hackers agissent 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'incorporer toutes leurs idées ultérieures comme des révisions.

Le fait que les hackers apprennent à hacker 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 la faisant, mais en faisant des travaux pratiques et des séries d'exercices. Les scientifiques commencent par faire un travail parfait, dans le sens où ils essaient juste de reproduire un travail que quelqu'un d'autre a déjà fait pour eux. Finalement, ils en arrivent au point où ils peuvent faire un travail original. Alors que les hackers, dès le début, font un travail original ; il est juste très mauvais. Ainsi, les hackers commencent originaux, et deviennent bons, et les scientifiques commencent bons, et deviennent originaux.

L'autre façon dont les créateurs apprennent est par l'exemple. Pour un peintre, un musée est une bibliothèque de référence de techniques. Pendant des centaines d'années, il a fait partie de l'éducation traditionnelle des peintres de copier les œuvres des grands maîtres, car copier vous force à regarder attentivement la façon dont un tableau est fait.

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

Les hackers, de même, peuvent apprendre à programmer en regardant de bons programmes — non seulement ce qu'ils font, mais aussi le code source. L'un des avantages moins médiatisés 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 dans les livres. La seule grande quantité de code disponible alors était Unix, mais même cela 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 été autorisé à être publié qu'en 1996.

Un autre exemple que nous pouvons tirer de la peinture est la façon dont les tableaux sont créés par affinage progressif. Les tableaux commencent généralement par une esquisse. Progressivement, les détails sont remplis. Mais ce n'est pas seulement un processus de remplissage. Parfois, les plans originaux s'avèrent erronés. D'innombrables tableaux, quand vous les regardez aux rayons X, révèlent 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 fonctionner de cette façon aussi. Il est irréaliste de s'attendre à ce que les spécifications d'un programme soient parfaites. Vous êtes mieux si vous l'admettez dès le départ, et écrivez des programmes d'une manière qui permet aux spécifications de changer à la volée.

(La structure des grandes entreprises rend cela difficile pour elles, donc voici un autre endroit où les startups ont un avantage.)

Tout le monde connaît maintenant le danger de l'optimisation prématurée. Je pense que nous devrions être tout aussi préoccupés par la conception prématurée — décider trop tôt ce qu'un programme devrait faire.

Les bons outils peuvent nous aider à éviter ce danger. Un bon langage de programmation devrait, comme la peinture à l'huile, faciliter le changement d'avis. Le typage dynamique est un avantage ici car vous n'avez pas à vous engager sur des représentations de données spécifiques dès le départ. 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 ressemble à un paradoxe, mais une grande peinture doit être meilleure qu'elle n'a besoin de l'être. Par exemple, lorsque Leonardo 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 y a soigneusement peint chaque feuille individuelle. Beaucoup de peintres auraient pu penser, c'est juste quelque chose à mettre en arrière-plan pour encadrer sa tête. Personne ne le regardera d'aussi près.

Pas Leonardo. La difficulté avec laquelle il travaillait sur une partie d'un tableau ne dépendait absolument pas de la proximité avec laquelle il s'attendait à ce que quelqu'un la regarde. Il était comme Michael Jordan. Implacable.

L'implacabilité gagne parce que, dans l'ensemble, les détails invisibles deviennent visibles. Lorsque les gens passent devant le portrait de Ginevra de Benci, leur attention est souvent immédiatement captivée par celui-ci, avant même qu'ils ne regardent l'étiquette et ne remarquent qu'il est écrit Leonardo da Vinci. Tous ces détails invisibles se combinent pour produire quelque chose de tout simplement époustouflant, comme mille voix à peine audibles chantant toutes juste.

Les grands logiciels, de même, exigent une dévotion fanatique à la beauté. Si vous regardez à l'intérieur d'un bon logiciel, vous constatez que les parties que personne n'est censé voir sont belles aussi. Je ne prétends pas écrire de grands 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 implémenteur, transformant un cahier des charges en code, alors il pourrait simplement le parcourir 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.

Dans le hacking, comme la peinture, le travail se fait par cycles. Parfois, vous êtes enthousiasmé par un nouveau projet et vous voulez y travailler seize heures par jour. D'autres fois, rien ne semble intéressant.

Pour faire du bon travail, il faut 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 colline, vous devez parfois relâcher l'embrayage pour éviter de caler. Relâcher peut de même empêcher l'ambition de caler. Dans la peinture comme dans le hacking, il y a des tâches terriblement ambitieuses, et d'autres confortablement routinières. C'est une bonne idée de garder quelques tâches faciles pour les moments où vous caleriez autrement.

Dans le hacking, cela peut littéralement signifier garder des bugs en réserve. J'aime le débogage : c'est la seule fois où le hacking est aussi simple que les gens le pensent. Vous avez un problème totalement contraint, 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ù est-ce que ça tourne mal ? 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 comment gérer notre propre travail, mais aussi comment travailler ensemble. Une grande partie de l'art du passé est l'œuvre de plusieurs mains, même s'il n'y a qu'un seul nom sur le mur à côté au musée. Leonardo était apprenti dans l'atelier de Verrocchio et a peint l'un des anges de son Baptême du Christ. Ce genre de chose était la règle, pas l'exception. Michelangelo était considéré comme particulièrement dévoué pour avoir insisté à peindre lui-même toutes les figures du plafond de la Chapelle Sixtine.

Autant que je sache, lorsque les peintres travaillaient ensemble sur un tableau, ils ne travaillaient jamais sur les mêmes parties. Il était courant que le maître peigne les figures principales et que les assistants peignent les autres et l'arrière-plan. Mais vous n'avez jamais eu un gars qui peignait par-dessus le travail d'un autre.

Je pense que c'est le bon modèle pour la collaboration en logiciel aussi. N'allez pas trop loin. Quand un morceau de code est hacké par trois ou quatre personnes différentes, dont aucune ne le possède vraiment, il finira par ressembler à une salle commune. Il aura tendance à paraître désolé et abandonné, et à accumuler des scories. La bonne façon de collaborer, je pense, est de diviser les projets en modules clairement définis, chacun avec un propriétaire défini, et avec des interfaces entre eux qui sont aussi soigneusement conçues et, si possible, aussi articulées que les langages de programmation.

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

Quand j'étais enfant, on me disait toujours de voir les choses du point de vue de quelqu'un d'autre. Ce que cela signifiait toujours en pratique, c'était de faire ce que quelqu'un d'autre voulait, au lieu de ce que je voulais. Cela a bien sûr donné mauvaise réputation à l'empathie, et je me suis fait un point d'honneur de ne pas la cultiver.

Mon Dieu, comme j'avais tort. Il s'avère que voir les choses du point de vue des autres est pratiquement le secret du succès. Cela ne signifie pas nécessairement être altruiste. Loin de là. Comprendre comment quelqu'un d'autre voit les choses n'implique pas que vous agirez dans son intérêt ; dans certaines situations — en guerre, par exemple — vous voulez faire exactement le contraire. [4]

La plupart des créateurs font des choses pour un public humain. Et pour engager un public, il faut comprendre ce dont il a besoin. Presque toutes les plus grandes peintures sont des portraits de personnes, par exemple, parce que les gens s'intéressent aux gens.

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

Une façon de juger la capacité des gens à l'empathie est de les regarder expliquer une question technique à quelqu'un sans formation technique. Nous connaissons probablement tous des gens qui, bien qu'intelligents par ailleurs, sont comiquement mauvais à cela. Si quelqu'un leur demande lors d'un dîner ce qu'est un langage de programmation, ils diront 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. » Langage de haut niveau ? Compilateur ? Code objet ? Quelqu'un qui ne sait pas ce qu'est un langage de programmation ne sait évidemment pas ce que sont ces choses non plus.

Une partie de ce que le logiciel doit faire est de s'expliquer. Donc, pour écrire un bon logiciel, il faut comprendre à quel point les utilisateurs comprennent peu. Ils vont aborder le logiciel sans préparation, et il ferait mieux de faire ce qu'ils devinent qu'il fera, car ils ne liront pas le manuel. Le meilleur système que j'aie jamais vu à cet égard était le Macintosh original, en 1985. Il faisait ce que le logiciel ne fait presque jamais : il fonctionnait tout simplement. [6]

Le code source, lui aussi, devrait s'expliquer. Si je pouvais faire en sorte que les gens ne retiennent qu'une seule citation sur la programmation, ce serait celle du début de Structure and Interpretation of Computer Programs.

Les programmes devraient être écrits pour être lus par les humains, et seulement accessoirement pour être exécutés par les machines.

Vous devez avoir de l'empathie non seulement pour vos utilisateurs, mais aussi pour vos lecteurs. C'est dans votre intérêt, car vous en ferez partie. Plus d'un hacker a écrit un programme pour découvrir six mois plus tard qu'il n'avait aucune idée de son fonctionnement. Je connais plusieurs personnes qui ont juré de ne plus utiliser Perl après de telles expériences. [7]

Le manque d'empathie est associé à l'intelligence, au point qu'il y a même une sorte de mode pour cela à 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 en sont venues à être associées. Mais il y a aussi beaucoup de gens stupides qui sont mauvais en empathie. Il suffit d'écouter les gens qui appellent avec des questions lors des émissions de radio. Ils posent leur question de manière si détournée que les animateurs doivent souvent reformuler la question pour eux.

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

Malheureusement, la question est difficile à répondre. Il y a toujours un grand décalage temporel dans le prestige. C'est comme la lumière d'une étoile lointaine. La peinture a du prestige maintenant grâce au grand travail que des gens ont fait il y a cinq cents ans. À l'époque, personne ne pensait que ces tableaux étaient aussi importants que nous le faisons aujourd'hui. Il aurait semblé très étrange aux gens de l'époque que Federico da Montefeltro, le duc d'Urbino, soit un jour connu principalement comme le gars au nez étrange dans un tableau de Piero della Francesca.

Donc, bien que j'admette que le hacking ne semble pas aussi cool que la peinture maintenant, nous devrions nous souvenir que la peinture elle-même ne semblait pas aussi cool à son apogée qu'elle ne l'est maintenant.

Ce que nous pouvons dire avec une certaine confiance, c'est que ce sont les jours de gloire du hacking. Dans la plupart des domaines, le grand travail est fait tôt. Les tableaux réalisés entre 1430 et 1500 sont toujours inégalés. Shakespeare est apparu juste au moment où le théâtre professionnel naissait, et a poussé le médium si loin que chaque dramaturge depuis a dû vivre dans son ombre. Albrecht Durer a fait la même chose avec la gravure, et Jane Austen avec le roman.

Encore et encore, nous voyons le même schéma. Un nouveau médium apparaît, et les gens sont tellement enthousiasmés par celui-ci qu'ils explorent la plupart de ses possibilités au cours des deux premières générations. Le hacking semble être dans cette phase maintenant.

La peinture n'était pas, à l'époque de Leonardo, aussi cool que son travail a contribué à la rendre. À quel point le hacking s'avérera cool dépendra de ce que nous pourrons faire avec ce nouveau médium.

Notes

[1] Le plus grand dommage que la photographie ait fait à la peinture est peut-être le fait qu'elle a tué le meilleur gagne-pain. La plupart des grands peintres de l'histoire se sont soutenus en peignant des portraits.

[2] On m'a dit que Microsoft décourage les employés de contribuer à des projets open-source, même pendant leur temps libre. Mais tant des meilleurs hackers travaillent sur des projets open-source maintenant que l'effet principal de cette politique pourrait être de s'assurer qu'ils ne pourront embaucher aucun programmeur 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 : le mauvais goût que 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 : qu'est-ce que nos concurrents détesteraient le plus ? À un moment donné, un concurrent a ajouté une fonctionnalité à son logiciel qui était fondamentalement inutile, mais comme c'était l'une des rares qu'ils avaient et que nous n'avions pas, ils en ont 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 énerverait davantage notre concurrent si nous l'implémentions nous-mêmes, alors nous avons bricolé notre propre version cet après-midi-là.

[5] Sauf les éditeurs de texte et les 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 un peu dépassé la RAM disponible, causant beaucoup d'échanges de disque gênants, mais cela a pu être corrigé en quelques mois en achetant un lecteur de disque supplémentaire.

[7] La façon de rendre les programmes faciles à lire n'est pas de les bourrer de commentaires. Je pousserais la citation d'Abelson et Sussman un peu plus loin. Les langages de programmation devraient être conçus pour exprimer des algorithmes, et seulement accessoirement pour dire aux ordinateurs comment les exécuter. Un bon langage de programmation devrait être meilleur pour expliquer un logiciel que l'anglais. Vous ne devriez avoir besoin de commentaires que lorsqu'il y a une sorte de bricolage dont vous devez avertir les lecteurs, tout comme sur une route, il n'y a des flèches que sur les parties avec des virages inattendus.