Nouvelles tâches de développeur senior

21

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?

MrBliz
la source
1
Cela dépend vraiment de la complexité des 11 000 lignes de code. Je m'attendrais à ce que quelqu'un avec 8 ans (cela signifie qu'il a commencé à l'utiliser en 2003) puisse fonctionner à pleine vitesse en une semaine.
Ramhound
En tant que point de données, il y a quelques semaines, nous avons réaffecté un développeur à un projet avec 13700 lignes de code JavaScript et avons supposé qu'il serait productif dans un sprint (une semaine) sans même vraiment y penser.
Gort le robot
@StevenBurnap: J'aime ça :) Allumez ses pieds en feu et voyez s'il brûle la maison.
Joel Etherton
Suis-je vraiment le seul à penser que les lignes 11k ne sont pas beaucoup? J'aurais donné un jour, par pure bonté de mon cœur.
Louis Kottmann
Une partie de votre choix d'affectations peut également dépendre de la fin de votre projet. Pour quelques idées sur la façon de limiter l'impact du nouveau personnel sur le personnel existant, consultez programmers.stackexchange.com/questions/164781/…
DeveloperDon

Réponses:

38

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.

HLGEM
la source
C'est une excellente réponse, en particulier la partie sur les revues de code et l'opinion des développeurs sur l'état actuel du projet. Heureusement, ce n'est pas un projet hérité, il est en fait très nouveau et évolue à un rythme très rapide.
MrBliz
1
+1 - Beaucoup de bons points, mais je voudrais réitérer qu'il est absolument essentiel de revoir tout leur travail afin que vous puissiez évaluer leur niveau de compétence et vous assurer qu'ils obtiennent la même page que l'équipe. Malheureusement, cela prend beaucoup plus de temps que les deux premières semaines. Un autre +1 pour pas aussi bon qu'à l'entrevue. Ce qui arrive à beaucoup de gens entre l'entrevue et le jour où ils se présentent est un mystère pour moi. Les lobotomies sont-elles vraiment aussi courantes qu'elles le paraissent? C'est la seule explication que je puisse trouver.
Dunk
Oui, passez en revue leur travail pour vous assurer qu'ils ne dérogent pas aux normes établies. Mais s'ils ont huit ans d'expérience et vous en avez trois, ils en savent probablement plus que vous . Assurez-vous de ne pas les forcer à faire les choses à votre façon.
DJClayworth
2
@DJClayworth, bien que je convienne que la nouvelle personne est susceptible d'avoir plus de connaissances et que le PO devrait prêter une attention particulière à ce qu'il veut faire différemment, il y a des moments où votre connaissance du système et les exigences peuvent l'emporter sur ses meilleures connaissances générales et vous devrez peut-être lui demander de prendre un chemin moins qu'optimal pour des raisons qui sont basées sur l'historique du système et les exigences. Parfois, vous devez insister pour qu'ils fassent les choses à votre façon pour des raisons dont ils ne sont peut-être pas encore au courant. Bien sûr, lorsque vous le faites, vous devez expliquer pourquoi, pas seulement nous le faisons toujours comme ça.
HLGEM
@Dunk: d'après mon expérience, même les pires personnes au monde peuvent se comporter pendant quelques heures lors d'un entretien, quand elles ont désespérément besoin d'un emploi. C'est pourquoi le contrat de location, les stages et les exemples de code sont si importants avec les nouvelles embauches.
Jordanie
18

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.

Oded
la source
C'est à peu près ce à quoi je pense.
MrBliz
+1, c'est une évidence, d'autant plus que la base de code est petite.
Louis Kottmann
8

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.

aceinthehole
la source
+1 Plus tôt la nouvelle recrue peut commencer à passer au crible le projet, plus tôt la nouvelle personne sera à l'aise (prête à s'approprier / à rendre des comptes) de ce qu'elle fait.
Chad Harrison
3

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 .

Nuit noire
la source
3

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!

Apprenez tous les jours
la source
2

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).

Bill Leeper
la source
Intéressant que tout le monde suppose que c'est un mec ... :)
MrBliz
1. Je dirais qu'en anglais, le pronom par défaut est masculin, en tapant "il ou elle" tout le temps serait approprié mais plus d'efforts que la plupart des gens ne veulent en faire. 2. Quel pourcentage de programmeurs sont des femmes? Dans ce cas, le défaut au masculin a des statistiques de son côté ... J'imagine donc qu'il serait plus simple d'utiliser la méthode simple par défaut pour désigner un individu au hasard, sans supposer spécifiquement qu'il s'agit d'un homme ou d'une femme.
Thymine
Je suis un gars et donc tout le monde doit l'être aussi :-). Juste ma façon d'écrire, je ne suis pas assez discipliné pour écrire tout le temps.
Bill Leeper
1

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).

Telastyn
la source
2
Je pense que mes standards sont probablement trop élevés, mais les vôtres ... 1 jour ... et 1 semaine pour être vraiment productif? IME, ce n'est pas très réaliste.
Dunk
@Dunk: se voir assigner des tâches et pouvoir les aborder sans se perdre complètement? Je ne dis pas qu'ils seront à pleine vitesse, mais à ce stade, ils devraient être en mesure de parcourir la base de code, savoir à qui demander d'en savoir plus, etc.
Telastyn
Oui, vraiment. 11k LoC n'est pas très gros. Faites-le configurer pour qu'il se construise et s'exécute dans le débogueur, puis montrez-lui comment cela fonctionne. Cela devrait suffire.
gbjbaanb
1

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.

jmoreno
la source