Quantos juniores deve um mentor sênior? [fechadas]

O tamanho de nossa loja aumenta dinamicamente, por isso planejamos contratar alguns novos desenvolvedores juniores, mas não gostaríamos de sobrecarregar os idosos com muita orientação e treinamento. Quantos desenvolvedores juniores (geralmente recém-saídos da faculdade) poderiam (e deveriam) um mentor para desenvolvedores seniores enquanto o sénior ainda está sendo capaz de executar suas tarefas com eficiência?

Em qualquer lugar de 0 a 5 ou 7 (mais ou menos).

Argumentos para o lado baixo:

• Nem todo mundo está disposto a ser um mentor. Eu trabalhei com alguns desenvolvedores que eram tão rudes que teriam assustado alguém para uma nova carreira.
• Se você espera que os desenvolvedores seniores mantenham o mesmo nível de saída, mantenha o número baixo.

Argumentos para uma quantidade maior:

• Alguns desenvolvedores têm a capacidade de ser tão produtivos, orientando o trabalho de outros. A programação em pares seria um exemplo. Se você tem esses tipos mágicos de desenvolvedores seniores, vá em frente e dê a eles mais.
• Se você estiver disposto a diminuir a saída esperada do desenvolvedor sênior, poderá atribuir mais desenvolvedores juniores a eles.
• Se você tem um desenvolvedor que é realmente bom em ensinar a eles o porquê da governança, pode explicitamente querer afetar a produtividade desse desenvolvedor sênior e dar a ele mais desenvolvedores juniores. A idéia aqui é um custo de curto prazo (perda de produção) para um ganho / investimento de longo prazo (melhor conformidade com os padrões de desenvolvimento da equipe).

Gostaria de encorajar uma conversa com os desenvolvedores seniores e ver com o que eles se sentem confortáveis. Nem todo mundo quer mentor. Lembre-se também de usar a analogia "estante cheia": Suas cargas de trabalho estão atualmente cheias. Se você quiser aumentar sua carga de trabalho com a orientação de mentores, precisará tirar outra coisa da prateleira para liberar espaço.

Não mais que dois por desenvolvedor sênior, se você estiver contratando pessoas diretamente da faculdade. Os recém-formados com os quais tive que lidar no passado têm uma boa compreensão do básico, mas não faziam ideia de como era programar no mundo dos negócios. Você terá que gastar tempo ensinando a eles como programar profissionalmente; é um choque quando eles perceberem que terão que dar suporte ao código que escreverem enquanto estiverem na empresa, sem precisar mais mudar tarefas e seguir em frente. Mas você também terá que gastar tempo ensinando a eles seus negócios (e todas as regras), ensinando-os a codificar sua arquitetura, revisando o código deles, ensinando-os a testar e respondendo perguntas após perguntas.

Se você tem muitos juniores entrando, digamos> 30, pode valer a pena dedicar um desenvolvedor sênior para orientá-los em período integral. No meu primeiro emprego, eles contrataram muitos de nós recém-saídos da faculdade e tinham um membro da equipe dedicado, ajudando-nos a aprender as cordas nos primeiros 6 meses. Isso facilitou muito a transição e ele nos ensinou muito.

Não é apenas mais eficiente ter uma pessoa cuidando do trabalho, como também pode haver uma pessoa em seu escritório que você sabe que seria um mentor perfeito. Um bom programador não é necessariamente um bom professor.

O maior número possível, enquanto ainda é capaz de realizar seu próprio trabalho a tempo.

A resposta, portanto, depende da eficácia do idoso, tanto como desenvolvedor quanto como professor.

Você não menciona o tipo de trabalho do projeto que, na minha experiência, tem um enorme impacto sobre onde essa proporção deve estar.

Em uma escala de repetição que pode quase ser automatizada para coisas experimentais, o desenvolvedor nem tem certeza de que funcionará. Você precisa manter os jr devs à esquerda, a menos que esteja em uma proporção realmente baixa e ainda mais estritamente à esquerda, se os sr devs estiverem tentando fazer algo que considerem experimental no final do espectro, porque geralmente não serão tão eficazes em montar uma equipe de jr devs se estiverem se esforçando ao mesmo tempo .

Depende do trabalho tanto quanto das pessoas na minha opinião.

A tutoria é menos formal que a administração. Os mentores não estão diretamente envolvidos na contratação, demissão, revisão e disciplina. O meio ambiente será um fator importante. Aqui estão os fatores a serem considerados:

• qualidade do sr. e jr. devs
• quão bem a empresa é administrada / trata programadores (isso agravará os outros problemas)
• sr. carga de trabalho atual do dev
• expectativas da administração sobre a rapidez com que o jr. desenvolvedores precisam se tornar produtivos
• outros recursos de treinamento (cursos assistidos por instrutor, materiais de referência, requisitos de certificação)
• contratação para caber na equipe. Muitas vezes, neste site, as pessoas mencionaram a importância da equipe necessária para obter um longo tempo e ser capaz de funcionar em conjunto. Alguém com um nível de habilidade mais alto pode precisar de mais orientação se não se encaixar.

A tutoria geralmente envolve algum nível de vínculo e eu simplesmente não acho que a maioria das pessoas possa construir qualquer tipo de relacionamento interpessoal com mais de 3 a 5 pessoas em um determinado ambiente.

Idealmente, um júnior trabalha com um mentor em um projeto. Dessa maneira, o idoso pode atribuir subtarefas e trabalhar com eles para concluir um projeto. Quanto mais juniores o Sênior tiver que gerenciar, menos trabalho ele poderá concluir por conta própria. Eu não gostaria que mais de 1 ou 2 juniores trabalhassem com um sénior de uma só vez. Embora o senior possa continuar a orientar outros programadores após 2 ou 3 meses, um programador decente deve precisar de muito menos tempo do senior do que originalmente. Portanto, é possível que um idoso possa ter 20 ou mais pessoas para quem ele é mentor, mas na verdade apenas 2 ou 3 que realmente exigem muito do seu tempo.