Como en un iceberg

Lo que se ve es solo una pequeña parte del total. 90% del iceberg yace debajo del agua.

El código fuente final luce de cierta manera. Pero no se llega directamente a él. En la resolución de un problema, hay muchos esbozos, intentos de diversas aproximaciones, hasta ir descubriendo la solución. Recién una vez encontrada, se va optimizando hasta llegar a la versión final.

Todos esos pasos previos, y el andamiaje necesario, es lo que no se ve. E igual que en el iceberg, aquello que vemos no sería posible sin lo que no se ve.

Si intentas trabajar queriendo lograr directamente la versión final, te llevarás un chasco. Es como querer llegar al décimo escalón de un brinco. Te puedes ir de nariz. O a lo mejor lo logras, pero quizás seas un atleta olímpico. Es mejor subir paso a paso cada escalón hasta llegar al décimo.

Aceptado eso, suena fácil. Si no fuera por la cultura que juega en contra. Hay muchas cosas del colegio y la familia en contra de fallar. Quién sabe por qué, porque cuando resuelves problemas te das cuenta que fallar es parte natural del proceso de solución.

Así que, cuando intentas resolver un problema paso a paso, de rato en rato aparecerá esa voz (tuya, de tu compañero, o de tu jefe), diciendo: "Ya estás cerca, qué tal si brincamos unos escalones, sería genial". No. No y no. Cada paso brinda información. Brincarse los pasos es renunciar a eso.

Parece que es una tentación común en alguien que empieza a conocer un tema el subestimar el valor de la experiencia. Puedes aprender algo en un día, pero hasta que no hayas hecho el ejercicio diez veces, yo diría que aún no habrás conocido aquellas cosas que solo la experiencia te da.

Aprendes un algoritmo. Ok. Aplícalo en diez casos distintos. Aprendes a usar un framework. Ok. Haz diez proyectos diferentes. Intenta hacer a tu modo diez cosas interesantes que veas por allí. Atiende diez pedidos de tus clientes. De cada diez intentos, nueve no salen tan bien como esperabas. A partir de allí, yo diría que ya aprendiste eso.

Introducción

Pintar un cuadro. Escribir una historia. Hacer una casa.

Un cuadro. Una historia. Una casa.

Alguien ve la obra terminada e imagina a grandes rasgos cómo se pudo producir.

Pero si intenta producirlas con esos procedimientos imaginados, pronto se dará cuenta que la realidad puede ser muy diferente.

Por ejemplo, en el caso del cuadro. Como público podemos acercarnos y ver que las formas, luces y profundidad son producidas por aplicaciones de pintura. Algo relativamente fácil de comprender. Entonces, vas a la tienda y compras acrílico y un lienzo para intentar hacer algo parecido. Luego, después de mucho intentarlo en tu casa, vas descubriendo que no es tan fácil como parecía.

Del mismo modo con una historia. Están hechas de palabras. Sabemos escribir. Pero si intentas escribir un cuento, vas descubriendo que no es tan fácil decir algo interesante.

Y también con una casa. Puede ser ladrillo sobre ladrillo, o tabla junto a tabla. También yeso, cemento o pintura. Podemos conseguir esas cosas. Pero cuando intentas levantar la primera pared descubres que no es tan sencillo.

Y es que todas esas cosas, en realidad, se construyen gradualmente. Inician con garabatos, bocetos, maquetas. Se hace armazones y se aplican capas de trabajo sobre capas de trabajo. Se usan máscaras, apuntes, tablas, andamios y otros apoyos. Hay un montón de cosas que el público jamás ve.

Lo que el público ve es el resultado, la obra. Lo que el público no ve es la técnica que produjo la obra.

Para aprender esas técnicas, puedes tardar vidas enteras probando por tu cuenta, o puedes apoyarte en una comunidad que te facilite ese conocimiento. Puedes encontrarla en libros, en institutos o universidades, y en comunidades profesionales.

Y lo mismo es para programar. Como estudiantes de programación, aprendemos la sintaxis de algunos lenguajes, resolvemos varios problemas y aprobamos el curso. Luego, vamos a la galería y vemos las aplicaciones que allí se ofrecen. Es relativamente fácil suponer que se hacen con código similar al que aprendimos. Entonces, vamos a la tienda, nos conseguimos unos libros sobre el tema e intentamos hacerlo. Trabajando en ello, nos damos cuenta de que no es tan fácil como parece.

También aquí, lo que vemos es la obra. Lo que no vemos es la técnica para producir esa aplicación.

Hay muchos lugares donde enseñan programación pero, por alguna razón, pocos donde aprender técnicas para construir programas. Es en el trabajo donde solemos aprender esas cosas. Por prueba y error. O conectándonos a una comunidad con quien compartir experiencias.

Me parece que las analogías de la programación con el mundo de la pintura, la literatura o la construcción, suelen dar una perspectiva interesante sobre las cosas que hacemos.

Por ejemplo, hay gente que intenta programar de modo que a cada instante el código que produce sea el más óptimo posible. Es como alguien que intenta hacer un retrato directamente en limpio. Ojos perfectos. Nariz perfecta. Barbilla. Cara. Cabellos. Entonces, da un paso atrás y se da cuenta de que el conjunto está descuadrado. Que cada una de esas cosas perfectas no está en el lugar ni en la proporción que debería. Es mejor hacer bosquejos primero, maquetas que determinen la estructura general, asegurar primero la base y luego recién ir a los detalles.

Hay gente que programa muy bien, pero no sabe construir programas. Así, se frustra produciendo cosas que no están a la altura de sus habilidades. A veces creyendo que es por culpa del lenguaje que usa, o el framework, o el IDE. Es como alguien que sabe cómo mezclar pintura y obtener cualquier tono. Puede que hasta sepa composición. Pero eso no es suficiente para lograr que la escena se vuelva realidad. Para hacer un programa se necesita más que saber programar. Se necesita conocer técnicas para construir programas.

En el mundo, un porcentaje significativo de los proyectos de software fracasa, incluso los que no tienen retos tecnológicos. Mucho tiene que ver la manera como se organiza la gente. Pero yo creo que también tiene que ver con lo que la gente imagina que hay que hacer. Hay mucha gente por ahí, tratando de construir edificios de software, esmerándose en encontrar la perfección en lenguajes y herramientas. Pero, en realidad, son las técnicas las que determinan lo que son capaces de hacer.

Ojalá podamos compartir aquí las técnicas que vamos aprendiendo. Gracias.