'Coders' : plongée dans le quotidien des dev

Comprendre les choses et les gens, c’est ma passion. Alors quand j’ai commencé ma reconversion, assez rapidement, je me suis dit que pour devenir développeuse, apprendre à coder n’était pas suffisant. Il fallait aussi que je comprenne le milieu où on code et comment pourquoi les gens le font.

Pour ça, entre autres choses, j’ai cherché des livres et notamment dans un domaine que je connaissais - parce que c’était quand même cool de se raccrocher à quelque chose de connu : l’anthropologie des institutions et du travail. Et la je suis tombée sur plein de choses fascinantes : il y a quelques recherches qui dissèquent en profondeur le travail et notamment les modalités collaboratives de développement (comme ça ou ça), mais ce n’est pas de ça dont je veux vous parler aujourd’hui. Aujourd’hui, je veux vous parler du livre de Clive Thompson, sur lequel je suis tombée pendant ces recherches et que j’ai littéralement DÉVORÉ :

Si je vous en parle aujourd’hui, c’est parce que je pense que ce livre devrait être lu par (cette liste n’est pas exhaustive) :

• Tous les gens qui veulent travailler dans l'informatique (que vous soyez en sortie de bac, en reconversion, en raccrochage de Master, peu importe) : à chaque page de ma lecture je me disais “mais c’est exactement ce que j’aurais aimé savoir avant de devenir dev!!”.
• Tous les chercheurs.euses qui s’intéressent au numérique : si vous avez envie de creuser le sujet mais ne savez pas par où commencer, foncez, c’est une mine de références, de sujets abordés, etc.
• Toutes les personnes qui travaillent avec des dev : ce livre va vous sauver. Vous avez rêvé que quelqu’un arrive et vous explique pas à pas comment fonctionne un.e dev, c’est quoi le fucking quotidien de ses journées, concrètement ??? Clive Thompson l’a fait.

Alors tout de suite, je vous vois froncer les sourcils et vous avez raison : moi aussi quand on me dit que quelqu’un a fait le tour d’un sujet et vous donne une recette miracle, c’est du pipeau. Et je pense que c’est le tour de force de ce livre : dresser un portrait plutôt complet du métier et assez généraliste, tout en soulevant toutes les nuances, différences, problématiques, etc. qu’il peut y avoir dans ce domaine.

Alors oui, le livre a des défauts et j’y reviendrai. Mais avant de dire ce qui ne va pas dans ce livre, voici quelques thèmes qu’il aborde et qui m’ont marquée :

Qui sont les “gens qui codent” ?

Clive Thompson part d’une idée simple : le numérique est partout, mais souvent on aborde ce sujet comme s’il tombait des nues ou apparaissait tout seul de lui-même. Pop “Et au 8e jour, naquit Facebook”. Evidemment que non, des gens existent derrière tout dispositif numérique, comme il le souligne (p.10) :

This may sounds weirdly obvious, but every single one of those piece of software was written by a programmer […]. Sometimes it seems that the software we use just sort of sprang into existence, like grass growing on the lawn. But it didn’t. It was created by someone who wrote out - in code - a long, painstaking set of instructions telling the computer precisely what to do, step-by-step, to get a job done […].

Alors, que font ces "programmers" ? Ça veut dire quoi “développer” ? Pour Thompson, qui a observé, dialogué et s’est lui même essayé au code, c’est une activité difficile pour plusieurs raisons :

• C’est un travail qui utilise une grande ressource cognitive et intellectuelle : coder, ça veut dire maitriser, comprendre et garder à flot dans sa tête tout un système. Il fait un parallèle évocateur : pour faire un changement dans le code, même s'il vous semble minime (par exemple changer la couleur d’un titre sur une page), il faut maitriser tout le système autour de ce titre ce qui reviendrait, par exemple, à connaitre et comprendre comment fonctionnent toutes les rues de Londres juste pour pouvoir renommer une rue.
• C’est un travail qui génère énormément de frustration : c’est une "daily vexation”. En effet, il souligne que la majorité du travail de dev est "de comprendre pourquoi ça ne fonctionne pas". Et cela se fait rarement en tapant frénétiquement sur son clavier des milliers de lignes de code. Scott Hanselman (programmeur à Microsoft) lui disait : "Dude, I’ve not idea how you’re going to write this book, because coding is the most boring thing in the world to behold."
• Les dev travaillent soit avec des machines intolérantes au moindre problème (ce qui fait du développement un travail extrêmement précis et rigoureux où chaque éventualité doit être anticipée) soit avec des utilisateurs imprévisibles.

Pour Clive Thompson, ces raisons sont quelques unes qui expliquent pourquoi ce travail attire des gens au profil spécifique : si les dev qu’il a rencontrés sont tous.tes très différent.e.s, il remarque trois traits en commun :

• Ce sont de gens qui aiment régler les problèmes au sens de résoudre des énigmes. Ce sont des “puzzle solvers”.
• Ce sont des gens précis. Pour certain.e.s, à la limite de l'obsession. Pourquoi ? Parce que leur interlocuteur de travail principal est la chose la plus intransigeante du monde : comme le confirme le fondateur de Stack Overflow, Jeff Atwood (p.68) : "The computer is a complete asshole. It doesn’t help you out at all […] working with computers all day long is like to share an office with a toxic, abusive colleague."
• Ce sont des gens qui aiment optimiser et gagner du temps.

Clive Thompson note aussi des évolutions dans ce qui est recherché chez les dev, selon les milieux, les technologies, etc. Il se penche sur plusieurs mythes liés aux développeur.euse.s, à commencer par celui du "10x programmer”: une sorte de star system qui valorise un nombre très restreint de personnes qui seraient extrêmement brillantes et sur qui reposerait la grande majorité des innovations technologiques. Cette idée se retrouve dans de nombreux “récits mythiques” de fondation de grandes entreprises comme Facebook, Youtube, Snapchat, etc. Elle repose sur une deuxième idée mythique selon Thompson : celle de la tech comme un des domaines où la méritocratie est reine, où ne compte soit-disant que l’excellence du code fait, qui peut l’être par des anonymes sur des projets opensource et qui donc, par essence, ne discriminerait personne.

De cette idée à celle de la "revanche du nerd”, il n’y a qu’un pas : le code serait le domaine méritocratique par excellence ou des gens aux profils atypiques, mis de côté par la société (les nerds) seraient enfin considérés sur la base uniquement de leurs compétences. Ce mythe est problématique pour Clive Thompson qui observe qu’il crée des “brillant jerks” des programmeurs convaincus de leur propre irremplaçabilité et qui pensent que le code ne repose que sur leurs épaules, incapables par conséquents de remises en question, de communication, etc. Il souligne à quel point ce mythe et d'autres ont impregné le système, sont encore vivaces dans certaines entreprises et polluent certains fonctionnements et même le travail d’autre dev.

Finalement, le dernier point de ce profil - le désir d’optimisation - permet de faire une transition vers un thème très exploré par l’auteur, à savoir le lien entre le code et le capitalisme.

Code et capitalisme: l’optimisation à tout prix

Clive Thompson observe au fil de ses entretiens que les dev sont des personnes qui ont une appétence pour l’optimisation et l’augmentation d’échelle. Ils n’aiment pas répéter les choses. Qu’est-ce qui est efficace pour répéter les choses ? Les ordinateurs. Ils exécutent, sans fin, sans limite, sans se plaindre, les mêmes tâches. Ad vitam aeternam. Ce qui expliquerait pourquoi libéralisme et tech iraient si bien ensemble. La tech serait intrinsèquement faite pour le capitalisme, dont un des principes est l’optimisation.

Pour Thompson, cette tendance à automatiser ces tâches dites "répétitives" et "pénibles" a des revers: comme, premièrement, le risque de tout considérer comme répétitif et pénible et donc de perdre par exemple, des choses humaines, comme la communication phatique. Konrad Zuse, considéré comme le créateur du premier ordinateur programmable disait à ce sujet (p.129) :

The danger that computers will become like humans is not as great as the danger that humans will become like computers.

En outre, qui décide de ce qu’est “une tâche pénible” ? Pour Thompson, les dev étant en majorité des jeunes hommes blancs (et le processus qui amène à ce résultat sera disséqué tout au long du livre), il remarque que l’“innovation technologique” s'est parfois davantage apparentée à des “dudes wanting to replicate mom” (Clara Jeffery, éditrice en chef de Mother Jones sur X). Et cette volonté d’alléger certaines tâches se fait souvent au mépris de l'augmentation de la charge des tâches pour d’autres personnes ou à d’autres endroits de la chaine de pénibilité.

Finalement, le lien entre code et capitalisme est beaucoup plus complexe que leur rencontre sur l’optimisation. D’une part, il souligne l’ironie dans l’idée que le développement technique de ces dernières années aurait reposé sur l’innovation des entreprises privées. Comme le relèvent R&D Magazine et Mariana Mazzucato (The entrepreuneurial state: debunking, public vs private sector mtyh, 2015), une grande majorité de l’industrie technique a été construite sur des innovations payées par l’Etat et l’argent public: les militaires ont acheté les micropuces en masse, la défense a financé les recherches sur les bases de données relationnelles, la cryptographie, la reconnaissance vocale et faciale et même les protocoles internet eux-mêmes ! Sans parler de l’IA….

D'autre part, il revient sur des moments où les devs se sont opposés aux systèmes en place, notamment capitalistes.

Quand les programmeurs s'opposent aux gouvernements

L’autre contrepoint intéressant aux liens entre tech et capitalisme est la partie consacrée au partage des connaissances, aux initiatives de protection des utilisateurs qui ont émergé du côté des dev, historiquement et actuellement, et qui ont crée des clashs entre les dev et les pouvoirs en place.

L’histoire est remplie d’exemples de ces clash qui se cristallisent notamment beaucoup autour de l'opensource et de la privacy. Dans les années 1970, une large frange de programmeurs pensent que le code qu’ils écrivent doit être accessible à tout le monde, mais pas les données des utilisateurs.trices.

Dans les années 80, les clashs entre gouvernement et programmeurs se durcissent aux Etats-Unis et le FBI commence à arrêter ce qu’ils nomment alors les “hackers” : des gens qui s’introduisent dans des ordinateurs ou du code auquel ils ne devraient pas avoir accès, mais surtout qui écrivent des logiciels spécifiques. Est particulièrement ciblé le code qui permet d’améliorer le chiffrement. En effet, depuis quelques années, les dev sont de plus en plus conscient.e.s que tout usage du numérique laisse des traces qui peuvent être suivies. With Diffie est inquiet de la façon dont les communications sont chiffrées : à ce moment, deux parties dans une communication ont une clé de chiffrement qu’elles partagent et qui leur permet de déchiffrer les communications de l’une et l’autre. Mais il est facile de perdre sa clé ou de se la faire voler. Il invente donc un autre système de chiffrement encore utilisé aujourd’hui : un système dit asymétrique, le système de clé privée/publique. Cette “invention” alarme le FBI (p.241) :

If you simply took this technology and released it widely, you were also potentially creating an opportunity for very small terrorist groups, criminals and the like to use this technology to get kind of perfect information security.

(Stewart Baker, 1er secrétaire du département de la défense américaine alors à la NSA in : Gregory Ferenstein, "How Hackers Beat the NSA in the ‘90 and how they can do it again”, TechCrunch, june 29, 2013).

La défense de l’opensource est un pivot de cette partie et Clive Thompson revient aussi les dev qui ont donné leur vie pour défendre certains principes, comme Aaron Swartz, évidemment. Ce dernier est un pionnier du travail opensource, accusé et acculé par le gouvernement américain parce qu’il met à disposition les articles scientifiques normalement payants, il finira par se suicider. Cette partie explore le débat sensible de la responsabilité des développeurs dans l’usage des outils qu’ils créent : si certains projets, comme celui d’Aaron Swartz, n’ont pas forcément trouvé d’utilisation dangereuse ou nuisible, d’autres comme le durcissement du chiffrement, le développement de la privacy ou du web ouvert, peu trackable (Thompson explore l’exemple de Tor), permettent aussi à beaucoup de réseaux mafieux ou terroristes de se développer.

Le problème de l’intégration des minorités dans la tech

On le disait plus haut, Thompson soulève la grande homogénéité des profils dans la tech : des hommes blancs. Le sujet traverse tout le livre et est en outre traité dans un chapitre spécifique. En ce qui concerne le genre, il souligne que le monde informatique est une aberration, un ovni dans le monde professionnel occidental : les domaines dans lesquels le nombre de femmes a toujours été faible sont nombreux, mais actuellement, la tendance est quand même pour ces domaines d’augmenter leur part de minorité de genre. Pas dans l’informatique. Dans l’informatique, le nombre de femme a diminué. En 1960 elles étaient 27%, un nombre qui a augmenté jusque dans les années 1990 où elles étaient 35%. Aujourd’hui elles sont 26%, si on compte la tech en général, 18% dans la programmation seulement. Pourquoi ?

Parce qu’au début, le métier était considéré comme spécifiquement féminin, puisque répétitif, secrétarial. Les calculs à faire étaient davantage rapprochés de métiers comme la comptabilité que de métiers scientifiques.

Les femmes ne sont donc pas “pas présentes dans le domaine” mais “elles ont été éjectées du domaine”. Thompson s’arrête aussi sur les formations et leur rôle pour expliquer cette “éjection”. Par exemple, en 1984 survient une “crise” : la demande pour devenir dev explose et du coup le formations mettent en place des critères d’entrées. Ces critères étaient très biaisés et ont installé un sexisme latent dans le milieu. Quand la crise est passée et qu’il a fallu re-recruter abondamment, ces critères sexistes étaient en place et sont restés, enclenchant un cercle vicieux : moins les femmes sont présentes dans un domaine, plus le sexisme a de place pour s’y développer et moins les femmes ont alors envie d’intégrer ce domaine.

Ce sexisme a eu pour résultat de diminuer le nombre de femmes dans le domaine, mais aussi et surtout de diminuer la confiance dans leurs compétences : ainsi une étude révèle que les femmes tendent à évaluer leurs compétences techniques plus bas que les hommes. En effet, l’étude, faite sur des hommes et des femmes de même diplôme, demandait quel degré de confiance les enquêté.e.s avaient pour “régler les problèmes avec des ordinateurs”. En moyenne les femmes se notent sur 7.7/10, alors que les hommes se notent 8.4/10. Le pire est quand on demande aux femmes de se comparer avec leur collègues : elles s’évaluent un point et demi en dessous de leurs collègues, alors que les hommes s’évaluent en moyenne 6 fois SUPERIEURS à leurs collègues (Lilly Irani, A different voice: women exploring stanford computer sciences, 2003, thèse de l'Université de Stanford). A diplômes et compétences égales, une femme se sentira en général bien moins “bonne développeuse” qu’un homme.

Evidemment, le problème n’est pas uniquement avec le genre. Si les femmes représentent 18-20% des effectifs, le ratio pour les employé.e.s racisé.e.s est encore plus bas avec des taux autour de 6%. Les études mettent en avant à quel point les minorités ont de la peine, en plus, à se faire prendre au sérieux, se font harceler, voire subissent des critiques et des comportements plus implicites. Thompson cite une étude de performance de 248 reviews d’ingénieurs a révélé que les femmes étaient considérablement plus enclines à recevoir des commentaires tout simplement négatifs, alors que les hommes reçoivent des feedback constructifs, sans négativité.

Evidemment aussi, ces biais sont plus ou moins conscients. Tout le monde de la tech ne se lève pas le matin en se disant qu’il va exclure une grande partie de l’humanité. Et c’est bien là le danger, le côté inconscient de ces biais, comme le relève Cynthia Lee, enseignante en computer sciences à Stanford :

They have a very big blind spot for biases on their side, because the don't think they have blind spots.

Clive Thompson passe tous les arguments en revue, dont notamment celui sur la biologie qui postule que les femmes seraient naturellement moins enclines et compétentes pour les métiers techniques. Les données balaient cet argument d’un revers de main : si c’était vrai, les statistiques de la part des femmes dans la tech n’auraient pas diminué et surtout, on ne trouverait pas des écarts complètement différents dans d’autres pays. En Inde ou au Maghreb, par exemple, la part des femmes dans le developpement est aujourd'hui de plus de 40%. C’est intéressant, car c’est un des rares moments du livre où Thompson cite des arguments non occidentalo-centrés. C’est dommage, car c’est une grosse faiblesse du livre et son biais certainement le plus important : ne s’intéresser majoritairement qu’aux USA ou en tout cas au monde occidental.

Cette réflexion sur la place des minorités se conclue par une question constructive : est-ce qu’il est possible d’inverser cette tendance ? La première partie de la réponse est oui : il cite l’exemple d’Allan Fisher qui a essayé à la Carnegie Mellon University (CMU) en faisant des changements significatifs dans l’offre des cours notamment en proposant des classes par expérience pour ne pas décourager les néophytes, en proposant des cours qui focalisent sur l’impact que le code peut avoir, en changeant la culture de l’université : ils avaient implicitement integré le fait que les étudiants qui entraient dans ces filières s’intéressaient déjà au code ou connaissait l’informatique ce qui leur faisait confondre raw aptitude et previous experience. Toutes ces initiatives ont permis de passer le pourcentage des femmes de 7% à 42%.

La deuxième partie de la réponse est plus complexe et on verra pourquoi tout à la fin de cet article (et de son ouvrage).

L’IA : boucler la boucle

Le livre se termine sur un chapitre consacré exclusivement à l’IA et qui s’arrête sur quelques problèmes. Un entretien avec Andrew Ng et Jeff Dean (les chefs de Google AI) souligne que ce qu’on vit est davantage une montée de l’automatisation et des vitesse d’exécution et de recherche, que de l’intelligence. Leur exemple est celui d’un réseau neuronal qu’ils ont pu faire tourner sur 16000 processeurs google sur un million de vidéos youtube. L’objectif était de voir ce qu’il pourrait reconnaitre à l’issue de cet entrainement. Réponse : des chats. La première chose que l’IA a appris à reconnaitre, ca a été des chats. Ce qui fait parfaitement sens, car les chats sont omniprésents sur le net. L’IA apprend ce qu’on lui donne. Cela permet de pointer le premier problème avec l’IA qui est moins liée à l’IA en elle-même qu’aux espoirs qu’on y met : l’IA reproduit les biais qu’on lui donne car il s’entraine sur des données dont on sait qu’elles sont déjà faussées. Comme le souligne Cathy O’Neil (p.291) :

Big data processes codify the past, they do not invent the future.

Problème 1: l’invocation magique

Un des problèmes liés à l’IA permet de boucler avec le début du livre de Thompson et cet article aussi : comme le code en général, l’IA est entourée d’une sorte d’invocation à la “magie”. Comme le code, l’IA n’est pas “magique” : Hilary Mason le dit simplement (p.296) :

It’s just math. […]. Software firms have often cultivated an air of sorcery, relying on the inscrutability of their work to baffle and enchant customers, while being in reality nothing more than a creaky pile of PHP scripts.

Problème 2: oublier l’effet de groupe

Autre problème du code que l’IA met particulièrement en exergue : peu de dev construisent volontairement un outil pour qu’il serve à propager la haine. Par contre, peu imaginent que leur outil peut propager la haine et lorsque c’est le cas, leur délai de réaction et bien souvent trop long. Thompson soulève aussi un point intéressant : quand on envisage les mauvaises utilisations d’un outil, on les envisage surtout à l’aune d’un seul utilisateur. Peu de dev imaginent comment plusieurs users pourraient se coordonner pour utiliser leur outil de manière malveillante, alors même que l’histoire du numérique fourmille de ces exemples.

Problème 3: penser qu’on n’a pas de poids

Finalement, un problème majeur de la tech est que le dev, un des maillons les plus importants de cette industrie et de ce domaine, pense qu’il a peu de poids dans les décisions. Thompson revient sur son introduction : les dev ont selon lui un énorme pouvoir et pour preuve il cite l’exemple du Projet Maven (un projet de Google de recherche sur l'IA pour le département de la défense des USA sous Trump), qui a été arrêté suite à la pression des développeurs en interne (p. 340).

Problème 4: le changement par l'intégration des minorités et la formation, vraiment ?

Thompson revient sur les enjeux de l'intégration des minorités (femmes et personnes racisées) et notamment du rôle de la formation dans ce changement. Ce que l'IA met en exergue selon lui, c'est que dès qu'un nouveaux champ technique émerge, il est généralement préempté par les hommes blancs. Ce glissement va de pair avec un autre glissement : on sait que, structurellement, dès que les femmes arrivent dans un champ, celui-ci est dévalué. Ainsi s'opèrent des reconfigurations des domaines "techniques" : l'infrastructure, le devops, l'IA, et les champs émergents restent masculins, car "nouveaux", alors que le frontend, rejoint par un grand nombre de femmes (pour beaucoup de raisons systémiques que Thompson aborde mais que je ne développerai pas ici), a été proportionnellement devalué par rapport à d’autres domaines tech.

Finalement, pour Thompson, si l'essor des bootcamps a laissé penser qu’ils pouvaient donner une chance à d’autres personnes d’integrer ce monde, ils sont en fait surtout accessibles aux gens avec une formation supérieure et peu de problèmes financiers. Ils n'atteignent pas du tout l'objectif de la mobilité sociale et les chercheur.euse.s sur le sujet, comme Marie Hicks, ne sont pas positifs sur le fait que les bootcamps pourront aider à renverser la dynamique.

En conclusion

Pfiou c'était long, hein ? Donc je vais faire court pour la conclusion : j’ai dévoré ce livre parce que l’écriture est fluide et que l’enchainement des informations est maitrisé. Les nombreuses citations sont une vraies qualités du livre car on voit que tout le propos de Thompson est enrichi de ses dizaines d’entretiens et de perspectives différentes qu’il a collectées sur le sujet. J’y ai ainsi découvert un nombre incalculable de “grandes figures”, j’ai mis des noms sur certaines “inventions”, j’ai découvert qui se cachait derrière tel département de recherche chez Google ou Pinterest… Bref, le propos est à la fois accessible, généraliste et nuancé grâce à ces nombreuses personnifications. Le livre fourmille aussi d’anecdotes ce qui rend la lecture facile et même amusante. Les notes sont nombreuses, car le livre est incroyablement sourcé, j’y ai découvert un nombre impressionnant de références, d’articles, de recherches scientifiques sur des sujets qui touchent le numérique.

C'est certes une vision, et une vision très USA-centrée (avec ses spécificités), de ce qu'est le milieu de la tech, mais j’ai fait un véritable voyage dans le temps, dans l’histoire de l'informatique, dans ses évolutions au travers de recherche, mais aussi au travers des yeux de certain.e.s développeur.euse.s et occupant depuis longtemps ce milieu. Bref, j’ai appris, ri, découvert… tout ce que j’attends d’un livre.