Discussion :

[Olivier Famien]

Votre sentiment d’échec vous a-t-il déjà conduit au syndrome d’épuisement professionnel ?
Un développeur donne sa recette pour éviter cette situation

Le syndrome d’épuisement professionnel, appelé burnout en anglais, est un état de fatigue professionnel accentué par un désinvestissement du travail effectué. Il est souvent accompagné d’un sentiment d’échec et une perte de confiance en soi, car le travailleur n’arrive plus à gérer les différentes pressions au travail et à faire face aux exigences de son employeur.

Dans le domaine IT, la pression est quasi permanente lorsqu’il s’agit d’achever les projets dans des délais serrés, de respecter le cahier des charges du client, d’intégrer les nouvelles exigences qui n’avaient pas été définies au départ toujours en respectant les contraintes d’avant-projet.

Et nombreux sont les développeurs qui, sous l’effet de ces différentes pressions, perdent au fil des années le gout pour le travail, car ils n’arrivent plus à s’adapter aux variations et objectifs de l’entreprise dans laquelle ils se trouvent. S’ensuivent alors des échecs et le manque de confiance en soi qui peut finir par le syndrome d’épuisement professionnel.

Un développeur du nom de Karolis Ramanauskas, qui sait trop combien ce phénomène est grandissant dans l’environnement des développeurs, puisqu’il l’a déjà traversé à maintes reprises, a voulu apporter sa contribution en donnant des conseils afin de permettre aux développeurs de ne pas tomber dans cette situation ou pour d’autres de sortir de cet étau.

Pour pouvoir donner des solutions idoines, Ramanauskas s’est d’abord penché sur les causes probables de cet état de fatigue professionnel et a pu dégager 4 facteurs clés à la base de cette situation.


Les causes de l’épuisement professionnel

1. La première est d’ordre physique. En effet, pour le développeur, travailler du matin au soir sur son ordinateur est néfaste pour la santé et conduit à une situation de léthargie qui pourrait avoir comme corolaire de mauvaises habitudes, telles que grignoter pendant la journée, prendre des stimulants ou encore rester éveillé tardivement.

2. La seconde raison énoncée est que la programmation est un métier très stressant qui sollicite beaucoup le cerveau. Cela entraine donc une fatigue mentale.

3. La troisième raison avancée est qu’un développeur peut ressentir un état de burnout lorsque son travail n’est pas gratifiant. Dans ce cas, il lui est recommandé de prendre du recul et de réfléchir sur quelque chose sur lequel il aimerait travailler sans mettre en avant le facteur rémunération.

4. En quatrième position, Ramanauskas cite une source externe expliquant que « le syndrome d’épuisement professionnel est causé par le fait que vous effectuez à plusieurs reprises de grandes quantités de sacrifices ou d’efforts sur les problèmes à haut risque qui échouent. C’est le résultat d’une erreur de prédiction négative dans le noyau accumbens. Vous conditionnez efficacement votre cerveau à associer le travail et l’échec ».

Comme recommandations, le développeur donne deux groupes de solutions. D’une part, celles qui touchent à l’ensemble des travailleurs et d’autre part celles qui sont intimement liées aux développeurs.


Les solutions adressées au grand public

1. Ramanauskas recommande en premier point de bien manger. Cela sous-entend boire de l’eau au lieu de soda, manger régulièrement et intégrer des légumes et hydrates de carbone dans le régime alimentaire.

2. En second point, il recommande de bien dormir. Le développeur recommande d’avoir une quantité et une qualité suffisante de sommeil. Aussi, pour ne pas être absorbé dans son travail et passer les heures de sommeil, Ramanauskas conseille l’installation de l’application Flux qui adapte la couleur de l’écran aux différentes heures de la journée.

3. En troisième point, ne vous surmenez pas. Même s’il est vrai que la durée légale de travail journalier s’élève à 7 heures dans certains pays et 8 heures maximum dans d’autres pays, il est également démontré qu’après 4 heures de travail, la productivité décroit fortement. À long terme, cela devient insoutenable pour le développeur qui doit fournir des efforts de réflexion au quotidien.

4. En quatrième point, utilisez la technique Pomodoro. Elle consiste à déterminer le temps imparti pour effectuer un travail et à faire des pauses régulières après une durée définie. Par exemple, pour 25 minutes de travail, il est recommandé d’avoir 5 minutes de pauses. Cela permet d’évacuer le stress tout en restant concentré sur l’objectif à atteindre et le temps réservé pour le travail.

5. En cinquième point, restez actif. Il n’est nul besoin de se lancer dans un programme de gymnastique que vous ne pourrez pas continuer à long terme. Il suffit juste de changer quelques habitudes. Au lieu d’utiliser l’ascenseur, prenez les escaliers. Au lieu d’utiliser la voiture, utilisez le vélo pour vous rendre au travail, si bien entendu la distance vous le permet. Soyez inventif en intégrant des activités sportives dans votre quotidien.


Les solutions destinées aux développeurs

1. En général, il est recommandé de faire ce que l’on sait faire le mieux. Ce à quoi vous prenez le plus plaisir doit-être la chose avec laquelle vous occupez votre temps. Mais à faire la même chose tous les jours, il est facile de tomber dans la routine et de ne plus y prendre plaisir. C’est pourquoi, si vous développez des logiciels, consacrez 20 % de votre temps à faire tout et n’importe quoi avec d’autres technologies. Cela sous-entend de tester de nouvelles bibliothèques, de créer quelque chose de drôle qui n’a rien à voir avec votre travail, ou encore d'utiliser votre temps pour apprendre quelque chose que vous ne maitrisez pas, tel que la programmation fonctionnelle.

2. La programmation étant un métier qui peut entrainer la solitude, il est conseillé de prendre part à des rencontres, des conférences afin de rencontrer du monde ou encore d'écouter l’expérience d’autres développeurs à travers les podcasts afin de pouvoir surmonter ses propres difficultés.

3. Ne lésinez pas sur vos moyens pour acquérir un bon environnement de travail. Il va falloir mettre la main à la poche pour obtenir un bon PC qui ne rame pas, mais obéit au moindre clic afin de ne pas perdre du temps précieux à attendre gratuitement la fin d’une longue compilation. Si vous travaillez dans un environnement où il y a beaucoup de bruits, achetez un casque de haute qualité afin de vous isoler des bruits extérieurs. Par ailleurs, assurez-vous de disposer d’un fauteuil confortable, d’une table et de moniteurs bien positionnés.

4. Domptez vos outils de travail. Acquérir de bons outils est une chose, mais les maitriser est encore mieux. Si vous avez l’occasion de maitriser les raccourcis de vos outils à savoir votre EDI, votre éditeur de texte, des lignes de commande pour votre système d’exploitation, n’hésitez pas à le faire. En outre, si vous pouvez automatiser les tâches banales ou rébarbatives, faites-le. Cela vous fera avancer bien plus rapidement en cas de pépin et vous permettra d’éloigner le burnout assez loin de vous.

5. Donnez-vous du temps pour d’autres choses que la programmation. Sinon un jour vous vous réveillerez de votre sommeil et certainement vous vous haïrez de n’avoir pas eu de vie autre que la programmation. Prenez donc part à des manifestations culturelles, sportives, à la pêche, à la photographie, etc. En le faisant, vous pouvez même avoir des lumières sur des aspects de votre travail sur lequel vous butez depuis belle lurette simplement parce que vous avez le nez trop plongé dans votre code.

6. Si le travail de développeur que vous avez n’est pas motivant, pensez à changer de carrière en explorant d’autres horizons tels que l’administration systèmes, ou encore l’architecture d’information, etc. Peut-être, vous vous découvrirez une nouvelle passion dans ces différents emplois explorés.

7. Enfin, exécuter les tâches quotidiennes connues comme pouvant vous procurer une sensation de bien-être. Par exemple, achever les activités de tests de code, d’écriture de commentaires, d’amélioration des noms de variables dégagera des endorphines qui aideront à restaurer l’acte de travail. « Ceci est une astuce courte, mais très précieuse, car elle donne à notre cerveau un sentiment plus positif sur le travail que nous effectuons », a conclu Ramanauskas.

Source : Medium.com

Et vous ?

Que pensez-vous de la solution de Ramanauskas pour éviter le burnout ?

Est-elle réaliste ?

Voir aussi
Forum langages de programmation

[Paul TOTH]

ça ce n'est qu'une vision du burnout, il suffit de faire un tour sur WP pour en trouver deux autres !

Vision transactionnelle de Cary Cherniss
... Un travail souvent routinier contraste avec les envies de tâches variées, de stimulations, d’accomplissement. Le manque de coopération entre collègues, voire les conflits interpersonnels, s’ajoutent à ces écarts entre attentes et réalité.
Face à un environnement de travail décevant, la motivation initiale s’étiole et fait place à des attitudes de retrait...

Approche motivationnelle d'Ayala Pines
... Plus ils s’impliquent au départ, plus la probabilité d’être atteint par le syndrome est forte si les conditions de travail sont défavorables...ce n’est pas l’échec en tant que tel qui provoque le syndrome d’épuisement professionnel, c’est plutôt la perception que quels que soient les efforts, le sujet ne peut prétendre avoir un impact significatif.

Dans ces définitions ce n'est pas une question de bien dormir ou de bien manger, c'est une inadéquation entre les motivations du travailleur et la liberté d'action qu'on lui laisse. Exemple, je voudrais corriger des bugs pour rendre le produit meilleurs, mais on me demande de justifier de mon temps de travail, de remplir des tableaux statistiques sur le temps passé au support, sans que jamais aucun retour ne soit donné sur l'intérêt éventuel de ces tâches. J'ai un contrat de développeur et on me demande de remplir des tableaux Excel...au lieu de critiquer mes performances, ou la qualité de mon travail on me réclame un strict respect des horaires, quitte à ce que je sois présent sans travail à accomplir ou que je quitte le travail avec une tâche non terminée.

[eldran64]

Le point numéro 3 est peut être le plus difficile à mettre en œuvre: pour la partie PC, toutes les boites n'acceptent pas le BYOD.

Sinon, je suis d'accord avec le reste.

Globalement il faut aussi savoir accepter qu'on a des périodes de haut et de bas (inutile de se mettre de la pression supplémentaire quand cela ne va pas très fort).

[Traroth2]

Donc en gros, pour travailler sur des trucs intéressants, il faut être prêt à travailler gratuitement, et il ne faut pas hésiter à acheter soi-même un outil de travail performant. Déprimant...

[Uranne-jimmy]

Je suis assez d'accord sur les points qui permettent d'améliorer notre état moral et physique par rapport au travail. Sans parler de burnout, faire ce qu'il dit, dans la mesure où cela nous convient, est un facteur assez sympa pour se sentir mieux.
Ce qui m'amuse c'est qu'un certain nombre des recommandations qu'il propose pour les développeur, je les exécute déjà, simplement en écoutant ce que j'ai envie, dans le mesure où ça ne m'empêche pas d'être performant.

[el_slapper]

le point 1 est de la foutaise pure et simple. Si ma spécialité n'a aucune valeur ajoutée dans l'entreprise, j'ai intérêt à faire autre chose. Je déteste le système, et je ne connais rien à Linux, mais comme on manque de gens pour faire ça, j'ai du m'y coller pour des raisons opérationnelles. ça m'a fait chier, je n'ai pas été très bon, ni très productif, mais je m'en suis sorti, et on a maintenant des environnements de test qui ressemblent à quelque chose.

Je n'aime toujours pas le système, et je reste un pas-très-bon(euphémisme) en Linux.

ça fait partie de la vie professionnelle.

Après, il ne faut pas se contenter de manger du gravier. Mon chef sait que ça me fait chier, et si on arrive à trouver du budget pour une ressource système, il sait que ça me fera grand plaisir, et pourquoi. Rien que le fait de lui dire à quel point je déteste ça(et admire les maitres), ça m'a aidé à passer le cap. Mais j'ai été professionnel, et j'ai fait de mon mieux. En râlant parce que je suis un Français, et parce que ça aide à tenir.

[LSMetag]

Ayant déjà vécu le Burn Out, je trouve cet article de très bonne facture. Il y a beaucoup de points que j'applique déjà désormais. En effet, je vise la reconversion en Architecture de SI, par le biais d'une petite (pour l'instant) entreprise de prestation de service, avec le mode de fonctionnement qui m'a toujours réussi (les rares fois où j'ai pu l'appliquer).

@el_slapper : Malheureusement, râler n'a pas fait bouger mes patrons en ce qui me concerne. Faire ce qu'on sait le mieux faire est effectivement plus facile et rassurant mais il est aussi indiqué qu'il est bon de faire de la veille techno. Après, le travail n'est pas toujours drôle et il faut faire avec, mais quand ça devient récurrent, il est normal de songer à démissioner.

[el_slapper]

(.../...)@el_slapper : Malheureusement, râler n'a pas fait bouger mes patrons en ce qui me concerne. Faire ce qu'on sait le mieux faire est effectivement plus facile et rassurant mais il est aussi indiqué qu'il est bon de faire de la veille techno. Après, le travail n'est pas toujours drôle et il faut faire avec, mais quand ça devient récurrent, il est normal de songer à démissioner.

Pour l'instant, le poste qui me libérerait(moi et deux autres, pour être précis) de ce fardeau est juste une idée qui circule entre les chefs. Certains sont convaincus, d'autres pas. Mais si tu ne râles pas, le chef ne va pas se poser de questions. Peut-être que dans dix ans je continuerait a avoir 25% de mes tâches en système, et je suis aussi doué pour ça que pour être pivot au basket(je mesure 1m64). Mais au moins ils savent que c'est un problème pour moi, et ça change la manière dont ils me donnent cette partie du boulot.

Après, démissionner, c'est à double tranchant, on sais ce qu'on perd, pas ce qu'on gagne. Sur les 75 autres % de ce nouveau job, j'y ai clairement gagné. Il faut savoir ce que l'on veut. Mais le dream job sans contreparties, ça n'existe pas.

[Marco46]

Dans le domaine IT, la pression est quasi permanente lorsqu’il s’agit d’achever les projets dans les délais serrés, de respecter le cahier de charge du client, d’intégrer les nouvelles exigences qui n’avaient pas été définies au départ toujours en respectant les contraintes d’avant-projet.

Ca c'est juste de l'incompétence au niveau de la gestion du projet (proposition commerciale et contrat en particulier).

Si le chiffrage initial c'est 100 jours et que les modifs demandées après coup rajoutent 30 jours de plus il faut facturer 30 jours de plus et augmenter le délai de 30 jours.

C'est délirant de voir que dans l'informatique on puisse faire des choses comme ça. Allez vous faire construire une maison ou n'importe quoi d'autre et changez les plans en cours de route tout en demandant de ne rien payer de plus et le même délai qu'on rigole un peu ...

[Bousk]

Article sympa, qui m'a fait immédiatement pensé à Barney Stinson

[Gort'h]

Ca c'est juste de l'incompétence au niveau de la gestion du projet (proposition commerciale et contrat en particulier).

Si le chiffrage initial c'est 100 jours et que les modifs demandées après coup rajoutent 30 jours de plus il faut facturer 30 jours de plus et augmenter le délai de 30 jours.

C'est délirant de voir que dans l'informatique on puisse faire des choses comme ça. Allez vous faire construire une maison ou n'importe quoi d'autre et changez les plans en cours de route tout en demandant de ne rien payer de plus et le même délai qu'on rigole un peu ...

Oui c'est semble-t-il un élément qu'on trouve beaucoup en informatique.
Pour autant lorsque le client demande on peut difficilement passer outre. Après il y a effectivement des méthodes pour gérer ça.Les avenants commerciaux par exemple mais ce n'est que d'un point de vue financier. Côté délais en revanche...

[Marco46]

Oui c'est semble-t-il un élément qu'on trouve beaucoup en informatique.
Pour autant lorsque le client demande on peut difficilement passer outre.

Ben si, il suffit d'arrêter de faire n'importe quoi. Pour reprendre l'exemple du bâtiment, demande des travaux sur une certaine base puis déboule au milieu en disant bon ben finalement je voudrais que la salle de bain ne soit plus ici mais là pis rajoutez moi 3 m² ici pour la cuisine, etc ... Ca ne passera jamais.

Pourquoi dans l'informatique on voit ce genre d'horreurs ?

Yavait quelqu'un qui avait posté une vidéo sur ce thème assez marrante, ils avaient fait l'analogie avec la restauration. On voyait un client qui se comportait comme les clients dans l'informatique.

client : "Je voudrais un steak mais pas comme sur la carte, un truc simple moins cher vous voyez ?"
serveur : "Vous voulez donc un steak ?"
client : "Non je ne veux pas le steak de la carte, je veux un steak mais différent."
serveur : "C'est quoi un steak simple ?"
client : "C'est un steak. Mais c'est pas le steak de la carte vous comprenez ?"

Je schématise de mémoire mais en gros c'est ça et c'est souvent ce que font les clients.

[Gort'h]

Ben si, il suffit d'arrêter de faire n'importe quoi. Pour reprendre l'exemple du bâtiment, demande des travaux sur une certaine base puis déboule au milieu en disant bon ben finalement je voudrais que la salle de bain ne soit plus ici mais là pis rajoutez moi 3 m² ici pour la cuisine, etc ... Ca ne passera jamais.

Pourquoi dans l'informatique on voit ce genre d'horreurs ?

Yavait quelqu'un qui avait posté une vidéo sur ce thème assez marrante, ils avaient fait l'analogie avec la restauration. On voyait un client qui se comportait comme les clients dans l'informatique.

client : "Je voudrais un steak mais pas comme sur la carte, un truc simple moins cher vous voyez ?"
serveur : "Vous voulez donc un steak ?"
client : "Non je ne veux pas le steak de la carte, je veux un steak mais différent."
serveur : "C'est quoi un steak simple ?"
client : "C'est un steak. Mais c'est pas le steak de la carte vous comprenez ?"

Je schématise de mémoire mais en gros c'est ça et c'est souvent ce que font les clients.

L'analogie avec la restauration est mauvaise à mon avis.
Lorsqu'un client à un projet informatique il n'y a pas de carte où il choisit. Il part d'une feuille blanche et expose son besoin. Il faut l'aider à le faire émerger pour faire réaliser ce qu'il souhaite. Rien à voir avec un choix dans une liste.

Ensuite son besoin peut évoluer avec le temps.A partir du moment où il paie il a droit de faire des modifications dans ce qu'il avait initialement prévu.
Le seul problème selon moi c'est surtout qu'il est difficile de faire bouger les délais en fonction des modifications qui arrivent en cours de projet.

[garn]

Ben si, il suffit d'arrêter de faire n'importe quoi. Pour reprendre l'exemple du bâtiment, demande des travaux sur une certaine base puis déboule au milieu en disant bon ben finalement je voudrais que la salle de bain ne soit plus ici mais là pis rajoutez moi 3 m² ici pour la cuisine, etc ... Ca ne passera jamais.

en fait, si (tant que c'est pas construit, et en payant les suppléments et le temps de rallonge. on a fait ca l'année dernière (en informatique, pas en batiment ) : périodiquement, on jetait quelques semaines de dev par la fenêtre parceque la nouveauté marketing / métier détruisait le modèle de données, les règles de gestion..;
bah, ca a mis plus longtemps, le client a raqué, mais ils ont eu ce qu'ils voulaient

Pourquoi dans l'informatique on voit ce genre d'horreurs ?

Yavait quelqu'un qui avait posté une vidéo sur ce thème assez marrante, ils avaient fait l'analogie avec la restauration. On voyait un client qui se comportait comme les clients dans l'informatique.

client : "Je voudrais un steak mais pas comme sur la carte, un truc simple moins cher vous voyez ?"
serveur : "Vous voulez donc un steak ?"
client : "Non je ne veux pas le steak de la carte, je veux un steak mais différent."
serveur : "C'est quoi un steak simple ?"
client : "C'est un steak. Mais c'est pas le steak de la carte vous comprenez ?"

Je schématise de mémoire mais en gros c'est ça et c'est souvent ce que font les clients.

je vais rajouter à la suite, après que le serveur soit parti se pendre

AMOA : "ok, donc on a dit un steak 300g, saignant, avec frite salade"
Client "mais j'ai pas dis ca"
AMOA : ah? ca vous va pas?
Client : euh ben si en fait, ca sera très bien

> My job
(bon, après on revient avec la photo du futur steak pour être sur et on nous fait changer ca pour du poulet, soit

[eulbobo]

je vais rajouter à la suite, après que le serveur soit parti se pendre

AMOA : "ok, donc on a dit un steak 300g, saignant, avec frite salade"
Client "mais j'ai pas dis ca"
AMOA : ah? ca vous va pas?
Client : euh ben si en fait, ca sera très bien

> My job
(bon, après on revient avec la photo du futur steak pour être sur et on nous fait changer ca pour du poulet, soit

Et quand tu lui sers son poulet parce que effectivement il voulait du poulet (et que tu as réussi à déduire qu'il le voulait pané), il te dit "Bizarre, Je m'attendais à ce que ça ait plus un goût de poisson pané... Y'a moyen de rajouter du ketchup à l'intérieur de la viande maintenant que c'est servi et que j'ai commencé à manger?"

[el_slapper]

en fait, si (tant que c'est pas construit, et en payant les suppléments et le temps de rallonge. on a fait ca l'année dernière (en informatique, pas en batiment ) : périodiquement, on jetait quelques semaines de dev par la fenêtre parceque la nouveauté marketing / métier détruisait le modèle de données, les règles de gestion..;
bah, ca a mis plus longtemps, le client a raqué, mais ils ont eu ce qu'ils voulaient (.../...)

ça, c'est un client sérieux.

Je me rappelle d'une TMA chez un grand compte, ou nous avions une procédure standard pour les modifs, et la modif unitaire, tout compris, coutait 9 heures. Ça marchait assez bien. Jusqu'au jour ou j'ai fait une connerie. Je teste un fichier de 10 enregs en dev, il marche bien, je teste rapidement un seul enreg en recette, il passe conforme aux nouvelles specs, hop, je livre confiant. A cause de différences techniques entre le dev et les autres environnements, plus rien ne marchait en recette et en prod à partir du deuxième enregistrement...une de mes plus grosses conneries, des centaines de courriers règlementaires ont été perdus à cause de ça.

Donc, ils nous ont demandé de faire des tests "complets", avec cahier de tests, traçage systématique des fichiers de test, et explication sommaire de chaque ligne. Et ça a marché. On a plus eu d'erreur du tout. On en avait pas beaucoup avant, mais là, plus du tout. Quand on leur a présenté la facture, à savoir 20 heures au lieu de 9, ils ont fait "gloups"... et payé. Ça, c'est du client sérieux. Qui sait pourquoi il paye et ce qu'il veut.

Mais, la plupart du temps, le client va gueuler que c'est trop cher, qu'il ne faut pas plus de 6 heures pour tout faire, ce retrouve avec de plus en plus de bugs, des prestas(les meilleurs) qui démissionnent, , des cahiers de tests truqués, etc... Et c'est là qu'on retombe sur les soucis précisés dans l'article. Je veux dire, j'étais le seul avec un background de testeur dans l'équipe, les collègues ont fait la gueule de devoir faire "tout ça"... mais ils ont vu les résultats, et qu'on leur donnait les moyens, et sont restés motivés. Alors que quand tout se casse la gueule, même le boulot rigolo devient démotivant. Bon, moi, je trouve ça rigolo aussi, les cahiers de tests, mais je ne suis pas cinglé au point de prendre mon cas pour une généralité...