Como corrigir um júnior, mas encorajá-lo a pensar por si mesmo? [fechadas]

54

Eu sou o líder de uma pequena equipe onde todos têm menos de um ano de experiência em desenvolvimento de software. Eu não diria que sou um guru de software, mas aprendi algumas coisas nos poucos anos em que tenho escrito software.

Quando fazemos revisões de código, eu ensino e corrijo erros. Eu vou dizer coisas como "Isso é excessivamente complexo e complicado, e aqui está o porquê", ou "O que você acha de mudar esse método para uma classe separada?" Tenho muito cuidado em comunicar que, se tiverem dúvidas ou opiniões divergentes, tudo bem e precisamos discutir. Toda vez que eu corrijo alguém, eu pergunto "O que você acha?" ou algo similar.

No entanto, eles raramente discordam ou perguntam por quê. E ultimamente tenho notado sinais mais flagrantes de que eles estão cegamente concordando com minhas declarações e não formando opiniões próprias.

Eu preciso de uma equipe que aprenda a fazer as coisas de maneira autônoma, não apenas siga as instruções. Como alguém corrige um desenvolvedor júnior, mas ainda o encoraja a pensar por si mesmo?

Editar: Veja um exemplo de um desses sinais óbvios de que eles não estão formando suas próprias opiniões:

Me: I like your idea of creating an extension method, but I don't like how you passed a large complex lambda as a parameter. The lambda forces others to know too much about the method's implementation.

Junior (after misunderstanding me): Yes, I totally agree. We should not use extension methods here because they force other developers to know too much about the implementation.

Houve um desentendimento, e isso foi resolvido. Mas não havia nem mesmo uma OUNCE de lógica em sua declaração! Ele pensou que estava regurgitando minha lógica de volta para mim, pensando que faria sentido quando na verdade ele não tinha ideia do por que ele estava dizendo isso.

    
por Phil 25.01.2012 / 16:09
fonte

10 respostas

37

Resposta curta:

Envolva-os (coloque o quebra-cabeça em sua mente), capacite-os (confie nas respostas deles).

It is the question that drives us! - Matrix.

Em geral, em minhas observações, os juniores têm seu próprio mundo - sua visão limitada de como pensam e, em parte, seu próprio entusiasmo / favoritos / opiniões sobre as coisas.

Não há nada de errado em dizer a eles que você está errado - mas o melhor é que você os faça pensar. Por quê? Existem outras maneiras? Existem maneiras melhores de fazer a mesma coisa? Uma das anedotas que eu sempre uso é - "Me dê três soluções (para esse problema)!"

No momento em que pensam sobre essas soluções, elas começam a perceber muitos problemas. Leva algum investimento de tempo - mas com o tempo eles tendem a visualizar as limitações e falhas de seu pensamento. Eles começam a ver isso mais como "Eu não pensei nisso!" que é muito melhor do que ir para casa com a sensação de que "eu estava errado!" ou até mesmo pior "Foi-me dito / provado estar errado mesmo quando eu tinha pontos de vista válidos" .

Em geral, crianças muito jovens tenderão a ser mais adeptas de questões técnicas (como qual padrão de design funciona melhor!) em relação a processos , mas com o tempo quando você os treina, funciona.

However they rarely if ever disagree or ask why. And lately I've been noticing more blatant signs that they are blindly agreeing with my statements and not forming opinions of their own.

Geralmente, esse é um resultado que você faz recebe suas sugestões, mas depois anula-as e elas não se convencem de seus pontos de vista; só porque você é mais velho eles estão evitando uma briga!

A melhor coisa que aprendi com um dos meus antigos chefes: ele pedirá aos membros da equipe para debater primeiro (eles se sentem bastante iguais aqui), e esperançosamente depois de todos os argumentos serem esgotados, ele entraria na sala com apenas uma pergunta - "Quais foram os pontos de desacordo?" - O ponto é que as pessoas sempre gostam de participar de debates e discussões, mas se seus pontos (válidos) não forem aceitos na próxima vez, eles sentem que não vale a pena participar da discussão.

Não apenas no software, mas em todos os lugares em última análise, somente os membros da equipe mais capacitados ousarão responder, quanto mais questionar o sistema.

    
por 25.01.2012 / 16:32
fonte
26

Se você quer que seus juniores pensem por si mesmos, não os corrija: faça com que eles se corrijam .

Em vez de dizer a eles o que você acha que está errado sobre a solução deles, faça perguntas pertinentes sobre isso. No seu exemplo, você poderia perguntar-lhes sobre o que alguém usando o método de extensão precisaria saber para criar o lambda. Continue fazendo perguntas como essa até que elas sugiram que isso é um problema. Dessa forma, você sabe que eles entenderam por que a solução deles poderia ser um problema e, além disso, têm mais probabilidade de aprender com isso - se você simplesmente disser a eles que a solução deles está errada, é um julgamento externo e facilmente ignorado. Se eles chegarem à conclusão por si mesmos (com um pequeno estímulo), perceberão quão bem fundamentado está e muito mais propensos a aprender com o erro.

Além disso, isso dá aos seus juniores a chance de defender seu design - talvez eles tenham pensado no problema e tenham uma boa justificativa que resolvam sua preocupação, ou seja, não há necessidade de você fazer qualquer corrigindo. Isso reduz qualquer percepção (embora não intencional) de que você está governando por decreto executivo.

    
por 25.01.2012 / 17:22
fonte
7

Como você tem vários desenvolvedores juniores, faça revisões de código como grupo e não um 1.

Abra perguntando ao grupo "Como mais poderia o problema ser resolvido?", e permita que os outros desenvolvedores juniores sugiram suas implementações primeiro. Adicione sua implementação somente depois que os outros membros da equipe tiverem falado e se nenhum deles sugeriu algo parecido com a sua ideia.

Depois, faça uma discussão em mesa redonda sobre as vantagens e desvantagens relativas de diferentes implementações com a intenção de orientar os desenvolvedores juniores a escolher a melhor implementação sem saber o que é.

Como um criador de confiança para os desenvolvedores juniores, você pode começar com alguns casos em que eles escolheram o que você acha ser a melhor opção e fazer de sua alternativa um palhaço com uma falha semi-óbvia e direcionar a discussão para o motivo da implementação original. melhor.

    
por 25.01.2012 / 18:12
fonte
5

Quando comecei a trabalhar em um trabalho de programação, fiz exatamente a mesma coisa que você descreveu: quando falado sobre algo que eu poderia estar fazendo, eu sempre concordaria. Foi principalmente porque eu não tinha experiência suficiente para dizer o contrário.

O que me deu a capacidade de realmente discutir metodologias e ideias foi aprender com a experiência, bem como ler sobre diferentes abordagens e novas tecnologias. Para que sua equipe pense por si mesma, eles precisam realmente saber quais problemas podem surgir de coisas como código "excessivamente complexo e complicado", e a única maneira real de descobrir isso é por meio da experiência.

Uma boa maneira de facilitar o pensamento individual é fazer com que eles visualizem sites de programação como o Stack Overflow ou o Programmers SE. Eu sei que isso me ajudou a aprender sobre as diferentes técnicas que estavam lá e me permitiu ter discussões com membros seniores da equipe, em vez de concordar cegamente com eles.

O ponto é que sem experiência, sugestões de membros seniores sempre soarão certas para eles.

    
por 25.01.2012 / 16:35
fonte
5

A interação do seu post demonstra um princípio fundamental para ensinar quase tudo: peça que eles expliquem o que eles acham que você disse , e ouça atentamente a resposta: ele dirá exatamente o que precisa ser corrigido.

Eu tenho descaradamente roubado copiado este truque do meu professor de matemática há 25 anos, e não me falhou desde então. Eu usei isso em sala de aula durante meu breve período como assistente de ensino, no trabalho quando falo sobre design de software, e com meus oito anos de idade quando falamos sobre suas atribuições escolares.

É claro que você nem sempre pode ser franco sobre pedir que eles repitam o que você acabou de dizer, então você precisa ajustar sua estratégia. Por exemplo, aqui está como eu re-frase sua declaração de acompanhamento do OP como uma pergunta "sondagem":

I like your idea of creating an extension method, but I don't like how you passed a large complex lambda as a parameter. Do you see how this complex lambda forces others to know too much certain things about the method's implementation?

Essa pergunta é impossível de responder corretamente sem entender o problema que você está tentando destacar. Descobri que terminar minhas explicações com uma pergunta que requer análise do que acabei de dizer acelera o processo de aprendizado e me dá feedback de que preciso fazer correções.

    
por 25.01.2012 / 17:11
fonte
5

Normalmente, quando as pessoas não estão dizendo o que você quer, isso significa que você precisa trabalhar em sua escuta. Ouvir significa ouvir as razões de seu design antes de julgar. Significa não apenas dizer que não há problema em discordar, mas provar considerando honestamente o que eles têm a dizer, e não apenas corrigindo-os. Procure as coisas boas sobre sua solução e modifique sua solução para incorporar essas coisas.

Você também precisa liderar pelo exemplo. Não quero dizer, escrevendo código super-incrível, quero dizer, pedindo-lhes a sua opinião sobre seus próprios projetos. Não espere por revisões de código após o fato, mas trabalhe junto ao longo do caminho. Diga coisas como: "Minha interface parece muito complexa, mas não tenho certeza da melhor maneira de simplificá-la." E dê a eles tempo para responder sem influenciá-los em suas próprias ideias primeiro.

    
por 25.01.2012 / 19:56
fonte
4

Quando eu tive que lidar com isso, eu disse (honestamente) coisas como:

You know, that's a really creative solution which I would never have thought of. How does it scale?/Do you think there might be an approach which is conceptually simpler, to make development faster or maintenance easier?/Unfortunately, I don't think it really fits in with the rest of the project's architecture./What will the configuration look like?

Isso geralmente tem sido suficiente para direcionar as pessoas para uma nova direção.

    
por 25.01.2012 / 16:31
fonte
2

Responsabilidade é uma coisa que pode ajudá-los.

Liderei uma equipe ou duas no passado e uma das coisas que fizeram os juniores brilharem foi o peso da responsabilidade pessoal. Quando se percebe que suas ações podem implicar com ele em um ponto, ele / ela geralmente se compromete um pouquinho mais de si mesmo no que faz. Não mencionar que, quando sentem o seu trabalho, os bons resultados são muito mais satisfatórios.

    
por 25.01.2012 / 17:00
fonte
1

Eu não me preocuparia muito com o fato de que eles te seguem cegamente, é isso que eles deveriam estar fazendo como juniores. O problema é que eles provavelmente não entenderão as verdadeiras razões para os itens que você aborda nas revisões de código até que eles tenham ido embora e trabalhem em outro lugar que tenha péssimos desenvolvedores de software, péssimo gerenciamento e códigos terríveis.

Nesse momento, eles terão aprendido boas práticas por hábito e terão que passar pelos erros de codificação e design que os outros cometem e são FORÇADOS a fazer com que agora tenham que trabalhar com software mal projetado e implementado.

Esta será uma eventual inevitabilidade em algum momento de suas carreiras. Você está fazendo um ótimo serviço, acostumando-os a bons padrões e práticas de codificação. Infelizmente, a maioria de nós teve que aprender da maneira mais difícil.

    
por 25.01.2012 / 16:35
fonte
1

Com base no exemplo dado, eu diria que acompanhar seus comentários com perguntas provavelmente seria o melhor caminho a seguir. Se você fizer uma pergunta junto com seus comentários, não os deixará simplesmente concordar ou discordar, pelo menos, têm que pensar em como podem implementar alguma coisa.

por exemplo. "Eu gosto da sua idéia de criar um método de extensão, mas eu não gosto de como você passou um grande lambda complexo como parâmetro. O lambda força os outros a saberem muito sobre a implementação do método. Você pode pensar em uma maneira melhor de implementar este método de extensão que não expõe tanta informação? "

Isso permite que eles vejam as falhas no desenvolvimento e, ao mesmo tempo, tenham a oportunidade de resolver o problema que introduziram no aplicativo.

    
por 25.01.2012 / 16:44
fonte