HACKERS ET PEINTRES

Mai 2003

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

Quand j'ai fini 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 soit également intéressée par la peinture. Ils semblaient penser que le piratage et la peinture étaient des types de travail très différents - que le piratage était froid, précis et méthodique, et que la peinture était l'expression frénétique de quelque pulsion primaire.

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

Ce que les pirates et les peintres ont en commun, c'est qu'ils sont tous les deux des créateurs. Avec les compositeurs, les architectes et les écrivains, ce que les pirates et les peintres essaient de faire, c'est de créer de bonnes choses. Ils ne font pas de recherche à proprement parler, bien que s'ils découvrent une nouvelle technique au cours de leurs efforts pour créer de bonnes choses, 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'y a pas de telle chose. L'informatique est un fourre-tout de domaines faiblement liés, réunis par un accident de l'histoire, comme la Yougoslavie. À une extrémité, vous avez des gens qui sont en fait des mathématiciens, mais qui appellent ce qu'ils font de l'informatique afin de pouvoir 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 les données à travers les réseaux, par exemple. Et puis à l'autre extrémité, vous avez les pirates, qui essaient d' écrire des logiciels intéressants, et pour qui les ordinateurs ne sont qu'un moyen 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 pirates s'appelle "génie logiciel", 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 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 du quoi, et les ingénieurs déterminent le comment.

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 du quoi sans comprendre le comment. Mais le piratage peut certainement être plus que simplement décider comment mettre en œuvre une spécification. À son meilleur, c'est créer la spécification - bien que la meilleure façon de le faire soit de la mettre en œuvre.

Peut-être qu'un jour, l'"informatique" se décomposera, comme la Yougoslavie, en ses parties constitutives. Ce serait peut-être une bonne chose. Surtout si cela signifiait l'indépendance pour ma terre natale, le piratage.

Regrouper tous ces différents types de travail dans un même département peut être pratique sur le plan administratif, mais c'est confus intellectuellement. C'est l'autre raison pour laquelle je n'aime pas le nom "informatique". On pourrait soutenir que les gens du milieu font quelque chose comme une science expérimentale. Mais les gens aux deux extrémités, les pirates et les mathématiciens, ne font pas vraiment de la science.

Les mathématiciens ne semblent pas gênés par cela. Ils se mettent joyeusement au travail pour démontrer des théorèmes comme les autres mathématiciens dans le département de mathématiques, et probablement cessent bientôt de remarquer que le bâtiment dans lequel ils travaillent porte l'inscription "informatique" à l'extérieur. Mais pour les pirates, cette étiquette est un problème. Si ce qu'ils font est appelé science, cela leur donne l'impression qu'ils devraient se comporter de manière scientifique. Donc, au lieu de faire ce qu'ils veulent vraiment faire, qui est de concevoir de beaux logiciels, les pirates dans les universités et les laboratoires de recherche ont l'impression qu'ils devraient écrire des articles de recherche.

Dans le meilleur des cas, les articles ne sont qu'une formalité. Les pirates écrivent des logiciels cool, puis écrivent un article à ce sujet, et l'article devient un substitut pour la réalisation représentée par le logiciel. Mais souvent, ce décalage pose des problèmes. Il est facile de s'éloigner de la construction de belles choses pour se diriger vers la construction de choses laides qui conviennent mieux comme sujets d'articles de recherche.

Malheureusement, les belles choses ne font pas toujours les meilleurs sujets pour les articles. Premièrement, la recherche doit être originale - et comme le sait quiconque a écrit une thèse de doctorat, le moyen d'être sûr d'explorer 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 produisent des articles plus substantiels, car vous pouvez écrire sur les obstacles que vous devez surmonter pour arriver à vos fins. Rien ne produit de problèmes plus substantiels que de partir des mauvaises hypothèses. La majeure partie de l'IA en est un exemple ; si vous supposez que les connaissances peuvent être représentées sous forme d'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 disait Ricky Ricardo, "Lucy, tu as beaucoup d'explications à faire."

La meilleure 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 type de travail est difficile à transmettre dans un article de recherche.

Alors pourquoi les universités et les laboratoires de recherche continuent-ils à juger les pirates sur la base de 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 pirates essaient vraiment de faire, concevoir de beaux logiciels, serait beaucoup plus difficile. Vous avez besoin d'un bon sens du design pour juger d'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 leur capacité à le faire.

Le seul test externe est le temps. Au fil du temps, les belles choses ont tendance à prospérer, et les choses laides ont tendance à être rejetées. Malheureusement, les durées impliquées peuvent être plus longues que des vies humaines. Samuel Johnson a dit qu'il fallait cent ans pour que la réputation d'un écrivain se stabilise. Vous devez attendre que les amis influents de l'écrivain meurent, puis que tous leurs disciples meurent.

Je pense que les pirates doivent simplement se résigner à avoir une grande part de hasard dans leur réputation. En cela, ils ne sont pas différents des autres créateurs. En fait, ils ont de la chance par comparaison. L'influence de la mode n'est pas du tout aussi grande dans le piratage que dans la peinture.

Il y a pire que de voir les gens mal comprendre votre travail. Un danger plus grand est que vous-même ne compreniez pas votre travail. C'est dans les domaines connexes que vous allez chercher des idées. Si vous vous retrouvez dans le département d'informatique, il est naturellement tentant de croire, par exemple, que le piratage est la version appliquée de ce dont la théorie de l'informatique est la théorie.

Tout le temps où j'étais à l'école supérieure, j'avais un sentiment désagréable au fond de mon esprit que je devrais en savoir plus sur la théorie, et que c'était très négligent de ma part d'avoir oublié tout ce fatras dans les trois semaines suivant l'examen final.

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

J'ai constaté que les meilleures sources d'idées ne sont pas les autres domaines qui ont le mot "informatique" dans leur nom, mais les autres domaines habités par des créateurs. La peinture a été une source d'idées beaucoup plus riche que la théorie de l'informatique.

Par exemple, on m'a enseigné à l'université qu'on devrait complètement mettre au point un programme 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 devant 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 vomir du code complètement cassé, et à le façonner progressivement. Le débogage, m'a-t-on enseigné, était une sorte de passe finale où l'on attrapait 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, j'ai eu honte de cela, tout comme j'ai déjà eu honte de ne pas tenir mon crayon de la façon dont on me l'avait enseigné à l'école primaire. Si j'avais seulement 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 puisse en juger, la façon dont on m'a enseigné à programmer à l'université était complètement fausse. Vous devriez concevoir des programmes au fur et à mesure que vous les écrivez, tout comme les écrivains, les peintres et les architectes le font.

Réaliser cela a de véritables 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 auxquels vous avez déjà pensé. Il devrait être un crayon, pas un stylo. Le typage statique serait une bonne idée si les gens écrivaient réellement des programmes de la manière dont on me l'a enseigné à l'université. Mais ce n'est pas comme ça que les hackers que je connais écrivent des programmes. Nous avons besoin d'un langage qui nous laisse gribouiller, estomper et barbouiller, pas d'un langage où vous devez vous asseoir avec une tasse de thé remplie de types équilibrée sur le genou et avoir une conversation polie avec une vieille tante de compilateur stricte.

Pendant que nous en sommes au sujet du typage statique, s'identifier aux créateurs nous épargnera un autre problème qui afflige les sciences : l'envie des mathématiques. 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 le plus mathématique 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 a l'air tellement impressionnante. (Astuce : pour un surcroît d'impressionnisme, utilisez des variables grecques.) Et donc il y a une grande tentation de travailler sur des problèmes que vous pouvez traiter de manière formelle, 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 se sentiraient pas tentés de faire cela. Les écrivains et les peintres ne souffrent pas d'envie des mathématiques. Ils ont l'impression de faire quelque chose de complètement différent. 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 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 que tout 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 constaté que ce que le piratage signifiait pour eux, c'était mettre en œuvre des logiciels, pas les concevoir. Les programmeurs étaient considérés comme des techniciens qui traduisaient les visions (si c'est le mot) des gestionnaires de produits 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 peuvent vraiment concevoir des logiciels, et il est difficile pour les personnes qui dirigent une entreprise de les repérer. Donc, au lieu de confier l'avenir du logiciel à un brillant hacker, la plupart des entreprises s'organisent de manière à ce qu'il soit conçu par un comité, et les hackers ne font qu'en mettre en œuvre la conception.

Si vous voulez gagner de l'argent à un moment donné, n'oubliez pas 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 catastrophes. Mais quand vous amortissez les oscillations, vous perdez les points hauts aussi bien que les bas. Ce n'est pas un problème pour les grandes entreprises, car elles ne gagnent pas en faisant de grands produits. Les grandes entreprises gagnent en étant moins mauvaises que les autres grandes entreprises.

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

Le lieu pour mener des guerres de conception se trouve sur de 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 de la conception et en faisant en sorte que les mêmes personnes conçoivent et mettent en œuvre le produit. Microsoft lui-même a fait cela 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 créer un excellent logiciel est de lancer votre propre startup. Il y a cependant deux problèmes avec cela. L'un est que dans une startup, vous devez faire tellement d'autres choses que d'écrire du logiciel. Chez Viaweb, je me considérais comme chanceux si je pouvais coder un quart du temps. Et les choses que je devais faire les trois autres quarts du temps allaient de l'ennuyeux à l'effrayant. 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 quelques caries. Je me souviens d'être assis dans le fauteuil du dentiste, en attendant la perceuse, et d'avoir l'impression d'être en vacances.

L'autre problème avec les startups est qu'il y a peu 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 répugnants pour que quelqu'un 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 à faire que pour les choses qui résolvent les problèmes banals des clients individuels. Jouer dans des pièces off-Broadway ne rapporte pas autant que de porter un costume de gorille dans le stand de quelqu'un lors d'un salon commercial. Écrire des romans ne rapporte pas autant qu'écrire des textes publicitaires pour des broyeurs à déchets. Et le piratage de langages de programmation ne rapporte pas autant que de trouver un moyen de 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 du logiciel, est un concept connu de presque tous les créateurs : le travail alimentaire. 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 pour l'amour.

Presque tous les créateurs ont un travail alimentaire au début de leur carrière. Les peintres et les écrivains le font notoire. Si vous avez de la chance, vous pouvez obtenir un travail alimentaire étroitement lié à votre véritable travail. Les musiciens travaillent souvent dans des magasins de disques. Un hacker travaillant sur un langage de programmation ou un système d'exploitation pourrait également pouvoir obtenir un travail alimentaire l'utilisant. [1]

Quand je dis que la réponse est que les hackers aient un travail alimentaire et travaillent sur un beau logiciel sur leur temps libre, je ne propose pas cela comme une nouvelle idée. C'est ce que le piratage open source est tout sur. Ce que je dis, c'est que l'open source est probablement le bon modèle, car il a été indépendamment confirmé par tous les autres créateurs.

Il me semble surprenant que tout employeur serait réticent à laisser les hackers travailler sur des projets open source. Chez Viaweb, nous aurions été réticents à embaucher quelqu'un qui ne le faisait pas. Quand nous interviewions 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 vraiment bien à moins que vous ne l'aimiez, et si vous aimez le piratage, 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 la peinture sur le piratage ?

Une chose que nous pouvons apprendre, ou du moins confirmer, de l'exemple de la peinture, est comment apprendre à pirater. Vous apprenez à peindre surtout en le faisant. Pareil pour le piratage. La plupart des hackers n'apprennent pas à pirater en suivant des cours universitaires de programmation. Ils apprennent à pirater en écrivant des programmes à leur compte dès l'âge de treize ans. Même dans les cours universitaires, vous apprenez à pirater surtout en piratant. [3]

Parce que les peintres laissent une trace de leur travail derrière eux, vous pouvez les regarder apprendre en faisant. Si vous regardez le travail d'un peintre dans l'ordre chronologique, vous constaterez que chaque peinture s'appuie sur des choses qui ont été apprises dans les précédentes. Quand il y a quelque chose dans une peinture qui fonctionne très bien, vous pouvez généralement en trouver la version 1 sous une forme plus petite dans une peinture antérieure.

Je pense que la plupart des créateurs travaillent de cette manière. Les écrivains et les architectes semblent également le faire. 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 plus récentes 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 piratage et les sciences. Les scientifiques n'apprennent pas la science en la faisant, mais en faisant des travaux pratiques et des exercices. Les scientifiques commencent par faire un travail parfait, dans le sens où ils essaient simplement 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. Tandis que les hackers, dès le départ, font un travail original ; c'est juste très mauvais. Donc 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 à partir d'exemples. Pour un peintre, un musée est une bibliothèque de référence de techniques. Depuis des centaines d'années, il fait partie de l'éducation traditionnelle des peintres de copier les œuvres des grands maîtres, car la copie vous oblige à regarder de près la façon dont une peinture est réalisée.

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 histoires de détective.

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 bénéfices 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 à des exemples dans les livres. Le seul gros morceau de code alors disponible était Unix, mais même celui-ci n'était pas open source. La plupart des gens qui ont lu la source l'ont fait dans des photocopies illicites du livre de John Lions, qui, bien qu'écrit en 1977, n'a pas été autorisé à être publié avant 1996.

Voici la traduction en français :

Un autre exemple que nous pouvons tirer de la peinture est la façon dont les peintures sont créées par un raffinement progressif. Les peintures 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 d'origine s'avèrent être erronés. De nombreuses peintures, lorsque vous les examinez aux rayons X, s'avèrent 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 piratage devrait également fonctionner de cette manière. Il est irréaliste de s'attendre à ce que les spécifications d'un programme soient parfaites. Vous feriez mieux d'admettre cela d'emblée et d'écrire des programmes d'une manière qui permette 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 sait maintenant présumément 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 de 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. La saisie dynamique est un atout 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 peut sembler paradoxal, mais une grande peinture doit être meilleure qu'elle ne le doit. Par exemple, lorsque Léonard a peint le portrait de Ginevra de Benci à la National Gallery, il a placé un buisson de genévriers derrière sa tête. Il a soigneusement peint chaque feuille individuelle. De nombreux peintres auraient pu penser que ce n'est qu'un élément à placer en arrière-plan pour encadrer sa tête. Personne ne le regardera de si près.

Pas Léonard. La difficulté avec laquelle il a travaillé sur une partie d'une peinture ne dépendait en rien 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 captée par lui, même avant qu'ils ne regardent l'étiquette et ne remarquent qu'il porte la signature de Léonard de Vinci. Tous ces détails invisibles se combinent pour produire quelque chose de tout simplement époustouflant, comme mille voix à peine audibles chantant en harmonie.

Un grand logiciel, de même, nécessite un dévouement fanatique à la beauté. Si vous regardez à l'intérieur d'un bon logiciel, vous trouverez 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 de tous les jours de la même manière. Ça me rend fou de voir du code mal indenté ou qui utilise de vilains noms de variables.

Si un hacker n'était qu'un simple implémenteur, transformant une spécification en code, il pourrait simplement y travailler d'un bout à l'autre comme quelqu'un qui creuse une tranchée. Mais si le hacker est un créateur, nous devons tenir compte de l'inspiration.

En piratage, comme en peinture, le travail se fait par cycles. Parfois, vous vous enthousiasmez pour 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, 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 avec une boîte de vitesses manuelle dans une côte, vous devez parfois relâcher l'embrayage pour éviter de caler. Se retirer peut également empêcher l'ambition de caler. Tant en peinture qu'en piratage, il y a des tâches terriblement ambitieuses et d'autres qui sont réconfortantes de routine. Il est judicieux de réserver quelques tâches faciles pour les moments où vous stagneriez autrement.

En piratage, cela peut littéralement signifier de conserver des bogues. J'aime déboguer : c'est le seul moment où le piratage 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ù se trompe-t-il ? Vous savez que vous allez gagner à la fin. C'est aussi relaxant que de peindre un mur.

L'exemple de la peinture peut nous enseigner non seulement comment gérer notre propre travail, mais aussi comment travailler ensemble. Une grande partie des grands arts du passé est l'œuvre de plusieurs mains, bien qu'il n'y ait qu'un seul nom sur le mur à côté dans le musée. Léonard était apprenti dans l'atelier de Verrocchio et a peint l'un des anges dans son Baptême du Christ. Ce genre de chose était la règle, pas l'exception. Michelange était considéré comme particulièrement dévoué pour avoir insisté pour peindre toutes les figures du plafond de la Chapelle Sixtine lui-même.

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

Je pense que c'est le bon modèle pour la collaboration dans les logiciels aussi. Ne le poussez pas trop loin. Lorsqu'un morceau de code est piraté par trois ou quatre personnes différentes, dont aucune ne le possède vraiment, il finira par ressembler à une salle commune. Il aura tendance à se sentir morne et abandonné, et à s'accumuler en déchets. 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 exceptionnel. Vous devez être capable de voir les choses du point de vue de l'utilisateur.

Quand j'étais enfant, on me disait toujours d'essayer 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é une mauvaise réputation à l'empathie, et je me suis fait un point de ne pas la cultiver.

Eh bien, je me suis trompé. 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 ê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 temps de guerre, par exemple - vous voulez faire exactement le contraire. [4]

La plupart des créateurs créent des choses pour un public humain. Et pour engager un public, vous devez comprendre ce dont ils ont besoin. Presque tous les plus grands tableaux sont des peintures de personnes, par exemple, parce que les gens sont ce qui intéresse les gens.

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

Une façon de savoir à quel point les gens sont doués d'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 tout simplement comiquement mauvais à cet égard. Si quelqu'un leur demande à 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 non plus ce que sont ces choses.

Une partie de ce que le logiciel doit faire est de s'expliquer lui-même. Donc pour écrire un bon logiciel, vous devez comprendre à quel point les utilisateurs en savent peu. Ils vont s'approcher du logiciel sans aucune préparation, et il vaut mieux qu'il fasse ce qu'ils devinent qu'il fera, car ils ne vont pas lire le manuel. Le meilleur système que j'aie jamais vu à cet égard était le Macintosh d'origine, en 1985. Il faisait ce que le logiciel ne fait presque jamais : il fonctionnait simplement. [6]

Le code source, lui aussi, devrait s'expliquer de lui-même. Si je pouvais faire retenir à des gens une seule citation sur la programmation, ce serait celle qui se trouve au début de Structure and Interpretation of Computer Programs.

Les programmes doivent être écrits pour que les gens les lisent, et seulement accessoirement pour que les machines les exécutent.

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 se rendre compte, six mois plus tard, qu'il n'a aucune idée de la façon dont il fonctionne. 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 dans certains endroits. Mais je ne pense pas qu'il y ait de corrélation. Vous pouvez réussir en mathématiques et dans les sciences naturelles sans avoir à apprendre l'empathie, et les gens dans ces domaines ont tendance à être intelligents, de sorte que les deux qualités en sont venues à être associées. Mais il y a beaucoup de gens stupides qui sont aussi mauvais en empathie. Il suffit d'écouter les gens qui appellent avec des questions dans les émissions de radio. Ils posent leur question d'une manière tellement détournée que les animateurs doivent souvent la reformuler pour eux.

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

Malheureusement, la question est difficile à répondre. Il y a toujours un gros décalage dans le prestige. C'est comme la lumière d'une étoile lointaine. La peinture a maintenant du prestige à cause des grands travaux réalisés il y a cinq cents ans. À l'époque, personne ne pensait que ces peintures étaient aussi importantes que nous le pensons aujourd'hui. Il aurait semblé très étrange aux gens de l'époque que Federico da Montefeltro, le duc d'Urbino, soit surtout connu pour son étrange nez dans un tableau de Piero della Francesca.

Donc, bien que j'admette que le piratage ne semble pas aussi cool que la peinture maintenant, nous devrions nous rappeler que la peinture elle-même n'a pas semblé aussi cool à l'époque de sa gloire 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 piratage. Dans la plupart des domaines, les grands travaux sont réalisés au début. Les peintures réalisées entre 1430 et 1500 sont encore sans égales. Shakespeare est apparu juste au moment où le théâtre professionnel naissait, et a tellement fait progresser le médium 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 excités à ce sujet qu'ils explorent la plupart de ses possibilités dans les deux premières générations. Le piratage semble être dans cette phase maintenant.

La peinture n'était pas, à l'époque de Léonard, aussi cool que son travail a contribué à la rendre. À quel point le piratage finira par être 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 emploi alimentaire. 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 tellement des meilleurs hackers travaillent maintenant sur des projets open source que l'effet principal de cette politique peut être de s'assurer qu'ils ne pourront pas embaucher de programmeurs de première classe.

[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 point vous aviez mauvais goût au lycée.

[4] Voici un exemple d'empathie appliquée. Chez Viaweb, si nous ne pouvions pas choisir entre deux alternatives, nous demandions : que détesteraient le plus nos concurrents ? À 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 beaucoup parlé dans la presse professionnelle. 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 l'avons bricolée en un après-midi.

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

[6] Eh bien, presque. Ils ont un peu dépassé la RAM disponible, provoquant de nombreux échanges de disque gênants, mais cela pouvait être corrigé en quelques mois en achetant un disque supplémentaire.

[7] Le moyen de rendre les programmes faciles à lire n'est pas de les remplir de commentaires. J'irais encore plus loin que la citation d'Abelson et Sussman. 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 le logiciel que l'anglais. Vous ne devriez avoir besoin de commentaires que lorsqu'il y a un genre 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 courbes étonnamment aiguës.

Merci à Trevor Blackwell, Robert Morris, Dan Giffin et Lisa Randall d'avoir lu les brouillons de ceci, et à Henry Leitner et Larry Finkelstein de m'avoir invité à prendre la parole.