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

Eu tenho uma pergunta sobre gerenciamento de equipe. No momento, estou lidando com um desenvolvedor júnior que trabalha remotamente em uma fábrica de códigos. O cara está aberto a críticas e disposto a aprender, mas eu tenho algumas dúvidas sobre o quanto devo empurrar algumas coisas.

Agora mesmo, quando algo é claro e óbvio, uma violação das boas práticas: como violação do SRP, objetos de Deus, nomes não significativos para métodos ou variáveis; Aponto o que ele precisa consertar e tento explicar por que está errado.

Minha pergunta é: quando eu paro? No momento, se houver algumas violações menores do estilo de codificação, como nomes de variáveis ​​no idioma errado (a equipe anterior misturou espanhol e inglês e estou tentando consertar isso), ou alguns problemas estruturais menores que estou deixando para trás e consertá-lo se Tenho algum tempo livre ou preciso modificar a classe problemática. Eu sinto que isso é bom para o moral da equipe, por isso não estou repetindo constantemente o código sobre o que para um iniciante pode parecer detalhes menores, o que pode ser bastante frustrante, mas também estou preocupada que ser muito 'suave' possa impedir o cara de aprender a fazer algumas coisas.

Como equilibrar a linha entre ensinar o cara e não deixá-lo esgotado com críticas constantes? Para um júnior, pode ser frustrante se você disser para ele refazer coisas que, aos olhos dele, estão funcionando.

Se você acha que o código deve ser corrigido antes da mesclagem, 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. Portanto, coisas que parecem "secundárias" podem ser realmente importantes (nomes de variáveis, por exemplo).

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

• Seu processo de IC deve capturar isso?
• Você tem um "guia do desenvolvedor" claro para fazer referência (ou está tudo documentado em 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. Cuidado para não fazer isso.

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

Se você achar que um trecho de código tem muitos problemas de retorno / retorno, solicite a revisão sobre trechos de código menores. É provável que mudanças incrementais evitem alguns dos problemas de design mais significativos, porque são por definição menores.

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

Mantenha as críticas ao código e não ao escritor.

Qualquer trabalho produzido vem com um apego emocional inerente. Considere facilitar isso desassociando o código do gravador o máximo possível. A qualidade do código deve ser consistentemente estabelecida como um objetivo mútuo que vocês 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 mágoa ou sentimentos poupados. Dizer "Este nome de função seria mais consistente com as convenções se estivesse em inglês" é preferível a "Você escreveu esse nome de função errado e deve estar em inglês". Enquanto o último ainda é manso e sozinho pareceria bom, em comparação com o primeiro, suas falhas se tornam óbvias - ao preparar o que dizer pessoalmente ou por e-mail, examine se o seu contexto ou não, as palavras e o foco estão nas questões e não a pessoa .

Linguagem corporal

Embora as palavras sejam importantes, a maioria das comunicações é não verbal. Preste atenção à linguagem corporal, mesmo as sutilezas aparentemente insignificantes, como a orientação, por exemplo. Muitas interações júnior-sênior ocorrem cara a cara, mas uma abordagem lado a lado seria muito mais favorável ao resultado desejado.

Dê um feedback positivo honesto

Vários estudos mostram que as informações são aprendidas mais rapidamente e retidas melhor quando recompensamos o bom comportamento, em vez de punir os maus. Às vezes, apenas observando que o desempenho foi aprimorado com um simples "bom trabalho" ou um "mais específico" notei recentemente que seu estilo está combinando nossos padrões com um tee, ótimo trabalho! " mesmo complementando esse reconhecimento de melhoria, solicitando que, por sua vez, avise alguém sobre os problemas que foram corrigidos, pode fazer toda a diferença para o desenvolvedor júnior e o trabalho dele.

O cara está aberto a críticas e disposto a aprender, mas eu tenho algumas dúvidas sobre o quanto devo empurrar algumas coisas.

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

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

Além disso, se você se segurar, não estará ajudando, mas a ser condescendente.

Só pelo fato de você ter postado sua pergunta aqui, perguntando se está fazendo muito, já me assina que você não precisa desse conselho específico, mas para outros, aqui vem: lembre-se de que pressionar demais não significa sendo 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 certifique-se de que ele faça isso em algum lugar que não cause danos reais.

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

Como você entende, as críticas têm um custo e, se você gastar muito tempo com detalhes, 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 os esteja seguindo. Isso economiza muito tempo e permite que você comece a trabalhar. Se você reservar suas críticas para 'coisas que importam', seus conselhos terão 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 de momento ensinável . Se o desenvolvedor tiver capacidade mental suficiente, ele poderá solicitar detalhes sobre o que você faria de diferente. (S) ele pode não e está tudo bem. As pessoas se cansam e, no início de uma carreira, pode ser necessária muita energia mental para realizar coisas que parecem simples mais tarde.

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

Portanto, quando o trabalho é aceito pela primeira vez, sua mensagem é de que não era ruim e alguns lugares o aceitariam como bom o suficiente - mas não em lugares onde você gostaria de ser um desenvolvedor júnior que deseja aprender seu ofício corretamente.

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

Uma questão bastante ampla, mas aqui estão algumas idéias.

1. Revisõ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 permitir que seu desenvolvedor júnior os execute também (embora você também deva exigir pelo menos uma revisão de um desenvolvedor sênior). Dessa forma, ele verá bons codificadores em ação, além de observar que existem comentários de revisão direcionados a engenheiros que não ele, o que significa que não é pessoal.

2. Feedback inicial / Revisões de tarefas

   Permita que o desenvolvedor participe de sua própria divisão de tarefas. Faça com que ele grave o design pretendido nas notas da tarefa e envie uma "revisão de código" sem nenhum conjunto de alterações e apenas a tarefa. Dessa forma, você pode revisar seu plano antes que ele tenha escrito uma única linha de código. Depois que sua tarefa for revisada, ele poderá começar a codificar (após o qual enviará outra revisão de código). Isso evita a situação desmoralizante em que o desenvolvedor escreveu um monte de coisas e você precisa dizer a ele para reescrevê-lo.

Se o código violar objetivamente um padrão inequívoco por escrito, acho que você deve continuar pressionando até que todo problema seja resolvido. Claro, pode ser um pouco chato para o desenvolvedor nos primeiros commits, mas eles podem aprender as diretrizes mais cedo ou mais tarde.

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

Não acho que o moral seja um grande problema, desde que o padrão de codificação seja anotado. Somente se entrar em um território mais subjetivo "bem, eu teria feito de maneira diferente", então você deve se preocupar, pois a abordagem dos desenvolvedores pode ser igualmente válida.

Considere adotar um fluxo de trabalho de revisão de código, no qual os desenvolvedores publicam seus commits propostos em uma ferramenta como Github Pull Requests ou Phabricator Diffusion e obtenham aprovação de colegas antes de fazer as alterações na ramificação principal compartilhada.

Dessa forma, em vez de criticar ou pedir retroativamente a alguém que refaça o que já foi feito, o trabalho ainda não está concluído até que seja aprovado na revisão por pares. A alternância entre pares é tão parte do processo de engenharia de software quanto a alternância com o 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 alterações específicas do código proposto, e não no desempenho ou competência de alguém em geral.

Até engenheiros seniores brilhantes da minha empresa ficam gratos quando as revisões de código detectam erros de digitação ou as forçam a deixar as coisas mais claras. É totalmente normal que novas contratações exijam mais rodadas de iteração. Com o tempo, você começa a corrigir reflexivamente os tipos de problemas que você sabe que atrairão comentários antes de postar uma comparação. Obter uma porcentagem maior de suas diferenças aceitas na primeira tentativa é como você sabe que está melhorando.

Eu não estou repetindo constantemente o código sobre o que para um iniciante pode parecer detalhes menores, o que pode ser bastante frustrante, mas também estou preocupado que ser muito "suave" possa impedir o cara de aprender a fazer algumas coisas.

Essas 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 recebimento ou fluxo de trabalho de revisão de código e pareça que sim, eu recomendaria observar 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 pequenos problemas estilísticos ou com necessidade de refatoração não crítica, deixe um comentário, mas também fique à vontade para aprovar. Dizer algo como "No futuro, talvez tente evitar nomes de métodos como esse em favor de algo como descritivoMethodName" documenta sua opinião sem forçá-los a alterá-lo ou impedir o desenvolvimento deles.

Agora, eles sabem sua preferência e, se estão tentando melhorar, esperariam perceber essa situação no futuro. Isso também deixa a porta aberta para eles realmente mudá-la naquele momento, caso concordem com você e a vejam como crítica o suficiente.

Estou lidando com um desenvolvedor júnior que trabalha remotamente em uma fábrica de códigos.

Infelizmente, essa não é uma situação ideal: um programador avançado encarregado de um programador iniciante, com separação geográfica. Não é de surpreender que haja alguma tensão, mas a disparidade pode ser atenuada.

Estou curioso, o que você quer dizer com "fábrica de códigos"? Essa terminologia, para mim, indica uma atitude preocupante que pode estar exacerbando alguns dos problemas de gerenciamento que você mencionou.

… Violação de SRP, objetos de Deus, nomes não significativos para métodos ou variáveis; Aponto o que ele precisa consertar e tento explicar por que está errado.

O problema, eu acho, é que seu desenvolvedor júnior está vomitando código sem ter passado por um processo de design adequado. Isso é uma falha de sua parte, como gerente e desenvolvedor sênior, em fornecer orientação e ensinar bons hábitos de desenvolvimento de software. Você pode impedir que códigos incorretos sejam gravados em primeiro lugar, se trabalhar primeiro para esboçar um esboço. Isso seria preferível a criticar e reescrever o código depois que ele foi 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 uma colaboração mais estreita, para que você possa fornecer orientações em todas as etapas do desenvolvimento. Fale sobre o design e a interface antes do início da codificação. Enquanto a codificação estiver acontecendo, faça pontos de verificação mais frequentes, para detectar problemas mais cedo. Se possível, tente programar em pares, através do 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 a ele onde está para que ele saiba. Se você precisar continuar mostrando o mesmo erro, poderá ter um problema com alguém que não pode cumprir as regras ou se recusa. Não use seu tempo livre para corrigir os erros. Essa pessoa deve corrigir seus próprios erros para não cometer novamente.

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

Outra idéia para lidar com "muitas críticas" é executar uma tarefa sozinha de tempos em tempos e permitir que um 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 existem várias boas soluções ou nomes de variáveis, aceito sugestões de abordagens diferentes, mas (quase?) igualmente boas. Quando eu corrigo meu código por causa do comentário de alguém, mostro às pessoas que elas são respeitadas e as críticas sempre dizem respeito apenas ao código - independentemente de quem seja o autor.