Como mentor de programador júnior que pode não ser um bom candidato à programação? [duplicado]

36

Estou em uma posição precária.

Estou trabalhando remotamente para um cliente que recentemente trouxe um desenvolvedor júnior da faculdade para o projeto. Ele trabalha fisicamente em seu escritório. Acredito que ele estudou ciência da computação (embora eu não consiga me lembrar de 100% no momento).

Ele está na empresa há alguns meses e foi iniciado, pelo gerente de projeto, em testes e familiarização com o aplicativo e, por cerca de um mês, recebeu pequenos bugs e recursos.

O problema é que, naquele tempo, ele só fez o commit do código uma vez e foi um código que eu basicamente o acompanhei e escrevi para ele. (Eu pensei que seria benéfico para ele ver a solução de trabalho depois que ele passou dias tentando fazê-lo funcionar).

Eu tive algumas ligações com ele e algumas sessões de programação em pares, mas ele está passando dias ficando frustrado com um código JavaScript simples que realmente não deveria ser tão difícil nem mesmo para um desenvolvedor júnior. Estou começando a pensar que talvez a programação não seja um bom caminho para ele, mas que queira fazer o máximo de esforço possível para ajudá-lo a encontrar soluções por conta própria e ajudá-lo a melhorar.

Esta é a primeira vez que estou em posição de ter que fornecer treinamento e orientação. Ser remoto provavelmente torna isso muito mais difícil também.

O que posso fazer para ajudá-lo a melhorar e levá-lo a funcionar?

    
por Matt McCormick 21.05.2011 / 06:30
fonte

8 respostas

16

Dependendo de onde ele foi para a escola, ele pode não ter mais do que alguns meses de experiência fazendo coisas muito triviais em um idioma. Isso pode ser corrigido, mas certifique-se de que vale a pena o esforço.

Parece que você precisa dizer se ele pode ser salvo ou não.

  1. coloque o código por um tempo
  2. explica um problema pequeno a médio que existe no projeto
  3. faça com que ele explique como ele resolveria - sem código, sem padrões, com práticas, apenas com a língua nativa ou diagramas explicando o que precisa acontecer em um nível básico.

Se ele conseguir encontrar uma solução meio razoável ou até mesmo uma solução ruim, mas, pensando no processo certo de solução de problemas, ele pode aprender o código. Se ele não consegue pensar no processo de encontrar uma solução corretamente, você provavelmente não pode ensiná-lo a pensar melhor.

Certifique-se também de que sua gerência entenda a situação ou você estará fazendo o trabalho de duas pessoas antes que o seu novo cara alcance o contato.

    
por 23.05.2011 / 23:22
fonte
39

Dê a ele a chance de brilhar

Eu realmente tive uma posição muito semelhante por algum tempo, mas agora eu acho que estou fazendo algum progresso com o desenvolvedor. Eu acho que no final será apenas um caso de timidez, mas eu disse a ele: "Eu preciso que você se comprometa e empurre para o servidor para que eu possa ajudá-lo melhor se você ficar preso, e você pode me ajudar a supervisionar melhor projeto ", e então ele começou a se comprometer.

Dê a ele responsabilidades com as quais ele pode lidar (ou seja, abaixo do nível dele) para melhorar o moral.

Dê a ele a chance de falhar

Também é importante deixá-los tomar decisões e fracassar, o chamado aprendizado. Dê a ele o poder de tomar pequenas decisões arquitetônicas ou de design e ver como ele se comporta. Quando ele falhar, diga como ele pode fazer melhor e então sente-se com ele.

Não fique impaciente porque você sabe que fará em 5 minutos o trabalho que ele fará em cinco horas. Deixe-o fazer isso.

Tarefas menores

Ter atribuições menores e objetivos mais claros fará com que ele se sinta menos perdido e ataque melhor os problemas em questão; passos de bebê se você quiser.

Nem todas as pessoas têm iniciativa suficiente, infelizmente, mas a iniciativa pode ser ensinada.

Esteja lá por não estar lá

Parcialmente continuando o argumento "deixe-o falhar", mas sempre permaneça ao alcance (por exemplo, IM), mas não fisicamente. Se você ficar conectado com ele por IM, às vezes você pode responder a ele com a resposta correta, mas outras vezes você pode simplesmente deixá-lo pendurado e fingir que está ocupado (cruel, eu sei * sorriso maligno *), e apenas diga a ele "brb , google XHR e ActiveX "ou" google the compiler error ", ou" google "... fazendo isso você está parcialmente fazendo com que ele se sinta estúpido de uma maneira boa e progressivamente perdendo o medo de pesquisar coisas sozinho.

Forneça a ele as ferramentas

Ele sabe sobre o Firebug ou o Chrome Dev Tools ?. Como sobre armadilhas js comuns? Ele está usando um bom framework javascript? (por exemplo, MooTools ). Você realmente precisa dar a ele as armas para tornar seu trabalho o mais divertido e produtivo possível.

Pense nele como seu eu passado

Você nem sempre foi profissional, certo? Como você aprendeu ?, lembre-se disso e tente colocá-lo no mesmo caminho.

Se ele não é realmente cortado para o trabalho ...

Pergunte-lhe se ele está tendo problemas com alguma coisa e deixe-o saber que sua performance não é boa o suficiente. Pessoalmente eu gosto de ser direto com as pessoas, e eu digo a elas que de antemão então há o menor ressentimento.

Ele pode não saber que há um problema se você não contar a ele.

    
por 21.05.2011 / 09:33
fonte
20

Eu tive uma experiência como essa com um programador júnior. Vou dar-lhe a anedota, juntamente com o aviso óbvio de que o que funcionou para ela não funcionaria necessariamente para mais ninguém.

Seu problema era que ela nunca teve que lidar com qualquer coisa na faculdade que não fosse um sistema de brinquedos que você poderia razoavelmente ser solicitado a fazer em um conjunto de trabalhos de casa. E assim, quando ela enfrentou um problema real em uma base de código real que vinha evoluindo por décadas, ela realmente não tinha ideia de por onde começar.

Nosso gerente deu a ela um problema muito difícil, que não dependia demais de outras coisas, que eu teria terminado em poucos dias. Eu a vi ficando presa nela. Depois de um tempo, comecei a consultá-la regularmente e perguntei: "Você quer uma sugestão?" Depois de um mês ou dois, ela finalmente desmoronou e estava disposta a me ajudar.

Minha "ajuda" consistiu em fazê-la dividir o problema em pequenos pedaços. Todo dia eu entrava, conversava com ela e perguntava a ela quais eram os objetivos dela para o dia. Invariavelmente ela esculpiu uma peça mal definida e grande demais. Eu diria a ela que isso soava muito grande para mim, e eu faria com que ela cortasse e se comprometesse com algo que ela pudesse fazer de verdade ao almoçar se não encontrasse problemas sérios. Depois do almoço, eu checava como estava indo.

Em uma semana ela estava fazendo um bom progresso e havia descoberto o ritmo. Depois de mais uma semana, ela entregou uma solução perfeitamente aceitável para o problema que lhe foi entregue. Ela fez bem em seu próximo problema e passou a fazer perfeitamente bem.

Descobrimos que nosso gerente realmente esperava seu fraco desempenho inicial. Eu suspeito que ele teria eventualmente entrado, mas ele viu o que eu estava fazendo e imaginou que seria mais eficaz vir de um colega do que de um gerente.

    
por 21.05.2011 / 08:31
fonte
6

Saiba mais sobre o histórico dele e o que ele está familiarizado. Se ele tem um grau de ciência da computação, presumivelmente ele fez alguma codificação (talvez não Javascript embora). Qualquer que seja o idioma com o qual ele esteja familiarizado, veja se você pode explicar problemas / soluções em termos dessa linguagem. Se ele puder ver as semelhanças, talvez as coisas começarão a clicar.

As pessoas aprendem de maneiras diferentes, tentam descobrir como ele aprende melhor. Você poderia fazer isso como uma pergunta direta, ou novamente como parte de sondar sobre seu passado, descobrir que tipo de projetos ele gostava e fazia bem na escola e ver se ele pode explicar como eles foram estruturados. Algumas pessoas aprendem melhor ao serem solicitadas a resolver um problema com um pouco de direção e fazendo experimentação / tentativa e erro, enquanto outras vão querer ser mostradas passo a passo ...

Outro benefício para perguntar sobre seu histórico é que você será capaz de determinar melhor se ele realmente não é um bom ajuste para um trabalho de programação. Obviamente, ele deve ter algum tempo e ajudar a melhorar, mas se ele eventualmente não o fizer, será ruim para ambos se ele continuar a tentar trabalhar em um trabalho que ele não é bom.

Parece que você está tentando fazer a coisa certa ajudando-o.

(Também: é possível combinar trabalhar no site com ele por uma semana ou mais?)

    
por 21.05.2011 / 06:47
fonte
6

ele é incompetente, não o proteja - você não está fazendo nenhum favor ao seu cliente amarrando alguém que não pode executar

desculpe ser duro, mas isso é negócio; nem todo mundo com um diploma faz um bom programador

Dito isto, se você quiser ajudá-lo a melhorar, sugira que ele participe de código katas, junte-se a um grupo de usuários locais, tente codificar competições e, em geral, mantenha codificação, codificação e codificação até que faça sentido ou ele perceba que escolheu profissão errada

não deixe, em nenhuma circunstância, que essa pessoa se torne sua responsabilidade - a menos que seja realmente seu trabalho

    
por 21.05.2011 / 07:31
fonte
5

Um difícil.

Infelizmente, algumas pessoas passam por seus cursos de programação pela pele de seus dentes, e muitas vezes pela ajuda (e código) dos outros, então é inevitável que alguém saia da faculdade sem ter a primeira pista de onde começar. (Eu poderia continuar culpando um pouco o sistema educacional aqui, pois acho que há a tendência de confiar demais no código do cortador de cookies, assim como a tendência de abstrair qualquer parte da programação de baixo nível - algo que eu encontrar fundamental para o processo de programação, ou seja, lógica.)

Aqui vai:

  • Entenda que ele é totalmente novo nisso e nunca teve que lidar com algo maior que algumas milhares de linhas de código ( se isso ). Quando confrontado com uma aplicação em larga escala com consequências reais, ele será mais do que um pouco hesitante, e é improvável que também entenda a floresta, muito menos as árvores e como elas se inter-relacionam.
  • Incentive onde for possível. Se parte do código fosse utilizável, ou se você pudesse ver a direção que o código estava indo era bom, então incentive, mesmo que o resultado final não seja tão quente. Nesse ponto, guie-o até a solução, sem soletrá-la palavra por palavra. (Eu digo às pessoas que eu pesquiso por tudo. Surpreendendo as pessoas que me ignoram, no entanto.)
  • Permitir falha. Deixe-o ver o que acontece quando as coisas quebram completa e completamente, se possível. Se não for possível, me diga que isso não vai direto para a produção? Ambientes de teste regra .) Aprende-se mais com o fracasso do que com o sucesso. (Eu digo isso porque eu posso escrever código que funciona, sem entender por que funciona. Se o código quebra, eu tenho que trabalhar com o que é suposto fazer, por que parte dele funciona e por que a parte que falha não é não está funcionando.)
  • Entre no fundo um pouco. Este programador pode ter um método totalmente diferente de aprendizado e pode não ser capaz de fazer os mesmos saltos lógicos da mesma maneira que você faz. (Eu sou um bom exemplo. Eu posso fazer grandes e grandes saltos lógicos que parecem simples para mim. E então eu me pergunto por que todo mundo está querendo saber como chegar do ponto A- > B, enquanto eu já estou no ponto D. E então eu me lembro, eu sou naturalmente lógico, nem todo mundo é.
  • Dê tempo. Não é hora de não fazer nada; Não, mas com o tempo o indivíduo deve começar a pegar as coisas. Se não, no entanto, pode ser hora de ...
  • Admita derrota. Graciosamente. E não de verdade. Com isso quero dizer que você pode precisar ter uma discussão franca com o gerente, mas também perceber que você está sendo essencialmente pago para ajudá-lo. Se você deseja continuar um bom relacionamento com seu cliente, cerrar os dentes ou deixar o cliente cair pode ser sua única opção final.
por 21.05.2011 / 10:14
fonte
3

Existem obviamente muitas variáveis em jogo aqui (e algumas outras boas respostas), mas aqui estão algumas perguntas para você mesmo e alguns pensamentos:

  • Qual é a expectativa de gestão de sua posição? Ele foi contratado com a intenção de ser mentoreado? Em caso afirmativo, quanto mentoring é esperado? Isso é importante para ajudar a determinar quanto esforço gastar para ajudá-lo a se tornar mais eficiente, mesmo que seja para pequenas tarefas.
  • Ele passa algum tempo livre "auto-aprendendo" sobre o que ele está trabalhando? Por exemplo, se ele está lutando com JavaScript, ele está gastando algum tempo sozinho para se atualizar?
  • Será que ele se aproxima de seus colegas quando fica preso ou está aguardando seu tempo? Eu trabalhei com alguns desenvolvedores que preferiam sentar e olhar para a tela do que pedir ajuda.
  • Como mencionado em outra resposta, qual é o histórico dele? Ele fez alguma codificação antes da faculdade? Ele contribui para projetos de código aberto em qualquer capacidade? Isso é para ajudar a avaliar o interesse e a paixão pelo papel.
  • Quando você trabalha com ele, você permite que ele "lidere" e discuta seu processo de pensamento? Você o ajuda a chegar a uma solução correta por meio de discussões?
  • Ele mostra algum sinal de melhora ao trabalhar com ele? Lembre-se de onde ele estava quando começou e até onde ele chegou desde então. A taxa de crescimento de competência é aceitável?
  • Ele ouve você ou outras pessoas ao dar conselhos? Algumas pessoas vão aceitar conselhos e ignorá-lo ou não entendê-lo, mas, ao invés disso, continuar a fazer suas próprias coisas. Isso inclui críticas construtivas.
  • Ele realmente causa mais trabalho para os outros? É aqui que fica um pouco perigoso manter a pessoa amarrada para o passeio. Se alguém está tendo um impacto negativo em um projeto, uma reavaliação pode ser necessária para determinar se é melhor manter a orientação ou não. Você quer uma contribuição positiva, não importa quão pequena seja para começar.
  • Ele tem uma atitude positiva em relação à programação? Uma atitude pobre pode ser prejudicial não apenas para o seu próprio desempenho, mas também para os outros.
  • Perceba que nem todos são iguais. Isso não deveria ser dito, mas aí está. Todo mundo aprende e executa suas tarefas de forma um pouco diferente, mas também deve haver limites quanto ao que é aceitável ou não. Isso pode variar de empresa para empresa e projeto para projeto.

Então, realmente, isso deve se resumir a expectativas, atitude, aptidão e contribuições. Se ele mostrar que é capaz de aprender e aprender o que precisa saber, então ele pode valer a pena se tiver uma boa atitude.

O importante é que ele mostra progresso e crescimento e não fica estagnado ou facilmente frustrado. Este é um papel que requer paciência e alguma auto-motivação.

    
por 21.05.2011 / 18:21
fonte
0

Chamada difícil. Tente identificar os fundamentos subjacentes que ele está perdendo.

Para ajudá-lo a localizar a área onde o problema está, pergunte a ele quando foi a última vez que ele estava indo bem, a última vez que ele realmente entendeu o que estava fazendo, pouco antes de ficar confuso. Poderia ser algo que ele estudou antes de entrar na empresa.

Você descobrirá que em algum lugar dessa área, no material que ele acredita entender , é a causa real de sua confusão. Pode ser algo tão básico quanto nunca ter entendido o que era uma variável ou até mesmo o que significa programação. Repita isso algumas vezes e ele deve começar a ficar "mais brilhante".

Outra abordagem seria olhar para as várias coisas com as quais ele está preso. Então "triangule" e encontre o que os denominadores comuns são. Note qualquer coisa que ele faz que não faz sentido algum. Em seguida, tente entender como eles se encaixam. Se você puder encontrar um padrão, ele deve dar uma boa ideia do que ele realmente não entende.

Outra situação possível é que ele não entende o que o aplicativo deve fazer e por quê. Uma demonstração do aplicativo e algum contexto do ponto de vista do usuário poderia realmente ajudar.

Depois de saber o que ele não entende, você pode ajudá-lo de forma eficaz. Até então, você está apenas brincando e esperando ter sorte.

No entanto, lembre-se de que depurá-lo pode não ser o que seu cliente está pagando, portanto, a menos que você tenha um entendimento com seu cliente, não deixe para trás seus próprios objetivos.

Boa sorte.

    
por 21.05.2011 / 16:55
fonte