Discussion :

[gotax]

Bonjour a tous,

Je suis un reconverti dans le developpement informatique en C#.NET en poste depuis 6 mois. C'est ma premiere experience. En tant que reconverti je n'ai pas de bonnes bases, mais j'y travaille notamment avec un coach. Au boulot on me donne des tickets qui sont difficiles je trouve et qui ne sont pas du tout detaillés. Quand on me file un ticket pour ajouter une fonctionnalité on me dit rien sur la logique metier derrière, je dois jouer le plus souvent tirer les vers du nez de mon lead pour avoir un peu d'infos. Depuis 6 mois que je bosse je pige pas grand chose au projet. Sur le projet j'ai a faire avec des techniques plutot avancées ppour moi comme de la reflection, des delegués, entity framework, includes etc... C'est une petite boite de 4 personnes dont moi. Le lead dev, qui fait aussi office de senior backend et de CTO ne m'aide pas, ou alors très sommairement. Il veut juste que je sois autonome mais j'ai clairement pas le niveau pour etre autonome.

Donc j'en viens a passer des jours bloqué devant un problème que je ne sais pas regler. Je commence à me sentir serieusement démotivé par cet emploi/metier en general car je sens que je ne progresse pas et que j'apprends rien. Ce qui est dommage car je me donne du mal a coté de ca et j'ai la chance de bosser sur des technos recentes (.NET 6 et postgresql). Mon contrat se termine dans 6 mois et je ne sais pas trop quoi faire. Tous les matins lors du meeting quotidien c'est la honte pour moi car je suis le seul a dire "oui je suis encore sur le meme ticket y a pas bcp de nouveautés..."

[AaâÂäÄàAaâÂäÄàAaâÂäÄ]

on me donne des tickets qui sont difficiles je trouve et qui ne sont pas du tout detaillés.

Dans les systèmes de billeteries sans template, c'est ça qui arrive.
Personnellement, sur un billet, je passe 75% du temps à aller à la pêche aux informations pour comprendre le besoin qu'à répondre réellement au besoin...

Si on ne te donne pas les informations, c'est à toi d'aller les chercher. N'hésite pas à programmer une réunion avec ton Lead ou autres et prépare ta liste de questions précises.
Après, c'est toujours la balance entre quémander de l'information et importuner le monde. Mais au moins soit proactif à demander de l'information.
Si on ne te revient pas, tu ne peux pas l'inventer.
C'est pas mal toujours comme ça sur une nouvelle job ou une nouvelle mission, malheureusement.

[gotax]

merci pour ta reponse. Etant novice et a ma premiere XP et tres peu de connaissances sur le projet, je ne sais pas quelles questions posees. Genre ca me vient pas a l'esprit car je n'ai reellement que tres peu de connaissances et de ce fait suis tres ignorant

[AaâÂäÄàAaâÂäÄàAaâÂäÄ]

Prends un cas concret, une demande et liste les points qui te bloquent ou les incertitudes. C'est ça que tu as besoin de savoir.
Il y a des questions qui vont être simples comme des définitions de mots ou d'expressions, mais il faut déjà les connaitre pour avancer et comprendre.
Je me souviens lors des mes premiers jours de dev, j'avais demandé ce que signifiait un acronyme que tout le monde employait et la grosse majorité avait souri ou ri. Mais finalement, il y avait peu de personnes qui en connaissaient réellement la signification, la plupart savait vaguement à quoi cela faisait référence mais ne connaissait pas pour autant le vrai sens...

[gotax]

oui merci pour ta reponse

[Mat.M]

Je commence à me sentir serieusement démotivé par cet emploi/metier en general car je sens que je ne progresse pas et que j'apprends rien. Ce qui est dommage

pour cela ne pas hésiter à consulter des tutos en ligne.
Et surtout le MSDN en ligne c'est la base de données de Microsoft qui regroupe toutes les technos Ms comme NET.

Au boulot on me donne des tickets qui sont difficiles je trouve et qui ne sont pas du tout detaillés. Quand on me file un ticket pour ajouter une fonctionnalité on me dit rien sur la logique metier derrière, je dois jouer le plus souvent tirer les vers du nez de mon lead pour avoir un peu d'infos.

bonjour,
je suppose que le projet est développé sans aucun cahier des charges, sans spécifications ?
La majorité des projets auxquels j'ai participé c'était le cas hélas.
Comme suggestion ce qu'il est possible de faire c'est un minimum de retro-ingénierie.
Avec Visual Studio il est possible d'afficher des diagrammes de classe en UML à moins de prendre des outils spécifiques pour ça.
Cela permet de comprendre un minimum de quoi sont faites les fonctionnalités du projet,c'est mieux que rien.
Ou bien sinon si UML est trop rébarbatif, se faire soi-même ses propres specs et ses propres schémas.
Bref poser les problèmes sur papier.

[gotax]

Effectivement ni specs ni tests. donc je me prends des null exception de partout pour n'impote quoi. la ca fait depuis vendredi que j'essaie de tester un truc mais je me prends System.Reflection.AmbiguousMatchException: 'Multiple custom attributes of the same type found.' je sais pas comment regler ca. donc autant te dire que niveau motivation la c'est zero.

[GreatDeveloperOnizuka]

Je suis le coach de gotax .

Je bosse pour lui gratose en ce moment pour l'aider à résoudre ces tickets. Il a une part de responsabilité car ne m'écoute pas assez (bon c'est un reconverti et il a mis plusieurs mois avant d'intégrer le fait de bien tester son code et de travailler méthodiquement) mais son projet est ultra bancal aussi. Voici un petit florilège des pratiques que je lui dis de pas faire mais faut qu'il le fasse quand même dans son job car le CTO est claqué.

1. Son CTO ne connait pas la POO. Vous avez bien lu, faire du C# sans connaître la POO. Aucun principe d'encapsulation, il y a 0 interface oui oui ZERO interface. Donc, oubliez les méthodes polymorphes, classes abstraites ou autre. Le fameux D des principes SOLID on oublie.
2. 0 test littéralement, couverture de test = 0%
3. L'archi est donc claqué, il y a aucune notion de clean architecture (normal vu qu'il n'y a 0 interface pour abstraire les composants)
4. La réflexion, c'est censé être utilisé avec parcimonie, le CTO l'utilise même dans le coeur de son métier alors que tu peux très bien appliquer certains patterns comme Decorator ou strategy pour abstraire ça (mais bon, je vais pas lui demander de faire du design pattern si il utilise déjà pas vraiment la POO). Ce qui est encore marrant car il avait demandé à Gotax d'apprendre les design pattern, l'hôpital qui se fout de la charité.

Il y a des gens qui codent encore comme ça après + 10 ans XP en 2024.

Donc d'un côté j'essaie de lui apprendre à faire de la POO, de bien respecter l'encapsulation, mais de l'autre côté il est obligé de faire de la merde et moi aussi je baisse de niveau en essayant de l'aider et donc obligé de faire de la merde.

Comme vous le mentionnez, il va pas assez à la pêche aux infos aussi. Je lui ai déjà dit.

Perso après des mois je lui ai plutôt dis de trouver un autre boulot car j'essaie de lui apprendre la POO, l'UML, je peux même pas commencer la partie Database car il va pas l'appliquer ou très mal dans son boulot, déjà qu'il ne comprend pas vite en plus.

[gotax]

Ce que dit Onizuka est vrai. J'ai des lacunes et une manque de methodologie qu'on corrige doucement doucement avec Onizuka. Helas la codebase sur laquelle je bosse comme l'a decrite Onizuka est tres compliquée ce qui ne m'aide pas du tout. Je passe mon temps a debuguer ces trucs bizarre (avec onizuka) qu'a reellement coder et progresser dans ca.

[Pyramidev]

Bonjour,

Effectivement ni specs ni tests. donc je me prends des null exception de partout pour n'impote quoi.

Je ne fais pas de C#. Mais j'ai lu que, à partir de C# 8, dans le .csproj, on peut définir <Nullable>enable</Nullable> pour que le compilateur affiche un avertissement en cas de risque de déréférencement de référence nulle : https://learn.microsoft.com/en-us/do...ble-references
En plus, je lis : "Beginning with .NET 6, new projects include the <Nullable>enable</Nullable> element in all project templates."
Normalement, le typage permet alors de différencier les références nullables des références non nullables.

En C#, est-ce que ça marche bien en pratique ?

Remarque : Pour avoir un programme qui marche bien, il faut des tests automatisés. Mais, même quand un programme est bien testé, un bon typage est quand même utile pour que les signatures des fonctions soient plus claires.

[gotax]

Oui il parait, mais je saurais pas te repondre. Tout ce que je peux dire c'est que je passe mes journees a tester et debug des trucs au lieu de coder. a ce rythme je vais finir par avoir plus d'XP comme testeur que comme dev...

[GreatDeveloperOnizuka]

Bonjour,


Je ne fais pas de C#. Mais j'ai lu que, à partir de C# 8, dans le .csproj, on peut définir <Nullable>enable</Nullable> pour que le compilateur affiche un avertissement en cas de risque de déréférencement de référence nulle : https://learn.microsoft.com/en-us/do...ble-references
En plus, je lis : "Beginning with .NET 6, new projects include the <Nullable>enable</Nullable> element in all project templates."
Normalement, le typage permet alors de différencier les références nullables des références non nullables.

En C#, est-ce que ça marche bien en pratique ?

Remarque : Pour avoir un programme qui marche bien, il faut des tests automatisés. Mais, même quand un programme est bien testé, un bon typage est quand même utile pour que les signatures des fonctions soient plus claires.

Oui les null exceptions c'est plus censé être un problème en 2024 et heureusement .

Pour te répondre pourquoi dans son projet il y en a pleins:

• Son CTO en a RAF des warnings, son projet doit comporter pas loin de 1000 warnings, Gotax filera le chiffre exact sûrement
• Il utilise trop la réflection, un des désavantages est la difficulté du testing qui va avec et donc son évaluation à l'exécution. Du coup pas d'analyse statique afin de lever des warnings de potentiels null exception en amont

En fait ce projet est finito pour moi sauf si grosse équipe commercial avec un gros portefeuille pour vendre. Car ils sont toujours en MVP malgré 3 personnes à pleins temps dessus en dev (le CTO, un dev front et Gotax reconverti) depuis 2 ans. Donc imaginez la dette technique accumulée avec 0% de test coverage + pleins de trucs coeur de métier fait avec de la reflexion. C'est le genre de projet qui fini à la poubelle avec une refonte intégrale d'ici quelques années car ils arriveront plus à fixer les bugs. Je parle même pas du risque de faillite de la boite.

[gotax]

Onizuka a tout résumé. bref c'est la grosse galère

[arkya4]

Bonjour,

J'ai connu plusieurs expériences assez similaires à la tienne, petite équipe, collègues qui font de la rétention d'informations ou qui rechignent à répondre à l'oral, et j'ai travailé sur des projets vieux de 10 ans ou plus avec une architecture osbolète et des bugs obscurs, me demandant parfois ce que je faisais là avec des grosses baisses de motivation.

Ce que je fais dans ces situations là, dans le désordre

• Poser des questions de manière groupée, pour un sujet spécifique et par mail
• Proposer des initiatives persos (documentation, amélioration technique) et voir le feedback
• auto-formation en lisant la documentation interne (si elle existe) et en lisant des tutoriels sur le net. Créer sa propre base de connaissances persos
• Travailler sur des tests unitaires

Je connais la frustration de travailler dans une telle configuration, et surtout pour une 1ère expérience, bon courage à toi

[gotax]

Salut et merci pour ta reponse. En effet c'est extremement frustrant pour moi d'autant plus que je n'apprends rien. En 7 mois d'XP j'ai fait 3 controlleurs et quelques endpoints. Je passe mon temps a debuguer le bouzin au lieu de coder et m'ameliorer, je l'impression d'etre plus QA que developpeur. D'autant plus que ca fait 1 mois et demi que je suis coincé sur le meme ticket car j'arrive pas a tester... donc je passe mes journees sur le debugger => zero apprentissage. un dev backend 7 mois xp qui sait pas faire un controlleur et des CRUD basiques ca la fout mal putain...

[d_d_v]

Bah si, tu apprends quelque chose d'important qui te sera utile pour la suite: rentrer dans un projet dégueulasse existant sans doc et sans specs. Utile chagpt sans lui fournir des informations confidentielles quand tu te poses des questions "bêtes" du genre "voici un bout de code, est-ce que ça te semble cohérent ?", etc. N'hésites pas à "harceler" tes collègues en leur posant des questions. Après tout, tu n'es pas responsable de ce merdier.
Quand tu as de l'expérience, avec ce genre de projet, tu t'arranges ensuite pour travailler à mi-temps dessus et l'autre moitié du temps sur des projets perso, sinon tu finit par perdre la motivation et les compétences. profites-en pour bien pipeauter ton cv avec cette expérience de "rétro-ingénierie" / "devéloppement legacy"

[gotax]

Oui j'utilise chatgpt sans probleme ni vergogne, je m'en fous. De collèguee j'en ai qu'un seul, qui fait office de dev senior, lead dev et CTO (comme j'ai dit c'est une micro boite.) et je lui pose des questions mais lui ne veut pas etre explicite car dit il "il veut me faire reflechir par moi meme pour me rendre autonome". Ok mais ca se fait avec le temps ca et pis en restant bloquer des jours et des jours sur le meme truc j'en perds la motivation. Oui comme c'est ma premiere XP donc je m'accorche mais par contre je sais pas si on peut appeller ca du legacy car les technos utilisees sont modernes (.NET 6.0, EF, Postgres) rien d'obscure la dedans et je sais que j'ai de la chance d'etre sur des technos modernes

[d_d_v]

OK. En gros, j'imagine que tu es mal payé car le recruteur n'avait pas beaucoup de moyens et à défaut de recruter un senior, essaye de rafistoler le truc avec un junior autodidacte en "espérant" que tu puisses faire des améliorations. Il est possible que tu ne lui coûtes rien grâce à des subventions ou je ne sais quoi.
Il n'y a aucune honte à avoir. Profites-en pour te former au langage/framework, remplis bien ton CV avec cette expérience "enrichissante" en mettant le plus de points positifs (même si tu en retiens plutôt du négatif), et essaye de trouver la prochaine fois au moins une PME avec plusieurs développeurs. Et pour le prochain entretien, demandes au recruteur la manière dont ils travaillent, s'ils ont de la documentation, des specs, etc.
Normalement, dans une équipe "normale", surtout quand le projet est "pourri", celui qui t'a recruté te met sur des tâches faciles au début pour t'habituer à rentrer progressivement dans le projet. Ce n'est visiblement pas le cas ici.

[gotax]

Oui on peut dire que je suis mal payé^^ et oui vu que c'est une micro boite ils ont pas les moyens de prendre un senior, d'un autre cote c'est une chance pour moi car vu la crise du marché des juniors actuellement sans minimum 2 ans XP c'est mort de chez mort. Et par consequent trouver ailleurs actuellement est quasiment impossible donc je m'accroche en esperant que ca sera une XP "revendable" par la suite. Je veux juste ne pas atteindre le point de dégout pour le metier, car lorsque rien ne va jour apres jour c'est moralement lourd, et il me suffit de peu tu sais, genre si j'arrive a faire un petit algo simple qui marche ou a un bout de code qui sert, ou a resoudre un exo leetcode ca fait ma journee j'ai le moral au top. Je sais que ca semble que je fixe la barre très bas mais c'est comme ca, je suis un debutant reconverti et j'essaie de voir la verre a moitié plein plutot qu'a moitie vide.

[gotax]

PETITE MAJ:

Cela fait 2 mois que je galere sur une serie de tickets que le lead lui meme avait dit qu'ils etaient difficiles. Ce matin je lui ai demandé un feedback sur moi. il a repondu:

"Malheureusement, ça ne va pas bien, mais je sais que tu t'en rends compte aussi. Cela est dû au fait que les tâches sont certainement exigeantes et, parce qu'elles sont exigeantes, elles mettent en évidence toutes tes lacunes. Selon moi, c'est un problème à la fois technique et d'expérience, mais surtout de raisonnement logique. La technique et l'expérience, tu peux les acquérir avec le temps, mais pour le raisonnement logique, il faut faire un effort supplémentaire : il ne suffit pas simplement de coder pour l'acquérir, il faut travailler vraiment sur les capacités analytiques. C'est une difficulté compréhensible, car c'est la vraie difficulté du codage : si tu viens d'une formation scolaire, la base analytique est exactement la première chose sur laquelle on se forme. Ne venant pas d'une formation scolaire, c'est comme si tu abordais le code uniquement avec de la "force brute", et c'est pour cela que tu finis souvent tes journées très épuisé, même avec des morceaux de logique pas trop complexes."

je lui ai dit "tu rigolais pas quand tu disais que les tickets etaient durs"
lui: "non pas du tout j'etais serieux"


La messe est dite. Je me suis vraiment donné a fond et la je suis epuisé et décu un peu meme si je m'y attendais.