Nouvelles tâches de développeur senior

J'ai un développeur senior avec huit ans d'expérience .NET à partir de demain pour travailler sur une application de 11 000 lignes de code. Dans l'équipe, il y a moi-même et un autre programmeur. Nous avons tous les deux environ trois ans d'expérience chacun.

C'est mon premier projet en tant que manager (je suis également développeur sur le projet) et c'est la première fois que je dois présenter à quelqu'un une base de code déjà établie. Évidemment, je vais passer en revue chaque module, le processus de déploiement, etc., et leur remettre l'emplacement du référentiel de contrôle de source, la documentation (qui n'est pas la meilleure), etc.

Combien de temps dois-je leur donner avant qu'ils ne soient prêts à commencer à écrire de nouvelles fonctionnalités et à corriger des bugs?

J'attribuerais quelques bogues de faible priorité le premier jour, de cette façon, personne ne crie s'ils ne le font pas tout de suite, ce qui donne au nouveau développeur le temps de se familiariser avec la base de code.

La chose la plus critique à faire est d'avoir une révision du code de tout son travail les deux premières semaines. Vous ne voulez pas savoir que le gars va dans la mauvaise direction ou ne suit pas les normes de codage de l'entreprise des mois durant. Il vaut mieux s'assurer qu'il sait ce qui est attendu dès le début, et les revues de code le garantissent. Bien sûr, je pense que les révisions de code sont bonnes pour tous les employés (nous examinons 100% de notre code avant le déploiement), mais elles sont essentielles pour les nouveaux employés et doivent être effectuées en personne, où vous pouvez répondre aux questions et les référer à la documentation qu'ils n'ont peut-être pas. vu encore si besoin est.

Ce que vous ne voulez pas, c'est qu'un nouveau mec arrive et utilise un style différent du reste d'entre vous. Les gens essaient souvent de continuer à utiliser le style de code de leur travail précédent même s'il entre en conflit avec le style de code utilisé au nouvel emplacement, ce qui peut créer de la confusion et de la gêne de la part des autres développeurs.

Une chose que j'ai remarquée même avec des développeurs expérimentés est que certains d'entre eux ne sont pas aussi bons qu'ils semblaient l'être dans l'interview, la révision du code vous aidera à le découvrir rapidement, afin que vous puissiez le corriger. Cela les encouragera également à faire quelque chose, j'ai vu de nouveaux employés qui ne sont pas soumis à une révision de code faire glisser un projet sans montrer ce qu'ils faisaient à personne, puis partir une semaine avant la date limite qu'ils savaient qu'ils n'allaient pas frapper parce que ils étaient au-dessus de leurs têtes et n'avaient en fait achevé aucune partie du projet. Mieux vaut vérifier tôt et souvent avec de nouvelles personnes jusqu'à ce que vous soyez vraiment sûr qu'ils travaillent.

En outre, il est normal que le nouveau gars soit consterné par l'état de votre projet hérité. Ce n'est pas conçu comme il le pense. Attendez-vous à cela, écoutez-le et ne rejetez pas automatiquement tout ce qu'il dit. En particulier, cette personne semble avoir plus d'expérience que vous ou les autres développeurs, il peut voir des choses que vous n'aviez pas envisagées. Cependant, en tant que responsable, vous devez équilibrer les modifications proposées par rapport à la charge de travail et aux délais actuels. Vous voudrez peut-être tous investir un peu de temps dans l'apprentissage de la refonte du code existant et investir quelques heures dans vos estimations de temps pour le faire, surtout si le nouveau type a des préoccupations valables. Vous ne pouvez probablement pas prendre en charge une réécriture totale (beaucoup de gens qui viennent de nouveau pensent que nous devrions recommencer et faire mieux),

Si vous avez un certain temps où il ne devrait pas contribuer pleinement (et rendre pleinement compte de son temps par le client), cela pourrait aussi être un moment où il peut commencer certaines de ces choses de refactorisation que vous avez voulu faire mais que vous n'avez pas '' t eu le temps de faire. Parfois, c'est une bonne chose d'utiliser la période de formation de la nouvelle personne pour aborder certaines choses qui ne figurent pas dans le plan de projet. Ils peuvent apprendre la base de code et si ce qu'ils veulent faire ne fonctionne pas, vous n'avez pas affecté les planifications existantes car vous ne les avez pas encore prises en compte dans la planification existante. Et si cela fonctionne, vous pourriez avoir un gros gain pour faciliter la maintenance future ou améliorer la sécurité ou quel que soit le problème.

Démarrez-les immédiatement pour de petites tâches - des choses qui ne nécessitent pas une vue d'ensemble.

À mesure qu'ils deviennent plus confiants et familiarisés avec la base de code, passez-les à des tâches de plus en plus importantes. La vitesse à laquelle cela se produit dépend principalement d'eux.

J'aime toujours obtenir des tâches qui me sont assignées dès le départ, étant entendu qu'il faudra beaucoup plus de temps pour fouiller le code, et beaucoup de questions seront posées au cours des premiers jours / semaines.

Je trouve que je ne suis pas en mesure de me concentrer complètement sur un projet tant que je ne dois pas vraiment réparer ou changer quelque chose.

Aussi ... Peu importe à quel point vous pensez avoir expliqué comment fonctionne un projet, il y a toujours le `` oh ouais j'ai oublié de vous le dire '', `` nous avons rencontré ce problème, nous l'avons donc fait '' des moments qui ne sont pas révélés avant vous commencez réellement le travail.

Combien de temps?

Quelle est la longueur d'une corde?

Quand il est à l'aise: quand il corrige son premier bug -> il est prêt .

Dans la communauté open source, tous ceux qui voulaient rejoindre le projet traitent d'abord de petits problèmes. S'il peut très bien gérer le problème, la tâche la plus importante lui sera assignée. De cette façon, ils deviendraient un développeur principal du projet.

Ce développeur senior a huit ans d'expérience .NET, vous pouvez donc lui attribuer quelques bugs simples à corriger. S'il lui est facile de les gérer, vous pouvez lui attribuer des problèmes complexes pour l'aider à se familiariser avec l'ensemble de l'application. Après cela, il pourrait commencer à écrire de nouvelles fonctionnalités et à analyser des problèmes étranges. Faites-le, il n'y a pas de temps de configuration!

8 ans d'expérience. Je le jetterais juste dedans. Il devrait pouvoir nager. Comme d'autres l'ont noté, commencez par de petites tâches faciles. Cela lui permettra de tâtonner à travers le processus d'enregistrement / de sortie du code et tout autre processus de développement que vous avez.

J'ai changé d'emploi plusieurs fois et j'ai contribué à tous dans la première semaine. Le plus dur m'a pris une semaine pour obtenir le code à compiler (100k + lignes de code au moins). Une construction complète a pris 8 heures pour ce projet.

J'ai travaillé environ 80 heures la première semaine (le projet était sérieusement en retard).

Pour une application aussi petite et un développeur expérimenté, je pense qu'une journée suffit pour les bugs de base. Bogues impliqués ou petites fonctionnalités plus proches d'une semaine (une fois qu'ils sont plus clairs sur le domaine et l'architecture du problème).

La réponse est: cela dépend. Si vous voulez qu'il corrige une erreur sur une chose ou change la couleur d'un élément GUI, alors environ 5 minutes (voici où nous conservons notre code), si vous voulez une refonte totale de l'architecture entière de l'application qui exiger un peu plus de temps.

Cela dépend vraiment de la tâche que vous attendez de lui.