Ajudando programadores juniores a superar suas deficiências? [fechadas]

Quais são as suas queixas comuns sobre desenvolvedores juniores que se juntam à sua equipe ou com quem você tem que trabalhar? Obviamente, eles são inexperientes, então você não pode esperar que eles saibam tudo, mas que habilidades geralmente estão inexplicavelmente ausentes - e como, especificamente, podemos ajudá-los a desenvolver essas habilidades ausentes?

Não me refiro a habilidades interpessoais como 'ouvir conselhos', refiro-me a assuntos técnicos como (se aplicável):

• 'você nunca fez SQL?'

• 'você nunca escreveu um teste de unidade?'

• 'você não sabe como usar uma linha de comando Unix?'

Coisas que você não espera - Eu gostaria de ouvir suas observações e técnicas para ensinar novos programadores para superar essas deficiências específicas.

Não sabendo o que é o controle de versão ou como usá-lo corretamente .

Um dos desenvolvedores juniores que esteve na minha empresa por vários meses recentemente teve que aprender o básico do Subversion. Isso realmente me fez estremecer ... ela esteve verificando código para viver projetos o tempo todo ... e não tinha ideia do que estava fazendo ...?

Não fazendo perguntas suficientes

Eu sei que eles são juniores, espero que eles cometam erros e simplesmente não saibam as coisas. Tantos f ** k ups reais poderiam ter sido evitados apenas fazendo uma pergunta em vez de assumir algo. Honestamente, não posso ser incomodado o suficiente.

Eu tinha TONELADAS de perguntas quando comecei - perguntar a elas salvou minha bunda em várias ocasiões. Inferno, ainda tenho muitas perguntas ... Só gosto de pensar que são perguntas melhores agora.

Copie colar, tente e tente, em vez de tentar entender os fundamentos subjacentes

Muitos desenvolvedores juniores copiam o código que parece mais próximo e tentam quase aleatoriamente diferentes permutações de modificações por força bruta até encontrarem um que funcione. Se você não sabe por que ele funciona, é provável que você esteja introduzindo erros nos casos de limite que alguém que entenda terá que limpar mais tarde.

Mantendo seu "primeiro rascunho" de código

Quando um desenvolvedor experiente escreve uma nova função de uma certa complexidade, ele começa com um esboço que não faz nada além de compilar, depois reescreve para adicionar comentários de pseudo-código de alto nível ao algoritmo geral e depois reescreve esses comentários um de cada vez com código real, adicionando e removendo código fictício conforme necessário para o teste, em seguida, reescreva para remover a redundância que surgiu durante a implementação e assim por diante em uma série de melhorias sucessivas e incrementais.

Os desenvolvedores juniores tendem a escrevê-lo em uma grande parte e depois fazem uma depuração massiva de força bruta. Eles não gostam de excluir uma linha de código depois que ela é digitada no editor e ficam tão felizes que finalmente conseguiram que funcionassem que detestam reescrever para melhorias não funcionais, mas são eles que precisam fazer então o mais.

Acreditando que você é o primeiro a encontrar uma situação.

Todo problema de programação que você enfrenta foi enfrentado por outros, de alguma forma geral. Há muito o que aprender com programadores experientes. Tenho idade suficiente para lembrar de programar antes do Google e péssimo . Foi ainda pior quando tínhamos motores de busca, mas ainda não havia muita informação boa na web. A programação agora é muito mais produtiva, porque você tem acesso ao conhecimento global em segundos. As pessoas que não usam o ignoram por sua conta e risco.

Editar :

Só para ficar claro, eu estou não defendendo copiar / colar programação. Estou certo, no entanto, de que você precisa revisar o conhecimento existente antes de poder tomar boas decisões.

Pensando que eles sabem tudo.

Eu tive um jr. estagiário que tentou resolver tudo com javascript. Tentou explicar vários conceitos, mas ele sempre pensou que poderia fazê-lo melhor. Agora ele saiu e está reformulando um programa importante que ele criou para imprimir usando HTML em vez de uma tecnologia pronta para impressão, como PDF. Sem mencionar uma pilha de outros problemas importantes.

A lição é pedir aos idosos orientações importantes importantes no início de um projeto, não saia da arquitetura sem ajuda. Você pode escrever o código e os detalhes sozinho, mas certifique-se de pelo menos usar a tecnologia certa.

Raramente fico aborrecido quando os juniores não sabem o básico, eles não aprendem habilidades da indústria, como o SCC na Universidade. É o trabalho dos desenvolvedores seniores ensiná-los. Eu só me irrito com conflitos de personalidade. Mas fico muito irritado com os desenvolvedores seniores que não sabem o básico.

Não querendo avançar seus conhecimentos - seguindo o caminho de menor resistência.

Outro dia, um estagiário, juntamente com o designer gráfico (que é surpreendentemente habilidoso em programação), pediu ajuda porque teve problemas para implementar algo no jQuery - o fechamento pode ser doloroso se você não conseguir ver isso.

Sentei-me com o estagiário e expliquei exatamente o que estava errado e por quê. Corrigimos o bug, depois apontei várias melhorias adicionais que poderiam ser feitas ("desde que estou aqui") e acabamos reescrevendo a função culpada em 10 linhas, em vez de 20 e sem bugs. Depois de responder a qualquer pergunta, satisfeito de que tudo estava bem no mundo mais uma vez, eu saí.

No dia seguinte, o estagiário veio com uma pergunta que revelou que ele "hum, queria fazer algumas alterações e reescrever a função do meu jeito, porque eu achei difícil de entender" (na maioria das vezes, desfazendo minhas melhorias).

Em vez disso, ele poderia ter se esforçado mais (fazendo perguntas adicionais, lendo os conceitos que mencionei) - código tão curto que nunca pode ser tão difícil de entender - ou seguir o caminho mais fácil. Entristece-me toda vez que vejo alguém fazer o último.

Não entendo OOP. Infelizmente, isso é muito mais comum do que a maioria de nós provavelmente imagina.

Saber como criar uma classe, classe abstrata, interface ou mesmo conhecer o polimorfismo é uma coisa; entender como usá-los adequadamente para o benefício do seu programa é outra .

Se você quiser evitar essa, achei essas perguntas e as respostas esclarecedoras:

• Cheiro de código: abuso de herança - Os perigos da herança
• De onde vem esse conceito de "favorecer a composição sobre a herança"? - Os perigos dos mantras sobre evitar a herança

Sem saber o que você não sabe, e na ignorância pensando, você sabe tudo.

(E seu primo próximo, não querendo perguntar.)

Em parte, isso é uma coisa organizacional - uma indução de entrada apropriada ajudaria muito a impedir que algumas dessas coisas se tornassem problemas. Mas muito poucas empresas têm tempo ou pessoas disponíveis para uma indução de entrada - algo que deve levar de alguns dias a algumas semanas e tira os desenvolvedores de seu trabalho. Portanto, temos que apagar os fogos.

Estou impressionado com quantos programadores juniores relativamente novos de um programa de CS são fracos com algoritmos. A má escolha do algoritmo pode não se destacar na linha de aplicativos de negócios, mas ao processar bilhões de solicitações de serviço da Web por dia, isso realmente importa.

Aqui está uma pergunta de entrevista que uso, quase todos os programadores juniores sentem falta, destacando a questão:

Escreva um código que calcule o número Nésimo de Fibonacci .

Eles quase sempre se esforçam para escrever o óbvio, mas ineficiente

int Fib(int n)
{
    if (n == 0) return 0;
    if (n == 1) return 1;
    return Fib(n-2) + Fib(n-1);
}

Quando me pedem para comentar sobre a complexidade algorítmica, geralmente recebo "é pior que O (N) ... uhm ... O (N logN)". Na verdade, é (muito) pior que isso ...

Fazendo recuo de código para trás!

Claro que não é muito "típico". Eu nunca poderia acreditar que isso era possível, mas como um desenvolvedor normal escreveria

try {
    switch(action){
        case case1:
            ...
            break;
        case case2:
            ...
            break;
        default:
            break;
    }
}
catch(Exception e) {
    e.printStackTrace();
}

ela escreveria assim (Deus, ainda me parece impossível!)

            try {
        switch(action){
    case case1:
...
break;
    case case2:
...
break;
    default:
break;
        }
            }

Frustrante, não é?