Lo que cuenta Sergio Gil, es una simple cuestión de enfoque, pero no de “enfoque” en el sentido “yo lo veo así y tu lo ves diferente” ni “hay miles de puntos de vista porque el mundo es de colores y vivimos en el país de la piruleta”, ni “la dualidad onda-corpúsculo implica que todo es relativo y por eso puedo pensar lo que quiera sin atender a razones”, sino en el sentido de “céntrate de una vez“. El hecho de que mañana salga la biblioteca para ruby on rails que permite definir fixtures con un iphone desde el cuarto de baño no implica que haya que usarla, ni que tengas que comprar un iphone, ni que aprovechar tu tiempo de reflexión en el cuarto de baño para crear fixtures sea una buena práctica. Se trata de que si tienes un iphone y tu intestino no está colaborando, entonces deberías plantearte usar esa biblioteca. Es decir, no te centres en los medios, sino que debes enfocar un objetivo.

También hay una creencia generalizada de que un buen programador es el que dedica esfuerzo en hacer buen código. No. Eso es cometer el mismo error, es centrarse en el medio y no enfocar el objetivo. Un buen programador hace buen código de forma natural, porque para él el lenguaje de programación es un lenguaje (casi) natural. Por alguna razón, la gente cree que un programador de la leche hace código indescifrable e incomprensible para los mortales. Y hay gente que hace alarde de ello, cuando le preguntas “¿qué m*erda es esto?” les encanta, les aumenta el ego e incluso no quieren contestarte del todo para mantener un aura de misterio a su alrededor. Luego te miran como HNGK!! cuando les dices “vale, entonces borro esta basura y lo escribo como lo haría una persona competente, más que nada para que funcione y tal.”

Al final, con tanto objetivo, parezco el señor Smith, pero creo que es la única forma de llevar un proyecto software a buen puerto. Más o menos, las claves que *yo* veo son:

• Hazte un plan de ataque: papel, lápiz, cajitas y elabora un plan general, suficientemente detallado pero que no entre en la arquitectura del software.
• Gestiona bien el tiempo, ponte plazos y checkpoints en el plan de ataque.
• Automatiza los casos de prueba. No tengas miedo de usar un maldito script de bash, lo importante es que sea fácil, mantenible y efectivo. Cucumber puede molar mucho, pero al final un script de perl (¡ha dicho perl!) puede ayudarte más y mejor.
• Usa el lenguaje de programación de forma natural. Si tu código no es bueno, tu programa no será bueno. O aprendes buenas prácticas de programación con tu lenguaje, o te buscas a alguien que lo haga mejor.
• No pierdas el tiempo en tonterías. Metodologías, patrones, etc. son “directrices”, tenlas en cuenta pero no centres tu desarrollo en ello.
• Céntrate en que el código refleje el comportamiento que deseas obtener.
• Programa de forma incremental: compila y prueba MUY a menudo. “A menudo” significa “no llegues a las 10 líneas de código sin probar”. Si cuesta hacerlo, siempre hay soluciones.
• NADIE es más listo que tú. No hagas caso a alguien porque tenga experiencia, oblígale a que te dé razones. Si no te las da, no le hagas caso, es un idiota, cástrale para limpiar la raza.

En fin, mi objetivo ahora es hacer una maleta porque mañana me voy a Sevilla con mi Ali, voy a cargar el móvil, la cámara de fotos y tal. Hasta el lunes……