Support technique
Documentation
Connexion
Nous contacter
Accédez directement au résumé généré par l'IA de cet article de blog 
Une batte et une balle coûtent au total 1,10 $. La batte coûte 1 $ de plus que la balle ! Combien coûte la balle ?
10 cents ? Félicitations, vous venez de tomber dans le piège cognitif que Daniel Kahneman a exploré dans son livre Thinking, Fast and Slow. Avant de poursuivre, sachez que la bonne réponse est 5 cents. Mais, bien sûr, la plupart des gens ne font pas de calculs, ils se fient à leur instinct. Ce n'est rien d'autre qu'un réflexe mental que Kahneman appelle le "système un".
Selon Kahneman, le système 1 est le mode de pensée automatique et intuitif du cerveau qui conduit souvent à des réponses rapides. Ce système de notre cerveau est toujours prêt à réagir et scrute continuellement les modèles qu'il peut résoudre avec peu d'effort. Malheureusement, ce système se trompe souvent.
D'autre part, le deuxième système est un processus plus lent et plus délibéré qui demande des efforts. Il commence à fonctionner lorsque nous nous empêchons de crier "10 cents". Toutefois, ce système consomme de l'énergie, et c'est pourquoi il n'est pas l'option préférée de notre cerveau. Ces deux systèmes n'apparaissent pas seulement dans les puzzles logiques.
Pour les développeurs, ils déterminent comment le code est écrit, comment les problèmes sont débogués, si vous attendez une compilation ou si vous donnez un coup d'œil rapide à Slack, et plus encore. Si ces deux systèmes fonctionnent à chaque fois que vous ouvrez votre IDE, la question est de savoir lequel vous utilisez le plus souvent, et comment vous pouvez utiliser l'un ou l'autre pour améliorer vos pratiques de développement ? Découvrons-le !
Kahneman 101 - Penser vite et lentement
Avant d'aborder la manière dont ces deux systèmes peuvent être utilisés pour renforcer l'efficacité du développement, examinons ce qu'ils sont réellement. Kahneman, un psychologue qui a reçu le prix Nobel d'économie et proposé ces systèmes, n'a pas été récompensé pour ses prévisions financières ou ses prédictions de marché.
En fait, il a été récompensé pour une réalité que les économistes avaient longtemps ignorée. L'homme n'est pas un décideur rationnel. Kahneman a passé 50 ans de sa vie à étudier la manière dont les êtres humains prennent des décisions lorsqu'ils sont confrontés à l'incertitude. Les résultats de ses travaux ont complètement modifié l'hypothèse selon laquelle les êtres humains choisissent sur la base de la logique et de la raison.
Dans son livre Thinking, Fast and Slow, Kahneman a présenté un modèle du cerveau humain, affirmant qu'il est divisé en deux systèmes :
| Caractéristiques | Fonctionnalité | |
| Système 1 | Rapide
Émotionnel Bon marché Intuitive |
Ce système saute aux conclusions en se basant sur des modèles, même lorsque ces modèles sont trompeurs. C'est le système qui crie instinctivement "10 cents" dans l'énigme de la batte et de la balle. Pour les développeurs, c'est ce qui vous fait dire "Ça m'a l'air bien" lorsque vous voyez le code, sans vraiment y réfléchir. |
| Système 2 | Coûteux
Lenteur Logique Contrôlé |
C'est ce système que vous activez lorsque vous vous surprenez à crier la mauvaise réponse, ou lorsque vous réfléchissez à un modèle de conception particulier pour déterminer s'il est adapté à l'architecture de votre projet. Cependant, ce système ne se met en marche que si vous le forcez à le faire. |
Qu'est-ce que cela signifie pour les développeurs ? La réponse est que votre cerveau est constamment en train de choisir entre une solution "rapide" et une solution "erronée". "rapide, mais erronée ou un "lent, mais correct". mais correct". Mais il y a un hic : lorsque vous êtes fatigué et épuisé, votre cerveau se met automatiquement à utiliser le système 1, ce qui peut avoir de graves répercussions sur la qualité de votre code.
Système un vs. Système deux - Qu'est-ce que les développeurs utilisent le plus ?
Si vous demandez à un développeur quel est le système sur lequel il s'appuie le plus, la réponse sera certainement le système deux. Il est lent, logique et nécessite des efforts. Tout cela correspond parfaitement au codage. En fait, lors d'un sondage en direct, près de 90 % des personnes interrogées ont levé la main pour le système deux. Ils n'ont pas tort. Pourquoi ? La plupart des développeurs ont besoin d'une réflexion profonde et ciblée.
Mais voilà le problème. Le système 2 est assez coûteux, car il consomme une ressource cognitive limitée que nous appelons communément "carburant mental". Lorsque ce carburant est épuisé, le cerveau humain passe automatiquement au système 1, et si la tâche exige encore de la précision, c'est bien dommage.
C'est un beau concept, n'est-ce pas ? Et bien, ce n'est pas que de la théorie. Les spécialistes du comportement ont trouvé des preuves réelles et mesurables que notre énergie mentale fonctionne de la même manière qu'une batterie de téléphone. Ainsi, chaque fois que vous écrivez du code, que vous déboguez ou que vous vous empêchez d'être distrait, la batterie se vide. Le Dr Gloria Mark, qui a passé 15 ans à étudier l'attention humaine, affirme que :
- Une personne moyenne consulte son courrier électronique 77 fois par jour.
- Le temps passé à l'écran avant de changer est de seulement 3 minutes et 47 secondes.
- Il faut 25 minutes pour se concentrer pleinement sur la tâche initiale après avoir été distrait.
Ainsi, les trois minutes d'attente sur un bâtiment que vous utilisiez pour consulter votre courrier électronique vous coûtent en réalité 25 minutes. Mais ce n'est pas le pire. Chaque fois que vous changez de contexte, votre cerveau revient automatiquement au système 1, même si vous travailliez dans le système 2. C'est pourquoi des erreurs se produisent, la qualité baisse et vous finissez par écrire "Code correct".
Est Un "bon code" est-il pire qu'un mauvais code ? pire qu'un mauvais code ?
Tous les mauvais codes ne constituent pas une menace réelle. Il y a des moments où "code correct" peut être tout aussi dangereux, voire plus. Quelle en est la raison ? Il se compile, il passe les tests, et il passe souvent inaperçu dans les demandes de modifications.
Ainsi, par essence, le code écrit en mode System One a tendance à être juste assez bon pour passer sous le radar. La cerise sur le gâteau, ce sont les réviseurs de code qui fonctionnent avec un carburant mental épuisé. Ils jettent un coup d'œil à ce code et disent, "Il me semble bien".
Ces pipelines, de par leur conception, fonctionnent comme des modèles du système 1, et le résultat est un code médiocre qui se transforme en un produit médiocre. Kahneman note que la répétition et les boucles de rétroaction peuvent faire passer les compétences du système 2 au système 1. Est-il donc possible de former les développeurs pour qu'ils écrivent instinctivement un meilleur code ?
Techniques de protection du système deux
Lorsqu'il s'agit d'utiliser tout cela pour l'efficacité du développeur, commencez par savoir que System Two est votre outil le plus puissant en tant que développeur, mais c'est aussi le plus fragile. C'est pourquoi il doit être protégé des distractions constantes, et il existe de nombreuses façons de le faire.
La gestion du temps est ici la clé. Il est possible que des systèmes comme la technique Pomodoro, qui consiste à se concentrer pendant 25 minutes avant de faire une pause de 5 minutes, soient efficaces, mais ils peuvent se retourner contre vous si votre session de travail approfondie est interrompue au moment où vous êtes sur le point d'entrer dans le flux. Par conséquent, vous devriez considérer 25 minutes comme un minimum et continuer si vous êtes dans la zone.
En outre, la mise en lots des tâches est également une excellente technique qui peut protéger les mécanismes du système deux, car elle permet d'éviter les changements de contexte. Les développeurs peuvent même utiliser différents outils basés sur l'IA pour ajouter des séances de concentration à leur emploi du temps tout en gardant de la place pour les réunions, ce qui est gagnant-gagnant. Le prochain point sur la liste est la protection du carburant mental.
Pour ce faire, la mise en veille est la seule option de réinitialisation complète. Toutefois, d'autres techniques peuvent s'avérer utiles. Par exemple, boire du café et s'allonger pendant quelques minutes jusqu'à ce que le café fasse effet peut aider. En outre, il existe des techniques telles que la pleine conscience et la méditation. Ces techniques peuvent sembler hippies, mais la science est de leur côté.
Les développeurs devraient faire cela pour améliorer la pratique et l'efficacité
Tout d'abord, le principe sous-jacent à tout cela est que les résultats de qualité proviennent du système deux, c'est-à-dire de l'état dans lequel les développeurs doivent se trouver s'ils veulent obtenir de meilleurs résultats. Dans ce contexte, voici quelques éléments clés à essayer :
- Protéger le système Deux temps en utilisant des outils qui programment des créneaux de concentration profonde et s'ajustent automatiquement en fonction de la disponibilité, ainsi que des méthodes de blocage du temps pour rester dans le flux pendant de plus longues périodes.
- Utiliser l'automatisation et l'IA pour réduire la charge cognitive en attribuant les tâches répétitives aux outils d'automatisation et d'IA, car cela permet de gagner du temps et d'éviter de changer de contexte.
- Le regroupement de tâches similaires permet également d'éviter les changements de contexte, ce qui préserve l'énergie mentale et aide à rester concentré.
- Rechargez-vous en utilisant des techniques de sommeil et de pleine conscience, car elles peuvent contribuer à protéger vos ressources cognitives et vous permettre de rester plus longtemps dans le système deux.
- Si quelque chose n'est pas de votre ressort et prend trop de temps, déléguez-le afin que des experts puissent créer des solutions meilleures et plus sûres. solutions plus sûres pendant que vous vous concentrez sur les activités principales qui stimulent la croissance de l'entreprise.
Réflexions finales
Daniel Kahneman n'a peut-être pas écrit Thinking, Fast and Slow pour les développeurs, mais les idées contenues dans ce livre sont exactement ce dont les équipes logicielles ont le plus besoin. La dure réalité est que lorsque vous codez en pilote automatique, vous obtenez des résultats fonctionnels. Mais on finit par passer à côté de solutions plus propres et évolutives qui se cachent sous la surface.
En fin de compte, écrire du bon code n'a pas grand-chose à voir avec le talent ou la compétence. Il s'agit d'être dans le bon état d'esprit, l'état d'esprit du système deux. Aujourd'hui, l'avantage concurrentiel consiste à identifier le moment où l'on glisse vers le système 1 et à concevoir son flux de travail de manière à rester plus longtemps dans le système 2.
Alors, la prochaine fois que vous coderez, faites une pause et demandez-vous si vous codez vite ou si vous codez intelligemment !
