O que é preciso para ser mentor?
Posso ser mentor de uma linguagem que ainda estou a aprender?
Posso ser mentor de mais do que uma linguagem?
Devo tentar dar mentoria a todas as soluções na fila?
E se uma solução está na fila há dias, ou mesmo semanas?
E se não tenho nada a sugerir sobre uma solução?
Devo dar mentoria a um exercício que nunca resolvi?
Devo dar mentoria a um exercício que resolvi, mas resolvi noutra linguagem?
Tenho de dar mentoria a uma solução depois de a ter visto?
E se o estudante não compreender depois de eu explicar algo várias vezes?
Como respondo se o estudante ficar na defensiva com a(s) minha(s) sugestão(ões)?
Deve o estudante ter a última palavra, mesmo que eu ache que está errado?
Como formulo da melhor forma uma sugestão?
Devo impor convenções de formatação, comentários e nomenclatura?
O que é preciso para ser mentor?
Não precisas de ser um especialista numa linguagem para seres mentor dessa linguagem.
Basta seres um pouco menos novato do que a pessoa a quem estás a dar mentoria.
Se houver algo numa solução que achas que poderia ser feito de outra forma, podes sugeri-lo.
Não tem necessariamente de ser uma forma melhor, apenas uma alternativa idiomática.
Isso deixa a decisão de usar ou não a sugestão nas mãos do estudante,
mas pelo menos o estudante passa a ter mais opções por onde escolher.
Posso ser mentor de uma linguagem que ainda estou a aprender?
O ideal é que nunca deixes de aprender uma linguagem, mesmo uma que já conheces.
Algumas linguagens lançam uma versão atualizada a cada poucas semanas ou meses.
Pode haver não só novas funcionalidades da linguagem para aprender, como também funcionalidades existentes que desconheces.
Às vezes, um estudante pode usar uma funcionalidade, e essa será a primeira vez que a vês.
Por isso, dar mentoria pode ser uma boa forma de aprender mais sobre uma linguagem.
Posso ser mentor de mais do que uma linguagem?
Podes dar mentoria em tantas linguagens quantas aquelas com que te sentires à vontade.
Não há problema em dar mentoria em várias linguagens em que te sentes seguro, bem como numa linguagem que ainda estás a aprender.
Devo tentar dar mentoria a todas as soluções na fila?
Se, naquele momento, não te ocorrer nada substancial ou construtivo para dizer sobre uma solução,
pode ser melhor para o estudante que deixes o pedido de mentoria para outro mentor,
mesmo que isso signifique que o estudante terá de esperar mais tempo por uma resposta.
E se uma solução está na fila há dias, ou mesmo semanas?
Se o estudante fez uma pergunta específica que não consegues responder, podes ainda assim querer deixá-la
para alguém que consiga responder à pergunta.
Caso contrário, a solução pode ser de um exercício que foi difícil para ti, que podes não ter resolvido,
ou que resolveste mas achaste que não resolveste muito bem.
Nesse caso, podes analisar a solução para ver se há algo que possas aprender com ela.
Se sim, podes agradecer ao estudante por aquilo que aprendeste especificamente com aquela solução.
Ou podes querer que o estudante te explique a solução.
Isso é uma espécie de «mentoria inversa», mas alguns estudantes podem ficar contentes por explicar a solução
quando lhes pedes com educação e respeito.
Podes então perguntar se considerou outra abordagem e porque escolheu essa abordagem.
Ou podes continuar a não compreender a solução no seu todo, mas vês algumas coisas que podes abordar.
Por exemplo, podes sugerir que se considerem nomes com significado para os parâmetros da função,
se o estudante usou apenas n ou m.
Se não te sentires à vontade para fazer nenhuma dessas coisas, não há problema em deixar o pedido sem resposta.
A mentoria é voluntária.
O facto de dares mentoria numa linguagem não significa que tenhas de dar mentoria a todos os exercícios dessa linguagem.
E se não tenho nada a sugerir sobre uma solução?
Não há problema em dizeres o que gostas numa solução.
Na verdade, dizer o que gostas especificamente numa solução é uma boa forma de começar qualquer conversa de mentoria.
Depois disso, se não tiveres sugestões de formas alternativas de abordar o exercício,
podes simplesmente dizer ao estudante: «Muito bem!»
Se o estudante submeteu mais do que uma iteração,
podes conseguir apontar em que aspetos a iteração mais recente é uma melhoria.
Devo dar mentoria a um exercício que nunca resolvi?
Às vezes, olhar para a solução de um estudante inspira-te a resolver o exercício tu próprio,
sobretudo se a abordagem usada na solução fizer o exercício parecer mais simples
do que abordagens que já tenhas considerado.
Depois de resolveres o exercício, se o pedido de mentoria que te inspirou já não estiver disponível,
pelo menos ficas preparado para a próxima vez.
Devo dar mentoria a um exercício que resolvi, mas resolvi noutra linguagem?
Dado que o que é idiomático numa linguagem pode não ser idiomático noutra linguagem,
o mais provável é que seja melhor teres resolvido o exercício na linguagem em que estás a dar mentoria.
Se as soluções entre duas linguagens forem muito semelhantes, e conheceres ambas as linguagens suficientemente bem
para saber o que é idiomático em cada uma, então não deverá demorar muito a transpor uma solução de uma linguagem para a outra.
Se o pedido de mentoria já não estiver disponível depois de transpores a solução,
pelo menos ficas preparado para a próxima vez.
Tenho de dar mentoria a uma solução depois de a ter visto?
Podes olhar para uma solução e perceber que não queres dar mentoria sobre ela por vários motivos, entre os quais:
- O estudante pode ter feito uma pergunta para a qual não sabes a resposta.
- O código pode ser tão verboso e/ou confuso que não sabes por onde começar a crítica.
- O código pode indicar que o estudante é um principiante absoluto que vai precisar de muita orientação básica
para a qual não tens tempo nem paciência.
- O comentário do estudante pode ser de tal modo que indique que pode ser desagradável ou trabalhoso interagir com ele.
Nada te obriga a clicar no botão «Começar mentoria» se achares que aquele pedido de mentoria não é para ti.
E se o estudante não compreender depois de eu explicar algo várias vezes?
Pode haver alturas em que um estudante parece quase deliberadamente resistente a compreender as tuas explicações.
Se sentires que esgotaste todas as formas que conheces de explicar algo, podes decidir
terminar a discussão com a sugestão de que o estudante volte a submeter o pedido de mentoria, para que
possa ser tratado por outro mentor que talvez tenha mais sucesso a explicar o(s) ponto(s) difícil(es).
Às vezes, um estudante diz que usou uma abordagem mais trabalhosa do que o necessário para aprender
mais sobre uma funcionalidade da linguagem, mesmo que essa funcionalidade não seja a mais adequada para o exercício.
Como o Exercism é uma plataforma de aprendizagem 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.
Podes fazer algumas sugestões sobre a forma como o estudante usou a abordagem,
se vires que a poderia ter implementado de forma mais idiomática.
Em qualquer caso, podes sugerir que submeta outra iteração com base no feedback,
ou que termine a discussão para libertar 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, pode querer usar sempre o paradigma orientado a objetos,
e fragmentar uma solução relativamente simples e direta numa pequena explosão de classes
com um fluxo de controlo 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.
Podes tentar, e pode acontecer que responda à tua sugestão, mas se o estudante se fechar na sua posição, talvez seja melhor seguir em frente.
O estudante pode rejeitar uma sugestão de forma categórica.
Por exemplo, podes 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 considera map e join mais legíveis.
Não há problema em concordar com o estudante que map e join podem ser mais legíveis do que reduce.
Podes sugerir que pode ficar mais à vontade com reduce depois de mais tempo a habituar-se,
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 tem razão,
e não há problema em tentar corrigir qualquer equívoco ou exagero que o estudante possa ter manifestado.
Deve o estudante ter a última palavra, mesmo que eu ache que está errado?
Por exemplo, podes sugerir a um estudante que não use números mágicos como 60 e 24
ao resolver o exercício Clock, mas que os defina como constantes com nomes com significado.
O estudante pode responder que, dado o contexto, é óbvio o que 60 e 24 representam.
Fizeste a tua sugestão e o estudante rejeitou-a.
Pode não haver nada a ganhar, e talvez boa vontade a perder, ao discutir sobre isso.
Para sugerir algo como alternativa que pode não ser necessariamente melhor, podes começar por «Outra abordagem poderia ser...»
Por exemplo, «Outra abordagem poderia ser usar every com includes.»
Se introduzires uma funcionalidade da linguagem que o estudante não usou na solução (como every ou includes),
é boa ideia incluir uma ligação para uma documentação que a explique.
Outra forma de começar uma sugestão pode ser «Talvez consideres...»
Por exemplo, «Talvez consideres usar a sintaxe de espalhamento em vez de split().»
Se achares firmemente que o estudante deve usar uma alternativa, podes retirar o «Talvez» e começar por «Considera...»
Por exemplo, «Considera usar um argumento por omissão.»
Para uma série de sugestões, podes querer variar a forma como cada uma é introduzida.
As listas com marcadores são uma forma eficaz de enumerar o que gostas numa solução.
Podem parecer menos amigáveis quando enumeras sugestões.
Apresentar as sugestões de forma descontraída e conversacional pode torná-las menos difíceis de o estudante considerar e aceitar.
Uma palavra que provavelmente é melhor não usar ao fazer uma sugestão é «deves».
Por exemplo, «Deves usar um argumento por omissão.»
Usar palavras como «deves» ou «tens de» pode soar autoritário.
É provável que os mentores discordem sobre quando e com que firmeza abordar questões como a formatação do código, os comentários e as convenções de nomenclatura.
Por um lado, podes querer levar o estudante a pensar nestas coisas desde cedo, com exercícios como o Two Fer,
antes de começar a criar maus hábitos.
Ou podes não querer intimidar um principiante com todas as considerações de conveniência.
Por outro lado, os 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 mãos.
Podem ressentir-se com uma insistência contínua nas convenções, encarando-a como pedantismo.
Se uma linguagem tiver um ou mais formatadores ou linters, pode ser boa ideia escolher um exercício onde os apresentar.
Caso contrário, se a violação de uma determinada convenção for realmente grave, podes querer apontá-la onde quer que aconteça.
Onde os mentores podem divergir é naquilo que pode ser considerado «realmente grave».
