Discussion :

[jacjac]

Salut à tous !

Ça fait 6 ans maintenant que je dév, au moins autant de boites en tant que salarié au compteur, et le constat est le suivant : Ce métier est beaucoup trop exigeant et trop frustrant.

J'en ai marre de ces projets mal encadrés, avec des produits qui partent en usine à gaz, que ce soit les dévs qui gèrent les features du produit tandis que le PO n'est pas capable de pondre une seule US / Spec... Bah ouais, c'est ça l'agile !
J'en ai marre que le PO comprenne pas que j'en ai marre de faire la girouette pour des idées qui n'ont rien a voir avec le produit d'origine... Bah ouais, c'est ça l'agile !
J'en ai marre de faire des tests qui me semble de plus en plus inutiles, de paramétrer des environnements, de me confronter à des bugs d'infra non stop (auth, database, cloud, etc.). Bah ouais c'est ça être Dev Fullstack !
J'en ai marre de la communauté de plus en plus toxique des dévs. Entre le gars qui a toujours un feedback même quand tu demandes rien, celui qui rabaisse les autres en live, le développeur rockstar élite ++, etc.

En bref, j'en ai marre de devoir avoir la force de frappe d'une bombe nucléaire pour tuer une mouche quoi...
Trop de bullshit, trop d'élitisme, trop de boulots qui ne sont pas dans ma fiche de poste, tout ça pour trop peu de concret et de résultats... Si peu satisfaisant...
Des fois je préfèrerais gagner moins pour me sentir plus utile et plus fier de ce que je fais... Genre, caissier dans un supermarché quoi par exemple...

Des gens ont ce même constat ? 

[gangsoleil]

Bonjour,

On sent bien que tu es au bout du rouleau. Je pourrai t'expliquer que Agile/Devops/Fullstack ne sont pas le problème, que tu as rencontré de mauvaises implémentations/utilisations, mais ça ne servirait à rien.

Je vois plusieurs solutions :
1. Consulte un médecin, explique-lui ta situation. Certains éléments font penser au burn-out, mais je ne suis pas médecin donc je ne sais pas ce qu'il en est.

2. As-tu pensé à changer de de boite ou de poste -- ou les 2 bien sûr.
Travailles-tu en SSII ? car 6 boites en 6 ans, ça semble beaucoup (mais je ne connais pas ta situation). Si c'est le cas, pourquoi ne pas regarder hors SSII ?
Pour le poste, as-tu pensé à évoluer vers de l'architecture, du management de projet, expertise technique, ... ?

[Glutinus]

Hello,

Des gens ont ce même constat ?

Oui, plus que jamais, je pense qu'un message sur 5 de ma part sur DVP parle du grand nainwak, de Business Analysts qui comprennent souvent le métier encore moins que moi, que les chefs de projet pensent qu'il n'y a pas que les devs (et la spec / dossier de transfert / test, on verra ça en prod), qu'il y a 1001 profils toxiques.

Je sais pas la place de l'Agile dedans, j'ai l'impression que, lorsque mal maitrisé, les mauvais côtés sont amplifiés.

Spoiler Alert : les méthodes agiles sont censées mettre en avant les bonnes pratiques mais surtout le bon sens, la logique, le concret, le simple (au lieu de livrer en prod tout dans 3 ans et en attendant ceux qui ont rédigé les specs ont été promu ou ont changé de mission, si on livrait le plus rapidement pour que le client puisse faire ses retours ?). Au lieu de cela, comme on a toujours réussi à le faire, les vendeurs de vent ont réussi à rajouter une couche supplémentaire ou y placer leurs parasites, leurs incompétents et leurs placardisés.

Comme dit gangsoleil, la première idée serait peut-être de changer de structure. Des projets en V qui fonctionnent, ça marche (bon , je suis en train d'en faire un, mais je dois avoir 10 jours de dev et tests à peine, c'est un très petit module, mais je sais que ça va bien se passer). L'agile n'est pas la panacée.

Et le mieux, l'idéal, c'est de prendre du recul. Moi je m'en fiche, les autres prennent leurs décisions, moi je défends mes fesses, je préviens qu'il faut prendre un lance-roquettes pour tuer une mouche, comme tu dis, et je l'écris en gros dans un mail. S'ils préfèrent les enc*ler justement, les mouches, c'est leurs problèmes, moi je suis couvert

[jacjac]

J'ai bossé dans une startup, 2 ESN, 2 PME et 1 grosse boite, toujours en tant que salarié.
J'ai eu une expérience en agile plutôt sympa (avec un projet bien organisé et tout), bon il manquait le salaire... (26k € annuel brut pour 2 ans d'xp)
Mais pour le reste de mes expériences, c'est beaucoup de bullshit, déployer des moyens overkill ...
(ex: équipe de 10 personnes, infra tentaculaire, stack et garantie de qualité de haut level, pour faire tourner un simple formulaire utilisé par 30 personnes en interne, vous voyez le tableau ?)

C'est juste que plus j'avance dans le temps, plus le métier de développeur devient complexe pour moi... Pourtant je fais de plus en plus de veille techno...
Mais j'ai surtout un sentiment de régression dans mon utilité au quotidien...

Je pense que la flamme de la passion s'est éteinte, et je réalise seulement dans quoi je me suis embarqué

[Derek Corgan]

Bonsoir,

T'es victime de la dérive malsaine des méthodes agiles. Cumul excessif de sprint. Pause obligatoire.

Les méthodes agiles cela peut être bien. Mal utilisées c'est une cata sur les entreprises et les gens. cf https://binnie.medium.com/pourquoi-a...s-3d699aa67a33

Pour moi le principale cause du problème : une métho/pratique issue des ingénieurs logiciels mais détournées par le business.

[Glutinus]

Un lien très très intéressant que tu nous as fourni là Derek Corgan.
Merki !

[el_slapper]

Les méthodes agiles cela peut être bien. Mal utilisées c'est une cata sur les entreprises et les gens. cf https://binnie.medium.com/pourquoi-a...s-3d699aa67a33

(0) J'adore quand je vote up un post, et que le compteur monte de deux. Ca veut dire que quelqu'un d'autre, dans le monde, a eu la même idée que moi au même moment.

(1) J'adore ton lien, je me le garde précieusement. Un grand merci.

EDIT :

Il est bien connu que les créatifs perdent toute créativité lorsqu’on leur demande de s’expliquer pendant qu’ils travaillent.

ça, ça me parle terriblement.

[ed73170]

C'est juste que plus j'avance dans le temps, plus le métier de développeur devient complexe pour moi... Pourtant je fais de plus en plus de veille techno...
Mais j'ai surtout un sentiment de régression dans mon utilité au quotidien...

Bonjour,

Développeur depuis 1987, j'ai arrêté il y a 6 mois, à 3 ans et demi de la retraite, et je ne reprendrai pas de mission. Ce qui m'a le plus dérangé pendant mes dernières années de pratique ce ne sont pas forcément les méthodes agiles appliquées n'importe comment, les stand up meetings où tout le monde passe son temps à regarder si l'aiguille des secondes de la pendule est bien synchronisée avec celle des minutes (du vécu sur ma dernière mission) sans écouter ce que disent les autres car on s'en fout complètement.

Là où j'ai vu une nette dégradation de l'intérêt de ce qu'on nous fait faire et des conditions de travail, c'est à l'apparition des outils comme Jira ou TFS qui découpent tout en tâches unitaires pour lesquelles les développeurs peuvent être interchangeables et remplaçables à volonté. Le résultat est effectivement qu'on ne comprend plus la finalité de ce qui est demandé et qu'on ne s'implique plus. Par exemple, pour un bug à corriger, je m'arrangeais pour que ça passe les tests sans me préoccuper des éventuelles régressions, ce que d'ailleurs on ne me demandait pas, le testeur validait, et si quelque temps après il s'apercevait d'une régression il créait un nouveau bug dans TFS et le chef l'affectait à n'importe qui d'autre, plus ou moins au hasard. Inutile de préciser que ce mode de fonctionnement entraîne des usines à gaz très difficilement maintenables.

En résumé, si maintenant un jeune me demande conseil pour exercer le métier de développeur, je lui dis de s'orienter ailleurs.

[Glutinus]

Développeur depuis 1987, j'ai arrêté il y a 6 mois, à 3 ans et demi de la retraite, et je ne reprendrai pas de mission. Ce qui m'a le plus dérangé pendant mes dernières années de pratique ce ne sont pas forcément les méthodes agiles appliquées n'importe comment, les stand up meetings où tout le monde passe son temps à regarder si l'aiguille des secondes de la pendule est bien synchronisée avec celle des minutes (du vécu sur ma dernière mission) sans écouter ce que disent les autres car on s'en fout complètement.

Anecdote, lors de mon premier stand-up meeting, je rentre dans la salle de meeting (à ce que j'ai compris, l'idéal c'est de le faire carrément à la machine à café ou dans le couloir histoire que ça dure le moins longtemps possible)... et là je retrouve tout le monde assis, et on me demande :
- Tu ne t'assieds pas ?
- Heu, c'est pas censé être un stand-up meeting ?
- Non, on l'a renommé "Morning Meeting", mais ne t'inquiète pas, ça ne dure pas plus de dix minutes...
Au bout de deux mois, il durait toujours plus de 75 minutes...

Là où j'ai vu une nette dégradation de l'intérêt de ce qu'on nous fait faire et des conditions de travail, c'est à l'apparition des outils comme Jira ou TFS qui découpent tout en tâches unitaires pour lesquelles les développeurs peuvent être interchangeables et remplaçables à volonté. Le résultat est effectivement qu'on ne comprend plus la finalité de ce qui est demandé et qu'on ne s'implique plus. Par exemple, pour un bug à corriger, je m'arrangeais pour que ça passe les tests sans me préoccuper des éventuelles régressions, ce que d'ailleurs on ne me demandait pas, le testeur validait, et si quelque temps après il s'apercevait d'une régression il créait un nouveau bug dans TFS et le chef l'affectait à n'importe qui d'autre, plus ou moins au hasard. Inutile de préciser que ce mode de fonctionnement entraîne des usines à gaz très difficilement maintenables.

Au moins ça permet de tracer, j'avais des utilisateurs qui arrêtaient pas de nous descendre pendant des comités mais quand je leur demandais "vous avez ouvert quand le ticket" c'était que des grommellements... ils passaient leurs temps à esquiver les validations, on ratait les échéances de mise en prod (à l'ancienne, deux fois par an...) et après ils venaient gueuler. Je prenais les devants : je vais les voir dans leurs bureaux, et ils me disent "oui oui on a testé on valide" alors que j'étais venu leur indiquer qu'on avait changé le système d'authentification et apporter leur nouveau mot de passe...

C'était horrible parce que le ticket JIRA restait chez moi et on se prenait des alertes parce que ça restait en rouge, mais personne ne voulait valider etc. ça a failli coûter ma place (bon, en tant que presta, mais ça la fout pas au moral alors que ton dev il est prêt depuis des semaines...)

En résumé, si maintenant un jeune me demande conseil pour exercer le métier de développeur, je lui dis de s'orienter ailleurs.

J'essaie un peu plus de nuancer. J'explique que les compétences techniques sont minimes, devant les difficultés d'organisation voire les comportements toxiques de certains. Qu'il va surtout falloir gérer des gens, des comportements, et des situations. mais bon, en général les juniors prennent en note "organisé, persistant, affinité technique" sur leur bloc-notes...

[eclesia]

J'ai bossé dans une startup, 2 ESN, 2 PME et 1 grosse boite, toujours en tant que salarié.
J'ai eu une expérience en agile plutôt sympa (avec un projet bien organisé et tout), bon il manquait le salaire... (26k € annuel brut pour 2 ans d'xp)

J'ai commencé à 20K il y a 13 ans, 26K€ c'est deja bien pour seulement 2ans, il ne faut pas réver, la vrai valeur d'un dev ce n'est pas à l'école qu'on l'aquiere.
Le diplome ne fait pas le salaire.

Toujours dans la meme boite depuis mes débuts et plutot que de passer chef de projet (j'ai décliné l'offre), je suis passé en télétravail complet à la campagne (c'etait avant le covid) et je fais quelques formations chez les clients en plus d'etre responsable de certaines de nos libraires .
Je ne peux que le conseiller pour ceux qui savent travailler sérieusement 7h par jour en étant seul, pour les autres mieux vaut continuer d'aller au boulot.

Mais pour le reste de mes expériences, c'est beaucoup de bullshit, déployer des moyens overkill ...
(ex: équipe de 10 personnes, infra tentaculaire, stack et garantie de qualité de haut level, pour faire tourner un simple formulaire utilisé par 30 personnes en interne, vous voyez le tableau ?)

Je constate la meme chose, docker, kubernetes, tomcat, spring, jvm, angular ... des couches sur des couches partout. et ca ne va pas en s'améliorant ...


Voici mes conseils :

1) Cherche la stabilité, spécialise toi
= moins d'outils
= moins de souffrance à cause des effets de buzz des nouvelles technos
= des taches qui auront une certaines routines, donc possibilités de capitaliser, d'améliorer les librairies plutot que d'en changer tout le temps
= fuis les technos Web, fuis l'administration serveur, les technos Back-end sont plus stables

2) Ne néglige pas ta vie, ton cadre de travail doit te plaire : maison, région, climat et pas que le lieu de travail
= on réfléchi mieux quand on n'a pas d'autres éléments de stress
= quand tous le reste se passe bien on se concentre bien plus facilement, et on arrive souvent à résoudre des problèmes impossibles
= on est plus diplomate, ce qui permet de mieux communiquer son opinion et d'influencer la direction de la boite et des choix

[GreatDeveloperOnizuka]

Salut à tous !

Ça fait 6 ans maintenant que je dév, au moins autant de boites en tant que salarié au compteur, et le constat est le suivant : Ce métier est beaucoup trop exigeant et trop frustrant.

J'en ai marre de ces projets mal encadrés, avec des produits qui partent en usine à gaz, que ce soit les dévs qui gèrent les features du produit tandis que le PO n'est pas capable de pondre une seule US / Spec... Bah ouais, c'est ça l'agile !
J'en ai marre que le PO comprenne pas que j'en ai marre de faire la girouette pour des idées qui n'ont rien a voir avec le produit d'origine... Bah ouais, c'est ça l'agile !
J'en ai marre de faire des tests qui me semble de plus en plus inutiles, de paramétrer des environnements, de me confronter à des bugs d'infra non stop (auth, database, cloud, etc...). Bah ouais c'est ça être Dev Fullstack !
J'en ai marre de la communauté de plus en plus toxique des dévs. Entre le gars qui a toujours un feedback même quand tu demande rien, celui qui rabaisse les autres en live, le développeur rockstar élite ++, etc...

En bref, j'en ai marre de devoir avoir la force de frappe d'une bombe nucléaire pour tuer une mouche quoi...
Trop de bullshit, trop d'élitisme, trop de boulots qui ne sont pas dans ma fiche de poste, tout ça pour trop peu de concret et de résultats... Si peu satisfaisant...
Des fois je préfèrerait gagner moins pour me sentir plus utile et plus fier de ce que je fait... Genre, caissier dans un supermarché quoi par exemple...

Des gens ont ce même constat ?

Ton message me touche . Dans mon service c'est plus ou moins la même chose et j'ai dit stop j'en ai marre, je démissionne et du coup on m'a passé chef de projet hier pour pouvoir remettre de l'ordre dans ce service. J'attends donc la réunion pour finaliser mon avenant de contrat. Par contre, je ne pourrais quasiment plus coder donc ça me fait un peu chier . Donc je leur ai expliqué que l'avantage d'avoir moi en tampon sur l'équipe de dév par rapport à un bullshiter qui ne s'y connait pas en informatique, est que je peux comprendre les problématiques techniques. Comme ça fait + 4 ans que je bosse ici, je connais assez bien le métier du coup et donc je peux voir où sont les problèmes.

Bref, pour moi un des principes si on veut que ça marche dans ce que j'ai vu dans ma carrière est que le PO doit avoir un passé de dév sénior pour réussir à avoir assez de reculs pour faire ce job. Ceux qui n'étaient pas sénior et qui ont été PO ou autres postes pour encadrer le projet, sont ceux avec une très grande expertise métier et qui sont passés par exemple par la case dev mais pas trop avancé.

[Invité]

J'avais le même ressenti il y a quelques années. Et puis, j'ai quitté la Région Parisienne. Les conditions de travail ne sont pas forcement meilleures, mais au moins les collègues sont moins cons et puis il y a la mer.

[Madmac]

Développeur en entreprise, vous aussi vous êtes au bout du rouleau ?
Méthodes agiles mal appliquées ? management irresponsable ? Scrum une vaste blaque ? quelles sont les causes ?

Le fond du problème est que les méthodes agiles et Scrum sont totalement inutile si le cahier de charge n'est pas précis. Et le cahier de charge n'est jamais précis parce que le client ne sait pas exactement ce qu'il veut et ce qu'il est prêt à payer. Tant que l'utilisation de prototype ne sera pas la norme, les conditions de production seront toujours bordélique.

C'est pourtant simple à comprendre tant que les besoins ne sont précisément définis, il est impossible de déterminé le type de base de donnée qui sera le mieux adapter pour le travail. Pour du web ce n'est pas qu'un petit détail ...

Petite parenthèse: Agile est mort

[Invité]

Bonsoir,

Des gens ont ce même constat ?

Je taff depuis 2013 (data analyste), je suis passé dans plusieurs secteurs d'activités. De ce que je constate :

> de plus en un plus de sachants et dirigeants ( un gestion pyramidale)
> les sachants et dirigeants brassent de plus en plus de vent pour mettre du vert dans une cellule de tableau (futile et superficiel)
> de moins en moins de techniques
> les rares techniques deviennent des pisseurs de codes
> les tenants et aboutissants des process sont de plus mal maitrisés (absence de connaissances de la chaine de valeur/traitement , qui génère une piètre qualité de la donnée , voire on stocke de la merde ... )
> une forme de flicage envers le bon sens , qui se perd au passage (quand cela ne va pas dans le sens du manager , ou qu'une procédure tordue est "contournée" pour remettre au carré ce qui foire ... )
> une manque de communication et de plus en plus de personne qui travaillent en mode "sous marin", de peur de se faire fliquer sur le taff

[SG2694]

> de plus en un plus de sachants et dirigeants ( un gestion pyramidale)
> les sachants et dirigeants brassent de plus en plus de vent pour mettre du vert dans une cellule de tableau (futile et superficiel)
> de moins en moins de techniques
> les rares techniques deviennent des pisseurs de codes
> les tenants et aboutissants des process sont de plus mal maitrisés (absence de connaissances de la chaine de valeur/traitement , qui génère une piètre qualité de la donnée , voire on stocke de la merde ... )
> une forme de flicage envers le bon sens , qui se perd au passage (quand cela ne va pas dans le sens du manager , ou qu'une procédure tordue est "contournée" pour remettre au carré ce qui foire ... )
> une manque de communication et de plus en plus de personne qui travaillent en mode "sous marin", de peur de se faire fliquer sur le taff

Mais c'est que ça me rappelle méchamment mon boulot et je suis fort éloignée du domaine de l'informatique, et dans la fonction publique. Nos contextes respectifs n'ont rien à voir mais les méthodes de management se ressemblent.
Je rôde dans le coin parce que j'envisage une reconversion professionnelle.

[Escapetiger]

Mais c'est que ça me rappelle méchamment mon boulot et je suis fort éloignée du domaine de l'informatique, et dans la fonction publique. Nos contextes respectifs n'ont rien à voir mais les méthodes de management se ressemblent.
Je rôde dans le coin parce que j'envisage une reconversion professionnelle.

Toute ressemblance avec des personnes ou des situations existantes ou ayant existé ne saurait être que fortuite....

C'est le pire pour les femmes et les hommes en développement à travers les sous-traitants SSII/ESN qui sont les précurseurs pour tout le secteur informatique et IT pro (audit, consulting, bureaux d'études, ingénierie, etc.), on le subit également à une moindre échelle dans la partie infrastructure au sens large (réseau, système, sécurité, supervision, télécommunications, support - de proximité & «hot-line», etc.)

Il s'agit, en France, d'un dévoiement dans la durée issu du processus d'amélioration continue japonais, le Kaizen.

Allez, des rappels pour celles et ceux - nouveaux - plus jeunes, qui découvrent notre univers :
Ça circulait avant la démocratisation de l'accès à la toile (Internet) avec des Américains à la place des Japonais: La fable du rameur et des barreurs

Philippe Lefournier
publié le 05/03/1998 à 09:59

Art d'exécution ou science de l'abscons, le management se prête bien aux fables. Celle-ci circule en ce moment sur Internet.

" Une firme japonaise et une société française décident de faire une course d'aviron. Les deux équipes s'entraînent dur. Les Japonais gagnent avec plus de 1 kilomètre d'avance. Les Français sont très affectés. Leur management se réunit pour chercher la cause de l'échec. Une équipe d'audit constituée de senior managers est désignée. Après enquête, ils concluent que l'équipe japonaise est constituée de huit rameurs pour un barreur, alors que l'équipe française a huit barreurs pour un rameur.

A la lecture de l'audit, le management décide de louer les services de consultants. Après avoir perçu d'énormes honoraires, ils rendent leur avis : l'équipe française doit avoir plus de rameurs et moins de barreurs. La structure de l'équipe française est donc réorganisée. Mais, comme personne ne veut devenir rameur, il est décidé de créer quatre postes de barreurs superviseurs, trois de barreurs superintendants et un de barreur superintendant assistant manager.

Les Français mettent aussi en oeuvre un système de stimulation pour encourager le seul rameur de l'équipe à travailler plus. Baptisé "La qualité et le zéro défaut", il repose sur des réunions, des dîners et une prime sur objectif pour le rameur. La course a lieu, et, cette fois, les Japonais gagnent avec 2 kilomètres d'avance. Humiliée, la direction française licencie le rameur, stoppe la mise en chantier d'un nouvel aviron, vend le bateau et annule tout investissement. Puis elle récompense les barreurs managers de leurs efforts en leur donnant le prix de la Performance. Enfin, elle distribue l'argent économisé par ces mesures de restriction à tous les directeurs seniors.

" Tout cela ne vous rappelle pas quelque chose ?

Source: La fable du rameur et des barreurs - L'Express L'Expansion



De la littérature rare dans le domaine informatique par ordre chronologique:

Le journaliste Nicolas Séné (cf. https://nicolasene.com/journalisme/), auteur de

Derrière l'écran de la révolution sociale
Quand le monde de l'informatique et des SSII sert de laboratoire social et induit une précarisation par le haut (chez Eyrolles épuisé https://www.eyrolles.com/Entreprise/...9782358100298/ par exemple)

Informaticiens en batterie, par Nicolas Séné (Le Monde diplomatique, mai 2011)
etc.


Anne Scotté, Ingénieur en chef informatique et Directeur de projets pendant plus de 20 ans dans plusieurs grandes sociétés de service

Bienvenue dans un monde d'esclaves - La face cachée des Entreprises de Service du Numérique , préfacé par Jean-Luc Gréau

http://www.editionsdusextant.com/f/i...iv&livre_id=49
https://www.decitre.fr/livres/bienve...59.html#resume

Anne Scotté - Bienvenue dans un monde d'esclaves - Editions du Sextant
etc.


Alain Silver pendant presque 30 ans cadre dans le secteur informatique auprès de SSII, d'éditeurs de logiciel et de grands groupes internationaux

54 ans, chômeur et toujours vivant
Le parcours du combattant d'un senior

[NDLR en 2014]
https://www.eyrolles.com/Litterature...9782917617885/
Les déboires d'Alain, senior au chômage - L'Express
etc.

[VBurel]

Anne Scotté - Bienvenue dans un monde d'esclaves - Editions du Sextant

Oui, elle a raison, mais la solution c'est surtout de devenir l'employeur qu'on aurait voulu rencontrer, devenir le manager qu'on aurait voulu avoir... Bref faire les choses qui concrètement apportent du changement.

En un peu plus de 20 ans je n’ai pas beaucoup vu d’entreprise qui valorisaient le travail des développeurs, ni par une quelconque reconnaissance (et le milieu est d'une acidité forte sur ce plan), ni par le succès commercial ou technique dans l’usage du produit fini, et encore moins par le salaire (la tendance lourde du moment : dénigrer le travailleur, d’autant plus qu’il sera sur le terrain). J’ajouterai que pour la décennie 2010-2020, les conditions de travail des développeurs se sont dégradées, de par le salaire (même en prestation) et de par leur considération.

Alors que le développeur logiciel est à la fois un ingénieur dans le sens ou il sait décrire l’ensemble des étapes de fabrication du produit, et à la fois un auteur (d’ailleurs assujetti aux droits de la propriété intellectuelle) qui devra être créatif, astucieux et évidemment singulier dans l’écriture du code de ce logiciel.

Hélas beaucoup d’entreprises considèrent les développeurs comme des techniciens interchangeables (pour ne pas dire de la viande à « open space ») qui doivent suivre un processus dicté par des méthodes plus ou moins automatisées qui n’ont qu’un seul objectif : dévaloriser la fonction, asservir l’employé et nier son importance (par corruption de la méthode Agile s’il le faut) - il faut diluer les compétences, diluer les savoir faires, diluer les responsabilités (finalement c'est la méthode allemande qui s'impose...).

C’est un enjeu de pouvoir, l’entreprise ne peut pas avouer une dépendance forte à des employés qui par leur travail (intellectuel ou non), peuvent générer autant de plus-value. A moins d’être associé, ou être son propre employeur, celui qui sait faire quelque chose n’est généralement pas valoriser dans le monde du travail aujourd’hui. Et c’est aussi pourquoi il ne se produit pas grand-chose en matière d’IT en France.

La situation est paradoxale car il y a sans nul doute, des centaines de Steve Wozniak ou James Halliday, avec de l’or dans les mains dans ce pays, mais contraints et asservis à une industrie qui ne sait pas quoi faire d’eux, mal ou sous employés dans des entreprises qui tournent en rond dans leur incapacité à valoriser leur production, inintelligence économique oblige...

[Invité]

Bonjour,

Oui, elle a raison, mais la solution c'est surtout de devenir l'employeur qu'on aurait voulu rencontrer, devenir le manager qu'on aurait voulu avoir... Bref faire les choses qui concrètement apportent du changement.

En un peu plus de 20 ans je n’ai pas beaucoup vu d’entreprise qui valorisaient le travail des développeurs, ni par une quelconque reconnaissance (et le milieu est d'une acidité forte sur ce plan), ni par le succès commercial ou technique dans l’usage du produit fini, et encore moins par le salaire (la tendance lourde du moment : dénigrer le travailleur, d’autant plus qu’il sera sur le terrain). J’ajouterai que pour la décennie 2010-2020, les conditions de travail des développeurs se sont dégradées, de par le salaire (même en prestation) et de par leur considération.

Alors que le développeur logiciel est à la fois un ingénieur dans le sens ou il sait décrire l’ensemble des étapes de fabrication du produit, et à la fois un auteur (d’ailleurs assujetti aux droits de la propriété intellectuelle) qui devra être créatif, astucieux et évidemment singulier dans l’écriture du code de ce logiciel.

Hélas beaucoup d’entreprises considèrent les développeurs comme des techniciens interchangeables (pour ne pas dire de la viande à « open space ») qui doivent suivre un processus dicté par des méthodes plus ou moins automatisées qui n’ont qu’un seul objectif : dévaloriser la fonction, asservir l’employé et nier son importance (par corruption de la méthode Agile s’il le faut) - il faut diluer les compétences, diluer les savoir faires, diluer les responsabilités (finalement c'est la méthode allemande qui s'impose...).

C’est un enjeu de pouvoir, l’entreprise ne peut pas avouer une dépendance forte à des employés qui par leur travail (intellectuel ou non), peuvent générer autant de plus-value. A moins d’être associé, ou être son propre employeur, celui qui sait faire quelque chose n’est généralement pas valoriser dans le monde du travail aujourd’hui. Et c’est aussi pourquoi il ne se produit pas grand-chose en matière d’IT en France.

La situation est paradoxale car il y a sans nul doute, des centaines de Steve Wozniak ou James Halliday, avec de l’or dans les mains dans ce pays, mais contraints et asservis à une industrie qui ne sait pas quoi faire d’eux, mal ou sous employés dans des entreprises qui tournent en rond dans leur incapacité à valoriser leur production, inintelligence économique oblige...

Tu pointes la un problème de fond . En entreprise il y a aussi un "hyper administration" et "hyper normalisation". Chaque manager va tenter de mettre dans case tel truc et tel autre ... Quitte a avoir des process dégueulasses ... et qui ne servent au fond à rien ! Une chaine de traitement complexe ... en France on aime la complexité ! Chacun doit montrer qu'il est indispensable ! Alors qu'en réalité il ne l'ai pas.

[Anselme45]

Des fois je préfèrerais gagner moins pour me sentir plus utile et plus fier de ce que je fais... Genre, caissier dans un supermarché quoi par exemple...

Mais qu'est-ce qu'il faut pas lire comme conn...!

Et bien un bon conseil: Engages-toi comme caissier d'un supermarché pour faire la comparaison... Tu seras en pleurs avant la fin de la première semaine et tu viendras supplier tes ex-patrons de te réengager!!!

[smarties]

Je ne suis pas trop mal loti où je suis on a plutôt une gestion de projet classique mais il arrive d'utiliser des méthodes agiles de temps en temps et dans certains cas.

Par contre, je suis sur du Delphi/Pascal et après avoir essayé pendant presque 1 an, je conclus que je n'aime vraiment pas cette technologie :
- très mal documenté --> maintenabilité horrible
- trop verbeux et je ne trouve pas la lecture du code aussi facile facile qu'en Python ou un langage qui utilise les accolades pour les blocs (JAVA, C++, C#, ...)
- manque de composants classiques (Set, Map, fonctions de manipulation sur les dates et heures), je passe un temps fou à "bricoler" des choses similaires --> je ne me sens pas productif et je n'ai pas l'impression de produire un travail de qualité
- n'a pas l'air bien intégré dans des outils de CI/CD
- l'ergonomie de l'éditeur de code Embarcadero est pas terrible, on ne peut pas folder simplement des blocs, c'est soit la fonction, soit il faut mettre des commentaires spécifiques pour ça

En plus de cela, la société ne songe même pas à changer de technologie sur une partie des projets et donc :
- je me suis fait un peu rembarrer quand j'ai voulu proposer des améliorations sur le logiciel principal, peu de chance d'avoir un nouveau langage de programmation car tout le monde dans la société programme en Delphi et c'est donc "plus facile à maintenir" (il y en a un dans la société qui a eu l'obligation d'utiliser un framework web Delphi --> il a exploser le temps sur sa tache qui n'était pas compliqué à développer dans un autre langage)
- c'est rapide... OK... mais le logiciel développé n'utilise pas de puissance de calcul, ce sont des grosses requêtes qui font tout le travail
- turnover
- il y a des alternantes (donc des jeunes) et à l'issu de leur alternance, je suis presque certain qu'ils vont partir
- difficulté à recruter car les candidats ne veulent pas programmer sur une technologie qui, selon moi, va finir par faire comme le COBOL
- je peux évidemment demander de l'aide au collègues mais les 3/4 du temps leur réponse m'apporte une solution alternative où je me retrouve encore coincé (c'est souvent le manque de fonctions/composants qui complexifie inutilement le travail).

Pour le moment je reste car il y a le contexte sanitaire, c'est proche de chez moi, la paye est correcte mais si je trouve quelque chose qui me correspond mieux, je n'hésiterais pas à aller voir ailleurs.