¿Qué hace que alguien califique para ser mentor?
¿Puedo ser mentor de un lenguaje mientras todavía lo estoy aprendiendo?
¿Puedo ser mentor de más de un lenguaje?
¿Debería intentar ser mentor de todas las soluciones que están en la cola?
¿Qué pasa si una solución lleva días en la cola, incluso semanas?
¿Qué pasa si no tengo nada que sugerir sobre una solución?
¿Debería ser mentor de un ejercicio que nunca he resuelto?
¿Debería ser mentor de un ejercicio que resolví, pero en un lenguaje diferente?
¿Tengo que ser mentor de una solución una vez que la he visto?
¿Qué pasa si el estudiante no entiende después de que le he explicado algo varias veces?
¿Cómo respondo si el estudiante se pone a la defensiva por mis sugerencias?
¿Debería el estudiante tener la última palabra, aunque crea que está equivocado?
¿Cómo formulo mejor una sugerencia?
¿Debería exigir convenciones de formato, comentarios y nombres?
¿Qué hace que alguien califique para ser mentor?
No necesitas ser un experto en un lenguaje para ser mentor de ese lenguaje.
Solo necesitas ser un poco menos novato que la persona a la que le haces mentoría.
Si hay algo en una solución que crees que se podría hacer de otra manera, puedes sugerirlo.
No tiene que ser necesariamente una manera mejor, basta con una alternativa idiomática.
Eso deja en el estudiante la decisión de usar la sugerencia o no,
pero al menos el estudiante tiene más opciones entre las que elegir.
¿Puedo ser mentor de un lenguaje mientras todavía lo estoy aprendiendo?
Lo ideal es que nunca dejes de aprender un lenguaje, ni siquiera uno que ya conoces.
Algunos lenguajes publican una versión actualizada cada pocas semanas o meses.
No solo puede haber características nuevas que aprender, sino también características existentes que desconoces.
A veces un estudiante puede usar una característica y esa será la primera vez que la ves.
Por eso, la mentoría puede ser una buena forma de aprender más sobre un lenguaje.
¿Puedo ser mentor de más de un lenguaje?
Puedes ser mentor de tantos lenguajes como te sientas cómodo.
No hay problema con ser mentor de varios lenguajes en los que te sientas fuerte, así como de un lenguaje que todavía estás aprendiendo.
¿Debería intentar ser mentor de todas las soluciones que están en la cola?
Si en ese momento no se te ocurre algo sustancial o constructivo que decir sobre una solución,
puede ser mejor para el estudiante que dejes la solicitud de mentoría para otro mentor,
aunque ese estudiante tenga que esperar más tiempo una respuesta.
¿Qué pasa si una solución lleva días en la cola, incluso semanas?
Si el estudiante hizo una pregunta concreta que no puedes responder, quizá igual quieras dejarla
para alguien que sí pueda responderla.
De lo contrario, puede que la solución sea de un ejercicio que fue difícil para ti, que quizá no resolviste,
o que resolviste pero sentiste que no lo hiciste muy bien.
En ese caso, podrías revisar la solución para ver si hay algo que puedas aprender de ella.
Si es así, puedes agradecer al estudiante por lo que aprendiste específicamente de su solución.
O quizá quieras pedirle al estudiante que te explique su solución.
Eso es una especie de «mentoría inversa», pero a algunos estudiantes les puede gustar explicar su solución
cuando se les pide con amabilidad y respeto.
Luego podrías preguntarles si consideraron otro enfoque y por qué eligieron el enfoque que usaron.
O puede que todavía no entiendas la solución en general, pero veas algunas cosas que puedas abordar.
Por ejemplo, podrías señalar que consideren usar nombres significativos para los parámetros de las funciones,
si solo usaron n o m.
Si no te sientes cómodo haciendo ninguna de esas cosas, está bien dejar la solicitud sin responder.
La mentoría es voluntaria.
Que seas mentor de un lenguaje no significa que tengas que ser mentor de todos los ejercicios de ese lenguaje.
¿Qué pasa si no tengo nada que sugerir sobre una solución?
Está bien decir qué te gusta de una solución.
De hecho, decir qué te gusta específicamente de una solución es una buena forma de empezar cualquier encuentro de mentoría.
Después de eso, si no tienes sugerencias sobre formas alternativas de abordar el ejercicio,
está bien decirle al estudiante: «¡Bien hecho!».
Si el estudiante envió más de una iteración,
podrías señalar en qué aspectos la iteración más reciente es una mejora.
¿Debería ser mentor de un ejercicio que nunca he resuelto?
A veces, mirar la solución de un estudiante te inspirará a resolver el ejercicio tú mismo,
sobre todo si el enfoque usado en la solución hace que el ejercicio parezca más simple
que los enfoques que ya habías considerado.
Después de resolver el ejercicio, si la solicitud de mentoría que te inspiró ya no está disponible,
al menos estarás listo para la próxima vez.
¿Debería ser mentor de un ejercicio que resolví, pero en un lenguaje diferente?
Dado que lo que es idiomático en un lenguaje puede no serlo en otro,
probablemente sea mejor haber resuelto el ejercicio en el lenguaje del que vas a ser mentor.
Si las soluciones entre dos lenguajes son muy similares, y conoces ambos lenguajes lo suficiente
como para saber qué es idiomático en cada uno, no debería tomarte mucho trasladar una solución de un lenguaje al otro.
Si la solicitud de mentoría ya no está disponible después de trasladar la solución,
al menos estarás listo para la próxima vez.
¿Tengo que ser mentor de una solución una vez que la he visto?
Puedes mirar una solución y darte cuenta de que no quieres ser mentor de ella por varias razones, entre ellas:
- Es posible que el estudiante haya hecho una pregunta cuya respuesta no conoces.
- Puede que el código sea tan verboso y/o confuso que no sepas por dónde empezar una crítica.
- Puede que el código indique que el estudiante es un principiante absoluto que necesitará mucha orientación básica
para la que no tienes ni el tiempo ni la paciencia.
- Puede que el comentario del estudiante sea tal que indique que puede resultar desagradable o laborioso interactuar con él.
Nada te obliga a hacer clic en el botón «Comenzar mentoría» si crees que esa solicitud de mentoría en particular no es para ti.
¿Qué pasa si el estudiante no entiende después de que le he explicado algo varias veces?
Puede haber veces en que un estudiante parezca resistirse casi a propósito a entender tus explicaciones.
Si sientes que agotaste todas las formas que conoces de explicar algo, puedes decidir
terminar la discusión sugiriendo que el estudiante vuelva a enviar su solicitud de mentoría para que
la atienda otro mentor que quizá tenga más éxito explicando el punto o los puntos difíciles.
¿Cómo respondo si el estudiante se pone a la defensiva por mis sugerencias?
A veces un estudiante dirá que usó un enfoque más laborioso de lo necesario como forma de aprender
más sobre una característica del lenguaje, aunque esa característica no sea la más adecuada para el ejercicio.
Como Exercism es una plataforma para aprender y no un sitio de programación competitiva, esa es una razón justificable
para no usar el enfoque más elegante o eficiente.
Podrías hacer algunas sugerencias sobre cómo usaron su enfoque,
si ves que podrían haber implementado su enfoque de forma más idiomática.
En cualquier caso, puedes sugerirles que pueden enviar otra iteración basada en la retroalimentación,
o que pueden terminar la discusión para liberar un espacio de mentoría.
Puede que un estudiante se adhiera a un paradigma de programación que no sea el más adecuado para el lenguaje o el ejercicio.
Por ejemplo, puede que siempre quiera usar el paradigma orientado a objetos
y fragmentar una solución relativamente simple y directa en una pequeña explosión de clases
con un flujo de control laberíntico a través de múltiples métodos.
En la medida en que el estudiante sea un seguidor dogmático del paradigma, normalmente es inútil intentar
convencerlo de un enfoque diferente.
Puedes intentarlo, y puede que responda a tu sugerencia, pero si el estudiante se aferra a su posición, quizá lo mejor sea seguir adelante.
Puede que el estudiante rechace directamente una sugerencia.
Por ejemplo, puedes sugerir usar reduce en lugar de map y join,
ya que reduce es solo una iteración en lugar de una iteración para map y otra para join.
Pero el estudiante puede rechazarlo, porque le parecen más legibles map y join.
Está bien darle la razón al estudiante en que map y join pueden ser más legibles que reduce.
Puedes sugerirle que quizá se sienta más cómodo con reduce después de más tiempo de acostumbrarse,
y que no hay nada malo en usar map y join.
Está bien darle la razón a un estudiante en la medida en que tenga razón,
y está bien intentar corregir cualquier idea equivocada o exageración que el estudiante haya expresado.
¿Debería el estudiante tener la última palabra, aunque crea que está equivocado?
Por ejemplo, puedes sugerirle a un estudiante que no use números mágicos como 60 y 24
al resolver el ejercicio Clock, y en su lugar proponer definirlos como constantes con nombres significativos.
Puede que el estudiante responda que, dado el contexto, es obvio qué representan 60 y 24.
Ya hiciste tu sugerencia y el estudiante la descartó.
Puede que no haya nada que ganar, y quizá algo de buena voluntad que perder, discutiendo al respecto.
Para sugerir algo como alternativa que quizá no sea necesariamente mejor, puedes empezar con «Otro enfoque podría ser...».
Por ejemplo: «Otro enfoque podría ser usar every con includes.»
Si presentas una característica del lenguaje que el estudiante no usó en la solución (como every o includes),
sería bueno enlazar a una documentación que la explique.
Otra forma de introducir una sugerencia podría ser «Quizás podrías considerar...».
Por ejemplo: «Quizás podrías considerar usar la sintaxis de propagación en lugar de split().»
Si sientes firmemente que el estudiante debería usar una alternativa, puedes quitar el «Quizás» y empezar con «Considera...».
Por ejemplo: «Considera usar un argumento por defecto.»
Para una serie de sugerencias, quizá quieras variar cómo introduces cada una.
Las viñetas son una forma eficaz de enumerar lo que te gusta de una solución.
Pueden percibirse como menos amables cuando enumeras sugerencias.
Ofrecer sugerencias de forma casual y conversacional puede hacer que al estudiante le resulte menos difícil considerarlas y aceptarlas.
Una palabra que probablemente sea mejor no usar al ofrecer una sugerencia es «deberías».
Por ejemplo: «Deberías usar un argumento por defecto.»
Usar palabras como «deberías» o «tienes que» puede sonar autoritario.
Es probable que los mentores no estén de acuerdo sobre cuándo y con cuánta firmeza mencionar temas como el formato del código, los comentarios y las convenciones de nombres.
Por un lado, quizá quieras que el estudiante empiece a pensar en esas cosas desde el principio con ejercicios como Two Fer,
antes de que empiece a desarrollar malos hábitos.
O quizá no quieras intimidar a un principiante con todas las consideraciones sobre lo que es apropiado.
Por otro lado, los estudiantes que hacen los ejercicios más avanzados puede que ya conozcan las convenciones pero decidan ignorarlas mientras se concentran en la tarea que tienen entre manos.
Puede que les moleste un enfoque continuo en las convenciones por considerarlo pedantería.
Si un lenguaje tiene uno o más formateadores o linters, puede ser bueno elegir un ejercicio donde introducirlos.
De lo contrario, si la violación de una convención en particular es realmente grave, quizá quieras señalarla dondequiera que ocurra.
Donde los mentores pueden diferir es en qué se considera «realmente grave».
