De 0 a 100 en segundos, y de vuelta a 0 en meses.

La primera vez que en una terminal escribí algo como:

sudo gem install rails
...
rails new blog
...
cd blog
...
./script/server

Casi me meo en los pantalones de la emoción.

Mi primera sensación fue de estar frente a un cambio fundamental en la forma en que podía programar.

Viniendo de perl y cansado de tener batallas épicas con Fast-CGI y Apache, la simplicidad aparente de Rails me resultó irresistible, y me dejé atrapar.

En el medio pasaron años. Y ahora, a la distancia, si bien no lamento haberme pasado a Rails, me pregunto en retrospectiva si realmente fue una buena decisión.

Hay algo en esas cuatro líneas, que llevan de la nada a un servidor local andando, en las decenas de tutoriales y screencasts que te llevan ciegamente de la mano a implementar (porque, no jodamos, seguir un screencast y terminar con un CMS de juguete andando en tu máquina, eso no es programar –es otra cosa), en la abundancia de gemas y librerías que permiten empaquetar funcionalidades que muchas veces ni siquiera se entienden. Decía, hay algo en todo eso que me parece nocivo.

Cuando yo estaba en la escuela primaria, una secretaria nos dijo un día: “ustedes confunden libertad con libertinaje”. Y a mí eso me quedó grabado a fuego en la memoria.

Y es que me pregunto si uno debería usar una librería que resuelve un problema que uno no sabría cómo resolver sin ella.

Naturalmente, todos estamos de acuerdo en que no es necesario reinventar la rueda en cada proyecto. Pero creo (y veo) que hay una tendencia a no tener ni idea de cómo funciona la rueda que estamos usando.

Y esto no lo escribo desde ningún lugar de privilegio. He pasado muchas más horas de las que debería buscando errores incomprensibles en librerías enormes que he usado indiscriminadamente por el sólo hecho de que, siguiendo un tutorial de 10 minutos, me permitían implementar funcionalidades que no hubiera sabido cómo programar.

Lo voy a escribir de nuevo.

Muchas veces usé librerías sin saber cómo funcionaban y pagué muy caro creer que la estaba haciendo fácil cuando en realidad me la estaba complicando al cubo.

En algún momento hice un click. Para una idea que tenía para un proyecto, y pensando que necesitaba escribir un API que respondiera lo más rápido posible, descarté incluso Sinatra y probé Cuba. Y no hubo vuelta atrás.

Una cosa llevó a la otra, y actualmente esa idea de proyecto es un proyecto hecho y derecho. Al menos, así lo siento. Y es un proyecto para el cual fui buscando una a una las herramientas que necesitaba, que hicieran bien una sola cosa.

Consecuencia de eso, me puse a mirar el código de esas herramientas que empecé a usar. Y noté otro patrón, pero uno bueno.

Dejé de buscar tutoriales sobre “como hacer X” y empecé a encontrar respuestas en el mismo código de las librerías que estaba usando. (Imagínense hacer lo mismo con ActiveSupport)

Hay años luz de distancia entre que te digan cómo hacer algo y aprender a hacerlo por uno mismo. Seguro, uno no es perfecto y la forma en que se aprende puede no ser la mejor. Pero hay algo en el proceso de aprendizaje que no puede reemplazarse siguiendo tutoriales, y es la capacidad para entender cómo funcionan las cosas.

Es la diferencia entre ir a comer al patio de comidas de un shopping y aprender a cocinar. Seguramente al principio la oferta del patio de comidas sea más atractiva y en primera instancia la comida va a parecer mejor. Pero con el tiempo uno crece, cambia la idea de qué es mejor. Y un buen día, la hamburguesa del shopping tiene gusto raro, mientras que en tu casa podés hacer un guiso de lentejas decente.

Y pasaron más cosas. Me animé a colaborar, discretamente, en esas librerías. Pude agregar funcionalidades que yo necesitaba y que los autores encontraron útiles (o al menos, inofensivas).

En toda mi historia laboral he trabajado de áreas muy diversas. Algunas de ellas, relacionadas con la tecnología, y otras completamente alejadas de ella. Una constante que se mantiene es que siempre hay que usar la herramienta apropiada para el trabajo. Y cuando no se sabe qué herramienta es esa, se averigua, se prueba y se aprende.

Me tomó mucho tiempo darme cuenta de que Rails (en realidad, esto aplica a cualquier framework, supongo) y todo su ecosistema son las herramientas indicadas para un montón de casos, seguro.

Pero para otro montón, no lo son. Y llevados por la motivación (equivocada, creo yo) de “hacer que ande” terminamos copiando y pegando código que no escribimos, para usar librerías que no entendemos, en aplicaciones que, cuando andan, lo hacen por la inercia del trabajo de otros.

Yo, por lo pronto, prefiero volver a 0, entender las herramientas que tengo, escribir las que necesito y compartir con otros lo que sirva de todo eso.