- Sobre la preparación del tema
- Sobre los slides
- Sobre el código
- Sobre la etiqueta
- Coolabora con esta guía
Un tema que se toca en varias sesiones se recibe mejor como una historia.
Busca hacer un Outline de tus sesiones que reflejen un propósito principal y propósitos secundarios. Cada propósito secundario debe ser un milestone de claridad o enriquecimiento sobre el propósito principal.
El error más común del instructor es abarcar demasiado. El segundo es no detallar temas centrales lo suficiente. Un temario grande no es señal de calidad, generalmente es lo opuesto.
Una herramienta útil para llegar a lo esencial es:
- Crea un outline sin preocuparte por el scope.
- Deja que el outline marine en tu cabeza por al menos una noche.
- Sientate a leerlo y quita todo lo que no sea esencial para tu historia.
- Repite este proceso las veces que puedas.
Prepara tu tema con anticipación, rebotalo con personas dentro del equipo y busca contarles tu tema en una plática corta. Escuchar tu propio outline en un pitch de 15 minutos suele ser suficiente para identificar cambios tu mismo, cualquier agregado externo es un bonus.
Se muy receptivo al feedback y toma lo que veas necesario. Las opiniones son importantes pero el liderazgo del tema no es consensual, debe haber un autor claro.
Cada tema y subtema tienen un nivel de complejidad alto, pero en las sesiones suele tocarse unicamente la superficie o unos centimetros más.
No confíes en esto, es importante que tu conocimiento llegue a un nivel intermedio alto o avanzado sobre cada subtema. Las personas que están contigo suelen sorprenderte con su interés y te abren la oportunidad de enriquecerlas de maneras distintas en cada sesión.
Imaginarte que tienes [EL tiempo de la sesión] para preparar a tu hij@ o herman@ para su primera entrevista sobre [El tema de la sesión].
Véndete la situación hasta que se sienta real. Esto suele enfocarte en tocar lo esencial y asegurarte que las bases están lo suficientemente claras.
Estás en Hacker School porque lo que haces te apasiona. Busca volver a pinchar esa vena en cada sesión. Prepara ejemplos y demos que despertaron esa pasión en ti la primera vez y sorprende a tus alumnos frecuentemente.
Es complicado detectar el nivel de influencia que tienes en cada persona a corto plazo, pero cada esfuerzo en buscar despertar energía se multiplica y te la devuelve.
La mayor parte de los alumnos están más interesados en el resultado que en el proceso. Los slides son una buena manera de comunicar las posibilidades que se abren al ejecutar lo que aprenderán. Esto es un gran driver para mantener el interés aprendiendo herramientas nuevas y complicadas.
Cuando hables de arquitectura, de paso de mensajes y flujo de información, las gráficas son una gran manera de comunicarlo.
No es necesario que sea un diseño excelente (Aunque honestamente si ayuda) mientras refleje claramente la información necesaria.
En general usa solo live coding con un editor que resalte el lenguaje de programación con un font size grande. También prepara este font size para la terminal.
En lo posible prepara esto antes de la sesión.
Si debes usar código en slides los fondos oscuros evitan malas experiencias con proyectores viejos o demasiado sol. No te excedas en la cantidad de código. Si te ves en la presentación preguntando si se alcanza a leer, es un pointer de que el slide contiene demasiada información.
Sigue el guideline de Steve Jobs por default:
- 10 Slides
- 20 Minutos
- 30 Point Font
El resumen de esos pointers es: Usa poco texto en los slides pero ten buen contenido para platicar. Más de 20 minutos de slides por sesión no es necesariamente malo pero si es una bandera roja.
Cuando uses ejemplos para explicar simplifica exageradamente.
I.E. No construyas una aplicación para administrar una escuela construye un registro de alumnos.
Minimiza las ramificaciones de dudas no relevantes.
Un checkpoint es el punto intermedio entre tener nada y tener el ejemplo completo. Los checkpoints son útiles cuando te pierdes o copias mal una parte del live code. Organízalos en archivos (o folders cuando aplique) con el nombre de tu ejemplo y números. I.E.:
- student-registration-1
- student-registration-2
- student-registration-3
- student-registration-complete
En una sesión de 1 hora. Usa al menos 3 check points.
Aprovecha tus checkpoints para hacer demos parciales del avance. Los resultados parciales mantienen la motivación arriba. Es mejor equivocarse con hacer demasiados demos que demasiado pocos.
Busca que tu código sea claro y sencillo de seguir. Idealmente debe ser lo suficientemente claro como para que el grupo pueda clonar el repositorio, ver el readme y seguirlo sin tu ayuda. Sabemos que esta métrica es exigente pero es importante apuntar a ella.
La cualidad más importante de Hacker School es que todos estamos ahí porque queremos. Esto puede relajar lo suficiente a los alumnos y mentores para estar abiertos a errores y fallas. No dejemos que suceda, valoremos el tiempo, interes y pasión de cada persona.
La primera conexión está en llamar a tus alumnos por su nombre. En general nadie es bueno para acordarse de los nombres (aun). Utiliza esta oportunidad para hacerte bueno en ello.
Cada persona está en la sesión por algo en particular. Algunos lo hacen por puro crecimiento y compartir, otros porque tienen un side project, o son parte de una empresa que quieren mejorar, etc.
Cada persona tiene una historia y el valor de Hacker School está en compartirla y ayudar en las metas personales.
Para colaborar con esta guía por favor crea un Pull Request y un miembro del equipo la incluirá.