Discussion :

[codeKiwi]

Bonsoir!
Ça fait très longtemps que je passe sur ce forum sans jamais intervenir. J'y ai toujours trouvé de bonnes idées, des débats houleux, des conseils pertinents, etc. Aujourd'hui j'aimerais recevoir des conseils personnalisés, de personnes ayant un peu plus de recul que moi sur le monde de l'info.
Je suis développeur web "professionnel" depuis le début d'année. Avant ça, je me suis formé sur plusieurs années, entre la fac (cursus maths/info) et un passage à l'école 42, souvent en bossant en parallèle pour remplir la gamelle
Je travaille dans une entreprise de vente en ligne (exclusivement). On est une poignée de développeurs, et l'outil principal est un framework maison qui est en place depuis plus de dix ans.

Honnêtement, sur le plan de mon intégration dans le métier et dans l'entreprise, tout se passe super bien. Je crois que j'ai rapidement réussi à devenir opérationnel (malgré le fait que l'outil ne soit absolument pas documenté) et l'entente avec l'équipe est plutôt cool. Mais (ben oui, il fallait bien qu'il y ait un "mais"), en terme de boulot, je dois dire que je m'ennuie sévèrement.
J'ai choisi ce poste parce que je ne savais pas trop ce que je recherchais comme boulot de développeur et j'étais très curieux de me faire une première expérience. J'avoue que je suis reconnaissant envers l'entreprise parce que j'ai pu devenir développeur à temps-plein, voir le métier beaucoup plus concrètement que ce qu'on nous présente à l'école, collaborer, comprendre comment sont définis les projets, etc. J'ai aussi pu prendre conscience des choses qui me séparent de développeurs plus chevronnés, les éléments sur lesquels je dois bosser (hors stack technique pure, je parle plutôt d'une vision plus générale du métier).

Et là, après environ sept mois, j'ai envie de partir et de découvrir autre chose. Le framework maison nous impose souvent d'écrire du code dégueu et d'adopter de mauvaises habitudes (ça prend trop de temps de tout revoir et de nettoyer le code en place, et tout ce qui ne rapporte pas d'argent n'est pas prioritaire, chose que je comprends évidemment mais qui est un peu frustrante). Par ailleurs, j'ai énormément travaillé avec JS avant ce poste. J'aime beaucoup le langage, son écosystème et j'ai la chance d'avoir appris plein de choses qui ne me servent à rien au quotidien. Je ne suis pas fermé, mais, pour vous donner un exemple, mon chef m'impose constamment d'utiliser jQuery partout parce que tout le monde ne sait pas lire du JS Vanilla. Il tique parfois même sur le fait que je déclare mes variables en utilisant "let" et "const" et pas "var".
Ce n'est qu'un exemple, et la frustration technique est souvent compensée par le fait que l'entreprise soit cool et l'équipe très sympa.

Enfin bref, j'arrête les détails. Je voudrais juste profiter de vos avis pour savoir si mon envie de partir n'est pas une mauvaise idée et si le fait de changer de poste au bout de sept/huit mois pourrait être préjudiciable. Je ne cherche pas le poste idéal (enfin si je le trouve, je ne compte pas cracher dessus ), mais j'ai envie de voir un peu ce qui se fait ailleurs, comment on travaille dans d'autres cadres, comment des développeurs un peu plus "à jour" pourraient m'aider à progresser.
Je souligne enfin que je n'ai aucun avantage matériel particulier dans mon entreprise. Je suis payé quasi au minimum, pas de RTT, pas d'avantages particuliers, et le poste n'est pas super proche de chez moi (sachant que le télétravail n'est pas une option envisageable pour mon patron).

Voilà, merci pour vos retours et bonne soirée!

[nathieb]

Bonjour,

Déjà, si tu te poses ce genre de question, c'est qu'il y a un mal être. Tu l'exprimes en tout seul, car tu cherches à te repositionner. Il faut savoir qu'on considère qu'en entreprise le retour véritable sur investissement, pour un débutant est de 3 ans. Je ne connais pas ton niveau, mais je crois comprendre que tu débutes.
Tu peux faire un exercice simple sur deux colonnes pour/contre, si je reste ou je pars.
Pour ce qui est de l'avenir, il est souvent conseiller de changer pour évoluer.
C'est aussi souvent une remise en question personnelle.
Après, il faut savoir que les bonnes ambiances sont plutôt rares ...
La seule personne qui a la réponse est toi même, et que si tu as un objectif précis (techno, méthodo, vie privée, etc ...) alors fonce.
Je jamais partir pour partir.

Passe des entretiens, c'est souvent, un bon retour et un repositionnent personnel, voir une thérapie

Olivier

[codeKiwi]

Merci beaucoup pour ton retour
J'avoue que, même si je n'avais pas l'impression de l'exprimer trop fort, il y a un petit mal-être vis-à-vis de mon poste.
Cela dit, j'ai du mal à dire si c'est parce que j'en attends trop ou si c'est parce qu'il n'est pas stimulant. Mes collègues n'ont pas l'air de s'amuser beaucoup non plus et restent (de leur propre aveu) parce que l'équipe est cool et la situation convient bien à leur vie personnelle.

L'idée du table pour/contre est bonne, je vais d'ailleurs le faire, ça m'aidera à poser un peu plus les choses.
En tous cas je ne m'attendais pas à ce qu'il me faille trois ans pour être rentable en tant que débutant
Ce chiffre est intéressant et met un peu les choses en perspective.

Merci encore pour ton retour, c'est vrai que c'est cool d'avoir la vision d'une personne qui a plus de recul sur le métier.
Bonne journée!

[Glutinus]

Hello,


Avoir un environnement propre, c'est extrêmement rare. Sur les quinzaines de mission que j'ai faites, il y a toujours, pour raison X ou Y, un concept erratique d'architecture ou de framework qui génère 80% des bugs, des baisses de performance, des temps de dev, etc. Partir où tu es en espérant un environnement plus joli, c'est très risqué. Cela est possible, mais pas toujours probable. Et si l'environnement est assez propre, ce seront des problèmes de management ou du collègue.

Quand je faisais de la SSII - je sais, ce n'est pas ta structure actuelle - et que j'ai voulu changer de boite, on m'a demandé de faire un an minimum sur une mission. J'avais enchainé plusieurs forfaits de deux ou trois mois, très valorisants et formateurs. Le problème, c'est que de l'autre côté du miroir, les SSII concurrentes pouvaient voir cela comme un manque de compétence, et qu'au bout de mois d'un an je ne faisais pas l'affaire. Si tu pars au bout de sept mois, les futurs employeurs théoriques pourraient prendre cela comme si on t'avait poussé à la porte de sortie, ou comme un manque d'implication de ta part, paradoxalement.

Je comprends ton envie, et surtout besoin de ta carrière de voir plusieurs environnements - je ne pourrai que recommander de faire plusieurs boites pour voir comment c'est un peu de chacune d'entre elles, multiplier les expériences c'est le meilleur moyen de connaître les différents obstacles qu'on peut surmonter - mais dans un premier temps, je dirai bien d'essayer d'attendre un petit peu. Tu sais toujours où tu es, mais jamais où tu vas atterrir.

[codeKiwi]

Merci pour ta réponse.

C'est vrai que ton argument sur la durée d'une première expérience fait indéniablement partie de l'équation. Se griller en partant trop tôt est certainement une mauvaise idée et je dois en tenir compte.

Quant à l'environnement, pour préciser un peu, il me paraît extrêmement sain sur le plan humain et managérial (ayant fait pas mal d'entreprises hors informatique avant, sur ce point j'ai un peu de recul), peut-être un peu moins sur l'aspect technique. Je manque évidemment de points de comparaison parce que c'est la première fois que je travaille sur un outil professionnel, mais certaines choses me semblent parfois assez bancales.

Le framework a été codé il y a longtemps, et il atteint aujourd'hui une complexité assez imbuvable parce que la plupart des portions de code n'ont pas évolué avec le temps. A titre d'exemple, il n'est pas rare de devoir debugger des fonctions qui font entre mille et deux mille lignes (sachant que l'outil n'est pourvu d'aucune forme de documentation) et contenant des potions de code qui ne sont plus utilisées mais qu'on doit garder "au cas où", ou de devoir écrire du code "sale" pour se conformer à l'existant. Je note aussi que mon Chef (le concepteur de l'outil) a créé ses propres règles sur pas mal de points comme l'application des concepts de POO, ou le fait que rien ne doit être fait en JS sans jQuery. Ce ne sont que des exemple isolés qui ne sont pas insurmontables, mais c'est vrai que j'ai parfois l'impression de prendre des mauvaises habitudes et surtout de ne rien apprendre qui soit vraiment transposable ailleurs que dans mon entreprise. C'est le genre de sentiments qu'on a tous quand on est développeur professionnel?

Je me demande aussi pourquoi aucun développeur expérimenté n'accepte de rejoindre notre équipe, alors que l'entreprise est en recherche depuis un an et que les entretiens se sont enchaînés. Pourquoi les anciens bons éléments sont partis?

Ouh là, je m'arrête parce que je noircis le tableau et c'est pas forcément cool. Quand on se pose des questions, on a trop vite tendance à voir les choses de façon très négative et on s'enferme soi-même dans ses idées.
J'avoue que les arguments concernant les conditions agréables de travail et le fait d'éviter un départ prématuré font sens et je pense que je vais prendre un peu de temps pour réfléchir à tout ça, histoire de ne pas "partir pour partir" comme disait nathieb. Et puis, cette posture peut aussi me permettre de mieux réfléchir à ce qui se fait ailleurs et de préparer un éventuel après.

En tous cas merci encore pour vos avis et conseils!

[Glutinus]

Ce ne sont que des exemple isolés qui ne sont pas insurmontables, mais c'est vrai que j'ai parfois l'impression de prendre des mauvaises habitudes et surtout de ne rien apprendre qui soit vraiment transposable ailleurs que dans mon entreprise.

Si c'est un framework maison, il est basé sur un langage que tu maîtrises et revends, il n'y a pas de souci.
Par contre, si tu travailles sur un progiciel hermétique, juste du paramétrage, tu seras bloqué.
Idem, si le langage est vieux (j'avais été envoyé en mission chez un client qui cherchait des développeurs java, mais une fois que tu arrivais ils te mettaient sur une appli avec un langage qui n'est plus utilisé).

Rien n'est jamais non-transposable. Au pire, tu auras appris à gérer ton temps, ta méthodologie et la manière dont tu gères les caractères de tout un chacun - c'est le plus difficile, àmha, quand tu travailles en société : savoir surtout gérer les autres.

Je me demande aussi pourquoi aucun développeur expérimenté n'accepte de rejoindre notre équipe, alors que l'entreprise est en recherche depuis un an et que les entretiens se sont enchaînés. Pourquoi les anciens bons éléments sont partis?

Pour les raisons que tu cites : quand tu es expérimenté, tu t'attends à des standards minimum. Il y aura des anguilles sous roche que tu découvriras seulement quand tu auras mûri toi-même dans le monde du travail au travers d'autres expériences. Quand tu es débutant, il faut bien te faire les dents quelque part. Justement, avant les entretiens que j'évoque au-dessus, j'étais sur une mission pas terrible, surtout niveau management qui change les priorités, te dis que tu dois gérer les quatre clients pour demain etc.

J'en ai eu marre, mais également à cause des temps de transport. Mais au final avec du recul, j'ai appris énormément en base de données en même pas 6 mois (dans d'autres missions ça m'aurait pris 2 ou 3 ans), et fais la connaissance de super personnes également qui aujourd'hui encore sont des amis et des bons contacts professionnels.

[yento]

Je me demande aussi pourquoi aucun développeur expérimenté n'accepte de rejoindre notre équipe, alors que l'entreprise est en recherche depuis un an et que les entretiens se sont enchaînés. Pourquoi les anciens bons éléments sont partis?

Quand c'est pas a cause de l'environment human, c'est une simple question de remuneration et/ou de pouvoir travailler a distance pendant le COVID.

La tres grande majorite du travail est de la maintenance de code existant, pas des nouveaux projets from scratch.
En un sens c'est bon pour toi de travailler sur du vieux code, parce que c'est certainement la ou tu vas passer la suite de ta carriere.
Et a ton age, c'est peu probable que ton prochain poste soit dans une startup ou une entreprise qui fonctionne grace aux internes, qui sont les principaux environments ou il y a tout a faire depuis zero (par des jeunes juniors sous payes qui travaillent jusqu'a epuisement ).

C'est normal de quitter sa premiere entreprise au bout de un a deux ans quand on debute, pour gagner plus et pour decouvrir l'herbe ailleurs (c'est rarement mieux mais ca donne de la perspective).
Les profils avances peuvent changer tous les 6 mois en debut de carriere, mais ca demande de la chance et une grosse aptitude technique que tu n'as probablement pas. (Les jeunes diplomes ont en fait facilement 3-5 experiences differentes a travers les stages et premiers emplois, qui sont rarement pris en compte quand il s'agit de la grille de salaire, mais qui comptent quand il s'agit de reussir les entretiens).

A 7 mois, je pense que tu es un peu court, mais ca n'empeche pas de prospecter.
Si tu trouves un poste, tant mieux pour toi.
Il y a un petite risque, si ca se passe vraiment mal dans la nouvelle entreprise et tu dois trouver un nouveau travail 6 mois plus tard, ca pourrait etre tres handicappant d'avoir seulement deux experiences de ~ 6 mois.

Au dela du temps, il y a une question d'objectifs.
Avec quels frameworks javascript tu peux coder? Quels sont les framework typiquement recherches sur un nouveau poste?
Tu sais packager et deployer une application? Est ce que tu as touche a l'environment de production? Savoir modifier et faire evoluer une application en production.
Comment est-ce que tu tests? Tests unitaires? Tests d'integrations? Et bien sur test HackerRank avant entretien

[Mat.M]

Et là, après environ sept mois, j'ai envie de partir et de découvrir autre chose. Le framework maison nous impose souvent d'écrire du code dégueu et d'adopter de mauvaises habitudes (ça prend trop de temps de tout revoir et de nettoyer le code en place, et tout ce qui ne rapporte pas d'argent n'est pas prioritaire, chose que je comprends évidemment mais qui est un peu frustrante)

désolé de dériver du sujet principal mais une entreprise qui a cette vision des choses c'est quasiment suicidaire pour elle..car il s'agit bien de dette technique du code
Curieux que Mr el_slapper ne l'ai pas rappelé soit dit en passant

pour une petite entreprise du numérique qui accumule de la dette technique c'est une catastrophe car au final ça finit par être extrêmement coûteux à effectuer une refonte de code à un moment donné et à corriger des bugs éternellement.
Le problème c'est que les coûts de production dans une entreprise qui "fait du logiciel" ( ESN ou éditeur peu importe) augmentent au fil du temps.
Donc un projet démarré à un instant t0 avec un budget de mettons x milliers voire millions d'euros, à un instant t1 rien qu'en maintenance avec l'inflation ça coûte évidemment plus cher.

[Glutinus]

La dette technique est effectivement un cercle vicieux : très souvent la conception et le développement ont été trop longs. Il y a eu rallongement de budget. Il suffit d'une mauvaise idée et il y a des effets de bord partout[1]. En plus derrière :
- Code compliqué, bourré de trous dans lequel s'insère les cas particuliers non testés
- Performance dégradée
- Reprise compliquée
- Code illisible, difficile à maintenir
- On remplace cette fonctionnalité automatique par 3 actions manuelles.

Les effets pervers derrière sont :
- "Je te rappelle qu'on est facturé à la correction d'anomalies et évolutions. On met 5jh pour faire un UPDATE ?", menace la grosse SSII qui a placé 5 juniors en TMA
- "Je suis obligé d'être en astreinte tous les week-ends car les traitements prennent 24h et peuvent péter à tout moment", se plaint le freelance chafouin qui facture 800€ de TJ, et 1200 le samedi et 1600 le dimanche.
- "Ha non tu touches pas, tu vas tout casser, c'est pas toi qui t'es tapé des soirées jusqu'à 23h pendant quatre mois pour boucler les devs", larmoie le manager trop méfiant - parfois à raison, mais difficile de lui expliquer qu'il a tout à y gagner, notamment en risques opérationnels qui seront nettoyés.
- "... Ha, c'est bien, on va devoir trouver d'autres tâches pour Nestor et Gilbert qui faisaient les copiers-coller des fichiers", dit le directeur de service, "content" de devoir bouger son cul pour former les deux juniors arrivés et qui se font chier, mais qui sert surtout à dire qu'il a une équipe de 10 personnes sur l'organigramme et LinkedIn.

[1]

Un exemple, dans le décisionnel - les concepteurs, ou quiconque ayant eu ce rôle car il n'y a pas eu de concepteur officiel - veulent absolument tout historiser. Au lieu de demander aux utilisateurs "vous voulez historiser les modifications des lignes de données", voire les convaincre que c'est pas nécessaire, c'est "dans le doute on le fait". Résultat c'est souvent des multiplications de règles complexes, des reprises archi-compliquées quand ça se plante et qu'il faut revenir en arrière etc. Et quand on pose la question "Qui a eu l'idée de faire ça ?", la réponse c'est souvent "Mais c'est comme ça qu'on fait dans le décisionnel !". Alors que justement, les pontes du décisionnel, comme Kimball, expliquent que ce n'est vraiment pas une bonne idée et qu'il faut faire ça si c'est nécessaire.

Résultat aujourd'hui je me retrouve avec une table de comptes clients de 10 millions de lignes, sans index (NON SURTOUT NE FAIS RIEN CA VA DEGRADER LES PERFORMANCES) qui représentent en fait 100 historisations, et en réalité la seule information historique qui intéresse les utilisateurs, c'est si le client a changé d'agence ou pas, donc grosso modo on aurait réduit à 2 ou 3 historisations, voire aucune, par client

[Mat.M]

Il y a eu rallongement de budget

voui d'accord mais pour une petite entreprise encore faut-il en avoir les moyens financiers pour rallonger le budget...
là le projet est tout à refaire parce que les normes ont changé et que la puissance publique décide de tout changer résultat des courses le petit éditeur il doit tout reprendre le code,faire une refonte du projet, faire appliquer les normes dans les règles de gestion du logiciel ;donc faut embaucher au besoin des développeurs en plus ,quitte à contracter un emprunt auprès de la B** pour payer les salaires des développeurs.
Si les entreprises du numérique en ont les moyens c'est bon, sinon...