Discussion :

[Plop55]

#maVie #pavé

Je travaille dans info depuis en gros 3 ans. J'ai récemment changé de boite et je me pose des questions existentielles sur mon "environment de travail": est-ce que la situation que je rencontre est commune dans le milieu? Ou est-ce que je vis une expérience pourrie? Et où aller avec tout ça? Should I stay ou should I go?

Préparez-vous au gros pavé (désolé).

A la base, je n'ai pas une formation de dev, mais bon, je me suis réorienté petit à petit. Dans ma boîte précédente, j'étais sur un poste de testeur, mais dans les faits, j'ai bossé en tant que dev à tout faire (front-end, back-end, mise en place de la chaîne CI, tests ...) dû surtout au manque de devs dans la team (en gros, on était 2 + des collègues chercheurs qui ne voulaient pas toucher au code). Le dev senior n'en foutait pas une. En gros, en 2 ans, j'ai dû avoir une revue de code de sa part et 1 semblant de brouillon d'architecture de l'appli qu'on était censé développer. En fait, toutes les 2 semaines, en Sprint review, on devait lui réapprendre ce que devait faire l'appli.
Pour résumer, la situation était: boulot chez le client final, beaucoup d’indépendance, beaucoup d'autonomie, beaucoup de responsabilités implicites, on ne te dit pas ce qu'il faut faire, les deadlines sont inexistantes et si ça tourne mal, bah, ce sera pour ta pomme. Mais je me suis barré avant.

Au bout d'un moment, j'en ai eu marre d'assumer les fonctions de dev senior UI / dev senior back-end / senior tester / senior tout (facile, quand on est le seul dev de la team ). Je me considère comme un dev débutant et je voulais apprendre au contact / en travaillant avec des "vrais devs". Du coup, j'ai changé de boîte (y a quelques mois) et je me demande si c'était pas mieux avant.

Dans la nouvelle team, y a surtout de vrais devs avec une formation de dev. On a une appli à faire, un dev UI, un senior dev qui fait tout (CI, dialogue avec les clients, management de la branche principale, dev d'autres features "plus compliquées", etc.) et un dev full-stack qui passe par là de temps en temps donner des coups de main. Plus bibi.
Petite précision: la majorité des devs vient au départ de la même boîte de presta pas française et ont progressivement été intégrés dans notre boîte. Du coup, ils ont un esprit de corps hyper développé: ils bossent très bien entre eux (la langue y aide), mais les devs tiers (et pas que moi), qui ne parlons pas leur langue, ont plus de mal à être intégré dans leur cercle.
Au départ, on m'a mis sur de la correction de bugs, histoire de me familiariser avec la techno et le code => aucun pb. Puis on m'a confié le dev d'une feature auxiliaire, censée un jour être intégrée au code principal. Ca aurait pu être un signe de confiance, mais là, 5 mois plus tard, je ne le vis pas du tout de cette manière.
En 5 mois, j'ai eu 1 revue de l'archi, à peu près au milieu de la période. 0 revue de code. Et je ne parle pas d'un truc formel: je me serais contenté d'un coup d'oeil en passant du dev senior sur ma branche, mais rien, que dalle, malgré mes demandes. Ma pauvre feature vivote toujours sur sa branche standalone.
Au départ, sa deadline était pour septembre, mais vu que personne à part moi n'a vu le code, il a été décidé de ne pas l'intégrer, ce avec quoi je suis d'accord. Donc c'est repoussé à perpète les oies - on ne sait pas quand - de toute façon, le dev senior n'a pas le temps de checker le code de le feature.

Problème parallèle: je ne me sens pas efficace. Je peux passer une journée à tenter de mettre en place un Mock de serveur, au lieu de laisser tomber et utiliser un vrai serveur test. Mais visiblement, mon manque d'efficacité ne gêne personne vu qu'on ne me le reproche pas. En fait (#grosseBoite), personne n'a l'air de courir pour les deadlines.
Problème principal: j'ai l'impression de stagner sur ce poste. Je suis venu là pour apprendre, pour récolter des feed-backs rapides de la part des devs plus expérimentes que moi. Mais au final, comme avant, je passe surtout beaucoup de temps sur StackOverflow () et je ne suis pas sûr d'avoir appris quelque chose de la part de mes collègues. Et ce n'est pas l'étude du pavé de code existant qui va m'aider. Pour donner un exemple, il y a environ 0 lignes de commentaires dans le code. Je veux bien que certains soient allergiques aux comments inutiles, mais 0, c'est quand même peu. 0 unit tests. Tout ça, avec le Product Owner tout content qui raconte partout que son app marche du tonnerre...
Pire qu'avant: le peu que j'avais appris sur mon poste précédent de "dev tout" n'est pas utilisé: c'était du Java/Python, là je fais du C++/JS. J'ai mis en place la chaîne CI; là le dev senior s'en est entièrement occupé, tout en étant overloadé par ailleurs. En fait, je suis relégué à un poste de "junior débutant avec 0 XP", alors que je sens que je pourrais faire mieux.
Mais plus aucune motivation de passer mes week-ends sur du code, si une fois tous les 6 mois, un grand senior dev de mes deux se pointe avec ses gros sabots et dise que c'est de la marde, qu'il faut tout refaire (#vécuSurPostePrécédent). Je suis ouvert à la critique qui est faite rapidement. Beaucoup moins quand elle s'adresse à un ensemble de code cohérent et qui a été fait sans avoir reçu une seule directive archi de la part de ce même dev senior...

Bref, je n'ai pas le feedback quotidien / hebdo auquel je m'attendais en étant dans une team de "vrais devs". Je n'ai pas l'impression d'apprendre ou de faire quelque chose qui a du sens. J'ai moins de responsabilités. Globalement, je me fais chier et je ne vois de perspectives d'évolution dans cette team: le line manager (#structureMatricielle #grosseBoite) m'a annoncé qu'il faudra que je reste minimum 2 ans dans ce poste de junior avant de ... de quoi d'ailleurs? Euh... je me considère junior, mais j'ai quand même 3 ans d'XP derrière moi. OK, ce n'était pas au sein d'une team de devs, mais j'ai quand même pissé du code qui fonctionnait. Ca me fait franchement chier de redémarrer à partir de 0.
=> est-ce normal, docteur? est-ce normal que le dev senior ne mette pas / peu le nez dans ce que fait le junior?

Mais je suis plutôt bien payé, donc je suppose que je ne devrais pas me plaindre et commencer à travailler sur des projets perso sur du temps que je passe dans la boite... => que me conseillerez-vous? Avez-vous des XP semblables de gens qui bossent directement pour le client final?
En fait, je me pose même la question de repartir sur des études d'info... quitte à être considéré en tant que junior, autant l'être avec un diplôme...

[Pyramidev]

Bonjour.

Dans la nouvelle team, y a surtout de vrais devs avec une formation de dev. On a une appli à faire, un dev UI, un senior dev qui fait tout (CI, dialogue avec les clients, management de la branche principale, dev d'autres features "plus compliquées", etc.) et un dev full-stack qui passe par là de temps en temps donner des coups de main. Plus bibi.
[...]
En 5 mois, j'ai eu 1 revue de l'archi, à peu près au milieu de la période. 0 revue de code. Et je ne parle pas d'un truc formel: je me serais contenté d'un coup d'oeil en passant du dev senior sur ma branche, mais rien, que dalle, malgré mes demandes. Ma pauvre feature vivote toujours sur sa branche standalone.
Au départ, sa deadline était pour septembre, mais vu que personne à part moi n'a vu le code, il a été décidé de ne pas l'intégrer, ce avec quoi je suis d'accord. Donc c'est repoussé à perpète les oies - on ne sait pas quand - de toute façon, le dev senior n'a pas le temps de checker le code de le feature.
[...]
=> est-ce normal, docteur? est-ce normal que le dev senior ne mette pas / peu le nez dans ce que fait le junior?

Il y a un problème organisationnel dans l'équipe. Quand une nouvelle personne arrive, il faut l'intégrer, quitte à reporter d'autres tâches à plus tard. C'est un investissement pour l'avenir. Ce n'est donc pas normal qu'ils laissent ton travail dans une branche qu'ils laissent mourir.
À lire ton message, le développeur sénior est trop chargé. Il faudrait que ton équipe se débrouille pour corriger son organisation. Il y a plusieurs pistes :

1. Si c'est possible, décharger le développeur sénior pour qu'il ait le temps de relire ton code. « personne n'a l'air de courir pour les deadlines » ? Eh bien, dans ce cas, on reporte certaines fonctionnalités que le développeur sénior doit développer.
2. Sinon, si c'est possible, confier la relecture de ton code à un autre développeur que le sénior.
3. Sinon, dans le pire des cas, au bout d'un moment, même sans relecture, il faudrait fusionner ton travail vers la branche principale. De toute façon, si le code existant a « 0 unit tests », c'est que le code existant est déjà plus ou moins du niveau junior.

[Marco46]

=> est-ce normal, docteur? est-ce normal que le dev senior ne mette pas / peu le nez dans ce que fait le junior?

Bah non mais une feature branch de 5 mois c'est juste du grand n'importe quoi. D'ailleurs au bout de 5 mois ça représente quoi comme volume ? En terme de lignes de codes ? 1000 ? 5000 ? 10 000 ?

Tu parles de CI, l'intégration continue c'est pas le fait d'avoir installé un Jenkins, c'est le fait d'intégrer les branches de travail de chaque dev dans la mainline tous les jours. Ça nécessite obligatoirement d'avoir des TU qui couvrent suffisamment le fonctionnel pour s'assurer de ne rien péter à chaque rebase / merge / réso de conflits, et ça nécessite obligatoirement d'avoir du feature fliping pour contrôler le périmètre fonctionnel de ce que vous passez en prod.

Dans ce contexte, une merge request / pull request quotidienne ça représente au grand maximum un volume d'une centaine de lignes de code. Et du coup une code review est possible en quelques minutes.

Donc il n'y a pas d'intégration continue dans l'organisation dans laquelle tu évolues. Et j'imagine même pas comment doivent se passer les déploiements dans un tel contexte.

Les dysfonctionnements que tu évoques sont tellement nombreux que tu devrais chercher un autre job, tu n'es pas dans une bonne organisation pour apprendre.

En fait (#grosseBoite), personne n'a l'air de courir pour les deadlines.

Je ne vois pas le rapport. De mon expérience c'est même généralement le contraire, dans une grande boite il y a beaucoup de personnels chefs de ceci ou de cela qui contrôlent les plannings et font du reporting dans tous les sens. J'ai encore jamais vu une telle chose (5 mois / homme de budget en mode invisible) dans une organisation de grande taille et j'en ai fait plusieurs grosses.

En conclusion :

- est-ce que la situation que je rencontre est commune dans le milieu?

Ça existe mais de là à dire que c'est la norme non.

- Ou est-ce que je vis une expérience pourrie?

Disons que pour être plus pourrie il faudrait ajouter des choses de type harcèlement, management par la pression, etc ...

- Et où aller avec tout ça? Should I stay ou should I go?

Tu devrais trouver un autre job.

Si les technos sur lesquelles tu bosses sont récentes et demandées par le marché avec 2 ou 3 ans d'xp tu n'auras aucun mal à trouver autre chose. Si tu travailles sur des technos plus anciennes ça peut être plus compliqué. Après ça dépend aussi énormément de ton bassin d'emploi. Si tu es dans une grande zone urbaine (Paris Lyon etc ...) tu n'auras pas de soucis.

[Plop55]

Merci beaucoup pour vos retours: ça me permet de relativiser un peu et de remettre dans le contexte du monde merveilleux de la "vraie" info.

Si les technos sur lesquelles tu bosses sont récentes et demandées par le marché avec 2 ou 3 ans d'xp tu n'auras aucun mal à trouver autre chose.

Sur le papier, oui - dans les faits, hmpf. Simulation scientifique / data science. Sachant, ce que j'ai surtout fait, c'est pisser du code pour parser des fichiers texte, et jouer avec des librairies tierces pas connues. Java 8, un peu de REST, un peu de Spring, du C++pas récent (ça existe le C++ récent ::p, et du React. D'où ma crainte d'abandonner un poste au chaud bien payé et ne rien trouver derrière. Objectivement parlant, je ne suis pas un 0 strict en info, mais je suis quand même un epsilon pas bien grand.

Bah non mais une feature branch de 5 mois c'est juste du grand n'importe quoi. D'ailleurs au bout de 5 mois ça représente quoi comme volume ? En terme de lignes de codes ? 1000 ? 5000 ? 10 000 ?

Plutôt dans les 3000, en considérant que j'ai craqué: plus envie de pisser du code, si c'est pour le mettre d'un bloc à la poubelle.

Donc il n'y a pas d'intégration continue dans l'organisation dans laquelle tu évolues. Et j'imagine même pas comment doivent se passer les déploiements dans un tel contexte.

La chaîne CI mise en place par le senior consiste aujourd'hui à checker la branche master uniquement. Branche qui est gérée entièrement par le senior, qui merge nos branches en gros toutes les 2 semaines. (ma feature de malheur exceptée).

De mon expérience c'est même généralement le contraire, dans une grande boite il y a beaucoup de personnels chefs de ceci ou de cela qui contrôlent les plannings et font du reporting dans tous les sens.

En fait, moi, c'est le contraire. Je bosse dans l'industrie, dans la R&D, et j'ai toujours vu des gens payés à rien foutre avec des deadlines qui glissent, qui glissent... A titre d'exemple, le département vient d'acheter une imprimante 3D, alors qu'on a absolument aucune activité en rapport. Mais c'est cool, ça fait genre "on travaille avec les technologies d'avenir". Une fois que les gens sont embauchés, ils peuvent s'endormir jusqu'à la retraite. Je crois que j'ai fait le parcours en sens inverse: normalement, les gens commencent en SSI et finissent par s'endormir chez le client final et moi, je me demande si ça vaut pas le coup de partir et être sous-payé en SSI, quitte à apprendre qqchose.
Contexte actuel: grosse boite dans l'industrie qui fait (beaucoup) de fric avec autre chose que du soft. Mon projet est en "bêta avancée" où il est déployé chez un petit nombre de clients: d'où l'importance du support, assuré uniquement par le dev senior. Mais la deadline est flexible: pour la version actuelle de la bêta, elle a dérapé de 2 mois. Si pression il y a, en tant que dev junior, moi, je ne la sens pas. Plutôt le contraire: je me dis que s'ils avaient VRAIMENT besoin de mains, ils ne me laisseraient pas à me tourner les pouces...

harcèlement, management par la pression, etc ...

Ca, honnêtement, j'aimerais en avoir, de la pression. (oh oui, maîtresse! ) Au moins, j'aurais une vraie bonne raison de me plaindre. Alors que là, je me plains quand même d'être payé à rien foutre.

Si c'est possible, décharger le développeur sénior pour qu'il ait le temps de relire ton code.

A court terme, je vais essayer de pousser là-dessus, quitte à gueuler un peu en public. Marre d'attendre.

[Marco46]

D'où ma crainte d'abandonner un poste au chaud bien payé et ne rien trouver derrière.

Tu es sur des technos demandées mais prends l'xp et le pognon. Après rien ne t'empêche de sonder le marché en posant ton CV on en répondant à quelques annonces.

Plutôt dans les 3000, en considérant que j'ai craqué: plus envie de pisser du code, si c'est pour le mettre d'un bloc à la poubelle.

C'est vraiment beaucoup trop pour une code review. Et tu as écrit des tests ? Les autres n'en font pas mais qu'est-ce qui t'empêche d'en écrire de ton côté ?

La chaîne CI mise en place par le senior consiste aujourd'hui à checker la branche master uniquement. Branche qui est gérée entièrement par le senior, qui merge nos branches en gros toutes les 2 semaines.

Vous n'avez pas de chaîne CI. Vous avez un Jenkins installé. Pas de tests + merge < 1j = pas de CI c'est non-négociable

Ça veut dire quoi checker la branche master ? Ça build et ça déploie ?

Mon projet est en "bêta avancée" où il est déployé chez un petit nombre de clients: d'où l'importance du support, assuré uniquement par le dev senior. Mais la deadline est flexible: pour la version actuelle de la bêta, elle a dérapé de 2 mois.

Sur ça ya aucun soucis. Les deadlines avec périmètres figés en développement logiciels n'ont aucun sens. Tu peux avoir une échéance de livraison à ne pas manquer mais avec un périmètre variable. Ou alors tu peux avoir un périmètre figé mais du coup une échéance variable (it's done when it's done) Cf triangle qualité / couts / délais.

je me dis que s'ils avaient VRAIMENT besoin de mains, ils ne me laisseraient pas à me tourner les pouces...

Ou bien ils estiment qu'ils n'ont pas le temps de s'occuper de toi. Tu devrais utiliser ce temps pour monter en compétence sur les technos utilisées il y a beaucoup de choses à apprendre.

A court terme, je vais essayer de pousser là-dessus, quitte à gueuler un peu en public. Marre d'attendre.

Surtout pas faire ce genre de chose en public !

Qui est ton responsable ? C'est à lui qu'il faut parler de tout ça et au dev senior qui est manifestement le responsable de la partie technique. Demande lui simplement comment tu peux l'aider.

[Plop55]

Ai perdu ma première réponse. Ca m'apprendra à écrire des pavés. Donc, on recommence:
- Unit tests pour ma feature: faits, il y a un petit moment, en espérant que ça pousserait les gens à avoir confiance dans la feature. Personne ne les a regardés. Les E2E sont complexes à mettre en oeuvre: en fait, aujourd'hui, il manque des choses à la feature pour être facilement utilisable par un utilisateur lambda. Choses qui résulteraient dans encore qqs milliers de lignes de code mort, risque que je ne veux pas prendre.

- D'accord pour l'inexistence de notre chaîne CI. Je pense que dans la version finale, elle est censée builder et faire tourner les unit tests sur les branches main-dev (code validé par le dev, updaté tous les sprints en gros) et master (issue de main-dev, updatée à faible fréquence, code stable), puis faire un joli package destiné à être fourni à la team System Tests (sous-traitance distante) + déployé manuellement sur du hardware de test chez nous (réseau séparé, pas accessible depuis le Jenkins).

- Pas de pb avec une deadline qui glisse, surtout que c'était dû à des facteurs tiers. Le pb est que ça aurait dû / pu libérer du temps du dev senior, et que ça n'a pas été le cas.

- Ils (dev senior + project lead) n'ont clairement pas le temps de s'occuper de moi. Ils sont là pour répondre ponctuellement à des questions, je peux leur proposer des choses, mais est-ce "s'occuper de qq1"? Qu'est-ce que ça veut dire, "s'occuper de qq1"?

Contexte actuel: les bugs de l'appli actuelle sont refilés soit au dev senior, soit à un dev tiers (junior ++, officiellement sur un autre projet), qui a codé toute la UI de l'appli et qui est beaucoup plus fluent en JS que moi. Et #modeJaloux, le dev senior trouve magiquement le temps de valider les corrections de bugs soumises par le dev tiers.
Ce mois-ci, je suis "responsable" des unit tests de l'appli. Je suis content, car on a enfin commencé à résorber notre dette technique. Mais ça résulte en 3000 autres lignes de code mort, qui ne seront jamais lues par personne. Call me Necromancer. Rendons justice au dev senior, qui a au moins parcouru les modifs que les tests ont entraîné sur le code principal.

En fait, entre mes invocations de zombies, j'ai parcouru le forum (#noob) et je me rends compte que ma situation n'est 1) pas nouvelle et 2) pas si terrible que ça. Je veux me rendre utile et je n'y arrive pas (1). Je suis payé pour pas faire grand chose (2) et je suis "en quête de sens" (1): "chouette, aujourd'hui, au boulot, j'ai bu du café et j'ai accidentellement (merci Google) appris l'existence des smart pointers". Ce n'est pas ça qui va révolutionner le monde mon projet. Ca va peut-être améliorer mon code. Mais j'ai le sentiment que les connaissances que j'arrive à glaner sont accidentelles et ne sont pas dues au travail que je fais (je ne suis pas clair là, je crois...).

Question philosophique à 1 euro: comment s'améliorer si personne ne nous dit ce qu'on a fait de mal / bien?
Autre question: comment gagner de l'XP dans ces conditions? Commencer un projet perso, qui n'a rien à voir, du type 'coder un morpion en C++'? Ajouter du code mort à ma feature?

[Pyramidev]

"chouette, aujourd'hui, au boulot, j'ai bu du café et j'ai accidentellement (merci Google) appris l'existence des smart pointers". Ce n'est pas ça qui va révolutionner le monde mon projet. Ca va peut-être améliorer mon code. Mais j'ai le sentiment que les connaissances que j'arrive à glaner sont accidentelles et ne sont pas dues au travail que je fais (je ne suis pas clair là, je crois...).

Question philosophique à 1 euro: comment s'améliorer si personne ne nous dit ce qu'on a fait de mal / bien?
Autre question: comment gagner de l'XP dans ces conditions? Commencer un projet perso, qui n'a rien à voir, du type 'coder un morpion en C++'? Ajouter du code mort à ma feature?

Il faut lire beaucoup de théorie et essayer de mettre en pratique au quotidien la partie qui t'est utile.

Par exemple, tu peux lire C++ Core Guidelines qui contient plein de bonnes pratiques, dont beaucoup sont spécifiques au C++.

Dans le cas spécial des smart pointers, je vais faire la pub pour mon tutoriel : Comment éviter facilement les déréférencements de pointeur nul et les fuites de mémoire en C++

Tu peux aussi demander conseil ou débattre sur notre Forum C++.

[Plop55]

Thx! Je confesse avoir aussi jeté des coups d'oeil aux tutoriels "C++ pr temps réel" (mon topic de travail actuel). => gogo implémentation d'améliorations incrémentielle.
Incrémentielle, à cause que j'ai déjà tenté le très diplomatique "désolé, le code fonctionne, mais, ne le prenez pas mal, je veux enlever tous vos singletons cacaboudin et tout refactorer" et que ça n'a pas marché Il me fut répondu que le truc marchait, donc on n'y touchait pas.

Bref, question subsidiaire: j'ai entendu parler d'une pratique venant d'autres milieux que le dev et qui consisterait à avoir un mentor, pas forcément appartenant à la team de travail, avec qui le jeune padawan aurait des entretiens informels réguliers. Le mentor pourrait donner son avis sur différents sujets, du type, comment il ferait pour faire tel ou tel truc, qu'est-ce qu'il pense de telle techno, etc. Il pourrait montrer ce sur quoi il travaille en ce moment, histoire de donner des idées au jeune padawan.
Bon, ok, ça consiste à étendre le concept de maître de stage et /ou formaliser des discussions qui , de toute façon, devraient avoir lieu dans un environnement sain (autour de la machine à café), mais tout de même, avez-vous déjà entendu parler d'un tel concept?

[Xelland]

Ou bien ils estiment qu'ils n'ont pas le temps de s'occuper de toi.

L'excuse du temps est souvent celle donnée

Il y a aussi ceux qui ne savent pas former les autres (savoir adapter les mots et les concepts à différentes personnes, ce n'est pas donné à tout le monde) et ceux qui ne veulent pas former (faudrait pas que l'autre devienne meilleur)

[Mat.M]

Il y a un problème organisationnel dans l'équipe.

je suis bien d'accord avec cette remarque, en ayant lu rapidement le premier message.
Malheureusement d'après mon expérience cela semble être le cas pour de nombreuses (petites) entreprises
Sinon merci pour le lien sur les "guidelines" en C++ cela va m'être très utile

Question philosophique à 1 euro: comment s'améliorer si personne ne nous dit ce qu'on a fait de mal / bien?
Autre question: comment gagner de l'XP dans ces conditions? Commencer un projet perso, qui n'a rien à voir, du type 'coder un morpion en C++'? Ajouter du code mort à ma feature?

Je retourne la question philosophique dans l'autre sens qu'est-ce bien faire les choses dans le développement informatique ? Du code clair donc avec des relectures de codes, l'emploi de méthodes AGILE, un projet qui tourne sans bugs et plantages ?

[sacdebille]

Il faut contextualiser ta problématique à la réalité géographique.
Si tu es Roanne ou marouille sur cher alors tu devrais peut-être rester dans ta boite.

En revanche, si tu es sur Paris Marseille ou Lausanne alors tu peux changer facilement.
Un dev qui sait faire du Java Anagular Python et qui est Autonome ca se revend bien. D'ailleurs ma boite en recherche désespérément.

[Plop55]

Je retourne la question philosophique dans l'autre sens qu'est-ce bien faire les choses dans le développement informatique ? Du code clair donc avec des relectures de codes, l'emploi de méthodes AGILE, un projet qui tourne sans bugs et plantages ?

Dans le monde merveilleux de l'imaginaire collectif, on aurait tout ça en même temps. Et du code beau et efficace. Et c'est là que j'ai du mal à savoir ce qu'est un code efficace, sans feedback: pour implémenter une somme d'entiers, on peut faire une boucle et ajouter 1 à chaque itération. Ou alors on peut utiliser l'opérateur "+". Ou alors le faire bit-wise. Quelle serait la meilleure méthode? Du coup, on doit écumer les forums, on fait des petits tests sur des bouts de table et on perd du temps d'une certaine façon.

Concernant l'orga, objectivement, on peut dire qd on fait de l'agile ou qd on en fait pas / peu / à la sauce béarnaise. Je vois ce qu'est un backlog bien tenu et j'ai déjà vu des backlogs dégueux. Donc question méthodo pure, je vois à peu près ce qu'est un projet bien conduit. Concernant les bugs, IMHO, un projet sans bugs, ça n'existe pas. Ou alors, ça consiste à coder une fonction somme et encore, bonjour l'overflow. Donc un projet bien fait serait un projet qui:
- d'une part, minimiserait les bugs via une implémentation "intelligente" (on a réfléchi un minimum à ce qu'on faisait) + des tests;
- et, d'autre part, aurait une gestion (intelligente) des bugs rencontrés: processus de remontée du bug bien défini, distribution des tâches dans la team, capitalisation et tests implémentes pour éviter de reproduire, etc.
Dans mon cas, on a un projet qui tourne avec peu de bugs remontés, mais qui sont mal gérés: pas de capitalisation, le savoir reste dans la tête du dev senior essentiellement. A titre d'exemple, ça se traduit par des variables ayant des valeurs magiques, sans que la raison d'avoir cette valeur-là soit documentée quelque part :/ . Mais là aussi, je vois à peu près ce qu'il manque pour faire de la qualité. C'est qui me manque, c'est plus une référence en termes de bonnes / mauvaises pratiques de code, je pense.

En revanche, si tu es sur Paris Marseille ou Lausanne alors tu peux changer facilement.

Je me suis vendu à l'ami teuton, qui paye plutôt bien des gens aussi incompétents que moi A l'époque, j'avais la bonne raison du manque d'XP / reconversion pro pour ne pas réussir à me faire embaucher en France.

[Mat.M]

bonsoir Plop55 merci pour la réponse.
Pour ce qui est d'être efficace eh bien je suis en train de concevoir un jeu 3d avec un éditeur de scène sous Direct3d et j'en bave un peu avec les transformations géométriques.
Donc être efficace ou bien ça fonctionne ou bien ça ne fonctionne pas.
Parce que ça finira par être visible à l'écran et le joueur ne paiera pas pour mon jeu
Cependant en entreprise c'est pas tout à fait le même schéma.

Pour ce qui est de la capitalisation je suis à 100% d'accord et je ne comprends pas pourquoi des grosses SSII ( par exemple Cap, Atos..) justement ne capitalisent pas sur leur savoir faire en développant leur propre middleware plutôt que de payer des royalties à SAP ou SAGE.
Mais ça c'est un autre sujet
Ah à propos de capitalisation, ça me fait penser aux propos de Axel de Tarlé l'autre jour qui nous disait à la radio que lors des ruées vers l'Or lors des sècles précédents ceux qui gagnérent le plus d'argent ce n'est pas les prospecteurs mais les vendeurs de pelles et poiches

[Invité]

Il y a une certaine inertie dans les structures informatiques. De ce que tu décris, aucune raison que cela change dans les 3 mois, 6 mois, 12 mois.
Et non, cela ne correspond pas à ce que vivent la plupart des devs. L'interaction avec ses collègues c'est tous les jours, normalement.
Honnêtement, j'ai connu un ou deux cas similaires : les types au bout de quelques années sont devenus fous. Ton poste est un placard doré. Au delà de ton bien-être psychologique, tu vas péricliter techniquement et professionnellement alors même qu'à ton âge on devrait être stimulé quotidiennement. Tu peux toujours voir le problème avec la RH : ils sont là pour ça.

[Plop55]

Merci pour vos retours. Et je retiens l'expression de "placard doré", j'aime beaucoup.

[Mat.M]

Merci pour vos retours. Et je retiens l'expression de "placard doré", j'aime beaucoup.

le sujet étant "conseils pour évolution de poste" attention de ne pas sombrer dans l'ennui profond
Il faudrait éviter le bore-out c'est préférable.