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

Du haut de mes deux ans d'apprentissage et de deux précédents stages (toujours dans la même boite), ce qui m'agace le plus c'est clairement les clients ! J'ai toujours développé pour des clients internes mais c'est souvent la même histoire à savoir :
- Pourquoi on change alors que ça marche (alors qu'ils utilisent Excel, c'est à dire des fichiers qui partent dans tous les sens avec des doublons et un nombre incroyable d'erreurs)
- ce dialogue qui revient souvent :
(client) - Tu pourrais créer cette fonctionnalité ?
(moi) - Regardez, elle existe déjà (montre la fonctionnalité en trois clics)
(client) - Ah oui mais non, je voudrais qu'elle la fasse en deux clics !

Alors que son précédent outil ne proposait même pas cette fonctionnalité !

Après niveau collègues développeurs, patron ou réunions j'ai pas du tout à me plaindre (sans doute parce qu'en tant qu'apprenti je ne suis convié à beaucoup de réunion et que les développements sont pour des clients internes (souvent des collègues donc))

ce qui m'agace le plus c'est la période de recrutement/les entretiens d'embauche

Travailler en relation directe avec le client peut effectivement être agaçant. C’est même un métier en soit.

Tu peut améliorer ces points par pleins de biais différent :

- Montrer de l’empathie à son problème. C’est fondamentale que le client comprenne que tu n’en pas «rien à cirer» de son problème / ses remarques / son métier. Après chaque point tu peut-même lister les remarques qu’il a faite pour récapituler, par un mail etc qui stipulera que ce qu’il a dit a été entendu. Après, il n’est pas possible d’arbitrer sur ce qui doit être fait.

- «Accueillez positivement les changements de besoins, même tard dans le projet. Les processus agiles exploitent le changement pour donner un avantage compétitif au client.»
C’est le deuxième principe agile du manifeste agile https://www.wikiwand.com/fr/Manifeste_agile et je le répète souvent à mes collègues les plus désabusés.

- Expliquer le contexte interne. «Ce sujet est noté, néanmoins il faut comprendre que nous travaillons en priorité sur tel ou tel sujet et cætera… Parce qu’il vont vous donner un avantage ici ou là…».

- Faire fréquemment un listing des remarques de ton client à tes responsables avec une catégorisation :*Il est peut-être le temps de songer à revoir complètement la démarche ergonomique si votre client est éternellement insatisfait de vos évolutions.

La démarche érgonomique c’est compliqué, ça veut dire parfois revoir l’organisation interne de la société sur les taches de tout un chacun. Par exemple, si c’est un profil marketing, ou un technicien, ou un power-user (qui ne connait pas la cible du projet) qui fait seul les maquettes, alors on court à la catastrophe. Il faut impliquer les différents membres afin de concevoir un projet qui soit ergonomique.

D’ailleurs peut-être que c’est vos clients qui devraient avec vous convenir des besoins fonctionnels et scénarios d’usage de votre application (si vous travaillez en agile). Peut-être que ton responsable pourra débloquer des ressources pour améliorer les points qui pêchent après les avoir eu sous les yeux! Par exemple la dette technique, votre méthode de spécification, votre organisation, vos éxigences techniques et vos normes.

Pour ma part je réalise tout un listing-feedback au cours d’un sprint (Agile inside :p) et j’en parle à la rétrospéctive de sprint toutes les deux semaines. Cela peut-être fait aussi dans un projet non agile j’imagine.

Bon courage!;)

Citation:

---

Envoyé par lutecefalco

Les salaires en province :aie:

---

Dans la situation actuelle c'est tellement galère de trouver un boulot que quand tu réussis enfin à signer un contrat, tu ne peux pas te plaindre du salaire.

Normalement en province les dépendances sont moindre que dans les grandes villes, donc ça devrait s'équilibrer.

Servir les outils plutôt que de m'en servir : Comment on configure le chemin du repo Maven, déjà ? Pourquoi Eclipse ne trouve pas mon JDK ? Pourquoi Git s'obstine à refuser mon commit ? J'ai du mal à supporter ce genre de chose. Et j'ai toujours l'impression que les outils pour développeur ont un côté brut de fonderie que les utilisateurs finaux n'accepteraient jamais. Même si ça s'est enfin amélioré ces dernières années.

Citation:

---

Envoyé par thierrybenji

Dans la situation actuelle c'est tellement galère de trouver un boulot que quand tu réussis enfin à signer un contrat, tu ne peux pas te plaindre du salaire.

Normalement en province les dépendances sont moindre que dans les grandes villes, donc ça devrait s'équilibrer.

---

La bonne blague..... tu es sérieux?

En tout cas pour les développeur/architectes .Net c'est complètement l'inverse

Je dois recevoir 6 ou 7 appel par semaine pour savoir si je suis en recherche (alors que je ne le suis pas).
Concernant les salaires c'est juste affligeant, les gens expérimenté pour arriver au salaire qu'ils méritent sont obligés de se mettre freelance (c'est devenu une généralité dans mon entourage).

Mais même en tant que freelance, les TJM sont divisés par 2 sur la province par rapport à la région parisienne, c'est juste une abbération, quand tu habite comme moi dans le sud (vers Aix) la vie est tout aussi chère que sur Paris, et on encore moins de facilités concernant les transports.

Le pire étant que la demande est forte, il y a peu de développeur expérimenté, mais les SSII/client ne veulent pas payer, ou continuer a faire leur 50% de marge sur ton dos (pour les SSII)




Pour revenir au sujet principal, d'une manière générale je dirais les chefs/patrons qui pour la plupart sont complètement à la masse concernant la problématique du développement informatique.
Et les recruteurs car effectivement on est constamment dérangé par des appels en pleins milieu de la journée.

Citation:

---

Envoyé par worm83

La bonne blague..... tu es sérieux?

---

Ben en tout cas moi j'ai eu énormément de mal à trouver mon premier boulot en tant que développeur.
Mais j'avais pas trop de mal à trouver des entretiens d'embauches.
Et les recruteurs continuent de m’appeler alors que ça doit faire un an que mon CV n'a pas été mit à jour sur le site de l'APEC.
Je devais juste être très nul en entretien d'embauche...

J'ai eu beaucoup d'offres pour la région parisienne, j'ai toujours dis NON directement.
Pour moi ce serait impossible d'aller bosser là-bas...

hha la bonne vieille blague des coûts différents entre Paris et la province... :roll:

Ayant quitté Paris, je peux dire que c'est que de la foutaise de recruteur pour faire baisser ton salaire. Car les coûts que tu perds, tu les retrouves dans d'autres domaines (metro (-cher) -> voiture (+cher), nourriture (kiff-kiff), loyers (+chers) -> loyers(-chers), etc). Ça s'équilibre et tu as légèrement l'impression qu'on s'est foutu ta g... à l'embauche :aie:

Alors le premier emploi peut effectivement être un soucis, j'ai eu moi aussi du mal (période de la crise 2007).

Mais le problème de salaire est pour ma part un soucis de "senior", quand tu es débutant la je te rejoint tu prends le premier truc qui viens même si t'es payé une misère.

Citation:

---

Envoyé par thierrybenji

(.../...)Et les recruteurs continuent de m’appeler alors que ça doit faire un an que mon CV n'a pas été mit à jour sur le site de l'APEC.
Je devais juste être très nul en entretien d'embauche...(.../...)

---

C'est une compétence qui se travaille - encore faut-il avoir de bons "professeurs". Quand j'ai changé de SSII en 2007, ma nouvelle boit m'a entrainé deux jours pleins à passer des entretiens. Tous les commerciaux de l'étage y sont passés. Je suis maintenant meilleur que la moyenne. Sans aucun mérite : j'ai juste eu la chance d'être bien formé.

Après ça, j'ai vu des gens en intercontrat refuser de s'entrainer avec des commerciaux avant des entretiens. Ca m'a paru aberrant. Le jour ou j'ai quitté cette crémerie, ce qu'ils m'ont appris a été TRES utile pour passer les entretiens. Non seulement c'est une compétence qui se travaille, mais surtout, c'est une compétence très utile à chaque mouvement de carrière. Je ne sais pas si tu est en SSII, mais si tu est dans une SSII sérieuse, avant chaque nouvelle mission, pleure pour avoir un entrainement aux entretiens. Ca te servira le jour ou tu devras les planter. Oui, oui, je suis cynique. Je les ai exploité. Mais eux aussi, alors on est quitte.

1. mes propres limitations
2. avoir des contraintes sans avoir les moyens
3. les attitudes négatives, avec lesquelles on progresse moins/pas

---

Les choix présentés correspondent bien à ce que je pensais en tant que junior.
C'est vraiment un manque de vision sur l'ensemble :
* qui n'aime pas les réunions ou le patron, n'a pas compris SOIT l'utilité SOIT comment convaincre. Ça s'apprend
* qui n'aime pas les QA, les bugs ou les collègues est souvent remis à sa place parce qu'il a raté un truc. Ça arrive, ça s'évite.

Depuis qu'on apprend le code, on est remis à notre place : on a mal codé, on a oublié un cas, on a mal lu la doc, mal testé, oublié un point virgule...
Pendant des années d'école et de carrière on apprend que ce n'est pas une fatalité, qu'on peut s'améliorer. Alors faisons-le.

---

Le plus symptômatique pour moi c'est la doc. Mais mettons-nous à la place des autres :
on s'enrage quand les outils qu'on achète et les libs qu'on utilise sont mal documentées.

Pourquoi détester la doc ? Je suis heureux d'être développeur car mes "superpouvoirs" aident des gens.
Sans manuel, ça ne les aide pas, pire ça les frustre ou les coince ou leur fait faire des bêtises !
Donnez un couteau à un enfant sans expliquer à quoi ça sert, mais que ça coupe et comment s'en servir, vous ne l'avez pas aidé loin de là.

Bref, sans écrire de la doc, mon travail et mes compétences sont inutiles, je suis inutile voire malfaisant.
Là encore on peut s'améliorer : meilleurs noms de variables, meilleurs libellés, messages d'erreur informatifs, reprise sur erreur...
C'est tout simplement de l'UX (Expérience Utilisateur) !

---

Pour moi le plus grand danger de l'informatique, c'est d'avoir des contraintes sans avoir des moyens.

Vous savez qu'il faut agir et vous ne le faites pas.
Vous voulez la qualité mais vous n'avez pas le temps.
Vous voulez le temps mais vous n'avez pas l'argent pour ça.
Vous voulez aider les utilisateurs mais vous ne les rencontrez pas.
Vous voulez une équipe de qualité mais vous ne savez/pouvez pas les recruter/attirer/garder.
Vous voulez que le projet soit un succès mais vous n'avez que les on-dit de quelqu'un et vous ne savez pas qui évaluera le succès et comment.

Il y a toujours quelqu'un qui édicte les règles, et qui n'a pas pensé que c'était incohérent voire anti productif.
Ce n'est même pas sa faute ! Je lui pardonne aussi ! Mais il faut pouvoir l'identifier, le dire, et changer la règle si nécessaire.

---

Et enfin, si vous avez une attitude négative... vous passerez à côté de tout cela, et vous préférerez dire "la doc c'est chiant" que "je veux gagner ma vie en profitant de mes superpouvoirs durement acquis, pour aider les gens à gagner des superpouvoirs facilement".

Il me semble qu'aujourd'hui au lieu d'écrire des commentaire ont peut écrire des tests unitaires.
En regardant le scénario, les mocks et tout ça, on comprend ce que la méthode reçoit, ce qu'elle retourne et comment l'utiliser.
L’intérêt c'est que les tests doivent toujours être vrai, du coup si on modifie la méthode et que le test devient faux, il faut faire quelque chose pour que ce soit juste.

Si t'écris une méthode et que tu la commentes, le jour où tu l'as modifie t'oublieras peut être de mettre à jour le commentaire.

Écrire une doc est important, comme ça d'autres personnes pourront comprendre rapidement et correctement comment le code fonctionne.
Mais par contre c'est très dur et très chiant.

En tant que prestataire externe, quand j'arrive chez un client :
- pas de bureau disponible
- pour des raisons de sécurité les machine externes ne peuvent être connectées au réseau interne
- pas de machine disponible
- finalement on me fourni un windows XP avec 2Go de ram pour développer une application web liée à une base de données :aie:

Sinon il y a aussi le chiffrage de projet:
Paul à 17h30: tiens voilà une doc de 126 pages, envoie moi le chiffrage pour la réunion de demain matin 9h
Moi: demain matin 9h de quelle année?... :ptdr:

Paul: Ton chiffrage est trop élevé, je divise tout par 3
:weird:

Citation:

---

Envoyé par shenron666

(.../...)
- finalement on me fourni un windows XP avec 2Go de ram pour développer une application web liée à une base de données :aie:

---

vécu.

Bon, pour faire du COBOL sur un émulateur de terminal, un P133 suffit largement(j'ai testé). Par contre, quand on commence à devoir faire des analyses de données préliminaires sur EXCEL, c'est très, très vite limité. Quand on compare le prix de la babasse et le prix du consultant, on se dit qu'il y a des priorités bizarres, quand même :aie:

Citation:

---

Envoyé par shenron666

Sinon il y a aussi le chiffrage de projet:
Paul à 17h30: tiens voilà une doc de 126 pages, envoie moi le chiffrage pour la réunion de demain matin 9h
Moi: demain matin 9h de quelle année?... :ptdr:

---

vécu aussi. Le truc improbable, c'est qu'on a dépassé que de 6%, sur les 120 jours que j'avais balançé au pif.

Citation:

---

Envoyé par shenron666

Paul: Ton chiffrage est trop élevé, je divise tout par 3
:weird:

---

Vécu par l'équipe avant nous, sur une mission. Ils ont tenu les délais quand même. Chapeau. Par contre, ils n'ont pas eu le temps de faire les choses bien : aucune doc, aucune normalisation, et surtout aucun traitement d'erreur un peu propre. Tant que l'alimentation en amont était maitrisée, ça faisait illusion. Puis des gens qui ne savaient pas ont décidé d'opter pour une alimentation moderne, fournie par un prestataire extérieur, qui ignorait tout, fatalement, des petites subtilités planquées à droite à gauche et qui faisaient que tout n'explosait pas.

Je suis arrivé en maintenance dans cette équipe, il n'y avait plus de sachant sur ce sujet, et un soir, sans signe avant-coureur, on m'a dit, "est-ce que tu peux rester un peu plus ce soir? C'est juste pour être sur - mais on a tout testé, ça devrait bien se passer". Je ne savais même pas, deux heures avant la catastrophe, qu'il y avait aussi du marketing dans le périmètre de l'équipe. Eh bien j'ai consommé an maintenance bien plus que les 2/3 du projet économisé auparavant. Sans compter l'exploitation, que j'ai dû martyriser à de nombreuses reprises, ni l'équipe cliente, qui s'est demandée pourquoi soudain elle devait faire plein d'heures sup.

Citation:

---

Envoyé par Jarodd

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 ! :evilred:

---

Un gros +1.

Là où je pense que vous faites faux bon, abréger la conversation et si le poste est intéressant, il est temps de s'augmenter.... Donc sa com, il faut la réduire.... Vous êtes ni plus ni moins une vache à lait pour lui.

Perso, j'ai voté correction de bug (application codée par un tiers. Si ce sont vos bugs, il faut s'en prendre qu'à soi même). C'est parfois une horreur de reprendre une application écrite par un tiers ! base de données très mal modélisée + poo four tout/bordel/n'importe nawak.

Le plus important pour moi reste les conditions de travail. Hauteur des tables, qualité des chaises, clim, écran etc. Tous ces éléments de confort fort essentiels pour moi et que les autres techniciens de la boite (on est pas une boite essentiellement informatique) ne comptent pas.
Ah j'oubliais, partagé un bureau avec des commerciaux. Ca créé une bonne ambiance mais parfois c'est assez dérangeant de les écouter gérer tous leurs appels.

Je sais, c'est l'inconvénient d'être en fixe dans une boîte, et de ne pas facturer les dev.
Dans une boîte qui met sur un piédestal "l'amélioration continue", on passe notre temps à développer des trucs d'une autre manière, juste pour voir si la présentation finale sera pas meilleure... Finalement on garde la version d'avant.
Une industrie qui est rachetée tous les 2 ans par un nouveau fond de pension. A chaque fois on part dans des développements de nouveaux indicateurs... qui seront abandonnés l'année suivante.
L'humeur des dirigeants (chefs de secteurs, de site, resp. des achats, directeur de production, ...) qui veulent se faire mousser ou se faire repérer. Il faut développer des indicateurs avec plein de couleurs à rendre dingue un caméléon, et c'est l'escalade, chacun veut son truc... qui servira 5 mois.
Quand ça vient du client, on ne dit rien ; mais quand ça vient d'un chefaillon, on rage !

Le code non documenté et qui se trouve intégralement dans la même méthode.
On pourrait croire que ce sont des manières de débutants, mais pas forcément.

Quand vous repasser derrière ça, pardon...

Citation:

---

Envoyé par Excellion

Le code non documenté et qui se trouve intégralement dans la même méthode.

---

Si il y avait un test unitaire avec les mocks et tout ça, ce serait plus clair, on verrait ce qui entre et ce qui sort.

Citation:

---

Envoyé par thierrybenji

Si il y avait un test unitaire avec les mocks et tout ça, ce serait plus clair, on verrait ce qui entre et ce qui sort.

---

Non ça aide pas forcement...
Quand tu as une machine heure qui gère des recalage très précis et que ses fonctions de recalage font appel à trois horloges différentes et font plus de 400 lignes sans aucun commentaire... (je suis sûr d'en avoir perdu déjà la moitié rien qu'avec le détail, alors parlons pas du code... :aie:)
Tu t'en fous un peu de savoir ce qui rentre et ce qui sort quand ça fonctionne pas dans un cas précis...
Ce que tu veux savoir c'est : bordel... Mais qu'est ce qu'elle fait dedans ?????