Quanto código devo ser responsável?

Através de colegas e entrevistas de saída, ouvi dizer que, na minha pequena empresa, sou "responsável" por 3-10 vezes mais código do que em outro trabalho. Estou tentando procurar algum tipo de métrica difusa que possa ser usada para comparar minha carga de trabalho com outras pessoas do meu campo.

Por "responsabilidade do código", não quero dizer "sou o único que conhece a área X da base de código" (embora, infelizmente, isso seja verdade em um ambiente de inicialização), mas estou me referindo a um número como "code_base_size / number_of_developers ".

Existem recursos que eu possa usar para me ajudar a medir com mais precisão minha carga de trabalho do que apenas contar linhas de código?

A única medida concreta para um desenvolvedor empregado é o número de horas gastas em codificação e correção de bugs e o dinheiro pago por isso. Se você ficar até tarde da noite 6 dias por semana por US $ 50 mil por ano, terá um problema. Não importa quantas linhas de código seu chefe deseje que você seja responsável, você não lidará com mais do que pode, levando em conta uma certa qualidade de código, é claro. Desenvolver código de baixa qualidade sem testes de unidade é uma boa maneira de lidar com muito mais código, mas a empresa terá que pagar o preço de uma grande dívida técnica .

Nas pequenas empresas, os desenvolvedores tendem a ser responsáveis ​​por muito mais código do que nas grandes empresas . O fator 3 a 10 a que você está se referindo parece realista para mim.

Conheci uma equipe de três pessoas que gerenciava uma base de código de 1,5 milhão de linhas e não estava se afogando nela. A medida importante não é a quantidade de código pelo qual você é responsável, mas a quantidade de código que você precisa alterar em um determinado incremento de tempo.

Há também o ângulo de avaliação de risco. Se você é a única pessoa que conhece um código, qual é o custo de oportunidade que seria perdido se você andar debaixo de um ônibus? As pequenas empresas geralmente não realizam avaliações de risco assim, mas isso significa que o sucesso contínuo dos negócios é deixado ao acaso.

o tamanho da base de código / número de desenvolvedores não está relacionado à carga de trabalho. Se você tiver uma enorme base de códigos estável, essa métrica será alta. Se você ainda possui um pequeno código em desenvolvimento, essa métrica será baixa. as mudanças de linhas por unidade de tempo por desenvolvedor estão mais relacionadas à carga de trabalho. Mas mesmo assim, passei dias rastreando bugs sutis, cuja correção era uma linha ...

O código deve ser de responsabilidade do grupo e não de um desenvolvedor. O suporte deve ser delegado de maneira justa a cada semana; parece estúpido alocá-lo de qualquer outra maneira. Se não for esse o caso, sugiro que você fale com sua gerência.

Na situação em que você descreve um desenvolvedor, pode estar lutando para cumprir os prazos devido a uma enorme quantidade de suporte de uma área em que outros desenvolvedores estão trabalhando mal. É uma estrutura de gerenciamento muito ineficiente.

Também sugiro que você se afaste da medição da carga de trabalho em linhas de código. Horas de homem é a única métrica sensata em que consigo pensar

Medir o progresso da programação por linhas de código é como medir o progresso da construção de aeronaves em peso - Bill Gates

NB Não estou dizendo igual, estou dizendo de maneira justa. Também vale a pena notar que é bom se especializar em certos aspectos da base de código, o que acontece naturalmente. É apenas um problema se ninguém mais trabalha nesse código.

Por exemplo, se o Facebook tivesse dois programadores, eles obviamente estariam sobrecarregados - mas como você chegaria a essa conclusão? Esse é o tipo de pergunta que eu estava fazendo.

Esta não é uma questão de programação, é uma questão de gerenciamento.
Existem algumas perguntas fáceis para responder a isso e elas não têm nada a ver com software.

1. Quantas horas você está trabalhando?
2. Quantas horas você deve estar trabalhando?
3. Os prazos estão sendo cumpridos?

Então siga esta lógica:

• Se 1> 2, você precisa de mais pessoas ou prazos menos agressivos.
• Se 1 <2, você precisa de menos pessoas ou mais iniciativas.
• Se os prazos não estiverem sendo cumpridos e 1> = 2, você precisará de mais pessoas.
• Se os prazos não estiverem sendo cumpridos e 1 <2, você deve demitir alguém.

Essa é uma simplificação excessiva que tem duas falhas gritantes.

• As pessoas não são criadas iguais.
• Existem maneiras de tornar as pessoas mais produtivas (atualize o computador ou algo assim).

Mas você entendeu.