Todo parte cuando decidí dar el salto a aprender JavaScript, algo que como cualquier cosa no se aprende el mismo día. Siempre me ha tocado ser autodidacta (como a mucha gente en el sector). Realmente se puede decir que empecé a aprender JavaScript de verdad en octubre de 2017 cuando me vine a Barcelona, un cambio profesional en el que sin duda he aprendido muchísimo. Ahora hago alguna cosa con Vue y React incluso.
Mi forma de enfocarlo, como casi todo, es desde las bases. Soy firme creyente que lo mejor que se puede hacer es aprender Vanilla JavaScript, a diferencia de otras personas que se ponen con una librería o framework concreto. Entender qué patrones sigue al hacer según que cosas, arquitectura para ver cómo ordenar las carpetas y evitar así problemas, en definitiva, lo que está debajo de la herramienta.
Así que, tras entrar en el nuevo trabajo y empezar a tener trato con algunos compañeros decidí preguntarle a uno si no le importaría ser mi mentor, que estaba intentando aprender sobre el tema.
Me dijo que sí y nos pusimos manos a la obra.
¿Por dónde empezar? ¿Qué se puede hacer con JavaScript? Me surgían dudas porque al empezar no conocía prácticamente nada más que añadir alguna clase en el HTML y poco más. ¿Testing? ¿Eso qué es? ¿Para qué sirve?
Tenía muchísimas dudas porque no sabía programar más que lo que era hacer bucles, if statements y poco más. Si, hacía un tiempo había hecho un Bootcamp (en Ruby y cuatro días de jQuery y JavaScript) y no solamente ya no me acordaba de nada sino que no sabía por donde empezar. Conocer el ecosistema de herramientas y tecnologías no me ayudaba mucho, sabía que existía React, Vue, Angular y mil cosas más pero no sabía que era una directiva, un endpoint, no tenía ni idea de patrones de diseño (aún conozco pocos) pero menos aún conocía buenas prácticas. Durante mis primeros dos años o dos años y medio había maquetado únicamente, se me daba decentemente pero no era programador y por tanto por mucho que había escuchado decir que JavaScript proveía de la interacción eso no me decía mucho. Para mi interacción es movimiento, ¿animaciones web entonces?
Mi definición de mentoría
Una persona con experiencia en un campo concreto que guía (no enseña) a otra que comienza o quiere mejorar, manteniendo una relación personal.
Mi experiencia siendo mentorizado
Estuvimos unas semanas reuniéndonos después del trabajo de vez en cuando pero unas veces no podía él y otras veces yo me hacía el remolón porque me costaba saber que preguntar o por donde avanzar, estaba perdido.
Me ayudó a que me explicase ciertas cosas que yo había visto y no entendía tras haber dedicado tiempo a investigar por mi cuenta. Le preguntaba definiciones sobre términos de JavaScript como closures, recursividad, o callback hell. El problema es que aunque había leído sobre el tema en mi casa, al ser términos avanzados (al menos para mí en ese momento) y desde luego que eran inconexos me costaba muchísimo entenderlos.
Me acuerdo que me decía, habrá un momento que hará «click» y entenderás ciertas cosas. ¿Cómo que hará «click»? No sabía ni pasar parámetros a funciones y mucho menos hacer composición de funciones.
Efectivamente, al cabo de un tiempo hizo «click» y entendí como hacer composición de funciones y pasar parámetros.
No funcionó, por mi desgana al no saber hacia donde ir y por ir dejándolo pasar al final lo dejamos. Poco después se fue a trabajar a Londres, gracias por tanto Alfredo.
De mentorizado a mentor
Después de un par de meses o así donde ya había unido conceptos (había hecho «click») decidí buscar nuevo mentor y un conocido de Twitter me recomendó un Slack orientado a backend que llevaba una empresa de recruiting en Gran Bretaña así que decidí probar suerte y buscar mentor pero cuando entré me preguntaron si podría mentorizar a alguien. Acepté pero claro, yo solamente sabía CSS así que les ofrecí mentoring técnico en ese área. Me preguntaron tres o cuatro personas y al final parece que encajé con una.
Estaba con una ilusión enorme de ayudar a alguien, en el pasado lo había intentado un par de veces pero fallé estrepitosamente, cuando las cosas no funcionan hay que dejarlas ir. En Twitter vi que un compañero del sector que vive en Valencia comentó que iba a organizar un Open Space sobre didáctica de la programación y allá que fui.
Tweet: ⚡️ «¿Os acordáis del Open Space ese sobre didáctica de la programación?»
No pudo ser mejor la experiencia, quizá porque no tenía mucha idea de prácticas que llevar y como gestionarlo volví con una energía enorme.
Tomé unas cuantas notas, así que aquí las dejo por si le sirven a alguien, también tener en cuenta que de ésto ha pasado más de un año. Puede que algo esté fuera de contexto y os parezca raro.
Notas del Open Space
- Ayudar a la persona a ser autosuficiente.
- El ritmo lo ha de llevar quien es mentorizado o mentorizada.
- El por qué se aprenden las cosas.
- Hacer pair programming.
- No tirar del mentee, que se preocupe de progresar.
- Evitar el paternalismo y el adoctrinamiento (no ser dogmático).
- Ha de ser el mentee quien tome la iniciativa en la mentoría para que sea un éxito.
- Lado oscuro del mentee: falta de crítica y/o sumisión.
- Expresar tu duda constantemente, hacerte ver que no eres perfecto, nadie lo es.
- Code reviews.
- Equipos multinivel.
- Cada persona tiene su ritmo.
- Al principio aceptar como válido y absorber conocimiento pero a la larga ser crítico y capaz de cambiar de opinión.
- Resolver dudas de cosas que tu también tuviste.
- Aprender que las cosas pueden ser válidas y a su vez ninguna mejor que otra.
- Dejarles hacer algo y que cuando se hayan equivocado hacerles una pregunta para cuestionar el resultado.
- Dejar que fallen para que cuando vean la solución aprendan y refactoricen.
- Cuestionar sus decisiones (no pain no gain).
Un año después (empezamos el 6 de julio de 2018) sigo mentorizando a esta persona, de Londres, en inglés (que aunque entiendo perfectamente hablado, escrito y oído hablado se me da regular). Ha sido un año increíble de aprendizaje, desde como explicar conceptos, a guiar a una persona. Estoy muy orgulloso de lo que está consiguiendo.
He leído que el mentoring ha de ser bidireccional, que si tu no ganas no se está llevando bien. En verdad me da bastante igual el «ganar» algo o no. Lo hago porque tengo la suerte de tener tiempo. Lo que si me he dado cuenta es que aunque mi nivel hablado de inglés es decente, noto que me falta infinito vocabulario y me paso el día pidiendo perdón por mi capacidad a la hora de expresarme.
¿Cómo nos organizamos?
Al principio era un poco caos, quería aprender CSS y yo no paraba de facilitarle recursos, ya filtrados de los que creo que no son tan interesantes, pero acabas dándote cuenta que cada persona tiene una forma de aprender. Tenemos una reunión cada dos-tres semanas por Skype (de unas 2-3h) donde compartimos pantalla, hacemos pair programming y/o solucionamos algún problema. Ayer mismo me pidió ayuda con JavaScript y no supe solucionarlo 🤦🏻.
Empezó aprendiendo algo de Flexbox y CSS Grid Layout, pero como todo hasta que no te encuentras problemas reales por mucha teoría que sepas si no te enfrentas a solucionarlo no acabas aprendiendo (al menos yo). Básicamente es lo que yo a muy grandes rasgos considero que es la diferencia entre un junior y un senior. El senior se ha peleado muchas más veces con problemas similares y le resultan familiares.
Hacíamos pequeños ejercicios con Flexbox y Grid, posteriormente hizo su primera web y la subió a Github, luego la deployó en Netlify. Todo un logro. Nos hemos peleado con Gulp, estuvo un par de semanas con una frustración enorme porque el Boilerplate que habíamos montado no funcionaba y me dijo que se había cansado de usar Gulp, que le parecía una tontería y que iba a usar CSS sin Sass (motivo por el cual usábamos Gulp) así que al cabo de unos días lo migró a Gulp 4 y me dijo, «¡Ya funciona!».
Hemos estado viendo como enfrentarse a sus primeros procesos de selección (apunta alto, la BBC, Spotify…), le ha pasado muchas veces que ve ofertas donde no se ve capaz, piden un junior con conocimientos de React, Redux, MYSQL, Node.JavaScript… Lo de siempre, la lista de los reyes magos. Hasta ha dado su primera charla pública de nada menos que 15min.
Resulta mucho más fácil decirle que se de cuenta de lo que ha conseguido en apenas un año que de hacerlo yo con mi progreso. Quizá porque somos más críticos con nosotros mismos y nos cuesta ver nuestros propios logros.
Al principio (lo hablábamos ayer precisamente) tenía que tirar yo del carro así que fui intentando que fuese al revés, dejaba pasar los días sin cuadrar nuestra próxima reunión, los fui aplazando (al inicio eran cada semana) y más que un mentor era un profesor, no es que me importe pero no es lo que busco, no me pagan ni pretendo (faltaría más) pero creo que así no aprenderá tanto. He conseguido que se motive, que sea más autodidacta y no ser un formador si no un guía.
Me ha costado mucho ver como cada persona necesita recibir la información de una manera y sobre todo no darle la solución de primeras. Dar las herramientas para que ellos puedan llegar a ella. Usamos Twitter por privado como si fuese una herramienta de mensajería instantánea y me acuerdo que al inicio me preguntaba y directamente le daba la solución, ahora le doy pistas para que llegue a la solución, por ejemplo que mire en cierto módulo de mi web que ahí tiene algo parecido a lo que busca.
Insiste en preguntarme soluciones de todo y es algo que estoy intentando corregir, que se pelee pero desde luego si no lo encuentra le ayudo. Siempre que me dice: ¿cómo se hace esto? Le respondo «sabes la respuesta» y me dice: «búscalo». Así que creo que vamos por buen camino.
Desde hace tiempo también miramos lo no técnico, miedos de no encontrar trabajo, las dificultades que se encuentra en los procesos de selección… aquí he tenido la suerte de contarle mis experiencias pasadas y presentes 😉 y que yo también he fallado estrepitosamente en varios procesos, le he enseñado las pruebas técnicas que tengo privadas en Github para que vea código de cosas que te pueden pedir, hemos hablado sobre lo que yo he visto que te piden cuando no tienes experiencia alguna y que lo que han de hacer es apostar por la persona, no exigir que desde el día uno sepa todo (nadie lo sabe todo).
Aún así, lo que más me ha costado con mucho es el ver que cada uno tiene sus tiempos y aprendemos de diferentes modos.
Una persona a la que aprecio me preguntó hace unos días si podía mentorizarle así que he aceptado, creo que aunque voy a tener a dos personas en paralelo voy a poder dedicarles el tiempo que merecen, si no, no lo haría. Vivo solo y no tengo cargas familiares, eso no puede decirlo todo el mundo, así que no nos olvidemos de este pequeño detalle, lo hago porque puedo.
Pregunté a en Twitter si alguien me podía dar consejos para mejorar.
Tweet: ⚡️ «¿Algún consejo o recurso sobre mentoring?»
Tengo la suerte de tener muchos conocidos súper majas y majos en el sector que no han dudado en responderme:
Cristina Grim
Al principio el apoyo sobre todo es moral, les surgen muchas dudas sobre su primer trabajo en el sector, entrevistas, currículum…
Luego es más un contacto profesional y si surge una relación de amistad, es diferente, con unas cañas se da todo el apoyo que necesitan
Les ayuda también bastante ir contigo a eventos para introducirse en el sector conocer a más gente, etc, etc
Daniel Primo
Hola! Tengo experiencias intermitentes de mi etapa de trabajo en empresa y de hace un año con un oyente que me lo pidió expresamente. Volveré a la carga en una semana menotirzando a otra persona. Ya no recuerdo si te escribí por esto, pero la mayor dificultad no fue la motivación sino “que me hicieran caso”. Tu dices “vete por aquí” y se despistan con cualquier tontería. Aquello del rabbit hole.
Jorge Barrachina
En mi caso fue con varios alumnos del máster, que hacen las prácticas conmigo:
Hay dos líneas de actuación: La puramente técnica, y la social.
Técnica:
- Lo primero para mí era identificar, que es lo que quiero transmitir que pueda ayudar a acelerar el progreso de la persona mentorizada.
- Para mí lo más importante es lo que lo motiva para que la persona aprenda, así que adapté lo que tenía que enseñar al ámbito de interés de cada alumno (por interés me refiero a campo de conocimiento, no lenguaje de programación ni nada específico).
- Si consigues despertar la curiosidad de la persona a la que mentorizas, todo irá luego mucho más rápido, porque con motivación se gana autonomía y autosuficiencia.
- ¿Qué temas le motivan? A partir de ahí busco que tecnología o herramientas les pueden venir bien.
Social:
- Trato de que tengan espíritu crítico, que no compren a la primera lo que parece que todo el mundo está usando o hablando de.
- Si consigues quitarle ruido de todo el tema de “frameworks”, o hype a tope, les ayudas más a ir centrándose en cumplir retos menos exigentes, y no se desbordan por todo lo que hay ahí fuera.
- En cuanto a hacer “pairing”, al principio si lo considero fundamental sobre todo, porque la gente a la que he mentorizado, no está acostumbrada a programar, y lo que hago es intentar que “cambien el chip” a la hora de cómo plantear un problema (descomponiéndolo en problemas pequeños), y siempre desde un punto de vista lógico. (La implementación es lo último).
- En la parte de implementación, siempre hacemos varias, y luego le explico pro’s y contras de hacer una u otra. Pero les dejo claro que al principio, es más importante que funcione que sea elegante. Eso ya lo irán interiorizando con la experiencia.
Meritxell Calvo
Ofrecemos distintos tipos de mentoring.
Asíncrona:
- Si es una mentoría asíncrona se abre un tablero de Trello donde se comparten recursos con los que el interesado puede avanzar a su ritmo, he duplicado uno de esos tableros para que puedas hacerte a la idea.
Evento:
Si es una mentoría en un evento, solemos recurrir al pair programming y a las reviews como tu comentas. Yo llevo el Katayuno que organizamos de la siguiente forma:
- 8:00 hacemos parejas o tríos en los cuales siempre hay al menos un mentor fijo o rotando.
- 8:00-9:00 trabajamos en una Kata.
- 9:30 presentamos nuestro ejercicio a los demás en el proyector, explicando nuestras decisiones etc.
Grupo:
- Cuando es una mentoría de grupo, por ejemplo durante los cursos de la Devscola., intentamos que se forme una mentalidad de aprendizaje en equipo. Aunque cada una tiene su Trello con sus recursos, el grupo en conjunto tiene un objetivo (un proyecto real).
Alberto Fortes
En mi caso:
- Code Review siempre. Hacérselos y que ellos te lo hagan.
- Tareas fáciles y pairing. Las haces juntos o se los dejas mascado para que terminen, etc.
- Explicarles bien dónde buscar y como la documentación (que si no la hay cm es nuestro caso) enseñarles como leer el código que es la documentación.
- Tickets dónde das instrucciones muy precisas tanto de que quieren hacer. Y cómo hacerlo (nivel código: coge este fichero el método tal y tal y tal qué no pierdan más tiempo del necesario buscando como se hace algo porque al no haber documentación se pierde mucho)
- Enseñarles como trabajan otros compañeros, quien te puede ayudar para según que cosa, quien tiene alguna manía que mejor saberla ;).
- En los Code Review sobre todo, decirles porque nos gusta hacer tal o cual cosa de una manera determinada y forzarles a hacerla así pero siempre tratando de argumentarlo y que comprendan el por qué.
- Y dejando de hacer código y estando en cambio dispuesto y libre para ayudar. En mi caso al principio me costó porque prefiero picar código que estar de call en call rollo mentoring.
- Ah y muy importante, si eres tech lead, que todo ticket asignado a tu equipo pase antes por ti. Para detectar duplicados, tareas contradictorias o erróneas, decidir si dicha tarea es o no adecuada para tal persona o falta coherencia o instrucciones etc.
Jesús María Villar
Yo en mi curro soy Teach Lead aka Mentor, y también mentorizo a dos compis que quieren reciclarse a java desde tecnologías más antiguas con el objetivo de poder dejar sus respectivas empresas, mira te comento lo que suelo hacer.
Lo primero es lo primero, y es que cómo mentor, debes tener muy claro hacia dónde quieres mentorizar a tus compañeros. Yo por ejemplo, considero que lo que todo desarrollador de calidad debe tener es lo siguiente:
- Principios SOLID.
- TDD.
- BDD.
- Automatización de pruebas.
Si te fijas, son conceptos totalmente agnósticos de la tecnología que implementes (a no ser que trabajes con COBOL o cosas así que lo dudo).
En mi empresa actual, detecté lagunas en cuanto a todo eso (sin ir más lejos no habían hecho TDD en la vida) así que empecé a meterles el veneno haciendo mucho pair programming (es lo que tu dices, no debemos ser meros profesores, yo soy un desarrollador más del equipo).
Para mi el Pair Programming es básico, tras tres semanas ya veía como ellos mismos hacián pairing entre ellos. Yo empecé haciendo pairing con el equipo entero de la siguiente forma. Escribía un test y pedía un voluntario para corregirlo, tomándome mi tiempo en explicar el por qué de TDD y todas las dudas.
Como detecté que los principios SOLID no estaban claros, les propuse hacer meetups internas cada final de Sprint, en la cual, cada miembro del equipo se preparase ejemplos según la letra que les hubiera caído. Para dar ejemplo, empecé yo con la S.
Como trabajamos con Scrum, los animé a revisar la guía Scrum, les di formación basándonos en detectar fake agile y eduqué a la persona que tenía el rol de PO y siempre en pairing, trato de ir un poco por delante, haciendo POC’s que se traducen luego en, primero formación y luego en herramientas para hacer un código de calidad, ahora estaba formando a los testers para que sepan automatizar pruebas con BDD (Selenium, Spock, Groovy y esas cosas).
Mi resumen de todo es, pair programming, mucho pairing, hasta que el equipo esté maduro y puedan ya hacer pairing entre ellos. TDD, SOLID, BDD y CI/CD, eso debería bastar para llevar a tus desarrolladores al lado bueno.
Twitter de Jesús María Villar.
Dani Latorre
Buenas! Pues lo he intentado en un par de ocasiones: Con @senpaidevs era un poco particular por ser grupal. Montamos una lista de temas que creíamos que eran importantes y pueden aportar a “cualquiera”. Íbamos improvisando sobre la marcha entre hacer charlas y ejercicios (Katas y un proyecto), además de recomendar lecturas y videos para comentarlos luego.
- TDD y testing.
- Git.
- Cultura devops.
- Metodología.
- Katas.
- Un proyecto.
Los ejercicios siempre en pairing, nadie trabajaba a solas.
En otra ocasión intenté echar un cable a una compañera a introducirse en la programación frontend/JavaScript. Salió un poco mal porque era en remoto y ni ella ni yo lo empujamos demasiado. Procuré darle un enfoque algo “agnóstico” empezando con temas de koans de JavaScript y Katas con JavaScript… Hasta que nos deshinchamos ambos; mi idea hubiera sido seguir con Vue (por ser el framework que venía utilizando) y hacer un proyecto como hilo conductor.
En ese caso al ser remoto la aproximación de code reviews asíncronos creo que nos hubieran facilitado. Pairear en remoto en mi experiencia es un poco más complicado.
¡Ah! Y una práctica que creo que puede ser interesante, si es una persona que trabaja ya en el sector, es utilizar código real. Ya sea de su curro o participar o hacer algo open source.
Lo de que sea del curro en el tiempo libre es un poco… meh, pero ayuda a llevar al día a día lo que se va aprendiendo (en temas de testing es un punto muy guay en mi opinión :))
Conclusiones
Estoy muy contento de ver a gente progresar y sentir que soy útil a alguien de ese modo, ojalá yo hubiese sabido aprovechar la mentoría de Alfredo.
Me queda muchísimo que aprender, pero para ayudar a la gente no tienes que llevar 20 años en el sector, siempre puedes encontrar alguien a quien le puedas aportar.
Espero que os sea de utilidad, es el artículo con mucho que más me ha costado escribir y del que hasta ahora más orgulloso me siento.
¿Eres mentor o te han mentorizado? Me encantaría saber sobre tu experiencia, seguro que puede ayudar a alguien.
