Rester bloqué, c'est le but

J'ai appris à coder à l'époque où être bloqué était la seule option. Un build qui refusait de compiler et un message d'erreur qui ne pointait vers rien d'utile. Un concept qui refusait de faire tilt, peu importe le nombre de fois où je relisais la même page. Non que j'aie été livré à moi-même pour autant. Il existait toute une échelle pour se débloquer : relire la documentation, plus lentement. Sortir le livre usé de l'étagère. Fouiller un projet plus ancien qui avait résolu quelque chose de voisin. Demander au collègue du bureau d'à côté, et si le mur survivait à tout cela, rédiger le problème avec soin, le poster sur un forum, puis attendre, parfois des jours, qu'un inconnu qui en portait les cicatrices réponde.

Aujourd'hui, j'écris du code tous les jours avec deux modèles à portée de main, et toute l'échelle s'est effondrée en un seul barreau. Je colle l'erreur et la réponse revient avant même que j'aie fini de formuler ma propre hypothèse. C'est une vraie accélération, et je prends ce marché sans hésiter. Mais j'ai passé plus de dix ans à gravir l'ancienne échelle à la main, et je sens avec une certaine précision ce qui cesse de se produire à cet instant-là. Quelque chose tournait dans ma tête entre les barreaux, et ce quelque chose n'a plus l'occasion de démarrer. J'ai pointé ce quelque chose dans des billets précédents, toujours en passant. Il mérite qu'on le regarde en face.

Ce que faisaient les heures de blocage

Être bloqué n'a jamais été du temps mort. C'était l'état dans lequel ma représentation de la machine se corrigeait le plus vite.

Voici ce qui se passe à l'intérieur d'un bug qui n'a aucun sens. Vous avez en tête une représentation du fonctionnement du système, et le système vient de faire quelque chose que cette représentation déclare impossible. Alors vous expérimentez. Vous formulez une hypothèse, vous la testez, vous la regardez échouer, vous la révisez. Chaque supposition ratée élimine une façon de plus dont la machine pourrait fonctionner. Quand vous trouvez enfin le correctif, le correctif est presque accessoire. Ce que vous avez vraiment fait, c'est trouver l'endroit exact où votre représentation était fausse, et la redessiner.

Même au cœur du meilleur des bugs, une bonne partie du temps part en agitation stérile, en ressaisies, en revérifications de l'évident. L'apprentissage vit dans les moments où une hypothèse rencontre la machine et meurt. Mais ces moments n'arrivent pas si vous n'êtes pas resté dans la pièce pour tout le reste.

C'est pour cela que je me souviens encore, des années plus tard, du bug qui a dévoré une semaine, et que je suis incapable de citer une seule fonctionnalité livrée sans accroc. La fonctionnalité sans accroc n'a jamais touché ma représentation du système. Le bug l'a redessinée.

Les concepts qui refusent de faire tilt fonctionnent de la même façon. Vous tournez autour, vous essayez un angle, vous le regardez s'effondrer, vous en essayez un autre. Quand l'idée finit par se poser, elle se pose dans une structure que vos tentatives ratées ont bâtie, et c'est pour cela qu'elle reste. La lecture, la documentation et la relecture corrigent aussi une représentation, et je m'appuie sur les trois. Mais une correction ne tient que là où une tentative lui a fait une place. L'explication reçue avant d'avoir lutté glisse sans accrocher. La même explication après vingt minutes d'hypothèses ratées se pose, et reste.

L'ancienne échelle était lente, et cette lenteur n'était pas que du gaspillage. Pour interroger le collègue ou le forum, il fallait d'abord condenser le problème en une question à laquelle quelqu'un d'autre pouvait répondre, et ce travail de condensation, à lui seul, en résolvait la moitié. Quiconque a un jour achevé un exposé soigné du problème et l'a supprimé sans le poster, la réponse soudain en main, connaît l'effet. Le livre non plus ne vous tendait jamais une réponse nue ; il vous obligeait à lire le chapitre autour, et c'est dans le chapitre que les trois bugs suivants étaient évités. Et pendant que vous attendiez une réponse, vos propres expériences continuaient de tourner, parce qu'attendre les mains vides était insupportable. L'aide existait à chaque barreau. Elle arrivait simplement assez lentement pour que vous continuiez à réfléchir entre-temps.

Le retrait est silencieux

Mettez maintenant un modèle dans la boucle. Le build casse, vous collez l'erreur, le correctif arrive, vous passez à la suite. Mesuré en volume produit, c'est strictement mieux, et je ne vais pas prétendre le contraire. Le problème, c'est l'allure que prend ce marché vu de l'intérieur. Rien dans le moment ne le signale. Le diff est identique à celui que vous auriez écrit après trois heures de lutte. L'historique de commits de quelqu'un qui comprend le système et celui de quelqu'un qui a externalisé chaque mur sont exactement les mêmes, jusqu'au jour où ils ne le sont plus.

Parce que le code n'a jamais été le produit de ces trois heures. Le produit, c'était la représentation corrigée, et le code en était le reçu. Prenez le raccourci et vous obtenez quand même le reçu, pendant que la représentation reste fausse d'une façon qu'aucune suite de tests ne fera remonter. Un apprenant qui n'est jamais bloqué n'est pas sur une route plus rapide vers la même destination. Il est sur une route rapide vers une autre, très à l'aise pour produire des logiciels dont il ne tient qu'une représentation mince, et cette minceur ne se voit que le jour où l'IA à ses côtés se trompe et où rien en lui ne le sait.

La version nostalgique se trompe

Une bonne partie de ce sur quoi j'étais bloqué ne m'a rien appris qui vaille ces heures. La chasse au point-virgule manquant. Le build qui cassait à cause d'un accident d'environnement que personne n'aurait pu prévoir. Le flag non documenté, le conflit de versions, l'après-midi perdu sur un outil qui était simplement mauvais. Ces murs m'ont appris un peu du folklore de l'outillage, et le folklore de l'outillage est précisément la cargaison que les machines transportent aujourd'hui mieux que je ne l'ai jamais fait. Dissoudre instantanément ce genre de mur, c'est exactement à cela que servent les outils.

Les heures de blocage qui m'ont construit étaient d'une autre sorte, et distinguer les deux sortes est tout le propos de ce billet. C'étaient les heures où l'obstacle était ma propre représentation fausse. Le système suivait ses règles, mon idée de ces règles ne les suivait pas, et la lutte était le processus qui me le faisait découvrir. L'une des deux était une taxe. L'autre, le prix de la formation.

On peut les distinguer avant que la réponse n'arrive, pas seulement après. Demandez-vous si le mur est à l'intérieur du problème ou à côté. Un conflit de versions est à côté du problème : le résoudre ne change rien à la façon dont vous écrirez le prochain programme. Une fonction qui renvoie une valeur que votre représentation déclare impossible est à l'intérieur : résoudre ce mur-là change ce que vous savez. Dans le doute, traitez le mur comme s'il était à l'intérieur pendant vingt minutes et regardez si votre compréhension bouge.

Choisir où être bloqué

La compétence a donc changé de forme. C'était de l'endurance, parce qu'être bloqué était obligatoire partout. C'est désormais optionnel partout, ce qui en fait un budget, et la compétence est devenue une affaire d'allocation.

Je dépense le mien délibérément. Quand le travail de retrieval que je mène pour le droit et la santé se comporte mal d'une façon qui me surprend, j'y vais à la main, parce que la surprise veut dire que ma représentation du système est fausse, et c'est le genre de blocage qui rapporte. La surprise est cependant un signal qui se mérite. Elle ne se déclenche que là où une représentation détaillée existe pour que la réalité la contredise, et c'est pourquoi le test du débutant donné plus haut porte sur le mur, pas sur le ressenti. Quand un agent à qui j'ai délégué trébuche à un endroit que j'aurais pu prédire, je laisse l'outillage l'absorber, parce qu'il ne reste rien que cette friction puisse m'apprendre. Le pipeline de délégation que j'ai construit existe précisément pour que je puisse céder les murs dont j'ai déjà tout appris. Ceux dont je n'ai pas tout appris, je les escalade encore moi-même, exprès, plus lentement que je ne pourrais.

Déléguez sans culpabilité. Le développeur qui ressent une vague honte chaque fois que le modèle le débloque se trompe de cadre, comme si la vertu résidait dans la friction elle-même. Elle n'y a jamais résidé. La friction n'a jamais été que le moyen d'obtenir la représentation. Dépensez-la là où votre représentation est encore mince.

Et cette dépense n'est pas du sentimentalisme, c'est de l'économie. À mesure que générer du code devient bon marché, le travail qui garde son prix consiste à distinguer la sortie juste de la fausse, et ce jugement est fait de représentations corrigées. L'habitude se transfère, en plus. Chaque bug qui force une hypothèse contre un système en marche est une répétition du même geste qui, plus tard, attrape une suggestion fausse dans du code que vous n'avez jamais vu. Une affirmation pleine d'assurance arrive, et quelque chose en vous sait qu'il faut la tester.

Si vous apprenez aujourd'hui

Bloquez-vous exprès, et bloquez-vous petit. Choisissez des problèmes calibrés pour que bloqué veuille dire vingt minutes de vraie réflexion, pas un week-end perdu. Ce que vous voulez, c'est un contact fréquent avec votre propre représentation fausse, en morceaux assez petits pour en venir à bout.

Tentez d'abord, toujours. Écrivez votre version cassée, formulez votre hypothèse sur le bug, puis faites entrer l'IA, et faites-la entrer comme le tuteur qui relit votre tentative, pas comme le chauffeur qui vous fait contourner le problème. Demandez-lui où votre raisonnement a échoué, pas seulement quelle est la réponse. Débattez avec elle. La correction du tuteur se pose précisément parce que votre tentative a bâti la place où elle s'emboîte. Sautez la tentative et les mêmes phrases n'apprennent rien.

Puis testez-vous. Coupez l'IA et reconstruisez la chose, et pendant que vous la reconstruisez, dites pourquoi chaque partie est là, comme si un collègue posait la question à côté de vous. La reconstruction seule peut se simuler de mémoire, à partir de frappes observées. Le pourquoi, non. Si les deux survivent, les heures de blocage ont fait leur travail et la compréhension est à vous. Sinon, vous tenez le reçu d'un apprentissage qui n'a jamais eu lieu, et mieux vaut le découvrir maintenant, sur quelque chose de petit, qu'à l'intérieur d'un système qui porte votre nom.

Les machines vous offriront une sortie devant chaque mur pour le reste de votre carrière, et la plupart du temps vous devriez la prendre. Beaucoup de murs sont du bruit, et dégager le bruit, c'est le rôle des outils. Les bons murs sont ceux où se construit votre représentation de la machine. Apprenez à les reconnaître, refusez la sortie devant ceux-là, et laissez le mur faire son travail. Rester bloqué devant les bons murs, c'est le but.