IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Quel impact le mécontentement d'un développeur est-il susceptible d'avoir sur sa productivité ?
Perte de motivation ? Manque de concentration ? Non-respect des délais ? Partagez votre expérience

Le , par Patrick Ruiz

102PARTAGES

22  0 
La réalité, appuyée par des études scientifiques, montre qu’un travailleur est plus productif quand il est heureux sur le lieu de service. Ceux de la filière informatique ne sont pas en reste. La question qui fait surface en lien avec cette catégorie est celle de savoir quel impact le mécontentement d’un développeur est susceptible d’avoir sur sa productivité ? Perte de motivation ? Manque de concentration ? Non-respect des délais ? Quelle conséquence du mécontentement colle le plus avec votre expérience personnelle ?

Des chercheurs de quatre universités basées en Allemagne, Italie, Finlande et Norvège sont à l’origine d’un sondage quantitatif et qualitatif de 2200 développeurs sélectionnés sur GitHub. De leurs travaux basés sur le SPANE-B (une métrique utilisée en psychologie) pour mesurer le niveau de bonheur des développeurs, il ressort que les travailleurs de cette catégorie sont « un peu heureux ». Dans les chiffres, le niveau de bonheur mesuré avec la métrique SPANE-B varie de -24 à 24. Dans le cas de cette étude, les développeurs affichent des scores allant de -16 à 24 et une moyenne de 9,05.


Grosso modo, les chercheurs sont d’avis que la nécessité de limiter le mécontentement des développeurs demeure. Leur publication dresse une liste de conséquences du mécontentement des travailleurs de cette catégorie sur leur productivité. Le mécontentement influe de façon négative sur la performance cognitive des développeurs. À contrario, la capacité d’un tiers à trouver des solutions à des problèmes est meilleure lorsqu’il est heureux sur le lieu de service. La publication fait de plus état de ce que le mécontentement peut expliquer un manque de concentration de la part d’un travailleur de cette filière. Conséquence logique : le non-respect des délais s’invite au processus de développement.

« Le mécontentement et l’aise sur le lieu de service sont de façon respective les causes de l'abandon du travail et de l'engagement au travail. Le retrait du travail est une conséquence très destructive du mécontentement et il est souvent apparu dans les réponses », indiquent les chercheurs.


Quels facteurs concourent à ceux que les développeurs ne soient pas heureux ?

La publication identifie un total de 219 causes de mécontentement des développeurs. Elle met une dizaine en évidence :

Être bloqué dans la résolution d'un problème. C'est de loin la cause la plus importante. Comme le rappellent les chercheurs, le développement de logiciels est essentiellement composé d'activités de résolution de problèmes, souvent exigeantes intellectuellement. Il est fréquent que les développeurs soient bloqués dans le codage, le débogage et toutes sortes d'autres tâches. Beaucoup de développeurs ont dit se sentir vraiment mécontents quand ils rencontrent des problèmes qu'ils n'arrivent pas à résoudre ou contourner.

La pression du temps. La plupart du temps, c'est une situation dans laquelle les développeurs se retrouvent lorsqu'on leur impose des délais serrés. D'après l'étude, c'est l'une des principales raisons pour lesquelles les développeurs peuvent être mécontents au travail.

De mauvaises qualités de code et pratiques de codage. Un code de mauvaise qualité ou de mauvaises pratiques de codage sont également parmi les causes les plus évoquées par les développeurs enquêtés. Mais comme vous pouvez l'imaginer, dans presque tous les cas, ce sont des causes de mécontentement chez les développeurs lorsqu'il s'agit d’un code écrit par d'autres développeurs et non par eux-mêmes. Certains développeurs affirment en effet qu'ils sont de mauvaise humeur lorsqu'ils doivent utiliser le code d'un autre développeur et qu'ils se rendent compte qu'il est plein de bogues.

La sous-performance d’un collègue. Le développement de logiciels est souvent un travail d'équipe. La sous-performance d’un collègue (que ça soit un membre de l'équipe, un membre d’une autre équipe, ou un collaborateur externe) peut donc avoir un impact négatif sur le travail collectif. Les répondants ont en effet affirmé qu’il est souvent frustrant de voir que d'autres collègues ne prennent pas le temps de se mettre à jour et se former aux technologies et pratiques de développement modernes.

Avoir le sentiment d’être sous-qualifié pour un travail. Pour certains développeurs, c’est la pire des choses qui peut leur arriver. Cela peut se manifester comme un sentiment de non-qualification ou sous-qualification dans certains aspects de leur travail. Il peut s’agir d’une maîtrise insuffisante des outils, langages, frameworks ou méthodes de développement qui sont utilisés dans les projets.

Les tâches banales ou répétitives. Les développeurs semblent éprouver plus de plaisir au travail quand chaque journée est un nouveau défi à relever. D'après l'étude, les tâches ennuyeuses, monotones, triviales ou encore récurrentes sont susceptibles d'avoir des effets négatifs sur l'épanouissement des développeurs au travail.

Un code qui ne marche plus sans raison. Pour certains développeurs, la pire des choses qui peut leur arriver, c’est de voir qu’ils n’ont rien changé à un code et qu’il ne marche plus tout à coup. C’est vraiment pénible pour eux de ne pas pouvoir expliquer ce qui s’est passé.

Mauvaises prises de décision. Comme n'importe quel employé en général, les développeurs sont également affectés par les mauvaises décisions prises par leurs supérieurs hiérarchiques ou pairs. Ces prises de décision peuvent être vues sous différents aspects, mais c'est surtout lorsqu’ils ne sont pas impliqués dans les processus décisionnels, pour des choix technologiques par exemple.

Limites imposées par les technologies de développement. Parfois, les technologies ou l’infrastructure technique sur lesquelles repose un projet de développement logiciel imposent certaines limitations aux développeurs. Les outils, langages et autres technologies utilisés ne fonctionnent toujours pas comme prévu*; parfois, parce qu'ils sont bogués, parfois parce que, par conception, ils imposent certaines limites ou ignorent certains cas d'utilisation. Les développeurs doivent donc trouver des solutions de contournement qui ne sont pas toujours aisées techniquement, et qui peuvent conduire à un code sale ou qui met en évidence des pratiques déconseillées. Pour certains développeurs, cela peut être également une source de mécontentement.

Les problèmes personnels. Comme dans n'importe quel autre métier, les développeurs peuvent vivre des problèmes personnels ou privés non liés au travail, mais qui affectent dans une certaine mesure leur travail. C'est le cas par exemple des problèmes de famille. Certains répondants disent en effet que les situations personnelles ont des effets importants sur le niveau de bonheur au travail. Ainsi, des problèmes personnels sont susceptibles de les affecter négativement et les rendre moins productifs.

Source : publication

Et vous ?

Vous est-il arrivé d’être mécontent sur le lieu de service ? Quel impact cela a-t-il eu sur votre productivité ?
Quelles sont les conséquences du mécontentement qui manquent à la liste proposée par cette étude ?
Votre entreprise use-t-elle d’artifices pour éviter le mécontentement des développeurs ? Partagez votre expérience

Voir aussi :

« 52 minutes de travail, 17 minutes de pause », la formule idéale pour un bon rendement, selon une étude

Une entreprise passe à la semaine de quatre jours après un test concluant sur l'amélioration de la productivité et la réduction du niveau de stress

Les travailleurs seraient beaucoup plus productifs en travaillant 4 jours au lieu de 5 par semaine selon une étude, qu'en est-il des informaticiens ?

Des experts font la promotion de la semaine de travail de quatre jours au lieu de cinq, pour eux, cela rendrait les travailleurs plus productifs

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de GLDavid
Expert confirmé https://www.developpez.com
Le 10/11/2021 à 11:45
Bonjour

Toutes ces raisons sont bonnes mais il manque un élément: le contexte de l'entreprise où l'on développe.
Vous travaillez dans une entreprise qui fait de ses développeurs comme un élevage de poulets en batterie (vu de mes yeux)? Avouez que ça donne pas envie.
Votre direction change tout le temps d'orientation ou tous les ans, une nouvelle réorganisation se pointe encore plus bordélique que la précédente et de toute façon, elle sera à peine déployée qu'une autre arrivera.
Ces éléments nuisent aussi à la sérénité du travail.

@++
27  0 
Avatar de walfrat
Membre expérimenté https://www.developpez.com
Le 10/11/2021 à 14:22
Citation Envoyé par GLDavid Voir le message
Bonjour

Toutes ces raisons sont bonnes mais il manque un élément: le contexte de l'entreprise où l'on développe.
Vous travaillez dans une entreprise qui fait de ses développeurs comme un élevage de poulets en batterie (vu de mes yeux)? Avouez que ça donne pas envie.
Votre direction change tout le temps d'orientation ou tous les ans, une nouvelle réorganisation se pointe encore plus bordélique que la précédente et de toute façon, elle sera à peine déployée qu'une autre arrivera.
Ces éléments nuisent aussi à la sérénité du travail.

@++
Tiens donc, ça me parle déjà plus.

Les répondants ont en effet affirmé qu’il est souvent frustrant de voir que d'autres collègues ne prennent pas le temps de se mettre à jour et se former aux technologies et pratiques de développement modernes.
Sur quel compte d'imputation je dois faire ça ? Sur mon temps perso ? Attends je revérifie mon contrat...

En outre bien que légèrement sous entendu, il manque un paragraphe sur les problèmes d'organisations : pas de spécification solides, pas de validation solide (oui oui, valideur c'est un métier, développeur est un autre métier), projet "agile" genre numéro d'équilibriste, etc, etc
19  0 
Avatar de dfiad77pro
Membre expérimenté https://www.developpez.com
Le 11/11/2021 à 10:45
y'a aussi les problématiques matérielles :
genre on te file un celeron avec 4go de ram , sans SSD, et un seul écran de 15 pouce pour faire du dev.

sous prétexte que les utilisateurs ont des pc de merde .
14  0 
Avatar de yoyo3d
Membre éprouvé https://www.developpez.com
Le 23/11/2021 à 17:07
S'lut
l'étude est intéressante, mais les principales raisons du mécontentement d'un Dev peuvent tout à fait être transposables à n'importe quel salarié.
mauvaises décisions stratégiques (de la hiérarchie)
manque de communication transverses (de la hiérarchie)
délestage massif des mission sur les subalternes (de la hiérarchie)
manque de reconnaissance(de la hiérarchie)
conditions de travail (matériel personnel sanitaires etc)

Et le résultat de ce mécontentement global aura également un impact négatif sur le travail de ce salarié...
11  0 
Avatar de ensi_en
Membre régulier https://www.developpez.com
Le 23/11/2021 à 15:03
Citation Envoyé par Jamatronic Voir le message
J'ai appris à coder sur un Atari ST...

Donc vu ton point de vue, je t'invite à changer d'activité
Malheureusement on n'est plus dans les années 1980. Maintenant on a besoin des IDE, Docker, des bases de données, des navigateurs et plein d'autres trucs pour pouvoir exercer notre activité !
9  0 
Avatar de Bousk
Rédacteur/Modérateur https://www.developpez.com
Le 22/11/2021 à 16:12
Citation Envoyé par Jamatronic Voir le message
J'ai appris à coder sur un Atari ST...

Donc vu ton point de vue, je t'invite à changer d'activité
Mais ton Atari ne chargeait pas un IDE, des tools et tout un tas de trucs qui prennent beaucoup de ressources.
Ton Atari était (très probablement) adapté à ton utilisation.
Dans mon premier job, j'avais une config à peu près équivalente, et c'était pas mal à l'époque.
Sauf que voilà, le projet est sur VS, contenait une centaine de projets, ils avaient des tools customs pour tester des trucs. Résultat : VS crash et pc reboot (BSOD) 2/3 quand j'ouvre le sln ou le compile...
8  0 
Avatar de fodger
Membre averti https://www.developpez.com
Le 10/11/2021 à 14:45
Citation Envoyé par GLDavid Voir le message
Bonjour

Toutes ces raisons sont bonnes mais il manque un élément: le contexte de l'entreprise où l'on développe.
Vous travaillez dans une entreprise qui fait de ses développeurs comme un élevage de poulets en batterie (vu de mes yeux)? Avouez que ça donne pas envie.
Votre direction change tout le temps d'orientation ou tous les ans, une nouvelle réorganisation se pointe encore plus bordélique que la précédente et de toute façon, elle sera à peine déployée qu'une autre arrivera.
Ces éléments nuisent aussi à la sérénité du travail.

@++
On ne pensera pas notamment à certaines célèbres ESN ...
6  0 
Avatar de Mister Nono
Membre expérimenté https://www.developpez.com
Le 24/11/2021 à 9:56
Une autre source de mécontentement : Travailler.
5  0 
Avatar de Aiigl59
Membre actif https://www.developpez.com
Le 24/11/2021 à 20:18
Malheureusement on n'est plus dans les années 1980. Maintenant on a besoin des IDE, Docker, des bases de données, des navigateurs et plein d'autres trucs pour pouvoir exercer notre activité !
Pour des résultats de plus en plus mitigés au niveau de la qualité, de l'efficacité et de la sécurité...
Quand on pense qu'on arrivait à créer des jeux complets avec 48Ko de RAM en "1980" (l'aigle d'or) sans "Dockers, Bdd, Navigateur et sans 8Go de librairies injectées pour se servir de 1% des libs.
Certes, ils étaient loin des graphismes actuels, mais coté ludique c'était les mêmes résultats.

C'est vrai aussi qu'en "ces temps là" il n'y avait pas besoin d'une machine avec une complète dépendance au réseau, sans 4 Go de logiciels antivirus, sans 8Go de ram pour ne faire tourner qu'un OS et son antivirus (keskispass ? j'ai ouvert mon navigateur et ça rame ?)
C'est pour ça qu'on appelle ça des navigateurs... c'est pour ramer bien sûr...

Oui tu as raison: les temps ont changés, mais dans quelle direction ? L'évolution est inéluctable, tout le monde le sait bien,
mais sans la prise de position de certaines sociétés qui monopolisent et dictent le "net" (et les problèmes qui vont avec), cette évolution aurait pu et du être gérée avec beaucoup plus de respect des droits essentiels de chaque individus.

Enfin ce n'est que l'humble avis d'un "ancien" qui a commencé à "s'amuser" avec un Oric dans le début des années "80" justement.
8  4 
Avatar de dfiad77pro
Membre expérimenté https://www.developpez.com
Le 24/11/2021 à 19:09
Franchement les gas qui me disent oui mais je codais avec 16kb de ram...

moi je suis un peu plus jeune, c'était avec 8mb de ram et j'avais moins 12 ans (ce qui faisait tourner windows 95),
mais franchement, faut se mettre à la réalité d'aujourd'hui. On nous vante l'écologie mais la réalité c'est que l'optimisation est très loin d'être la priorité tant qu'on gagne de l'argent.

essaye de promouvoir de coder un soft prenant moins de 100mo de ram actuellement (pour un budget 4fois plus élevé), et tu fera éjecter royalement, pour raison budgétaire , sauf cas particulier
4  1