Du 996 au travail efficace : Le parcours de transformation d'un programmeur
En octobre dernier, j'ai failli être licencié.
Ce n'était pas à cause de mes compétences techniques — j'ai 8 ans d'expérience en développement Java, et la conception d'architecture ne pose pas de problème. Le problème, c'est que je ne pouvais jamais terminer mes tâches à temps. Même en arrivant au bureau à 9h du matin et en partant à 23h, mon temps de travail réellement efficace était probablement inférieur à 3 heures.
Le jour où mon patron m'a convoqué, je m'en souviens clairement : "Tu es très travailleur, mais ton efficacité est trop faible."
Ce soir-là, dans le métro, je suis tombé sur un article sur l'effet Stroop. L'auteur disait que l'attention est comme un muscle, elle peut être entraînée. À ce moment-là, je me suis dit, tentons le tout pour le tout.
Où était mon problème ?
C'est plus tard que j'ai compris que je n'étais pas paresseux, mon attention était hors de contrôle.
Une journée type ressemblait à ça : j'ouvre mon IDE pour coder, je vois un message sur DingTalk, je clique pour répondre. Après avoir répondu, je me souviens du bug d'hier que je n'ai pas encore regardé, j'ouvre JIRA. En pleine lecture, le chef de produit vient poser des questions sur les besoins. Après la discussion, il est déjà 11h, je n'ai pas écrit une seule ligne de code.
Ça vous semble familier ?
J'ai fait une expérience en utilisant la technique Pomodoro pour enregistrer combien de fois je suis interrompu dans une journée. Le résultat m'a choqué : en moyenne toutes les 8 minutes. Les recherches montrent qu'après une interruption, un programmeur a besoin d'environ 23 minutes pour retrouver son état de concentration.
Pas étonnant que je ne finisse jamais rien — je n'ai jamais vraiment "commencé".
Une découverte inattendue
Pour essayer, j'ai commencé à faire le test de Stroop pendant 10 minutes chaque matin.
Au premier test, mon temps de réaction était de 1,8 seconde, taux d'erreur de 22%. Le site affichait que c'était un niveau "d'attention gravement dispersée". Honnêtement, c'était un coup dur.
Mais après une semaine de persévérance, quelque chose de magique s'est produit.
Ce vendredi-là, je devais corriger un bug de concurrence complexe. Avant, ce genre de problème me prenait au moins deux jours, et je cassais souvent quelque chose ailleurs en le corrigeant. Mais ce jour-là, j'ai codé pendant 3 heures d'affilée sans regarder mon téléphone une seule fois. À 16h, le bug était corrigé, tous les tests passaient.
Mon collègue Xiao Zhang a dit : "Qiang, tu es en forme aujourd'hui."
Je n'arrivais pas à y croire moi-même.
Plan de transformation sur trois mois
Encouragé par ce succès, j'ai établi un plan d'entraînement systématique. Pas du genre "21 jours pour changer votre vie" façon développement personnel, mais une méthode basée sur les sciences cognitives.
Premier mois : Établir les bases
Chaque matin à 8h30, je faisais 5 minutes de test de Stroop à mon bureau. Au début, mes collègues pensaient que j'étais fou, à dire "rouge, bleu, vert" face à l'écran.
Mais l'effet était évident. La première semaine, mon temps de réaction moyen est passé de 1,8 à 1,5 seconde. Plus important encore, j'ai découvert qu'après le test, les 1-2 heures suivantes étaient mon moment de concentration maximale de la journée.
J'ai donc ajusté mon organisation de travail pour placer les tâches les plus difficiles entre 9h et 11h. Pendant ce créneau, je coupe toutes les notifications, mon téléphone en mode avion.
Une fois, le chef de produit est venu me voir à 10h, m'a vu avec mon casque antibruit en train de coder et est parti silencieusement. Plus tard, elle m'a dit : "Tu étais tellement concentré, je n'ai pas osé te déranger."
Deuxième mois : Améliorer l'entraînement
Le test de Stroop seul ne suffisait pas. J'ai commencé à essayer "l'entraînement à la charge cognitive".
Qu'est-ce que ça veut dire ? C'est travailler délibérément dans un environnement distrayant. Par exemple, je codais dans des cafés ou faisais des revues de code avec de la musique. C'était difficile au début, mais petit à petit, j'ai découvert que ma capacité à résister aux distractions s'était renforcée.
Un mercredi après-midi, l'équipe d'à côté discutait intensément d'une solution technique, c'était très bruyant. Avant, je n'aurais jamais pu coder, mais ce jour-là, j'ai terminé tout le module de paiement et refactorisé le code horrible d'avant.
J'ai aussi découvert une astuce : utiliser différents langages de programmation pour différents types de tâches. Java pour la logique métier, Python pour le traitement de données, Go pour la concurrence. Ce changement en lui-même est un entraînement cognitif qui garde le cerveau flexible.
Troisième mois : Former un système
À ce moment-là, mes résultats au test de Stroop étaient stables autour de 0,9 seconde, taux d'erreur sous 5%. Mais le plus grand gain a été de trouver mon propre rythme de travail.
J'ai divisé ma journée en quatre blocs de temps :
Matin 9h-11h : Travail en profondeur, écrire le code central Matin 11h-12h : Traiter les emails et messages Après-midi 14h-16h : Revue de code et pair programming Après-midi 16h-18h : Apprendre de nouvelles technologies ou écrire de la documentation
Entre chaque bloc, je fais 2 minutes de "réinitialisation cognitive" — peut-être quelques exercices Stroop ou une méditation simple.
Le plus magique, c'est que je n'ai plus besoin de faire d'heures sup. Les fonctionnalités qui me demandaient de travailler tard sont maintenant terminées l'après-midi.
Quelques astuces pratiques
Pendant ces trois mois, j'ai résumé quelques techniques d'attention spécifiques aux programmeurs :
Méthode du double écran : Écran principal pour le code, écran secondaire uniquement pour la documentation. Ne jamais ouvrir de logiciel de chat sur l'écran secondaire. Ça réduit au moins 50% de distractions.
Entraînement pendant la compilation : Quand le code compile, ne pas regarder le téléphone, faire 10 exercices de test Stroop. Pas de temps perdu, et ça maintient l'état de concentration.
Méthode de concentration pour le debugging : Avant de débugger, respirer profondément 30 secondes, puis écrire d'un coup la description du problème. Ça aide à clarifier ses pensées et évite de modifier au hasard.
Réinitialisation entre les revues : La revue de code consomme beaucoup d'attention. Après chaque PR, se lever et marcher 2 minutes ou regarder par la fenêtre. Le cerveau a besoin de ces courts moments de déconnexion.
Bénéfices inattendus
L'amélioration de la concentration n'a pas seulement amélioré mon efficacité au travail.
J'ai maintenant le temps de faire du sport. Chaque jour à 18h, je vais à la salle de sport au rez-de-chaussée de l'entreprise pour courir. J'ai perdu 4 kg en trois mois, mon état mental est bien meilleur qu'avant.
J'ai recommencé à écrire un blog technique. Avant, je disais toujours que je n'avais pas le temps, maintenant j'écris 1-2 articles par semaine. Mon article sur la concurrence en Golang du mois dernier a même été en tendance sur Juejin.
Le plus important, c'est que j'ai retrouvé le plaisir de coder. Quand tu peux te concentrer pour résoudre des problèmes, cette sensation de flow devient vraiment addictive.
Vendredi dernier, j'ai refactorisé tout le module d'authentification d'un coup, réduisant le code de 40% et améliorant les performances de 3 fois. Le CTO a dit lors de la revue de code : "C'est l'implémentation la plus élégante que j'aie jamais vue."
Mes conseils
Si vous avez des problèmes similaires, mes conseils sont :
- Testez d'abord votre niveau de base. Peu importe à quel point c'est mauvais, c'est juste un point de départ.
- Commencez par 5 minutes par jour. N'en faites pas trop, la clé est la persévérance.
- Trouvez votre heure dorée. Je suis du matin, vous êtes peut-être oiseau de nuit.
- Créez un rituel. Avant de commencer un travail en profondeur, je me fais un café, c'est un signal pour mon cerveau.
- Enregistrez vos progrès. J'utilise Excel pour enregistrer mes résultats de tests quotidiens et ma productivité, voir la courbe de progression donne un sentiment d'accomplissement.
Bilan après trois mois
Hier, ça faisait exactement trois mois que j'ai commencé l'entraînement. J'ai comparé les données :
Octobre (avant l'entraînement) :
- Temps de travail efficace quotidien moyen : 2,8 heures
- Story points complétés : 13
- Taux de bugs : 8,2%
- Jours d'heures sup : 22
Janvier (après l'entraînement) :
- Temps de travail efficace quotidien moyen : 5,5 heures
- Story points complétés : 31
- Taux de bugs : 2,1%
- Jours d'heures sup : 2
À l'évaluation de fin d'année, je suis passé de C à A. Non seulement mon bonus de fin d'année a doublé, mais j'ai aussi eu une opportunité de promotion.
Mais pour moi, le plus important est l'amélioration de ma qualité de vie. J'ai le temps d'aller au cinéma avec ma petite amie, de faire de la randonnée le week-end, de dormir paisiblement le soir au lieu d'angoisser sur les deadlines du lendemain.
Il s'avère que le secret d'un travail efficace n'est pas de travailler plus dur, mais d'être plus concentré.
Pour conclure
Le mois dernier, le patron qui disait que j'étais inefficace m'a de nouveau convoqué. Cette fois, il m'a dit : "Peux-tu partager ta méthode avec l'équipe ?"
J'ai souri. La personne qui allait presque être licenciée il y a trois mois est maintenant un modèle d'efficacité.
Le changement n'est vraiment pas si difficile. Ce dont vous avez besoin n'est pas une méthode magique, mais un entraînement scientifique plus un peu de persévérance.
Si vous voulez aussi essayer, vous pouvez commencer par ce test de Stroop. Rappelez-vous, peu importe votre niveau actuel, ce qui compte c'est votre niveau dans trois mois.
Comme le code a besoin d'être refactorisé en permanence, notre cerveau a aussi besoin d'être optimisé continuellement. La seule différence, c'est de savoir si vous êtes prêt à commencer.
Ah oui, aujourd'hui c'est vendredi, je vais à la salle de sport à 18h. Et vous ? Vous faites encore des heures sup ?