VIEUX SCRIPT DÉTECTÉ

“Chaque bug dans ce système legacy reflète maintenant ma compétence”

Essaie cette réponse :

“Je possède ce que je change ensuite, pas tout ce qui était avant moi.”

Faire l’auto-évaluation de 60 secondes →

VOIR LA PRATIQUE

Crée une réponse à cette pensée et un geste pour la mettre à l’épreuve.

LA PENSÉE

“Chaque bug dans ce système legacy reflète maintenant ma compétence”

TA RÉPONSE ENREGISTRÉE

“Je possède ce que je change ensuite, pas tout ce qui était avant moi.”

UN PAS PRIVÉ

Ouvrez l'historique Git du fichier avec le bug. Notez la date du commit qui a introduit le problème. Si c'était avant votre arrivée, écrivez cette date dans une note privée et lisez ce commit original pour comprendre le contexte d'alors.

Le Défaut qui Était Là Avant Votre Arrivée

Trois Jours Dans le Projet

Vous explorez le codebase pour la première fois, vous scrollez à travers une partie du code d'authentification, et vous trouvez une chaîne de conditions imbriquées mal gérées. Vous notez mentalement : c'est du legacy, c'est comme ça que ça marche. Vous demandez au mentor si c'est une zone à refactoriser et on vous dit « c'est vieux, ça tourne, on n'y a pas touché en six mois ». Vous hochez la tête. Vous ne le touchez pas non plus.

La Semaine Où On Vous Demande Pourquoi

Un bug de sécurité légèrement important surgit exactement dans ce code imbriqué. Pas catastrophique, mais visible. Quelqu'un en reunion dit « comment ça a pu arriver? ». Vous sentez tout le poids s'arrêter sur vous. Une voix intérieure crie : tu aurais dû le repérer le premier jour, tu aurais dû déjà le savoir, tu aurais dû demander plus avant. Soudain chaque défaut préexistant ressemble à une preuve que vous n'aviez rien compris à ce que vous repreniez, et que maintenant tout le monde le sait.

Ouvrir le Diff Original

Vous créez un commit tout seul un matin, vous revenez à la première version du fichier du jour où vous avez commencé. Vous lisez la date du commit original qui a introduit cette condition imbriquée. C'était dix-huit mois avant votre arrivée. Vous écrivez sur un bloc-notes: « Ce code existait avant moi. Je n'ai pas hérité une preuve. J'ai hérité une tâche d'amélioration ». Vous fermez le bloc-notes. Vous continuez à lire le fichier, mais cette fois pour comprendre, pas pour vérifier.

TRACE · 01/04

Comment ce script te dirige

Vous relisez mentalement votre première semaine chaque fois qu'un bug du legacy surgit, certain que vous auriez dû le voir ce jour-là.
Vous défendez le code existant devant les autres parce qu'admettre son état cassé ressemble à admettre que vous l'avez manqué.
Vous vous blâmez pour les problèmes que vous n'avez pas créés, juste parce que vous êtes là maintenant.

SOURCE_LOCATED · 02/04

La règle cachée en dessous

Le Script de l'Héritage Légué

Si j'ai repris ce système et qu'un bug surgit dedans, ça doit signifier que je n'aurais pas dû le reprendre, ou que je ne comprends rien à ce que j'ai repris.

FORGING_REPLACEMENT · 03/04

Lignes de remplacement (à enregistrer)

Je possède ce que je change ensuite, pas tout ce qui était avant moi.
La compréhension du contexte est progressive; les lacunes que je ferme cette semaine ne sont pas des échecs hier.
Je peux améliorer le code ligne par ligne sans d'abord tout maîtriser.

Générées par personne dans l'app — ceci donne le ton, pas ton script. Le tien se construit à partir de tes mots exacts.

INSTALL · 04/04

Le protocole, sur une carte

Quand je pense

“Chaque bug dans ce système legacy reflète maintenant ma compétence”

Je dis

“Je possède ce que je change ensuite, pas tout ce qui était avant moi.”

Puis je fais une chose

STATUS: READY_TO_INSTALL

Effacer cette pensée

4 minutes. Ta voix. Gratuit.

Lancer ce wipe précis dans l'app →

Le protocole de wipe

Écris la pensée exactement comme elle tourne : « Chaque bug dans ce système legacy reflète maintenant ma compétence ». Mot pour mot — le wipe vise la phrase, pas l'ambiance.
Repère la règle et l'action évitée. De quoi cette pensée t'excuse-t-elle si commodément ?
Enregistre les lignes de remplacement ci-dessous avec ta propre voix. Parle pour de vrai — pas d'enregistrement, pas d'installation.
Fais tourner la boucle : écoute matin et soir, note une action-preuve par jour pendant 7 jours.

Réponses directes

Est-ce que c'est de la faiblesse professionnelle de ne pas avoir compris le code legacy le jour où je l'ai repris?

Non. La compréhension d'un système est progressive et prend du temps. Chaque système a un contexte historique que personne ne maîtrise en vingt-quatre heures. Les lacunes que vous identifiez maintenant sont des opportunités d'apprentissage, pas des preuves que vous aviez dû déjà savoir.

Si le bug était préexistant, pourquoi m'en blâme-t-on?

Vous pouvez être blâmé par défaut parce que vous êtes là maintenant, même si vous n'avez pas créé le problème. C'est un biais mnémonique : tout défaut visible semble lié à la personne présente. Votre réponse n'est pas de défendre le code cassé, mais de clarifier ce que vous avez et n'avez pas hérité, puis d'agir.

Devrais-je tout réécrire dès mon arrivée pour éviter ce problème?

Non. Les réécritures complètes prennent des mois, créent de nouveaux risques, et retardent votre compréhension du système. L'amélioration chirurgicale – une partie du code à la fois – vous permet de maîtriser le contexte en agissant.