No platiques de una tecnología, cuenta la historia de lo que hiciste con esa tecnología.
Nunca nadie salió de una plática con suficiente información en la cabeza para escribir un programa con lo que aprendieron. Por razones prácticas las personas aprenden y siguen con la documentación mientras escriben software. No trates de enseñar a las personas lo que ya está en la documentación, cuentales una historia que los haga interesarse lo suficiente para seguir con esa tecnología.
Idealmente se responderían estas preguntas
- Qué es fácil
- Qué es difícil
- Qué es una pesadilla
- Qué trucos aprendiste
- De qué pieza de código estás orgulloso
A veces es complicado balancear. Si tu plática es de muy alto nivel, el público podría perderse con tus ejemplos. Si es muy básica, todos van a saber de qué hablas y perder la atención.
En ChelaJS intentamos que nuestras pláticas vayan a un nivel medio tanto de experiencia como de entendimiento del lenguaje. Es mejor que alguien llegue a su casa con curiosidad de lo que se perdió a que todos lleguen a su casa pensando que mejor hubieran visto los tutoriales en vez de asistir al meetup.
Casi siempre, abrir el editor y mostrar el código que hizo algo posible termina aburriendo al público. Primero, el público puede leer más rápido de lo que puedes explicar y si entienden tu código de sólo leerlo (lo cual es preocupante si no pasa) entonces puedes perder a la audiencia. Mejor elige los métodos o líneas de código que quieres explicar y presentalo diapositiva por diapositiva con los cambios que sean interesantes. Recuerda que finalmente una presentación es contar una historia.
A menos que tengas mucha mucha seguridad en los demos, mucho puede salir mal. Si estás muy seguro de que quieres un demo en vivo, practicalo muchas veces y no dependas de agentes externos como la red, o que los participantes ingresen con un browser soportado.
Tanto los eventos como la comunicación entre los miembros de la comunidad deben apegarse a lo establecido por el código de conducta.