Cada domingo tu bandeja de entrada se llevará una alegría

LSN159

Dos cosas que no valen y 3 que sí para aprender a programar

Uno de mis propósitos del 2021 era aprender de los que están aprendiendo.

Este compromiso sí que lo he cumplido. Lo de aprender inglés, el gimnasio, ya si eso, tal...

🚀 Suscríbete gratis a La Selecta Newsletter

(Si lo que te interesa es tener los recursos seleccionados de cada semana, scroll hasta abajo).

He compartido 4 semanas de trabajo con una persona que no sabía programar.

Así dicho parece que tuviera la peste.

Para nada. Su nombre, en este relato de hoy, será Atanasio.

La cuestión es que llevo tanto tiempo sumergido en este mundo del software que temo que me pase como a los políticos: despegarme de la realidad y creer que todo el monte es orégano.

Oiga, no.

Estas cuatro semanas dan como fruto esta reflexión que hoy quiero compartir contigo.

¿Sabría enseñar a programar a alguien que no sabe y quiere aprender?

¡Uf! Qué pregunta más dura.

¿Te gusta recibir La Selecta Newsletter cada domingo?

Genial. Compártelo en twitter para que el gusto sea de muchos más. ¡Gracias!

Mal: Dar cosas por sabidas

No daré detalles de la vida del co-protagonista de esta historia, Atanasio, pero es importante saber que es una persona motivada, organizada, con sentido del humor y un trabajo que le deja pegado a la pantalla.

Con ese punto de partida me vine arriba.

Supuse cosas. Que sabría lo que era una "variable" o una "función". También que es intrínseco al conocimiento humano saber lo que es una "librería de JavaScript" o "el tiempo unix"

Erré en el tiro.

Los conceptos los interpretó de forma correcta porque es una persona ágil. Pero quedaron flotando en su mente despistándole del objetivo de la primera sesión: generar una fecha en la consola del navegador.

Bien: Trabajar sobre un proyecto

Sé que muchas personas prefieren un aprendizaje basado en un guión establecido y claro. De lo más sencillo a lo más complejo. Como en la escuela o en la universidad.

Resolvería el problema de los párrafos anteriores, pero generaría otro muy acusado en un plan tan corto como son 4 semanas: falta de acción.

Mi propuesta fue clara: dime un proyecto que tengas en mente y que pudiera venirte bien en tu vida cotidiana.

Presentó dos. Uno era un blog, así que descartado de inicio. El otro era una calculadora de fechas para asuntos laborales: ¡premio!

El foco para resolver el reto es más firme si quien se enfrenta a ello tiene una implicación personal.

Mal: Mostrar más de un camino

La comparación no es justa, pero esto podría ser como al ratón que aparece un laberinto y tiene que llegar al queso. ¿Qué camino elige? Imagino que donde huela más a queso.

A Atanasio le pasó como al ratón.

Le invité a seguir por 2 caminos diferentes como final de fiesta de las dos primeras sesiones.

No había queso al final, pero sí eligió el camino que olía más fuerte: el más fácil.

En una formación dirigida, aunque sea a la carta, me he dado cuenta del error que supone ofrecer varias opciones para avanzar.

Mejor te quedas con una y, si surgen dificultades, cosa que pasará, activa el comodín del email y pregúntame.

Bien: Dar por buena cualquier solución

Los programadores tendemos a ser reticentes, inconformistas y adictos a la perfección.

Enseguida sale de ojo dónde se pueden hacer mejoras. Quieres plantearlas ya, borrar ese código que tienes frente a ti.

Esta vez jugué esta baza a mi favor. Impliqué al tutorizado en la mejora continua del código. En base a dos cosas fundamentales en programación:

  • Poner nombre de las cosas.
  • No duplicar código.

La primera fue la excusa para explicar la diferencia entre el "snake_case" y el "camelCase" y la relevancia de nombrar a las cosas del software en inglés.

La segunda, vital para la experiencia del proceso: explicar para qué sirven las funciones, cuál es su estructura y por qué es muy sano saber utilizarlas.

Atanasio, de rebote, comprendió rápido en qué consistía la refactorización y dijo de forma espontánea: "Ahora esto se ve mucho mejor".

Pues sí. Y, además, calcula las fechas.

Mejor: Motivación y compromiso

Atanasio va a tener un gran futuro en el aprendizaje de la programación aunque ya tenga unos añitos.

Está motivado, no se ha venido a menos con las dificultades. Apoyé cada paso que dío en nuestras sesión semanal via Zoom porque tenía que refrendar ese esfuerzo.

Además se comprometió a cumplir el objetivo. Oculto estaba el sistema: tener un entregable pequeñito cada semana para ir avanzando y revisarlo en la sesión pesencial.

Recursos utilizados

Para esta mentorización hemos utilizado tres recursos princpalmente para tener "algo a lo que agarrarse".

Los cursos de Manz en castellano sobre JavaScript y CSS, la documentación oficial del Mozilla Developer Network y los contenidos de mi academia.

En cuanto a los recursos, usamos Visual Studio Code, LiveServer y Gist de Github para compartir el código (HTML, CSS y JS).

El penúltimo renglón

La pildorita malandriner de hoy la trae Santi.

These Modern Programming Languages Will Make You Suffer es un largo análisis de varios lenguajes de programación modernos (ReasonML, F#, Elm, Elixir...) desde varios puntos de control: velocidad, curva de aprendizaje, concurrencia, tipado... Completísimo.

¡Hasta el próximo domingo!