Skills

Construisez un seul chemin étroit qui traverse toutes les couches et qui s'exécute, avant de construire une seule couche en entier — une intégration qui ne s'est jamais exécutée est une supposition.

Un critère écrit après l'implémentation décrit l'implémentation. Écrivez d'abord la vérification qui échoue, observez son échec, puis construisez.

Un réglage qui s'enregistre correctement et ne change rien jusqu'au redémarrage est pire qu'un réglage qui échoue. Dites quand il s'applique, et déduisez-le de l'endroit où il est lu.

Dépensez sur un budget inférieur à la fenêtre réelle, et comptez les schémas d'outils que vous renvoyez à chaque étape — ils sont le plancher que la compaction ne peut pas atteindre.

Une boucle de réessai qui écrase sa variable de feedback ne montre à la tentative 3 que l'échec de la tentative 2 — elle redérive donc le patch que la tentative 1 avait déjà essayé.

Prenez la signature depuis la version installée, pas depuis votre mémoire — une API plausible est indiscernable d'une vraie tant qu'elle n'a pas été exécutée.

Tout ce qui est recopié à la main depuis un autre fichier est correct exactement une fois. Si cela peut être généré, générez-le, et faites échouer le build quand la copie a vieilli.

Un générateur qui plante vous dit qu'il a échoué ; un qui produit une sortie plausible ne vous dit rien. Testez ce qu'il a trouvé, jamais qu'il s'est exécuté.

Un test de régression que vous n'avez jamais vu échouer est une supposition. Recassez le code et regardez-le passer au rouge avant de le committer.

Un diagnostic est une affirmation sur une machine que vous n'avez pas exécutée. Reproduisez d'abord l'échec en une commande courte — surtout quand le diagnostic vient de quelqu'un d'autre.

Lancez la commande de vérification du projet à la lettre — même périmètre, mêmes flags. La variante presque identique que vous improvisez ment dans les deux sens.

Une classe assemblée à la main dans un test prouve que la classe fonctionne, pas que quoi que ce soit l'atteint — couvrez le chemin que la production emprunte réellement.

Quand un contrôle se déclenche sur la mauvaise cible, le correctif l'affaiblit. Capturez le faux positif sous forme de test dans le même commit, sinon la règle s'érode en silence.

Avant d'annoncer qu'une tâche est terminée, lancez le contrôle qui échouerait si elle ne l'était pas — une explication n'est pas un correctif.

Un taux sans son dénominateur ni sa composition induit en erreur alors que chaque chiffre reste vrai — donnez n, et dites quelle part du numérateur est du bruit déjà connu.

Un classement construit à partir d'une partie du système se lit comme un classement du système — écrivez le périmètre et les exclusions à côté des conclusions, pas après elles.

Quand deux de vos propres mesures divergent d'une marge qu'aucun mécanisme ne pourrait produire, le défaut est dans l'instrument. Auditez le harness avant de bâtir une théorie dessus.

Un chiffre et sa réserve doivent former un seul artefact. Deux paragraphes s'éloignent l'un de l'autre ; un composant ne le peut pas.

Publiez l'expérience qui a échoué, conservez telle quelle celle qui a été remplacée, et ne relancez jamais pour obtenir la significativité. Le biais est dans la sélection, pas dans le chiffre.

Un contrôle ajouté après ce qu'il protège est un contrôle que quelqu'un désactive pour livrer. Fermez-le pendant qu'il n'y a rien à bloquer.

Une barrière qui énumère ce qu'il faut vérifier échoue en laissant passer — le site que personne n'a pensé à ajouter est celui qui casse. Énumérez plutôt les exemptions, chacune avec une raison écrite, et le défaut devient l'échec.

Un écran, un onglet ou une catégorie vide est une promesse que le produit ne tient pas. Masquez-le jusqu'à ce qu'il ait du contenu, ou ne le construisez pas encore.

Un avertissement placé après l'action qu'il concerne arrive alors que le lecteur a déjà décidé. Mettez-le au-dessus et, quand cela compte, rendez-le impossible à ignorer.