# 10 Cosas que aprendí como coach

Mi tiempo de *coach* se ha terminado y ahora da paso a la auto-reflexión, tan necesaria para no cometer los mismos errores. Algunos de ellos se dieron por atenerme al programa marcado desde regional, otros por mi propia falta de experiencia como *coach* y otro tanto por mi llegada tardía al programa que no me permitió detectar las necesidades a tiempo de corregir camino.

> **Nota:** Esto no significa que las estudiantes hayan salido con baja calidad del programa. Al final ellas sacan la garra, con nosotros, o sin nosotros. Si no que hubieran tenido un camino mucho menos tortuoso (el masoquismo no debe ser requisito para programar) y hubieran alcanzado a aprender unos cuantos acrónimos más (tan amados por RH en las entrevistas aunque No Posean Información de que significan).

## 0.- Acentuar la programación orientada a objetos durante todo el proceso

No tanto por su utilidad inmediata, si no por su capacidad de dividir datos de la representación de los mismos, paradigma que se repite en todas las arquitecturas desde tiempos inmemoriales y que seguirá repitiéndose en todos los *frameworks* de JS del futuro.

No hice esto tanto como hubiera querido (y el programa tampoco lo daba a entender), muchos de los ejercicios hubieran podido llevar esta filosofía, pequé de paternalista al no querer hacer nunca mi código más grande de lo estrictamente necesario para comunicar la idea principal.

## 1.- Introducir React y Vue desde que se aprende maquetado
En su forma más básica React y Vue son sistemas de plantillas, que además pueden entenderse desde la filosofía de programación orientada a objetos.

No es necesario comenzar con una gran explicación de todo el ciclo de vida estas bibliotecas, con solo dividir tu interfase en pedazos que guardas en archivos independientes y potencialmente reutilizables, ¡Boom! ya entendiste los primeros conceptos de React y Vue.

En la mayoría de los trabajos de *Front-End Junior* no comienzas haciendo grandes sistemas, si no maquetando aquello a lo que un senior le pondrá funcionalidad. Por lo que incluso con el limitado tiempo del *bootcamp* las estudiantes podrían tener bien practicado ese *skill* al final de su formación.

## 2.- Jamás cortar las asesorías 1:1
Siempre en todo grupo hay estudiantes que no hacen *match* con el modo en que diste la clase general y necesitaran que te sientes con ellas a explicar el tema de formas alternativas. Los métodos de enseñanza son casi infinitos pero es necesario pasar tiempo con cada estudiante para encontrar lo que le sirve.

En mi caso comencé dichas asesorías, pero cuando se dio mi cambio a medio tiempo tuve que dejar de ofrecerlas (esto también se debió haber comunicado, muchas estudiantes pensaron que las deje de dar por flojera).

> En este mismo sentido también hubo muchas estudiantes que no se acercaron lo suficiente para llegar a ese *match*, sirva este documento para que ellas también sepan que es necesario perderle el miedo a sus *Tech Leads*, ellos y ellas son su acceso al conocimiento (te caiga bien o mal, en el trabajo eso es irrelevante)

## 3.- Dividir el salón para los talleres
En las clases de teoría es muy fácil tener 30, 50, 100 estudiantes, pero en los talleres no es la misma atención que se le puede dar a 10 estudiantes que a 30.

Esto significa que tendrás que dar el mismo taller 2-3 veces, pero a cambio puedes ayudar a cada estudiante individualmente y que quien no entiende bien en la primera ronda, se anote puede anotar a la segunda o tercera.

Estos talleres se comenzaron a dar en las tardes, pero también se cortaron en mi cambio a medio tiempo.

## 4.- Dejar de ser paternalista
Cuando las clases son en secundaria y preparatoria puedes asumir que tu publico no tiene gran madurez, pero en el caso de la educación para adultas todas son... adultas. Muchas de esas personas serán incluso mayores que tú, la gran mayoría ya tiene experiencias laboral e incluso algunas la tienen dando clases. De manera que el conocimiento no puede ser dado desde un imaginario podio, si no como iguales, de esa forma el aprendizaje fluye en dos vías.

Está filosofía debe además extenderse en todos los temas, si desde el punto de vista técnico (donde sí que somos especialistas y hablamos con total autoridad) les invitamos a retarnos y contradecirnos, con más razón se debe de hacer para el resto de los temas donde ellas ya tienen experiencia.

## 5.- Entrevistas técnicas a lo largo del camino
Muy al final del *bootcamp* se realizaron entrevistas de código que nos dieron gran luz sobre las carencias y fortalezas de las estudiantes, gracias a ellas se tomaron medidas para corregir el ritmo del *bootcamp*.

Es común que en trabajos en equipo e incluso en los individuales (pero que al estar en una cultura de colaboración te apoyas con otras personas) se escondan las necesidades de las estudiantes. Pero eso no se puede esconder en una entrevista de código, 30 minutos entrevistando a cada estudiante mensualmente puede significar la diferencia entre que muera de frustración o que sobresalga en el programa.

## 6.- No disponer el tiempo de todo el grupo
Las organizaciones tenemos la tendencia a disponer del tiempo de todos y todas, así sea para tirarle una pedrada a una sola persona o para dar anuncios que bien podrían haber sido un *email*. Educativamente no nos quedamos tan atrás, de dientes para afuera queremos que todo sea basado en proyectos, pero constantemente robamos tiempo de proyecto para clases. Ya hacía el final comencé a adoptar la posición dar clase a quien lo quisiera y estuviera, y de ser necesario repetir la clase a quien no la haya tomado, los grupos más pequeños siento que funcionaron bien.

Que como lo mencione en el punto #2, no necesariamente es malo.

## 7.- Usar Linux desde día cero
La cantidad de horas perdidas tratando de hacer que el *stack* funcionara bien en Windows fue un desperdicio (cosas tan básica como que la consola de varias herramientas no sirven en *git bash*), al principio no quise meter mano porque como también tenemos UX en el *bootcamp* no dejaba de tener la duda de sí habría alguna herramienta especializada solo para Windows. Al final no la hubo, a cambio sufrimos incompatibilidad y un sistema operativo horrible todo el *bootcamp*.

## 8.- Presentar juntos
Recibir clase de forma pasiva no solo es aburrido, también se presta a que las estudiantes entren en modo zombie. Por lo que experimenté al final con la presentación como grupo de los temas, Preparando con ellas y llenando los huecos que las estudiantes pudieran llenar.

Eso las hizo investigar más a profundidad sus partes, las mantuvo despiertas en clase (porque ya casi les tocaba) y evitó que se aburrieran solo con mi voz.

*border-bottom*: Las clases que más disfruté dar y que creo las estudiantes disfrutaron tambien (y si no al menos fue divertido ver a todas terminando sus slides el domingo a las 10pm)

## 9.- La documentación oficial rulea
Muchas veces tenemos la tentación de replicar la información oficial para nuestros propios cursos, pero eso es un error total. Es dificil que esas replicas no transmiten correctamente la filosofía de los creadores (común con React por ejemplo), ya sea en traducciones o en supuestos ejemplos mejores que aquellos oficiales.

Ahora, no siempre la documentación oficial es buena, en esos casos debemos dejar que la gente aprenda a lidiar con mala documentación (y malas APIs, y malos IDEs, y malos lenguajes), el 80% del tiempo de programación es investigar y no debemos ser paternalistas con los materiales base, entre más rápido aprendas a navegar entre ese caos que es el Internet mejor.

# Epilogo
Educar desde la presunción de que estudiantes y equipo somos iguales, acercarse a los casos de trabajo reales, flexibilidad para las necesidades y capacidades de cada persona.

Hago esto de forma publica por respeto a mis ahora colegas, estamos en un proceso de mejora continua, y así como yo y la organización tenemos mucho que mejorar, ustedes vean también constantemente sus áreas de mejora.

Este documento ya lo tiene regional y varios de estos puntos están cubiertos en el nuevo programa, queda en ellos decidir que más incluir.

¿y ustedes, tienen alguna otra idea o aprendizaje?