¿Qué hace falta 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 mentorizar todas las soluciones de 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 mentorizar un ejercicio que nunca he resuelto?
¿Debería mentorizar un ejercicio que he resuelto, pero en otro lenguaje?
¿Tengo que mentorizar una solución una vez que la he visto?
¿Qué pasa si el estudiante no entiende después de haberle explicado algo varias veces?
¿Cómo respondo si el estudiante se pone a la defensiva con mis sugerencias?
¿Debería tener el estudiante la última palabra, incluso si creo que se equivoca?
¿Cómo formulo mejor una sugerencia?
¿Debería exigir convenciones de formato, comentarios y nombres?
¿Qué hace falta 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 mentorizas.
Si hay algo en una solución que crees que podría hacerse de otra manera, puedes sugerirlo.
No tiene por qué ser necesariamente una manera mejor, basta con una alternativa idiomática.
Eso deja en manos del 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 nuevas características del lenguaje 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.
Así que mentorizar puede ser una buena forma de aprender más sobre un lenguaje.
¿Puedo ser mentor de más de un lenguaje?
Puedes mentorizar tantos lenguajes como te sientas cómodo.
No pasa nada por mentorizar varios lenguajes en los que te sientes fuerte, así como un lenguaje que todavía estás aprendiendo.
¿Debería intentar mentorizar todas las soluciones de la cola?
Si en ese momento no se te ocurre nada sustancial o constructivo que decir sobre una solución,
puede que sea mejor para el estudiante que dejes la solicitud de mentoría para otro mentor,
aunque eso signifique que tendrá 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 sabes responder, puede que aun así quieras dejarla
para alguien que pueda responderla.
En caso contrario, puede que la solución sea de un ejercicio que a ti te resultó difícil, que quizá no hayas resuelto,
o que hayas resuelto pero sientas que no lo resolviste muy bien.
En ese caso, podrías echar un vistazo a la solución para ver si hay algo que puedas aprender de ella.
Si es así, puedes darle las gracias al estudiante por lo que hayas aprendido concretamente de su solución.
O puede que 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 educación y respeto.
Luego podrías preguntarles si consideraron otro enfoque y por qué eligieron el enfoque que eligieron.
O puede que sigas sin entender la solución en conjunto, pero veas algunas cosas que puedas abordar.
Por ejemplo, podrías señalarle que considere usar nombres significativos para los parámetros de las funciones,
si solo usó n o m.
Si no te sientes cómodo haciendo nada de eso, no pasa nada por dejar la solicitud sin responder.
La mentoría es voluntaria.
El hecho de mentorizar un lenguaje no significa que tengas que mentorizar todos los ejercicios de ese lenguaje.
¿Qué pasa si no tengo nada que sugerir sobre una solución?
No pasa nada por decir qué te gusta de una solución.
De hecho, decir qué te gusta concretamente de una solución es una buena forma de empezar cualquier interacción de mentoría.
Después de eso, si no tienes sugerencias sobre formas alternativas de abordar el ejercicio,
basta con decirle al estudiante: «¡Bien hecho!».
Si el estudiante ha enviado más de una iteración,
puede que puedas señalar en qué aspectos la iteración más reciente es una mejora.
¿Debería mentorizar 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 es uno que hace que el ejercicio parezca más sencillo
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 preparado para la próxima vez.
¿Debería mentorizar un ejercicio que he resuelto, pero en otro lenguaje?
Dado que lo que es idiomático en un lenguaje puede no serlo en otro,
lo más probable es que sea mejor haber resuelto el ejercicio en el lenguaje en el que vas a mentorizar.
Si las soluciones entre dos lenguajes son muy similares, y conoces ambos lenguajes lo bastante bien
como para saber qué es idiomático en cada uno, no debería llevarte 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 preparado para la próxima vez.
¿Tengo que mentorizar una solución una vez que la he visto?
Puede que mires una solución y te des cuenta de que no quieres mentorizarla por alguno de varios motivos, entre ellos:
- Puede que el estudiante haya hecho una pregunta cuya respuesta no conoces.
- Puede que el código sea tan verboso o confuso que no sepas por dónde empezar a criticarlo.
- 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 de tal naturaleza que indique que puede resultar desagradable o pesado interactuar con él.
Nada te obliga a hacer clic en el botón «Empezar a mentorizar» si crees que esa solicitud de mentoría concreta no es para ti.
¿Qué pasa si el estudiante no entiende después de haberle explicado algo varias veces?
Puede haber ocasiones en las que un estudiante parezca casi empeñado en no entender tus explicaciones.
Si sientes que has agotado todas las formas que conoces de explicar algo, puedes decidir
terminar la conversación con la sugerencia de que el estudiante vuelva a enviar su solicitud de mentoría para que
la pueda atender otro mentor que quizá tenga más éxito explicando los puntos difíciles.
¿Cómo respondo si el estudiante se pone a la defensiva con 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.
Dado que Exercism es una plataforma de aprendizaje y no un sitio de programación competitiva, esa es una razón justificable
para no usar el enfoque más elegante o eficiente.
Puede que quieras hacer algunas sugerencias sobre cómo usó su enfoque,
si ves que podría haberlo implementado de forma más idiomática.
En cualquier caso, puedes sugerirle que envíe otra iteración basada en tus comentarios,
o que termine la conversación para liberar un hueco 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 sencilla 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 atrinchera, lo mejor puede ser pasar página.
Puede que el estudiante rechace una sugerencia de plano.
Por ejemplo, puede que sugieras 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 puede que el estudiante lo rechace, porque encuentra que map y join son más legibles.
No pasa nada por darle la razón al estudiante en que map y join pueden ser más legibles que reduce.
Puedes sugerirle que puede sentirse más cómodo con reduce cuando se acostumbre,
y que no hay nada malo en usar map y join.
No pasa nada por darle la razón a un estudiante en la medida en que tenga razón,
y no pasa nada por intentar corregir cualquier idea equivocada o exageración que el estudiante haya expresado.
¿Debería tener el estudiante la última palabra, incluso si creo que se equivoca?
Por ejemplo, puede que le sugieras a un estudiante que no use números mágicos como 60 y 24
al resolver el ejercicio Clock, sino que los defina como constantes con nombres significativos.
Puede que el estudiante responda que, dado el contexto, es obvio qué representan 60 y 24.
Ya has hecho tu sugerencia y el estudiante la ha descartado.
Puede que no haya nada que ganar, y quizá buena voluntad que perder, discutiendo al respecto.
Para sugerir algo como alternativa que quizá no sea necesariamente mejor, podrías empezar con «Otro enfoque podría ser...».
Por ejemplo: «Otro enfoque podría ser usar every con includes.»
Si vas a presentar una característica del lenguaje que el estudiante no ha usado en la solución (como every o includes),
sería buena idea enlazar a una doc que la explique.
Otra forma de introducir una sugerencia podría ser «Quizá puedas considerar...».
Por ejemplo: «Quizá puedas considerar usar la sintaxis de propagación en lugar de split().»
Si crees firmemente que el estudiante debería usar una alternativa, podrías quitar el «Quizá» y empezar con «Considera...».
Por ejemplo: «Considera usar un argumento por defecto.»
Para una serie de sugerencias, puede que quieras variar cómo se introduce cada una.
Las viñetas son una forma eficaz de enumerar lo que te gusta de una solución.
Pueden resultar menos amables cuando enumeras sugerencias.
Ofrecer sugerencias de forma informal y conversacional puede hacer que al estudiante le resulten menos difíciles de considerar y aceptar.
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 «debes» puede resultar autoritario.
Es probable que los mentores no se pongan de acuerdo sobre cuándo y con qué firmeza sacar a relucir cuestiones como el formato del código, los comentarios y las convenciones de nombres.
Por un lado, puede que 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 puede que no quieras intimidar a un principiante con todo tipo de consideraciones sobre lo que está bien y lo que no.
Por otro lado, los estudiantes que hacen los ejercicios más avanzados puede que ya conozcan las convenciones, pero que decidan ignorarlas mientras se centran en la tarea en cuestión.
Puede que les moleste que sigas insistiendo en las convenciones, como si fuera pedantería.
Si un lenguaje tiene uno o varios formateadores o linters, puede ser bueno elegir un ejercicio en el que presentarlos.
Por lo demás, si la infracción de una convención concreta es realmente grave, puede que quieras señalarla allá donde ocurra.
Donde los mentores pueden diferir es en qué se considera «realmente grave».
