Suis-je en train de programmer trop lentement?
Cela fait seulement un an que je travaille dans l'industrie et j'ai eu quelques problèmes pour faire des estimations pour des tâches spécifiques. Avant de fermer ceci, oui, j'ai déjà lu ceci: Comment répondre quand on vous demande un devis? et c'est à peu près le même problème que j'ai. Mais je cherche une jauge d'expériences plus spécifique, quelque chose de quantifiable ou probablement les performances moyennes d'autres programmeurs que je devrais viser et baser mes estimations. Les réponses vont de semaines en semaines, et je cherchais plus une réponse au niveau d'une tâche assignée pour un jour ou deux. (Notez que cela n'inclut pas la soumission pour l'AQ ou les documentations, juste le temps de développement réel depuis l'écriture des tests si j'ai utilisé TDD, jusqu'à la création de la page, avant de la soumettre aux tests)
Mon taux actuel est actuellement le suivant (sur les formulaires Web ASP.NET):
- À l'heure actuelle, je suis en mesure de développer une page de saisie de données simple avec une liste de grille (pas de logique complexe, juste de créer et de lire) sur une architecture déjà construite, compte tenu d'une journée complète (8 heures).
- L'ajout de fonctionnalités complexes et les pages de mise à jour et de suppression ajoutent une journée supplémentaire à la tâche.
- Si je dois démarrer la page à partir de zéro (pas de solution, pas de site web existant) cela me prend une autre journée complète.
- (Pas toujours) mais si je rencontre quelque chose de nouveau ou si je ne l'ai pas encore fait, cela me prend une autre journée complète.
Chaque fois que je fais une estimation plus longue que prévu, j'ai l'impression que les autres pensent que je suis en retard par rapport à tout le monde. Je suis juste inquiet car on s'attendait à ce que lorsque ce n'est qu'une page, cela ne me prenne pas plus d'une journée. Oui, il y a certainement plus de place pour l'amélioration. Il y en a toujours. J'ai beaucoup à apprendre. Mais j'aimerais savoir si mon taux actuel est bien trop lent, juste moyen ou moyen pour quelqu'un qui ne dépasse pas un an dans l'industrie.
Si vous programmez pour un emploi et que vos supérieurs sont satisfaits du rythme auquel vous produisez, alors je dirais que vous vous en sortez bien. Comme vous avez duré un an, ils ne sont clairement pas indignés par votre sortie. En outre, vous seulement êtes là depuis un an, et en supposant qu'ils gèrent des personnes depuis plus d'une journée, ils savent qu'il y a une courbe d'apprentissage lorsque vous êtes encore vert.
Quant aux estimations ... Je suis dans l'industrie depuis 5 ans maintenant (certainement pas en territoire vétéran, je sais!), Et mes estimations personnelles sont toujours nulles. Je surestime presque aussi souvent que je sous-estime, et je fais les deux bien plus que je ne le fais bien. Quelque chose arrivera quelque part et vous mordra. Parfois, vous trouverez une bibliothèque qui fait tout ce que vous pensiez devoir faire vous-même, et le travail d'une semaine disparaît en une demi-journée. D'autres fois, un bug stupide étendra la journée de travail à 2, 3, 4 ...
Si vous répétez le même travail encore et encore et que vous avez l'impression d'avoir optimisé votre débit, vous devriez peut-être demander à être déplacé vers une autre tâche. La "pollinisation croisée" et d'autres termes favorables aux PHB sont certainement avantageux pour les développeurs. Si vous passez un mois ou plus sur autre chose, vous trouverez peut-être quelque chose qui vous convient mieux. Si ce n'est pas le cas, ou si vous n'êtes pas en mesure de rester à l'écart des formulaires Web, le changement ne vous fera aucun mal, et vous pourriez revenir avec un peu plus de connaissances et d'expérience qui vous aideront.
Heureusement, si vous avez réussi 1 an en tant que programmeur vert. J'ai été transféré dans une autre unité après seulement 9 mois (dont 3 mois en fait de programmation), pour ne pas être suffisamment productif. Et j'apprenais de plus en plus chaque jour, appréciant le processus et livrant des choses à un rythme régulier. C'était la première fois que je travaillais dans la programmation d'entreprise, eh bien ...
Il serait peut-être préférable de faire le code le plus sale et le moins fiable avec un test zéro qui reste à peine avec bubblegum lors de la tâche, afin que les gestionnaires obtiennent suffisamment de "productivité" pour leurs références.
Vous pourriez être un peu "lent" par rapport à quelqu'un qui programme depuis 5 ou 10 ans, mais tout vient avec le temps. Vous faites probablement des choses maintenant au 1/10e du temps comme lorsque vous appreniez pour la première fois, et cela continuera à devenir plus facile. C'est juste la façon dont la plupart des choses dans la vie sont ... vous êtes lent lorsque vous l'apprenez pour la première fois, et vous vous améliorez progressivement, plus rapidement, plus efficacement. Si vous vous entraînez assez longtemps, vous pourriez devenir "magistral".
Si vous faites des choses qui sont quelque peu uniques à chaque fois, passer à des tâches détaillées ou obtenir une estimation très précise sera toujours difficile.
Personnellement, j'aime le défi, mais parfois il peut vous faire paraître un peu idiot si vous regardez simplement une liste de tâches ou une chronologie.
Si vous faites des tests au fur et à mesure, je dirais que les exemples que vous avez donnés sont assez rapides selon la complexité de ce que vous faites. J'ai travaillé sur des projets où chaque élément, même certains si les éléments à l'intérieur de vos puces, avaient au moins une journée qui leur était assignée.
Chaque fois que je fais une estimation plus longue que prévu, j'ai l'impression que les autres pensent que je suis en retard par rapport à tout le monde.
C'est tout à fait commun, si personne ne donne tous une estimation plus longue en examinant un problème en détail, alors toutes les estimations auront tendance à être trop courtes.