couple-repo/personnalités/Patterns_Dev_Alexis.md
StillHammer f5aa93bcbd Initial commit: Couple matters documentation + PowerPoint skill
Documentation personnelle complète
- CLAUDE.md : Instructions compactes et enrichies
- personnalités/ : Profils Alexis, Tingting, Ben, Xiaoxiao + TingtingWork.md
- couple_backlog/ : Historique conflits (16-22 octobre 2025)
- conversation_topics/ : Système suivi sujets actifs
- Projects/ : Analyses techniques et projets
- ToRemember/ : Leadership socratique, suivi conversations
- Promesses_à_tenir.md, observations_patterns.md

PowerPoint skill
- .claude/skills/pptx/ : Skill officiel Anthropic (html2pptx)
- Identité visuelle Tingting : Bordeaux + Or antique + Crème
- Exemple : personnalités/Tingting_Class73_Elegant.pptx

Organisation
- planning/, stratégie/, topics/, plan_discussion/
- .gitignore : node_modules, *.pptx (sauf personnalités/), HTML/JS temp

🎯 Repo propre : 129 fichiers essentiels, 0 dependencies
2025-10-24 14:54:57 +08:00

8.2 KiB

Patterns de Développement d'Alexis

Problème Central Identifié

"Je suis jamais satisfait. Je passe mon temps à améliorer des trucs qui sont déjà good enough. J'ai peur de faire parce que je veux que ce soit si bien que ça me décourage avant de me lancer."

Nuance Importante

Ce n'est PAS juste du perfectionnisme. C'est contextuel selon la stack technique et le type de projet.

Patterns selon le Contexte

Zone de Confort (C++, Architecture Système)

Comportement :

  • Design efficace et rapide (2-3 jours)
  • Confiant dans ses choix
  • Accepte "assez bien"
  • Avance sans blocage
  • Pas de perfectionnisme paralysant

Exemple : Warfactory

  • Designé en 2-3 jours
  • Architecture pensée pour son workflow + Claude Code
  • En pause pour raisons légitimes (énergie mentale, timing)
  • Pas de doute, juste attente du bon moment

Hors Zone de Confort (Node.js, JavaScript)

Comportement :

  • Syndrome de l'imposteur ("je suis pas dev Node.js")
  • Over-engineering pour compenser
  • Refactor en boucle
  • "C'est pas assez bien" même si fonctionnel
  • Spec creep (ajouter features non demandées)
  • N'accepte jamais "assez bien"
  • Procrastination via amélioration

Exemples : Projet SEO, ClassGen

  • Fonctionnels mais jamais livrés
  • Revamps multiples
  • Envie de tout refaire en C++ (fuite vers zone de confort)

RÉVÉLATION CRUCIALE : Compétence Manquante Cachée

  • Procrastination ≠ Juste perfectionnisme
  • Procrastination = Évitement de ce qu'il ne sait pas faire
  • Exemple SEO :
    • Sait faire : Monitoring LLM, architecture complexe → Fait en 1h
    • Sait PAS faire : Endpoints REST basiques → Évite, procrastine
    • Compensation : Ajoute features complexes au lieu d'apprendre les bases
  • Pattern : Fait des trucs avancés pour éviter d'avouer qu'il manque de compétences basiques

Le Vrai Problème Sous-Jacent

Origine Psychologique

Construction identitaire basée sur l'intelligence :

  • Enfance sans validation externe
  • Identité construite sur "je suis smart"
  • Protection de cette identité à l'âge adulte

Conséquence :

  • En C++ : Se sent légitime → Pas de menace → Avance
  • En Node.js : Se sent imposteur → Menace identitaire → Sur-compensation

Pattern Conception vs Exécution

Conception :

  • Dopamine maximale
  • Rapide et efficace
  • Ce qu'il fait de mieux
  • "Addiction" - "j'aime trop planifier"

Exécution :

  • Pas de dopamine
  • Procrastination
  • "L'exec c'est relou"
  • Une fois intellectuellement résolu → Cerveau considère que c'est fini

Citation clé : "Design sur mobile, exec sur ordi - mais je peux pas paralléliser pour l'instant"

Profil 2E (Twice Exceptional)

Caractéristiques observées :

  • Smart concepteur : Rapide, bonne capacité d'abstraction, conception quali
  • Excellent pour les trucs complexes/conceptuels
  • Difficulté d'exécution
  • Gap entre ce qu'il conçoit et ce qu'il exécute
  • Tâches répétitives = difficiles
  • Finir ce qui est "intellectuellement résolu" = chiant
  • Exécution administrative/mécanique = galère

Auto-évaluation : "Je pense vraiment que je suis smart mais l'exec c'est relou"

Solutions Identifiées

Ce Qui Marche

1. Design adapté aux contraintes (Warfactory)

  • Modules 200-300 lignes (taille parfaite pour Claude Code ET son cerveau)
  • Hot-reload 0.4ms (feedback immédiat = dopamine)
  • Interfaces immutables (impossible de refactor à l'infini)
  • Architecture pensée POUR résoudre ses problèmes

2. Stratégie Mobile/Ordi

  • Design sur mobile (moments low-energy, dopamine)
  • Exécution sur ordi (moments high-energy, setup complet)
  • Respecte ses ressources mentales

3. Claude Code comme Multiplicateur

  • Claude fait l'exécution (partie chiante)
  • Alexis garde conception/direction (partie fun)
  • "Depuis que Claude Code existe je vis une bien meilleure vie"

4. Plan Juste-à-Temps (Option 3)

  • Concevoir 1 module
  • Implémenter immédiatement
  • Pas le droit de concevoir la suite tant que pas livré
  • Gamification de la dopamine de conception

Ce Qui Ne Marche Pas

1. Refactor/Revamp Infinis

  • ClassGen : Revamp #1, #2, bientôt #3
  • Jamais satisfait car problème pas technique mais psychologique
  • Fuite vers C++ = Fuite vers zone de confort

2. Over-Engineering pour Compenser

  • Ajouter features non demandées
  • Systèmes complexes pour prouver compétence
  • Résultat : Fonctionne mais trop complexe à maintenir

Règles de Décision

Différencier Perfectionnisme vs Dette Technique

Dette Technique Réelle :

  • Ça bloque concrètement pour ajouter features
  • Temps d'ajout feature = 10x ce que ça devrait être
  • Architecture empêche l'évolution → Refactor justifié

Perfectionnisme :

  • Ça marche mais "c'est pas élégant"
  • "Je suis pas sûr du code"
  • "C'est pas assez bien" (subjectif)
  • Aucun utilisateur pour valider → Livrer d'abord, améliorer après feedback

Question à se Poser

Avant d'améliorer/refactorer : "Est-ce que je fais ça parce que :

  • A) Ça me bloque concrètement pour avancer ?
  • B) Ça ne me semble pas 'assez bien' même si ça marche ?"

Si A → Go, c'est légitime Si B → Noter dans idees-ameliorations.md et continuer

Stratégies Pratiques

1. Time-Boxing

  • 4h max par session de dev
  • Protège contre sessions infinies d'amélioration
  • Évite "commencer à 10h, finir à 23h à améliorer un truc"

2. Liste d'Améliorations Différées

  • Créer idees-ameliorations.md
  • Noter toutes les envies d'amélioration
  • NE PAS les faire immédiatement
  • Relire après 1 mois de stabilité
  • Décider ce qui est vraiment important

3. Freeze Après Livraison

  • Une fois livré → STOP
  • Pas de "juste améliorer un petit truc"
  • Seulement fixes de bugs rapportés par utilisateurs
  • Nouvelles features seulement après validation usage

4. Gamification de la Conception

  • Autoriser design sur mobile (dopamine)
  • MAIS obligation d'implémenter avant de designer la suite
  • "Je livre pour avoir le droit de concevoir le module suivant"

Cas Spécifiques Documentés

Projet SEO (Node.js)

Statut : Fonctionnel depuis 2 semaines, pas livré Problème :

  • Fonctionnel selon specs initiales
  • Over-spec avec modulation de ton + config avancée (non demandé)
  • "C'est pas assez bien" + "Je trust pas le système"
  • Refactor en boucle Diagnostic : Syndrome de l'imposteur (Node.js) → Perfectionnisme paralysant Solution : Finir endpoints, livrer, STOP

ClassGen (Node.js)

Statut : En prod, utilisé par élèves, livraison toutes les 1-2 semaines Problème :

  • Architecture devenue difficile à maintenir (2 systèmes parallèles)
  • Envie de tout refaire en C++
  • Mais contraintes business : Vente potentielle, WeChat mini app, déploiement facile Diagnostic : Dette technique réelle + Envie de fuir Node.js Solution : Migration TypeScript (si business confirmé), pas réécriture C++

Warfactory (C++)

Statut : Designé (2-3 jours), pas encore implémenté Problème : Aucun - juste en pause Forces :

  • Architecture excellente
  • Pensée pour son workflow
  • Confiance totale Action : Implémenter quand énergie mentale disponible

Plan d'Action Général

Court Terme

  1. Stabiliser projets existants (SEO, ClassGen)
  2. Livrer sans améliorer
  3. Pas de nouveaux projets
  4. Pas de refactors "pour améliorer"

Moyen Terme

  1. Obtenir feedback réel utilisateurs
  2. Décider : ClassGen = Hobby ou Business ?
  3. Si Business → Migration TypeScript justifiée
  4. Si Hobby → Garder JS, pas de migration

Long Terme

  1. Warfactory quand énergie disponible
  2. Améliorer projets selon feedback réel
  3. Pas selon hypothèses internes

Diagnostic Non Médical

Suspicion 2E / TDAH (non diagnostiqué, auto-évaluation) :

  • Conception brillante, exécution difficile
  • Pas de dopamine pour tâches répétitives
  • Hyperfocus sur conception, procrastination sur exécution
  • Claude Code compense parfaitement ce pattern

Recommandation : Envisager diagnostic professionnel

  • Si TDAH/2E confirmé → Outils adaptés possibles
  • "Courir un marathon avec cheville foulée en se disant faut juste être plus motivé"