Como lidar com o código 'quase bom' de um desenvolvedor júnior? [fechadas]

Se você acha que o código deve ser corrigido antes de mesclar, faça comentários. De preferência com "por que" para que o desenvolvedor possa aprender.

Lembre-se de que o código é lido com muito mais frequência do que escrito. Então, coisas que parecem "menores" podem realmente ser realmente importantes (nomes de variáveis, por exemplo).

No entanto, se você estiver fazendo comentários que parecem tediosos, talvez considere:

• O seu processo de CI deve detectar isso?
• Você tem um "guia do desenvolvedor" claro para fazer referência (ou está tudo documentado na sua cabeça)?
• Esses comentários realmente contribuem para a qualidade do código?

Muitas pessoas sacrificam a produtividade no altar do processo ou da perfeição. Tenha cuidado para não fazer isso.

Tente visitar seu colega pessoalmente, se possível. Ou use videochamadas. Construir um relacionamento torna as críticas (mesmo as revisões de código) mais fáceis de gerenciar.

Se você achar que um trecho de código tem muitos problemas, solicite a revisão em pequenos pedaços de código. Mudanças incrementais têm maior probabilidade de evitar alguns dos problemas de design mais significativos, porque são, por definição, menores.

Mas absolutamente não mescle as coisas e depois volte e corrija. Isso é passivo agressivo e se o desenvolvedor achar que você está fazendo isso, você vai matar o moral deles.

Mantenha as críticas sobre o código em vez do escritor.

Qualquer trabalho produzido vem com apego emocional inerente. Considere atenuar isso desassociando o código do gravador tanto quanto possível. A qualidade do código deve ser consistentemente estabelecida como um objetivo mútuo que vocês dois enfrentam, juntos, em vez de um ponto de atrito entre vocês.

Uma maneira de conseguir isso é escolher sabiamente suas palavras. Embora os indivíduos STEM gostem de se considerar altamente lógicos, as emoções fazem parte da natureza humana. O palavreado usado pode ser a diferença entre sentimentos feridos ou poupados. Dizer "Este nome de função seria mais consistente com as convenções se estivesse em inglês" é preferível a "Você escreveu este nome de função errado e deve estar em inglês". Enquanto o último ainda é manso e sozinho parece bem, em comparação com o anterior suas falhas tornam-se óbvias - ao preparar o que dizer pessoalmente ou um e-mail examinar ou não o seu contexto, palavras e foco estão no questões em vez da pessoa .

Linguagem Corporal

Enquanto as palavras são importantes, a maior parte da comunicação não é verbal. Preste atenção à linguagem corporal, mesmo sutilezas aparentemente insignificantes como a orientação matutina, por ex. Muitas interações entre juniores e juniores ocorrem face-a-face, mas uma abordagem lado a lado seria muito mais propícia ao resultado desejado.

Dê um feedback positivo honesto

Uma infinidade de estudos mostra que a informação é aprendida mais rapidamente e retida melhor quando recompensamos o bom comportamento, em vez de punir os maus. Às vezes, apenas observando que o desempenho foi melhorado com um simples "bom trabalho" ou um mais específico "Eu notei ultimamente que o seu estilo tem correspondido aos nossos padrões para um tee, ótimo trabalho!" mesmo complementando este reconhecimento de melhoria por tê-los, por sua vez, aconselhar alguém sobre os problemas que foram corrigidos pode fazer toda a diferença para o seu desenvolvimento júnior e seu trabalho.

The guy is open to criticism and willing to learn, but I got some doubts how much should I push some stuff.

Empurre tudo o que puder. Se o cara está aprendendo, e é seu trabalho rever o código dele, ambos têm muito a ganhar se ele fizer um bom trabalho.

Isso significa menos código para você analisar no futuro e possivelmente dar à sua equipe uma meta de contratação.

Além disso, se você se contenta, não está ajudando, mas sim protegendo.

Apenas pelo fato de você ter postado sua pergunta aqui, perguntando se você está fazendo demais, já me avisa que você não precisa desse conselho específico, mas para outros, aí vem: significa ser um idiota.

Ser um mentor não é uma tarefa fácil. Você também terá que dar algum espaço para ele cometer alguns erros e corrigi-los por conta própria, apenas tenha certeza de que ele fará isso em algum lugar que não cause dano real.

Com base na sua descrição, eu deixaria: "isso é bom. há algumas coisas que eu teria feito de forma diferente, mas elas não são muito importantes".

Como você parece entender, as críticas têm um custo e, se você gastar muito tempo com detalhes triviais, isso se torna um problema moral. Idealmente, todos os padrões de codificação são verificados automaticamente e você não pode construir, a menos que você os esteja seguindo. Este é um grande economizador de tempo e permite que você comece a trabalhar. Se você reservar suas críticas para "coisas que importam", seu conselho terá muito mais impacto e você será visto como um mentor valioso. É realmente crucial distinguir entre coisas que não são boas e coisas que não são exatamente como você faria.

Eu acredito no conceito do momento de aprendizado . Se o desenvolvedor tiver capacidade mental suficiente, ele poderá solicitar os detalhes sobre o que você faria de diferente. (S) ele pode não e isso é OK. As pessoas se esgotam e, no início de uma carreira, pode ser preciso muita energia mental para realizar coisas que parecem simples depois.

Eu consideraria aceitar o trabalho dele quando for aceitável, não perfeito. E então a próxima tarefa é depois de uma discussão para refatorar imediatamente fazendo todas as pequenas mas importantes mudanças que você quer.

Então, quando o trabalho é aceito pela primeira vez, sua mensagem é que não foi ruim, e alguns lugares o aceitaram como bom o suficiente - mas não lugares onde você gostaria de ser como um desenvolvedor júnior que quer aprender comércio corretamente.

Então você não diz "Eu rejeito seu trabalho porque não é bom o suficiente". Você diz (a) "Eu aceito seu trabalho porque é bom o suficiente", e então (b) "Mas eu quero isso melhor".

Questão bem ampla, mas aqui estão algumas idéias.

1. Avaliações por pares (pelo desenvolvedor júnior)

   A melhor maneira de alguém aprender o caminho "certo" é ver os outros fazendo isso. Todos os seus desenvolvedores realizam revisões de código? Pode não ser uma má idéia deixar que seu desenvolvedor júnior os execute também (embora você também deva exigir pelo menos uma avaliação de um desenvolvedor sênior). Dessa forma, ele verá bons codificadores em ação, além disso, ele observará que há comentários de revisão direcionados a engenheiros que não ele próprio, o que significa que não é pessoal.

2. Feedback inicial / revisões de tarefas

   Permitir que o desenvolvedor participe da análise de sua própria tarefa. Peça-lhe que registre o design pretendido nas notas da tarefa e envie uma "revisão de código" sem nenhum conjunto de alterações e apenas com a tarefa. Dessa forma, você pode rever o plano dele antes de escrever uma única linha de código. Uma vez que sua tarefa tenha sido revisada, ele pode começar a codificação (após o qual ele enviará outra revisão de código). Isso evita a situação desmoralizante em que o desenvolvedor escreveu um monte de coisas e você tem que dizer a ele para reescrevê-lo.

Se o código estiver violando objetivamente um padrão escrito e não ambíguo, acho que você deve continuar pressionando até que todos os problemas sejam corrigidos. Claro, pode ser um pouco irritante para o desenvolvedor os primeiros commits, mas eles também podem aprender as diretrizes mais cedo do que mais tarde.

Além disso, se você permitir algumas violações de padrões aqui e ali, elas definirão um mau precedente - veja teoria das janelas quebradas . Além disso, é muito mais fácil lembrar de seguir os padrões se ele já estiver sendo aplicado consistentemente à base de código. Então, realmente, todo mundo ganha, incluindo os desenvolvedores juniores em questão.

Eu não acho que o moral é um grande problema, desde que o padrão de codificação seja escrito. Só se entrar em mais subjetivo "bem, eu teria feito de forma diferente" -território, então você deve se preocupar, já que a abordagem dos desenvolvedores pode ser igualmente válida.

Considere a adoção de um fluxo de trabalho de revisão de código, onde os desenvolvedores postam seus commits propostos em uma ferramenta como Github Pull Requests ou Phabricator Diffusion e obtêm a aprovação dos pares antes de colocar as alterações na ramificação master compartilhada.

Desta forma, em vez de criticar retroativamente ou pedir a alguém para refazer o que já foi feito, o trabalho ainda não está pronto, até passar na revisão por pares. O vai e vem com os colegas é parte do processo de engenharia de software, assim como o vai e vem do compilador.

Você pode postar suas preocupações como comentários em linhas específicas e ter discussões encadeadas sobre elas. Ele pode fazer o mesmo com o seu código. A discussão permanece focada nas mudanças específicas propostas no código, e não no desempenho ou competência de alguém em geral.

Mesmo os engenheiros seniores brilhantes da minha empresa são gratos quando as revisões de código detectam erros de digitação ou os forçam a deixar as coisas mais claras. É totalmente normal que os novos contratados precisem de mais rodadas de iteração. Com o tempo, você começa a corrigir os tipos de problema que você sabe atrair comentários antes de postar um diff. Obter uma porcentagem maior de seus diffs aceitos na primeira tentativa é como você sabe que está melhorando.

I'm not pushing back code constantly on what to a novice might seem like minor details, which can be quite frustrating, but I'm also worrying that being too 'soft' might prevent the guy from learning how to do some stuff.

Estas são possibilidades reais e preocupações válidas. Pergunte ao desenvolvedor como eles se sentem sobre isso.

Supondo que você tenha alguma solicitação de solicitação ou fluxo de trabalho de revisão de código, e parece que você faz isso, eu recomendaria observar as coisas que são "não-críticas" ou "preferidas".

Se você vir um PR em um estado semelhante ao que está descrevendo, com alguns problemas de estilo menores ou precisando de refatoração não-crítica, deixe um comentário, mas também sinta-se à vontade para aprová-lo. Dizer algo como "No futuro, talvez tente evitar nomes de métodos como esse em favor de algo como descriptiveMethodName" documenta sua opinião sem forçá-los a alterá-la ou bloquear seu desenvolvimento.

Agora eles conhecem sua preferência e, se estiverem tentando melhorar, esperançosamente perceberão tal situação no futuro. Também deixa a porta aberta para eles, na verdade, mudando-a naquele momento, caso eles concordem com você e a considerem crítica o suficiente.

I'm dealing with a junior developer who's working remotely from a coding factory.

Estou curioso, o que você entende por "fábrica de codificação"? Essa terminologia, para mim, indica uma atitude perturbadora que pode estar exacerbando alguns dos problemas de gerenciamento que você mencionou.

… violation of SRP, God objects, non-meaningful names for methods or variables; I point out what he has to fix and try to explain why it is wrong.

O problema, eu acho, é que seu desenvolvedor júnior está lançando código sem ter passado por um processo de design adequado. Esta é uma falha de sua parte, como gerente e desenvolvedor sênior, para fornecer orientação e ensinar bons hábitos de desenvolvimento de software. Você pode evitar que códigos ruins sejam escritos em primeiro lugar se você trabalhar em conjunto para esboçar um contorno. Seria preferível criticar e reescrever o código depois de produzido, em termos de eficiência e moral.

Você provavelmente precisará reajustar seu fluxo de trabalho. Parece que você está esperando que ele entregue produtos para você. O que você precisa é de colaboração mais próxima, para que você possa fornecer orientação em cada etapa do desenvolvimento. Fale sobre o design e a interface antes de começar a codificação. Enquanto a codificação está acontecendo, faça checkpoints mais frequentes, para detectar problemas mais cedo. Se possível, experimente a programação em pares, via compartilhamento de tela com um canal de áudio.

Tudo isso exigirá mais esforço de sua parte, mas provavelmente valerá a pena, considerando o relacionamento problemático que você tem atualmente.

Se for uma violação dos padrões de codificação, mostre-lhe onde está para que ele saiba. Se você tem que continuar mostrando o mesmo erro, então você pode ter um problema com alguém que não está em conformidade com as regras ou se recusa. Não use seu tempo livre para consertar os erros. Essa pessoa deve corrigir seus próprios erros para que eles não os façam novamente.

Sempre diga a eles o que eles fizeram certo e como eles podem melhorar da próxima vez. Sempre podemos melhorar em alguma área. O feedback é fundamental para se tornar melhor em qualquer coisa.

Outra ideia para lidar com "excesso de críticas" é fazer uma tarefa sozinho de vez em quando e deixar que o desenvolvedor júnior faça uma revisão de código para você. Isso tem pelo menos duas vantagens:

• eles podem aprender como as coisas devem ser feitas.
• nos casos em que há várias boas soluções ou nomes de variáveis Aceito sugestões de abordagens diferentes, mas (quase?) igualmente boas. Quando eu corrijo meu código por causa do comentário de alguém, estou mostrando às pessoas que elas são respeitadas e que a crítica sempre diz respeito somente ao código - independentemente de quem seja o autor.