programar

En breve, voy a publicar en GitHub un proyecto en el que he ido trabajando desde hace un año y que da soporte a mi propia plataforma de publicación abierta (Hub de Libros). Se trata de un framework al que le he puesto el nombre de Mantra Framework, escrito en Node.js y que permite crear componentes altamente desacoplados para encarar proyectos grandes y que van a evolucionar mucho, tal y como describo con más detalle técnico en mi último libro (El Arte del Emprendedor Digital). Confío en basar en este framework muchos proyectos de aquí en adelante, al menos todos los basados en Node.

Tanto a un proyecto como al otro, le dedico todo el tiempo que puedo con la ayuda además de algunos colaboradores; en cualquier caso, analizando Mantra Framework, no me deja de sorprender la naturaleza de una actividad como es la programación, después de dedicarme a esto profesionalmente toda mi vida (en mis primeros escarceos tenía tan solo doce años).

Mi actividad profesional se reparte entre atender responsabilidades de desarrollo de negocio, tratar con clientes directamente, dirigir un equipo de desarrollo y también desarrollar y diseñar directamente proyectos como el anterior, además de todo lo relacionado con la publicación de mis libros (que, por el momento, son cinco técnicos y dos novelas).

Cualquiera que haya leído tan solo alguno de mis libros, sabrá que todo lo que hago está relacionado directamente con el desarrollo de software, más orientado a productos que a proyectos específicos y particulares para clientes, esto es, paso parte de mi tiempo programando, de ahí las siguientes reflexiones sobre el acto de programar y las sutilezas que esconde esta actividad y esta profesión.

Ciertamente, programar es una actividad poliédrica que se puede considerar sencilla, pero también puede ser muy compleja. Como suelo poner como ejemplo, no es lo mismo construir un chamizo que un rascacielos, como tampoco lo es construir algo pensando en que dure tan solo unas semanas a diferencia de que deba aguantar años. Y, sin embargo, paradójicamente, puedes tener éxito afrontado el software desde un lado y el otro, aunque el coste sea diferente, como veremos a continuación.

A menos que te lo propongas, cualquiera puede aprender en un videocurso de un fin de semana algunas nociones y comenzar a hacer cosas útiles, mientras que los más experimentados, no dejamos de tener nuevas percepciones y descubrir nuevos detalles que nos sorprenden en algo que llevamos haciendo años (“¡ah!, mira, nunca había reparado en esto o en las consecuencias de hacer esto otro de este modo, curioso…”)

Del mismo modo que un autor siempre escribe para contar algo que sea de utilidad a otros (entretenimiento, formación, cultura, crítica, opinión, etc), en esencia, programar consiste en resolver algún tipo de problema utilizando algún dispositivo para dar también utilidad a otros.

Esto es, salvo que programes por puro juego y divertimiento (como hago yo en ocasiones para experimentar), programamos para servir a los demás.

No importa de qué modo, en qué entornos, con qué lenguajes de programación, si dentro de una pequeña o gran empresa o como freelance, siempre programamos para ofrecerle algo a alguien. En mi opinión, esta es la actitud esencial que deberíamos tener los desarrolladores profesionales, cierta vocación de servicio de cara a nuestros clientes, usuarios de nuestros proyectos y productos y cualquiera que consuma lo que hacemos. En otras palabras, nuestro cliente final es lo más importante, mientras que en ocasiones esto se nos olvida en nuestro día a día.

Por llevarlo al terreno de lo concreto: hace años enfocaba proyectos personales centrándome en lo que a mí me gusta y que confundía con lo que podían necesitar otros. Corregí a tiempo (creo), me sumergí en toda la cultura lean (Lean Startup, de Eric Ries) y está claro que ahora, en todo lo que hago, me centro no solo en un tema que me apasiona (como todo lo relacionado con la literatura y la publicación abierta), sino que lo enfoco desde la perspectiva del usuario final o del cliente. Nos guste o no, esto afecta a nuestra forma de enfocar el software porque cambiamos la naturaleza y la prioridad de los requisitos.

Por otra parte, no solo servimos a una comunidad, sea la que sea, sino también a nuestros propios compañeros que algún día heredarán nuestro código (y lo bendecirán o se acordarán cada día de algún miembro de tu familia). Esto es, programamos también para hacerle la vida un poco más fácil a otros programadores cuando continúen con tu rabajo.

Tu misión como programador consiste en que otros entiendan tu trabajo de la forma más rápida y sencilla posible. Es más, cuanto mejor hagas esto, más podrás delegar y centrarte en aquello en lo que aportas más valor.

En cierto modo, cuanto más útil es lo que hacemos y para más personas, mejor nos irá. Por tanto, no se trata de trabajar más, de programar más y más proyectos, sino de centrarlo todo en escalar la utilidad que éstos ofrecen al mayor número de personas posible.

Programar requiere de un nivel de abstracción que, me temo, no todo el mundo es capaz de desarrollar, puesto que se deben resolver problemas traduciendo la solución usando un lenguaje de programación con sus propios recursos pero también limitaciones. Evidente, pero no lo es tanto que el código que se genera y su calidad depende mucho de ese nivel de abstracción. Observemos tan solo cómo cambia una solución implementada funcionalmente o bien escrita con un lenguaje orientado a objetos: no solo cambia el resultado de lo que se genera, sino la forma de pensar del desarrollador para enfocar el problema. Esto viene a ser algo así como un paradigma mental de trabajo que te hará resolver las cosas de un modo u otro totalmente diferente. En ocasiones, el desarrollador no es que sea malo, es que no ha cambiado aún de paradigma…

Debemos abstraer, sí, pero solo señalo que esta es una habilidad más que debemos tener los desarrolladores, y que no por eso nos convertimos en personas especiales, ni mucho menos.

La programación orientada a objetos no es un capricho académico, es una forma de pensar para traducir un problema programáticamente de un modo más sencillo, generando código con mejor diseño y más reutilizable, qué duda cabe. Sin embargo, es habitual que se utilicen clases como siemple almacén de funciones monolíticas…

Opino que programar es sencillo, cualquiera que se lo proponga puede hacerlo, pero también pienso que programar bien no es fácil, de ahí que me cause cierta sensación extraña esos cursos de dos semanas que prometen hacerte experto de la noche a la mañana. Lo sé, es un simple recurso comercial, claro está.

Programar tiene también connotaciones artísticas además de las técnicas, pensar solo con las segundas y sin las primeras conduce siempre a una mala solución. Lo digo desde la perspectiva de que para programar con éxito, necesitamos desplegar muchísima imaginación y creatividad, más allá de conocer las técnicas y buenas prácticas que sabemos que tenemos que emplear. En muchas ocasiones, la creatividad consiste en encontrar una solución sencilla a un problema que no lo es.

A diferencia de otras disciplinas, algo que también puede resultar extraño es que cuando programamos, tenemos que pensar mucho en hacerlo de un modo que podamos detectar y corregir errores más adelante. Piénsalo, el diseño del código cambia cuando pensamos en el mantenimiento del mismo, del mismo modo que se puede diseñar un coche de cara a que la reparación de sus averías sea sencilla años más tarde. Por alguna razón, esta cuestión cuesta que cale profundo en muchos desarrolladores con los que me cruzo, y si extrapolo, no tengo más remedio que pensar que es algo extendido en nuestro sector.

Inevitablemente, por mucha experiencia que tengamos, por muchas miles de líneas de código que hayamos escrito, siempre (SIEMPRE) programamos cometiendo errores, que bien son detectados por mala sintaxis en tiempo de compilación o en tiempo de ejecución en lenguajes interpretados, además de log bugs que se producirán aunque el código sea perfecto. No conozco ninguna otra actividad en la que se avance creando algo nuevo pero al mismo tiempo corrigiéndolo continuamente.