Como orientar um desenvolvedor júnior

99

Este título é um pouco amplo, mas talvez seja necessário fornecer um pouco de experiência antes de poder fazer minha pergunta corretamente.

Eu sei que perguntas semelhantes já foram feitas aqui . Mas, no meu caso, não estou perguntando se devo orientar alguém ou se a pessoa é adequada para ser um desenvolvedor de software. Esse não é o meu lugar para julgar. Não me perguntaram diretamente, mas é aparente que eu e outros colegas desenvolvedores seniores devemos orientar os novos desenvolvedores que começam aqui. Não tenho nenhum problema com isso e, em muitos casos, isso me dá uma nova perspectiva sobre as coisas e acabo aprendendo no processo. Além disso, lembro como foi benéfico no início da minha carreira quando alguém levava algum tempo para me ensinar alguma coisa.

Quando digo "novo desenvolvedor", eles podem estar em qualquer lugar, desde recém-saídos da faculdade até um ou dois anos de experiência.

Recentemente, começamos aqui pessoas que parecem ter uma atitude em relação ao desenvolvimento / programação diferente da minha e difícil de conciliar; eles extraem informações suficientes para realizar a tarefa, mas não aprendem realmente com ela. Encontro-me repetindo as mesmas questões com eles. Entendo que parte disso pode ser uma coisa de personalidade, mas acho que é meu trabalho fazer o meu melhor e empurrá-los para fora do ninho enquanto estão sob minha asa, por assim dizer.

Como posso transmitir informações suficientes para que elas aprendam, mas não dêem o suficiente para resolver o problema?

Ou talvez:

Qual é a resposta adequada a perguntas projetadas para seguir o caminho de menor resistência e, em essência, forçá-las a aprender em vez de seguir o caminho mais fácil?

Essas perguntas provavelmente são questões de ensino mais gerais e não têm muito a ver especificamente com o desenvolvimento de software.

Nota: Não sei dizer em que tarefas eles estão trabalhando. O gerenciamento distribui a tarefa e pode ser qualquer coisa, desde uma simples correção de bug até o início de um aplicativo inteiro. Embora isso não seja o ideal de forma alguma e, obviamente, apresente seus próprios desafios, considero que é melhor deixar um tópico para outra pergunta. Portanto, o melhor que posso fazer é ajudá-los com o problema em questão e tentar ajudá-los a dividir em problemas mais simples, além de verificar os logs de confirmação e apontar os erros que eles cometeram.

Meus principais objetivos são:

  • Ajude-os e forneça as ferramentas necessárias para começar a se tornar mais autossuficientes.
  • Guie-os na direção certa e quebre os maus hábitos de desenvolvimento desde o início.
  • Diminuir a quantidade de tempo que passo com eles (o tipo de personalidade descrito acima tende a precisar de muito mais tempo individual e não se dá bem com mensagens instantâneas ou e-mail. Embora isso geralmente seja bom, nem sempre consigo parar o que estou ' estou trabalhando, quebre meu ritmo e ajude-os a depurar um erro em um instante; eu tenho meus próprios projetos que precisam ser concluídos).
Josh Johnson
fonte
1
você só pode ajudar alguém a se tornar o que ele próprio deseja. Guie aqueles que querem ser guiados.
Darknight
14
Você está certo que há muito sobre isso que não é específico para o desenvolvimento de software, mas é sobre ser um bom professor (mesmo que esse não seja seu trabalho principal). No contexto do ensino, escrevi um pequeno artigo no Chronicle of Higher Ed que diz que o sucesso pode acontecer quando você desempenha três papéis: ser um bom modelo, atuar como suporte técnico (até que eles descubram como fazer boas perguntas e onde ) e seja uma líder de torcida (paciente e solidária).
jcmeloni
1
Há um monte de ótimos comentários sobre esse tópico aqui: programmers.stackexchange.com/questions/137708/…
KodeKreachor 5/12/12
Por que você está adotando a retórica de "tutoria"? Use a palavra "treinamento": você está descrevendo "treinamento para o trabalho" , isso não é coisa filosófica, sua maneira de ver a vida no universo e tudo mais, é assim que as coisas devem ser feitas na sua empresa. (e sua empresa deve pensar um pouco mais sobre dando-lhes uma oficial)
ZJR
3
E .. se certificar de seu cubo está a meio caminho no caminho de seu cubo para o banheiro ...
vrdhn

Respostas:

121

Havia uma pergunta por aqui que continha esse tipo de informação, e a peça que mais me chamou atenção foi não tocar no teclado

Em resumo, diga ao seu aluno como realizar o que está tentando fazer, mas não faça isso por eles.

Mas além disso, aqui estão algumas outras dicas:

  • Incentive o Google (ou qualquer outra ferramenta de pesquisa). Se você souber que a resposta pode ser encontrada on-line facilmente, peça a eles para procurá-la em vez de dizer a resposta. Por fim, você deseja ensiná-los a ensinar a si mesmos , e não deixá-los depender de você.
  • Torne-se disponível para responder perguntas. Se você nunca estiver disponível ou não desejar ser interrompido, deixe claro para eles que eles devem manter suas perguntas até um tempo especificado.
  • Faça revisões de código regularmente para dizer o que está fazendo certo / errado. Use isso como uma oportunidade para apontar as melhores práticas
  • Comece cedo com as melhores práticas. É melhor dedicar um tempo extra para ensiná-los da maneira certa, do que tentar mudar seus métodos posteriormente.
  • Comece com o planejamento / documentação do que eles farão em vez de deixá-los começar a escrever código.
  • Esteja aberto a aprender com eles. Eles provavelmente gastam mais tempo do que você aprende, e é possível que eles aprendam algo que você não sabia.
  • Ajude-os a aprender com seus erros. Haverá erros, portanto, mostre a eles que os erros fazem parte do aprendizado e que eles devem usá-los como uma oportunidade de aprender.

  • (Do RuneFS abaixo) Em vez de dizer a eles como fazer algo, tente ajudá-los a descobrir por si mesmos. Isso ajudará a melhorar a capacidade de trabalhar logicamente com um problema e aumenta a capacidade de aprendizado

  • (No RuneFS abaixo) Em vez de dizer o que eles fizeram de errado, conte-lhes como eles podem melhorar. Certifique-se de incluir por que seu caminho é melhor que o deles. Isso aumentará sua confiança em vez de enfraquecê-la. Claro, se eles não estão ouvindo você, não tenha medo de dizer para eles fazerem da maneira certa :)
Rachel
fonte
68
+1 para não tocar no teclado. Em parte porque ensiná-los a fazer algo é mais importante do que fazê-lo em uma situação de mentoria, mas realmente porque eu odeio pessoas roubando meu teclado.
precisa saber é o seguinte
3
Eu sei que já foi dito, mas "não toque no teclado". É um ponto MUITO bom
Tom Squires
3
Parece-me que muito disso é apenas ensinar ao desenvolvedor júnior a fazer perguntas mais inteligentes. Grande recurso para isso: catb.org/esr/faqs/smart-questions.html
TALlama 5/12
4
Embora eu concorde com a maioria dos seus pontos, há duas partes que eu tento ensinar aos treinadores e outras pessoas responsáveis ​​pelo desenvolvimento de outras pessoas. Nunca diga a eles como fazer algo. Ajude-os a descobrir a si mesmos e nunca diga o que eles fizeram de errado e diga como podem melhorar. O ex porque isso aumenta o seu aprendizado o último porque, em vez de enfraquecer a confiança pode impulsioná-lo
Rune FS
1
@ Jae: o conselho é para o mentor não tocar no teclado do junior.
ftr
21

Tenho cerca de 4 anos de experiência e posso dizer a partir da minha experiência como desenvolvedor júnior o que eu gostaria de ter em termos de orientação. Parece que você está realmente descrevendo o tipo de desenvolvedor que eu era quando comecei :)

Essencialmente, você deseja incentivá-los a aprender. Algumas pessoas pensam que depois que terminam a faculdade, não precisam mais ler livros ou aprender mais. Esse tipo de atitude pode levar a procurar atalhos e apenas "fazê-lo".
Pegue o programador pragmático e peça para lerem. Este livro irá ajudá-los a perceber que a programação é um ofício / carreira e não apenas um trabalho. Recomende livros para eles lerem a cada trimestre. Ajude-os a criar seu "portfólio de conhecimento" (como mencionado no Pragmatic Programmer). Eu recomendo o Safari Books Online, que possui muitos livros sobre CS / Programação.

Com seu portfólio de conhecimentos, eles saberão onde procurar se tiverem problemas. Ensine-os onde procurar. Eu mesmo descobri a utilidade do StackOverflow recentemente (e como você sabe, é melhor procurar aqui do que apenas o Google).

Parece que você não pode gastar muito tempo com eles, mas a programação em pares é muito útil. Se você não pode fazer isso, pelo menos faça uma revisão de código usando o CodeCollaborator ou outra ferramenta similar. Eles não demoram tanto tempo quanto você pensa.

Os testes de unidade também são muito importantes. Eles podem revelar rapidamente más práticas de desenvolvimento, especialmente se você associar isso à integração contínua.

Atif
fonte
10

Faça as perguntas principais de volta para orientá-lo às respostas, em vez de simplesmente lhe dizer (bem, você pode dizer algumas coisas básicas, como o nome do servidor e o banco de dados que armazena as informações). Mostre a ele como encontrar suas respostas.

E nunca reescreva seu código quando estiver errado, diga a ele o que está errado e espere que ele o conserte. Você consegue o que espera. Você não ajuda ninguém, tornando-o dependente de você.

Revisões de código também são críticas. E se você emparelhar um programa, deixe-o usar o teclado com frequência. Mesmo se você estiver dizendo a ele o que digitar, ele aprenderá digitando mais do que ele aprenderá sentado ao seu lado enquanto você programa.

Pegue alguns exemplos do software que são típicos de como o aplicativo está estruturado e passe por eles linha por linha, certificando-se de que ele entende por que cada linha é necessária e o que faz. É seu trabalho garantir que ele conheça os padrões de codificação e como o código está organizado e por que você (como empresa) faz as coisas da maneira que faz.

Se ele tiver uma maneira diferente de sugerir, ouça com atenção. Em primeiro lugar, ele pode estar certo. Em segundo lugar, ouvir lhe dirá onde está sua fraqueza na compreensão, se o que ele sugere não for prático. Além disso, as pessoas tendem a respeitá-lo mais se você as ouvir. Quando ele estiver errado, volte às perguntas principais para que ele veja por que a ideia está errada. Se ele estiver perto de estar certo, siga as idéias dele algumas vezes, nada é mais desanimador do que sempre lhe dizem que suas idéias são inúteis.

Faça perguntas sobre o seu passado. Ele pode saber algumas coisas com as quais você não teve a chance de trabalhar. Se houver, e a oportunidade de usá-los surgir, faça perguntas sobre seu conhecimento.

Se seu aplicativo é antigo, provavelmente tem algumas "dicas" sorrateiras do que alguém novo não terá como saber. Portanto, quando ele estiver começando a trabalhar em áreas em que você tem uma ou mais dessas dicas, você pode contar a ele sobre ele quando ele estiver se adiantando antes da codificação, e veja se ele caiu na pegadinha quando codificou.

Finalmente, você obtém respeito, em parte, dando respeito. Trate todos os seus mentores com respeito. Não faça com que se sintam menosprezados ou estúpidos. Eles o ouvirão muito melhor se você os tratar com respeito.

HLGEM
fonte
1
Quase idêntica à resposta que eu teria me dado, mas também acrescentarei: deixe seus juniores cometerem erros (forneçam oportunidades para torná-los iguais) porque os erros fornecem a melhor oportunidade de aprender. O fracasso provoca um estímulo emocional com maior probabilidade de resultar em associação de memória que incentiva o aprendizado, e esperamos que seus juniores sejam incentivados pelo fracasso em fazer mais perguntas. Costumo dizer aos meus alunos que não há problema em tentar falhar no início, se eles também tentarem aprender com suas falhas, e uso testes e revisões de código para orientar seus esforços de aprendizado.
31712 S.Robins
Fazer perguntas importantes é uma das melhores técnicas que encontrei para levar alguém a outro nível de maturidade. Seu objetivo principal não é para levá-los para a resposta certa, é levá-los a um lugar onde eles podem reconhecer a resposta certa quando encontrá-lo (e, como tal, ser capaz de descartar as respostas erradas ao longo do caminho.)
Cânhamo
1
@ S.Robins, descobri que também é importante ressaltar que você conhece essas coisas por causa dos erros nos quais caiu.
HLGEM
8
  • Sempre garanto que o desenvolvedor deseja minha ajuda e tomo muito cuidado para não me aprofundar nas explicações do que sua paciência pode tolerar. Como todo mundo, eu amo o som da minha própria voz!
  • Trato-os como iguais, e certifique-se de pedir a opinião deles sempre que eu parecer.
  • Pegue-os fazendo algo certo e avise-os.
  • Sempre aprendo alguma coisa quando faço isso direito - sobre meu ofício, minha profissão, sobre o desenvolvedor e sobre o ensino.
  • A primeira lição é sempre: quando saber que você está tentando por conta própria há muito tempo. Muitas pessoas se orgulham de encontrar suas próprias respostas e gastam um tempo valioso em círculos.
Tom McNamee
fonte
Re: "Pegá-los fazendo algo certo": Não tenho certeza se concordo com isso, pois implica que você está sempre olhando por cima do ombro deles, ou pelo menos, verificando-os regularmente. Pode haver alguns relacionamentos onde isso é necessário, mas não acho que o relacionamento mentor / protegido seja um deles; e contradiz seus excelentes conselhos para "tratá-los como iguais".
Ruakh
Ruak, você faz um excelente argumento. Foi-me ensinado isso pelo meu gerente quando me tornei gerente (ele era meu mentor, mas ele era do Brooklyn ...) e eu nunca questionei o texto até agora. Mais apropriadamente: "Observe algo certo sobre o que eles estão fazendo". Eu começo com isso. Quando o inevitável problema 'off by 1' surge com os programadores C, posso observar que a construção do loop dela era compacta e bem comentada, e depois pedir que ela me orientasse na lógica. Obrigado.
Thomas McNamee
OK, sim, estou de acordo com isso. +1. :-)
ruakh
7

Sou desenvolvedor júnior e acho que meu mentor lida muito bem com essas coisas. Geralmente, ele me diz algumas maneiras de fazer algo, mas não como fazê-lo. Então eu costumava sentar lá e experimentar os dois lados e decidir qual era a solução mais limpa para o problema.

Além disso, se alguma vez ele estivesse fazendo algo que pudesse ser útil para mim, ele me ligaria apenas para dar uma olhada no que estava fazendo e por quê.

Isso resultou em uma pequena quantidade de tempo gasto comigo e, essencialmente, significando que eu tinha que aprender as respostas certas e como implementar as coisas. Claro, se eu ficar preso, ele estará lá para ajudar, mas isso foi um punhado de vezes. Depois de apenas 5 meses trabalhando com ele, provavelmente adquiri mais conhecimento do que todo o meu curso universitário.

O importante é lembrar que sou apenas um indivíduo e isso funcionou bem para mim por causa de como sou e como ele é. Trata-se de encontrar uma estrutura adequada que os ajude.

código de edição
fonte
5
+1 Aprendi mais sobre o trabalho do que jamais poderia ter na Universidade, só porque as pessoas dedicaram um tempo para me ensinar.
James Khoury
7

Dependendo da tarefa dada, ficaria tentado a adotar algumas abordagens diferentes:

  • Pergunte a eles o que eles tentariam a seguir para concluir a tarefa. Isso pode dar uma idéia de onde, da categoria "Eu não sei o que fazer" a "Bem, eu tentaria isso, mas ..." são eles em termos de ter sua própria idéia que pode ser útil para um ponto de partida .

  • Dê uma olhada rápida no que eles querem fazer e ofereça dicas para descobrir o problema. Isto é, em vez de dar a resposta de "Apenas retire esta linha de código", sugere que eles examinem o que está lá e é tudo necessário.

  • Se o primeiro casal não vai funcionar, eu tentaria fazê-los seguir minhas instruções sobre o que fazer para resolver o problema. Este é o próximo passo na progressão onde, se eles não têm idéia de onde começar e as dicas não funcionam, este é o próximo ponto.

  • Por fim, se nada mais funcionar, eu faria o trabalho por eles, mas tentaria evitar isso o máximo possível, pois é assim que problemas como uma pessoa conhecendo intimamente um sistema são criados, como alguém pode ter uma ideia do trabalho de descarregamento para mim por esse sistema que pareço conhecer tão bem.

JB King
fonte
+1 Eu ia escrever algo, mas isso resume minha abordagem.
Jason Sebring
5

Uma coisa que eu fiz aqui no meu trabalho que achei realmente útil foi configurar um fórum (por exemplo, PHPbb) para perguntas e respostas internas e seguir a regra de que, se a pergunta e / ou a resposta demorar mais de 5 minutos, deve ser perguntou e respondeu através do fórum. Os benefícios:

  • Obriga o desenvolvedor júnior a declarar claramente a pergunta, o que facilita a resposta, sem mencionar os momentos em que ele mesmo encontra a resposta, apenas pensando um pouco mais sobre ela.
  • Evita perguntas duplicadas, já que o desenvolvedor júnior deve começar procurando por perguntas semelhantes já feitas
  • Ajuda na construção de uma base de conhecimento que será útil para contratações futuras e para documentar muitas pequenas coisas que podem ser perdidas no tempo.
Fabio Ceconello
fonte
4

Vou reverter a tendência aqui e sugerir que você não tente incentivar os desenvolvedores juniores a aprender como encontrar as respostas. Parece um jogo do tipo "eu tenho, mas não vou dar a você".

Em vez disso, junte-se a eles para encontrar a resposta. Você vai pesquisar no Google de qualquer maneira, então faça isso enquanto está sentado com eles. Eles perceberão que esse é o caminho para encontrar respostas.

Se você trabalhar em estreita colaboração com eles, eles aprenderão como usar o IDE corretamente; Como normalizar um banco de dados; como secar o seu código ... o que você sabe que vale a pena conhecer.

As chaves são: uma - tornar-se disponível para elas, para que elas possam ver como você trabalha. E dois - para dizer em voz alta por que você está fazendo o que está fazendo. "Este código se repete, então eu vou refatorá-lo", não "use o método extract nessas três linhas".

Sean McMillan
fonte
Não acredito que você esteja contrariando a tendência. Essa é uma boa dica; trabalhar com eles e mostrar-lhes como você resolveria o problema (no entanto, talvez seja necessário fingir que eles já não sabem a resposta [não a esconda] para mostrar o processo de encontrá-lo).
Josh Johnson
E para ser claro, não tenho a intenção de esconder conhecimento. Mas ficou claro que o que eu sei está sendo aproveitado (consciente ou inconscientemente). E não estou falando de alguma caverna profunda e escondida da tecnologia que estamos usando; Estou falando da diferença entre um objeto primitivo e um objeto, ou uma variável de instância e local, ou uma mensagem de erro que diz exatamente qual é o erro e por onde começar a procurá-lo. (para referência, meu aluno atual tem 5 anos de experiência profissional, eu não acho que estou sendo irracional.)
Josh Johnson
4

Eu só tive que treinar um programador júnior uma vez. Foi para ajudar a manter um sistema que eu havia construído. O objetivo era, eventualmente, entregar todo o sistema para ele.

Depois de um curto período em que ele me sombreou, eu o joguei no fogo. Eu atribuiria casos a ele e esperaria que eles fossem concluídos. Se ele tivesse problemas, gostaria que ele explicasse qual era o problema e para onde ele olhava. Eu o aconselharia nos termos mais gerais, onde procurar a seguir. (Qual aplicativo, talvez qual módulo procurar etc.). Eu nunca o deixaria debatendo, mas também nunca faria nenhum trabalho. Apenas forneça direção. Se ele ainda tivesse problemas, eu apenas daria de ombros e diria "Comece a rastrear o código". E toda vez que eu dizia isso, ele se encolhia - sabendo que estava fazendo um exercício tedioso. Isso o deixou louco, porque nós dois sabíamos que eu provavelmente poderia encontrar o problema em 10 minutos, se eu desse um pulo e ajudasse.

Anos depois, ele mudou para coisas maiores e agora está treinando seus próprios juniores. E sua história favorita é como eu sempre dizia a ele para "rastrear o código" e como esses exercícios de rastreamento de código eram cruciais para torná-lo o programador que ele é hoje.

Brett
fonte
3

Sempre que for feita uma pergunta que eu sei que pode ser resolvida por uma rápida pesquisa no Google, encontrarei documentação ou um artigo relativo e o transmitirei à pessoa que fez a pergunta.

Saber onde procurar as coisas é uma habilidade importante, e às vezes é mais difícil do que você imagina para um novo desenvolvedor. Eles podem nem saber o que estão procurando, e é aqui que você precisa ajudá-los.

Quando disponíveis, os artigos e a documentação os forçarão a ler sobre a solução em vez de procurar outros desenvolvedores para obter uma resposta rápida.

Isso fará o seguinte:

  • Tirando parte do fardo de desenvolvedores experientes.
  • Forçando o novo desenvolvedor a aprender.
  • Felicidade para todos.

Às vezes, você apenas precisa lhes dar um amor difícil, principalmente se elas não parecem querer aprender. Não dê a resposta, mas aponte-os na direção certa.

BrandonV
fonte
3

Eu recomendaria começar a atribuir partes de tarefas reais que você possui e fazer de tudo para poder usar o código dele. Em outras palavras, treine-o como substituto para si mesmo.

Dessa forma, você se comprometerá a alocar tempo para trabalhar com os juniores e ele poderá ver a "vida real". Ao trabalhar em tarefas reais e ouvir um feedback animado, ele conseguirá acelerar rapidamente.

vang
fonte
1

Já ensinei várias disciplinas às pessoas no passado, e o que mais me impressionou é como a maioria das pessoas não tem nenhuma habilidade para resolver problemas . Ou seja, se você lhes mostrar uma solução exata, eles poderão reutilizá-la mais tarde se reconhecerem ou receberem a indicação de que precisam.

Mas, muito poucas situações na vida são assim. A menos que seu trabalho seja uma "fábrica mental" que envolva o widget A do widget B com a ferramenta C, você precisará de alguns itens:

  • Uma caixa de ferramentas de habilidades e ferramentas
  • Um método de resolução de problemas

Por exemplo, dê uma olhada nesta resposta que eu postei . Isso cobre o método de solução de problemas que muitas pessoas não possuem . O College não ensinou isso a ninguém no programa CompSci, você já sabia ou descobriu você mesmo.

Uma vez que o desenvolvedor júnior compreenda como resolver os problemas, precisará de um conjunto de ferramentas para fazer isso.

  • Depurador (a faculdade nunca mencionou isso)
  • Profilers
  • Editor de texto
  • Shell (e utilitários associados)
  • Recursos (livros, google, SO, páginas de manual)

Determine o que está faltando para o desenvolvedor júnior e você pode ajudá-lo a melhorar. Esteja ciente de que algumas pessoas realmente não estão interessadas em aprender a resolver seus próprios problemas e apenas desejam uma solução "óbvia passo a passo". Estes não são bons desenvolvedores.

Felizmente, você não terá nenhum desses. Se o fizer, perceba que, não importa quanto tempo você gaste, eles nem sempre se ajudarão. Isso exigiria esforço, e é mais fácil pedir que você faça isso por eles. É semelhante ao problema do bem-estar, e explicado pela teoria econômica.

O interesse próprio esclarecido diz que as pessoas aceitarão o que consideram a opção mais vantajosa em qualquer situação. Observe que é o que eles veem. Eu vejo a coisa mais importante como ser auto-suficiente e aprender. Então, eu mesmo faço as coisas. Mas outros podem ver que eles só precisam fornecer código de trabalho dentro do prazo. Então, eles procuram o método menos dispendioso de fazê-lo. Ao fornecer a eles "brindes", eles precisam fazer o menor esforço possível para concluir seu objetivo. Até você remover a muleta, eles não crescerão.

Spencer Rathbun
fonte
1

Sua organização, como você a descreve, é muito diferente da minha. Estou no controle do meu trabalho de juniores e vejo como meu papel julgar. Então, muita coisa é diferente.

Uma coisa que eu gostaria de aconselhá-lo a fazer de qualquer maneira é visitar frequentemente a mesa deles nas duas primeiras semanas, especialmente. Algo como três vezes ao dia na primeira semana, diminuindo gradualmente.

A mensagem que tento enviar dessa maneira é que me preocupo com a produtividade deles. Eu garanto que eles não fiquem presos. Garanto que eles sigam as regras e não reinventem a roda. Eu os ensino a cometer o mais rápido possível. Aprenda a desenvolver de forma incremental e pense em design de forma incremental.

Meu pior pesadelo são os desenvolvedores que, a cada dia, dizem que precisam de apenas mais um dia para realizar seus recursos. Após semanas de atraso, você obtém um design complicado demais, que é hackeado desde o início pelo autor. Recursos extras de buggy não solicitados são lançados no mix para compensar o atraso e porque eram um efeito colateral livre do design.

Acredito que muitos desenvolvedores estão inclinados a essa abordagem. Se você ficar sozinho com uma tarefa compex, é uma reação natural tentar provar que você pode fazê-lo por conta própria. Mas é a resposta errada. Qualidade é trabalho em equipe, e quanto mais cedo eles aprendem, melhor.

jdv-Jan de Vaan
fonte
1

As outras respostas são muito boas, mas eu queria comentar essa frase.

Recentemente e no passado, começamos aqui pessoas que parecem ter uma atitude em relação ao desenvolvimento / programação diferente da minha e difícil de conciliar; eles parecem extrair informações suficientes para realizar a tarefa, mas na verdade não aprendem com ela.

A maioria das pessoas quer saber como fazer alguma coisa. Essa atitude é boa no começo, quando você está sobrecarregado de aprender coisas novas e aprender a fazer seu trabalho.

Raras são as pessoas que querem saber por que algo é feito. Essas são as pessoas que os gerentes inteligentes desejam, mesmo que às vezes sejam difíceis de gerenciar.

Algumas pessoas codificam para serem bem pagas. Outros aceitam dinheiro com prazer pela codificação. É muito melhor trabalhar com pessoas apaixonadas por design e codificação. Infelizmente para mim, também foi bastante raro. Pelo menos até encontrar Stack Overflow.

Gilbert Le Blanc
fonte
1

Uma coisa a observar, para aqueles que estão entusiasmados com a perspectiva de fazer todo esse aconselhamento para desenvolvedores juniores: verifique se a sua gerência entende o que está acontecendo.

Ensinar outras pessoas é um trabalho árduo, em geral. É preciso foco e concentração, planejamento e esforço, e acima de tudo, leva tempo. Qualquer que seja a abordagem adotada, se você estiver ensinando e mentorando de maneira séria, estará consumindo seu tempo.

  • Se seu gerenciamento contratar desenvolvedores menos experientes com a expectativa de que os desenvolvedores seniores assumam funções de treinamento, verifique se isso é explícito. Descubra qual será o prazo e verifique se seus cronogramas de desenvolvimento refletem o tempo e o esforço gastos no treinamento. Certifique-se de que a gerência tenha alguns planos para avaliar o sucesso dos esforços de orientação em um ou mais horários acordados. (Obviamente, se eles estão contratando desenvolvedores que precisam de ensino e orientação, mas a gerência não está planejando isso, então isso é obviamente um problema sério.)

  • Nem todo mundo é um bom professor ou mentor, e nem todo mundo quer ser. Não pretendo parecer duro ou amargo; Eu gosto muito de ensinar. Mas é bobagem esperar que todo mundo seja bom nisso (apesar de seus próprios talentos), nem podemos esperar que todos gostem do processo (lembre-se, não é fácil). Além disso, se você é um desenvolvedor sênior que não gosta de orientação, ou se realmente sente que é uma má escolha para um professor ou mentor, verifique se sua gerência entende que um plano que envolva você cumprindo essas tarefas é um plano com falha grave. Por outro lado, se você quiser se tornar um bom professor ou mentor, isso também é algo para se comunicar.

  • Se o ensino e a orientação são encargos compartilhados de maneira desigual entre a população de desenvolvedores seniores, verifique se essas atribuições são reconhecidas como valiosas para a empresa da mesma maneira que as realizações de desenvolvimento de produtos são reconhecidas.

Pontudo
fonte
1

Vou dar uma olhada nele.

Basicamente, aprendo bem quando:

  1. Recebi uma introdução formal ao tópico. Nunca consigo aprender algo novo sem que alguém (sim, uma pessoa) responda a todas as perguntas que tenho sobre os novos conceitos. Uma vez feito isso, eu ...
  2. Pegue um livro. Como meu mentor, você deve ter exatamente o mesmo livro, para que eu possa sempre dizer algo como: "Ei, o que isso significa no capítulo quatro, página 72, parágrafo 6 ..." e você saberá exatamente do que estou falando sobre. Depois de ter um livro, sou mais independente e realmente só faço perguntas. Então eu...
  3. Inicie um projeto juntos. Esta é a parte mais importante do processo. É aqui que você pode começar a me ensinar sobre práticas recomendadas, algoritmos, recursos de idiomas difíceis (mas úteis) etc.

Agora você disse que tem seus próprios projetos para cuidar e que nem sempre tem tempo. Por isso fomos abençoados com o StackOverflow . Tenho certeza que eles ficariam felizes em ajudá-lo a depurar seu código. Quanto às perguntas que não estão no tópico, ele pode fazer aqui.

Com isso dito, você ainda precisa trabalhar com ele regularmente. Uma "linha do tempo" geral deve ser:

  • 1 mês. Deve saber a sintaxe básica. Ainda não é independente ao codificar.
  • 3 meses. Nesse ponto, ele deve conhecer a sintaxe como as costas da mão e ser capaz de resolver problemas simples com facilidade. Ele é muito mais independente, mas ainda não está lá.
  • 6 meses. Eles devem saber, além de tudo: Boas Práticas, Algoritmos Comuns, etc. Ele deve ser capaz de fazer um projeto sozinho, talvez com um pouco de ajuda da SO.

Além do exposto, a maneira mais fácil de tornar alguém independente é dar a eles um tópico difícil de aprender e não dar nada para ajudá-los, a não ser a Internet. Ele será forçado a aprender por si mesmo e conhecerá suas coisas.

Depois que ele souber o que você quer que ele saiba, liberte-o. Permita que ele saia e aprenda o que ele quer aprender (você sempre pode dizer que deseja que ele continue trabalhando nesse idioma).

Eu espero que isso ajude! A propósito, deixe-o ler o seguinte: Ensine-se a programar em dez anos .

Dinâmico
fonte
0

Faça uma distinção entre níveis mais baixos e mais altos de aprendizado. Se estiver relacionado ao conhecimento, à compreensão ou ao aplicativo, não tenho problemas diretamente para dar a resposta, com uma breve explicação de como eles podem procurar na próxima vez. Isso não é escola, não é trapaça, e eles não confiarão em você dessa maneira para sempre. Apenas não planeje fazer mais nada pela primeira semana ou duas, para que não o aborreça quando não o fizer.

Após as primeiras duas semanas, se você for interrompido com muita frequência com esse tipo de pergunta, use um temporizador de pomodoro e não responda a nenhuma pergunta até o final de um pomodoro. O Google é fácil para você agora, porque você sabe o que procurar. Geralmente, eles não precisam; portanto, se você precisar pedir algo para o Google, informe quais termos de pesquisa usar para obter os melhores resultados.

Se um problema está relacionado à análise, síntese ou avaliação, passo mais tempo no tópico. É aqui que você fornece seu raciocínio por trás de suas decisões e as ajuda a chegar às mesmas conclusões. Isso ocorre com mais frequência em questões de design e estilo. Não basta dizer-lhes para usar um determinado design, mostrar- lhes por que é superior à sua primeira escolha. Deixe-os cometer erros e conserte seus próprios erros.

Karl Bielefeldt
fonte
0

Não vi ninguém aqui mencionando meu herói pessoal, Randy Pausch .

Eu acho que pode ser benéfico para quem realmente faz, ensina ou ensina programação (ou mesmo para quem quer viver uma vida significativa). Você e / ou seus colegas podem assistir a essas palestras valendo o tempo que eu tenho, em

Lorand Kedves
fonte
-4

Eu, como desenvolvedor júnior, acho que, se eu me deparar com um problema, seria melhor colocar a resposta imediatamente e passar um tempo compreendendo como ela foi resolvida.

Sou pago. meu empregador não espera me pagar pelo aprendizado. eu devo fazer um trabalho no final do dia. Não adianta perder tempo em um ambiente de trabalho tentando descobrir uma solução. Isso é algo que eu aprenderei a tempo, espero que rapidamente, se sou bom no que faço.

MaxSan
fonte
9
Uma forma ou de outra o seu empregador está pagando para aprender
smp7d
13
Você é menos valioso para o seu empregador se nunca se tornar melhor do que era no dia em que foi contratado como programador júnior.
10
Max, você está errado, a menos que tenha um empregador de baixa qualidade. Bons empregadores pagarão para você aprender, no trabalho ou até mesmo enviando você para conferências ou aulas. Se você mantiver sua atitude atual, nunca espere deixar de ser um desenvolvedor júnior. Títulos como junior / senior não são distribuídos com base na quantidade de tempo que você faz alguma coisa; se você fizer a mesma coisa há muito tempo, mas não souber, ainda será considerado junior.
Andy
5
@MaxSan O problema é que os desenvolvedores seniores raramente querem dar uma colherada em você. Não contratamos estagiários como temporizadores, porque eles não conseguiram descobrir a solução por conta própria. Esperamos que você gaste algum tempo tentando descobrir isso, e somente depois de gastar um tempo razoável pedir ajuda. No último ano, espera-se que você resolva os problemas que ninguém mais pode, e você não poderá fazer isso se for alimentado com colher.
Andy
6
Se você deseja uma solução "em um prato", nunca sairá do seu status de desenvolvedor júnior. Aprender com as soluções completas fornecidas a você pode ser possível, mas certamente não é eficaz . É assim que o cérebro funciona: se você experimentar o caminho para a solução, não apenas a solução em si, aprenderá muito mais do que apenas estudar a solução que outra pessoa lhe apresentou.
Perdian