Cómo Programar

¡Me encanta programar! Es una de las cosas que más me divierte y me llena de mi carrera. Programar es una actividad que involucra tanto la creatividad, como la habilidad técnica y hacerlo bien puede potenciar incluso múltiples regiones de la mente.

¡Programar siempre es emocionante! :D

Sin embargo, quienes me han visto programar sabrán que yo suelo programar "extraño".

¿Cómo así?

Yo puedo pasar horas sólo viendo la computadora o incluso estar aparentemente procrastinando por la web, pero eventualmente abro el editor y básicamente escupo todo el código en cuestión de minutos. Algunos confunden la procrastinación con flojera, pero es muy al contrario. Cuando parezco estar haciendo nada, en realidad estoy pensando y planificando como voy a programar lo que necesito: las estructuras que hacen falta, algoritmos eficientes y patrones reutilizables de otras cosas que ya haya hecho. De repente, sale todo ese código y la gente se queda sorprendida con la velocidad en la que se me ocurrió todo. Pero la verdad, es que no hay realmente ninguna velocidad extravagante involucrada. Sólo una metodología de pensamiento diferente, donde primero se diseña y luego se programa. :)

La gente de Sistemas de Información, a pesar de sus documentos infinitos (los cuales, hay que confesar, contienen mayormente información inútil), tienen sin embargo un concepto acertado: Para programar bien, primero hay que planificar. Lamentablemente esto se enseña en torno a requerimientos y, en menor medida, a herramientas y patrones. Pero realmente no se enseña a planificar y diseñar soluciones con tipos de datos y algoritmos adecuados. Se enseña muy bien a tener claro lo que se desea hacer, pero muy poco se ahonda en tener claro cómo hacerlo.

Por todo esto, quisiera compartir con ustedes cuales son las reglas fundamentales en mi proceso al programar (al menos en la mayoría de los casos):

• Regla fundamental No. 1: No echar ni un caracter de código, hasta haber planificado la estructura y funcionamiento básico del programa. Esto ahorra muchísimo trabajo al final, en especial de refactorizaciones constantes. Al principio no se verán resultados tangibles, pero cuando comiencen a aparecer será tan veloz que parecerá algo mágico, jajaja.
• Regla fundamental No. 2: Los lenguajes y herramientas son diversos por algo. Cada problema tiene diferentes características y diferentes herramientas pueden ser mejores o peores en determinados momentos. Es importante conocer y dominar varias formas de pensar y resolver problemas para así poder seleccionar la más adecuada en cada situación. Por poner un ejemplo, creo que nadie duda que hacer una aplicación web en C sería un dolor de cabeza, pero para programar sistemas de operación pocos lenguajes se le comparan. ¿A su vez, cómo sería programar un sistema de operación en un lenguaje como Ruby? Cada herramienta tiene su dominio y por esto es importante saber distinguir entre ellos.
• Regla fundamental No. 3: Pensar a futuro. Este es un hábito difícil de adquirir, pero sumamente útil si se domina. La verdadera parte complicada al programar está en diseñar la solución. Una vez el diseño de estructuras y algoritmos está completo, efectivamente programar la solución es en verdad un trabajo mecánico. Como tal, consume muy poco procesamiento mental realmente. Por lo tanto, es posible (aunque repito, difícil en un principio) seguir planificando a futuro mientras se programa lo que ya está planificado. Algo así como el pipeline del procesador que mientras ejecuta una instrucción ya interpreta la siguiente. Esto hace que la programación sea un poco más fluida y rápida. Además mantiene la mente activa y evita los peligros de contraer flojera crónica entre "sprints" de implementación.
• Regla fundamental No. 4: ¡Reutilización por siempre! Y no sólo me refiero a reutilización de código, sino también de procesos mentales. Muchos problemas son parecidos o tienen componentes parecidas entre si. Aunque finalmente el código no sea el mismo (por una u otra razón), el proceso mental que llevó a solucionar un problema puede llevar a solucionar otro. Por ejemplo, si se pasó un par de días resolviendo una conexión entre una aplicación web y una base de datos de forma eficiente, el mismo proceso puede reutilizarse si en algún momento se debe conectar eficientemente una aplicación móvil a una base de datos local (a pesar de que muy posiblemente, el código sea bastante diferente).
• Regla fundamental No. 5: Nunca perder la práctica. Es importante mantenerse programando y no únicamente en un área específico. Se debe intentar explorar nuevas áreas sin descuidar aquellas que ya se han explorado antes. Por ejemplo, a un programador web deberían poder asignarle un trabajo de bajo nivel (implementar un driver, por ejemplo) y no debería ser el fin del mundo para él, sino sólo un reto más a superar y una nueva oportunidad para aprender y practicar algo diferente.

Las tres primeras reglas fundamentales, potenciadas con la cuarta y la quinta, hacen que un programador luzca como un verdadero mago. Después de unos minutos pensando en un problema complejo, puede producir código muy rápido que lo soluciona. Y muy posiblemente, código eficiente, reutilizable y hasta seguro. Todo depende de cuanta experiencia se tenga. Como ejemplo personal, estoy claro que al programar en un lenguaje funcional (como Haskell) puedo llegar a hacerlo sumamente rápido. Pero eso no es más que una mezcla de pasión y experiencia. Eso no me hace más inteligente que nadie, ni mucho menos. Estoy totalmente seguro que todos y cada uno son mejores que yo en algo. Pero finalmente, creo honestamente que la experticia en cualquier herramienta o dominio siempre puede lograrse no más que siguiendo estas 5 reglas fundamentales.

Todas estas reglas dependen claro, de una que es incluso más fundamental y básica:

• Regla fundamental No. 0: No puedes escribir un programa para resolver un problema que no entiendes. Es sumamente nocivo intentar resolver un problema, cuando no se tiene claro cuál es siquiera el problema que se necesita resolver. Esto, lamentablemente, es más que común por los tiempos apresurados de producción en la industria de la computación. Sin embargo, debe evitarse a toda costa. Lo primero que debe asegurarse siempre es haber entendido el problema, luego entender cómo resolverlo, luego con que herramientas y sólo entonces se debe echar manos a la obra e implementar. (gracias a Ernesto Hernandez-Novich por el comentario que inspiró esta regla adicional).

Y bueno, esto quería compartir con ustedes hoy. Éste es mi extraño método y debo decir que muchas veces me ha funcionado bastante bien (aunque puede ser terrible cuando hay deadlines cercanos involucrados, pero ese es otro cuento, jajaja). Cualquier comentario, como siempre, es más que bienvenido. ¡Hasta una próxima entrada! :D