Cinco novos desenvolvedores juniores e muitas tarefas complexas. O que é agora?


10

Nossa empresa contratou cinco novos desenvolvedores juniores para me ajudar a desenvolver nosso produto. Infelizmente, os novos recursos e as correções de erros recebidas geralmente requerem um conhecimento mais profundo do que um desenvolvedor recém-formado normalmente (segmentação / simultaneidade, depuração de gargalos de desempenho em um sistema complexo etc.)

Delegar (e planejar) tarefas que eles (provavelmente) podem resolver, responder suas perguntas, orientar / gerenciar, revisar seu código consome todo o meu tempo e geralmente sinto que poderia resolver os problemas em menos tempo do que todo o processo de delegação (contando apenas o meu tempo). Além disso, não tenho tempo para resolver as tarefas que exigem conhecimentos mais aprofundados do sistema / habilidades mais avançadas e não parece que isso mude no futuro próximo.

Então, o que é agora? O que devo fazer para usar efetivamente o tempo deles e do meu?


11
Todas as 5 pessoas Jr. foram colocadas no seu projeto? Você é o único Sr. dev supervisionando-os?
Tyanna

@Tyanna: Sim, eu sou o único sênior deste projeto. Os outros idosos foram transferidos para outros projetos há algum tempo.
mxe

2
a primeira coisa a fazer é explicar à gerência que você será um pouco menos produtivo ao aumentar os novatos
jk.

Como recém-formado, estou muito surpreso com a existência de um programa que não cobre concorrência ou desempenho.
Daniel Joseph

+1. Meu único arrependimento é que não posso te votar mais.
Shivan Dragon

Respostas:


2

Sim, você pode resolver as coisas mais rapidamente do que elas, é por isso que você é mais velho e elas não. No entanto, um bom aluno sênior também quer levar os juniores para o nível sênior, e a única maneira de fazer isso é deixá-los aprender a fazer as coisas.

A tutoria é o uso mais eficaz do seu tempo agora, não a codificação.

Veja dessa maneira, se você passar os próximos seis meses mentorando de maneira eficaz e os juniores aprenderem o suficiente para se tornarem desenvolvedores intermediários - então você terá 5 desenvolvedores intermediários e um sênior. Se você faz todo o trabalho duro porque é mais rápido, em seis meses ainda terá cinco juniores mexendo o polegar (bem, o melhor deles terá passado para outros trabalhos até então, se você não lhes der um trabalho desafiador, então você pode ter menos ou mais novos devlopers juniores) e um sênior sobrecarregado e irritadiço.

Você sabe quais interações complexas são normalmente encontradas nos bugs; portanto, desenvolva algum treinamento especificamente sobre esses tipos, se necessário, como solucionar problemas e encontrar o problema real e, em seguida, os tipos de métodos normalmente necessários para corrigi-los. Depois, dê a eles esses problemas à medida que surgirem. Sim, eles levarão mais tempo para corrigi-los e você deve permitir isso em suas estimativas de tempo.

A ideia de programação de pares é ótima. Emparelhe com um diferente para cada problema verdadeiramente avançado. Mesmo que eles ainda não saibam o suficiente para resolver o problema, ter o júnior no teclado enquanto você lhes diz o que tentar em termos de procura da causa ajudará a ensiná-los o processo de solução de problemas. Claro, não apenas espere que eles tomem dictaion. explique o que você deseja que eles procurem e por quê. Peça suas idéias e ouça-as. Explique por que a ideia deles não é uma boa escolha, se não for. Use o método socrático de ensino, fazendo perguntas importantes. Eles se lembrarão melhor da solução que surgiram com suas perguntas principais do que a que você ditou a eles sem explicação. Eles também se lembrarão melhor se digitarem a solução completamente, em vez de apenas observá-la.

Depois que o júnior o ajudar a resolver uma classe específica de problemas como parte de um par, você poderá emparelhá-lo com outra pessoa na próxima vez em que essa classe de problema surgir e ficar disponível apenas para consultoria, não ficando por cima dos ombros deles. eles tentam coisas diferentes.

Você tem cinco novas pessoas, o que é realmente difícil. Você precisa ser justo com todos eles e alternar com quem você emparelha ou orienta. Não jogue favoritos. Mas você também precisará ser uma pessoa que forneça "Amor Difícil" se alguém não tiver sucesso e progredir. Você pode precisar chamar um ou mais deles de lado e dizer que eles precisam melhorar e por que você acha que eles não estão conseguindo. Uma única pessoa permitirá que você faça todo o trabalho, se você emparelhar e puder; não permita que isso seja apenas porque é mais fácil. Se a pessoa não puder fazer o trabalho, é mais gentil com ela e muito melhor para a sua equipe se você não a realizar, pois é óbvio que ela não pode ou não aprenderá a ser mais independente.

Lembre-se, você obtém o que espera. Se você não espera muito, não receberá muito. Espere que eles brilhem e a maioria deles chegará ao seu padrão.


20

A programação em pares parece uma grande possibilidade aqui.

  • Dê a quatro deles dois dos bugs mais simples, deixe-os emparelhar e faça com que cada par resolva um deles.
    • Expresse esta solicitação como "Você consegue descobrir o que está causando isso?". Não faça com que eles comecem a pensar sobre como corrigi-lo ainda.
    • Uma vez que eles têm algum nível de uma explicação, em seguida, perguntar-lhes como ele pode ser corrigido. Dessa forma, eles não ficarão tão sobrecarregados com uma enorme tarefa ao mesmo tempo. Deixe-os ir e experimentar o código, se ainda não o tiverem, e uma vez que tenham um plano - mesmo que seja vago -, você pode guiá-los para uma boa solução.
  • No outro, você pode emparelhar e começar a trabalhar em um dos mais difíceis com ele. Isso pode ser mais difícil, devido à sua inexperiência com o código, mas ele também terá o benefício de alguém com experiência em passar por ele com ele.
    • Eu acho que um novo recurso pode ser uma boa maneira de fazer isso, dada a sua experiência. Você pode mostrar a ele a API existente à medida que o novo recurso é desenvolvido.

Para uma anedota / exemplo dessa sugestão de trabalho: Foi assim que fui apresentado à parte mais cabeluda da base de código em que trabalho - com o outro desenvolvedor relativamente novo com o qual me parei, acabamos fazendo algo assim:

  • Nos foi dado um bug e, após cerca de 10 minutos de introdução, nos disseram para tentar descobrir o que estava acontecendo.
  • Cerca de uma hora depois, nos separamos e cavamos em duas linhas de pensamento diferentes.
  • Cerca de duas horas depois, eu descobri em geral como o código funcionava, mas não sabia exatamente onde a saída ruim estava sendo gerada. Ele descobriu como estava sendo gerado, pesquisando os dados brutos e desnormalizados, mas não conseguiu descobrir o código.
  • Emparelhamos novamente e seguimos os caminhos do código juntos, e obtivemos uma resposta exata. A partir disso, debatemos com o nosso gerente algumas soluções possíveis e acabamos implementando-a posteriormente.

Desde então, herdei a manutenção de toda essa parte da base de código, já que sou realmente o único que entende mais como funciona (os desenvolvedores originais que ainda estão por aí nem se lembram totalmente).


+1. O único problema pode ser dividir 5 pessoas em pares de 2 ;-)
Doc Brown

@DocBrown Bem, 5 desenvolvedores inexperientes + 1 desenvolvedor experiente significa que você pode criar 3 grupos de 2 (consulte o segundo ponto principal). Pode se tornar mais um tutorial sobre que tipo de código (interface do usuário, lógica de negócios etc.) vai para onde, mas ele aprenderá coisas diferentes das outras 4. Em seguida, no próximo conjunto de tarefas, gire.
precisa saber é o seguinte

7

Ensine-os. Atribua-lhes tarefas que eles possam resolver facilmente.

Simplificando, a questão é que a referida força de trabalho não é qualificada o suficiente para ser muito produtiva com a tarefa que possui. Como tal, você pode 1) facilitar a tarefa 2) tentar aumentar a habilidade da força de trabalho.

Problemas semelhantes quase sempre acontecem (até certo ponto) sempre que uma nova pessoa se junta a uma equipe e começa a trabalhar em uma base de código da qual não tem experiência. Isso se torna mais um problema se as ferramentas e metodologias são desconhecidas. Ao treinar a pessoa a se familiarizar com as ferramentas e metodologias, o problema pode ser amenizado mais rapidamente.

No entanto, resolver esse problema leva tempo - não se pode esperar que os outros saibam tudo ou aprendam tudo em um único momento. Talvez a introdução de alguns livros sobre concorrência, otimização de software e metodologias gerais necessárias seja um bom começo.


3

Parece que você não fez parte da decisão de contratação. Faça uma avaliação justa de suas habilidades para lidar com as tarefas atuais. Anote um relatório com uma recomendação (treinamento externo e tarefas, desde que isso não afete o tempo de entrega), envie o relatório ao seu gerente, que poderá começar a conversar com quem contratou esses funcionários. Uma nova pessoa pode ser absorvida em uma equipe, mas cinco novas pessoas ao mesmo tempo, não parecem boas, a menos que você tenha uma loja descontraída. O que quer que você faça, não tente ensiná-los no tempo do projeto, a menos que isso seja explicado no plano.

Edit: Pode ser apropriado mencionar a Lei de Brook nesta situação.


2

Talvez você possa dedicar algum tempo criando um ambiente de área restrita onde você pode jogá-los para resolver alguns dos problemas difíceis sem causar danos. Peça-lhes que testem suas soluções o máximo possível. Coloque mais de 1 no mesmo problema.

Todas essas coisas oferecem a possibilidade de serem qualificados o suficiente para serem úteis, além de exigirem menos do seu tempo. Obviamente, se você os tem (na maior parte) afundando ou nadando e eles praticamente afundam, é preciso repensar as coisas.

Na profissão de programador, as pessoas que não conseguem aprender principalmente sozinhas provavelmente não valem o esforço necessário para ensiná-las. Mas acho que eles provavelmente o surpreenderão com o desempenho deles quando você reduzir a ajuda.


Parece uma perda de tempo se o ambiente de sandbox ainda não existir.
Ramhound 29/08/2012
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.