Hoy en día, todo el mundo quiere aprender a programar y quiere hacerlo muy deprisa. De hecho hay series de libros que prometen enseñarte a programar en 21 días e incluso en ¡24 horas! También hay cursos, que prometen convertirte de la nada en un “full stack” (sea lo que sea) en 4 semanas.
Si quieres aprender a programar, es difícil resistirse a esos cantos de sirena, ya que dicen precisamente lo que quieres oír.
No obstante, si lo piensas un poco, la falacia, por no decir el engaño resulta evidente. En este artículo veremos cómo aprender a programar, cómo lo he hecho yo, cuánto se tarda (de verdad), cómo optimizar tu esfuerzo y lo más importante de todo: ¿por qué demonios hacerlo? Vamos, una serie de cosas que me hubiera gustado saber antes de empezar a programar.
¿Cuánto se tarda en aprender a programar?
«Bad programming is easy. Idiots can learn it in 21 days, even if they are dummies.»
Mathias Felleisen, Shriram Krisnamurthi et al How to Design Programs
Mathias y Shriram, autores de algunos de los mejores libros de programación del mercado y con décadas de experiencia enseñando en las mejores universidades de USA, lo dejan meridianamente claro y no tienen pelos en la lengua. Por una vez, y sin que sirva de precedente, seré yo el comedido y políticamente correcto. Lo explicaré mediante una analogía.
Supongamos que la furia del momento fuese por aprender a pintar, y no programar. ¿Cuánto tiempo tardarías en aprender los siguientes conceptos:
- Tipos de pinceles y sus propiedades
- Tipos de pinturas (oleo, acuarela, etc), sus propiedades y diferencias
- Lienzos y papeles
Yo diría que 24 horas es más que suficiente; sin embargo, al terminar seguirás sin ser un pintor.
La adoración de la herramienta
Tú y yo sabemos manejar un bolígrafo sin ninguna dificultad. Llevamos décadas haciéndolo y la herramienta en sí no tiene ningún secreto para nosotros. Sin embargo, ¿te crees capaz de pintar con uno, como hace este artista?
Pintar es algo totalmente distinto del manejo de la herramienta. Es más, el que sabe pintar, puede usar cualquier herramienta.
¡Van Gogh creó sus obras maestras si tocar un pincel: usaba una espátula que otros sólo utilizaban para mezclar los pigmentos!
Aunque aprender a manejar una herramienta concreta sea sencillo, la triste realidad es que el dicho sigue siendo válido: lo que importa es el mago y no la varita.
Programar tampoco es usar una herramienta
Al igual que con la pintura, programar es algo diferente del manejo de unas cuantas herramientas. De la misma manera, aprender a manejarlas no te acercará ni un milímetro a ser un programador y limitarse a ello es malgastar tu tiempo y dinero.
Hagamos un experimento usando de nuevo una analogía. Mira este video que promete que en 15 minutos cualquiera puede convertirse en un dibujante. Esta es básicamente la misma promesa que otros hacen respecto a la programación.
Sigue alguno de sus ejemplos y ahora dime si te consideras un dibujante de cómics. ¿Podrías empezar una carrera, aunque de forma muy humilde, como dibujante? Va a ser que no.
Podrás repetir los ejemplos que te dieron y replicarlos. No obstante, cuando te encuentres con un lienzo vacío y encargado de crear algo levemente diferente, no sabrás ni por dónde empezar.
Este pánico frente el lienzo vacío es algo muy común entre los que han aprendido alguna herramienta y no a programar.
Has sido programado
Sin embargo, el ejercicio no ha sido en vano. No has aprendido a dibujar, pero has aprendido a ser programado. No eres un dibujante, pero te has convertido en un ordenador. Es decir, has sido capaz de seguir a rajatabla una serie de instrucciones sencillas, sin necesidad de entender nada y sin saber su objetivo final. Aun así, has permitido que el dibujante crease un personaje de cómic.
Eres una varita decente, pero no podrías estar más lejos de ser Dr Strange.
¿Por qué es falso decir que vas a programar en 24 h, 21 dias o 4 semanas?
Ahora ya podemos entender mejor por qué es una falacia decir que alguien va a aprender a programar en 24h, 21 días o 9 semanas.
Hay dos razones, una de ellas de sentido común y que no hace falta leerse este artículo para entenderlo.
Namber gúan: Hay una demanda brutal e insatisfecha de programadores en el mercado. Los sueldos son muy altos y no hay paro. Si convertirse en programador fuese algo rápido y trivial, todo el mundo ya lo habría hecho, y el paro estaría lleno de programadores.
Namber chú: Lo que esos libros y cursos enseñan, NO es a programar, sino a usar algunas de las herramientas de un programador (algún lenguaje, un ide, git y poco más). Eso sí que es fácil, pero hemos visto que no nos lleva a ningún lado. El mercado paga por Stephen Strange, no por una varita.
Ya sabemos que no se puede aprender a programar en 3 dias, ni es trivial hacerlo, ni es aprenderse unas cuantas herramientas. Entonces, ¿qué es programar exactamente, cómo lo puedo hacer, en cuanto tiempo, y sobre todo por qué hacerlo?
Son buenas preguntas que merecen ser respondidas.
¿Qué es programar?
Programar es la ciencia y el arte de resolver problemas de forma eficaz y sistemática. (punto)
Para hacernos una idea mejor, lo ideal es otra analogía. A menudo cuando a un programador le preguntas con qué ordenador empezó a programar, te contestará (según la edad): con un ZX-Spectrum, un MSX, un 286, un Amiga, etc… y no dejará de hablar hasta pasadas algunas horas.
Mi primer ordenador: Gregorio
En mi caso, mi primer ordenador fue Gregorio. Gregorio era el portero del piso de mis padres hace eras geológicas. Tenía una serie de características que le hacían peculiar:
- Muy dedicado y concienzudo en su trabajo
- Muy laborioso
- Menos luces que Hodor.
A menudo se quejaba de lo que le dolían las manos por la artrosis y la psoriasis así como de la “pedorrera” (piorrea) que tenía en la boca (sic).
Todos los días, recorría todas las plantas del edificio, recogiendo las bolsas de basura que dejaban los vecinos, para luego dejarlas en la acera donde pasaba el camión de la basura. Empezaba en la última e iba bajando en el ascensor, de una en una de forma metódica y sin fallos.
Pues bien, para facilitar su tarea y ayudar un poco con lo de la artrosis (la psoriasis y la “pedorrera” no tenían mucho arreglo), compré una cubo de basura que le facilitase el trabajo y no le obligase a recoger directamente la bolsa. Lo dejé en el descansillo con la bolsa de la basura dentro y salí a por churros para el desayuno.
Cual no sería mi sorpresa, cuando a la vuelta me encuentro el cubo (con la bolsa dentro) tirado en la acera a la espera del camión del ayuntamiento. Gregorio dió por hecho que todo lo que quedaba depositado en el descansillo era basura y debía de ser retirado.
Asombrado por su falta total de cacumen, recuperé el cubo, lo dejé de nuevo en el descansillo y tomé una nota mental de explicarle el uso de un cubo de la basura la próxima vez que me lo encontrase.
Tontuna tal vez, pero dejadez ¡jamás!
Lamentablemente, Gregorio era un profesional muy dedicado y como hacía siempre, volvió a darle un repaso a todos los pisos, por si alguien había dejado más basura. Al llegar al 12 se llevó una pequeña sorpresa:
- ¡Anda, pero si han vuelto a tirar otro exactamente igual!
De inmediato procedió a tirarlo y ya no tuvo arreglo, porque el camión del ayuntamiento se lo llevó.
¡¿Cómo iba yo a pensar?!
Al dia siguiente me lo encontré al volver de la facultad:
- Gregorio, la primera vez, pasa, pero la segunda ¡no tienes perdón de Dios!
Asombrado abrió los brazos y me dió la clave: ¿¡Cómo iba yo a pensar!?
Fue entonces que entendí dos cosas vitales:
- Si dispones de un tonto fiable y una lista de instrucciones suficientemente precisas, puedes programar y resolver cualquier problema
- Hay gente que no ha nacido para pensar, pero que puede ser programada.
Programar a Gregorio
Vamos a pensar un poco cómo sería el código para programar a Gregorio para que saque la basura.
Tienen que ser instrucciones muy sencillas para que Gregorio no se aturulle y a la vez muy exhaustivas, para que no tenga que pensar. Además, deberían de describir un proceso rápido, que no malgaste innecesariamente el tiempo de Gregorio. Pues bien, estas son las 3 características de todo buen programa.
La primera versión de nuestro programa tendría esta pinta:
1 Baja en ascensor desde la última planta a la primera
2 Si es la primera planta, saca todo lo que tengas en el ascensor a la calle
3 Sino, recoge todo y mételo en el ascensor y sigue bajando
Selección, Repetición y Secuencia: la Santísima Trinidad del Código
La línea 1 define una repetición, una serie de instrucciones que se deben de repetir un cierto número de veces.
Las líneas 2 y 3 definen una selección, según un cierta condición (en la planta en que estés) se toman unas u otras decisiones.
El conjunto de las líneas 1, 2 y 3 forma una secuencia de instrucciones que hay que seguir una detrás de otra.
Pues bien, secuencia, selección y repetición son los 3 únicos elementos necesarios para crear un programa. Todos os programas del mundo, independientemente de su complejidad están hechos de esos 3 elementos, independientemente del lenguaje que sea.
Fallos en el código
Habíamos dicho que el código tenía que ser sencillo, exhaustivo y eficaz. La primera y segunda condición se cumplen. Son frases sencillas y no malgastamos el tiempo de Gregorio diciéndole recoja los pisos pares primero y luego los impares. Además, habría que explicarle lo que son pisos pares…
Ahora bien, ¿qué pasa con la regla segunda? ¿Es exhaustivo y correcto? Claramente, NO. La línea 3 no especifica que Gregorio debe de volver al ascensor después de meter la bolsa. Estamos hablando de Gregorio, ojo.
Tendríamos entonces que crear una segunda versión del programa:
1 Baja en ascensor desde la última planta a la primera 2 Si es la primera planta, saca todo lo que tengas en el ascensor a la calle 3 Sino, recoge todo y mételo en el ascensor, vuelve al ascensor y sigue bajando
¡Ahora si!
Alguien deja un cubo…
Gregorio podría estar años ejecutando este código sin ningún problema, hasta que algún idiota bienintencionado deja la bolsa dentro de un cubo. ¿Qué ocurriría? La linea 3 lo explica muy bien y ya sabemos que Gregorio no se salta sus instrucciones: recoge todo y lo tira.
A este fallo, se le llama un bug. El por qué de este extraño nombre es un detalle cómico perdido en los primordios de la historia de la computación, pero que se sale de este artículo.
Lo más importante, es entender que el programa en sí no es incorrecto. Las instrucciones NO están mal. Lo que ha cambiado es el contexto en el que se tienen que ejecutar. Algún idiota ha cambiado lo que deja en el descansillo y tenemos que actualizar nuestro programa para tener en cuenta algo nuevo.
Esto es particularmente interesante, porque demuestra que ningún programa está asegurado de que no vaya a fallar. Si cambia el contexto, todo se puede ir al garete.
Ten eso en cuenta la próxima vez que te subas a un avión o te hagas un TAC, y la experiencia será mucho más emocionante.
Para resolver esto, sólo tenemos que actualizar nuestro código:
1 Baja en ascensor desde la última planta a la primera
2 Si es la primera planta, saca todo lo que tengas
en el ascensor a la calle
3 Sino, recoge la bolsa. Si hay un cubo, saca la bolsa del cubo y métela en el ascensor. Deja el cubo donde estaba, so cenutrio, vuelve al ascensor y sigue bajando
Esta versión funcionará perfectamente hasta que un vecino se compre un tele gigante para ver Netflix y deje la caja en el descansillo. ¿Qué crees que hará Gregorio cuando se encuentre una caja de cartón?
Este constante modificar el código, consume buena parte del tiempo diario de un programador. A cada dos por tres, aparece algo nuevo en el contexto del programa que no habíamos tenido en cuenta, y toca actualizar. Otras veces, encontramos fallos reales, como no decirle a Gregorio que tenga la amabilidad de meterse de nuevo en el ascensor en vez de quedarse pasmado en el descansillo.
Este sencillo ejemplo muestra dos características esenciales de la programación:
Lo mejor de los ordenadores, es que hacen exactamente lo que les dices.
Lo peor de los ordenadores, es que hacen exactamente lo que les dices.
Con esto ya sabemos un poco en qué consiste programar. Sin embargo, seguimos sin respuesta para las siguientes preguntas:
- ¿Cuales son las habilidades que debemos de aprender para convertirnos en buenos programadores?
- ¿Cuánto se tarda?
- ¿Qué camino se debe de seguir?
En el próximo artículo veremos precisamente esto, basándome en mi experiencia de años enseñando a programar y en mis propias experiencias cuando estaba aprendiendo.
➡️Descarga temario – Full Stack Web Bootcamp
➡️Descarga temario – Full Stack Mobile Bootcamp
➡️Descarga temario – Full Stack DevOps Bootcamp
