Novas tarefas de desenvolvedor sênior

Eu tenho um desenvolvedor sênior com oito anos de experiência em .NET a partir de amanhã para trabalhar em um aplicativo de 11.000 linhas de código. Na equipe, eu e outro programador. Ambos temos cerca de três anos de experiência cada.

É o meu primeiro projeto como gerente (também sou desenvolvedor do projeto) e é a primeira vez que introduzi alguém em uma base de código já estabelecida. Obviamente, examinarei cada módulo, o processo de implantação, etc., e entregarei a eles o local do repositório de controle de origem, a documentação (que não é a melhor), etc.

Quanto tempo devo dar a eles antes que eles estejam prontos para começar a escrever novos recursos e corrigir bugs?

Eu atribuiria alguns bugs de baixa prioridade no primeiro dia, para que ninguém grite se não tiver terminado imediatamente, dando ao novo desenvolvedor algum tempo para se familiarizar com a base de código.

A coisa mais crítica a fazer é fazer uma revisão do código de todo o seu trabalho nas primeiras duas semanas. Você não quer descobrir que o cara está indo na direção errada ou não está seguindo os padrões da empresa há meses. É melhor garantir que ele saiba o que é esperado desde o início, e as revisões de código garantem isso. É claro que acho que as revisões de código são boas para todos os funcionários (revisamos 100% do nosso código antes da implantação), mas são críticas para novos funcionários e devem ser feitas pessoalmente, onde você pode responder a perguntas e encaminhá-las para a documentação que podem não ter. visto ainda, se necessário.

O que você não quer é um cara novo entrando e usando um estilo diferente do resto de vocês. As pessoas geralmente tentam continuar usando o estilo de código de seu trabalho anterior, mesmo quando ele entra em conflito com o estilo de código usado no novo local, o que pode criar confusão e aborrecimento por parte dos outros desenvolvedores.

Uma coisa que notei, mesmo com desenvolvedores experientes, é que alguns deles não são tão bons quanto pareciam na entrevista; a revisão de código ajudará você a descobrir isso rapidamente, para que você possa corrigi-lo. Isso também os incentivará a realizar alguma coisa. Vi novos funcionários que não são revisados ​​por código arrastar um projeto sem mostrar o que estavam fazendo com ninguém e, em seguida, saem uma semana antes do prazo que sabiam que não iriam atingir porque eles estavam loucos e ainda não haviam concluído nenhuma parte do projeto. É melhor verificar cedo e frequentemente com novas pessoas até ter certeza de que elas estão funcionando.

Além disso, é normal que o novo cara fique chocado com o estado do seu projeto legado. Não foi projetado da maneira que ele pensa que deveria ter sido. Espere isso, ouça-o e não descarte automaticamente tudo o que ele diz. Em particular, essa pessoa parece ter mais experiência do que você ou os outros desenvolvedores; pode ver coisas que você não considerou. No entanto, como gerente, você deve equilibrar as alterações propostas com a carga de trabalho e os prazos atuais. Todos vocês podem investir algum tempo aprendendo a refatorar o código existente e investir algumas horas nas estimativas de tempo para fazer isso, especialmente se o novo cara tiver algumas preocupações válidas. Provavelmente, você não pode apoiar uma reescrita total (muitas pessoas que entram no novo grupo pensam que devemos começar de novo e fazer melhor)

Se você tiver algum tempo em que não se espera que ele esteja contribuindo totalmente (e contabilizando totalmente seu tempo pelo cliente), também pode ser um momento em que ele poderá começar com algumas daquelas coisas de refatoração que você queria fazer, mas que ainda não fez ' Não tive tempo de fazer. Às vezes, é bom usar o período de treinamento da nova pessoa para abordar algumas coisas que não estão no plano do projeto. Eles podem aprender a base de código e, se o que eles querem fazer não funcionar, você não afetou as agendas existentes porque ainda não as incluiu na agenda existente. E se funcionar, você poderá obter uma grande vitória, facilitando a manutenção futura ou melhor a segurança ou seja qual for o problema.

Inicie-os imediatamente em pequenas tarefas - coisas que não exigem uma imagem maior.

À medida que eles se tornam mais confiantes e familiarizados com a base de código, gradue-os para tarefas cada vez maiores. A rapidez com que isso acontece depende principalmente deles.

Eu sempre gosto de ter as tarefas que me foram designadas diretamente, com o entendimento de que levará muito mais tempo para pesquisar o código, e muitas perguntas serão feitas nos primeiros dias / semanas.

Acho que não sou capaz de envolver completamente a cabeça em um projeto até ter que realmente entrar e consertar ou mudar alguma coisa.

Além disso ... Não importa o quão bem você pense que tenha explicado como um projeto funciona, sempre haverá o 'ah, sim, eu esqueci de lhe contar', 'encontramos esse problema, então fizemos isso' momentos que não são provocados até você realmente começa a trabalhar.

Quão mais?

Quanto tempo dura uma corda?

Quando ele está confortável: quando ele corrige seu primeiro erro -> ele está pronto .

Na comunidade de código aberto, todos os que desejavam ingressar no projeto lidam primeiro com alguns pequenos problemas. Se ele ou ela puder lidar muito bem com o problema, a tarefa mais importante será atribuída a ele. Dessa forma, eles se tornariam o desenvolvedor principal do projeto.

Esse desenvolvedor sênior tem oito anos de experiência em .NET, então você pode atribuir a ele alguns bugs simples para corrigir. Se for fácil para ele lidar com eles, você poderá atribuir-lhe problemas complexos para ajudá-lo a se familiarizar com todo o aplicativo. Depois disso, ele poderia começar a escrever novos recursos e analisar problemas estranhos. Basta fazê-lo, não há tempo de configuração!

8 anos de experiência. Eu apenas o jogava. Ele deveria nadar. Como outros observaram, comece com pequenas tarefas fáceis. Isso permitirá que ele atrapalhe o processo de check-in / check-out de código e quaisquer outros processos de desenvolvimento que você tiver.

Mudei de emprego muitas vezes e fui colaborador de todos eles na primeira semana. O mais difícil levou uma semana para compilar o código (pelo menos 100 mil linhas de código). Uma compilação completa levou 8 horas para esse projeto.

Trabalhei algo como 80 horas na primeira semana (o projeto estava seriamente atrasado).

Para um aplicativo tão pequeno e um desenvolvedor experiente, acho que um dia é suficiente para erros básicos. Bugs envolvidos ou pequenos recursos próximos a uma semana (depois de serem mais claros no domínio e na arquitetura do problema).

A resposta é: depende. Se você deseja que ele conserte um erro em algo ou mude a cor de um elemento da GUI, cerca de 5 minutos (aqui é onde mantemos nosso código), se você deseja um redesenho total de toda a arquitetura do aplicativo que será exigir um pouco mais.

Realmente depende da tarefa que você espera que ele realize.