Discussion :

[SurferIX]

L'article original en Anglais est plein de choses sympa, comme "A senior developer is intimately familiar with their own failure" ou encore "A senior developer has fallen out of love of the complexity which dominates the intermediate, and is obsessed with simplicity", et mon préféré "A senior developer thinks in terms of “context” when applying theory".

Mais j'ai connu, dans ce classement, des seniors de 25 ans et des débutants de 50. C'est le seul reproche que je peut faire à l'article original. Sinon, il appuie sur les points importants. Bon article, merci du lien.

Comme toujours ce sont des chiffres génériques, et je suis d'accord avec toi.

J'ai connu un type qui n'avait pas de diplômes car il n'aimait pas l'école, et pourtant était plus intelligent et compétent que moi, et de loin. Il m'avait affirmé quelques vérités qu'il avait comprises (comme "en base de données, il ne faut jamais rien réellement effacer") alors qu'il avait 20 ans, et que j'ai comprises... 10 ans après (avec mon expérience).

Seulement il ne savait pas gérer le côté relationnel / commercial... et passait pour un idiot aux yeux de ses patrons.
Si, depuis une dizaine d'années que je ne l'ai pas vu, il a su apprendre à gérer ce côté commercial / relationnel - et je pense qu'il a dû savoir, alors il doit être arrivé bien plus loin que moi actuellement... tiens d'ailleurs je vais voir ce qu'il est devenu !

[Tr0n33]

Ah ah exactement la réflexion que je me faisais ces derniers temps (de junior à intermédiaire dans mon cas). Arriver à moins penser en terme de technique, sachant que la technique s'adapte au besoin, et non l'inverse. Enfin il m'aura fallu en passer par là pour arriver à allier performance/élégance et pertinence. Enfin l'expérience, et surtout la capacité à se remettre en question et accepter de se heurter à des murs. Comme le dit Tr0n33

"2- Considérez l'échec comme un mur infranchissable qui est un boulet à traîner plutôt qu'un apport d’expérience."

C'est cette mentalité qui fait qu'une personne n'évolue pas. Plus on essaie d'éviter l'echec moins on comprend les raisons qui nous y amènent. Tel que je l'ai ressenti on nous encourage souvent trop à performer plutôt qu'à essayer par nos propres moyens.

C'est exactement ça. Et cette notion est typique de la société civile française (et s'applique parfaitement à tous les métiers). Comme l'échec devient un indicateur social, tout le monde a peur d'entreprendre. Les hiérarchies noient donc les responsabilités ou les catégorisent pour que personne ne doivent assumer l'échec dans le meilleur des cas; dans le pire, on use et abuse de la politique du bouc émissaire. Beaucoup font des retours sur expérience mais l'image de l'échec colle à la peau d'une équipe ou d'un individu à chaque fois. Au lieu d'évoluer, on cantonne ainsi des développeurs à des rôles. Effectivement, un individu qui ne fait pas ça : n'évoluera jamais. Je vous enjoins, si cela vous intéresse, à lire le chapitre sur l'allégorie du Grand Dragon dans "Ainsi parla Zarathoustra" de Nietzsche (je n'ai pas le chapitre exact et cela prend une dizaine de minutes) : il évoque une façon théorique et imagée de remettre en cause ses propres valeurs (et donc s'applique assez bien par extension à une forme de logique pour évoluer face à une angoisse de l'échec imposé par la société).

Pour la catégorie des développeurs patchworks, je suis plus mitigé, c'est souvent un problème qui n'a pas trait au développement mais à l'environnement dans lequel on évolue. Certaines personnes voient l'ennui comme un frein, alors que très personnellement je le vois comme une chance de créativité. Certains se cantonnent à ce qu'on leur demande, ou n'ont que peu d'intérêt. C'est là, tout l'art d'une bonne gestion humaine des équipes ou des employés. Le pair programming m'a permis plusieurs fois de faire changer la façon de voir de certains développeurs patchworks. Bref, c'est une problématique très "ressources humaines" au final.

Pour beaucoup l'âge d'or du développeur, c'est à dire au moment ou il est à son apogée, c'est vers les 30-35 ans, soit en gros 10-15 ans d’expérience. C'est peut être faux mais pas aberrant, la vivacité d'esprit, la motivation, tout ça... Hors le problème c'est que tu es payé selon ton expérience, donc du coup à un moment donné ton cout dépasse ta valeur ajoutée supposée.

Ah ça... D'ailleurs c'est rédhibitoire dans ma négociation salariale

[arkhamon]

Bonjour,
le débat est sympa et ça reste dans le sujet, j'aime.
Junior, sénior, confirmé... selon quel critère ? Là est la question ! Si "la valeur n'attend pas le nombre des années", on en peut quand même pas faire abstraction de l'impact de l'âge sur l'esprit (on gagne probablement en sagesse ça s'appelle l'expérience), mais on perd probablement en rapidité d'esprit et en capacités d'apprentissage et/ou de création (à part quelques énergumènes que j'admire). Et je peux me permettre de dire ça parce que je suis à 48 ans moins rapide à piger et moins "curieux" qu'à 20 ans. Encore que pour la curiosité, je continue à passer des nuits à suivre des liens sur Wikipedia...).

Donc il y a une différence indéniable entre juniors et séniors. Maintenant il faut se poser une question : que veut-on du salarié ? Eliminons tout de suite le mouton à 5 pattes et le sacré Graal. Eliminons aussi les aberrations comme "cherche développeur C# niveau ingenieur ou bac+5", pas besoin de ça. A-t-on besoin de la fougue de la jeunesse, ou la sagesse des plus anciens ? Avoir les deux sera certainement un atout. Je rejoins (un peu) la personne qui disait qu'il fallait des "vieux" pour encadrer des "jeunes". La sagesse sachant piloter la fougue donnera à mon avis un taux de réussite élevé. Pour peu que chacun ait un peu de diplomatie (ça faut encore que j'apprenne ).

Dernier point, il faut arréter de considérer que développeur est "une phase entre le débutant et le CP". Il faut reprendre à l'esprit un fil d'il y a quelques temps qui critiquait cette manie de vouloir a tout prix faire évoluer les gens. Certaines personnes très compétentes dnas un domaine deviennent incompétentes dans celui "au dessus". Un bon développeur ne fera pas forcément un bon CP, laissons le alors faire du bon boulot de dev.

[Tr0n33]

Je rejoins (un peu) la personne qui disait qu'il fallait des "vieux" pour encadrer des "jeunes". La sagesse sachant piloter la fougue donnera à mon avis un taux de réussite élevé. Pour peu que chacun aitr un peu de diplomatie (ça faut encore que j'apprenne ).

Un peu juste ? (cétait moi, sniff) Oui l'interaction sociale, le lien entre les individus et la diversité de compétences/caractères, sont les meilleurs moteurs pour beaucoup d'activités.

Dernier point, il faut arréter de considérer ue développeur est "une phase entre le débutant et le CP". Il faut reprendre à l'esprit un fil d'il y a quelques temps qui critiquait cette manie de vouloir a tout prix faire évoluer les gens. Certaines personnes très compétentes dnas un domaine deviennent incompétentes dans celui "au dessus". Un bon développeur ne fera pas forcément un bon CP, laissons le alors faure du bon boulot de dev.

Alors ça... C'est ce que j'évoquais rapidement. La fameuse voix royale et le fameux principe que j'adore : Principe de Peter, et c'est tellement vrai. D'ailleurs je suis développeur, je deviens expert et formateur (avec une touche de ressources humaines) et certainement pas Chef de Projet. J'en avais discuté avec un RH qui m'avait refusé quand j'étais jeune. Je ne rentrais pas dans la bonne case avec ma réponse qui disait que je ne voulais pas devenir CP ou Manager d'équipe.

Mais le souci va plus loin : les grilles de salaire ont un gap entre le CP et le développeur expert. Vous avez toujours une marge plus importante de progression côté CP. J'en ai récemment discuté avec un Manager, et j'avoue gueuler de plus en plus auprès des syndicats sur ce sujet lui aussi bien français. En France, un développeur de 50 ans est une peur pour la hiérarchie. Aux USA, c'est une mine d'or et un trésor d'expérience. Pour vous rassurer, non, à 50 ans, on est encore jeune dans notre société (malgré tout ce qui se dit, je cite souvent l'exemple de ma modeste maman, qui a 51 ans a repris ses études, qui à 61 ans cette année, qui est devenu de secrétaire au comité d'entreprise de la SNCF à doctorante en civilisation et langue arabe, et qui est désormais une experte reconnue de l'armée andalouse du 13e siècle. Croyez moi, elle réfléchit bien mieux que 95% des jeunes de l'université. Les exemples sont légions en réalité, et c'est le poids de la société qui fait croire qu'on est cramé à 50 ans. Je n'y crois pas un seul instant.).

[SurferIX]

Tel que je l'ai ressenti on nous encourage souvent trop à performer plutôt qu'à essayer par nos propres moyens.

Aaaaaaaaaaaaaargh -> Clique sur le lien : performer

[Glutinus]

Objectivement, en terme de rapport qualité/prix, c'est difficile de concurrencer un JD. Et vu qu'on est gouverner par des comptables...

On en est sur encore un autre niveau d'abstraction.
Le problème est effectivement qu'en France, on est plutôt gouvernés par le résultat, mais pas le résultat financier (cette appli va nous faire gagner / économiser n millions d'euros €), mais quelque chose de visible ASAP.

Une étude sur le ROI d'une action invisible ? poubelle !

Si tu proposes le truc du genre "je vais faire quelque chose, vous verrez pas le résultat, mais après-demain, ça va nous faire gagner 5 semaines par projet" le mec il te rigole à la gueule en disant que tu veux passer les 48h à glander sur internet.

Micro-anecdote :

un client éditeur E, une fois une installation faite, me demande de revenir chez eux après avoir fait une installation chez C. Il est 16h, le client C est pas loin de chez moi, je dis que je vais rentrer à la maison, E refuse et veut que je fasse 1h de transport quitte à rester bosser 1h et repartir faire une heure. Heureusement pour moi, panne de RER. Je rentre chez moi à 16h30. Conscienscieux, je décide de bosser jusqu'à 18h30 en calbute avec un coca à la main. J'ai juste les fichiers SQL qui composent 99% de mon projet.

Je fais alors tout le travail administratif que j'ai prévu : commentaires, suppression d'élément inutile, indentation, "indexation", inventaire etc. C'est quelque chose que j'ai dit à E que je ferai et il m'a physiquement empêché de le faire (il a débarqué dans mon bureau, m'arrache la souris des mains pour me faire revenir sur JIRA pour reprendre mes anos).
Finalement ces deux heures de travail m'ont permis de gagner 5 minutes + 5 minutes + 5 minutes et ainsi de suite, et beaucoup de frustration.
J'étais JD, j'aurai dû mentir sur mon planning et passer ça en sous-marin. E s'est félicité après sur mon efficacité, qui s'est accrue uniquement avec deux heures de "perdu".

Je pense pas qu'il y ait réellement de solution au problème. Si on ne veut pas faire du management ou du commercial, je pense quil faut apporter une réelle expertise en freelance ou faire de la formation sur un domaine technique. Honnêtement se réorienter dans l’enseignement quand on aime la technique, c'est pas un mauvais plan.

Je vais revenir sur mon avis qui est le même.
AUJOURD'HUI si on veut SURVIVRE dans le monde de l'informatique français (à majorité SSIIaque), on se doit d'être un peu diplomate, un peu commercial et un peu chef de projet (et comme j'ai dit dans un post précédent, au final j'ai souvent remarqué que les "développeurs" faisaient plus de gestion de projet que le CP...). Soit t'acceptes tristement la réalité, et oui c'est triste, c'est pas normal, ou alors tu cries ta frustration sur developpez

En France, un développeur de 50 ans est une peur pour la hiérarchie

Déjà vu à plusieurs reprises : un développeur de 50 ans sur le bureau de côté. Son secret ? Il, et sa SSII, ne l'ont pas présenté comme un développeur. Mais un expert, un CP, un référent, whatever. Tu veux être développeur à 50 ans ? change de titre.

[Tr0n33]

Une étude sur le ROI d'une action invisible ? poubelle !

Celle là je l'adore, c'est tellement vrai... On ne jure que par ROI de plus en plus. Il faut du concret.

Si tu proposes le truc du genre "je vais faire quelque chose, vous verrez pas le résultat, mais après-demain, ça va nous faire gagner 5 semaines par projet" le mec il te rigole à la gueule en disant que tu veux passer les 48h à glander sur internet.

Dites vous que cette micro anecdote, je l'ai vécu chez tous les clients. En France, la hiérarchie voit toujours celui d'en bas comme un glandeur qu'il faut fouetter. Je suis sûr que votre chef sur JIRA ne savait surtout rien du tout de votre métier et qu'il vous jugeait comme un bon petit ouvrier.

Déjà vu à plusieurs reprises : un développeur de 50 ans sur le bureau de côté. Son secret ? Il, et sa SSII, ne l'ont pas présenté comme un développeur. Mais un expert, un CP, un référent, whatever. Tu veux être développeur à 50 ans ? change de titre.

Oui on dit expert mais tu restes dans la grille/case "Développement ou Technique" qui signifie : vous êtes ouvrier mon bon monsieur. Ouvrier ou pompier de service. Dès qu'on nuance et qu'on prend sur soi, la hiérarchie vous adore. Et c'est à ce moment là que vous faites passer comme une lettre à la poste vos évolutions. C'est tout un art, je dois l'avouer.

[Glutinus]

Dites vous que cette micro anecdote, je l'ai vécu chez tous les clients. En France, la hiérarchie voit toujours celui d'en bas comme un glandeur qu'il faut fouetter. Je suis sûr que votre chef sur JIRA ne savait surtout rien du tout de votre métier et qu'il vous jugeait comme un bon petit ouvrier.

De toute ma carrière d'une dizaine de missions, c'est bien cette personne en particulier qui répondrait au mieux et parfaitement à cette description.

[el_slapper]

On l'a tous eu, chacun avec ses variantes.

Moi, j'ai eu un truc additionnel : je les ai aidé à rentrer chez eux plus tôt le soir. Là ou j'ai croisé Glutinus en vrai.

En fait, avant mon arrivée, la banque avait mis en place une petite chaine marketing(en COBOL), et une interface maison pour alimenter la chaine, moche mais blindée. La chaine n'était pas blindée. On avait généreusement octroyé à mes prédécesseurs 1/3 du budget qu'ils avaient demandé, et ils avaient réussi, dans le temps imparti, à faire un truc qui marchait. Je ne peut décemment pas leur en vouloir d'avoir laissé des loups. Tant que l'ancienne interface était en place, après tout, ça marchait.

Sauf que la banque a acheté un produit du commerce pour remplacer l'outil maison. Un très joli truc, mais comme c'était paramétré par le métier, faire des contrôles, ce n'était pas leur truc. Soudain, tous les mois, je me suis retrouvé à faire 3-4 jours de pompiers à réparer leurs conneries, parce que des codes banques à 99999, ça n'existe pas. Et que ça plantait le château de cartes qu'avait construit mes malheureux prédécesseurs grave. Et que comme il fallait finir le dernier jour ouvré du mois, les gens du marketing(qui avaient fait la connerie du 99999, parce que le nouveau système ne le leur interdisait pas) devaient valider, il restaient jusqu'à minuit.

Ce petit jeu a duré quelques mois. J'ai demandé à plusieurs reprises à ce qu'ils fassent gaffe, ou alors 5 jours pour faire un correctif qui ferait gagner 3 jours par mois. Je n'ai jamais eu de réponse(pas même un non, poli ou non). RIEN.

Puis, on m'a demandé de chiffrer "un changement de la sortie"(en gros, au lieu de faire un listing pourri, faire un beau fichier que le poste de travail pourrait rendre accessible en ligne). Je regarde la spec, quasiment tout est différent de l'existant. Au final, j'ai gardé 3 programmes sur 160, et encore, 2 ont été bien charcutés. Donc, je chiffre l'évolution à 120 jours de COBOL...incluant une gestion propre des rejets. Ils voulaient un mail qui leur dise "tout s'est bien passé", j'ai chiffré un mail qui dise "ça c'était bon, ça c'était fait, j'ai rejeté". Pas de commentaire. Avec mon collègue, on fait une spec technique qui détaille ledit rejet, pas de commentaire. On passe en test, ils reçoivent le premier mail, avec 4 OK et un KO...et ils m'appellent. J'ai eu 20 minutes d'insulte au téléphone, du style "tu as volé la banque". Mot pour mot. J'étais le nouveau Kerviel. Vraiment. Au bout de 20 minutes, elle se calme, et je pose la question qui tue : "qu'est-ce qui manque à mon feedback?"...et elle a trouvé plein de trucs. Je lui dis, pas de problème, fais moi des anomalies à ce sujet. Elle en a rempli 10. A la fin, on faisait un roman pour chaque erreur dans le fichier.

Résultat, quelques mois après la mise en place de la nouvelle chaine, il n'y avait plus d'erreur du tout(ils avaient appris à ne pas faire d'erreur dans le nouvel outil grâce à mon feedback), et ils pouvaient rentrer chez eux à une heure normale le dernier jour ouvré du mois. Et je n'avais plus de maintenance du tout à faire. Mais j'ai du les mettre devant le fait accompli(bon, j'avais laissé quelques indices, mais avec la quasi-certitude qu'ils ne les remarqueraient même pas).

Anecdote rigolote : les gens du JAVA avaient été contacté pour budgétiser la création de la même chaine(pour rappel, mon collègue et moi avons refait 95% de l'existant). Leur chiffrage était le double du nôtre. COBOL Powaaaaaaaaaaaaaaa!!!!!!

Mais, en gros, si on veut améliorer la vie du client, il faut le faire dans son dos. C'est canulant, parfois. Mais je n'avais pas imaginé pouvoir rigoler autant en recevant une engueulade. 20 minutes de plaisir absolu, à se faire insulter, en sachant que l'autre sait qu'il a tort.

[garn]

Mais, en gros, si on veut améliorer la vie du client, il faut le faire dans son dos

c'est tellement vrai

Maintenant, je demande plus "si" je dois faire des docs
Je fais. je demande juste avant si ca existe, quitte a pas faire un boulot inutile, et après je vais à la peche aux infos

developpeur ou AMOA, mêmes problèmes la dessus

en ce moment je fais de l'exploitation, c'est pas trop mon role normalement mais vu la bizarrerie du client, why not. On recoit des demandes du service client pour des updates en base de prod par exemple, ou facturer des utilisateurs (ouais, le presta informaticien qui facture manuellement un client final, et les updates en prod ni vu ni connu. tout va bien)
bref, c'est un travail répétitif, qui demande une certaine connaissance de la base, des requêtes à faire, de qui, pourquoi, dans quelle situation. Ca fait des années que les internes font ca. Je suis arrivé, on m'a formé direct à ca en mode "je me pose à coté et je regarde ce que fais le collegue". je demande si y a des docs, on me répond brutalement "y a pas de doc, c'est comme ca ici, tout dans la tete des gens"... okaaay

J'ai donc appris, et une fois appris j'ai fait un doc expliquant chaque cas, les requêtes à faire, pourquoi (et je pousse le vice a rajouter les explications fonctionnelles, pas juste un fichier SQL)
Envoi du doc, réponse client "ah mais c'est génial pourquoi on a pas fait ca avant"


=> c'est pas que le client veut pas
le client veut pas
1) le faire lui meme
2) payer une charge pour ca "officiellement"

une fois que c'est fait tout va bien

[jpoulson]

Cette manie de demander systématiquement trois années d'expérience dans le développement est d'une monstruosité inouïe.

Aller, j'explique mon cas:

- 40 ans (bientôt).
- Parle couramment l'anglais.
- A commencé un graduat vers 2000 puis du arrêter car problème de sante/famille.
- A fait une formation PC Support en 2001. N'a pas de trouvé de place (manque de diplôme et/ou permis).
- Formation de 9 mois en Java en 2010 dans un centre réputé. Toujours pas de job.
- Tout de même une percée avec CDD à travailler sur un petit réseau social, puis plus tard stage dans une agence web. 1 an d'expérience en tout.
- Reprise aux cours du soir après quelques années et Bachelier en Informatique finalement obtenu en 2014. Stop recherche emploi car je suis tombé sous la mutuelle faute de dépression.
- Difficultés d'ordre non verbal (anxieux) lors des entretiens d'embauche qui remontent au temps du graduat. M'en suis seulement véritablement rendu compte que vers 2008-2009.

Je demande, elle est où la pénurie d'informaticiens ?

J'ai eu de la chance pour mes expériences plus récentes. Si on demande trois années d'expérience partout, comment est-ce qu'une personne est supposer démarrer ?

[Trucherelle]

Je trouve cet article plein de bon sens. J'adhère à cette analyse. On pourrait d'ailleurs avoir la même réflexion pour bon nombre de disciplines autre que l'informatique. L'exercice d'une activité professionnelle durant des années et des années permet de prendre du recul sur le travail accompli, les services rendus et finalement le sens de son métier. En vue de se concentrer davantage sur la fin (logiciel final en tant que service) et non sur les moyens (le code).

[kEep OnE]

Perso j'essaie toujours d'allers au plus simple (pas trop de prise de tête, je déteste).
Mais j'ai un profil particulier. J'adore l'informatique, le net, je me documente sur un peu tout et n'importe-quoi mais je ne me concentre pas vraiment sur les subtilités des langages que je connais, ce qui fait que souvent j'en viens à demander au professeur Google et de bidouiller les codes que je trouve (tout en faisant attention que y ait pas de gros bugs ou de failles hein).
Bon je suis dans le web, on m'a mis en front-end donc je peux me la jouer bidouilleur, mais je sais combien mon profil peut agacer certains programmeurs plus érudits ! Désolé .
Bref, je sais déjà que je serais jamais un expert à cause de ma personnalité non-chalante et peu passionnée par la programmation même.
Encore désolé .

[yolle]

Je trouve cet article plein de bon sens. J'adhère à cette analyse. On pourrait d'ailleurs avoir la même réflexion pour bon nombre de disciplines autre que l'informatique. L'exercice d'une activité professionnelle durant des années et des années permet de prendre du recul sur le travail accompli, les services rendus et finalement le sens de son métier. En vue de se concentrer davantage sur la fin (logiciel final en tant que service) et non sur les moyens (le code).

Dans les autres secteurs d'activités, cela s'appelle de l'expérience ....

[Tr0n33]

Cette manie de demander systématiquement trois années d'expérience dans le développement est d'une monstruosité inouïe.

Aller, j'explique mon cas:

- 40 ans (bientôt).
- Parle couramment l'anglais.
- A commencé un graduat vers 2000 puis du arrêter car problème de sante/famille.
- A fait une formation PC Support en 2001. N'a pas de trouvé de place (manque de diplôme et/ou permis).
- Formation de 9 mois en Java en 2010 dans un centre réputé. Toujours pas de job.
- Tout de même une percée avec CDD à travailler sur un petit réseau social, puis plus tard stage dans une agence web. 1 an d'expérience en tout.
- Reprise aux cours du soir après quelques années et Bachelier en Informatique finalement obtenu en 2014. Stop recherche emploi car je suis tombé sous la mutuelle faute de dépression.
- Difficultés d'ordre non verbal (anxieux) lors des entretiens d'embauche qui remontent au temps du graduat. M'en suis seulement véritablement rendu compte que vers 2008-2009.

Je demande, elle est où la pénurie d'informaticiens ?

J'ai eu de la chance pour mes expériences plus récentes. Si on demande trois années d'expérience partout, comment est-ce qu'une personne est supposer démarrer ?

La seule problématique réelle que je vois dans votre CV est votre âge. C'est ce qui va rebuter toutes les sociétés de prestation : elles embauchent très rarement au delà de 35 ans à part expertise (c'est d'ailleurs mon cas actuellement, je vais avoir 35 ans, et c'est uniquement mon expertise et mes 10 ans d'expérience qui me permettent de négocier facilement). Il y a vraiment une pénurie d'informaticiens (dans ma région, deux grosses SSI n'arrivent toujours pas à recruter). Je vous conseille de vous orienter sur de très petites sociétés de service informatique (entre 5 et 20 employés). Elles acceptent généralement les profils atypiques. La mienne, en perdition au niveau économique, adorait votre type de profil car le changement, les aléas de la vie, et les échecs sont une force pour les individus. Sur ce sujet, si vous avez besoin d'aide (selon mes disponibilités), je puis vous donner des conseils pour vos entretiens, votre CV ou vous aidez un peu. N'hésitez pas à mettre en valeur ce côté d'adaptation justement. Plus vous avez une palette large avec une spécialité, plus vous arriverez à faire passer votre manque d'expérience pour une force. Je suppose qu'on vous l'a déjà dit ou que vous êtes au courant mais bon, si cela peut être utile, n'hésitez pas à me contacter en privée.

je sais combien mon profil peut agacer certains programmeurs plus érudits !

Nein. Je suis plutôt dans la catégorie érudit mais nous ne dénigrons, j'ose espérer, jamais un bidouilleur. Lors de la dernière mission par exemple, nous avions toute une partie de design web : maquettage, javascript etc. Généralement ça bidouille en CSS, ça passe des heures à essayer de faire un cadre compatible sur IE6 et Firefox, puis ça s'arrache les cheveux parce que ça ne marche jamais. Ce métier là, je suis tombé sur un véritable petit génie : aucune formation informatique, juste une connaissance de la bidouille. Il nous a fait le truc aux petits oignons en un temps record (et vu que les érudits détestent cette partie...). Comme il a été évoqué plus haut, il faut de tout pour faire une équipe viable : un bidouilleur, un junior débutant, un expert senior, peut être un senior en formation, peut être un junior génie de la technique. Bref. C'est tout un ensemble avec les spécialités de chacun qui permet d'avoir quelque chose de "construit". D'où la réponse : l'expérience est un gros plus, mais ne justifie en rien le type de profil. Ce n'est qu'un indicateur parmi d'autres.

J'ai un exemple assez amusant d'ailleurs. Un développeur de 23 ans est vendu actuellement comme un Senior. Il n'a que 2 ans d'expérience, il n'a pas un bac+5 et pourtant c'est un véritable petit architecte, concepteur et expert dans son domaine. Il est bien meilleur que moi qui ait pourtant un DEA et 10 ans d'expérience. En 6 mois il a acquis toutes les problématiques de l'entreprise et de la communication, tout simplement car il a eu la chance d'être au coeur d'une mission intéressante, entouré de gens très bons et diversifiés.

[garn]

Cette manie de demander systématiquement trois années d'expérience dans le développement est d'une monstruosité inouïe.

Aller, j'explique mon cas:

- 40 ans (bientôt).
- Parle couramment l'anglais.
- A commencé un graduat vers 2000 puis du arrêter car problème de sante/famille.
- A fait une formation PC Support en 2001. N'a pas de trouvé de place (manque de diplôme et/ou permis).
- Formation de 9 mois en Java en 2010 dans un centre réputé. Toujours pas de job.
- Tout de même une percée avec CDD à travailler sur un petit réseau social, puis plus tard stage dans une agence web. 1 an d'expérience en tout.
- Reprise aux cours du soir après quelques années et Bachelier en Informatique finalement obtenu en 2014. Stop recherche emploi car je suis tombé sous la mutuelle faute de dépression.
- Difficultés d'ordre non verbal (anxieux) lors des entretiens d'embauche qui remontent au temps du graduat. M'en suis seulement véritablement rendu compte que vers 2008-2009.

Je demande, elle est où la pénurie d'informaticiens ?

J'ai eu de la chance pour mes expériences plus récentes. Si on demande trois années d'expérience partout, comment est-ce qu'une personne est supposer démarrer ?

exact. C'est toute la base du problème. Et ce pour quoi, en général, je privilégie quand on est débutant l'expérience à la reprise d'étude (ca n'est pas une vérité absolue, mais l'expérience, elle reste toute la vie, les études on considère vite que t'as passé le cap, ca marche qu'a début). C'est aussi la raison pour laquelle l'alternance informatique est tellement bien, permettant de cumuler expérience et diplome

[Tr0n33]

exact. C'est toute la base du problème. Et ce pour quoi, en général, je privilégie quand on est débutant l'expérience à la reprise d'étude (ca n'est pas une vérité absolue, mais l'expérience, elle reste toute la vie, les études on considère vite que t'as passé le cap, ca marche qu'a début). C'est aussi la raison pour laquelle l'alternance informatique est tellement bien, permettant de cumuler expérience et diplome

Dans un sens totalement d'accord. Par contre vous trouverez certaines personnes qui pensent l'inverse. Ca reste rare mais je trouve que les abstractions fournies par les études sont importantes. Une personne qui prend le risque de se reformer, pour moi, est dans une direction d'évolution et elle va de l'avant. Elle a donc un sérieux avantage d'adaptabilité, et de comportement par rapport à une personne qui aura de l'expérience en plus. L'expérience n'est pas tout - je pense - c'est un indicateur. Parfois j'apprécie aussi quelqu'un qui prend des risques pour changer de voix ou sortir de son quotidien. Je reconnais que c'est complexe, mais ça s'argumente en face d'un DRH; souvent ça bloque véritablement juste à cause de l'âge. En France, beaucoup de société tentent de revoir leur pyramide des âges : entre le non remplacement de départs à la retraite et le désir de diminuer l'âge moyen, entre 35 et 60 ans, vous commencez à avoir de gros problèmes pour être recrutés.

Après nous faisons souvent l'amalgame entre l'âge, l'expérience et le profil. Pour un client, profil senior voudra dire : âgé, expérimenté, expert, cher et junior : débutant, tout fou, manipulable, pas cher. Or tous ces indicateurs (et d'autres qui rentrent en ligne de compte et qui ne sont pas forcément de l'expérience mais plutôt une forme de caractère qui ne peut pas toujours s'acquérir par expérience comme la capacité à s'adapter, à nuancer, à se comporter face à une hiérarchie rigide, à écouter le client) permettent d'établir des dizaines de profils différents. Une entreprise ou une mission ou un poste, ont besoin d'un profil particulier. Il est donc difficile (de ce que je vois à force de lire les réponses de ce débat), d'établir une définition stricte de Junior ou Senior.

[Tr0n33]

J'en profite pour répondre aux petites anecdotes du dessus qui m'ont fait sourire.

Ce petit jeu a duré quelques mois. J'ai demandé à plusieurs reprises à ce qu'ils fassent gaffe, ou alors 5 jours pour faire un correctif qui ferait gagner 3 jours par mois. Je n'ai jamais eu de réponse(pas même un non, poli ou non). RIEN.

C'est le problème hiérarchique typique des entreprises françaises (je n'ai pas d'expériences à l'étranger pour comparer). Nos belles entreprises actuelles ont une nette tendance à ne pas être en forme de pyramide mais de losange (on utilisait cette image dans une mission avec quelques potes). Tu as une personne en haut qui délègue successivement à tout plein d'autres personnes. Tu arrives alors à la fondation de la pyramide avec tout plein d'ouvriers, ingénieurs, experts, équipes en tout genre. Et puis c'est là que notre modèle prend tout son sens. Derrière chaque action de ces fondations de pyramide, il n'y a en réalité qu'un seul type : "Jean Paul". Et Jean Paul il fait la production, le pompier, le support, les scripts d'automatisation et même le café si tu passes à son bureau. Le problème c'est que Jean Paul en bout de chaine, il est tout seul. D'où l'analogie avec le losange plutôt que la pyramide. Dans ce modèle les juniors sont d'ailleurs en plein milieu et le Senior motivé généralement à la pointe basse du losange. Il gagne toujours le jackpot car il aime son métier, il est passionné, tout le monde l'adore mais... Mais aucune information ne remonte car dans toute cette magnifique figure géométrique tu as des rouages complexes et les demandes du fameux Jean Paul n'arrive jamais Ô grand jamais aux bonnes personnes. Et oui, elles remontent vers le chef de Jean Paul qui appelle le chef des Juniors qui appellent le marketing, le management, et tutti quanti. Au final 8 mois après, personne ne sait où est passé le message du pauvre Jean Paul.

En somme, j'ai croisé des dizaines de fois ce problème du "jamais de réponses". C'est d'un classicisme... C'est d'ailleurs typiquement la différence entre le Senior qui va savoir triturer les rouages de la hiérarchie pour avoir sa réponse et le Junior qui va soit péter un boulon (en remuant ciel et terre et se faire tirer dessus par son chef), soit se taire (et ruminer toute sa frustration jusqu'à ce qu'elle explose).

Puis, on m'a demandé de chiffrer "un changement de la sortie"

Le grand classique induit par une erreur commerciale dès le début. D'ailleurs probablement que le choix d'un logiciel éditeur a été effectué avec Jean Michel. Oui, Jean Michel c'est le chef qui a fait ses études avec un autre chef d'une SSI ou d'une boîte informatique (et je dois vous avouer, que Jean Michel j'en ai croisé au moins 4 ou 5 en 10 ans d'expérience. Entre l'ancien commercial d'une SSI qui devient RH d'une très grosse association chargée de récolter les cotisations salariales et patronales... Entre le directeur de la plus grande banque de l'état qui est un proche d'une société qui développe un Webservice de gestion d'authentifications...). Tous reviennent à la fin, par rationalisation et par rejet des utilisateurs à demander à Jean Paul, un chiffrage. Heureusement, Jean Paul est le seul Senior ET expert, car la direction préfère ne pas trop investir dans l'informatique. Oui, l'informatique ça n'est pas considéré comme "le coeur de métier" (dixit un grand muffti d'une entreprise d'assurance privée qui a tout un SI monstrueux à gérer). Alors on chiffre, et généralement comme tu l'indiques :

'ai eu 20 minutes d'insulte au téléphone, du style "tu as volé la banque"

Voilà ce qu'on récolte ! On a jamais osé me la faire. Disons parce que je fais du rugby. A chaque fois que je tombe sur du personnel de ce style, la seule réponse est celle que tu indiques. L'informatique est au service du métier généralement et je ne prends jamais de manière personnel une critique. Toujours de manière constructive. D'ailleurs pour en revenir au débat, Senior comme Junior n'ont pas forcément le sens du service, qui est dans ce métier (avec l'adaptatibilité) une des plus grandes qualités. Peu importe le traitement, l'autruche c'est bien dans ce genre de situation. Pour en revenir au débat, j'ai toujours du mal à définir réellement ce que sont Junior et Senior. Je vois des Seniors qui sont bien moins expérimenté dans tous les domaines que des Juniors. Le principe de Peter évoqué un peu plus haut est à l'origine de ce fait d'ailleurs.

Anecdote rigolote : les gens du JAVA avaient été contacté pour budgétiser la création de la même chaine(pour rappel, mon collègue et moi avons refait 95% de l'existant). Leur chiffrage était le double du nôtre. COBOL Powaaaaaaaaaaaaaaa!!!!!!

Autre débat mais tout dépend totalement de la conception et du logiciel que vous souhaitez.

Mais, en gros, si on veut améliorer la vie du client, il faut le faire dans son dos. C'est canulant, parfois. Mais je n'avais pas imaginé pouvoir rigoler autant en recevant une engueulade. 20 minutes de plaisir absolu, à se faire insulter, en sachant que l'autre sait qu'il a tort.

J'ai quand même eu l'expérience de plusieurs équipes où nous étions un peu moins emmerdé par les clients. Nous avions mis en oeuvre une petite formation une fois par semaine après 18 h pour ceux qui voulaient avoir de l'expertise en Java, et nous avions 1/2 journée (le vendredi après midi - ultra négocié) pour développer ce que nous voulions en rapport avec les problématiques de l'équipe (liberté de développer un automatisme pour favoriser une installation par exemple). Quand on arrive aux yeux d'un client à lui prouver une forme d'expertise et lui montrer sur le long terme un certain nombre de gain, il est généralement plus réceptif. C'est tout un art de la communication avec les bons individus, au bon moment. Ainsi vous allez créer des profils de jeunes Seniors (waou).

Personnellement, je dois vous avouer, j'ai utilisé les techniques les plus ancestrales de manipulation. Un chef avait refusé une évolution technique d'un produit qui pouvait nous faire gagner sur l'aspect sécurité et sur l'aspect gain de temps des mises en production. On avait chiffré etc. 6 mois après je lui ai sorti en réunion la même étude en lui disant qu'on était ok. Il m'a demandé ok pour quoi ? Je lui ai montré le document en lui disant que c'était lui qui avait eu l'idée. Bilan il était ok sur tout et il a récolté tout plein de lauriers. Je sais, c'est pas joli joli, mais il faut savoir prendre les gens par les sentiments pour faire évoluer l'entreprise !

[garn]

Dans un sens totalement d'accord. Par contre vous trouverez certaines personnes qui pensent l'inverse. Ca reste rare mais je trouve que les abstractions fournies par les études sont importantes. Une personne qui prend le risque de se reformer, pour moi, est dans une direction d'évolution et elle va de l'avant. Elle a donc un sérieux avantage d'adaptabilité, et de comportement par rapport à une personne qui aura de l'expérience en plus. L'expérience n'est pas tout - je pense - c'est un indicateur. Parfois j'apprécie aussi quelqu'un qui prend des risques pour changer de voix ou sortir de son quotidien. Je reconnais que c'est complexe, mais ça s'argumente en face d'un DRH; souvent ça bloque véritablement juste à cause de l'âge. En France, beaucoup de société tentent de revoir leur pyramide des âges : entre le non remplacement de départs à la retraite et le désir de diminuer l'âge moyen, entre 35 et 60 ans, vous commencez à avoir de gros problèmes pour être recrutés.

Après nous faisons souvent l'amalgame entre l'âge, l'expérience et le profil. Pour un client, profil senior voudra dire : âgé, expérimenté, expert, cher et junior : débutant, tout fou, manipulable, pas cher. Or tous ces indicateurs (et d'autres qui rentrent en ligne de compte et qui ne sont pas forcément de l'expérience mais plutôt une forme de caractère qui ne peut pas toujours s'acquérir par expérience comme la capacité à s'adapter, à nuancer, à se comporter face à une hiérarchie rigide, à écouter le client) permettent d'établir des dizaines de profils différents. Une entreprise ou une mission ou un poste, ont besoin d'un profil particulier. Il est donc difficile (de ce que je vois à force de lire les réponses de ce débat), d'établir une définition stricte de Junior ou Senior.

tout a fait
ca n'est pas une vérité absolue l'expérience, et autant ca peut permettre de décrocher un job autant celui ci au départ sera moins payé. Tout est à voir au cas par cas... D'une manière générale un junior je lui conseillerais toujours de continuer jusqu'au bac +5 s'il peut se le permettre financièrement. C'est l'inverse de ce que je disais plus haut? Oui mais y a une marge entre quelqu'un avec un parcours erratique qui a déja travaillé, ou veut se reconvertir, et quelqu'un qui fait une ligne droite dans ses études
Limite faites juste les bac +5 en alternance si possible, c'est le top du top

A l'inverse, qqu'un qui prend 2 ans pour passer de bac + 2 a bac +3 alors qu'il a déja 30 ans, c'est moins radical comme choix. parfois, c'est obligatoire, et utile, notamment pour les reconversions complètes. parfois, c'est une grande perte de temps

Ce qui est sur c'est que d'une manière générale les entreprises, pour évaluer si un profil peut être intéressant, vont regarder expérience et diplomes. Si l'expérience est une valeur sure et chiffrable, le diplome dépend largement du niveau / établissement / spécialité et d'autres caractéristiques personnelles ...
Les entreprises n'aiment pas les profils atypiques, car il y a soit disant un "risque" à confier un boulot à quelqu'un qui n'est pas habitué à le faire, et qui diffère de ce qu'il faisait avant
C'est pour ca que la reconversion est si difficile. Les recruteurs considèrent aussi qu'un jeune est maléable, et peut être formé, mais que ca n'est plus possible après quelques années (ce qui est bien sur idiot, mais c'est comme ca...)
Ajoutez à ca les contraintes RH : les grilles de salaires dépendent de l'âge, et payer un profil "junior sur ce poste" plus cher parceque la personne est plus agée, beaucoup ne voudront pas, puisqu'ils ont pléthore de jeunes

[el_slapper]

(.../plein de choses auxquelles j'adhère et sur le quelle je n'ai pas besoin de revenir/...)
Autre débat mais tout dépend totalement de la conception et du logiciel que vous souhaitez.

C'est souvent ça, mais dans ce cas précis, c'était plus subtil. Pour garder le contrôle de leur "architecture", les grands pontes avaient exigé un contrôle total sur les livraisons des composants par des équipes dédiées. Même en intégration. Les devs JAVA n'avaient même pas le droit de créer leurs propres classes, ils devaient passer par une bureaucratie profonde. Nous, en COBOL, on pouvait créer un composant comme on voulait, et le livrer en prod en 4 minutes chrono. Le seul point sur lequel il y avait un contrôle, c'étaient les scripts(on appelle ça les JCL) des chaines. Si la chaine machine devait partir à 18h00, mais seulement à bonne fin de la chaine truc, et en présence du fichier bidule, alors si le fichier bidule changeait de nom, il fallait faire une demande, qui pouvait durer jusqu'à trois semaine. En vrai, elle durait deux jours. Les gens du JAVA, eux, avaient des installations en intégration qui duraient une semaine. . Pauvres malheureux. Ils ne pouvaient pas lutter. On avait des flingues, ils avaient des cailloux.

J'ai quand même eu l'expérience de plusieurs équipes où nous étions un peu moins emmerdé par les clients. Nous avions mis en œuvre une petite formation une fois par semaine après 18 h pour ceux qui voulaient avoir de l'expertise en Java, et nous avions 1/2 journée (le vendredi après midi - ultra négocié) pour développer ce que nous voulions en rapport avec les problématiques de l'équipe (liberté de développer un automatisme pour favoriser une installation par exemple). Quand on arrive aux yeux d'un client à lui prouver une forme d'expertise et lui montrer sur le long terme un certain nombre de gain, il est généralement plus réceptif. C'est tout un art de la communication avec les bons individus, au bon moment. Ainsi vous allez créer des profils de jeunes Seniors (waou).

J'aurais adoré voir ça. Mais je ne crois pas que ça aurait marché dans le contexte de l'histoire que je raconte. Parceque le développement et la maintenance, ce n'est pas le même budget.

Personnellement, je dois vous avouer, j'ai utilisé les techniques les plus ancestrales de manipulation. Un chef avait refusé une évolution technique d'un produit qui pouvait nous faire gagner sur l'aspect sécurité et sur l'aspect gain de temps des mises en production. On avait chiffré etc. 6 mois après je lui ai sorti en réunion la même étude en lui disant qu'on était ok. Il m'a demandé ok pour quoi ? Je lui ai montré le document en lui disant que c'était lui qui avait eu l'idée. Bilan il était ok sur tout et il a récolté tout plein de lauriers. Je sais, c'est pas joli joli, mais il faut savoir prendre les gens par les sentiments pour faire évoluer l'entreprise !

Je n'oserai jamais. J'ai tort, d'ailleurs.