Quelques mots naïfs sur mon expérience de rookie de la programmation informatique !

J'ai fait l'essentiel de ma carrière dans la "sociométrie", la "modélisation économique", la "méthodologie statistique" et "l'évaluation de politiques publiques", bref, dans des métiers où il faut parler des gens (et aux gens) avec des chiffres, des métiers scientifiques mais où les ordinateurs ne tiennent qu'un rôle secondaire.

Mes connaissances scolaires et universitaires en informatique, un peu superficielles, se sont éventées, et les langages que j'avais appris (assembleur, Basic, Pascal, C, C++, CAML, Prolog) sont presque tous des langues mortes.

Mais depuis 2013, je travaille à temps partiel dans une start-up, où la grande majorité des collègues codent toute la sainte journée. Les schémas papier, explications verbales et autres idées de manoeuvre les laissent froids. Mes maquettes Excel et macros bidouille, mes relectures de code avec questions naïves, étaient tolérées avec charité… Il aurait fallu que je parle la langue commune, celle des machines.

Mais comment trouver le temps et la concentration d'apprendre une nouvelle langue, dans le rythme saccadé de la start-up ?

Le ralentissement de juillet-août m'a enfin permis de me lancer, sur un projet important et qu'aucun collègue n'avait le temps de coder. J'étais au pied du mur !

Voici donc, en vrac, mes sensations.

D'abord la pesanteur, l'inertie énorme du truc. Pour réaliser la maquette Excel du produit, une journée avait suffi ; mais au bout d'une journée dans l'univers de Scala sur Intellij, je commençais à peine à comprendre à quoi servait chaque morceau de l'écran, et il avait aussi fallu ce temps pour que mes collègues informaticiens arrivent à trouver la bonne clé pour que j'accède aux données stockées sur nos bases Cassandra. Le Basic et le Pascal de ma jeunesse étaient des mobylettes qui démarraient au quart de tour ; maintenant, me voilà pilote de tracteur.

Ensuite, la surabondance. Toutes les fonctions développées par des millions de gens à travers le monde sont réutilisables, des "collections", des "libs", des "packages", des machins trucs je n'ai pas encore pigé les différences. Et quand on voit un mot dont on ne comprend pas ce qu'il fait là, Commande-B ouvre immédiatement le bout de code qui l'a défini, et qui, les bons jours, est commenté par l'auteur. Dans mon jeune temps, on programmait en suivant un sentier que l'on traçait soi-même. Maintenant, on active l'un après l'autre les boutons d'un immense cockpit.

Après, la qualité des guides. Les bons guides allient la compréhension profonde du langage, et la compréhension profonde de l'humain qui va devoir l'utiliser. J'ai eu le sentiment de pouvoir faire toute confiance à Nadim Bahadoor et Alvin Alexander. Les mauvais guides abondent. Leur refrain est "Vous pouvez faire tout ce que vous voulez". Ils se reconnaissent facilement, c'est heureux : aux fautes de typographie dans les exemples, ou aux noms de variables bâclés.

Après vient l'exigence. Le sentiment, l'expérience aussi, que le moindre relâchement coûte cher. J'avais appelé vite fait "indexMax" le nombre d'éléments d'un tableau. Quand je l'ai proprement rebaptisé "machinSize", ça m'a fait sauter aux yeux la cause d'un bug récurrent — parce qu'en Scala comme dans d'autres langages, on compte les éléments à partir de 0, si bien que le dernier a le numéro machinSize-1, et l'avant-dernier (auquel je faisais appel) machinSize-2.

J'ai aussi perdu 4 heures, entre avant-hier et hier, à ne pas comprendre pourquoi tel résultat valait si souvent 0 — avant de réaliser que, quand je divisais 1 par 2, cela donnait forcément 0 puisque j'avais défini la variable qui valait souvent 1 comme un entier, avant de voir une utilité à la diviser par 2.

Vers 2014, j'avais travaillé, à temps très partiel, pour un studio de jeux vidéo. Une partie de ce que je concevais (le système d'enregistrement des actions du joueur) était ensuite "codée" par un informaticien du studio (Alexis, si tu m'entends, bravo encore). J'étais surpris par l'ambiance dans les rangées des devs, le calme : écouteurs bien sûr, doigts qui font tourner des crayons, longues minutes passées à regarder l'écran tourner. Je croyais me souvenir que de mon temps, on pissait du code au kilomètre ; que le plus rapide sur son clavier avait un sérieux avantage. Mais avec les langages d'aujourd'hui, je le voyais dans ce studio et je l'expérimente maintenant, on lit et on comprend plus qu'on ne tape. On mange du code, et il faut manger lentement. Une ligne en vaut cent.

C'est pourquoi le terme de code n'est pas si mauvais. Ça ressemble plus à un code (secret, magique) qu'à une langue, ou qu'à un programme au sens commun du terme. Même une formulation aussi simplette que "(aDateTime.getMillisOfDay / seasonDuration).toInt" fait appel à une douzaine de notions, non seulement informatiques mais juridico-physiques (les fuseaux horaires et les changements d'heure) ou économétriques (la saisonnalité).

Quand je fais ma compatibilité, à la fin de chaque ligne, je me sens rassuré d'avoir coché les cases, de ne pas être sorti du cadre. La ligne copiée-collée d'une ligne précédente est la meilleure de toutes, la plus sûre, la plus rassurante. En Scala, au contraire, chaque retour à la ligne me donne le sentiment d'avoir inventé, créé quelque chose, et pris un risque. Copier-coller fait honte. C'est le signe qu'on fait fausse route, que l'on est en train de mal concevoir, de dégrader, de fragiliser l'ouvrage.

Et à l'arrivée, merci les big data : le tracteur tracte. Le programme traite des centaines de milliers de données en un rien de temps — it breaks Excel, comme disait je ne sais plus qui. Comme il m'a fallu, non plus comme avec Excel gérer les données qui étaient sous mes yeux, mais gérer toutes les données qui pourraient arriver demain, j'ai dû prévoir une palanquée d'options et de réglages. Et cette palanquée me donne envie de vendre le truc avec l'argument : "Vous pouvez faire tout ce que vous voulez".

Ah zut, ce n'est pas le bon argument.

Le chemin, à peine, tu débutes, jeune padawan !