Enseñar a programar, "desprogramar" y todo lo demás
Dentro de poco se celebra el Open Space de ‘Enseñar a programar’ en Valencia y estuve preparando una sesión sobre algunas reflexiones tras escuchar el título del Open Space.
Aunque finalmente no voy a poder acudir, voy a recoger las ideas por aquí, porque me gustaría dejar constancia de lo que pienso ahora mismo y revisarlo con los años para ver si sigo convencida de las mismas cosas o algo ha cambiado, ya que no dejamos de aprender continuamente, de vivir experiencias, de conocer las de otros y todo nos influye.
¿Qué se entiende por “enseñar a programar”? Nunca he enseñado a alguien desde cero, ni mentorizado a alguien que está aprendiendo. ¿Qué enseñaría a alguien que empieza desde cero? ¿Qué es lo que más me ha resultado útil a mí? ¿Por dónde empezaría? ¿Sería suficiente con “enseñar a programar”?
Después de darle muchas vueltas, ya tenía una propuesta de título para la sesión: enseñar a programar, “desprogramar” y todo lo demás ;)
Enseñar a programar
En algunos centros de formación comienzan enseñando a programar en algún lenguaje de programación. O bien, enseñan a manejarse en un stack determinado.
¿Empezaría por ahí? Conociendo mi humilde experiencia, creo que no.
¿Por qué? Porque me gustaría enseñar a programar de forma agnóstica sin estar atada a ningún lenguaje de programación.
Me gustaría proporcionar cierta base que permita a la persona situar lo que está aprendiendo y poder encajar otras piezas de puzzle más adelante.
No me gustaría “dar forma” a un “doer”: a una persona que simplemente programa lo que otros le piden que programe.
¿Por dónde empezaría?
Por una breve historia de los paradigmas y lenguajes de programación, así como algunas de las características más relevantes, ventajas, desventajas, …
Después indicaría qué dos lenguajes de programación aprenderían. ¿Dos? Sí, porque si se aprende únicamente uno, se corre el riesgo de no atreverse a aprender ningún otro lenguaje, encontrar la zona de comfort y no atreverse a salir de ahí.
Pero antes de empezar a programar en esos lenguajes, enseñaría a programar en un pseudolenguaje.
Y cuando pienso en enseñar a programar realmente estoy pensando en:
- Enseñar conceptos, estructuras de datos, estructuras de control, …
- Enseñar a pensar: cómo hacer uso de todo lo anterior para dar solución a determinados problemas.
- Enseñar a comunicar de forma sencilla mediante el código (por no decir código limpio… vaya, ya lo he dicho).
- Enseñar ciertos principios de diseño que debemos perseguir. Detrás de la mayoría de los principios de diseño y arquitecturas, hay ciertos elementos comunes que deberían guiar nuestras decisiones de diseño.
Es cierto que la mayoría de todo eso se podría enseñar con un lenguaje de programación real, pero me gustaría no “acoplar” la enseñanza de programar con un lenguaje de programación en particular.
Y siempre tendría en cuenta código productivo y código de test para que de forma natural aprendan a no desvincularlos, o bien, a entender que programar no sólo se refiere al código productivo.
Enseñar a “desprogramar”
Con esa palabra tan rara (y que me perdone la RAE) quiero comunicar que no sólo se trata de programar, escribir, crear, sino que también hay que aprender a:
- Leer código de otros: puede parecer una tontería, pero es algo que convendría enseñar o acostumbrar. Mostrar piezas de código y descubrir cuál es su cometido.
- Eliminar código: aunque aún existen personas que no lo creen así, se puede ser muy productivo borrando código.
- Cambiar código: aquí entraría lo relativo a mejorar el código (no quiero decir refactorizar… vaya, ya lo he dicho). El punto anterior también entraría aquí, pero he querido ponerlo separado para darle más énfasis.
Y todo lo demás
¿Qué es todo lo demás?
- Antes de comenzar a enseñar nada, comentaría ciertas pautas a seguir para enfrentarse a todo el aprendizaje. Esto incluye la importancia de mantener la vida personal, descansos, motivación, etc. Todo aprendizaje tiene un proceso de asimilación que no hay que acelerar, sino disfrutar.
- Un repaso por las diferentes metodologías de desarrollo.
- Prácticas de XP.
- Herramientas del entorno de desarrollo: control de versiones (también se puede hacer una introducción agnóstica a una herramienta en concreto), editores, IDEs, contenedores, etc.
- Recordar que hay cosas que sólo se aprenden o asimilan a través de la experiencia.
- Recordar que los “aha moments” son muy amigos de los momentos en los que se comparte algún conocimiento (charla, post, mesa redonda, conversación, …).
- Motivación para no sentirse en ningún momento inferiores a aquellos que lleven más tiempo en esta profesión o que comenzaron a programar de pequeños. Los que lleven más tiempo puede que sufran “cegueras” (aquí me incluyo) que pueden arreglarse con las ideas que aporten las nuevas incorporaciones. Y ante todo que no se comparen nunca.
Y creo que me dejo lo más importante para el final: rodearse de buena gente de la que aprender, ya que el aprendizaje no tiene fin.
Otros enfoques
Después de estas reflexiones, me doy cuenta de que le podría haber dado otros enfoques diferentes:
-
Cómo enseñar a programar: hasta ahora sólo he incluido qué enseñaría, pero no cómo lo haría (plan, actividades, técnicas, recursos, etc).
-
Enseñar a programar mejor: he puesto el foco en personas que empiezan desde cero, pero ¿y las personas que ya programamos? Siempre hay cosas que podemos mejorar.