1. #1
    Membre confirmé
    Homme Profil pro
    Développeur Web
    Inscrit en
    octobre 2009
    Messages
    227
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Nouvelle-Zélande

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : octobre 2009
    Messages : 227
    Points : 614
    Points
    614

    Par défaut Faire progresser son équipe

    Bonjour !

    Je m'adresse aux chefs de projets/équipe et aux développeurs qui ont déjà eu a gérer d'autres développeurs pour avoir des retours sur comment faire progresser les gens, en gros sans les vexer ni passer pour un gros con qui sait tout (c'est TRES loin d’être le cas).

    Petite mise en contexte : Je suis développeur web au sein d'une équipe de 3 et je me retrouve a être le référent technique par défaut a qui on demande d'expliquer les choses. Un des devs était la avant moi et la boite vient de recruter un junior. Mon souci c'est que le dev avec l'ancienneté est plutôt médiocre et a tendance a faire des spaghettis. Il dit qu'il fait de l'OO mais en réalité il fout juste ses spaghettis dans des classes. Le junior n'est pas non plus très bon (normal c'est un junior) mais ce qui lui fait défaut ce n'est pas la qualité du code en tant que tel mais la capacité d'abstraction. De manière plus générale, ils n'arrivent pas bien a suivre le fil d’exécution d'un programme, quel processus parle avec qui, les allers/retours entre client et serveur, l'asynchronisme (ca se dit comme ca? ), etc.

    Les 2 sont de bonne volonté et je cherche des astuces pour leur faire passer ce plafond de verre mais en tant qu’autodidacte personne ne m'a jamais expliqué ces choses et du coup je ne sais pas du tout par ou commencer. Je n'ai pas vraiment de légitimité, ni par rapport a mon parcours, ni par rapport a l’ancienneté, ni par rapport a mon poste (je ne suis pas du tout le 'chef' de l’équipe) pour attraper un dev et lui dire "tu galères un peu".

    Bref du coup je me suis dit qu'il serait intéressant d'avoir des retours d’expérience, des trucs a faire ou a ne surtout pas faire, et de manière plus générale un discussion sur comment progresser me semble constructive.

    Merci

    PS: j’espère avoir poste ça au bon endroit , n’hésitez pas a bouger la discussion si ce n'est pas le cas.
    Désolé pour les rétines, clavier QWERTY

  2. #2
    Expert confirmé Avatar de DonQuiche
    Inscrit en
    septembre 2010
    Messages
    2 744
    Détails du profil
    Informations forums :
    Inscription : septembre 2010
    Messages : 2 744
    Points : 5 441
    Points
    5 441

    Par défaut

    Pour le junior il n'y a sans doute pas grand chose à faire à part laisser le temps faire son oeuvre : il s'habituera au code et deviendra plus à l'aise avec l'asynchronicité. Sauf si c'est vraiment un problème d'intelligence, auquel cas c'est sans espoir.

    Cela dit c'est une bonne idée en général de chercher à simplifier les problèmes asynchrones, en particulier via une meilleure expression des séquences asynchrones. Plusieurs langages offrent aujourd'hui les mots-clés async/await pour cela. A défaut on peut toujours se tourner vers des "promises"/"futures" basés sur des lambdas, avec des mots-clés pour les chaîner ("then"). Pour les cas plus complexes (implémentation d'un protocole ou d'un agent), divers outils existent pour générer automatiquement des machines à états à partir de spécifications plus lisibles et rigoureuses.

    Dans l'idéal nos codes devraient être si simples que n'importe quel idiot devrait pouvoir les comprendre. Cette quête éternelle réclame l'adoption de meilleurs outils et des séances de remise en cause du code existant.


    Pour le senior, tu peux opter pour plusieurs approches :
    * Prétendre que c'est un problème d'équipe, sans mettre en évidence son propre rôle. Mettre en avant une recherche collective d'amélioration de vos talents individuels. Par exemple via une prog en binôme chaque vendredi.

    * Approcher le problème avec des données concrètes : métriques du code, et exemples avec un "avant" et un "après". Si le bénéfice est évident, ça peut être un moyen puissant pour l'éduquer. Tu peux aussi simplement venir le voir de temps en temps en proposant un changement donné, sans jamais évoquer un problème général de qualité du code.

    * Organiser une discussion autour d'une certaine partie du code afin de rechercher collectivement comment le simplifier. Cela permettra ainsi de découvrir des arguments erronés ou obsolètes chez lui (obsession des performances datant des années 80), et de l'exposer à d'autres modes de pensée.

    * Recommander de bons livres tels que "coder proprement" et autres livres du même auteur.

  3. #3
    Membre confirmé
    Homme Profil pro
    Développeur Web
    Inscrit en
    octobre 2009
    Messages
    227
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Nouvelle-Zélande

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : octobre 2009
    Messages : 227
    Points : 614
    Points
    614

    Par défaut

    Coté asynchrone on utilise effectivement des promise (via axios) ainsi que .then (et .catch) et notre techno front c'est React/Redux donc tous les appels ajax sont dans un même répertoire et je pense bien lisible. Quand je parle de difficultés a suivre le fil, c'est plutôt qu'ils se perdent dans les imports ou les portées des variables, et se retrouvent a écrire du code pour tourner autour d'un problème alors qu'ils avaient une méthode disponible qui faisait le job.

    Je pense qu'ils galèrent avec le langage, habitués de jquery ils ont beaucoup de mal avec JavaScript natif et encore plus avec ES2015. Du coup ils ont du mal a lire le code qui exploite les "nouvelles" notations comme la déconstruction ou les "fat arrow functions".

    Merci pour les astuces, je pense que le code en binome est une très bonne idée dans mon cas
    Désolé pour les rétines, clavier QWERTY

  4. #4
    Expert confirmé Avatar de DonQuiche
    Inscrit en
    septembre 2010
    Messages
    2 744
    Détails du profil
    Informations forums :
    Inscription : septembre 2010
    Messages : 2 744
    Points : 5 441
    Points
    5 441

    Par défaut

    Citation Envoyé par Mrsky Voir le message
    c'est plutôt qu'ils se perdent dans les imports ou les portées des variables
    Il serait intéressant de savoir pourquoi. Cela dit ce sont surtout des problèmes causés par votre mauvais outil (JS). Même si je présume qu'une hygiène rigoureuse et une connaissance intime de la base de code permettent d'y remédier. Je connais trop peu JS pour en être certain.

    Existe t-il des outils pour y remédier (lint pour forcer bonnes pratiques ? outils pour automatiser les imports ?). Ou des bonnes pratiques que tu pourrais imposer ?

    Du coup ils ont du mal a lire le code qui exploite les "nouvelles" notations comme la déconstruction ou les "fat arrow functions".
    Cela semble étonnant car c'est trivial à lire. Je pense que tu n'as pas bien ciblé ou explicité leurs difficultés.

  5. #5
    Membre confirmé
    Homme Profil pro
    Développeur Web
    Inscrit en
    octobre 2009
    Messages
    227
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Nouvelle-Zélande

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : octobre 2009
    Messages : 227
    Points : 614
    Points
    614

    Par défaut

    Je pense que je me suis mal exprimé. Ce que je veux dire par 'se perdre dans les imports et la portée des variables' c'est leur difficulté a lire le code et a comprendre comment tout s'imbrique. Un exemple récent, hier le junior m'a demandé de créer une simple page avec un appel a notre API pour voir comment je m'y prenais. Je lui ai dit j'allais juste le faire en commentant ce que je faisais en même temps et qu'il n'hésite pas a m'interrompre, et la plupart des questions étaient d'ordre "pourquoi on a accès a cette méthode" alors qu 20 lignes plus haut il y a un "import foo from path", ou "c'est quoi cet objet" en parlant de la déconstruction dans les paramètres d'une fonction, ou "pourquoi .bind(this)". Cela dit c’était constructif comme expérience et je pense que ça l'a aidé.

    On développe from stratch donc il n'y a pas de connaissance du code a avoir ce qui rend la chose plus simple. J'ai mis en place une structure de fichiers assez simple a suivre et très standard dans le monde de React.

    A mon avis je peux assez facilement dire au junior qu'il doit progresser sur sa compréhension du JS, surtout qu'il veut devenir un expert front-end. Il est bien ouvert d'esprit et tant que je suis pas idiot et que je lui aboie pas a la figure ça devrait passer. Je suis plus embêté pour le senior et pour le coup j'ai beaucoup de mal a déterminer quelles sont ses lacunes. A l'instant par exemple il vient de nous dire "on devrait se demander quelles opérations sont difficilement faisables dans des modales HTML, comme l'upload de fichier", ce a quoi le junior a répondu "une modale c'est juste une div on peut tout faire". Je flaire de très grosses lacunes sans pouvoir vraiment mettre la main dessus.

    Je vais regarder pour intégrer JSLint a notre outil de build, je sais que ça existe mais je ne l'ai jamais utilisé.
    Désolé pour les rétines, clavier QWERTY

  6. #6
    Membre émérite
    Inscrit en
    janvier 2011
    Messages
    684
    Détails du profil
    Informations personnelles :
    Localisation : Autre

    Informations forums :
    Inscription : janvier 2011
    Messages : 684
    Points : 2 418
    Points
    2 418

    Par défaut

    Sur JS, je recommande Javascript : The Good Parts de Douglas Crockford (bouquin et vidéos : _https://www.youtube.com/watch?v=hQVTIJBZook) qui est une des références en la matière. Il a aussi un cours plus à jour des dernières nouveautés d'EcmaScript sur Pluralsight il me semble.

    JSLint est très strict, ils vont avoir une masse de recommandations et bonnes pratiques à comprendre dès le début, mais pourquoi pas.

    Sinon, pour un job qualifié, c'est pas déconnant non plus de suivre des formations de perfectionnement. Je pense à celles de Skills Matter par exemple. Après c'est à Londres, je sais pas trop ce qui existe en NZ.

  7. #7
    Expert éminent sénior

    Profil pro
    Développeur informatique
    Inscrit en
    novembre 2006
    Messages
    6 387
    Détails du profil
    Informations personnelles :
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : novembre 2006
    Messages : 6 387
    Points : 12 716
    Points
    12 716

    Par défaut

    Citation Envoyé par Mrsky Voir le message
    Le junior n'est pas non plus très bon (normal c'est un junior) mais ce qui lui fait défaut ce n'est pas la qualité du code en tant que tel mais la capacité d'abstraction. .
    la capacité d'abstraction c'est là toute la problématique ça fait l'épine dorsale d'un projet et ça ne s'apprendra jamais à l'école ni même dans les grandes Ecoles ( Polytechnique,école d'ingénieur sans vouloir troller )
    Cependant en faisant des études après le bac on apprend à avoir de la capacité d'abstraction en principe.
    Mais le risque c'est d'apprendre des théorêmes tout faits bref des patterns

    Pour développer la capacité d'abstraction il y a un truc un peu à la mode c'est la méthode Montessori..mais ce n'est sans doute pas la panacée.
    Le mieux c'est d'être créatif et de jouer aux legos
    Citation Envoyé par Mrsky Voir le message
    Ce que je veux dire par 'se perdre dans les imports et la portée des variables' c'est leur difficulté a lire le code et a comprendre comment tout s'imbrique.
    ne pas comprendre l'imbrication de classe en étant tout juste embauché sur un projet info je comprends ; mais à la longue ne pas comprendre les principes de base de la POO là j'ai des inquiétudes


    sinon je partage l'avis à 100% de DonQuiche, lecture de code croisée , instauration d'une métrique du code c'est là l'essentiel et c'est important
    Ne dites pas : "chercher la petite bête" mais plutôt "effectuer un travail d'entomologiste."
    Pour corriger des bugs c'est pareil

  8. #8
    Membre confirmé
    Homme Profil pro
    Développeur Web
    Inscrit en
    octobre 2009
    Messages
    227
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Nouvelle-Zélande

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : octobre 2009
    Messages : 227
    Points : 614
    Points
    614

    Par défaut

    JSLint semble en effet trop stricte, je pense que je vais intégrer ESLint qui est beaucoup plus configurable même si ça prend un peu plus de temps.

    La vidéo de Crockford date de 2009 j'ai peur que ce soit un peu vieux. Ça dure trop longtemps pour que je puisse la regarder au boulot donc je ferais ça chez moi pour être sur En tous cas ce sera un bon point de départ pour trouver des sources.

    J'ai la chance de bosser pour une boite qui a une vision a long terme du coup je vais voir avec notre manager si c'est possible de consacrer les vendredis après midi par exemple (qui ne sont pas des plus productifs) pour que les devs se tiennent a jour et lvlup. Personnellement j'ai beaucoup utilisé les sites qui proposent des contenus vidéo (souvent payants), et si aujourd'hui ça ne m'apporte plus autant qu'au début ça m'a vraiment aidé a franchir le cap de la professionnalisation a l’époque. Je pense que je vais suggérer ce genre de choses.

    Merci pour vos retours en tous cas !
    Désolé pour les rétines, clavier QWERTY

  9. #9
    ovh
    ovh est déconnecté
    Rédacteur
    Avatar de ovh
    Homme Profil pro
    Lead developer web full stack
    Inscrit en
    mai 2002
    Messages
    3 821
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Lead developer web full stack

    Informations forums :
    Inscription : mai 2002
    Messages : 3 821
    Points : 6 420
    Points
    6 420

    Par défaut

    Je pense que le mieux c'est de montrer l'exemple en faisant des revues de code le plus souvent possible. Et dans ces revues tu indiques le chemin diplomatiquement : "tu vois, en faisant ça et ça, tu gagnes en perf ou en maintenabilité", ou "pourquoi n'as-tu pas utilisé ça ou ça", etc. tu vois le genre. Quand tu détectes un problème, tu leur montres comment faire mieux.
    Tu peux aussi proposer des ateliers de programmation en binôme avec toi, ça ne peut être que bénéfique.

    Tutoriels sur les UPS, e-commerce, PHP, critiques de livres...

    Pensez à consulter les FAQs et les cours et tutoriels.
    FAQ Linux - Cours et tutoriels Linux - FAQ PHP - Cours et tutoriels PHP
    Ce forum est fait pour vous et surtout par vous, merci d'en respecter les règles.

    Je n'ai rien à voir avec la société www.ovh.com !

  10. #10
    Membre confirmé
    Homme Profil pro
    Développeur Web
    Inscrit en
    octobre 2009
    Messages
    227
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Nouvelle-Zélande

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : octobre 2009
    Messages : 227
    Points : 614
    Points
    614

    Par défaut

    Petit retour d’expérience après quelques semaines :
    - Le linting est un échec cuisant qui a généré plus de frustration et de 'je suis nul' qu'autre chose.
    - Le code en binôme est de loin ce qui a été le plus efficace même si ça prend beaucoup de temps, avec le junior on a "trouvé" un système ou je code et il m’interromps quand il veut et en 2 semaines je dirais a la louche qu'il me stoppe 5 fois moins qu'au début.
    - Le code review avec le senior n'a pas vraiment fonctionné, il est sur la défensive malgré la tonne de diplomatie employée et il a pondu un système de login que je soupçonne très fortement d’être un c/c d'un tuto sur le net qui malheureusement complexifie les choses inutilement (aka. les 2/3 des méthodes sont la 'au cas ou') et quand je lui ai demandé de m'expliquer ce que faisait le code pour que je l'utilise et ça a été la levée de boucliers.

    J'ai abandonné l'idée avec le senior, trop compliqué et trop risqué pour qqch qui n'est même pas mon boulot, en revanche l’expérience avec le junior est des plus plaisantes et je pense qu'on sortira grandi tous les 2 de cette pratique régulière.
    Désolé pour les rétines, clavier QWERTY

Discussions similaires

  1. faire un son quand je passe sur mon bouton
    Par cdevl32 dans le forum Flash
    Réponses: 1
    Dernier message: 24/09/2007, 09h22
  2. Que faire quand son site est plagié ?
    Par boux2 dans le forum Droit
    Réponses: 3
    Dernier message: 07/08/2006, 18h52
  3. Réponses: 4
    Dernier message: 07/11/2005, 16h54
  4. Peut-on faire du son juste avec du code assembleur ?
    Par Rick1602 dans le forum Assembleur
    Réponses: 7
    Dernier message: 26/03/2004, 18h39

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo