Ceci est une série d'articles. Ce qui suit peut être lu ici.
À quoi s'attendre et comment aider un développeur stagiaire à devenir un junior confiant?
Le niveau du développeur est ce que tout le monde a l'habitude de mesurer et ce pour quoi tout le monde court d'une entreprise à l'autre.
Au cours des dernières années, la tendance du marché est telle que l'expérience professionnelle réelle est réduite par rapport à l'offre :: tag ::.
Ce sujet me dérange surtout parce que des années d'expérience parlent encore de quelque chose. Ils parlent de la durée pendant laquelle vous avez travaillé. Et il est purement statistiquement vrai que plus de makaps et de paires peuvent se produire en m temps qu'en n , à condition que m > n . C’est tout. En témoignent des années d'expérience. Ce n'est pas l'indicateur par lequel je vais trier les personnes des postes (s'il s'agit d'un senior, avec 1,5 ans d'expérience réelle), mais celui par lequel je déciderai entre deux candidats identiques si je ne peux pas en prendre deux.
Donc, mon type de développeur préféré est stagiaire . Ce sont des gars absolument novices, peu importe leur age_pol_religion, ils peuvent être vus dès le premier jour si leurs yeux brûlent. De plus, une question technique, comme le dit un de mes bons amis: "vous pouvez apprendre à un singe à écrire un code", et nous enseignons ... pas un singe, bien sûr ... mais une personne. Nous enseignons, nous disons, nous chassons du travail quand ils s'attardent, et ils aiment s'attarder, parce que tout est intéressant. À ce stade, la tâche du développeur est d'apprendre à travailler avec des outils, à comprendre que l'eau est mouillée, le feu est chaud et le stand-up du mot "stand". Chaque langue a une tâche typique. Dans Rub - Hartle et son alias Twitter. En javascript, tout le monde aime énormément cette feuille et toutes sortes d'implémentations pour le framework avec lequel vous travaillez. S'il peut l'écrire sur un guide étape par étape, il s'adapte aux stagiaires. Lorsqu'il peut l'écrire sans guide étape par étape, vous pouvez parler de juin. J'ai particulièrement insisté étape par étape ici, car peu importe votre expérience, vous exécuterez sur MDN pour regarder l'ordre des paramètres dans reduce et oublier les constructions de base.
Plus Junior - et il n'y a pas de transition abrupte. Il est lisse. Et c'est pourquoi notre entreprise a fait une division en Junior Débutant / Junior / Junior Fort. Mais c'est l'étape où vous pouvez immédiatement voir quelle culture est dans votre équipe, je terminerai cette section sur le Junior avec cette pensée.
Au niveau Junior, une personne sait déjà écrire du code, mais ce code ne fait rien de plus que de résoudre un problème commercial ici et maintenant. Et c'est normal, c'est avec cela que l'équipe technique, le mentor ou le service de formation devront travailler. À ce stade, vous devez expliquer à la personne le cycle de vie du bogue, pourquoi l'auto-test est important, comment le coût du bogue change en fonction du stade auquel il a été détecté.
Pour l'aider à penser et à comprendre à quoi il fait face la plupart du temps. Autrement dit, s'il envoie des demandes du navigateur au backend pendant une demi-journée, il a compris ce qu'est la demande et pourquoi le navigateur envoie 2 demandes lorsque vous avez un backend sur une autre origine. Il commence à prendre conscience des processus en développement. Il remarque progressivement à quel point il a tort dans les estimations.
C'est l'étape où il vaut la peine de jouer au Scrum Poker avec une personne et de faire une évaluation descendante de la tâche, même si vous ne l'avez pas accepté en équipe.
Il doit apprendre à formuler des pensées, à argumenter sa position, pour cela nous devons commencer à signaler des choses qui ne sont pas évidentes. Pourquoi j'ai dit sur le poker scrum et le top-down. C'est un excellent moyen de montrer à une personne les nuances auxquelles vous faites attention en raison de votre expérience, quels détails vous clarifiez, quelles spécifications vous ne semblez plus vagues et comment vous le faites.
Les résultats d'une évaluation conjointe montreront des compétences techniques, mais il est tout aussi important d'enseigner comment formuler des questions, comment communiquer avec les clients ou les parties prenantes, comment entrer les informations reçues dans le système.
Plus tôt un développeur apprend à prêter attention aux détails et à communiquer sur les tâches avec les parties prenantes, plus ce sera facile pour lui. Parce que les communications projectives et l'analyse de l'incompréhensible sont notre façon consciente de nous plonger dans l'inconnu et d'obtenir un nouveau cas +1 dans notre expérience.
Personnellement, je ne m'attends pas du tout à ce qu'au niveau junior, il obtienne au moins un peu dans ses notes dans les grandes fonctionnalités, dans les petites - peut-être, mais pas un fait. En gros - non, connaît encore peu les risques, ne prend pas en compte les tests, la psychologie du client et ne comprend pas la différence entre l'évaluation en heures et l'ETA.
Ce qui est également important est d'apprendre les compétences de base du débogage d'application, de comprendre comment trouver des changements, plusieurs sessions de programmation de paires avec le June, et vous lui transfèrerez les compétences de primitif, mais donc des techniques "géniales" pour l' instance.freeze juin instance.freeze pour attraper la mutation de l'objet. Il doit apprendre à utiliser tout cet outil multifonction, pas toujours efficacement, mais au moins il doit savoir qu'il y a un tournevis et qu'il n'a pas besoin de marteler les vis avec un marteau.
Finissant de décrire Junior`a , nous reviendrons sur la culture d'équipe. À ce niveau, une personne absorbera la culture de communication de l'équipe, si vous secouez les testeurs et les considérez inutiles, mais ne vous en rendez pas compte, regardez juin et rappelez-vous s'il était comme ça il y a six mois / un an. Se comportait-il de la même manière envers ces gens? Si "non" dans le sens négatif, voici la cloche. Il a appris cela de vous et de votre environnement. Il ne peut toujours pas dire clairement pourquoi quelque chose n'est pas important, mais c'est déjà clair. De plus, nous savons tous déjà que chaque étape du développement d'une application est importante et quelle que soit l'équipe, sans testeur ils vont dégrader le produit plus ou moins vite et plus cher.
Au départ, j'ai publié un article sur Medium , mais il me semble que pour le segment avec lequel je veux entamer une conversation - c'est une mauvaise plateforme. Je vais omettre une partie de l'intro, si vous voulez parler, écrivez à @_golubev .
J'ai donné à cette section le nom work & dev fun (damentals) . Parce que le travail et le développement sont amusants. Mais des choses fondamentales doivent être apprises. Peu importe qu'il s'agisse d'une compétence non technique ou d'une compétence difficile.
Tout ce qui est décrit plus en détail est l'expérience que j'ai acquise. Cela se limite à ma compréhension des choses qui se passent en informatique. Les processus qui ont lieu ici. Les décisions qui sont prises. Cette compréhension m'a permis de passer du stagiaire à l'un de leurs prospects dans le sens d'une pile complète. En parallèle, créer un département spécialisé dans le développement technique et le suivi de l'état émotionnel des salariés, afin de rendre leur travail confortable et de leur apporter une compréhension concrète de ce que l'on attend d'eux dans l'entreprise et le projet.