Hay dos cosas importantes que hay que saber sobre aprender a codificar:

1. La mayoría de la gente en realidad no quiere «aprender a codificar»
2. Aprender a codificar ya no significa una cosa

Es importante saber estas dos cosas porque si no la forma en que enseñamos a la gente sobre la codificación es incorrecta, y la gente no aprenderá.

El primer punto lo he visto una y otra vez. La gente que me dice que va a aprender a codificar, luego empiezan a aprender, y piensan que es aburridísimo.

Lo llamo la falacia de la codificación. La gente cree que quiere aprender a codificar pero lo que realmente quiere hacer es construir un producto.

Cuando lo pensamos, esto debería ser bastante obvio. El conocimiento del código en sí mismo no es valioso si no puedes hacer nada con él. Así que para la mayoría de la gente, la mayor motivación para aprender a codificar es construir algo (aunque un cercano segundo lugar es conseguir un trabajo mejor pagado).

Eso me lleva al punto número dos. Aprender a codificar ya no significa lo mismo.

Antes, para codificar había que saber casi todo sobre ordenadores (de ahí el término «Informática»). Luego las cosas se fueron abstrayendo hasta el punto de no tener que bucear en ciertos temas a menos que fuera realmente necesario. Por ejemplo, como desarrollador de aplicaciones web en este momento, necesito saber muy poco sobre la administración de sistemas porque la mayoría de las veces lo hacen por mí herramientas como Heroku y Amazon Web Services.

Así que cuando la gente dice que quiere aprender a codificar, la mayoría de los profesores empiezan por donde suponen que deben hacerlo (por donde siempre lo han hecho), con los tipos de datos, las distintas estructuras de un lenguaje, y ayudan a los estudiantes a desarrollar una comprensión más profunda de los ordenadores.

El problema es que eso no es lo que la gente quiere. Quieren construir algo. Y no deberíamos seguir dando por sentado que para construir algo hay que aprender todo sobre informática o incluso sobre codificación en general.

Por ejemplo, si alguien ya está trabajando con un gran desarrollador de back-end, tendría sentido enseñarle sólo el front-end, porque eso va a ser lo más útil para él. De hecho, conseguirán lo que quieren hacer más rápido, y podrán aprender el back-end en un momento posterior. Con ello reducimos la carga cognitiva del alumno y le permitimos aprender más rápido.

Cuando desarrollas para la web tienes que lidiar específicamente con:

• HTML
• CSS
• JavaScript
• Programación de Back-end
• Bases de datos
• Hosting/DNS

Aquí hay mucho que aprender. Y la mayor parte es bastante irrelevante para el desarrollo no web (excepto las bases de datos y la estructura de la aplicación, obviamente).

La forma en que lo veo, la mayoría de la educación de codificación implica un cebo y cambio. Va así:

Estudiante: «Quiero aprender a codificar». (Pero lo que realmente -pero no saben lo suficiente como para preguntar- es que quiero construir una aplicación web o móvil.)

Profesor: «Bien, empecemos con los tipos de datos.»

Estudiante: «…»

(2 semanas después)

Profesor: «Ahora podemos diseñar algoritmos eficientes»

Estudiante: «¡Pero yo sólo quería hacer un sitio web que se viera bien!»

Como profesores, tenemos que reconocer que cuando la gente dice que quiere aprender a codificar, a menudo quieren decir realmente que quieren construir una aplicación web o móvil.

Eso es porque para ellos, eso es lo que es la codificación. Es todo lo que han visto sobre la codificación. ¡El problema es que no saben cómo pedirlo! Así que no deberíamos tomar todo lo que dicen al pie de la letra. Es nuestro trabajo como educadores leer entre líneas.

Recuerdo que hace unos años vi una obra de teatro en la que un sacerdote dice que hay que decir la verdad incluso en circunstancias difíciles. Su interlocutor le pregunta: «¿pero qué pasa si alguien te hace una pregunta y sabes que la verdad le va a hacer daño?». El sacerdote responde: «Cuando alguien te hace una pregunta, responde a la pregunta que realmente te está haciendo».

También en la educación hay que leer entre líneas para averiguar lo que la gente realmente quiere. Si preguntan algo específico, hay que guiar a la persona hacia lo que le va a llevar a su experiencia de aprendizaje ideal.

Así que nos corresponde a nosotros, como educadores y como expertos, guiar a la gente en la dirección correcta y no dejar que flote. Si podemos hacer esto, entonces podemos empoderar a mucha más gente para que haga cosas increíbles.

Como estudiante: aprende lo que quieres aprender.

Una de las mejores cosas que puedes hacer en tus propias aventuras de aprendizaje es aprender un poco sobre muchas cosas – así sabrás en qué quieres profundizar después.

Aquí en One Month, cuando decimos que puedes «aprender a codificar en 30 días» lo que queremos decir es que en sólo 30 días puedes aprender lo suficiente de HTML (JavaScript o Python) para ser conversacional en el código, con la suficiente confianza para que puedas destacar en el mercado de trabajo.

¿Entonces cuánto tiempo se tarda en aprender a codificar?

Nos llamamos «One Month», ¿eso significa que después de 30 días de codificación nuestros estudiantes han terminado de aprender? En absoluto. He estado codificando durante más de 15 años y todavía hay muchas cosas que no sé – pero ese no es el punto. «Aprender a codificar» no consiste en saber todas las cosas del lenguaje, sino en saber lo suficiente para poder conversar y dejar una huella en el mundo usando tu mente, y tus habilidades creativas.