Codant au moins huit heures par jour, les programmeurs doivent en permanence prendre des décisions. Cela peut devenir épuisant. Aujourd’hui, un ingénieur full-stack peut avoir à gérer différents aspects d’une technologie en même temps. Cela peut signifier utiliser des talents DevOps pour assurer en même temps une intégration en continu (CI) et une livraison en continu (CD), ou programmer dans différents langages en fonction des technologies client-serveur utilisées. Certains peuvent également travailler dans des langages de programmation, orientés objet ou fonctionnels, qui utilisent des paradigmes variables.

À chacune de ces tâches, se rattache un nouveau lot de questions. Devons-nous concevoir cette fonction de l’extérieur (l’interface utilisateur) et travailler vers l’intérieur (vers le backend), ou devons-nous le faire dans l’autre sens ? Pouvons-nous utiliser une librairie tierce pour l’implanter ou devons-nous plutôt la coder nous-mêmes ? Comment s’y prendre ? Comment automatiser le processus ? La liste des questions est sans fin.

Avec ce besoin incessant de prendre des décisions, et des heures passées à coder, les développeurs peuvent être amenés à choisir les options les moins pénibles à mettre en place. Ils peuvent également avoir une vue limitée de certains éléments à prendre en compte, ou encore éviter de prendre toute décision. C’est ce que l’on appelle la fatigue décisionnelle. Si elle n’est pas prise rapidement en compte, elle peut entraîner du code « spaghetti », du code difficile à lire et à comprendre et qui plus tard sera impossible à démêler.

Peut-on éviter la fatigue décisionnelle ? 

Dans certains cas, les développeurs en mode “pair programming” peuvent rencontrer des situations où ils sentent qu’il vaudrait mieux impliquer toute l’équipe. Dans ce cas, ils peuvent rassembler tous les ingénieurs pour discuter de différents sujets comme la façon de concevoir une réponse à un problème technique particulier, assurer la consistance du code, ou tout autre sujet qui pourrait bénéficier d’une communication au sein du groupe. La diversité des talents et des expériences au sein d’une équipe garantit des solutions efficaces à tous les problèmes récurrents. Il est également très important que la paire se rappelle mutuellement de faire des pauses, surtout quand l’un d’entre a trop le nez dans le guidon pour s’en souvenir !

Cela n’évitera pas totalement la fatigue décisionnelle, mais cela permettra de faire un meilleur usage de son énergie mentale. C’est là que la programmation par paire devient réellement utile. Elle permet de partager la charge décisionnelle entre deux personnes. Une communication en amont au sein du duo et de l’équipe en général, permet de s’assurer que tout le monde est sur la même longueur d’onde. 

Quelles que soient les décisions prises, la programmation par paire est l’une des nombreuses méthodes que les ingénieurs peuvent utiliser pour avoir un retour immédiat en temps réel sur le code qu’ils écrivent. Totalement à l’opposé d’une revue de code où la personne faisant la revue n’a pas toujours accès au cheminement de pensée qui a abouti au code. Cette dernière méthode correspond plus à voir une vidéo terminée sur YouTube, une performance artistique ou un livre publié. Les clients ne voient pas le processus qui a abouti au produit final. 

Dans l’idéal, la programmation par paire entraîne moins de fatigue décisionnelle, car chaque membre de la paire peut travailler avec l’autre pour se soutenir mutuellement, prendre de meilleures décisions et y arriver plus vite que tout seul. 

Le travail à distance durant la pandémie a-t-il accru la fatigue décisionnelle ? 

Idéalement, travailler à distance en faisant du pair programming ne devrait pas avoir d’impact négatif sur la fatigue décisionnelle, à condition que chaque membre du duo communique activement et s’engage dans le travail à faire. Mais, programmation par paire ou non, dans les faits, le travail à distance en lui-même peut s’avérer compliqué pour de nombreuses raisons. Et quand les gens ne sont pas réellement impliqués dans leurs partenariats que ce soit sur site ou à distance, alors les équipes peuvent constater une augmentation de la fatigue décisionnelle et une perte des avantages du travail en duo. 

Beaucoup de gens mettent en avant les avantages du travail à distance, et il y en a certainement un grand nombre : plus de flexibilité, pas de temps perdu dans les transports, le confort de travailler de chez soi, etc.. Toutefois, sans avoir un environnement de travail et un équipement approprié, travailler de la maison peut s’avérer difficile et peu confortable pour un grand nombre de travailleurs. En particulier, certains peuvent avoir du mal à déconnecter du travail et cela peut gêner la possibilité de créer des liens au sein des équipes. Ces occasions soit disparaissent complètement avec le travail à distance, ou demandent beaucoup plus d’effort pour être créées. 

C’est ici que les avantages de la programmation extrême (XP) deviennent de plus en plus intéressants : la communication, le retour, la simplicité, le courage et le respect. Travailler à distance ne facilite pas la pratique de ces valeurs, car cela limite les occasions d’interagir avec vos équipiers. Ce qui rend encore plus important le fait que tous les membres d’une équipe prennent en compte ces valeurs en toute conscience avant d’interagir avec leurs collègues.

Comme de nombreuses personnes continueront à travailler à distance, mon conseil pour les autres développeurs serait de préserver leur énergie mentale pour les décisions qui comptent vraiment, comme comment concevoir ou tester une nouvelle fonction, et de dépenser moins d’énergie pour les choix les moins importants que les ingénieurs doivent faire tous les jours. Certains processus peuvent également être automatisés, ce qui leur évite de devoir revenir sans cesse sur certaines décisions. L’automatisation peut prendre des formes aussi simples qu’un format de code constant, ou être aussi compliquée qu’écrire un script pour une tâche répétitive. L’automatisation codifie les décisions pour ne pas avoir à les reprendre une deuxième fois, garantissant que les processus soient exécutés toujours de la même façon et les rendant facilement compréhensibles pour les autres membres de votre équipe.