Lecture – Page 21 – Grignotages

Coding software : splendeurs et misère du code

[Deuxième partie d’un compte-rendu de lecture sur l’essai Geek Sublime: Writing Fiction, Coding Software, de Vikram Chandra. La première concernait la sociologie du geek. La troisième, à venir, porte sur la critique littéraire indienne avec laquelle l’aspect informatique est mis en regard.]

Geek, man and machine

Le but premier et ultime d’un programme informatique est qu’il fonctionne, c’est-à-dire qu’il compile (pas d’erreur qui empêche de le transformer en langage binaire exécutable par l’ordinateur) ET qu’il fait ce qu’on veut qu’il fasse (un ordinateur est bête : il fait toujours ce qu’on lui dit de faire, pas nécessairement ce qu’on veut qu’il fasse). Pourtant, rappelle Knuth (le dieu que révère Vikram Chandra), programmer, ce n’est pas seulement indiquer à un ordinateur ce que l’on veut qu’il fasse ; c’est aussi expliquer à un être humain ce qu’on vaut que l’ordinateur fasse. Cet être humain peut aussi bien être un collègue que vous-même quelques mois après l’écriture du code ; rien de tel, en effet, que de reprendre un ancien bout de code pour vérifier que je est un autre. Pour que votre moi du futur remercie votre moi du passé, il faut, nous dit Knuth, bien choisir le nom des variables (ok), expliquer ce qu’elles représentent (sous forme de commentaires), et introduire les concepts dans l’ordre qui sied à la compréhension humaine (yolo, Boileau). Comme s’il y avait un mode de compréhension humaine. Chacun a donc son idée sur la question, et ses propres critères pour en juger. On retrouve cependant avec récurrence l’idée qu’un code ne devrait pas se répéter.

D’une manière générale, le geek voit la répétition d’un mauvais œil : c’est le boulot de la machine, pas le sien – « any repetition of effort seemed like an insult. » (p. 15) Le geek pourra donc passer cinq heures à coder l’automatisation d’une tâche qui lui aurait pris 30 minutes – et ce, même s’il est probable voire certain qu’il n’aura pas à la reproduire 9 autres fois. Le geek, comme l’homme dont il hérite, est un animal raisonnable : ce n’est pas parce qu’il peut être raisonné qu’il est d’emblée rationnel.

Le plaisir de coder

Le code peut-il être esthétique ? « The beauty of code » est l’un des leitmotiv de l’essai de Vikram Chandra, et le titre de son chapitre central. Pour autant, vous pouvez ranger Kant, l’émotion esthétique due au vertige des interprétations infinies n’est pas à l’ordre du jour. Vu qu’un programme a pour finalité d’être exécuté par une machine, mieux vaut qu’il n’ait qu’un sens bien défini ; contrairement aux interprétations, les boucles gagnent à ne pas être infinies. Exit la polysémie.

Exit le plaisir esthétique. Bonjour le plaisir sportif. Oui, vous avez bien lu. Pour Yukihiro Matz Matsumoto, le beau code a vocation à rendre le développeur « heureux et productif » (p. 122), et à en croire Vikram Chandra, cela passerait très concrètement par les endorphines : face à problème ardu, « the world fell away, my body vanished, time receded. And three or five hours later, when the pieces of the problem came together just so and clicked into a solution, I surfed a swelling wave of endorphins. » (p. 19) Et si le développeur était accro au code comme d’autres aux sport ?

En 6 ans de Palpatine, je peux vous dire qu’un geek, un vrai geek, ne lâche jamais le morceau. Lorsqu’un problème lui résiste, il y pense tout le temps, fusse en arrière-plan : en marchant (très péripatétique), sous la douche (un grand classique), au concert (la musique aère l’esprit et permet à la pensée de mieux circuler), mais aussi en société, ce qui peut parfois occasionner un freeze en pleine conversation : les pièces click into a solution, réelle ou supposée. (Je le soupçonne de continuer à ruminer au lit, mais il y a des choses que je préfère ne pas savoir avec certitude).

De quoi la métaphore du code comme art est-elle la revendication ?

Palpatine rappelle régulièrement à qui veut l’entendre qu’en France, le code est régi par le code de la propriété intellectuelle, exactement comme un roman (eh non, un programme ne se brevète pas). La métaphore du code comme art a de quoi surprendre, parce que l’on oublie généralement que l’artiste est d’abord un artisan. Le développeur n’est pas un mécanicien qui sert des boulons binaires, c’est un artisan, qui adapte, polit, peaufine… et revendique donc un savoir-faire. Car non, coder, ce n’est pas (uniquement) appliquer des principes mécaniques qui s’enchaîneraient comme le développement d’une équation ; c’est structurer une réalité foisonnante, la mettre en forme, la concevoir. On ignore généralement que le bon développeur est créatif – on l’imagine rusé, oui, mais pas créatif.

Si les développeurs se comparent à des peintres, des musiciens ou des essayistes, c’est pour faire valoir cet aspect méconnu de leur travail. Et revendiquer le statut qui devrait aller avec. Id est la considération, le salaire et… le sex appeal ? Vikram Chandra cite l’interprétation toute personnelle de Ceglowski sur le recours aux comparaisons artistiques : « Great paintings… get you laid in a way that great computer programs never do […] especially if you have the slighteste hint of being a tortured, brooding soul about you… » (p. 8-9). En bref : le geek ne veut pas être un nerd (le retour en grâce du terme geek, employé à tout va, ne doit pas nous faire oublier qu’à la base, c’est un synonyme de nerd, le mec antisocial un peu zarb avec qui on n’a pas du tout envie de traîner)(Palpatine, en tant que ‘vrai geek’, s’offusque régulièrement de ce que n’importe quel bidouilleur soit aujourd’hui honoré d’un qualificatif qu’il a eu à souffrir comme insulte avec ses camarades pendant sa jeunesse ; être geek, ça se mérite !).

Architecture

L’art est utile comme métaphore pour exprimer les rapports de proportions et d’harmonie. On pourra dire, par exemple, qu’un beau programme est comme une symphonie : chaque morceau en est une phrase musicale, qui peut être jouée seule, mais trouve sa raison d’être au sein de l’oeuvre, nuancée, enrichie par les phrases musicales qui la précèdent, la suivent, et l’entourent de leurs résonances. « Each small part is coherent, singular in its purpose, and although all these small sections fit together like the pieces of a complex mosaic, they come apart easily when one element needs to be changed or replaced. » (p. 123) Cette modularité, je me la représente sous la forme des sas de station spatiale, par lesquelles les astronautes des films passent toujours pour entrer et sortir sans danger. En cas d’urgence (et dans les films comportant des astronomes, il y a toujours une urgence), ces sas permettent de se défaire d’une partie endommagée sans détruire l’ensemble de la station. C’est-à-dire, pour le développeur, de modifier facilement une fonctionnalité pour le client qui a encore changé d’avis et veut son nouveau choix là tout de suite ; mieux vaut, donc, ne pas avoir à aller fouiller dans tous les recoins du programme pour modifier une fonctionnalité réduite.

Big Ball of Mud

L’effet boule de ~~neige~~ boue

L’architecte, qui veille au bon agencement de toutes les parties, joue ainsi un rôle primordial. Et ce n’est pas de la tarte : même un projet très simple se révèle toujours plein d’exceptions et de cas spéciaux qu’il faut gérer (si possible, sans faire rejaillir la complexité de ces exceptions sur les manipulations ordinaires). On a vite fait, les deadlines aidant, de se laisser embringuer : « you know that functionality should be somewhere else but you don’t have the time to bother, the users ask for a new feature and you patch it in, and of course you mean to come back later and clean everything up, but then, before you know it, you are trapped inside an unwholsome, uncontrollable atrocity, a Big Bull of Mud » (p. 126), « and yes, it is a technical term of art » (p. 127). Devenue incontrôlable, une Big Ball of Mud peut atteindre un nombre de ligne et une complexité tels que le programme échappe purement et simplement à la capacité de conception humaine. Plus personne ne comprend comment il fonctionne de bout en bout. « No temple, no cathedral has ever contained as many moving parts. » (p. 124)

[Go to indique au programme d’aller à telle ou telle ligne… qui a de fortes chances de bouger lors du développement. C’est le truc crade par excellence, à ne pas faire. Une pratique qui vaut -42, vous dira Plapatine.]

Dinosaures sous respiration artificielle

Comment traquer des bugs et ajouter des fonctionnalités à un programme que l’on ne comprend pas, quand la moindre modification effectuée dans un coin peut avoir des répercussions inattendues à l’autre bout du système ? Généralement, nous dit Vikram Chandra, on est pris de l’envie de tout réécrire de manière propre. Sauf qu’on n’en a jamais le temps ni le budget. Alors on rajoute une rustine, un peu de boue à la Big Ball of Mud.

Il existe ainsi des programmes qui tournent depuis des décennies et qui ne peuvent pas être correctement maintenus ni mis à jour parce que plus personne ne comprend comment ils fonctionnent dans leur ensemble. C’est par exemple le cas du logiciel comptable du Pentagone, apparemment célèbre pour ses erreurs dans les fiches de paye des soldats (p. 128)… Le secteur bancaire est également un beau tas de boue : 90 % des transactions financières dans le monde se font via des logiciels en COBOL, « the computing equivalents of Mesopotamian cuneiform dialects ». Hé oui, le site web tout beau tout neuf tout responsive de votre banque cache un système vieilli jusqu’à la moelle (p. 129)…

La programmation orientée objet

Au milieu des années 1980, on a imaginé de rassembler à un même endroit du code les différentes types de données et ce qu’on peut faire avec (i.e. les fonctions qui s’y rapportent). En encapsulant ces informations thématiques dans des objets, on espérait en mettre un peu moins partout. Et cela a fonctionné. Un peu. La programmation orientée objet a résolu certains problèmes, parfois même avec une certaine élégance, souligne Vikram Chandra ; elle a permis de mettre de l’ordre dans la « spaghetti code jungle » (la jungle est de Foote et Yoder, dans Big Ball of Mud, mais le « code spaghetti » est aussi un terme technique consacré, désignant les kilomètres de lignes de code enchevêtrées, issus de la programmation procédurale.). Pour autant, la programmation orientée objet n’est pas une solution miracle et les Big Balls of Mud continuent de proliférer (un peu comme le bordel dans mon studio en dépit des placards)…

« If you’ve ever writen code, the fact that so much software works so much of the time can seem profoundly miraculous. » (p. 124) Le bug est la normalité, pas le fonctionnement. Comme dirait Palpatine, ça « tombe en marche ».

Les travaux et les jours

Les bons outils font les bons… jongleurs ?

Un précepte geek enjoint de ne pas réinventer la roue et de se hisser sur les épaules d’un géant, en utilisant ce qui a déjà été fait. Il existe ainsi tout un tas de briques pré-construites qui permettent de réutiliser le travail déjà fait, des librairies dans lesquelles aller piocher un savoir patiemment accumulé ; et tout un tas d’outils pour gérer le code et éviter sa prolifération anarchique. Git, par exemple, permet de gérer le versionnement, pour que plusieurs personnes puissent travailler sur le même programme sans risquer d’effacer le travail des autres, et que l’on puisse à tout instant revenir à une version antérieur. Un outil puissant et précieux, donc, mais complexe à utiliser, qui constitue une compétence en soi (au point de figurer sur les annonces d’emploi au même titre que les langages à maîtriser).

Les outils, remarque Vikram Chandra, deviennent un savoir à part entière – problème du moyen qui devient une fin. « Each tool and pre-constructed library solves a problem that you must otherwise solve yourself, but each solution is a separate body of knowledge you must maintain. » (p. 139-140) D’où pour certains développeurs l’impression de ne plus être à l’aise dans quoi que ce soit. L’assurance d’avoir toujours quelque chose de nouveau à apprendre est l’un des attraits du métier, mais cela peut aussi se transformer en course épuisante contre la montre et l’obsolescence. Se former aux nouveaux langages pour les projets de demain tout en bossant à fond sur les projets en cours…

Le nouveau langage à la mode

« Our industry [remarks Steve Yegge] is fashion-driven to a degree that would embarrass haute couture designers from New York to Paris… » Aussi surprenant que cela peut paraître de l’extérieur, la mode dicte les langages que les gens étudient à l’école, qu’il utilisent ensuite dans projets professionnels, ceux à propos desquels des bouquins sont publiés, etc. Palpatine pestait récemment contre les choix de langage faits par ses associés : parce qu’un geek, par principe, peste toujours contre les langages qui ne sont pas ses préférés, mais aussi parce que le choix du langage n’en a pas été un. Il n’a pas fait l’objet d’un choix rationnel après mise en balance avec d’autres langages et étude de leurs avantages et inconvénients pour ce projet particulier ; ses associés l’ont choisi parce que c’est ce qui se fait et ce qu’ils savent faire. (Je soupçonne tout de même Palpatine d’un léger snobisme geek, à kiffer des langages paraît-il d’une grande élégance, mais à peu près jamais utilisés dans l’industrie.)(Un mignon snob, évidemment.

Et demain ?

À l’heure où l’on taquine l’idée d’enseigner le code à l’école, Vikram Chandra remarque que la promesse de démocratisation du code, déjà ancienne, n’a jamais vraiment été tenue. La forme de programmation la plus courante dans les entreprises, au final, est celle des feuilles Excel. « The biggest problem is that anyone can create Excel spreadsheets – badly. » (Kwak, The Importance of Excel). Même quand on maîtrise Excel, surtout quand on le maîtrise et qu’on y fait des calculs complexes, ce type de programmation peut s’avérer dangereux, car il est très difficile à auditer et débuguer – pas fait pour. J’ai d’autant moins de mal à le coire qu’il y avait un pro des tableaux Excel dans l’équipe où j’étais en apprentissage ; vous n’avez pas idée du nombre d’entrées et de formules qu’il y avait là-dedans, d’une complexité telle que… lui seul pouvait s’y retrouver. Vikram Chandra cite même le cas d’une erreur financière monstrueuse (à plusieurs millions) due à une feuille de calcul où une cellule calculait la somme au lieu de la moyenne… (p. 142)

Ouais, je sais, c’est moyen glamour d’envisager le futur sous la forme d’un tableau Excel. Du coup, Vikram Chandra se lâche pas mal en imaginant tout un tas de trucs, dont une rencontre du troisième type entre programmation informatique et génétique. Si vous voulez lire là-dessus, je vous conseille plutôt l’article d’Eliness où elle explique son métier de bio-informaticienne.

Geek Sublime

[Ceci est la première partie d’un compte-rendu de lecture (augmenté de digressions et de jeux de mots pourris, évidemment) sur l’essai Geek Sublime: Writing Fiction, Coding Software, de Vikram Chandra. Je me concentre ici sur l’aspect sociologique du geek ; un deuxième volet est prévu sur la notion de beauté/d’élégance dans le code… et son absence ; et sûrement un troisième sur la critique littéraire indienne avec laquelle le tout est croisé.]

Il y a geek et geek

C’est quoi, un geek ? Pour mon père, on est geek quand on a un blog, un compte Twitter et qu’on passe plus d’une heure par jour sur son ordinateur – je suis donc une indécrottable geekette à ses yeux. Ce qui n’est rien pour le bidouilleur de code. Lequel, à son tour, sera pris de haut par un architecte (parce que oui, on parle d’architecture pour la structure d’un programme). Vikram Chandra nous propose une petite typologie du geek en trois persona.

Tout d’abord, il y a Mel, qui comprend tellement bien la machine qu’il peut programmer en langage machine. En gros, on peut lui mettre des 0 et des 1 à défiler comme les $ dans les yeux de Picsou. Mel, c’est un vieux de la vieille, une espèce en voie de disparition. Typiquement, mon prof de C à Paris 7 est un Mel ; on a parlé de trucs tellement bas niveau qu’on n’a pas eu le temps d’arriver jusqu’aux pointeurs. *oups*

Après Mel, nous avons Einstein, expert en architecture, à la fois bas et haut niveau : il sait comment fonctionne la machine et en tient compte, voire en tire parti, dans son code, qui sera bien bâti et pourra être facilement maintenu. Einstein, typiquement, c’est Palpatine (ouais, je couche avec une rockstar dans son domaine ; jalousez). Palpatine = new.Einstein() (un homme-objet, hihi)(pardon, je m’égare)

Et puis, à côté de Mel et Einstein, vous avez Mort, qui bricole en chopant des trucs à droite à gauche. Le code de Mort, c’est du patchwork : il peut être fonctionnel, voire vraiment efficace, mais ne sera jamais du sur mesure (clairement, la haute couture est l’affaire d’Einstein). Mon année d’initiation au code ferait de moi une Mort-padawan ; j’en sais juste assez pour savoir que je ne pourrai jamais devenir une Einstein, et j’avoue, du coup, avoir moyennement envie de me casser le cul à devenir une Mort. « The vast majority of programmers in the world today are Morts » nous dit Vikram Chandra, qui s’inclut dedans (p. 49). Les Einsteins méprisent généralement les Morts, mais les sous-estimer serait une erreur, car ils sont légion. L’armée des Morts peut être vue comme une bonne chose, le signe d’une (relative) démocratisation du code, aussi bien que comme une plaie pour l’humanité, car ils produisent du code dégueu, que Palpatine appelle généralement du « code d’Indien » (après avoir vérifié qu’il n’y avait a priori aucun Indien parmi ses pioupious). Vikram Chandra propose en filigrane une explication à cet étonnant relent de racisme chez notre Einstein humaniste…

Le geek indien

Vikram Chandra rapporte l’anecdote d’un ami indien travaillant aux États-Unis, à qui l’on reprochait son humilité et à qui l’on conseillait : « walk smart », avec plus d’assurance. Ce reproche d’humilité paraît aberrant à l’auteur, pour qui les étudiants indiens en informatique ont toujours paru insupportablement prétentieux… Incompréhension culturelle : le développeur indien type ne dit jamais non ; cela fait partie d’une culture de face-saving, que ne parviennent pas à saisir les Américains, lesquels, cash, passent en retour facilement pour malpolis. L’endroit de la médaille, c’est que, si on lui reproche de ne pas avoir assez la niaque, on reconnaît au développeur indien une qualité essentielle : la patience. « Indian programmers are also tolerant enough to do the ‘shit’ work. That is: going through somebody else’s code. » (N. Sivakumar, cité p. 86) Le revers, c’est que, dans ces conditions, les programmeurs indiens (tout comme leurs collègues chinois) se retrouvent avec un champ de compétences plus élargi mais plus superficiel, prennent moins d’initiatives et sont moins susceptibles d’innovations que leurs homologues américains, qui ont un champ de compétences plus réduit mais qu’ils maîtrisent à fond. D’où, au final, l’impression d’avoir des spécialistes d’un côté, et une main d’œuvre polyvalente de l’autre – ce qui est malheureusement assez cohérent avec le système éducatif hérité du colonialisme. Les universités technologiques mises en place par le système britannique préparaient en effet à un travail de subalterne. Un étudiant qui voulait étudier les technologies les plus modernes devait partir à l’étranger ; le brain drain vers le MIT était tel que certains professeurs ont fini par refuser de faire des lettres de recommandation… Lors de la décolonisation, des IIT (Indian Institute of Technologies) ont été mis en place mais apparemment, les résultats ne seraient pas encore tout à fait à la hauteur des attentes – pour la masse des programmeurs lambda, rappelle l’auteur. Car des Einsteins, on en trouve peu, mais un peu partout ; l’enjeu, c’est d’avoir des Morts d’un bon niveau. D’ailleurs, quand on vous dit que la France manque de programmeurs, ce n’est qu’à moitié vrai : on manque surtout d’Einsteins, c’est-à-dire d’architectes.

Le geek qui ne savait pas comment fonctionnait un ordinateur

Si les Morts ont tendance à produire du code dégueu, it’s « because they don’t know how the machine really works, and, what’s worse, more Morts don’t want to know » (p. 50) Comment diable peut-on avoir des informaticiens professionnels qui ne savent pas comment fonctionnent les ordinateurs ? C’est qu’il y a un monde entre le langage binaire et les langages haut niveau dans lesquels on programme, qui possèdent une grammaire et peuvent être lus. Chaque couche est ajoutée pour masquer la complexité de la précédente : le langage binaire (0, 1) est repackagé en langage assembleur (8B, EC, bref, de l’hexadécimal), lequel est repackagé en langage haut niveau (avec non plus des chiffres, mais des mots, truc de ouf). Le passage d’une couche à l’autre est très coûteuse en ressources ; l’unique raison pour laquelle on ne s’en aperçoit pas, c’est que les composants augmentent considérablement en puissance chaque année (dans l’esprit des développeurs pressés, plus de puissance signifie manifestement une obligation moindre d’optimiser le code – d’où que les ordinateurs, toujours plus puissants, finissent toujours par ramer autant).

Avec toutes ces couches, du coup, il est assez facile d’oublier les 0 et les 1, et surtout, surtout, d’ignorer comment les 0 et les 1 peuvent avoir à la fois être matériel et logiciel. Vikram Chandra prend ainsi le temps d’un chapitre pour nous expliquer le passage du hardware au software, via les logical gates, « portes logiques ». Avec des 0 et des 1, on peut faire des trucs aussi délirant que des additions et des soustractions dont les mécanismes, tenez-vous bien, peuvent être reproduits mécaniquement. 0 et 1, c’est false et true, c’est éteint et allumé, c’est off et on, etc. Voilà toute la magie. Car si j’ai appris un truc au contact de Palpatine, c’est qu’il n’y a jamais de magie. À chaque fois que vous êtes tentés de voir de la magie quelque part, remplacez mentalement l’incantation par un travail laborieux ; plus vous l’imaginerez laborieux, plus vous aurez de chances d’être proche de la réalité. (Oui, je sais, heureusement que je ne suis pas RH dans l’IT.)

The bug slayer

D’où vient, se demande Vikram Chandra, que le développeur se représente comme un bug slayer alors que, si l’on considère la minutie et la patience déployées, il serait bien davantage un bug sweeper ? On pourrait y voir une sorte de compensation, comme lorsqu’un complexe d’infériorité s’inverse en complexe de supériorité. Mais pourquoi cette revendication prend-t-elle une forme agressive alors qu’elle est parfaitement explicitée, par exemple, comme on l’a vu au début, dans la métaphore du code comme art ? L’hypothèse de Vikram Chandra, étayée de multiples études et citations, est que l’agressivité qui règne dans le monde des développeurs n’est pas une vérité universelle, mais un fait culturel que l’on pourrait rattacher à la mythologie américaine du Far West et du cowboy. Le plus fort, c’est celui qui écrase l’autre ; le meilleur, c’est un killer : un lien s’est insidieusement établi entre testostérone et qualification. Le code est devenu un truc de mec, de vrai, pas de mauviette, et l’agressivité, une manière de gagner le respect de ses paires – fusse contre-productif. Vikram Chandra note ainsi que l’agressivité entre développeurs est particulièrement visible dans le mouvement open-source, pourtant fondé sur les contributions volontaires – tant pis si cela fait fuir des contributeurs potentiels…

//Le côté fun de la chose, quand même, c’est que la virulence générale donne des citations pas piquées des hannetons… //

Geek and gender : où sont les geekettes ?

La geekette vintage

Vikram Chandra lie la problématique de la parité à la mythologie guerrière du milieu, et propose là une hypothèse expliquant pourquoi la programmation est devenue un milieu essentiellement masculin. Devenue parce que, oui, il y avait des femmes aux débuts de la programmation, quand programmer était encore un synonyme de câbler (les ordinateurs n’étaient pas encore multi-tâches ; il fallait effectuer des changements physiques pour que la machine réalise des opérations logiques différentes). Les femmes réalisaient alors les schémas pensés… par les hommes. Des secrétaires de la programmation, en quelque sorte. Pas de quoi crier à la parité, donc, même si certaines ne se limitaient pas à leur rôle d’exécutantes : Vikram Chandra rapporte l’histoire de Betty Holberton qui, après avoir insisté sur le caractère humain et donc faillible des branchements opérés, a obtenu que soit implémenté une fonctionnalité d’arrêt dans les programmes (si j’ai tout bien compris ; j’avoue ne pas être très sûre de mon anglais sur ce coup-là).

Lorsque les programmeurs ont commencé à obtenir la reconnaissance de leur travail intellectuel, on s’est dit que le moyen le plus sûr de recruter des développeurs de type Einstein était de les recruter sur leurs compétences mathématiques et logiques. Et, à l’époque, les personnes les plus susceptibles d’avoir reçu une formation académique dans ces domaines sont évidemment des hommes. La standardisation du processus de recrutement et la reconnaissance de la programmation comme métier intellectuel a écarté les femmes à une époque où elles étaient, dans l’ensemble de la société, cantonnées à des rôles subalternes.

En bref, ce n’était pas brillant, mais pas franchement pire que dans d’autres secteurs. Pourquoi, alors, y a-t-il toujours aussi peu de filles dans ce secteurs-là (alors que, par exemple, les amphis de droit sont pleins de futures avocates) ? Les critères de sélection choisis ont abouti au recrutement d’hommes matheux et asociaux, caractéristiques qui ont fini par devenir des prérequis. Inconsciemment, la logique s’est inversée : pour être (bon) développeur, il faut être (un homme) asocial et matheux. Et il n’est pas totalement absurde de supposer que horde masculine a répondu à la stigmatisation dont elle a fait l’objet en en rajoutant dans la testostérone dont on la soupçonnait de manquer (dans les teen movies, le nerd, souvent incarné par un maigrichon ou un bedonnant, et le beau gosse sportif, souvent présenté comme benêt, ne forment à peu près jamais une seule et même personne…). Nous voilà revenus aux bug slayers des temps présents.

Culture dominante, culture invisible

« The rudeness of the elite programmers – the explaination goes – is actually the necessarily blunt, no-bullshit-style of problem-soving engineers who value results over feeling » (p. 67). Dans ce système, c’est la valeur du code qui a de l’importance, indépendamment de l’origine nationale ou ethnique du programmeur. La culture ne serait pas pertinente ; elle serait même inexistante : tout serait le résultat d’un processus naturel et, selon cette logique, s’il n’y a pas de femme dans le milieu, c’est qu’elles savent pas ou ne veulent pas coder. Signe d’une culture dominante : elle réussit à devenir invisible ou, du moin, à se présenter comme le résultat d’un processus naturel.

WASP n’est pas geekette

Vikram Chandra rapporte un fait curieux pour nous occidentaux : alors que l’Inde n’est pas franchement réputée pour être un modèle en terme de parité, le pourcentage de femmes développeuses y est plus élevé qu’aux États-Unis. Le développeur n’y a pas du tout la même image : loin du stéréotype de geek/hacker, il est vu comme une personne bosseuse, intelligente, méticuleuse, qui aide ceux qui en ont besoin et participe volontiers aux activités sociales, sport compris (p. 81). Du coup, les filles sont plus enclines à envisager ce secteur comme discipline dans lequel faire valoir leurs compétences intellectuelles. Sans compter qu’en Inde, ajoute l’auteur, travailler dans un bureau est vu pour les femmes comme un moyen de se protéger du monde extérieur. Cette corrélation entre image du geek et taux de féminisation serait corroboré par des études menées en Iran, à Hong Kong, à Taïwan… et même, par la négative, aux États-Unis : en effet, les filles d’origine étrangère sont statistiquement plus nombreuses que les filles WASP (enfin « Non-Hispanic white girls »)… Citant Varma, Vikram Chandra avance donc que l’inégalité des sexes dans la programmation aux États-Unis semble être spécifique à ce pays et ne pas être un phénomène universel comme on a coutume de le penser. Vu qu’on a aussi le problème en Europe, il faudrait quand même élargir à l’Occident, mais l’hypothèse comme quoi le faible taux de femmes dans la profession est corrélée à l’image du programmeur viril, agressif, héritée de l’imaginaire américain du Far West, est pour le moins intéressante – surtout, donc, quand on observe que cette vision-là du geek ne s’est pas propagée partout.

// Parenthèse franco-française nombriliste

J’ai aperçu sur Twitter quelques louables tentatives pour promouvoir les femmes dans le numérique, mais je reste dubitative sur l’efficacité des chartes graphiques rose pétant… On ne masquera pas l’image négative d’un univers geek quasi-exclusivement masculin avec un coup de peinture, mais plutôt en donnant vie à une nouvelle image globale. Pour changer la composante genrée du cliché du geek comme mec matheux et asocial, il faudrait je crois changer les autres également. Faire connaître la sociabilité et la culture geek dans sa diversité, au-delà des mangas et des jeux vidéos, avec ses films, ses livres (je ne me suis toujours pas remise de la preuve de l’inexistence de Dieu par Dieu lui-même dans The Hitchhiker’s Guide to the Galaxy), mais aussi et surtout son histoire et ses modèles féminins. Parce que oui, il y en a ! Et pas des moindres : le premier programme informatique a été écrit par Ada Lovelace. Or, en-dehors des geeks, je ne crois pas que grand monde ait ouïe dire de l’existence de cette pionnière… Ni de Grace Hopper, qui a conçu le premier compilateur (le truc qui transforme un programme écrit avec des mots en chiffres compréhensibles par la machine).

Il pourrait également être utile d’y aller mollo sur la culture de warrior / survivor entretenue et même revendiquée par des écoles comme Épita/Épitech ou 42. Le côté koh-lanta de la piscine m’aurait probablement découragée de faire l’école 42 (même si je comprends son utilisation pour marquer la rupture d’avec un enseignement traditionnel et récupérer les élèves qui ne s’y sentaient pas bien) : les blagues de cul des mecs et le travail à outrance ne me dérangent pas si et seulement si j’ai dormi plus de 7h dans mon lit et pris un petit-déjeuner consistant. On peut être intelligent et motivé mais pas très résistant physiquement. Ou simplement aimer son confort. Alors votre devise officieuse de « Dormir, c’est tricher », vous pouvez vous la mettre où je pense.

Enfin, surtout, surtout, il faudrait dire haut et fort que la programmation (sauf dans certains cas bien précis mais pas majoritaires), ce ne sont pas des maths, mais de la logique. On se fout que vous sachiez résoudre des équations du second degré si vous kiffiez les énigmes du Journal de Mickey. Un langage de programmation, c’est comme son nom l’indique un langage. Captain obvious, je sais. Rappeler que la composante linguistique est essentielle dans la programmation ne serait pourtant pas une mauvaise idée quand on sait que les classes de L sont quasi-exclusivement féminines. Il faut venir chercher les filles là où elles sont ! *Comme par hasard*, on était bien plus proche de la parité dans mon master d’informatique réservé aux étudiants issus des sciences humaines que dans les classes d’ingénieurs issus de S où Palpatine donne cours… Je regrette aujourd’hui de ne pas avoir su plus tôt qu’il y a dans l’apprentissage des langages de programmation un plaisir intellectuel similaire à l’apprentissage des langues étrangères ou au décorticage d’une phrase latine (j’ai d’ailleurs une amie passionnée de lettres classiques qui a assez naturellement bifurqué vers la linguistique informatique). Il me semble retrouver dans l’architecturation du code un plaisir conceptuel et créatif similaire à l’ordonnancement des idées dans une dissertation de philosophie, par exemple… On voit les choses prendre forme. Et bonheur supplémentaire : ça marche ou ça ne marche pas ; on le voit immédiatement.

Alors oui, il y sûrement une question de légitimité (est-ce que je me sens capable de faire ces études ?), mais je crois qu’on néglige pas mal la question de l’appétence (ai-je envie de faire ces études ?), qui me semble bien plus efficace pour parer à la pénurie de femmes dans le numérique. En tant que première de la classe un brin arrogante, je n’aurais pas eu besoin qu’on me donne confiance mais qu’on me donne envie… Je n’ai tout simplement jamais songé à m’orienter vers l’informatique : c’était dans mon esprit un truc de matheux et les mathématiques me donnaient beaucoup moins de plaisir que les lettres ; j’ai préféré aller en L, au grand dam de mon professeur de physique… et de ma prof de français, manifestement plus élitiste encore que littéraire.

Strapless

Strapless est typiquement le bouquin que j’aurais laissé en plan s’il ne m’avait pas été offert. Il se veut l’histoire d’un tableau de John Singer Sargent intitulé Madame X. Mais Deborah Davis, l’auteur, a la mauvaise idée de commencer par le commencement, qu’elle situe deux générations en amont de ladite madame X, aka Amélie Gautreau. On patauge pendant quelques chapitres dans la Nouvelle-Orléans pour finalement suivre Amélie à Paris et, sitôt arrivé, la laisser tomber pour tout recommencer avec Sargent. Clairement, Deborah Davis et le storytelling font deux. Strapless ne fonctionne ni comme roman ni essai : l’illusion romanesque est régulièrement interrompue par l’auteur qui nous faire part de ses hésitations ou des différentes interprétations qu’elle a pu rencontrer, lesquelles font paraître, par contraste, le récit trop fleuri et trop bavard pour une enquête minutieuse qui aurait pu générer son propre suspens.

L’auteur ne sait manifestement pas trop où elle va, mais elle nous y emmène avec plaisir. Oublions les grands arcs temporels du roman ou de l’essai : Deborah Davis a le goût de l’anecdote et le talent des miniatures. L’absence de dramatisation se voit ainsi compensée par des vignettes colorées. Sa description du début des grands magasins, par exemple, je l’aurais bien vue en citation dans mes poly d’histoire sur la société des années 1870-1910. C’est vivant, c’est bien vu. On se laisser entraîner dans le tout-Paris de la Belle Époque avec le même amusement que l’on aurait à feuilleter des journaux d’époque, reconstituant tout un univers à coup de ragots. J’apprends ainsi que le portrait du Dr Pozzi (amant d’Amélie ?) serait l’inspiration du Portrait de Dorian Gray ; que Sargent a rencontré dans son cercle la fille de Théophile Gauthier ; et qu’il a été courtisé par Henry James, sans que l’on sache dans quel sens, les préférences sexuelles du peintre, extrêmement discret, demeurant un mystère (dont on se fout un peu, mais ça a manifestement l’air d’embêter les biographes). On pénètre également dans les coulisses des Salons de la peinture : on apprend que la taille des toiles était souvent choisie comme un moyen d’attirer l’attention, que les lauréats d’une année étaient systématiquement admis à exposer l’année suivante, et que le tout-Paris s’y pressait, au moins autant par goût du scandale que de la peinture.

Le même tout-Paris qui portait Amélie Gautreau aux nues s’empresse de vouer son portrait aux gémonies, sous prétexte que l’absence de bretelle à cette robe décolletée et comme prête à être ôtée est indécente. Occasion rêvée pour brûler une idole qui devait certainement éveiller les jalousies ou réelle indignation bourgeoise ? Il y avait certes largement plus de chair étalée dans d’autres tableaux du salon, mais le nu avance en funambule sur le fil de la morale : s’il est placé dans un contexte mythologique ou biblique, il ne provoque pas un haussement de sourcil ; s’il est rendu actuel, en revanche, ou si l’on reconnaît la modèle (ce qui trahit le sujet biblioco-mythologique comme prétexte), scândâle ! De fait, la nudité est largement moins problématique que l’érotisme. Et, pour le coup, en ne montrant rien, Sargent suggère beaucoup : une bretelle en moins et voilà la robe prête à être ôtée. Si encore la modèle s’offrait de bonne grâce… mais quoi, ce profil ? Les admirateurs en ont assez d’être dédaignés. Trop, c’est trop – ou pas assez. L’attraction d’Amélie a assez duré, et en moins de temps qu’il n’en faut pour le dire, c’en est fini pour elle. On éprouve un peu de compassion par principe, mais guère plus car, sous le mystère que veut nous peindre Deborah Davis, on finit par soupçonner une personnalité un peu creuse, celle d’une belle femme un peu vaine et un peu capricieuse, qui avait comme qualité principale de savoir gérer son image. Si le tableau de Sargent lui a coûté sa réputation, il lui assure désormais sa postérité, après une période où le peintre a été mis de côté, jugé trop traditionnel par l’histoire de la peinture, avide de ruptures. Loin du peintre maudit, Sargent a été un portraitiste qui a (bien) vécu de ses commandes. Il a profité de sa double identité américaine-européenne pour s’éloigner de Paris après le scandale de Madame X, et son (abondant) travail aux États-Unis a finalement redoré son blason auprès de sa clientèle européenne.

Le plus drôle, au final, aura été le réseau de coïncidences dans lequel ce livre s’est trouvé : JoPrincesse est tombée dessus lors d’un voyage à New York peu de temps après que je lui ai parlé de mon goût pour Sargent, et ma lecture a précédé de peu l’annonce d’un ballet de Christopher Wheeldon qui en est directement inspiré – ballet que, vous vous en doutez bien, je brûle à présent de voir !

Carnet de lecture : pèlerinage murakamiesque

L’incolore Tsukuru Tazaki et ses années de pèlerinage. L’impression d’avoir déjà lu ce roman. De lire à chaque Murakami le même roman :

une comparaison improbable dès l’incipit,

À cette époque, il lui paraissait pourtant plus aisé de franchir le seuil qui sépare la vie de la mort que de gober un œuf cru.

Haruki Murakami, L’Incolore Tsukuru Tazaki et ses années de pèlerinage, 10/18, p. 7

un leitmotiv musical,

Ici, les Années de pèlerinage de Liszt ; dans 1Q84, que je n’ai jamais réussi à finir, c’était un quatuor de Janáček…
Et, en plus de ce leitmotiv, quelques références disséminées ici et là :

Durant les quinze minutes environ que dura son attente, il mémorisa tous les modèles de Lexus proposés à la vente. Il nota qu’elles ne portaient pas un nom qui les distinguait comme « Corolla » ou « Crown », mais qu’on les distinguait seulement par un numéro. Comme les Mercedes ou les BMW. Ou comme les symphonies de Brahms.

p. 156

(Il y a forcément une thèse qui a dû être écrite sur le sujet.)

un mystère autour duquel on mène une enquête mystico-philosophico-poético-psychanalytique,

Pourquoi Tsukuru Tazaki a-t-il été, du jour au lendemain et sans aucune explication, rejeté de son groupe d’amis, liés comme les cinq doigts de la main ? Seize ans plus tard, sa nouvelle potentielle petite amie lui demande d’élucider ce mystère ; elle sent qu’il y a quelque chose entre eux.

des récits en abyme,

Ici, un homme qui, au seuil de la mort, acquiert une vision d’une extrême acuité sur le monde.

un onirisme érotico-fantastique qui me semble de plus en plus identifiable comme nippon (cf. Le Bras),

Vocabulaire cru comme le poisson des sushis, qui passe pourtant comme une lettre à la poste.

et des vérités dont la temporalité lente du roman se charge d’évacuer l’aspect sentencieux qu’elles revêtent une fois extraites :

Pour chaque chose, il faut un cadre. Pareil pour la pensée. On ne doit pas craindre le cadre exagérément, mais il ne faut pas non plus craindre de le casser. C’est ça le plus important pour trouver la liberté. Respecter et détester le cadre. Les choses qui comptent le plus dans la vie d’un homme sont toujours ambivalentes.

p. 74

Tsukuru réussit alors à tout accepter. Enfin. Tsukura Tazaki comprit, jusqu’au plus profond de son âme. Ce n’est pas seulement l’harmonie qui relie le cœur des hommes. Ce qui les lies bien plus profondément, c’est ce qui se transmet d’une blessure à une autre. D’une souffrance à une autre. D’une fragilité à une autre.

p. 299

***

Comme c’est le même mystère qui se rejoue encore et encore, on pourrait arrêter de lire n’importe quand, mais on continue à tourner les pages, au détour desquelles on trouve parfois une peinture un peu trop vive, un peu trop réaliste, du monde dans lequel on vit. Parfois amusante…

Tout dans cette pièce était simple et cohérent. Il n’y avait rien de superflu. Chaque meuble et chaque élément étaient des articles haut de gamme mais, à l’inverse du luxe déployé dans le show-room Lexus, tout ici avait été conçu pour rester discret. « Ruineux anonymat » : tel semblait être le concept de base de ce bureau.

p. 180

… et parfois moins, quand on s’y retrouve (pour le coup, je vois rouge – du nom du personnage) :

Je n’étais apparemment pas fait pour être salarié, poursuivit Rouge. De prime abord, rien ne l’indiquait. Moi-même, jusqu’à ce que je sorte de l’université et que je travaille, je ne m’étais pas aperçu que j’avais ce caractère. `

p. 185

C’est un autre personnage qui parle :

Je veux juste continuer à m’exercer à la pensée pure et libre. C’est tout. Néanmoins, j’admets volontiers, au fond, que pratiquer la pensée pure, c’est comme créer du vide.
– Il est bien possible que le monde ait aussi besoin de gens qui créent du vide.

p. 60

Dans cette conversation, il est question de penseurs académiques, mais on se demande plus tard si ça ne vaudrait pas autant et même plus pour les auteurs du bullshit managerial. Cela devrait plaire à Palpatine :

J’ai donc essayé de dresser la liste de tout ce que je n’aimais pas, de ce que je ne voulais pas faire, de ce que je ne souhaitais pas que les autres me fassent. À partir de cette liste, j’ai conçu un programme grâce auquel on pourrait former efficacement des employés à obéir aux ordres venus d’en haut et à travailler avec méthode. Enfin, « j’ai conçu », c’est peut-être exagéré, étant donné que j’ai puisé ici ou là. Mon expérience de stagiaire dans la banque m’a été très utile. J’y ai ajouté des techniques issues du développement personnel ou des mouvements sectaires. J’ai aussi étudié les programmes vendus par certaines sociétés qui font un tabac aux États-Unis. J’ai lu des tas d’ouvrages de psychologie. Et je me suis servi des manuels destinés aux nouvelles recrues de la SS ou chez les marines. […]

Pas question d’imposer un remède de cheval. Ce serait un moyen d’obtenir des résultats spectaculaires, certes, mais temporaires ; à long terme, cela ne marcherait pas. […] Notre objectif n’est pas de créer des espèces de zombies. C’est dans l’intérêt de l’entreprise que nous formons des travailleurs qui croient penser par eux-mêmes.

p. 185-186

Le plus dur, quand on a cessé de croire, c’est de s’illusionner.

***

Pour la route, parce que cela m’a rappelé l’étude des Méditations métaphysiques de Descartes, où l’on est coincé si l’on n’admet pas un certain nombre d’idées – et notamment l’idée de Dieu :

Il existe pourtant des exemples concrets que l’on est contraint d’accepter ou pas, de croire ou pas, sans possibilité intermédiaire. Autrement dit, il faut accomplir un bond spirituel. La logique, dans ces cas-là, ne pèse d’aucun poids.
– En effet, c’est à ces moments précisément que la logique cesse d’opérer. Il n’existe pas de manuel qui indiquerait à quels moments employer la logique. Mais peut-être est-il possible de l’appliquer après coup.
– Après, cela risque également d’être trop tard.

p. 90

Accomplir un bond. Non pas Je pense donc je suis (rationalisation a posteriori de La Méthode) mais Je pense, je suis.

Carnet de lecture, janvier 2015

Écrire à propos d’œuvres déjà composées de mots tient moins de la transcription que du résumé – sauf à se lancer dans une véritable critique littéraire. L’envie n’y est pas ; il y a des gens qui font cela beaucoup mieux que moi. Je ne consignerai dans cet éphémère carnet de lecture que quelques extraits, une ou deux réflexions plus ou moins fortuites, au cœur ou à la marge des lectures qui les ont suscitées.

Le Flûtiste invisible, Philippe Labro

« Elle s’est levée et s’est dirigée vers un phonographe – vous vous souvenez ? Un de ces merveilleux appareils qu’on ne trouve plus aujourd’hui que chez les antiquaires. »

Dad, pourtant parfaitement en phase avec son temps, fait parfois ça : poser d’emblée qu’il est dépassé. Se croire déjà trop vieux pour être compris, alors qu’on l’est parfaitement, serait-il un symptôme de l’âge qui vient, le pressentiment, peut-être, du moment où l’on ne sera véritablement plus compris ? Parce qu’on sait ce qu’est un phonographe. Je le sais depuis toute petite, depuis Babar, je crois. Le phonographe reste curieusement associé au dessin animé et à l’élégance de la vieille dame : proximité graphique entre le pavillon de l’appareil et l’oreille des éléphants ? première représentation de l’objet ?

Mais si c’est déjà par le biais d’une représentation que je connais le phonographe et pas par l’objet lui-même, peut-être que la génération suivante, de laquelle l’auteur espère être lu, ne la connait pas. Et d’un coup, ce n’est plus l’âge de l’auteur que marque cette innocente incise (vous vous souvenez ?), mais le mien. Sur le coup du phonographe, en dépit de l’arithmétique des années, je suis plus proche de l’auteur que des lecteurs en herbe. Mais alors, faudra-t-il tout expliquer ? Accepter de se laisser dévorer par les notes de bas de page ? Un intervenant du master édition nous racontait que, déjà, son jeune fils ne comprenait plus Gaston : qu’est-ce qu’était tout ce courrier des lecteurs ? Pourquoi toutes ces lettres ? Ils ne pouvaient pas envoyer des mails, comme tout le monde ?

La Beauté, tôt vouée à se défaire, Yasunari Kawabata (recueil de deux nouvelles)

« Le Bras » est l’une des plus belles choses que j’ai lues depuis longtemps. Une fille confie son bras à un homme, qui l’emporte chez lui pour une nuit, et c’est toute l’étrangeté de l’abandon amoureux qui surgit, dans un mélange d’érotisme et d’onirisme comme seuls les Japonais savent le faire (j’ai découvert ce fantastique nippon avec « Le Bureau de dactylographie japonaise Butterfly » dans La Mer, de Yôko Ogawa).

« Il y a quelque chose que je comprends mal chez les femmes, c’est leur manière de s’abandonner. Je me demande ce qu’elles entendent par « s’abandonner ». Pourquoi le souhaitent-elles, et pourquoi en prennent-elles l’initiative ? Je n’ai jamais compris, même quand j’ai su que leur corps était fait dans ce but. »

« La Beauté, tôt vouée à se défaire. » Je préfère le titre au récit, tentative d’épuisement d’un meurtre, qui souligne tout à la fois notre besoin d’ordonner le réel pour le comprendre et l’impossibilité d’en restituer le chaos. La reconstitution est toujours une re-création, aussi récréative soit-elle pour le lecteur. Le meurtre l’exemplifie, mais on en fait tout aussi bien l’expérience en essayant de se souvenir des paroles exactes d’une conversation. Même d’une seule phrase, c’est quasi-impossible. On s’arrête à la version qu’on estime la plus proche ou la plus à même de reproduire l’effet ressenti. Les guillemets, qui n’ont plus vocation à contenir une citation exacte, ne sont plus qu’une trace d’oralité, qu’on laisse pour signaler qu’à cet endroit, ce moment, quelque chose a été dit.

« Il me semble surtout que le malheur des hommes a commencé à partir du moment où ils ont appris à le conserver artificiellement. »

La Nouvelle rêvée, Arthur Schnitzler

Je ne savais pas que La Nouvelle rêvée était à l’origine d’Eyes Wide Shut. Je l’ai prise à cause de Mademoiselle Else et de l’érotisme qu’Arthur Schnitzler fait surgir de la pudeur (du refoulement, si l’on se réfère à la Vienne des années 1900). Comme dans le film, s’opposent des faits réels vécus comme dans un rêve et un rêve beaucoup trop réel une fois raconté – comme si les images agencées à l’insu de la rêveuse devenaient à voix haute, adressées à son mari, des intentions qui lui étaient imputables. On sait si bien se faire du mal ; Arthur Schnitzler le saisit comme aucun autre. On sait si bien se faire du mal – à soi, par le truchement de l’autre. Indice que l’autre n’est qu’un intermédiaire : le narrateur ne réussit pas à en vouloir à sa femme, Albertine (qu’on pense aussitôt disparue, à cause de Proust). Elle sera là, chacun sera là pour l’autre, pour qu’il ne s’en veuille pas – la vie de famille apaisante après la piqûre éprouvante de la passion.

Le Restaurant de l’amour retrouvé, Ito Ogawa

Je consignerai quelques-unes des jolies métaphores qui émaillent ce livre quand je l’aurai récupéré (j’oublierai sûrement mais, au moins, vous saurez qu’il contient de jolies métaphores). Ce roman où la narratrice cuisine pour les gens, qu’elle rencontre en amont du repas pour le préparer en fonction de leur situation et de leur personnalité, m’a fait prendre conscience que mon envie récente de me mettre à cuisiner est surtout une envie de revoir/recevoir mes amis, qui me manquent un peu – par ma propre faute, par paresse. Au programme des week-ends prochains : l’achat d’une table et de chaises. Près d’un an après la pendaison de crémaillère qui n’a toujours pas eu lieue.