Quando você não dá ajuda a programadores menos experientes? [fechadas]

Em um dos meus trabalhos, eu estava aprendendo e ensinando (porque eu obviamente não sei tudo, mas eu sei mais do que alguns)

Não use a todo custo coloque as mãos no teclado. Isso é frustrante para você e para a pessoa que você está ensinando. Mesmo que você dê instruções passo a passo, quando você põe as mãos no teclado, é o equivalente a dar-lhes um trecho de código e dizer "isso conserta".

No que aprendi:

• Não digite o código para eles
• Tente ensinar no nível deles (se eles entenderem a sintaxe, não explique isso a eles. Isso só vai aborrecê-los; em vez disso, ensine as classes / funções usadas)
• Não os ignore ou diga "descubra por conta própria". O que você vai acabar é que eles vêm para você mais tarde, exceto agora as 3 linhas de código que eles tiveram problemas, agora são 50 linhas espalhadas em 8 arquivos tentando resolver o problema.
• Ensine-os a aprender por conta própria. Uma das melhores maneiras é dizer-lhes para usar o stackoverflow. Eu às vezes, mesmo sabendo a resposta, se eles me perguntassem. Eu diria "bem, vou fazer essa pergunta no stackoverflow". e eu daria a eles um link para a pergunta. Faça uma pausa para o café e veja um código diferente. Quando eles voltaram perguntando "então como eu corrijo esse problema?", Apenas diga a eles para procurarem a pergunta no SO (usando o URL que você deu a eles). Descobri que as massas geralmente são melhores professoras do que eu.
• Quando copiam e colam código da Internet e perguntam por que isso não funciona, peça-lhes que expliquem o que cada linha faz. Se não puderem, diga a eles para pesquisar as funções / classes usadas. Se necessário, forneça explicações para a classe e funções
• Realize revisões de código para verificar se eles estão resolvendo o problema, não apenas trabalhando em torno dele para que ele seja exibido mais tarde.
• Seja legal. Quando alguém está apenas começando em sua base de código sem documentação, não diga apenas para ler o código-fonte. Forneça uma visão resumida de alto nível da função em questão. Ou, melhor ainda, comece a escrever a documentação:)
• Seja humilde. Não BS sobre o problema. Se você não sabe, diga que não e ajude-os a procurar. Muitas vezes, basta conhecer o domínio o suficiente para saber quais palavras-chave procurar por uma ajuda suficiente para que você as forneça.

Método socrático, ou seja, faça-lhes perguntas que os levem a pensar em uma direção positiva

[isso é útil mesmo quando você não sabe qual é o problema, muito menos a solução]

Eu aprendi a ajudá-los a arquitetar e parar por aí. Escolha as ferramentas certas, elabore um projeto geral para um ou dois problemas complexos e deixe-os ir em frente. Se eles voltarem e pedirem conselhos, dê-os em pequenos pedaços. Se não, deixe que eles sejam.

Você está totalmente certo sobre o "queimado e frustrado". Eles serão exatamente isso se você gerenciar micro ou nit-pick. Finalmente, ajuda muito estabelecer uma relação de trabalho amigável com seus colegas de trabalho. O tempo gasto ganhando confiança e respeito mútuo vai se pagar 10x mais.

Eu os ajudo quando realmente preciso que as coisas terminem rapidamente, quando fica claro que eles atingiram uma parede de tijolos, e quando é claramente irracional esperar que eles descubram sem ajuda. Se, no entanto, eles não tiverem tempo para algo, então é melhor que eles tentem primeiro.

No que diz respeito a "pescar" em vez de "ensinar a pescar", a melhor maneira de fazer isso é não resolver os problemas das pessoas para eles . Dê-lhes ideias e deixe-as correr com ele. Se eles correm com isso e falham, ajude-os mais. Se eles tiverem sucesso, melhor ainda.

Se eles são um bom programador, devem encontrar uma maneira de fazê-lo. Agora, em uma situação onde é quase impossível encontrar informações ou uma solução para um determinado problema, dar uma ajuda está aparentemente dentro da razão, contanto que você a mantenha dentro da razão. Não colher alimentá-los a resposta.

Talvez, por exemplo, eu tenho 18 anos e tenho aprendido por anos e tenho escrito algumas coisas loucas, incluindo o meu próprio compilador e eu sou autodidata. Eu só procuro ajuda com coisas nas quais realmente estou presa (como em pesquisas e experimentos há pelo menos um dia, mas sem sucesso). Eu também gostaria de fornecer um contra-exemplo: em uma aula de programação, uma vez um aluno me pediu para depurar o código que ele nem tinha compilado!

Essencialmente, um bom programador, mesmo um júnior, deve ser capaz de experimentar e pesquisar soluções para a maioria dos problemas.

Eu irei mentor, mas eu vou embora se eles quiserem que eu faça o trabalho deles por eles. Tipicamente, apenas alguns conselhos sobre como resolver um problema, ou reescrevendo a descrição da tarefa, podem percorrer um longo caminho. Mesmo apenas dizendo-lhes as palavras que deveriam estar usando no google pode ser ajuda suficiente. 2 minutos no máximo.

Recentemente, comecei a usar a técnica pomodoro . Como resultado, se eu não puder responder a uma pergunta sem interromper minha linha de pensamento na minha tarefa atual, comecei a perguntar se posso adiar uma resposta até o final do pomodoro, uma média de cerca de 15 minutos de atraso. Um efeito colateral interessante disso eu descobri é quando eu passo em sua mesa para responder a pergunta, eles já muitas vezes já resolveu por conta própria. Se não, nesse momento estou muito mais preparado para dar-lhes toda a atenção.

Isto não é escola. Não é trapaça se você rapidamente fornecer um fato que eles poderiam eventualmente encontrar por conta própria. Pelo contrário, faz sentido para os negócios economizar tempo e, na minha experiência, as habilidades são muito pouco aguçadas por tentativa e erro, em comparação com um mentor, dando-lhe frequentes pequenos empurrões na direção certa. Eu prefiro que eles aprendam 10 maneiras certas de fazer as coisas com a minha ajuda do que 9 maneiras erradas e uma certa por conta própria.

Se algo puder ser facilmente consultado, ensine-os a fazê-lo. Por outro lado, se é algo que você só pode saber por experiência, como quais arquivos investigar para certos sintomas de bugs, não vejo absolutamente nada de errado em apenas dar uma resposta inexplicável.

Por outro lado, coisas mais subjetivas, como a orientação de arquitetura, devem sempre ser acompanhadas pelo raciocínio por trás dela. Por um lado, o desenvolvedor júnior tem pensado muito mais profundamente sobre sua tarefa específica do que você. Falar sobre isso garante que você não está tirando conclusões precipitadas. Por outro lado, impede que eles apliquem cegamente regras a situações futuras em que podem não se aplicar.

Eu só consigo pensar em um caso em que eu me recusei a continuar ajudando um colega de trabalho, e foi depois de passar algumas horas explicando algo várias vezes e passando por vários exemplos, após os quais ela literalmente ainda não sabia o próximo depoimento. para digitar com algumas dicas muito importantes. Naquele momento, ela tinha pouca esperança de manter seu emprego sem um reaprendizado sério dos fundamentos, e com certeza ela durou apenas alguns meses.

Eu paro de ajudá-los quando eles voltam com a mesma pergunta pela terceira vez.

Eu digo a eles que ficaria feliz em ajudá-los, mas apenas se eles se ajudarem primeiro. De lá, ou eles vão buscar outro lago para pescar comida de graça, caso em que eles geralmente são demitidos pouco tempo depois. Ou eles trabalham e ganham o jackpot quando voltam para mais ... isso é mais coisa para aprender do que mais do mesmo!

Eu acho que o contexto é importante.

Se estamos lidando com um problema crítico de suporte à produção, em que o tempo de resposta é importante, então eu realmente forneço muita ajuda e muitas explicações para que eles possam aprender o assunto.

Se o prazo for menos sensível, a complexidade se tornará o driver. Você pode, é claro, ajudar muito os iniciantes apenas atribuindo tarefas apropriadas no nível de habilidade, mas se é algo que pode ser resolvido através de pesquisa, então eu concordo com os outros cartazes que os guiam sem dar a resposta exata é uma ótima abordagem. .

Se eles fazem perguntas que são facilmente respondidas olhando para outro lugar, então eu os direciono a fazer seu próprio trabalho. Nesse sentido, se houver um processo ou uma solução que seja bastante rotineira e que haja pouco valor em torná-los escravos para isso, então fique envergonhado se você não tiver um wiki à mão para eles verificarem.

Quando se trata de transferir conhecimento de domínio que é personalizado para o negócio, então eu não medito palavras. Faça a leitura em linha reta o mais breve possível. Novatos precisam disso para ajudar com tudo o que vem depois. Não há tal coisa como ser educado sobre o negócio muito rapidamente ou muito facilmente. Eu tive um chefe uma vez que jogou todos os tipos de truques por uma hora tentando me levar a uma resposta. Eu era novo, não sabia nada sobre o aplicativo ou o negócio ainda, e estava lidando com uma questão de suporte à produção. Eu queria gritar: "Por que você está & #; $ @! Jogando # @ & (* $%! Jogos? Os usuários que tentam obter as faturas estão aguardando uma resposta!"

Eu acho que a primeira coisa que você deve perguntar a eles antes de ajudá-los é você já investigou isso? se sim, pergunte a eles o que eles descobriram e aponte-os na direção certa. Investigar é muitas vezes subestimado, mas é uma das melhores práticas que aprendi, encontrar informações sobre o que você precisa lhe dá o poder de aprender por si mesmo, e também deixará claro que eles têm que tentar primeiro.

Se o problema for mais complexo, tente não dizer a eles o que fazer, mas compartilhe algumas ideias, pergunte a eles como eles acham que poderiam abordar o problema.

Se eles não têm idéia, tente dividi-lo em um nível muito básico, no qual você não revela todos os detalhes, mas descreve a solução o suficiente para eles tentarem, existem ferramentas muito úteis para isso, como algoritmos ou fluxogramas .

Concluindo, tente orientá-los sem interferir no processo de aprendizado, sempre ajudando-os a depender de você para cada tarefa a ser atribuído, o que levará seu tempo e será contraproducente .

Eu evito ajudar em coisas simples como a sintaxe que eles deveriam saber, ou se eles não sabem que devem ser capazes de entender por conta própria. Se é algo mais complexo, não me importo de explicar uma vez.

Quando se trata de coisas como explicar o processo, ou os padrões de codificação da nossa organização / projetos, etc., eu uso a regra das três greves. Eu realmente acho que uma pessoa é chata se precisar explicar as coisas três vezes. Na verdade, esse também é um dos critérios em nossa avaliação.

Depende muito do aluno. Espero que eles coloquem algumas coisas por conta própria. Se surgirem: "Enfrentei este problema, tentei os métodos A, B e C, mas não consegui resolver o problema", vou ajudá-los. Se eles simplesmente aparecerem com "Estou enfrentando esse problema" e não tiver feito nada, pedirei que voltem aos livros e procurem uma solução.

Como um novato programador (cerca de 9 meses no meu trabalho atual usando principalmente Perl e SQL e com a) sem conhecimento de Perl eb) alguns meses mexendo com SQL antes deste trabalho), ao fazer perguntas de programação, eu tente mostrar o que eu fiz até agora, ou no caso de algo não funcionar (e ser difícil de depurar), onde eu acho que o bug pode estar. Quando possível, procurei aprender a pescar.

Eu paro de ajudar nas seguintes circunstâncias:

• Se estou sendo usado para canalizar Google / Stack
• Se eu tiver fornecido documentação e comentários adequados, e eles estão abrindo caminho no RTFM estágio
• Se eles são sujos, sem comentários, "Eu vou hackear isso agora e voltar mais tarde "& & £ >! $

Se eu não tiver fornecido documentos adequados, ou eles estão trabalhando com uma ferramenta / classe que eu criei, então é minha responsabilidade ajudá-los