Les questions que nous nous posons encore

Quelque chose a changé dans ce que les développeurs se demandent entre eux, et je l'ai d'abord remarqué dans mon propre comportement. Pendant plus de dix ans, entre équipes de grands groupes et startups, les questions qui circulaient entre les gens relevaient surtout de la mécanique. Pourquoi cette regex ne matche pas. Que veut dire cette erreur, au juste. Comment faire pour que ces deux bibliothèques s'accordent sur une version. Je les ai posées, j'y ai répondu, et quelque part au cours des deux dernières années j'ai cessé de faire l'un comme l'autre, parce qu'une machine y répond désormais en quelques secondes, à toute heure, sans donner à personne le sentiment d'être bête d'avoir demandé. Les questions qui passent encore d'une personne à l'autre se sont faites plus rares, et plus lourdes.

L'ancien trafic ne me manque pas. Répondre pour la quarantième fois à la même question mécanique n'a jamais été le meilleur de ce métier, et qu'une machine infatigable l'absorbe est un cadeau. Mais observer quelles questions traversent encore l'espace entre les personnes, maintenant que tout le reste n'en a plus besoin, m'a appris quelque chose sur l'endroit où se déplace la valeur d'un développeur. Trois sortes font encore le voyage, et elles ne sont pas aussi durables les unes que les autres.

Plus récent que l'entraînement du modèle

La première sorte naît plus vite que les modèles n'apprennent. Une release sort le mardi, et dès le mercredi elle casse d'une façon que personne n'a documentée, parce que personne n'a vécu avec assez longtemps pour la documenter. J'écris du code avec deux modèles différents, tous les jours, et à l'instant où un outil se met à jour sous mes pieds, tous les deux passent du sage au devineur sûr de lui sans changer de ton d'un iota. Reconnaître ce basculement est devenu une compétence.

L'objection évidente, c'est que les modèles naviguent sur le web. Ils peuvent aller chercher notes de version et fils d'issues à la demande, et cela a considérablement rétréci cette fenêtre. Mais le retrieval lit du texte, et dans les premiers jours qui suivent la casse, le texte n'existe pas encore. Le savoir vit dans la tête des cinquante personnes qui ont heurté le même mur la même semaine, et dans les messages qu'elles s'échangent une fois qu'elles se sont trouvées. Pendant ces quelques jours, ces personnes sont le seul endroit où la réponse existe. Tout ce que la machine finira par savoir de cette casse devra d'abord passer par elles, parce qu'il faut bien que quelqu'un écrive quelque chose avant que quoi que ce soit puisse le retrouver. La fenêtre continue de se rétrécir, mais chaque release la rouvre à zéro, et les questions qui vivent à l'intérieur continuent donc d'avoir besoin d'une personne. Jamais la même très longtemps, c'est tout.

Plus profond qu'une réponse plausible

La deuxième sorte descend au lieu d'avancer. Le recoin sombre d'un compilateur. Le paragraphe d'une spécification que deux implémentations lisent différemment. La question où une réponse plausible ne sert à rien, parce qu'il faut une réponse dont la justesse se prouve, avec sa provenance, venue de quelqu'un capable de pointer la clause exacte qui tranche. Quand quelqu'un demande pourquoi l'optimiseur a le droit de réordonner ces deux écritures, il ne demande pas un paragraphe qui sonne comme de la documentation. Il demande le modèle mémoire, chapitre et verset.

Autant être clair sur ma position ici, parce qu'elle joue contre moi. J'ai passé une bonne partie de ces dernières années à travailler sur des systèmes de retrieval pour le juridique et la santé, où une réponse incapable de montrer sa source ne vaut rien, quelle que soit son allure, et où tout l'effort d'ingénierie consiste à épingler chaque affirmation au document qui la porte. Ce travail parie que cette catégorie peut s'automatiser, et le pari se porte bien. Une machine qui répond avec la clause exacte à l'appui n'est pas un fantasme ; c'est à peu près ma fiche de poste. Des trois sortes, c'est donc celle que je m'attends à voir rétrécir encore. Le spécialiste qui connaît la spécification sur le bout des doigts gardera l'avantage dans les recoins où les documents se contredisent, et sur les questions que les documents n'ont jamais anticipées. Mais je ne vais pas bâtir un essai sur des douves que je passe mes journées à assécher.

La question qui porte sur vous

La troisième sorte semble la moins technique et se révèle la plus durable. Regardez mon projet. Lequel de ces outils pour mon équipe, vu notre codebase, notre deadline et les deux personnes qui maintiendront vraiment la chose. Vous, vous feriez quoi.

Posez ces questions à un modèle et vous obtenez quelque chose de réellement utile, un panorama de l'espace des options avec chaque compromis étalé. Insistez et il finira même par en choisir un, je ne vais donc pas prétendre que la machine refuse de trancher. Ce qu'elle ne peut pas faire, c'est pondérer les compromis comme les pondère la conséquence vécue, et je crois que la raison est concrète plutôt que mystique. Les écrits sur lesquels la machine a appris sont biaisés. Les échecs spectaculaires ont droit à des postmortems ; les échecs lents, non. Personne ne rédige de rapport d'incident intitulé « cette bibliothèque n'était pas tout à fait la bonne pour notre équipe et nous a coûté trois heures par semaine pendant deux ans ». La personne qui a maintenu la chose qu'elle avait un jour recommandée porte exactement cette donnée manquante : lesquels des compromis du panorama ont vraiment mordu, à quel point, et combien de temps le bleu a mis à partir. Quand elle réduit l'espace des options à une décision pour votre situation, c'est cette donnée manquante qui fait la réduction.

Il existe une lecture moins flatteuse de tout cela, et j'en concède une partie. Certains de ceux qui demandent « vous feriez quoi » cherchent une couverture plus qu'un conseil, un nom à désigner si le choix tourne mal. Mais même cela, aucune machine ne peut le fournir, parce qu'on ne désigne pas un modèle du doigt. Et la meilleure version du même réflexe est saine. Ils veulent que la décision vienne de quelqu'un qui paie un prix quand il se trompe, en réputation à défaut d'autre chose, parce qu'une recommandation qui ne coûte rien à son auteur se donne trop facilement à la légère.

L'inversion

La machine a donc pris le milieu. Toute l'archive de la mécanique résolue sort désormais d'un prompt en un instant, et de là où je me tiens, le trafic de ces questions entre les gens s'est réduit à presque rien. Ce qui circule encore penche nettement vers la dernière sorte, les demandes de goût, de recommandation et de jugement.

C'est un renversement qui mérite qu'on s'y attarde, parce que notre culture a entraîné les développeurs à considérer précisément ces questions comme mineures. Demandez ce que quelqu'un choisirait, et le réflexe était de balayer cela comme une simple opinion, pas une vraie question, puisqu'elle n'avait pas de réponse vérifiable. Le réflexe avait sa logique. Nous réservions les arbitrages subjectifs aux personnes payées pour les rendre, les tech leads et les architectes, et entre pairs nous valorisions les questions que les preuves pouvaient trancher.

Les questions que les preuves peuvent trancher, une machine les tranche désormais avant même qu'elles n'atteignent une personne. Ce qui reste, c'est la sorte sans réponse vérifiable, celle qu'on balayait autrefois. Elle est passée du bruit dans le canal à l'essentiel de ce que le canal transporte. Et les gens qui la posent encore ne se trompent pas sur le fonctionnement de tout cela. Ils ont correctement identifié la chose qu'un prompt ne peut pas leur donner, et ils la demandent au seul endroit où elle existe.

Devenez quelqu'un digne d'être consulté

Je dois dire d'où je parle. Je construis une partie de la machinerie du côté bon marché de cet échange, des outils qui génèrent du code et des réponses à longueur de journée, et chacun d'eux se termine sur un humain qui doit prendre une décision que l'outil ne peut pas prendre à sa place. Quand je dis que la valeur s'est déplacée vers la personne prête à trancher, je décris le point exact où mes propres outils s'arrêtent.

Pour un développeur, la question pratique en découle directement. Êtes-vous quelqu'un digne d'être consulté ? Existe-t-il un coin de ce domaine où vous avez vécu avec vos propres choix assez longtemps pour que votre avis y pèse quelque chose ?

Et quand la question arrive, répondez avec le raisonnement, pas seulement le verdict. Un verdict se périme à la release suivante, et c'est la seule partie de votre réponse que celui qui demande aurait pu obtenir d'un prompt. Ce qu'il ne peut pas obtenir d'un prompt, c'est la pondération : comment vous avez comparé les options, ce que cela vous a coûté quand vous avez mal choisi, ce que vous surveilleriez aujourd'hui. Transmettre cela, c'est ce qui rend meilleur celui qui demande, et ce qui le rend un jour digne d'être consulté à son tour.

Je ne prétendrai pas que cette fenêtre tiendra pour toujours. Toutes les autres fenêtres de cette histoire ont bougé, et celle-ci peut bouger aussi. Mais aujourd'hui, quand quelqu'un vous apporte son projet et vous demande ce que vous feriez, remarquez ce qui vient de se passer. Cette personne avait une machine qui répond à tout, et c'est à vous qu'elle a apporté la question. Prenez-la au sérieux, et répondez en montrant vos raisons.