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

95

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.

Zalomon
fonte
7
Quanto tempo você passou para garantir que ele saiba quais são suas expectativas?
Blrfl
13
@gnat Acho que não é o mesmo caso, meu problema não é que estamos excedendo as estimativas ou exagerando o código. De fato, estamos adiantados. Minha pergunta é como equilibrar a linha entre ensinar o cara e não deixá-lo com críticas constantes; para um júnior, pode ser frustrante se você disser a ele para refazer coisas que aos seus olhos estão funcionando.
Zalomon 6/06/19
4
Eu editei isso para torná-lo mais sobre o tópico. Acredito que isso também seja diferente da pergunta duplicada vinculada.
Enderland 6/06
3
Algumas coisas que eu tentei que ajudam com isso: programação em pares - obtenha informações sobre como ele trabalha e pensa e talvez o exponha a seus processos de pensamento à medida que você avança no seu código. Encontre as tarefas nas quais ele é bom - às vezes, você obtém melhores resultados lançando vários bugs pequenos contra o trabalho de grandes recursos. Projetos técnicos - dê a ele a primeira chance de criar software sem tocar no código. Isso permite que ele pense sobre estrutura e processo versus abaixar a cabeça e produzir código. Por fim, boa sorte. Às vezes é preciso mais persistência do que o esperado, mas vale a pena se ele se tornar produtivo.
Sandy Chapman

Respostas:

84

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.

enderland
fonte
65
@ 9000 é incrível como muitas vezes as pessoas estão frustrados sobre as pessoas que não contribuem de acordo com suas normas, quando essas normas não são sequer documentado em qualquer lugar ...
enderland
32
Nomes de variáveis ​​são totalmente importantes na descrição da intenção do código; nomes de método / função, ainda mais. Conseguir os nomes certos não é perfeccionismo inútil, é necessário para a manutenção.
9000
9
@Zalomon Definitivamente mencione isso para ele; mais, transforme-o em uma discussão. Como desenvolvedor júnior, trabalhei com alguns desenvolvedores seniores diferentes. Minha melhor experiência foi com um desenvolvedor que me falou sobre todas as suas recomendações - mesmo as "pequenas" como um nome um pouco melhor para uma variável. Não apenas aprendi muito com ele, mas me senti tão bem que ele estava ouvindo meus processos de pensamento e me incluindo na discussão - me fez querer que ele revisasse mais meu código para que eu pudesse aprender mais. (continuação)
dj18 06/06/19
6
@Zalomon (continuação) Por outro lado, um desenvolvedor sênior que fez alterações nas minhas costas (mesmo que você diga depois, ainda está nas costas) foi totalmente desmoralizante - me fez sentir como se estivesse trabalhando com um autocrata que eu teve que descobrir como agradar.
dj18
6
Minha (pequena) experiência em orientar desenvolvedores juniores mostra que vale a pena fazer com que um desenvolvedor pense muito sobre o nome apropriado e expresse o propósito dos dados no nome da variável. Isso ajuda o desenvolvedor a entender o que o código está fazendo, de uma maneira muito menos manual do que está acostumado. Às vezes, leva-os a encontrar erros lógicos no código envolvido ou apenas maneiras melhores de expressar as coisas. (A mesma coisa funciona para mim; a diferença é que eu tenho a disciplina internalizado, graças aos revisores rigoroso código que eu tinha no passado.)
9000
19

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.

Legato
fonte
2
No que diz respeito à verborragia: quando você precisa usar um pronome pessoal, simplesmente escolher "nós" em vez de "você" também despersonaliza a crítica, na minha experiência nos dois lados da revisão de código.
Josh Caswell
6

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.

Machado
fonte
5

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.

JimmyJames
fonte
Uma das maneiras de evitar ciclos intermináveis ​​de revisões de código é fazer pequenas alterações. Nenhuma solicitação de recebimento é ridiculamente pequena se fizer uma alteração benéfica (fiz minha parte dos PRs de 1 caractere). Quanto menor, melhor. Sem dó, reduza o escopo dos ingressos entregues aos desenvolvedores juniores e mantenha-os fazendo as coisas. Uma vez que eles são bons em todo o processo de leitura-compreensão-código-teste-revisão-implantação, o escopo pode aumentar.
9000
1
Não acho que seja uma boa ideia dizer ao desenvolvedor "eles não são muito importantes" se forem importantes o suficiente para o OP voltar e mudar mais tarde.
Enderland 6/06
3
@enderland Na minha experiência, não existe código perfeito. Você sempre pode aprimorá-lo mais tarde, para que isso não seja realmente relevante aqui. O OP diz que estas são coisas para "consertar se eu tiver algum tempo livre". Existem dois tipos de problemas. Coisas que precisam ser consertadas e coisas que não precisam ser consertadas. Este último pode ou não ser corrigido e parece que eles se enquadram nessa categoria. É uma decisão de julgamento em algum nível, mas acho que, como um desenvolvedor experiente, você não tem certeza de que vale a pena chamar como uma mudança obrigatória, provavelmente não é.
JimmyJames
5

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".

gnasher729
fonte
3
Ou "(b) e eu sei que você pode fazer melhor.". Se ele pede "me ensine", você sabe que ele está no caminho certo. :)
Machado
1
Na minha posição anterior, usamos o Stash / BitBucket como nossa ferramenta de revisão de código. Ele tinha a opção de bloquear uma solicitação de recebimento definindo uma tarefa pendente ou recusando completamente a solicitação de recebimento. Eu os usaria apenas para as alterações necessárias. Se houve uma alteração cosmética (por exemplo, menor legibilidade do código, melhor estrutura de dados, refatoração), eu indicaria isso com sugestões, mas não adicionaria uma tarefa de bloqueio, se você tiver tempo. Isso também evita a falta de prazos em relação a pequenos problemas.
Hand-E-Food,
4

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.

John Wu
fonte
3
Gosto da ideia da revisão por pares, no momento somos apenas dois de nós, mas posso fazer com que ele revise meu código. Se ele consegue entender o que eu faço e encontrar algumas incoerências, isso pode ser um obstáculo, tanto pela qualidade do código quanto pelo moral dele. Ele me ajudou quando eu estava aprendendo seing que eu não era a única a fazer erros +1
Zalomon
2

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.

JacquesB
fonte
2

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.

perto
fonte
1

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.

Kevin Krumwiede
fonte
De fato, ele me disse que estava se sentindo burro. Estou tentando manter as críticas do lado positivo e disse a ele que estava feliz com o trabalho dele. Também expliquei que tinha esse tipo de dúvida quando estava iniciando, mas devo assumir que parte do feedback sobre dar a ele para melhorar o trabalho dele, está saindo errado.
Zalomon 6/06/19
2
Explique que você não perderia tempo criticando o código dele com cuidado, se não esperava que ele se tornasse um programador melhor. E seja cuidadoso ao distinguir entre "você precisa corrigir isso para que o código seja aceitável" e "aqui está algo que você pode fazer ainda melhor na próxima vez". Fornecer grandes quantidades de críticas perspicazes e precisas é o maior presente que você pode dar a um programador júnior. Não fazer isso os torna um programador pior. As críticas devem começar a diminuir. Você só precisa cometer todos os erros uma vez, talvez duas vezes, e existem tantos erros.
David Schwartz
1

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.

zak
fonte
0

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.

200_success
fonte
-1

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.

acítio
fonte
-1

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.
BartoszKP
fonte
Ficaria feliz em saber o que há de errado com minha postagem. Um voto negativo é um sinal compreensível de desacordo, mas excluir votos ?!
precisa saber é o seguinte