Discussion :

[Michael Guilloux]

Trolldi : qu’est-ce qui vous agace le plus en tant que développeurs ?
Partagez vos expériences

Comme tout le monde, les développeurs sont souvent agacés par un certain nombre de choses au travail. Certaines peuvent être spécifiques à leur métier et d’autres, générales. Mais bon nombre sont liés à leurs relations avec leurs collègues, leur patron ou d’autres personnes qui interviennent dans leur quotidien. Parmi les choses et les personnes qui agacent ou ennuient les développeurs, on peut citer de manière non exhaustive :

Corriger les erreurs et bugs : si cela fait partir du quotidien du développeur, parfois, cela peut devenir un calvaire de corriger certains bugs, surtout s’il s’agit d’un code dont on a hérité, et de surcroît, d’un développeur avec de mauvaises pratiques de codage.

Écrire la documentation : tous les développeurs sont d’accord sur le fait que la documentation est importante, mais encore, il faut qu’elle soit bien écrite. Les développeurs se plaignent donc quand il n’y a pas de documentation. Et quand il y en a, ils se plaignent parfois du fait qu’il y a trop de documentation, ou de la façon dont les autres écrivent leur documentation. Mais quand ils doivent l’écrire eux-mêmes, ils le voient comme une corvée. Bref, les développeurs veulent une documentation bien écrite, précise, concise, mais personne ne veut l'écrire.

Les réunions : personne n’aime les réunions inutiles, fastidieuses ou longues, et ce n’est pas un problème seulement pour les développeurs.

Les collègues développeurs : travailler en équipe peut être parfois plus fastidieux que productif. D’abord parce que la force d’une chaine se mesure par son maillon le plus faible. Ainsi, des compétences limitées d’un développeur peuvent influer sur le travail du groupe. L’un des plus gros problèmes ici est de travailler avec un collègue qui n’a pas de rigueur en matière de qualité de code. Mais au-delà de cet aspect, on peut encore avoir travaillé avec un développeur avec un ego surdimensionné et qui n’est pas assez humble pour écouter les autres et reconnaitre ses erreurs. Un véritable problème de communication va s’installer avec des répercussions sur le travail du groupe.

Les gestionnaires de projet/produit : du point de vue technique, les développeurs ont en général une meilleure vision du produit qu’ils sont en train de développer, mais ils sont parfois supervisés par des gestionnaires de projet/produit qui essaient souvent de leur dire comment ils doivent travailler. Cela peut très souvent créer des frictions entre eux.

Le patron : tout comme les gestionnaires de projet/produit, les responsables de développement ou de l'ingénierie doivent diriger les activités des développeurs pour s'assurer que les projets sont terminés à temps et dans le budget. Cela peut être source de conflit, car dans certaines entreprises, l’on peut se trouver dans des situations où c’est un membre actif de l'équipe de développement, ou un développeur qui a été promu, qui doit jouer ce rôle.

Les ingénieurs QA (assurance qualité) : le QA est un élément essentiel dans le développement de logiciels. Dans les grandes équipes où les taches de développement sont séparées de celles de l’assurance qualité du produit, les ingénieurs QA peuvent devenir facilement la bête noire des développeurs. Sans prendre en compte les contraintes du projet et les obstacles auxquels les développeurs ont été confrontés, les ingénieurs QA n’hésitent pas à demander aux développeurs de revenir en arrière et retravailler sur certaines parties du code après que les programmeurs ont fini de développer le produit.

Les entretiens d’embauche : un entretien d’embauche peut être quelque chose de très agaçant pour un développeur surtout à cause des méthodes de sélection utilisées par les recruteurs. Questions stupides, résolution d’un problème technique de programmation qui pourrait ne jamais être rencontré dans le monde réel, voici parmi tant d’autres, des points qui ennuient les développeurs.

Les recruteurs de talents : les développeurs n'ont pas besoin d'être activement à la recherche d'un emploi pour être dérangés par les recruteurs. Dans un marché des talents serré, un autre métier RH a émergé ces dernières années : celui de recruteur ou chasseur de talents. Ces derniers visitent très souvent les sites des communautés de développeurs pour essayer de trouver des profils pour des clients. Et lorsqu’ils repèrent un profil prometteur, ils se lancent alors à sa conquête. Ils entrent en contact avec lui, appellent, envoient des emails, même si vous n’êtes pas à la recherche d’un emploi. Leur persistance est parfois très agaçante.

En ce qui vous concerne, nous voulons savoir, à travers ce sondage à choix multiples, quelles sont les choses qui vous agacent. N’hésitez pas non plus à partager vos expériences sur les différents points que vous choisirez.

Et vous ?

Qu’est-ce qui vous agace le plus en tant que développeurs ?
Partagez vos expériences

[heid]

Sans hésiter et pour toujours : Le proxy

[Invité]

Expliquer son métier de développeur au non initié en informatique

[el_slapper]

presque comme Heid : le réseau(ou le matériel en général) qui me pète à la gueule, toujours au mauvais moment, et qui me fait perdre des heures.

[Jarodd]

La plupart des points sont des contraintes du métier, pas forcément quelque chose de négatif. C'est comme se lever le matin, on aimerait faire sans mais c'est impossible

Dans le chapitre du patron ou du responsable, on peut peut-être ajouter ceux qui veulent toujours le dernier truc à la mode, même si ça n'apporte rien (à part des problèmes de perf parce que ce n'est pas fait pour notre usage) mais qu'il faut âââbsolument faire comme les autres ! (sans en avoir le budget ou les ressources)

Donc je vote pour le dernier point (le recruteur), car c'est celui qui est le plus perturbant dans la quotidien, et cause des pertes de temps et de concentration sans rien apporter de positif sur notre projet actuel. Les appels se font à toute heure de la journée, les recruteurs n'ont même pas la politesse de demander si on a quelques minutes à leur accorder (parce que mine de rien, à 11 ou 15h, je suis censé bosser et pas raconter mon cv pendant 30 mn), et ne prennent en considération que les besoins de leurs clients, et pas celui du développeur. Et la plupart appellent alors qu'ils n'ont rien de précis à proposer, juste pour avoir "le cv au format word" à jour, et même si on indique qu'on n'est pas "à l'écoute du marchay" sur les jobboards !

Et par dessus tout, ce qui m'insupporte c'est qu'ils ne connaissent pas le métier. Il confondent encore Java et Javascript, demande d'être sénior sur un framework qui vient juste de sortir, voire de tous les maîtriser (il n'a même pas assez de doigts pour compter le nombre de frameworkds Javascripts qui sont sortis cette année).

Et enfin, ils verrouillent le marché, impossible d'atteindre un client final sur un projet sympa sans passer par eux et leur grosse commission !

[JP CASSOU]

Ce qui me gonfle le plus:
- Développer pour des technologies peu fiables (Bluetooth), mal documentées ou obsolètes
- Batailler avec les paramètres de l'EDI et les pbs de dépendances au lieu de me concentrer sur le coeur de métier
- Le débogage des erreurs aléatoires

[Cincinnatus]

Quand les fonctionnels indiquent comment réaliser la solution à un problème, alors qu'ils ne sont pas fichus de préciser (comprendre ?) le problème qui, lui, est de leur ressort.

[hotcryx]

Ce qui est agaçant c'est d'être bloqué par d'autres informaticiens de la boite!

(pas tous mais un grand nombre par leurs postes, décisions...)

[GLDavid]

Allez j'y vais.
Les collègues développeurs. J'ai eu à gérer les egos surgonflés. Ah, les prima donna qui penses tout savoir et qui n'écoutent qu'eux ! Et en plus, incapables d'avouer qu'ils se trompent ou même de partager leurs connaissances (c'est vrai on est trop c..s pour certains).
Honnêtement, je préfère travailler avec quelqu'un d'un peu plus limité techniquement mais qui voudra s'aligner et faire des efforts plutôt qu'avec des gens qui ont un trop haute-estime d'eux-mêmes et qui ne sont connus... que d'eux-même.

@++

[Garvelienn]

Le "Directeur Technique Expert Docteur en Informatique" qui te dit à quoi bon utiliser un SGBD quand on peut le coder nous-même "en plus simple" pour une base de plusieurs milliers d'entrées et que les primary keys ne servent à rien. Véridique. Conséquence : il n'est plus mon patron.

Ça rejoint @GLDavid: les égos-surdimensionnés qui pensent tout savoir, experts en tout.

[lutecefalco]

Les salaires en province

[Florian_PB]

Expliquer le métier de dév à ma famille où il n'y a aucun féru d'informatique, les (très) nombreuses frictions avec mon chef de projet qui n'est pas programmeur (!!!), les clients convaincus que l'informatique consiste juste à sortir une baguette magique et pouf problème réglé, ces mêmes clients incapables de savoir ce qu'ils veulent, ceux qui changent le cahier des charges tous les deux jours, les patrons qui s'étonnent que le projet n'avance pas alors qu'ils donnent 15 milliards de trucs à faire en parallèle en "urgence" (et qui ne comprennent pas notre métier au passage).
Et la liste est encore longue...

[benjani13]

Dans l'ordre des éléments proposées:
- Les réunions : quand t'es convié à une réunion pour lequel tu n'as rien a apporter (pas assez de connaissance du sujet pour débattre). Et quand le débat est ponctué tous les 3 mots d'acronymes inconnus tu peux juste abandonner et réfléchir à ce que tu vas manger le soir.
- Les gestionnaires de projet/produit et patrons : qui sont très loin de la réalité des projets. Je ne parle pas des managers directes, qui subissent aussi cela, mais des personnes au dessus qui définissent la stratégie. Ces personnes ne sont souvent pas consciente de la réalité technique, parle dans des paradigmes qui n'ont rien à voir avec la réalité des produits, et imposent des choix technologiques au doigt mouillé et du jour au lendemain (je viens de découvrir cette techno, on va maintenant l'utiliser dans tous nos produits par ce que je suis un visionnaire et tant pis si la release et dans un mois). Je rajoute dans cette catégorie le marketing interne. Ce que j’entends par là est le fait de communiquer en interne sur le fait que nos produits sont les meilleurs, sont parfaitement réalisés, etc. Pour une communication externe c'est normale, c'est le jeu du marketing. Mais pour de l'interne c'est se voiler les yeux sur de nombreux problème, et c'est très déprimant pour les dévs qui eux voient au quotidien que la réalité est toute autre.
- Les entretiens d’embauche : Je pointe juste les entretiens RH qui ne servent, honnêtement des quelques entretiens que j'ai eu, à rien.

[el_slapper]

Expliquer le métier de dév à ma famille où il n'y a aucun féru d'informatique, les (très) nombreuses frictions avec mon chef de projet qui n'est pas programmeur (!!!), les clients convaincus que l'informatique consiste juste à sortir une baguette magique et pouf problème réglé, ces mêmes clients incapables de savoir ce qu'ils veulent, ceux qui changent le cahier des charges tous les deux jours, les patrons qui s'étonnent que le projet n'avance pas alors qu'ils donnent 15 milliards de trucs à faire en parallèle en "urgence" (et qui ne comprennent pas notre métier au passage).
Et la liste est encore longue...

J'ai trouvé très bien cet article en anglais qui décrit nôtre métier. Conclusion pour ceux qui n'ont pas une demi-heure à perdre : un programme est une suite sans fin d'un nombre gigantesque de décisions. Chaque ligne de code est elle même une, ou plusieurs décisions.

[Matthieu Vergne]

Les trolldi sur DVP. {^_^}

Comment ça, passer sur DVP n'est pas primordial pour un développeur ?

[el_slapper]

(.../...)
- Les entretiens d’embauche : Je pointe juste les entretiens RH qui ne servent, honnêtement des quelques entretiens que j'ai eu, à rien.

Résultat : dans ma boite, il n'y a pas d'entretien RH(et j'ai eu 7 entretiens avec 8 personnes avant d'entrer). Bon, la RH a un peu de mal à justifier son existence, et est un peu chiante à cause de ça, mais est-ce une catastrophe? Je n'ai pas l'impression.

[LSMetag]

Sans hésitation : les clients !

Que ce soit en prestation de service ou en mode forfait (où les devs leur parlent directement), ils ne savent pas ce qu'ils veulent, ne comprennent pas forcément leur fonctionnel, t'embêtent sur un bouton décallé d'1 pixel sans t'indiquer les vraies erreurs (sauf à la toute fin où il faut refondre), te rapportent des erreurs qui n'ont aucun lien avec ce que tu as développé (que tu n'arrives donc pas à débugguer) ou t'imposent parfois leur stratégie/modèle voué à l'échec.

Actuellement nous avons un gros client qui a rédigé un cahier des charge et payé pour un projet qu'il ne comprends pas. A chaque réunion hebdomadaire le besoin change ou ce qui est fait conformément au cahier des charges est remis en cause. Un projet qui aurait dû être terminé en 2 mois, n'a toujours pas eu de première version livrée en 2 ans. Heureusement qu'ils sont friqués ^^

[transgohan]

Ce qui m'agace du fait de ma façon d'être :
La documentation, car j'aime pas en faire... Je passe un temps fou devant la feuille blanche comme on dit et j'ai l'impression de perdre mon temps et de faire du copier/coller des commentaires mis dans le code.

Ce qui m'agace venant des autres :
Le réseau ! C'est un domaine que je n'aime pas depuis mes études, que je ne pratique pas (heureusement pour les autres), mais qui conditionne ma vie de développeur.
Passer 5h à faire une compilation parce que le serveur de fichier est lent... (au lieu de 30 minutes) C'est passer des journées à rien faire, car comme tout est en réseau en m'occupant à côté sur autre chose j'augmente d'autant plus le temps de compilation...

Avoir à faire des fiches d'essai pour justifier des exigences qui n'auraient jamais du être écrites au niveau système... Je fini souvent par écrire : "Vérifier que dans telle fonction on appelle telle fonction"... Vive la fiche d'essai qui ne sert à rien à part couvrir l'exigence...

Les Faits techniques mal détaillés qu'on arrive pas à reproduire, qui sont fermés / rouverts / fermés / rouverts trente six fois avant qu'on ait la bonne manipulation pour le reproduire et enfin comprendre qu'il y a un bug...

[TiranusKBX]

Bon voici la liste des choses qui m'exaspère le plus dans le métier et dans l'ordre du plus exaspérant au moins énervant

1. Le cahier des charges qui change tout le temps
2. Devoir régler les problème informatique(si il y en avait vraiment !) de mes collègues pas du métier(moyenne 1x/jour ouvrés)
3. Mon patron qui fait les tests la veille de la mise en prod(et le soir en plus) alors qu'il à eus une ou deux semaines pour le faire
4. les demandes pour le lendemain
5. Devoir relancer plusieurs fois les commerciaux pour qu'ils me donnent les infos restantes sur un projet

[Garvelienn]

les demandes pour hier