O que qualifica alguém para ser mentor?
Posso mentorar uma linguagem enquanto ainda estou aprendendo?
Posso mentorar mais de uma linguagem?
Devo tentar mentorar todas as soluções da fila?
E se uma solução estiver na fila há dias, ou até semanas?
E se eu não tiver nada a sugerir sobre uma solução?
Devo mentorar um exercício que nunca resolvi?
Devo mentorar um exercício que resolvi, mas em outra linguagem?
Sou obrigado a mentorar uma solução depois de vê-la?
E se o estudante não entender depois que eu explicar algo várias vezes?
Como respondo se o estudante ficar na defensiva com minhas sugestões?
O estudante deve ter a última palavra, mesmo que eu ache que ele está errado?
Como formular bem uma sugestão?
Devo impor formatação, comentários e convenções de nomenclatura?
O que qualifica alguém para ser mentor?
Você não precisa ser especialista em uma linguagem para mentorar essa linguagem.
Você só precisa ser um pouco menos novato do que a pessoa que está mentorando.
Se houver algo em uma solução que você acha que poderia ser feito de outra forma, você pode sugerir.
Não precisa ser necessariamente uma forma melhor, apenas uma alternativa idiomática.
Isso deixa a escolha de usar ou não a sugestão com o estudante,
mas pelo menos ele passa a ter mais opções para escolher.
Posso mentorar uma linguagem enquanto ainda estou aprendendo?
Na verdade, você nunca para de aprender uma linguagem, nem mesmo uma que já conhece.
Algumas linguagens lançam uma versão atualizada a cada poucas semanas ou meses.
Pode haver não só novos recursos da linguagem para aprender, mas também recursos que já existem e que você desconhece.
Às vezes um estudante usa um recurso, e essa será a primeira vez que você o vê.
Então mentorar pode ser uma boa forma de aprender mais sobre uma linguagem.
Posso mentorar mais de uma linguagem?
Você pode mentorar quantas linguagens se sentir à vontade.
Não há problema em mentorar várias linguagens nas quais você se sente seguro, assim como uma linguagem que ainda está aprendendo.
Devo tentar mentorar todas as soluções da fila?
Se você não conseguir pensar em algo substancial ou construtivo para dizer sobre uma solução naquele momento,
pode ser melhor para o estudante deixar a solicitação de mentoria para outro mentor,
mesmo que esse estudante precise esperar mais por uma resposta.
E se uma solução estiver na fila há dias, ou até semanas?
Se o estudante fez uma pergunta específica que você não sabe responder, talvez ainda seja melhor deixá-la
para alguém que consiga responder à pergunta dele.
Caso contrário, a solução pode ser de um exercício que foi difícil para você, que talvez você não tenha resolvido,
ou tenha resolvido mas achado que não resolveu muito bem.
Nesse caso, você pode dar uma olhada na solução para ver se há algo que possa aprender com ela.
Se houver, você pode agradecer ao estudante pelo que aprendeu especificamente com a solução dele.
Ou você pode querer que o estudante explique a solução para você.
Isso é meio que uma "mentoria reversa", mas alguns estudantes podem ficar felizes em explicar a solução
quando perguntados com educação e respeito.
Você poderia então perguntar se ele considerou outra abordagem e por que escolheu a abordagem que escolheu.
Ou você ainda pode não entender a solução como um todo, mas enxergar algumas coisas que consegue abordar.
Por exemplo, você pode sugerir considerar o uso de nomes significativos para os parâmetros da função,
caso ele tenha usado apenas n ou m.
Se você não se sentir à vontade para fazer nenhuma dessas coisas, não há problema em deixar a solicitação sem resposta.
A mentoria é voluntária.
O fato de você mentorar uma linguagem não significa que você precisa mentorar todos os exercícios dessa linguagem.
E se eu não tiver nada a sugerir sobre uma solução?
Não há problema em dizer o que você gostou em uma solução.
Na verdade, dizer o que você gostou especificamente em uma solução é uma boa forma de começar qualquer interação de mentoria.
Depois disso, se você não tiver sugestões de formas alternativas de abordar o exercício,
tudo bem apenas dizer ao estudante: "Muito bem!"
Se o estudante enviou mais de uma iteração,
você pode conseguir apontar de que formas a iteração mais recente é uma melhoria.
Devo mentorar um exercício que nunca resolvi?
Às vezes, olhar a solução de um estudante vai te inspirar a resolver o exercício você mesmo,
especialmente se a abordagem usada na solução for uma que faz o exercício parecer mais simples
do que as abordagens que você já considerou.
Depois de resolver o exercício, se a solicitação de mentoria que te inspirou não estiver mais disponível,
pelo menos você estará pronto para a próxima vez.
Devo mentorar um exercício que resolvi, mas em outra linguagem?
Como o que é idiomático em uma linguagem pode não ser idiomático em outra,
provavelmente é melhor ter resolvido o exercício na linguagem que está sendo mentorada.
Se as soluções entre duas linguagens forem muito parecidas, e você conhecer as duas bem o suficiente
para saber o que é idiomático em cada uma, não deve levar muito tempo para transpor uma solução de uma linguagem para a outra.
Se a solicitação de mentoria não estiver mais disponível depois de transpor a solução,
pelo menos você estará pronto para a próxima vez.
Sou obrigado a mentorar uma solução depois de vê-la?
Você pode olhar uma solução e perceber que não quer mentorá-la por vários motivos, incluindo:
- O estudante pode ter feito uma pergunta cuja resposta você não sabe.
- O código pode ser tão verboso e/ou confuso que você não sabe por onde começar uma crítica.
- O código pode indicar que o estudante é um iniciante absoluto que vai precisar de muita orientação básica
para a qual você não tem tempo nem paciência.
- O comentário do estudante pode ser do tipo que sinaliza que ele pode ser desagradável ou trabalhoso de lidar.
Nada te obriga a clicar no botão "Começar a mentorar" se você achar que aquela solicitação de mentoria não é para você.
E se o estudante não entender depois que eu explicar algo várias vezes?
Pode haver momentos em que um estudante pareça quase deliberadamente resistente a entender suas explicações.
Se você sentir que esgotou todas as formas que conhece de explicar algo, você pode decidir
encerrar a discussão com a sugestão de que o estudante reenvie sua solicitação de mentoria para que ela
possa ser atendida por outro mentor que talvez tenha mais sucesso em explicar o(s) ponto(s) difícil(es).
Às vezes um estudante dirá que usou uma abordagem mais trabalhosa do que o necessário como forma de aprender
mais sobre um recurso da linguagem, mesmo que esse recurso não seja o mais adequado para o exercício.
Como o Exercism é uma plataforma de aprendizado e não um site de programação competitiva, essa é uma razão justificável
para não usar a abordagem mais elegante ou eficiente.
Você pode fazer algumas sugestões sobre como ele usou a abordagem dele,
se perceber que ele poderia ter implementado a abordagem de forma mais idiomática.
De qualquer forma, você pode sugerir que ele envie outra iteração com base no feedback,
ou que encerre a discussão para liberar uma vaga de mentoria.
Um estudante pode seguir um paradigma de programação que pode não ser o mais adequado para a linguagem ou para o exercício.
Por exemplo, ele pode sempre querer usar o paradigma orientado a objetos,
e fragmentar uma solução relativamente simples e direta em uma pequena explosão de classes
com fluxo de controle labiríntico por vários métodos.
Na medida em que o estudante é um seguidor dogmático do paradigma, geralmente é inútil tentar
convencê-lo de uma abordagem diferente.
Você pode tentar, e ele pode responder à sua sugestão, mas se o estudante se fechar, pode ser melhor seguir em frente.
O estudante pode rejeitar totalmente uma sugestão.
Por exemplo, você pode sugerir usar reduce em vez de map e join,
já que reduce é apenas uma iteração em vez de uma iteração para map e outra para join.
Mas o estudante pode rejeitar isso, porque acha map e join mais legíveis.
Não há problema em concordar com o estudante que map e join podem ser mais legíveis que reduce.
Você pode sugerir que ele pode se sentir mais à vontade com reduce depois de mais tempo de prática,
e não há nada de errado em usar map e join.
Não há problema em concordar com um estudante na medida em que ele está certo,
e não há problema em tentar corrigir qualquer equívoco ou exagero que o estudante possa ter expressado.
O estudante deve ter a última palavra, mesmo que eu ache que ele está errado?
Por exemplo, você pode sugerir que um estudante não use números mágicos como 60 e 24
ao resolver o exercício Clock, mas sugira defini-los como constantes com nomes significativos.
O estudante pode responder que, dado o contexto, é óbvio o que 60 e 24 representam.
Você fez sua sugestão e o estudante a descartou.
Pode não haver nada a ganhar, e talvez boa vontade a perder, ao discutir sobre isso.
Para sugerir algo como uma alternativa que talvez não seja necessariamente melhor, você pode começar com "Outra abordagem poderia ser..."
Por exemplo: "Outra abordagem poderia ser usar every com includes."
Se você apresentar um recurso da linguagem que o estudante não usou na solução (como every ou includes),
seria bom colocar um link para uma documentação que o explique.
Outra forma de introduzir uma sugestão pode ser "Talvez considere..."
Por exemplo: "Talvez considere usar sintaxe de espalhamento em vez de split()."
Se você achar fortemente que o estudante deveria usar uma alternativa, você pode deixar de lado o "Talvez" e começar com "Considere..."
Por exemplo: "Considere usar um argumento padrão."
Para uma série de sugestões, você pode querer variar como cada uma é introduzida.
Marcadores são uma forma eficaz de listar o que você gostou em uma solução.
Eles podem soar menos amigáveis quando usados para listar sugestões.
Oferecer sugestões de forma casual e conversacional pode tornar mais fácil para o estudante considerá-las e aceitá-las.
Uma palavra que provavelmente é melhor não usar ao oferecer uma sugestão é "deveria".
Por exemplo: "Você deveria usar um argumento padrão."
Usar palavras como "deveria" ou "precisa" pode soar autoritário.
Mentores provavelmente vão discordar sobre quando e com que força abordar questões como formatação de código, comentários e convenções de nomenclatura.
Por um lado, você pode querer fazer o estudante pensar sobre essas coisas desde cedo, com exercícios como Two Fer,
antes que ele comece a desenvolver maus hábitos.
Ou você pode não querer intimidar um iniciante com todas as considerações de adequação.
Por outro lado, estudantes que fazem os exercícios mais avançados podem já conhecer as convenções, mas optar por ignorá-las enquanto se concentram na tarefa em questão.
Eles podem se irritar com um foco contínuo nas convenções, vendo isso como pedantismo.
Se uma linguagem tem um ou mais formatadores ou linters, pode ser bom escolher um exercício onde apresentá-los.
Caso contrário, se a violação de uma convenção específica for realmente grave, você pode querer apontá-la onde quer que aconteça.
Onde os mentores podem divergir é no que pode ser considerado "realmente grave".
