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

Sou o líder de uma equipe pequena, onde todos têm menos de um ano de experiência em desenvolvimento de software. Eu não me chamaria de guru de software, mas aprendi algumas coisas nos últimos anos em que escrevo software.

Quando fazemos revisões de código, eu ensino bastante e corrigo erros. Vou dizer coisas como "Isso é muito complexo e complicado, e aqui está o porquê" ou "O que você acha de mudar esse método para uma classe separada?" Sou extremamente cuidadoso ao comunicar que, se eles tiverem perguntas ou opiniões divergentes, tudo bem e precisamos discutir. Toda vez que eu corrijo alguém, pergunto "O que você acha?" ou algo semelhante.

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

Preciso de uma equipe que possa aprender a fazer as coisas corretamente de forma autônoma, e não apenas seguir as instruções. Como alguém corrige um desenvolvedor júnior, mas ainda o encoraja a pensar por si mesmo?

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

Eu: gosto da sua ideia de criar um método de extensão, mas não gosto de como você passou um lambda complexo e grande como parâmetro. O lambda força outros a saberem muito sobre a implementação do método.

Junior (depois de me entender mal): Sim, eu concordo totalmente. Não devemos usar métodos de extensão aqui, porque eles forçam outros desenvolvedores a saberem muito sobre a implementação.

Houve um mal-entendido, e isso foi tratado. Mas não havia nem uma onça de lógica em sua declaração! Ele pensou que estava regurgitando minha lógica de volta para mim, pensando que faria sentido quando realmente ele não tinha idéia do por que estava dizendo isso.

Resposta curta:

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

É a pergunta que nos move! Matrix.

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

Não há nada 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 histórias que sempre uso é: "Me dê três soluções (para esse problema)!"

Quando pensam nessas soluções, começam a perceber muitos problemas. Isso leva algum investimento de tempo - mas, com o tempo, eles tendem a visualizar as limitações e deficiências de seu pensamento. Eles começam a ver isso mais como "eu não pensei nisso!" o que é muito melhor do que ir para casa com a sensação de que "eu estava errado!" ou pior ainda: "Foi-me dito / provado errado, mesmo quando tinha pontos de vista válidos" .

Em geral, crianças muito jovens tendem a ser mais hábeis em relação a questões técnicas (como qual padrão de design funciona melhor!) Em relação a questões de processo , mas com o tempo quando você as treina, elas funcionam.

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

Isso geralmente é um resultado que você fazer tomar suas sugestões, mas mais tarde overrule-los e eles são igualmente convencido sobre seus pontos de vista; só porque você é mais velho, eles estão evitando uma briga!

A melhor coisa que aprendi com um dos meus chefes anteriores: ele pedirá aos membros da equipe que debatem primeiro (eles se sentem bastante iguais aqui) e, esperançosamente, depois de esgotados todos os argumentos, ele entraria na sala com apenas uma pergunta - "O que 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 levados à ação na próxima vez que sentirem que não vale a pena participar da discussão.

Não apenas em software, mas em todos os lugares, em última análise, apenas os colegas de equipe mais poderosos ousam responder e muito menos questionar o sistema.

Se você quer que seus alunos 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, faça perguntas pertinentes. No seu exemplo, você pode perguntar a eles 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 é um problema. Dessa forma, você sabe que eles entenderam por que a solução deles poderia ser um problema e, além disso, são mais propensos a aprender com ela - se você simplesmente disser a eles que a solução está errada, isso é um julgamento externo e facilmente ignorado. Se chegarem à conclusão por conta própria (com um pouco de estímulo), perceberão o quão bem fundamentado é e terão muito mais chances de aprender com o erro.

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

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

Abra perguntando ao grupo "De que outra forma o problema poderia 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 semelhante ao que sua ideia é.

Em seguida, 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 construtor de confiança para os desenvolvedores juniores, você pode começar com alguns casos em que eles escolheram a que você acha que era a melhor opção e tornar a sua alternativa um palhaço que possui uma falha semi-óbvia e direcionar a discussão para o melhor resultado da implementação original.

Quando comecei a trabalhar em um trabalho de programação, fiz exatamente a mesma coisa que você descreveu: quando me disseram sobre algo que eu poderia estar fazendo, 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 idéias foi aprender com a experiência e 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 descobrirem é através da experiência.

Uma boa maneira de facilitar o pensamento individual é fazer com que eles pesquisem sites de programação como o Stack Overflow ou o Programmers SE. Sei que isso me ajudou a aprender sobre as diferentes técnicas existentes e me permitiu discutir com os membros seniores da equipe, em vez de concordar cegamente com eles.

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

A interação da sua postagem demonstra um princípio fundamental para ensinar quase tudo: peça que expliquem o que acham que você disse e ouça com atenção a resposta: ela informará exatamente o que precisa ser corrigido.

Eu descaradamente roubei esse truque do meu professor de matemática, há 25 anos, e ele não me falhou desde então. Usei-o nas aulas durante minha breve passagem como assistente de ensino, no trabalho quando falava sobre design de software e com meus oito anos de idade quando falava sobre as tarefas da escola.

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

Gosto da sua ideia de criar um método de extensão, mas não gosto de como você passou um lambda complexo e grande como parâmetro. Você vê como esse lambda complexo força outras pessoas a saberem certas coisas demais sobre a implementação do método?

É impossível responder corretamente a essa pergunta 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á um feedback de que preciso fazer as correções.

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

Você também precisa liderar pelo exemplo. Não quero escrever código super-impressionante, quero pedir a opinião deles sobre seus próprios designs. Não espere por revisões de código após o fato, mas trabalhe junto o tempo todo. 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 enviesá-los primeiro para suas próprias idéias.

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

Você sabe, é uma solução realmente criativa na qual eu nunca teria pensado. Como é dimensionado? / Você acha que pode haver uma abordagem conceitualmente mais simples para tornar o desenvolvimento mais rápido ou a manutenção mais fácil? / Infelizmente, eu não acho que ele realmente se encaixa no resto da arquitetura do projeto. a configuração parece?

Isso geralmente é suficiente para apontar as pessoas para uma nova direção.

Responsabilidade é uma coisa que pode ajudá-los.

Liderei uma equipe ou duas no passado e uma das coisas que fez os juniores brilharem foi o ônus da responsabilidade pessoal. Quando alguém percebe que suas ações podem implicar nele em determinado momento, ele / ela geralmente se compromete um pouquinho mais de si mesmo no que faz. Sem mencionar que, quando sentem o seu trabalho, os bons resultados são muito mais satisfatórios.

Eu não me preocuparia muito com o fato de eles te seguirem cegamente, é isso que eles deveriam estar fazendo como juniores. O problema é que eles provavelmente não entenderão os verdadeiros motivos dos itens que você aborda nas revisões de código até que eles saiam e trabalhem em outro lugar que possua desenvolvedores de software terríveis, gerenciamento terrível e código terrível.

A essa altura, eles terão aprendido boas práticas por hábito e terão que passar pelos erros de codificação e design que outros cometem e são forçados a cometer que agora precisam trabalhar em software mal projetado e implementado.

Isso será uma inevitabilidade eventual em algum momento de suas carreiras. Você está prestando um ótimo serviço a eles, 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.

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

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

Isso permite que eles vejam as falhas no que estão desenvolvendo e, ao mesmo tempo, oferece a oportunidade de resolver o problema que eles introduziram no aplicativo.