Discussion :

[nfluch]

Expliques nous comment tu fais pour t'organiser dans ton travail et comment tu divises tes phases de conception, le pb de temps perdu vient potentiellement de là

[MiaowZedong]

Bonjour,

Je relance de quinze car je suis toujours dans une situation difficile. Malgré mes efforts je n'arrive pas à faire mieux, c'est donc toujours compliqué. Je sens que je stagne, sans arriver à justifier mon expérience ni mon salaire.

J'avais posé cette question restée sans réponse :


J'en suis à un stade où je doute et me demande si je fais le bon métier, ou si je ne ferai pas mieux de me réorienter. Seulement vers quoi, quelles sont les possibilités ? Je souhaiterais rester dans cette branche car malgré les difficultés mon domaine me plaît. Mais à mon âge (la trentaine) et avec ma situation familiale, je ne peux pas tout claquer pour apprendre autre chose. donc que faire ? Je n'en ai aucune idée, je regrette le collège où il y avait un conseiller d'orientation...

Toutes les idées sont les bienvenues, merci pour vos conseils !

À te lire, je me demande si tu ne souffres pas tout simplement d'un manque de confiance en toi?

Si tu n'as pas confiance en tes capacités et tes choix techniques, tu vas perdre du temps à te sur-documenter, faire plus d'éssais que nécessaire, rester bloqué en attendant des conseils => perte de productivité.

[philippe.peso]

Donc je ne vois pas pourquoi le problème disparaîtrait en changeant de domain.

Certes mais il existe bien des métiers qui sont moins soumis à la pression de la date limite non ? Exemple, les formateurs, ils ont d'autres contraintes mais il ne me semble pas que le temps soit leur principal adversaire. Les commerciaux aussi.

Expliques nous comment tu fais pour t'organiser dans ton travail et comment tu divises tes phases de conception, le pb de temps perdu vient potentiellement de là

Je développe pas-à-pas, je teste chaque étape. Je sais que des collègues développent "au kilomètre" et débugguent ensuite les cas qui sont en erreur, ce n'est pas ma façon de faire. J'essaye de n'oublier aucun cas, de tester toutes les solutions possibles, de vérifier qu'il n'y a pas de trou dans la raquette. Mais je n'ai pas de méthode type en tout cas, quand j'ai pas mal de pistes, je fais au feeling, en essayant de partir du début pour arriver à la fin, sans m'éparpiller.

À te lire, je me demande si tu ne souffres pas tout simplement d'un manque de confiance en toi?

Si tu n'as pas confiance en tes capacités et tes choix techniques, tu vas perdre du temps à te sur-documenter, faire plus d'éssais que nécessaire, rester bloqué en attendant des conseils => perte de productivité.

Ca c'est fort probable, mais le savoir n'arrange pas la situation D'où le doute concernant ma place dans la métier. Mais ta description de la méthode correspond bien à mon cas, oui. J'ajoute juste qu'étant étourdi, je fais pas mal d'erreurs : par exemple je remonte un mauvais champ de la bdd et ensuite je me demande pourquoi ça ne fonctionne pas, ou bien j'oublie de spécifier le retour d'une fonction... Je connais mes qualités et mes faiblesses, ma question est : suis-je fait pour continuer dans cette voie ? Et ça me tourne dans la tête depuis plusieurs semaines...

[nfluch]

Je développe pas-à-pas, je teste chaque étape. Je sais que des collègues développent "au kilomètre" et débugguent ensuite les cas qui sont en erreur, ce n'est pas ma façon de faire. J'essaye de n'oublier aucun cas, de tester toutes les solutions possibles, de vérifier qu'il n'y a pas de trou dans la raquette. Mais je n'ai pas de méthode type en tout cas, quand j'ai pas mal de pistes, je fais au feeling, en essayant de partir du début pour arriver à la fin, sans m'éparpiller.

Je commence à piger, il vaut mieux réfléchir avant de commencer à développer quoique ce soit, perso je réfléchi énormément avant
de telle sorte à ne pas avoir à le faire durant le développement
En fait il faut faire en sorte de t'imaginer ton code, tes fonctions, tes objets, potentiellement une mise en cache avant de le commencer, car si tu commences à réfléchir pendant le développement, tu vas déjà peut-être partir sur de mauvaises pistes et ensuite pour tout refaire
Visiblement tu réfléchis à une petite partie pour la réaliser et ensuite une autre phase de réflexion pour une autre réalisation et ainsi de suite.
Or dans une appli tout est censé s'imbriquer, donc il vaut mieux penser l'ensemble avant de réellement commencer à développer.

Ca c'est fort probable, mais le savoir n'arrange pas la situation D'où le doute concernant ma place dans la métier. Mais ta description de la méthode correspond bien à mon cas, oui. J'ajoute juste qu'étant étourdi, je fais pas mal d'erreurs : par exemple je remonte un mauvais champ de la bdd et ensuite je me demande pourquoi ça ne fonctionne pas, ou bien j'oublie de spécifier le retour d'une fonction... Je connais mes qualités et mes faiblesses, ma question est : suis-je fait pour continuer dans cette voie ? Et ça me tourne dans la tête depuis plusieurs semaines...

Ca, ça arrive à tout le monde de faire quelques erreurs.
Il faut simplement un peu de méthodologie et ne pas partir tête baissée dès le début, la réflexion est très importante, la phase d'analyse aussi.

[Ubiquité]

Je commence à piger, il vaut mieux réfléchir avant de commencer à développer quoique ce soit, perso je réfléchi énormément avant
de telle sorte à ne pas avoir à le faire durant le développement
En fait il faut faire en sorte de t'imaginer ton code, tes fonctions, tes objets, potentiellement une mise en cache avant de le commencer, car si tu commences à réfléchir pendant le développement, tu vas déjà peut-être partir sur de mauvaises pistes et ensuite pour tout refaire
Visiblement tu réfléchis à une petite partie pour la réaliser et ensuite une autre phase de réflexion pour une autre réalisation et ainsi de suite.
Or dans une appli tout est censé s'imbriquer, donc il vaut mieux penser l'ensemble avant de réellement commencer à développer.

J'aurai plutôt dis le contraire. Quand il dit qu'il avance pas à pas, ca veut dire qu'il avance peut-être trop prudemment.

[Drizzt [Drone38]]

Bonjour,

Je vais être un peu moins gentil que la plupart des intervenants de ce post.

Etant du coté de l'encadrement de développeurs, je voit clairement des différences de vitesse entre personnes.
- Il y a les cracks, qui vont vite et bien. Ceux sur qui tu te reposes pour faire avancer ton projet/rattraper le retard.
- Il y a les sprinters, qui vont vite mais qui zappent généralement tous les cas particuliers et qui nécessitent pas mal d'aller retour derrière.
- Il y a les endurants, qui vont lentement mais tu peux presque livrer en production derrière, il y a aura très peu de retours.
- Il y a les cas plus délicats, qui vont lentement et qui induisent beaucoup de retours.

Si tu es dans les 3 premieres catégories, pas besoin de s'inquieter. Dans les catégories 2 et 3, ton manager aura toujours à critiquer, de façon positive ou négative selon sa façon de manager, mais tu es dans la majorité pas besoin de s'inquieter (ce qui ne veut pas dire que tu ne dois pas essayer de progresser).

Si tu es dans le dernier cas, effectivement tu as soit un gros problème de méthodologie, soit tu n'es pas fais pour développer.
Dans les deux cas il y a des solutions.

Coté méthode, il n'y a pas de méthode miracle, tous ne travaillent pas de la même façon. La clé est de trouver dans ce que tu fais actuellement, ce qui te fait perdre du temps (compréhension initiale, tests unitaires, corrections de bug, compréhension globale...) et travailler la dessus. Ton manager (direct, pas le gars que tu vois une fois par an) dois pouvoir t'aider la dessus, c'est son role.
Par exemple si tu fais plein de tests au fur et à mesure mais que 95% sont ok. N'irais-tu pas plus vite à faire moins de tests quitte à faire un aller retour par la suite ?

Si tu n'es pas fais pour développer, tu peux demander à aller vers d'autres voies : fonctionnel, qualification, exploitabilité par exemple. Je ne pense pas que ta hiérarchie s'oppose à ce changement bien au contraire.


Mon post est un peu caricatural, que ce soit dans les catégorie de dev ou les solutions proposées, il y a bien sur plein de cas particuliers et il faut adapter au contexte projet. Le but était plutot de te donner un point de vue un peu plus cru et moins complaisant. Ne te décourage pas pour autant.

[Bluedeep]

- Il y a les cas plus délicats, qui vont lentement et qui induisent beaucoup de retours..

Tiens je ne connaissais pas ce synonyme.

Ce doit donner des trucs amusants :

- il a senti passer le vent du cas délicat

- un cas délicat du calibre de 40 livres
- la flotte espagnole tirait à cas délicat rouges.
- Dès leur arrivée au bagne de Brest, un cas délicat était fixé à leur cheville

Vraiment, on en apprend tous les jours; mais c'est vrai que "cas délicat" c'est plus joli que "boulet".

[nfluch]

Tiens je ne connaissais pas ce synonyme.

Ce doit donner des trucs amusants :

- il a senti passer le vent du cas délicat

- un cas délicat du calibre de 40 livres
- la flotte espagnole tirait à cas délicat rouges.
- Dès leur arrivée au bagne de Brest, un cas délicat était fixé à leur cheville

Vraiment, on en apprend tous les jours; mais c'est vrai que "cas délicat" c'est plus joli que "boulet".

t'es méchant toi des fois

[Drizzt [Drone38]]

t'es méchant toi des fois

Oui mais c'est drole

[philippe.peso]

Joli résumé. Je pense être dans la catégorie des endurants, enfin j'espère

[philippe.peso]

Bonjour,

Je relance le sujet car j'envisage de changer de société. La mission qui m'avait incité à lancer ce sujet s'est mal terminée, je suis sorti plus tôt que prévu du projet et on m'a directement reproché ma lenteur, sans que j'ai le droit de me défendre (nouvelle société, framework inconnu, spécs imprécises, peu importe tout le retard m'est imputable). Je voudrais éviter de revivre la même expérience...

Je me demande comment signaler au recruteur que je ne recherche pas des missions "rush" où il faut être très rapide et de suite, mais plutôt des missions où on peut avoir le temps de monter en compétence, et où la qualité prime sur la vitesse, voire la possibilité de perdre du temps avec une formation (!) pour ensuite mieux développer.

Avec mon expérience (5 ans), on ne présente souvent des projets avec des délais courts, puisque l'expérience est censée refléter la maîtrise de son sujet, et donc ma vélocité. Mais je ne peux pas directement dire que cela ne me convient pas ! Et je ne peux pas dire non plus que je suis plus lent que ce que le profil qu'ils recherchent, à moins de voir écourter l'entretien...

Je voudrais donc arriver à indiquer à mon interlocuteur que cette lenteur fait partie de mes lacunes, et qu'il doit l'intégrer s'il me fait une proposition, pour me placer sur des projets qui me correspondent. Mais je ne sais pas comment présenter cela sans me tirer une balle dans le pied...

Merci pour vos conseils.

[tmanta7]

A priori ton profil semble plus convenir à un client final qui va privilégier la qualité à la quantité, contrairement à la SSII (en règle générale).

Pour moi tu peux très bien le vendre à un entretien, expliquer que dans toutes tes précédentes expériences tu privilégiais le travail bien fait, avec très peu de retour plutôt que de bourriner. Dis leur que t'aimes bien prendre peut-être un peu plus de temps que nécessaire mais qu'au moins ta conception est parfaite et qu'ensuite ton dev sera très propre.

Tu peux par exemple chercher dans un département R&D. Je connais beaucoup de personnes qui travaillent dans ce type de département et qui ne subissent pas de pression, ce qui peut-être pour toi très bénéfique d'après ce que j'ai lu.

[philippe.peso]

Je pensais aussi que la régie était moins pressée, mais je dois avoir la poisse parce que ma mission actuelle (en régie) est la plus urgente de toutes, je fais des journées de 14h tellement il faut faire vite...

Concernant la R&D, c'est la bonne période ces temps-ci ? Sur toutes les annonces que je vois depuis plusieurs semaines, très peu sont pour ce genre de poste, la très grande majorité sont pour des postes de dév pur. D'où mon interrogation sur le fait de dire en entretien que je recherche une mission où on a le temps de faire du beau boulot. En fait je ne dois pas choisir les bons termes, car selon la façon dont on le dit, ça fait très "je recherche un poste de planqué pour faire du 10h-17h avec 2h de pause déjeuner, et sinon vous avez un baby foot ?"

[Glutinus]

Moui... ça veut souvent pas dire grand-chose. Des fois une régie enchaîne une autre qui a bouffé tout le budget en y allant tranquillou. Et qui est parti sans laisser une once de doc ou de commentaire.

De manière générale les boîtes veulent tout tout de suite. C'est normalement charge aux SSII de lever les boucliers et d'expliquer que ce n'est pas possible, que ça prend un process long etc. mais souvent on plie l'échine face aux demandes, car sinon ça passe au voisin qui lui va dire oui-oui.

[tmanta7]

Des journées de 14h ? Faut pas abuser quand même ^^

[MiaowZedong]

Je pensais aussi que la régie était moins pressée, mais je dois avoir la poisse parce que ma mission actuelle (en régie) est la plus urgente de toutes, je fais des journées de 14h tellement il faut faire vite...

Il faut savoir dire non: en régie, à l'inverse du forfait, tu as une obligation de moyens mais pas de résultats. Et les moyens que tu dois fournir incluent normalement, pour un cadre, un temps de présence conforme au nombre d'heures hebdomadaires mentionnés dans ton contrat +-10%.

Si ça ne suffit pas à boucler le projet, ce n'est pas ton problème, le client a mal budgeté (il faut éviter de lui balancer ça tout cru dans la figure, mais il doit le comprendre quand même).

Concernant la R&D, c'est la bonne période ces temps-ci ? Sur toutes les annonces que je vois depuis plusieurs semaines, très peu sont pour ce genre de poste, la très grande majorité sont pour des postes de dév pur. D'où mon interrogation sur le fait de dire en entretien que je recherche une mission où on a le temps de faire du beau boulot. En fait je ne dois pas choisir les bons termes, car selon la façon dont on le dit, ça fait très "je recherche un poste de planqué pour faire du 10h-17h avec 2h de pause déjeuner, et sinon vous avez un baby foot ?"

Il y a moins de postes en R&D qu'en informatique de gestion, c'est normal.

Plutôt que de dire que tu veux avoir le temps de faire du beau boulot, tu ferais mieux de dire que tu est passioné d'info pure et que tu veux pouvoir faire des choses réellement innovantes plutot que de pisser des lignes de Java.