Discussion :

[Plop55]

Bonjour,

la question est vaste, à tendance philosophique et s'adresse plutôt à des devs non juniors.

On est d'accord que lorsqu'une boîte recrute, elle aimerait bien trouver la poule aux oeufs d'or, fraîchement diplômée, avec 20 ans d'XP dans les technos les plus récentes utilisées par votre boîte, qui bossera de façon efficace pour vous environ 20h/jr, tout en étant payée 3 croissants au chocolat / semaine. Avec des compétences en *insert buzzword*, ayant un bon relationnel client et "non-autiste" de préférence.
Et qu'au bout d'un an, on est confiant pour le laisser gérer tout seul l'intégralité des 10 M de lignes de code de votre application chérie, ainsi que toute la relation client, les sessions de formation pour les nouveaux, la préparation de café pour tout l'open space, l'achat des fournitures de bureau et l'arrosage des plantes. Sauf qu'en fait, non.

Du coup, ma question est: prenons une techno / langage / framework donné/e (au hasard, Python / Java / React JS / data science / *insert l'exemple que vous voulez* ). Prenons un dev junior lambda, moyen, fraîchement diplômé / ayant pas d'XP pro avec la techno, ni avec le domaine métier.
Que peut-on attendre comme compétences /évolution de compétences professionnelles de ce dev au bout d'une année? Quels résultats peuvent être attendus? Quels types de tâches lui confieriez-vous? Avec exemple de votre choix, si possible

But de la question: avoir une idée des attendus crédibles.

[Marco46]

Que peut-on attendre comme compétences /évolution de compétences professionnelles de ce dev au bout d'une année? Quels résultats peuvent être attendus? Quels types de tâches lui confieriez-vous? Avec exemple de votre choix, si possible

De prendre en charge des tâches basiques avec de plus en plus d'autonomie au fil du temps. Un dev junior nécessite de l'encadrement au quotidien. Difficile de donner des tâches précises ça dépend du projet et des difficultés de la personne mais il faut comprendre que cela nécessite un cadrage et une revue quotidienne au minimum les premiers mois avec une fréquence de moins en moins importante au fil du temps. Pour sortir du statut junior à mon avis il faut avoir vu plusieurs projets / contextes différents, au moins deux. Donc pas avant 4 ou 5 ans.

[Carhiboux]

Salut, une question intéressante.

Je dirais que plus que les compétences techniques, réelles ou supposées, ce qui fait la différence ce sont les attitudes et la manière d'être.

J'ai déjà eu l'occasion de le dire dans d'autres sujets, mais avoir dans ton équipe un mec super fort, mais qui ne communiquerais jamais et ne feras jamais de compromis, c'est un boulet pour l'équipe.

Je préfère mille fois travailler avec des gens "moyens" mais qui savent travailler en équipe.

Ce qui importe, c'est de savoir être humble quand on débute. Pas toujours facile pour des jeunes diplômés à qui des profs qui n'ont jamais connu le monde du travail privé rabâchent qu'ils seront "l'élite de la nation" (le directeur de mon école d'ingé du fin fond du groupe C...).

Les compétences, cela s'acquiert avec le temps sous réserve d'avoir un minimum d'aptitudes. Le caractère et les manières d'être, cela ne se change pas comme cela...

Donc quelle taches lui donner?

Des taches quasi exclusivement techniques d'une part, pour le familiariser avec les technos (c'est à dire que toute la partie fonctionnelle à été épluchée par l'encadrant). Typiquement du factoring, de la QS, une migration technique, du petit correctif, etc....

Et des taches fonctionnelles d'autres part, pour rentrer dans le métier. Lui donner la responsabilité de petites évolution non critiques où il faut échanger avec le métier sur le besoin, en confrontant le besoin aux contraintes techniques.

Après, faut pas se leurrer, un débutant, il faut bien 1 an pour qu'il soit autonome dans son rôle.

[Darkzinus]

Excellent post de Carhiboux , tout est dit ! Il est très important de trouver les personnes aux côté de qui progresser (forts techniquement, qui aiment partager leurs connaissances) et donc de communiquer avec ses collègues et ne pas rester bloqué sur un sujet. C'est comme ça tu progresseras beaucoup plus vite que d'autres.
Il ne faut pas hésiter à avertir son n+1 quand les délais s'annoncent tendus par rapport à l'estimation initiale (cela évite de se mettre en "danger").

[Plop55]

Merci pour ces retours!

Un dev junior nécessite de l'encadrement au quotidien. [...] cela nécessite un cadrage et une revue quotidienne au minimum les premiers mois avec une fréquence de moins en moins importante au fil du temps.

Ce qui appelle la question subsidiaire: quel est le temps que l'on accorde à un junior? Et dans le suivi, quelle est la part accordée à la vérification de tâches à effectuer et quelle est la part qu'on consacre à "l'enseignement bête et méchant"?

Il ne faut pas hésiter à avertir son n+1 quand les délais s'annoncent tendus par rapport à l'estimation initiale

Totalement d'accord, et comme le junior a a priori une idée très floue du temps que lui prendra une tâche donnée, c'est plus au fur et à mesure que le mur s'approche qu'il va se rendre qu'il n'y arrive pas. => re-souligne l'importance d'une communication constante et de qualité.

*moult choses intelligentes*

- "QS"? Quality something?
- Fun fact: je me rappelle avoir eu le droit à "l'élite de la nation" en 1e année, mais pas à la remise des diplômes... Faut croire qu'on ne l'était plus.

[Carhiboux]

Qualité de Service : tout ce qui va toucher à la qualité des données, des métriques, des logs, la maintenabilité des applications, etc...

Malheureusement, c'est souvent la dernière roue du carrosse dans toute activité informatique.

[Mat.M]

quel est le temps que l'on accorde à un junior?

en tant que junior si on se pose trop de questions philosophiques justement à ça risque d'être la catastrophe.
Car en entreprise pour faire du code on a coutume de dire "ça devait être fini pour la veille".
En plus comme le taux journalier moyen c'est 400-500 euros que le te client paie à la SSII, on n'en pas trop le temps de se lancer dans des méditations métaphysiques car il y a des deadlines à respecter.
Cependant oui après quelques temps c'est vraiment bien d'avoir du recul, lorsqu'on acquiert de l'expérience

[Plop55]

@Mat.M
Là, tu as une approche: on jette le bébé dans la piscine et on revient au moment de l'entretien annuel pour voir s'il a réussi à pêcher ses 3 tonnes de sardines. Et tant pis s'il n'a pas survécu, on en trouve tous les ans, des fraîchement diplômés.
Je me reformule alors: "Quel temps qu'on devrait / voudrait consacrer à un junior (vérifs de ce qu'il fait / formations)?" Mais c'est aussi hautement philosophique. Une question qui serait peut-être plus pertinente: "Quelle forme pourrait prendre la formation d'un junior? (échanges informels, on s'assoit et on dessine, etc.)". Témoignages?

[Carhiboux]

Salut,

J'avais pas vu la question du temps à accorder à un junior.

Il me semble qu'il n'existe pas de formule magique toute faite pour déterminer cela.

Bien sur, il faut que le "tuteur" ait du "temps" (c'est à dire surtout de quoi imputer le temps passé dans l'outil de saisie des temps), mais il faut surtout qu'il ait de la disponibilité.

A la fois de la disponibilité temporelle (ne pas mettre en tuteur qqn qui va passer 70% de son temps en réunion par exemple) mais aussi de la disponibilité relationnelle.

Et là encore, c'est beaucoup une question de caractère. Certains sont de bon "tuteurs" d'autres ont plus de mal à passer leurs connaissances, à expliquer, ou même à vulgariser pour les débutants.

La proximité géographique joue aussi beaucoup. Le fait de pouvoir formuler une question à voix haute est plus facile que de devoir passer par messagerie ou téléphone. Le fait de pouvoir croiser le regarde de la personne aussi.

Pour revenir sur la question du "combien de temps", je crois que la meilleure solution, c'est d'avoir une enveloppe au départ, en sachant que les premiers jours, il y aura forcément plus de questions qu'au bout de 3 mois. D'ailleurs, au bout de 3 mois, normalement, on devrait être arrivé au stade où il y a des questions, mais que ce n'est plus chronophage au point de nécessiter un budget spécifique. Sur le combien, je pense que 10 jours est un minimum. Sachant que sur la première semaine, il faudrait déjà bien en cramer au moins 3 pour bien intégrer et expliquer le pourquoi du comment à la personne (en pratique, c'est rarissime qu'il y ait tant de disponibilité, je pense qu'on se souvient tous de s'être fait chier comme des rats morts lors de nos premiers jours dans des nouveaux postes parce que personne de dispo pour nous expliquer les missions ou les spécifiques). Ensuite, 1j / semaine sur les 7 semaines suivantes.

C'est à la grosse louche. Si tu tombes sur un mec qui relie vite les points, tu peux passer moins de temps. Si tu tombes sur un anxieux, tu peux y passer 3 fois plus de temps.

Dans tous les cas, il faut un suivi, au risque que n'importe quoi soit fait et de s'en rendre compte bien trop tard pour pouvoir redresser la barre...

[Mat.M]

Je me reformule alors: "Quel temps qu'on devrait / voudrait consacrer à un junior

en entreprise la personne qui t'encadre n'a pas toujours le temps de bien t'expliquer les choses.
Donc cela suppose beaucoup de travail de la part d'un nouvel arrivant en entreprise ( jeune diplômé ou pas)
Donc il faut au besoin emporter son travail le soir et éventuellement étudier les problèmes après le travail
étant donné que les projets de développement informatique sont de plus en plus complexes c'est tout un truc à détricoter.

Le problème en entreprise et notamment dans les SSII c'est bien connu, il y a des développeurs qui arrivent ils font leur job et donc une couche de code et arrivent derrière d'autres développeurs

"Quelle forme pourrait prendre la formation d'un junior? (échanges informels, on s'assoit et on dessine, etc.)". Témoignages?

euuh la forme de la forme ? Quid de la poule ou de l'oeuf et qui est arrivé(e) le premier ?

Je pense commencer à saisir le problème: c'est que souvent en entreprise il y a une défaillance totale de méthodes.
Si tu mentionnes le terme "dessiner" c'est qu'il faut faire des spécifications bien précises, du conceptuel solide pour démarrer un projet info.

C'est comme construire une maison : si l'architecte fait mal les plas pour que les ouvriers du bâtiment fassent correctement les choses, la maison sera mal construite.
En supposant évidemment que les ouvriers sachent bien travailler

Pour revenir sur la question du "combien de temps", je crois que la meilleure solution, c'est d'avoir une enveloppe au départ, en sachant que les premiers jours, il y aura forcément plus de questions qu'au bout de 3 mois.

je suis bien d'accord avec cette remarque de bon sens ( et plus précise que je n'ai été capable de produire ).

Cependant le gros problème des entreprises c'est qu'elles sont serrées par les délais et le nouvel arrivant s'il finit par être un boulet ( je préfére écrire franchement les choses..) eh bien ça risque de mal finir.
Histoire de faire de l'auto-dérision je parle en connaissance de cause
Donc le nouvel arrivant donc le junior doit beaucoup travailler pour s'adapter.

Et lorsqu'on se fait recruter les recruteurs ça ils ne le disent jamais ils ont tendance à "vendre du vent" plus qu'autre chose

[Terin]

Dans les faits c'est très simple, on attend d'un dev junior exactement la même chose qu'un senior, mais sans le salaire.

Réaliser les features ASAP dicter par le client et CDP. S'approprier toute la dette technique seul et en une journée etc etc ...

ça existe plus le "détail" des compétences, des technos, le développeur c'est tellement fait dévaloriser qu'il est considéré comme un executant, un mec de chantier qui suis les ordres de son chef, ce qu'on lui demande est simple, c'est une storyline qui tiens en 2 phrases dans le ticket

Je caricature, mais depuis 2/3 ans, c'est mon ressenti, on attend aucune compétences technique en particulier d'un dev, juste qu'il soit capable de réaliser les tickets dans jira ...

[el_slapper]

(.../...) on attend aucune compétences technique en particulier d'un dev, juste qu'il soit capable de réaliser les tickets dans jira ...

Et aussi qu'il guérisse le cancer par imposition des mains, qu'il fasse le boulot du marketing et ramène plein de clients(mais que les commissions restent aux commerciaux, hein), et qu'il négocie une baisse de salaire chaque année à son entretien annuel.

[Almopine]

Et aussi qu'il guérisse le cancer par imposition des mains, qu'il fasse le boulot du marketing et ramène plein de clients(mais que les commissions restent aux commerciaux, hein), et qu'il négocie une baisse de salaire chaque année à son entretien annuel.

Qu’il fasse l’UX car la personne dédié est une tanche qui a fait un sketch sur un coin de table et connais pas le projet, qu’il s’occupe aussi de l’UI car les maquettes suffisent pas mais ont déjà été validé par le CDP, qu’ils proposent des idées, mais sans s’en attribuer la paternité, c’est le PO qui doit recevoir les lauriers, qu’il fasse la maintenance et la correction de bug en dehors de son temps de travail (bah oui si t’es bon pas de bug ...), qu’il se forme le week-end au dernière technologie, qu’il soit capable de monter un POC en 2h sur la dernière techno JS que le PO a vue sur un post linkedin etc etc ...

Et bien sur toutes les 2h il doit faire un rapport de son avancement à son maître CDP et s’auto-chatié quand il a pas avancé de façon significative... Et après les entreprises se demandent pourquoi tu as 20 à 40% de turn-over mais pas que tout le monde souhaite être CDP, PO, Scrum Master, Ux research/Désigner, head of product, head of acquisition, référent SEO/SEA, chef de produit, chargée de projet ...