De combien de code devrais-je être responsable?

Grâce à des collègues et des entretiens de sortie, j'ai entendu dire que dans ma petite entreprise, je suis «responsable» de 3 à 10 fois plus de code que je ne le serais dans un autre emploi. J'essaie de chercher une sorte de métrique floue que je peux utiliser pour comparer ma charge de travail avec d'autres dans mon domaine.

Par «responsabilité de code», je ne veux pas dire «je suis le seul à connaître la zone X de la base de code» (mais malheureusement, c'est souvent vrai dans un environnement de démarrage), mais je fais plutôt référence à un nombre comme «code_base_size / number_of_developers ".

Existe-t-il des ressources que je peux utiliser pour m'aider à mesurer plus précisément ma charge de travail que de simplement compter des lignes de code?

La seule mesure concrète pour un développeur employé est le nombre d'heures passées à coder et à corriger les bogues, et l'argent que vous êtes payé pour cela. Si vous restez tard le soir 6 jours par semaine pour 50K US $ par an, alors vous avez un problème. Quel que soit le nombre de lignes de code dont votre patron veut que vous soyez responsable, vous n'en manipulerez pas plus que vous ne le pouvez, compte tenu d'une certaine qualité de code, bien sûr. Développer un code de mauvaise qualité sans tests unitaires est un bon moyen de gérer beaucoup plus de code, mais l'entreprise devra payer le prix d'une dette technique importante .

Dans les petites entreprises, les développeurs ont tendance à être responsables de beaucoup plus de code que dans les grandes entreprises . Le facteur 3 à 10 auquel vous faites référence me semble réaliste.

J'ai connu une équipe de trois personnes qui gérait une base de code de 1,5 million de lignes et ne s'y noyait pas. La mesure importante n'est pas la quantité de code dont vous êtes responsable, mais la quantité de code dont vous avez besoin pour changer dans un certain incrément de temps.

Il y a aussi l'angle d'évaluation des risques. Si vous êtes la seule personne à connaître un code, quel est le coût d'opportunité qui serait perdu si vous passiez sous un bus? Les petites entreprises ne font généralement pas d'évaluation des risques comme cela, mais cela signifie que le succès continu de l'entreprise est laissé au hasard.

la taille de base du code / le nombre de développeurs n'est pas liée à la charge de travail. Si vous avez une énorme base de code stable, cette métrique sera élevée. Si vous avez encore une petite base de code en développement, cette métrique sera faible. les changements de lignes par unité de temps par développeur sont davantage liés à la charge de travail. Mais même alors, j'ai passé des jours à suivre les bogues subtils dont la correction était une ligne ...

Le code devrait être la responsabilité du groupe et non d'un développeur. Le support doit être délégué équitablement chaque semaine, il semble stupide de l'allouer autrement. Si ce n'est pas le cas, je vous suggère de parler à votre direction.

Dans le cas où vous décrivez un développeur peut avoir du mal à respecter les délais en raison d'une énorme quantité de soutien d'un domaine où d'autres développeurs sont sous-employés. C'est une structure de gestion très inefficace.

Je vous suggère également de vous éloigner de la mesure de la charge de travail en lignes de code. Les heures de travail sont la seule métrique sensible à laquelle je peux penser

Mesurer la progression de la programmation par des lignes de code, c'est comme mesurer la progression du bâtiment d'un avion en poids - Bill Gates

NB. Je ne dis pas égal, je dis juste. Il convient également de noter que son amende pour se spécialiser dans certains aspects de la base de code, cela se produit naturellement. Ce n'est un problème que si personne d'autre ne travaille sur ce code.

Par exemple, si Facebook avait 2 programmeurs, ils seraient évidemment surchargés de travail - mais COMMENT arriveriez-vous à cette conclusion? C'est le genre de question que j'allais poser.

Ce n'est pas une question de programmation, c'est une question de gestion.
Il y a quelques questions faciles pour répondre à cela et elles n'ont rien à voir avec les logiciels.

1. Combien d'heures travaillez-vous?
2. Combien d'heures devez-vous travailler?
3. Les délais sont-ils respectés?

Suivez ensuite cette logique:

• Si 1> 2, vous avez besoin de plus de personnes ou de délais moins agressifs.
• Si 1 <2, vous avez besoin de moins de personnes ou de plus d'initiatives.
• Si les délais ne sont pas respectés et 1> = 2, vous avez besoin de plus de personnes.
• Si les délais ne sont pas respectés et 1 <2, vous devriez aller virer quelqu'un.

Il s'agit d'une simplification excessive qui présente deux défauts flagrants.

• Les gens ne sont pas créés égaux.
• Il existe des moyens de rendre les gens plus productifs (mettre à niveau leur ordinateur ou quelque chose).

Mais vous avez l'idée.