Discussion :

[gsanz]

Bonjour,

Cela fait 5 ans que je suis dans une petite ESN, l'ambiance y est sympa, le patron genial et accessible seulement voilà. Il n'a pas forcement des missions interessantes à me proposer du coup depuis 5 ans je ne fais quasiment que du debug.

Il me dit clairement qu'il ne peux pas me proposer autre chose et compense ça en me payant de manière correcte, je connais mon TJM et tout ça, je touche a peine moins de 50K€ pour un dev Java de 10 ans d'experiences.

Seulement avec le télétravail et mon taf pourri je commence à me remettre en question vis à vis de mon boulot. Les vrais projets de developpement existent ils encore ou alors dans la majorité des cas ce n'est que de la maintenance/correction de bug ?

Je suis en pleine remise en question, d'où mon message pour avoir des avis.

Je n'habite pas dans une grosse ville, donc oui si je mets mon CV sur l'apec j'ai 35 appels par jour mais pas vers chez moi


Que feriez vous à ma place ?

[GreatDeveloperOnizuka]

Si t'es dans un endroit paumé et que tu veux faire du dev, il n'y a pas 36 solutions:
1) chercher en remote
2) déménager
3) accepter de faire de la route pour aller au boulot

Les entreprises plus ouvertes à des profils en total remote sont les startups mais paient moins bien. Après 50k normalement tu devrais pouvoir trouver une startup pour s'aligner.

[Glutinus]

Hello,

Le truc c'est que les missions dépendent des opportunités qui peuvent être reçues par ton ESN. Et une fois en mission, il sera difficile d'en sortir pour aller sur une autre. Pour te donner un exemple, j'étais sur une mission pourrie (qu'on m'a vendu super bien) et dans le RER j'ai sympathisé avec un gars de mon étage qui faisait un bout de chemin avec moi. Il était dans une autre ESN, le commercial l'a bien vendu, il était ouvert : résultat il est rentré sur un projet, complètement débutant sur la techno (du reporting) et s'est éclaté pendant 3 ans. Mais bon, je n'y serai pas allé, parce que ma SSII n'était pas short-listée, et qu'elle était short-listée que pour les missions de merde

Conclusion : il faut être disponible et à l'affût des opportunités, soit directement en interne, soit auprès d'autres ESN (et se faire recruter sur mission)

[Chuck 3.50]

Si le salaire te conviens je trouve que tu es chanceux car tu as une ambiance sympa et un patron cool, en plus tu es en teletravail ce qui peut te permettre de t'adonner à tes pations ou même d'apprendre de nouvelle technologie ou faire d'autres projet quand ta charge de travail est faible ?

[Mat.M]

s'adonner à ses passions...attention on ne peut pas être au four et au moulin en même temps.
C'est à dire que si votre employeur vous demande une modif dans du code en Java et que vous plantez vos géraniums dans votre jardin ça va pas le faire..

[Glutinus]

Seulement avec le télétravail et mon taf pourri je commence à me remettre en question vis à vis de mon boulot. Les vrais projets de developpement existent ils encore ou alors dans la majorité des cas ce n'est que de la maintenance/correction de bug ?

En toute logique, plus il y a d'applications qui se lancent, plus il y a de maintenance...
Sachant que les nouvelles applications sont souvent faites en mode forfait, avec des juniors, etc. là je reprends un sujet, la nana que j'ai remplacée était une grande gueule et son boulot c'est que de la merde... Et bien sûr, hors de question de tout refaire (avec tests de non-reg tout prévu) mais il faut faire de la merde (mais surtout bien faire 50 jours de test de non-reg).

Donc je pourrai pas dire quelle proportion d'employés/consultants sont sur des maintenances, mais il y en a beaucoup oui. Et si un projet est décommissionné, il est remplacé par une autre... qui sera en run.

C'est à dire que si votre employeur vous demande une modif dans du code en Java et que vous plantez vos géraniums dans votre jardin ça va pas le faire..

Mieux veut ça que faire une modif dans les géraniums du jardin et planter du code en Java

[GreatDeveloperOnizuka]

En toute logique, plus il y a d'applications qui se lancent, plus il y a de maintenance...
Sachant que les nouvelles applications sont souvent faites en mode forfait, avec des juniors, etc. là je reprends un sujet, la nana que j'ai remplacée était une grande gueule et son boulot c'est que de la merde... Et bien sûr, hors de question de tout refaire (avec tests de non-reg tout prévu) mais il faut faire de la merde (mais surtout bien faire 50 jours de test de non-reg).

Donc je pourrai pas dire quelle proportion d'employés/consultants sont sur des maintenances, mais il y en a beaucoup oui. Et si un projet est décommissionné, il est remplacé par une autre... qui sera en run.

Et toi ? T'es sûr que tu ne fais pas de la merde ?
Perso je pense qu'on fait de la merde si les moyens ne sont pas fournis. Tu peux être expert mais si t'as pas de ressources et temps pour bien faire, ben tu vas au plus vite. Tu sais que tu seras plus là pour gérer le bordel plus tard.

[Mat.M]

Et toi ? T'es sûr que tu ne fais pas de la merde ?

moi je veux bien mais selon vous c'est quoi "faire de la merde" et qu'est-ce qui n'est pas "faire de la merde" ?
Ne pas "faire de la merde" c'est travailler sur l'ordinateur quantique ?
Un moteur de jeu 3d avec des graphismes en ray-tracing ?

[Glutinus]

Je n'ai jamais prétendu ne pas en faire !
D'ailleurs, pour mon premier vrai projet from scratch de chez scratch depuis des années, j'ai fait de la merde : je n'ai pas réussi à convaincre mon chef de projet que notre architecte faisait de la SUPER-MEGA-GIGA-MERDE-QUI-PUE-BIEN-CHIASSE.

Disons qu'il y a une différence entre quelqu'un qui fait au mieux - qui souvent n'a pas de ressource, ni temps, ni machine puissante, ni outil nécessaire, ni expertise
Et quelqu'un qui fait de la merde - qui pour le coup avait des mois de dev devant lui, des experts qui le contredisent, des machines de guerres, etc.

Mais je mets un process qualité le plus sérieux possible, et met en avant plusieurs briques : qualité du typage de données, besoins utilisateurs, performance, tests etc. Je ne prétends jamais avoir la solution ultime, ni même d'ailleurs la meilleure des solutions, mais je mets un point d'honneur sur identifier sur ce que veut vraiment le chef de projet.

[Mat.M]

mais je mets un point d'honneur sur identifier sur ce que veut vraiment le chef de projet.

très bien d'accord.
Et si le chef de projet lui-même vous fait faire de la "merde" ?

[Chezkele]

Que feriez vous à ma place ?

Je commencerais (en fait c'est ce que je fais en ce moment) par faire de la recherche d'emploi ciblée sans rendre mon profil public (moi aussi je compte éviter jusqu'en dernier recours les 100 appels inutiles d'ESN par jour). Il est possible de se renseigner via ses contacts, en allant voir directement les gens qui pourraient avoir des infos intéressantes sur des projets/missions ou sur les boîtes qui en ont, en contactant directement des entreprises précises ou des particuliers via internet.

[GreatDeveloperOnizuka]

Je n'ai jamais prétendu ne pas en faire !
D'ailleurs, pour mon premier vrai projet from scratch de chez scratch depuis des années, j'ai fait de la merde : je n'ai pas réussi à convaincre mon chef de projet que notre architecte faisait de la SUPER-MEGA-GIGA-MERDE-QUI-PUE-BIEN-CHIASSE.

Disons qu'il y a une différence entre quelqu'un qui fait au mieux - qui souvent n'a pas de ressource, ni temps, ni machine puissante, ni outil nécessaire, ni expertise
Et quelqu'un qui fait de la merde - qui pour le coup avait des mois de dev devant lui, des experts qui le contredisent, des machines de guerres, etc.

Mais je mets un process qualité le plus sérieux possible, et met en avant plusieurs briques : qualité du typage de données, besoins utilisateurs, performance, tests etc. Je ne prétends jamais avoir la solution ultime, ni même d'ailleurs la meilleure des solutions, mais je mets un point d'honneur sur identifier sur ce que veut vraiment le chef de projet.

Oui mais justement peut-être que l'architecte, le chef de projet, on lui donne pas de moyen ou les besoins remontés sont débiles ?

Il y a je suis d'accord une bonne part d'incompétence chez certaines personnes, mais on est pas des magiciens, si on te donne au pif 4 mois pour faire un truc mais durant 3 mois les demandes ne font que changer pour X ou Y raisons, tu vas malheureusement pas faire de miracle. Bref, je trouve que bcp de mauvaises solutions émanent d'abord du demandeur plutôt que du concepteur de la solution

[Glutinus]

Oui mais justement peut-être que l'architecte, le chef de projet, on lui donne pas de moyen ou les besoins remontés sont débiles ?

Si tu veux une précision sur ce projet : énorme projet de refonte du SI d'une boîte qui a un quasi-monopole. Je n'essaie même pas d'imaginer quel est le budget qui y a été attribué. La phase analyse a duré un an et demi : aucun document n'a été pondu. Et quand je dis aucun, c'est aucun.

Est-ce qu'on avait les ressources ? Oui, notre CP a pu recruter une dizaine de personnes, et deux ans de devs.
Les autres équipes également. Elles ont même recruté une vingtaine de personnes. Après toutes ses personnes se sont tirées dans les pattes.
Donc quand tu passes tout ton temps à t'envoyer des mails pour dire que c'est la faute à l'autre, et que tu laisses chacun faire ce qu'il veut, oui très clairement, tu fais de la merde avec beaucoup de moyens.

Est-ce que l'architecte avait les ressources ? Oui, parce qu'il a installé la plate-forme. Oui on avait suffisamment d'espace disque sur Oracle. Il a surtout voulu se servir du projet pour faire un laboratoire pour essayer. En gros le prétexte, c'est que la production pouvait être bloquée pendant "plusieurs jours" et il voulait absolument faire un algo pour calculer les deltas intermédiaires entre chaque jour et chargé d'un coup. Il a voulu chargé deux jours : ça a planté lamentablement, il a décrété qu'il était le temps pour lui de se barrer (la mise en prod était deux semaines après). Donc oui, il avait le temps, les moyens, il a fait de la merde parce qu'il a décidé qu'il voulait le faire, et s'est caché derrière un besoin inexistant (voir plus bas).

Est-ce que les besoins remontés sont débiles ? Non, pas du tout. Mais j'ai demandé à mon chef de projet de se renseigner sur "combien de jours la prod pouvait être bloquée". Il est devenu tout rouge, a dit "une cinquantaine de jours sûrement mais là n'est pas la question" et m'a interdit d'aller voir les utilisateurs (la compta) de peur qu'on se fasse matraquer. Quand ma mission s'est terminée prématurément, je suis allé les voir le dernier jour, je leur ai demandé combien de temps ils bloquent la prod. Réponse "Deux jours grand max, mais ça ton chef de projet il sait ? on fait ça chaque année". Donc grosso modo, on avait juste à faire une astreinte et lancer le traitement deux jours de suite, une fois par an.

Donc si mon chef de projet avait eu les couilles de leur demander - sachant que j'ai jamais compris pourquoi il l'a jamais fait, qu'ils les connaissaient bien, et que les utilisateurs l'adorent - on aurait pu avoir une contrainte qui a sauté. Maintenant ça n'aurait pas empêché l'autre bachi-bouzouk d'en faire qu'à sa tête et implémenter cette solution, certainement pour la garder et l'implémenter autre part (si ça se trouve, il a gardé le code, et à ma prochaine mission je vais retomber sur la même architecture débile et dysfonctionnelle).

Il y a je suis d'accord une bonne part d'incompétence chez certaines personnes, mais on est pas des magiciens, si on te donne au pif 4 mois pour faire un truc mais durant 3 mois les demandes ne font que changer pour X ou Y raisons, tu vas malheureusement pas faire de miracle. Bref, je trouve que bcp de mauvaises solutions émanent d'abord du demandeur plutôt que du concepteur de la solution

Encore une fois, je vais répéter ce que je dis au-dessus : quand je reprends un sujet, j'arrive à faire la part des choses - et j'interviewe les gens qui sont déjà là - et on voit très bien ce qui a été fait à l'arrache pour sauver le projet (ça, j'accepte) et ce qui a été une grosse erreur d'implémentation dès le début (ça, je suis obligé de l'accepter, à contre-coeur). Par exemple, une même requête consommatrice est utilisée sur les 15 process. Question : pourquoi ne pas avoir fait la requête une fois, mis le résultat dans une table temporaire ? Réponse : "c'est comme ça depuis le début du projet" c'est de la merde.

Alors c'est très simple : un utilisateur sait rarement ce qu'il veut. Si le MOA n'a pas été en mesure de cadrer, de proposer un proto, si les décideurs n'ont pas voulu se mettre en mode agile, ou l'ont fait sans coach (parce que "pas de spec et une réunion tous les jours, moi j'adore"), alors ils ont fait de la merde (je les mets dans le même sac que la MOE pour le coup).

Si le chef de projet passe tout de suite de : on reçoit les specs et on fait les devs sans concevoir, sans bâtir un plan de recette, sans faire une roadmap, il fait de la merde.

Si on ne recrute pas de concepteur-modélisateur, ou qu'on attribue cette tâche à un dev ou un chef de projet qui n'en n'a jamais fait, alors on fait de la merde (pour info, en 15 ans de carrière et 12 datawarehouses consultés, pas un seul ne respecte ne serait-ce 50% d'une architecture de Kimball ou Inmon, qui sont considérés comme les gourous ; c'est seulement à la mission où je suis où j'ai vu pour la première fois une table de dimension Temps qui pourtant est un peu le Premier commandement du décisionnel, que la première fois sur la mission où je susi actuellement).

Et si le chef de projet lui-même vous fait faire de la "merde" ?

C'est très vague, mais s'il est trop occupé pour regarder, je fais les choses en sous-marin désormais. Et s'il regarde, bah je le fais... mais le plus proprement possible. Je fais une merde bien carrée avec un noeud rose dessus. Et bien documentée sur comment elle a été pondue, ses ingrédients, etc. bref, de la merde, ouai, mais de qualitay

[yento]

Seulement avec le télétravail et mon taf pourri je commence à me remettre en question vis à vis de mon boulot. Les vrais projets de developpement existent ils encore ou alors dans la majorité des cas ce n'est que de la maintenance/correction de bug ?

Les missions intéressantes n'existent pas. Quasiment tout le travail que tu trouveras est de la maintenance parce qu'il a enormement plus de developpements existants a maintenir que de nouveaux (et les nouveaux sont regulierement pour integrer/remplacer de l'existant donc meme cadre).

L'exception c'est en startup, qui sont rares en province, ou tout est nouveau puisque l'on fait tout de zero.

De mon avis personnel. Le plus important c'est d'avoir un environnent correct (collegues, chef, conditions de travail et salaire).
Ensuite c'est de trouver son trou en ce qui concerne les taches quotidiennes. Peu importe que l'on soit motive par debugger ou par de la gestion de projet ou par coder toute la journee, c'est possible de trouver un poste ou l'on peut faire cela la plupart du temps.