HACKERS ET PEINTRES

May 2003

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

Lorsque 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 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 primal.

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

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 créer de bonnes choses. Ils ne font pas de recherche à proprement parler, mais si au cours de leur tentative de créer de bonnes choses, ils découvrent une nouvelle technique, 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 mélange d'aires à peine liées, rassemblées par un accident de l'histoire, comme la Yougoslavie. À une extrémité, vous avez des gens qui sont vraiment des 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 travaillant sur quelque chose comme l'histoire naturelle des ordinateurs-- étudiant le comportement des algorithmes pour le routage des données à travers les réseaux, par exemple. Et puis à l'autre extrême, vous avez les hackers, qui essaient de é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 hackers est appelé "ingénierie logicielle", mais ce terme est tout aussi trompeur. De bons concepteurs de logiciels ne sont pas plus des ingénieurs que les architectes ne le sont. La frontière entre l'architecture et l'ingénierie n'est pas clairement définie, mais elle existe. Elle se situe entre quoi et comment : les architectes décident quoi faire, et les ingénieurs déterminent comment le faire.

Quoi et comment ne devraient pas être trop séparés. Vous demandez des ennuis 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 une spécification. Au mieux, c'est créer la spécification-- bien que il s'avère que la meilleure façon de le faire est de l'implémenter.

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

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

Les mathématiciens ne semblent pas dérangés par cela. Ils se mettent joyeusement au travail pour prouver des théorèmes comme les autres mathématiciens du département de mathématiques, et probablement cessent bientôt de remarquer que le bâtiment dans lequel ils travaillent dit "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, qui est de concevoir des logiciels magnifiques, les hackers dans les universités et les laboratoires de recherche estiment qu'ils devraient écrire des articles de recherche.

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

Malheureusement, les belles choses ne font pas toujours les meilleurs sujets pour des articles. Numéro un, la recherche doit être originale-- et comme quiconque ayant écrit une thèse de doctorat le sait, la façon de s'assurer que vous explorez un territoire vierge est de revendiquer un morceau de terrain que personne ne veut. Numéro deux, la recherche doit être substantielle-- et les systèmes maladroits produisent des articles plus consistants, car vous pouvez écrire sur les obstacles que vous devez surmonter pour faire avancer les choses. Rien ne produit de problèmes consistants comme partir de mauvaises hypothèses. La plupart 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 de d'articles à écrire sur la façon de faire fonctionner cela. Comme le disait Ricky Ricardo, "Lucy, tu as beaucoup d'explications à faire."

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 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 hackers par leurs publications ? Pour la même raison que "l'aptitude scolaire" est mesurée par des tests standardisés simplistes, ou 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 à peu près.

Mesurer ce que les hackers essaient réellement de faire, concevoir des logiciels magnifiques, serait beaucoup plus difficile. Vous avez besoin d'un bon sens du design pour juger un bon design. Et il n'y a pas de 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. Au fil du temps, les belles choses ont tendance à prospérer, et les choses laides tendent à être rejetées. Malheureusement, les durées impliquées peuvent être plus longues que les vies humaines. Samuel Johnson a dit qu'il fallait cent ans pour qu'une réputation d'écrivain converge. Vous devez attendre que les amis influents de l'écrivain meurent, puis que tous leurs suiveurs meurent.

Je pense que les hackers doivent simplement se résigner à avoir un grand composant aléatoire dans leur réputation. Dans ce domaine, ils ne sont pas différents des autres créateurs. En fait, ils sont chanceux en comparaison. L'influence de la mode n'est pas aussi grande dans le hacking que dans la peinture.

Il y a des choses pires que d'avoir des gens qui ne comprennent pas votre travail. Un danger plus grave est que vous vous méprenez vous-même sur votre travail. Les domaines connexes sont là où vous allez 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 que l'informatique théorique est la théorie de. Tout le temps où j'étais à l'école supérieure, j'avais un sentiment inconfortable au fond de mon esprit que je devrais 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 j'avais tort. 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 peintures. Vous devez savoir comment calculer la complexité temporelle et spatiale et à propos de la complétude de Turing. Vous voudrez peut-être aussi vous souvenir au moins du concept d'une machine d'état, au cas où vous auriez à écrire un analyseur ou une bibliothèque d'expressions régulières. Les peintres, en fait, doivent se souvenir d'un bon nombre de choses sur la chimie des peintures.

J'ai constaté que les meilleures sources d'idées ne sont pas les autres domaines qui ont le mot "ordinateur" dans leurs noms, 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 la computation.

Par exemple, on m'a appris à l'université qu'il fallait d'abord concevoir un programme complètement sur papier avant même de s'approcher d'un ordinateur. J'ai découvert que je ne programmais pas de cette manière. J'ai constaté que j'aimais programmer assis devant un ordinateur, pas un morceau de papier. Pire encore, au lieu d'écrire patiemment un programme complet et de m'assurer qu'il était correct, j'avais tendance à simplement cracher du code qui était désespérément cassé, et à le façonner progressivement. On m'a appris que le débogage était une sorte de passage final où vous attrapiez des fautes de frappe et des oublis. De la manière dont je travaillais, il semblait que la programmation consistait à déboguer.

Pendant longtemps, je me suis senti mal à ce sujet, tout comme je me suis un jour senti mal de ne pas tenir mon crayon de la manière dont ils m'avaient appris à 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 : esquisse. Autant que je puisse en juger, la façon dont ils m'ont appris à programmer à l'université était complètement fausse. Vous devriez concevoir des 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 est pour penser des programmes, pas pour exprimer des programmes que vous avez déjà pensés. Il devrait être un crayon, pas un stylo. La typage statique serait une bonne idée si les gens écrivaient réellement des programmes de la manière dont ils m'ont 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 permet de gribouiller, de brouiller et de tacher, pas d'un langage où vous devez vous asseoir avec une tasse de types équilibrée sur vos genoux et faire la conversation polie avec une vieille tante stricte qu'est un compilateur.

Alors que nous sommes sur le sujet de la typage statique, s'identifier avec les créateurs nous sauvera d'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 croient aussi cela. Quoi qu'il en soit, 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 juste l'air si impressionnante. (Conseil : pour plus d'impression, utilisez des variables grecques.) Et il y a donc une grande tentation de travailler sur des problèmes que vous pouvez 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 se sentiraient pas tentés de faire cela. Les écrivains et les peintres ne souffrent pas de l'envie des mathématiques. Ils ont l'impression de faire quelque chose de complètement non lié. Les hackers le sont aussi, je pense.

Si les universités et les laboratoires de recherche empêchent les hackers de faire le type de travail qu'ils souhaitent faire, peut-être que leur place est dans des 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 récemment. Lorsque Yahoo a acheté Viaweb, ils m'ont demandé ce que je voulais faire. Je n'avais jamais aimé beaucoup le côté commercial, et j'ai dit que je voulais juste hacker. Quand je suis arrivé chez Yahoo, j'ai découvert que ce que le hacking signifiait pour eux était d'implémenter des logiciels, pas de 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. Ils le font parce que cela diminue l'écart type des résultats. Seul un petit pourcentage de hackers peut réellement concevoir des logiciels, et il est difficile pour les personnes qui dirigent une entreprise de les identifier. Au lieu de confier l'avenir du logiciel à un brillant hacker, la plupart des entreprises mettent en place des systèmes pour que ce soit conçu par un comité, et les hackers ne font que implémenter le design.

Si vous voulez gagner de l'argent à un moment donné, rappelez-vous 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 lorsque vous amortissez les oscillations, vous perdez les points hauts ainsi que les bas. Ce n'est pas un problème pour les grandes entreprises, car elles ne gagnent pas en créant de grands produits. Les grandes entreprises gagnent en étant moins mauvaises que d'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 chefs de produit, ils ne pourront jamais vous rattraper. 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 dans un combat corps à corps. Il 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 remarquerait probablement même pas si vous le faisiez.

L'endroit pour mener des guerres de conception est dans de nouveaux marchés, où personne n'a encore réussi à établir des fortifications. C'est là que vous pouvez gagner gros en adoptant une approche audacieuse de la conception, et en ayant les mêmes personnes concevant et implémentant le produit. Microsoft eux-mêmes ont fait cela au début. Apple aussi. Et Hewlett-Packard. Je soupçonne presque chaque startup réussie l'a fait.

Donc, une façon de créer un excellent logiciel est de commencer votre propre startup. Il y a cependant deux problèmes avec cela. L'un est qu'au sein d'une startup, vous devez faire beaucoup d'autres 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 quarts du temps allaient de l'ennuyeux au terrifiant. J'ai un point de référence pour cela, car j'ai une fois dû quitter une réunion du conseil d'administration pour faire remplir quelques caries. Je me souviens d'être assis dans le fauteuil du dentiste, attendant la perceuse, et de me sentir comme 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 était un, en fait, mais personne ne paiera pour des langages de programmation maintenant. Si vous voulez gagner de l'argent, vous êtes souvent contraint 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 des choses qui sont amusantes à travailler que pour des choses qui résolvent les problèmes banals des clients individuels. Jouer dans des pièces de théâtre off-Broadway ne paie tout simplement pas aussi bien que de porter un costume de gorille dans le stand de quelqu'un lors d'un salon professionnel. Écrire des romans ne paie pas aussi bien que d'écrire des textes publicitaires pour des broyeurs à déchets. Et hacker des langages de programmation ne paie pas aussi bien 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 travail de jour. Cette phrase 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 de l'argent, et un autre par amour.

Presque tous les créateurs ont des emplois de jour 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 de jour qui est é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 également être en mesure d'obtenir un emploi de jour en l'utilisant. [1]

Quand je dis que la réponse est que les hackers aient des emplois de jour, et travaillent sur des logiciels magnifiques à côté, je ne propose pas cela comme une nouvelle idée. C'est ce que le hacking open-source est tout à fait. 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 soit réticent à laisser les hackers travailler sur des projets open-source. Chez Viaweb, nous aurions été réticents à embaucher quiconque ne le faisait pas. Lorsque nous avons interviewé des programmeurs, la principale chose qui nous intéressait était quel type de logiciel ils écrivaient pendant leur temps libre. Vous ne pouvez rien faire vraiment bien à moins de l'aimer, et si vous aimez hacker, vous travaillerez inévitablement sur des projets qui vous tiennent à cœur. [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 encore nous apprendre 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. Vous apprenez à peindre principalement en le faisant. Idem pour le hacking. La plupart des hackers n'apprennent pas à hacker en suivant des cours universitaires de programmation. Ils apprennent à hacker en écrivant leurs propres programmes à l'âge de treize ans. Même dans les cours universitaires, vous apprenez à hacker principalement en hackant. [3]

Parce que les peintres laissent une trace de travail derrière eux, vous pouvez les voir 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. Lorsqu'il y a quelque chose dans une peinture qui fonctionne très bien, vous pouvez généralement trouver la version 1 de cela 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 le faire aussi. Peut-être qu'il serait bon pour les hackers d'agir plus comme des peintres, et de recommencer régulièrement à zéro, au lieu de continuer à travailler pendant des années sur un projet, et d'essayer d'incorporer toutes leurs idées ultérieures comme révisions.

Le fait que les hackers apprennent à hacker en le faisant est un autre signe de la façon dont le hacking est différent des sciences. Les scientifiques n'apprennent pas la science en la pratiquant, mais en faisant des laboratoires et des exercices de 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 atteignent le 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 par des 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 copier vous oblige à regarder de près la façon dont une peinture est réalisée.

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

Les hackers, de même, peuvent apprendre à programmer en regardant de bons programmes-- pas seulement ce qu'ils font, mais aussi le code source. Un des avantages moins médiatisés du mouvement open-source est qu'il a facilité l'apprentissage de la programmation. Lorsque j'ai appris à programmer, nous devions nous fier principalement à des exemples dans des livres. Le seul gros morceau de code disponible à l'époque était Unix, mais même cela n'était pas open source. La plupart des personnes qui lisaient le code source le lisaient dans des photocopies illicites du livre de John Lions, qui bien que écrit en 1977, n'a pas été autorisé à être publié avant 1996.

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 simplement un processus de remplissage. Parfois, les plans originaux s'avèrent erronés. D'innombrables peintures, lorsque vous les regardez en 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 hacking 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 êtes mieux loti si vous admettez cela 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 à faire, donc voici un autre endroit où les startups ont un avantage.)

Tout le monde sait maintenant probablement le danger de l'optimisation prématurée. Je pense que nous devrions être tout aussi inquiets de la conception prématurée-- décider trop tôt ce que 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 typage dynamique est un avantage ici car vous n'avez pas à vous engager à 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 à changer est celui qui est très court.

Cela ressemble à un paradoxe, mais une grande peinture doit être meilleure qu'elle ne doit l'être. Par exemple, lorsque Léonard a peint le portrait de Ginevra de Benci à la National Gallery, il a mis un buisson de genévrier derrière sa tête. Dedans, il a soigneusement peint chaque feuille individuelle. De nombreux peintres auraient pu penser, c'est juste quelque chose à mettre en arrière-plan pour encadrer sa tête. Personne ne regardera cela de si près.

Pas Léonard. La difficulté avec laquelle il a travaillé sur une partie d'une peinture ne dépendait pas du tout de la proximité avec laquelle il s'attendait à ce que quiconque la regarde. Il était comme Michael Jordan. Implacable.

L'implacabilité gagne parce qu'en agrégat, les détails invisibles deveniennent visibles. Lorsque les gens passent devant le portrait de Ginevra de Benci, leur attention est souvent immédiatement attirée par celui-ci, même avant qu'ils ne regardent l'étiquette et remarquent qu'elle dit 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 toutes en harmonie.

Un excellent logiciel, de même, nécessite un dévouement 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 un excellent logiciel, mais je sais que quand 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 était un simple implementateur, transformant une spécification en code, alors il pourrait simplement travailler d'un bout à l'autre comme quelqu'un qui creuse une tranchée. Mais si le hacker est un créateur, nous devons prendre en compte l'inspiration.

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

Pour faire du bon travail, vous devez prendre ces cycles en compte, car ils sont affectés par la façon dont vous réagissez à eux. Lorsque vous conduisez une voiture avec une transmission manuelle sur une colline, vous devez parfois relâcher l'embrayage pour éviter de caler. Relâcher peut également empêcher l'ambition de caler. Dans la peinture et le hacking, il y a certaines tâches qui sont terriblement ambitieuses, et d'autres qui sont réconfortamment routinières. C'est une bonne idée de garder quelques tâches faciles pour les moments où vous risqueriez autrement de caler.

Dans le hacking, cela peut littéralement signifier économiser des bugs. J'aime déboguer : c'est le seul moment où le hacking est aussi simple que les gens pensent qu'il l'est. 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ù cela tourne-t-il 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 comment travailler ensemble. Une grande partie de l'art du passé est le travail de plusieurs mains, bien que il n'y ait peut-être qu'un seul nom sur le mur à côté dans le musée. Léonard était un 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. Michel-Ange était considéré comme particulièrement dévoué pour avoir insisté pour peindre lui-même toutes les figures sur le plafond de la chapelle Sixtine.

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 figures principales et que les assistants peignent les autres et l'arrière-plan. Mais vous n'aviez jamais un gars peignant par-dessus le travail d'un autre.

Je pense que c'est le bon modèle de collaboration dans les logiciels aussi. Ne poussez pas cela trop loin. Lorsque un morceau de code est hacker par trois ou quatre personnes différentes, dont aucune ne possède réellement le code, cela finira par ressembler à une salle commune. Cela aura tendance à sembler désolé et abandonné, et à accumuler des 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 de regarder 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é un mauvais nom à l'empathie, et j'ai pris soin de ne pas la cultiver.

Mon dieu, 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 ê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 fabriquent des choses pour un public humain. Et pour engager un public, vous devez comprendre ce dont il a besoin. Presque toutes les plus grandes peintures sont des peintures de personnes, par exemple, car 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 grand hacker. Certains hackers sont assez intelligents, mais en ce qui concerne l'empathie, ils sont pratiquement solipsistes. Il est difficile pour de telles 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 dire à quel point les gens sont bons en empathie est de les observer expliquer une question technique à quelqu'un sans formation technique. Nous connaissons probablement tous des gens qui, bien que par ailleurs intelligents, sont tout simplement comiquement mauvais à cela. Si quelqu'un leur demande lors d'une soirée 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, vous devez comprendre à quel point les utilisateurs comprennent peu. Ils vont s'approcher du logiciel sans 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'ai jamais vu à cet égard était le Macintosh original, en 1985. Il faisait ce que le logiciel fait presque jamais : il fonctionnait simplement. [6]

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

Les programmes devraient être écrits pour être lus par des gens, et uniquement accessoirement pour être exécutés par des machines.

Vous devez avoir de l'empathie non seulement pour vos utilisateurs, mais pour vos lecteurs. C'est dans votre intérêt, car vous en serez un. Beaucoup de hackers ont écrit un programme pour découvrir en y revenant six mois plus tard qu'ils n'ont aucune idée de son fonctionnement. Je connais plusieurs personnes qui ont juré de ne plus jamais 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 quelque chose d'une mode pour cela dans certains endroits. Mais je ne pense pas qu'il y ait de corrélation. Vous pouvez bien 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, donc les deux qualités en sont venues à être associées. Mais il y a beaucoup de gens stupides qui sont également mauvais en empathie. Écoutez simplement les gens qui appellent avec des questions lors des émissions de discussion. Ils posent ce qu'ils demandent d'une manière si indirecte 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, vous n'avez qu'une seule vie. Vous feriez mieux de la passer à travailler sur quelque chose de grand.

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 à cause du grand travail que les gens ont fait il y a cinq cents ans. À l'époque, personne ne pensait que ces peintures étaient aussi importantes que nous le pensons aujourd'hui. Cela 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 avec le nez étrange dans une peinture de Piero della Francesca.

Donc, bien que j'admette que le hacking ne semble pas aussi cool que la peinture maintenant, nous devrions nous rappeler que la peinture elle-même ne semblait pas aussi cool à ses jours de 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 hacking. Dans la plupart des domaines, le grand travail est fait tôt. Les peintures réalisées entre 1430 et 1500 sont encore inégalées. Shakespeare est apparu juste au moment où le théâtre professionnel était en train de naître,

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 si enthousiasmés par cela qu'ils explorent la plupart de ses possibilités dans les deux premières générations. Le hacking semble être dans cette phase maintenant.

La peinture n'était pas, à l'époque de Léonard, aussi cool que son travail a aidé à le rendre. À quel point le hacking s'avérera-t-il cool dépendra de ce que nous pouvons faire avec ce nouveau médium.

Notes

[1] Le plus grand dommage que la photographie a causé à la peinture peut être le fait qu'elle a tué le meilleur emploi de jour. 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 de 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 pas embaucher de programmeurs de premier ordre.

[3] Ce que vous apprenez sur la programmation à l'université est très similaire à ce que vous apprenez sur les livres ou les vêtements ou les rendez-vous : quel mauvais goût vous aviez au lycée.

[4] Voici un exemple d'empathie appliquée. Chez Viaweb, si nous ne pouvions pas décider entre deux alternatives, nous demandions, que détesterait le plus notre concurrent ? À un moment donné, un concurrent a ajouté une fonctionnalité à son logiciel qui était essentiellement inutile, mais comme c'était l'une des rares qu'ils avaient que nous n'avions pas, ils en ont beaucoup parlé dans la presse spécialisée. Nous aurions pu essayer d'expliquer que la fonctionnalité était inutile, mais nous avons décidé qu'il agacerait notre concurrent davantage si nous l'implémentions nous-mêmes, donc nous avons bricolé notre propre version cet après-midi-là.

[5] Sauf pour 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] Eh bien, presque. Ils ont légèrement dépassé la RAM disponible, causant beaucoup de swaps de disque gênants, mais cela a pu être corrigé dans quelques mois en achetant un disque dur supplémentaire.

[7] La façon de rendre les programmes faciles à lire n'est pas de les bourrer de commentaires. Je prendrais la citation d'Abelson et Sussman un pas 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 les logiciels qu'en 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.

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