Hackers et peintres
This is a french translation of the famous Hackers and painters essay written by Paul Graham.
Hackers et peintres
Mai 2003
(Cet article est dérivé d’une conférence à Harvard, qui intégrait un premier discours à Northeastern.)
Lorsque j’ai terminé mes études supérieures en informatique, je suis allé étudier la peinture dans une école d’art. Beaucoup de personnes semblaient surprises que quelqu’un qui s’intèresse aux ordinateurs puisse également s’intéresser à la peinture. Ils semblaient penser que le hacking et la peinture étaient des travaux très différents – que le hacking était froid, précis et méthodique, et que la peinture était l’expression frénétique d’un besoin primaire.
Ces deux images sont fausses. Le hacking et la peinture ont beaucoup de point communs. En fait, de tous les différents types de personnes que j’ai connu, les hackers et les peintres sont parmis les plus semblables. Les hackers et les peintres ont en commun qu’ils sont tous deux des créateurs. Tout comme les compositeurs, les architectes, et les écrivains, les hackers et les peintres essayent de créer des belles choses. Ils ne font pas de la recherche en soi, bien que si jamais ils découvrent une nouvelle technique pendant qu’ils essayent de créer de belles choses, c’est encore mieux.
Je n’ai jamais aimé le terme de “science informatique”. Principalement parce qu’un tel concept n’existe pas. L’informatique est un ensemble de domaines vaguement reliés ensemble qui ont été jetés ensemble par un accident de l’histoire, comme la Yougoslavie. A une extremité vous avez des gens qui sont de vrais mathématiciens, mais qui appellent ce qu’ils font de l’informatique pour obtenir des subventions de la DARPA. Au milieu vous avez des gens qui travaillent sur ce qui pourrait être l’histoire naturelle des ordinateurs – étudier le comportements des algorithmes de routage de données à travers un réseau, par example. Et ensuite, à l’autres extrémité, vous avez les hackers, qui essayent d’écrire des programmes intéressants, et pour qui les ordinateurs ne sont qu’un moyen d’expression, come le béton l’est pour les architectes ou la peinture l’est pour les peintres. C’est comme si les mathématiciens, physiciens, et architectes devaient tous être dans le même département.
Parfois, ce que les hackers font s’appelle “ingénieurie logicielle” mais ce terme est tout aussi trompeur. Les bons concepteurs de logiciel ne sont pas plus des ingénieurs que les architectes. La frontière entre l’architecture et l’ingénieurie n’est pas précisement définie, mais elle existe. Cela se situe entre le quoi et le comment : les architectes décident ce qu’il faut faire, et les ingénieurs trouvent comment le faire.
Le quoi et le comment ne devraient pas restés trop séparés. Vous cherchez les ennuis si vous décidez ce qu’il faut faire sans comprendre comment le faire. Mais le hacking peut en fait être bien plus que juste décider comment implémenter une spécification. A son meilleur, c’est créer la spécification – et il s’avère que la meilleure façon de faire cela est de l’implémenter.
Peut être qu’un jour la “science informatique” sera, comme la Yougoslavie, découpée en ses différentes sous parties. Ca pourrait être bien. Surtout si cela signifiait l’indépendance pour mon pays natal, le hacking. Regrouper ensemble toutes ces différentes sortes de travaux est peut être pratique administrativement, mais c’est intellectuellement trompeur. C’est l’autre raison pour laquelle je n’aime pas le terme “science informatique”. On peut dire que les gens au milieu font quelque chose qui ressemble à une science experimentale. Mais les gens aux extrémités, les hackers et les mathématiciens, ne font en fait pas de science.
Les mathématiciens ne semblent pas embêtés par cela. Ils se mettent joyeusement à la tâche de prouver des théorèmes, comme les autres mathématiciens du département de math, et ils occultent probablement rapidement le fait que le batiment dans lequel ils travaillent est intitulé “science informatique” à l’extérieur. Mais pour les hackers, l’étiquette est un problème. Si ce qu’il font est appelé science, cela les fait s’imaginer qu’ils devraient agir scientifiquement. Donc au lieu de faire ce qu’ils veulent vraiment faire, c’est à dire créer des magnifique logiciels, les hackers dans les universités et les centre de recherche pense qu’ils devraient écrire des publications de recherche.
Dans le meilleur des cas, les publications ne sont qu’une formalité. Les hackers écrivent des programmes cools, et ensuite écrivent une publication à ce sujet, et la publication devient un portail vers la réalisation qu’est le logiciel. Mais souvent ce décalage engendre des problèmes. En commençant par vouloir créer de belles choses, il est facile de finir par construire des choses moches mais qui sont de meilleurs sujets pour une publication.
Malheureusement, les belles choses ne font pas toujours les meilleurs sujets de publication. Primo, les sujets de recherches doivent être originaux – et comme quiconque a écrit une thèse le sait, le moyen d’être certain d’explorer un territoire vierge est de choisir un territoire dont personne ne veut. Deuxio, la recherche doit être substantielle – et les systèmes tordus engendrent des publications plus fournies, parce que vous pouvez écrire à propos des obstacles que vous avez dû surmonter pour faire quelque chose. Rien n’engendre des publications plus fournies que de partir avec les mauvaises hypothèses. La majorité de l’IA en est un exemple; si vous supposez que la connaissance peut être représentée commune une liste d’expressions de prédicats logiques dont les arguments représente des concepts abstraits, vous allez devoir écrire beaucoup de publications pour expliquer comment faire fonctionner cela. Comme Ricky Ricardo avait l’habitude de dire “Lucy, vous avez beaucoup d’explications à faire.”
La manière de créer quelque chose de génial est souvent de faire quelques subtiles modifications à quelque chose qui existe déjà, ou de combiner des idées existantes d’une manière légérement différente. Il est difficile de transmettre ce genre de travaux dans une publication.
Alors pourquoi les universités et les laboratoires de recherche continuent de juger les hackers par leurs publications ? Pour les mêmes raisons que les “aptitudes scolaires” sont mesurées par des tests simplistes et standards, ou que la productivité des programmeurs est mesurée en nombre de lignes de code. Ces tests sont faciles à appliquer, et il n’y a rien de plus tentant qu’un test facile qui d’une certaine manière, fonctionne.
Mesurer ce que les hackers essayent effectivement de faire, créer de magnifiques logiciels, serait beaucoup plus difficile. Vous avez besoin de bon gout pour juger une bonne conception. Et il n’y a pas de corrélation, sauf peut être une négative, entre la capacité des gens à repérer une bonne conception et leur confiance qu’il le peuvent.
Le seul test externe est le temps. Avec le temps, les belles choses tendent à s’épanouir, et les moches tendent à être rejetées. Malheureusement, le temps nécessaire pour cela peut être plus long qu’une vie. Samuel Johnson a dit qu’il fallait cent ans pour que la réputation d’un écrivain converge. Vous devez attendre que les amis influents de l’écrivain meurent, et ensuite que tous leurs suiveurs meurent.
Je pense que les hackers doivent simplement se résigner à avoir une grande part d’aléatoire dans leurs réputations. Dans ce sens 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 tout à fait aussi grande dans le hacking que dans la peinture.
Il y a pire que les gens qui comprennent mal votre travail. C’est plus dangereux si vous même comprenez mal votre travail. C’est dans les domaines connexes que vous pouvez trouver des idées. Si vous vous trouvez dans le département d’informatique, il sera naturel de croire, par exemple, que le hacking est la version appliquée de ce que l’informatique théorique théorise. Pendant toutes mes études supérieures, j’éprouvais un malaise latent à me dire que je devrais connaitre plus de théorie, et que j’avais été très négligent d’avoir oublié toutes ces choses à trois semaines de l’examen final.
Maintenant j’ai réalisé que je me trompais. Les hackers ont à peut prêt autant besoin de comprendre la théorie du calcul que les peintres ont besoin de comprendre la chimie de la peinture. Vous avez besoin de savoir comment calculer la complexité temporelle et spatiale et ce qu’est la complétude de Turing.Vous avez peut être également besoin de vous souvenir au moins du concept de machine à état, au cas où vous auriez à écrire un parser ou une librairie d’expression régulières. En fait les peintres doivent se souvenir de bien plus concernant la chimie de la peinture.
Je me suis rendu compte que les meilleurs sources d’idées ne sont pas les autres disciplines qui ont le mot “ordinateur” dans leur nom, mais les autres disciplines occupées par des créateurs. La peinture est une source bien plus riche en idées que la thérie du calcul.
Par exemple, on m’a appris à l’université qu’il fallait complétement mettre au point un programme sur le papier avant de s’approcher d’un ordinateur. Je me suis rendu compte que je ne programmais pas comme cela. Je me suis rendu compte que j’aimais m’assoire devant mon ordinateur, pas devant une feuille de papier. Pire, à la place d’écrire patiemment un programme complet et de m’assurer qu’il était correct, j’avais tendance à simplement balancer du code qui était désespérement buggé, et de le façonner petit à petit. Le debugging, comme on me l’a appris, n’était qu’une sorte de relécture finale où vous pouviez corriger les erreurs d’écritures et d’étourderies. Avec ma manière de travailler, on aurait dit que la programmation était du debugging.
Pendant longtemps, je me suis senti coupable à cause de ça, tout comme je me suis senti mal parce que je ne tenais pas mon crayon comme on me l’apprenais à l’école élémentaire. Si j’avais seulement regardé les créateurs d’autres disciplines, les peintres et les architectes, je me serais rendu compte qu’il y avait un nom pour ce que j’étais en train de faire : des ébauches. Aussi loin que je sache, la manière avec laquelle il m’ont appris à programmer à l’université était complétement fausse. Vous devriez concevoir vos programmes en même temps que vous les écrivez, tout comme les écrivains et les peintres et les architecte le font.
Ce rendre compte de cela a de réelles conséquences sur le conception de logiciel. Cela veut dire qu’un langage de programmation doit, avant tout, être maléable. Un langage de programmation est là pour réfléchir à des programmes, pas pour exprimer des programmes auxquels vous avez déjà réfléchi. Ca devrait être un crayon, pas un stylo. Le typage statique serait une superbe idée si les gens écrivait effectivement des programmes à la manière de ce qu’on m’a appris à l’université. Nous avons besoin d’un langage qui nous permette de griffoner et maculer et étaler, pas un langage où vous devez vous assoir avec une tasse à thé remplie de types en équilibre sur vos genoux et tenir une conversation polie à votre grand-tante stricte qu’est le compilateur.
Tant qu’on est sur le sujet du typage statique, s’identifier aux créateurs nous évitera un autre problème qui touche les sciences : l’envie de math. Tout le monde dans les sciences croit en secret que les mathématiciens sont plus intelligents qu’ils ne le sont. Je pense que les mathématiciens le croient aussi. Dans tous les cas, le résultat est que les scientifiques tendent à en sorte que leur travail ait l’air le plus mathématique possible. Ca ne fait surement pas beaucoup de mal dans un domaine comme la physique, mais plus vous vous éloignez des sciences naturelles, et plus le problème devient sérieux.
Une page de formules donne un air tellement sérieux. (Astuce : pour impressionner encore plus, utilisez des variables grecques.) Et donc il y a une grande tentation de travailler sur les problèmes qu’on peut traiter de manière formelle, plutôt que les problèmes qui sont, par exemple, importants.
Si les hackers s’identifient avec les autres créateurs, comme les écrivains et les peintres, ils ne seront pas tentés de faire cela. Les écrivains et les peintres ne souffrent pas de l’envie de math. Ils prensent qu’ils font quelque chose de complétement différent. Comme, je crois, le pensent les hackers.
Si les universités et les labos de recherche ne permettent pas aux 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 les hackers faire ce qu’ils veulent non plus. Les universités et les labos de recherches obligent les hackers à être des scientifiques, les entreprises les obligent à être des ingénieurs.
J’ai personnellement découvert cela seulement récemment. Lorsque Yahoo a acheté Viaweb, ils nous ont demandé ce que je voulais faire. Je n’ai jamais beaucoup aimé la partie business, et j’ai dit que je voulais juste hacker. Lorsque je suis arrivé à Yahoo, j’ai compris que pour eux hacking voulait dire implémenter des logiciels, pas les concevoir. Les programmeurs étaient vus comme des techniciens qui traduisaient les visions (si tel est le mot) des product managers en code.
Cela semble être le système par défaut dans les grandes entreprises. Ils le font parce que ça diminue l’écart type du résultat. Seulement un petit pourcentage des hackers peuvent effectivement concevoir des logiciels, et il est difficile de les trouver pour les personnes dirigeant une entreprise. Donc à la place de confier le future des logiciels à un seul hacker brillant, la plupart des entreprises font en sorte qu’il soit conçu en groupe, et que le hackers se contente d’implémenter la conception.
Si vous voulez gagner de l’argent à un certain moment, rappelez vous de cela, parce que c’est la raison pour laquelle les startups gagnent. Les grandes entreprises veulent réduire l’écart type des résultats de conception parce qu’elle veulent éviter les désastres. Mais lorsque vous attenuez les oscillations, vous perdez les points hauts aussi bien que les bas. Ca n’est pas un problème pour les grandes entreprises, parce qu’elle ne gagnent pas en faisant des supers produits. Les grandes entreprises gagnent en étant moins nulles que les autres grandes entreprises.
Donc si vous vous trouvez un moyen de faire une guerre de conception avec une entreprise assez grande pour que son software soit conçu par des directeurs produits, ils ne seront jamais capables de vous suivre. Ces opportunités ne sont pas facile à trouver cependant. Il est difficile d’engager une guerre de conception avec une grande entreprise, tout comme il est difficile d’engager un enemis dans son chateau en combat au corps à corps. Il serait très facile d’écrire un meilleur traitement de texte que Microsoft Word, par exemple, mais Microsoft, à l’intérieur de leur chateau du monopole du système d’exploitation, ne se rendrait surement même pas compte que vous l’auriez fait.
Les champs de bataille des guerres de conception sont les nouveaux marchés, où personne n’a encore réussi à établir des fortifications. C’est là que vous pouvez gagner beaucoup en prenant l’approche courageuse de la conception, et en ayant les même personnes qui à la fois conceoivent et implémentent le prduit. Microsoft eux même ont fait cela au début. Comme Apple. Et Hewlett-Packard. Je soupçconne que quasiment toute les startups à succés l’ont fait.
Donc une manière de construire des logiciels géniaux est de démarrer votre propre startup. Il y a deux problèmes avec cela, cependant. L’un est que dans une startup il y a beaucoup à faire en plus d’écrire des logiciels. A Viaweb je me considérais chançeux si j’arrivais à hacker un quart de mon temps. Et les choses que j’avais à faire les trois autres quarts du temps allait du pénible au terrifiant. J’ai un benchmark pour cela, parce qu’à une occasion j’ai dû quitter une réunion du conseil pour me faire soigner des caries. Je me souviens être assis sur le fauteuil du dentiste, attendant la fraise, et me sentir comme si j’étais en vacances.
L’autre problème avec les startup est que l’intersection entre le genre de logiciels qui rapportent de l’argent et le genre qui sont intéressant à écrire est petite. Les languages de programmation sont intéressants à écrire, et le premier produit de Microsoft en était un en fait, mais personne ne voudra payer pour un langage de programmation maintenant. Si vous voulez faire de l’argent, vous aurez tendance à devoir travailler sur des problèmes qui sont trop vilains pour que quiconque veuille les résoudre gratuitement.
Tous les créateurs font face à 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 sur lesquelles il est amusant de travailler que sur les choses qui résolvent les problèmes terre à terre des différents clients. Jouer dans une pièce de théatre hors Broadway ne paye tout simplement pas autant que de porter un déguisement de Gorille dans une cabine pour quelqu’un à une foire commerciale. Ecrire des livres ne paye pas autant que d’écrire des copies de publicités qui finiront aux ordures. Et hacker des langages de programmation ne paye pas aussi bien que de trouver comment connecter la base de donnée historique d’une entreprise à leur 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 job de jour. Cette expression à commencée avec les musiciens, qui se produisent la nuit. Plus généralement, ça veut dire que vous avez une sorte de travail que vous faites pour l’argent, et une autre par passion.
Presque tous les créateurs ont un job de jour au début de leur carrière. Il est célébre que les peintres et les écrivains en ont. Si vous êtes chanceux vous pouvez trouver un job de jour qui est très proche de votre vrai travail. Les musiciens semble souvent travailler dans des magasins de disques. Un hacker qui travaille sur un langage de programmation ou un système d’exploitation pourrait également être en mesure de trouver un job de jour qui l’utilise. [1]
Lorsque je dis que la réponse pour les hackers est d’avoir un job de jour, et de travailler sur de beaux softwares à côté, je ne propose pas cela comme une nouvelle idée. C’est la raison d’être du hacking open-source. Ce que je dis c’est l’open-source est probablement le bon modèle, parce qu’il a été indépendament confirmé par tous les autres créateurs.
Ca me semble très surprenant qu’un employeur soit récalcitrant à laisser les hackers travailler sur des projest open-source. A Viaweb, nous aurions été récalcitrant à embaucher quiconque ne le faisait pas. Lorsque nous faisions passer des entretiens à des programmeurs, la chose à laquelle nous faisions le plus attention était de savoir quel était le genre de logiciels qu’ils écrivaient dans leur temps libre. Vous ne pouvez pas faire quelque chose vraiment bien sans aimer le faire, et si vous aimer le hacking, inévitablement vous travaillerez sur vos projets personnels. [2]
Compte tenu que les hackers sont des créateurs plutôt que des scientifiques, le bon endroit pour trouver des métaphores n’est pas dans les sciences, mais auprès des autres sortes de créateurs. Qu’est ce que peut encore nous apprendre la peinture à propos du hacking ?
Une chose qu’on peut apprendre, ou en tout cas 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’apprenne pas à hacker en suivant des cours de programmations à l’université. Ils apprennent à hacker en écrivant leurs propres programmes à 13 ans. Même à l’université, vous apprenez principalement à hacker en hackant. [3]
Comme les peintres laissent une trace de leur travail derrière eux, on peut les voir apprendre en faisant. Si vous observez le travail d’un peintre par ordre chronologique, vous verrez que chaque peinture est construite sur des choses qui ont été apprises lors des précédentes. Lorsqu’il y a quelque chose dans une peinture qui fonctionne vraiment bien, vous pouvez souvent en trouver la version 1 en plus petit dans une peinture plus ancienne.
Je pense que la plupart des créateurs travaillent de cette manière. Les écrivains et les architectes le semblent aussi. Peut être qu’il serait bon pour les hackers d’agir plutôt comme les peintres, et de régulièrement redémarrer de zéro, plutôt que de continuer à travailler pendant des années sur un projet, et d’essayer d’incorporer toutes leurs dernières idées comme évolutions.
Le fait que les hackers apprennent à hacker en faisant est un autre indice d’à quel point le hacking est différent des sciences. Les scientifiques n’apprennent pas les sciences en les pratiquant, mais en faisant des expériences et des hypothéses. Les scientifiques commencent par faire du travail parfait, dans le sens où ils essayent juste de reproduire le travail que quelqu’un d’autre a déjà faire pour eux. Tout à la fin, ils arrivent au point où ils peuvent faire du travail original. A la différence des hackers qui, depuis le début, font du travail original; qui est juste très mauvais. Donc les hackers commencent originaux, et deviennent bons, et les scientifiques commencent bons, et deviennent originaux.
L’autre moyen d’apprendre pour les créateurs est par l’exemple. Pour un peintre, un musée est une librairie de référence de techniques. Pendant des siècles l’apprentissage traditionel des peintres à consister à copier des oeuvres de grands maîtres, parce que la copie vous oblige à regarder dans le détail la manière dont la peinture est faite.
Les écrivains font cela aussi. Benjamin Franklin a appris à écrire en résumant les points dans les essais de Addison et Steel et ensuite en essayant de les reproduires. Raymond Chandler a fait la même chose avec les histoires de détectives.
Les hackers, de même, peuvent apprendre à programmer en regarder des bons programmes– pas seulement ce qu’ils font, mais le code source aussi. Un des avantages les moins médiatisés du mouvement open-source est qu’il a simplifier l’apprentissage de la programmation. Lorsque j’ai appris à programmer, nous devions principalement nous appuyer sur des exemples dans des livres. Le gros morceaux de code disponible à l’époque était Unix, mais même cela n’était pas open-source. La plupart des gens qui en lisait les sources lisaient des photocopies pirates du livre de John Lion, lequel, bien qu’écrit en 1977 n’a pas été autorisé à la publication avant 1996.
Un autre exemple que nous pouvons prendre de la peinture est la manière avec laquelle les peintures sont construites par améliorations successives. Les peintures commencent d’habitude avec un croquis. Progressivement les détails sont ajoutés. Mais ça n’est pas qu’une technique d’ajout. Parfois le plan de départ se révèle faux. D’innombrables peintures, lorsque vous les observée aux rayons X, se révèlent contenir des membres qui ont été déplacés ou traits de visage qui ont été ajustés.
Voici un cas où nous pouvons apprendre de la peinture. Je pense que le hacking devrais fonctionner de cette manière aussi. Il est irréaliste d’espèrer que les spécifications d’un programme soient parfaites. Vous serez plus à l’aise si vous admettez ceci dès le début, et que vous écriviez des programmes de manière à permettre aux spécifications de changer à la volée.
(L’organisation des grandes entreprises rend cela très difficile à faire, voici donc une autre point où les startups ont un avantage.)
Aujourd’hui, sans doute tout le monde connait les danger de l’optimisation prématurée. Je pense que nous devrions être tout aussi inquiet de la conception prématurée– décider trop tôt ce que notre programme devrait faire.
De bons outils peuvent nous aider à éviter ce danger. Un bon langage de programmation devrait, comme la peinture à l’huile, nous permettre de changer d’avis plus simplement. Le typage dynamique est un gain ici parce que vous n’avez pas à vous engager sur des représentations spécifiques des données dès le début. Mais la clef 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.
Ceci résonne comme un paradoxe, mais une peinture extraordinaire doit être encore meilleure que ce qu’elle doit être. Par exemple, lorsque Léonard a peint le portrait de Ginevra de’Benci à la Gallerie Nationale, il mit un genévrier derrière sa tête. Il peint avec minutie chacune de ses feuilles. Beaucoup de peintre auraient pu penser que cela était juste quelque chose à mettre en fond pour encadrer sa tête. Que personne ne regarderait cela d’aussi prêt.
Pas Léonard. Le travail qu’il fournissait pour une partie d’une peinture ne dépendait pas de la distance à laquelle il imaginait qu’on la regarderait. Il était comme Michael Jordan. Implacable.
L’acharnement est toujours un succes parce que, dans l’ensemble, les détails invisibles deviennent visibles. Lorsque les gens passent devant le portrait de Ginevra de’ Benci, il capte souvent immédiatement leur attention, avant même qu’il regarde l’écritau et l’explication qui indique Léonard de Vinci. Tous ces détails invisibles se combinent pour produire quelque chose de tout simplement ahurissant, comme un milier de voix à peine audibles qui chantent à l’unisson.
Les excellents logiciels, eux aussi, exigent une dévotion fanatique à la beauté. Si vous regardez à l’intérieur de bons logiciels, vous trouverez des parties que personnes n’est supposé voir et qui sont magnifiques. Je ne prétends pas écrire des excellents logiciels, mais je sais que lorsqu’il s’agit de code je me comporte d’une manière qui me vaudrait une prescription de médicament si je l’utilisais dans la vie de tous les jours. Ca me rend fou de voir du code qui est mal indenté, ou qui utilise des noms de variables affreux.
Si un hacker n’était qu’un simple implémenteur, transformant une specification en code, alors il pourrait juste travailler d’un bout à l’autre comme quelqu’un qui creuse un fossé. Mais si un hacker est un createur, nous devons tenir compte de l’inspiration.
En hacking, comme en peinture, le travail arrive par cycle. Parfois vous êtes excité par un nouveau projet et vous voulez travailler seize heures par jours dessus. D’autres fois rien ne semble intéressant.
Pour faire du bon travail vous devez prendre tenir compte de ces cycles, parce vous êtes sensible à la manière dont vous leurs réagissez. Lorsque vous conduisez une voiture avec transmission manuelle sur une coline, vous devez parfois rétrograder pour éviter de caller. De la même manière, rétrograder évite parfois à l’ambition de caller. En peinture tout comme en hacking il y a des tâches tellement ambitieuses qu’elles en sont sont terrifiantes, et d’autres qui sont confortablement routinières. C’est une bonne idée de conserver des tâches faciles pour les moment où vous auriez caller autrement.
En hacking, cela peut litéralement signifier garder des bugs. J’aime le debugging : c’est le moment unique ou le hacking est aussi simple que les gens le pensent. Vous avez un problème complétement conscrit, et tout ce que vous avez à faire est de le résoudre. Votre programme est supposé faire x. A la place il fait y. Où va-t’il de travers ? Vous savez que vous allez gagner à la fin. C’est aussi relaxant que de peindre un mur.
L’exemple de la peinture peut nous apprendre à non seulement à gérer notre propre travail, mais aussi à travailler ensemble. Beaucoup d’oeuvres du passé sont le travail de beaucoup de mains, même si il se peut qu’il n’y ait qu’un nom sur le mur qui la soutient au musé. Léonard était un apprenti à 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 a été considéré particulièrement dévoué pour avoir insister à peindre lui même tous les personnages du plafond de la chapelle Sistine.
Aussi loin que je sache, lorsque les peintres travaillent ensemble sur une peinture, ils ne travaillent jamais sur les même parties. Il était commun pour un maître de peindre les personnages principaux et pour les assistants de peindre le fond et les autres. Mais vous n’aviez jamais un type qui paignait sur le travail des autres.
Je pense que cela est également le bon modèle de collaboration pour le logiciel. Ne le poussez pas trop loin. Lorsqu’un morceau de code est hacké par trois ou quatres personnes, n’appartenant à aucun de ceux-ci, il finira comme une pièce commune. Il aura tendance à être morne et abandonné, et à accumuler la saleté. La bonne manière de collaborer est, je pense, de diviser les projets en modules précisement définis, chacun avec un propriétaire connu, et avec des interfaces entre eux qui soient aussi bien conçues et, si possible, aussi flexibles qu’un langage de programmation.
Comme la peinture, la plupart des logiciels sont destinés à des humains. Et donc les hackers, comme les peintres, doivent avoir de l’empathie pour des choses vraiment géniales. Vous devez être capable de voir les choses du point de vue de l’utilisateur.
Lorsque j’étais un enfant on me disait tout le temps de regarder les choses du point de vue de quelqu’un d’autre. Ce que cela voulait dire en pratique était de faire ce que quelqu’un d’autre voulait plutôt que ce que je voulais. Cela biensûr donna une mauvaise réputation à l’empathie, et je me fis un principe de ne pas la cultiver.
Et bien, qu’est ce que j’avais tord. Il s’est révélé que de regarder les choses depuis le point de vue des autres est pratiquement le secret du succès. Ca ne veut pas nécessairement dire se sacrifier. Loin de là. Comprendre ce que pense quelqu’un autre n’implique pas que vous agissiez dans son interêt; dans certains situation– pendant la guerre, par exemple– Vous voulez faire exactement l’opposé. [4]
La plupart des créateurs font des choses pour un public humain. Et pour intéresser un public vous devez comprendre ce dont il a besoin. Presque toutes les plus grandes peintures sont des peinture de personnes, parce que, par exemple, ce sont les gens qui intéressent les gens.
L’empathie est probablement la différence la plus importante entre un bon hacker et un hacker génial. Certains hackers sont très intelligents, mais en ce qui concerne l’empathie sont pratiquement solipsistes. C’est difficile pour de telles personnnes de concevoir des logiciels géniaux [5], parce qu’ils ne peuvent pas voir les choses du point de vue de l’utilisateur.
Une bonne manière de dire à quel point des gens sont empathiques et de les regarder expliquer un problème technique à quelqu’un sans formation technique. Nous connaissons tous des gens qui, bien qu’intelligents, sont juste comiques lorsqu’ils font cela. Si à une soirée repas quelqu’un leur demande ce qu’est un langage de programmation, ils diront quelque chose comme “Ah, un langage de haut niveau est celui utilisé par le compilateur pour générer le code machine.” Langage de haut niveau ? Compilateur ? Code machine ? Quelqu’un qui ne sait pas ce qu’est un langage de programmation ne sait évidement pas ce que ces choses sont non plus.
Une chose que le logiciel doit faire est de s’expliquer soit-même. Donc pour écrire de bon logiciels vous devez comprendre à quel point les utilisateurs en comprennent peu. Il vont essayer le logiciel sans préparation, et il vaut mieux qu’il fasse ce qu’ils ont deviné qu’il faisait, parce qu’ils ne vont pas lire le manuel. Le meilleur système que j’ai vu selon ce critère est le premier Macintosh, en 1985. Il faisait ce que les logiciels ne font quasiment jamais : il fonctionnait tout de suite. [6]
Le code source, lui aussi, devrait s’expliquer lui-même. Si je pouvais amener les gens à se souvenir d’une seule citation à propos de la programmation, ça serait celle au début de Structure and Interpretation of Computer Programs.
Les programmes devraient être écrit pour que les gens puissent les lire, et seulement accessoirement que les machines les exécutent.
Vous devez avoir de l’empathie non seulement pour vos utilisateurs, mais également pour vos lecteurs. C’est dans votre interêt, parce que vous serez l’un d’eux. Beaucoup de hackers ont écrit un programme et ont dû y revenir six mois plus tard pour se rendre compte qu’ils n’avaient aucune idée de comment est ce qu’il fonctionnait. Je connais plusieurs personnes qui ont ont juré de ne plus utiliser Perl après de telles expériences. [7]
Le manque d’empathie est associé à l’intelligence, au point que ça en soit une sorte de mode à certains endroits. Mais je ne pense pas qu’il ait une corrélation. Vous pouvez être bon en math et en sciences naturelles sans avoir à apprendre l’empathie, et les gens dans ces matières sont plutôt intelligents, donc les deux qualités sont devenues associées. Mais il y a également beaucoup d’imbéciles qui ne sont pas empathiques. Ecoutez seulement aux personnes qui appellent pour poser des questions dans les talk shows. Ils posent leur question d’une manière tellement tordue que le présentateur est souvent obligé de reformuler la question pour eux.
Donc, si le hacking fonctionne comme la peinture et l’écriture, est-ce aussi cool ? Après tout, vous n’avez qu’une seule 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élais avant le prestige. C’est comme la lumière d’une étoile lointaine. La peinture a du prestige maintenant grâce au travail génial que des gens ont fait il y a cinq siècles. A cette époque, personne ne pensait que ces peintures étaient aussi importantes que nous le pensons aujourd’hui. Ca aurait semblé très étrange aux gens de cette époque que Federico da Montefeltro, le Duke of Urbino, serait un jour principalement connu comme le type avec le drôle de nez dans une peinture de Piero della Francesca.
Donc bien que j’admette que le hacking n’ait pas l’air aussi cool que la peinture maintenant, nous devrions nous souvenir que la peinture elle même n’avait pas l’air aussi cool pendant son age d’or que maintenant.
Ce qu’on peut dire avec une certaine certitude est que c’est l’âge d’or du hacking. Dans la plupart des domaines les grandes oeuvres sont faites tôt. Les peintures faites entre 1430 et 1500 sont toujours insurpassées. Shakespeare apparu en même temps que le théatre professionel naissait, et a poussé le milieu si loin que depuis, tout dramaturge a du vivre dans son ombre. Albrecht Durer fit même chose avec la sculpture, et Jane Austen avec les romans.
Encore et encore nous assistons au même schéma. Une nouvelle matière apparait, les gens en sont tellement enthousisathes qu’ils explorent la plupart de ses possibilités pendant les 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 l’a rendue. Le hacking deviendra cool ou pas suivant ce que nous arrivons à faire avec cette nouvelle matière.
Notes
[1] Le plus grand tord qu’a fait la photographie à la peinture est peut être qu’elle a tué les meilleurs jobs de jour. La plupart des grands peintres de l’histoire sont subvenus à leurs besoins en peignant des portraits.
[2] On m’a dit que Microsoft déconseille à ses employés de contribuer à des projest open-source, même dans leur temps libre. Mais maintenant une telle proportions des meilleurs hackers travaillent sur ldes projets open-source que l’effet principal de cette politique pourrait être de s’assurer de ne pas embaucher les programmeurs de première classe.
[3] Ce que vous apprenez à propos de la programmation à l’université est très semblable à ce que vous apprenez à propos des livres ou des vêtements ou des rencontres : qu’est ce que vous aviez mauvais gout au lycée.
[4] Voici un exemple d’empathie appliquée. A Viaweb, si nous ne parvenions pas à choisir entre deux alternatives, nous nous demandions, qu’est ce que nos concurrent détesteraient le plus ? A un moment, un concurrent a ajouté une fonctionalité à leur logiciel qui était globalement inutile, mais comme c’était une des rares qu’ils avaient et pas nous, ils en firent beaucoup de bruit dans la presse. Nous aurions pu essayer d’expliquer que cette fonctionalité était inutile, mais nous avons décidé que ça énerverait plus notre concurrent si nous l’implémentions simplement, nous avons donc hacké notre propre version en une après midi ce jour là.
[5] Sauf les éditeurs de texte et les compilateurs. Les hackers n’ont pas besoin d’empathie pour concevoir ceux-ci, parce qu’ils en sont eux même des utilisateurs typiques.
[6] Enfin, presque. Ils ont quelque peut dépassé la quantité de RAM disponible, entrainant beaucoup de swap disque pénible, mais cela pouvait être corrigé après quelques mois en achetant un lecteur de disque supplémentaire.
[7] La manière de rendre les programmes facile à lire n’est pas de les remplir de commentaires. Je pousserais 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 que les machines les exécutent. Un bon langage de programmation devrait être plus efficace pour expliquer un programme que l’Anglais. Les commentaires ne devraient être nécessaires que lorsqu’il y a une sorte de bricolage dont vous devez mettre en garde le lecteur, tout comme il n’y a des flèches sur la route qu’aux virages serrés et innattendus.
Merci
à Trevor Blackwell, Robert Morris, Dan Giffin et Lisa Randall pour avoir lu les ébauches de ceci, et à Henry Leitnet et Larry Finkelstein pour m’avoir invité à parler.</p>
Fixes and improvements are welcome.
Leave a comment