Hay diferentes maneras de aprender y mejorar nuestro trabajo como desarrolladores de software. El aprender una nueva tecnología (o mejorar las habilidades en aquellas que dominamos) requiere a menudo repensar cómo hacemos las cosas.

Hay quien se siente cómodo buscando en foros continuamente para resolver cualquier problema; esto para mí es algo así como aprender por prueba y error llevado al extremo. Hay quien, como yo, preferimos aproximarnos a una nueva herramienta o tecnología leyendo un buen libro de arriba abajo. Las opciones son diversas y como se suele decir cada maestro tiene su librillo.

No obstante, he visto durante mucho tiempo el que es un gran defecto de muchos programadores profesionales: cuando conocen en profundidad las herramientas, lenguajes, etc. que utilizan en el día a día, se anquilosan haciendo siempre, durante años, las mismas cosas y del mismo modo. El desarrollar software tiene un grado versatilidad y flexibilidad que difícilmente hay una única forma de hacer algo, todo lo contrario, siempre existen cientos de formas de resolver un problema; entonces, ¿por qué nos abstenemos de descubrir esos otros enfoques?.

En ocasiones me han preguntado por qué insisto tanto en que el código que se escriba sea lo más legible posible, que se pueda leer y entender sin que construcciones extrañas o clases de cientos de líneas te arañen la vista, por poner unos ejemplos.

Se pueden dar muchos argumentos a favor de añadir un poco de esfuerzo a nuestro trabajo para escribir código que otros puedan entender; de todos los posibles a mí me parece que hay un criterio fundamental que no siempre se tiene tan en cuenta.

La productividad de un equipo de trabajo en ocasiones viene dada por pequeños detalles que en sí mismos pueden parecer insignificantes pero sumados marcan una gran diferencia. El Libro Negro del Programador habla intensivamente acerca de cómo desterrar malos hábitos e incorporar buenos precisamente para aumentar la productividad. En ocasiones se entiende ésta exclusivamente como echar más horas: yo digo que trabajar con productividad tiene más que ver con usar herramientas correctamente, tener un equipo de trabajo bien organizado y buenos procedimientos.

Uno de estos procedimientos que pueden ahorrar muchísimo tiempo de esfuerzo inútil es subir correctamente al repositorio de código los últimos cambios introducidos. Como en muchas ocasiones, los mejores hábitos y técnicas son precisamente los más sencillos.

Cuanto más tiempo viva tu aplicación, más probable será que tenga que cambiar; así de sencillo y contundente.

En ocasiones me han preguntado por qué parezco obsesionado por programar y diseñar de la manera más simple y legible posibles, para qué preocuparse ahora por aquello que puede o no necesitar cambiar en el futuro. La pregunta en sí ya encierra cierta candidez acerca de los artefactos que generamos en nuestra profesión.

Una de las verdades sobre nuestro trabajo, entronada a modo de ley, nos dice que cuanto más tiempo viva nuestra aplicación, programa, sistema, plugin, framework, etc. más probable será que necesite cambios, mejoras, correcciones, etc. Ley o no, lo que sí puedo decir es que ningún software en el que he participado ha permanecido inmutable más de seis meses...

En una etapa laboral anterior, sufría a menudo el típico ataque inesperado según el cual un manager o jefe de proyecto venía a pedirme a mí y a mi equipo la corrección o puesta en producción de algo que por arte de birlibirloque se había convertido ese día en crítico. A lo mejor lo tenía en el cajón olvidado hasta que le explotó en las manos.

Nada peor para un programador que tener que resolver un bug o incluir una nueva característica con la presión del tiempo, sobre todo si no estaba previsto.

Resulta sorprendente cómo pequeños pasos y hábitos consiguen con muy poco mejorar muchísimo la calidad de nuestro código; cuando hablamos de calidad entendemos también legibilidad, es decir, la facilidad o no de poder entender un pedazo de código leyéndolo tal como leemos un relato corto. Yo siempre digo que si se consigue entender de una o dos pasadas lo que hace un pedazo de código, entonces es que este apunta a estar bien hecho.

Ahora bien, ¿qué hacen por ahí esos trozos de código comentados que, lógicamente, no se van a ejecutar?.

10:00 de la mañana; tienes por delante una tarea que estimas en dos horas para hacerla bien y darla por terminada. Te preparas ante tu entorno de trabajo y comienzas a desarrollar código; poco a poco tu mente va dejando las divagaciones de la charla del café anterior y se mete de lleno en el problema a resolver. No es raro entrar en ese estado de fluidez definido por Mihaly Csikszentmihalyi en su famoso libro de psicología positiva.

Tomar decisiones de diseño, desarrollar una clase o refactorizar un conjunto de pruebas, por poner unos ejemplos, requieren de concentración y cierta paz mental para que las decisiones tomadas sean las correctas.

Esto parece evidente, pero pocos entornos laborales fomentan esta tranquilidad y capacidad de estar concentrados.

Los programadores por naturaleza afrontamos muy mal aquellas tareas que más nos cuestan y casi siempre comenzamos por las que más nos gustan o aquellas que más nos apetecen en el momento, esto es así porque tenemos la opción de elegir qué hacer de entre todo el trabajo que tenemos por delante.

Un desarrollador neófito o júnior comienza siempre por lo divertido, mientras que un programador profesional elige siempre en primer lugar lo más difícil o aquello que le causa especial incertidumbre. Las consecuencias de esta elección son evidentes.

Cualquier proyecto software comienza cargado de problemas e incertidumbres, se desarrolla con problemas e incertidumbres y se entrega con... pues eso.

Cuando programamos estamos resolviendo problemas, al menos algunos de los que conocemos y nos agobiamos precisamente por aquellos que desconocemos.

Todo sería un poquito más fácil si asumiéramos que cualquier proyecto software tiene en su naturaleza tres verdades que al conocerlas bien nos pueden hacer nuestro trabajo más asumible y cómodo. Son las siguientes.

Las reglas para desarrollar buen software son en ocasiones de un total sentido común y están al alcance casi de cualquiera que se proponga realizar su trabajo en condiciones.

No hace mucho re-descubrí un conjunto de sencillas preguntas que nos dicen si tenemos un buen equipo de trabajo y trabajamos desarrollando software con un mínimo de calidad: es el test de Joel que resumo a continuación y que no es más que sentido común aplicado a nuestra actividad diaria:

Páginas

¿Por qué leer El Libro Negro del Programador?

Adquirir desde:
Amazon (kindle eBook / papel)
CreateSpace (papel)
PayHip (epub / mobi / pdf)

El libro negro del programador.com
Segunda Edición - 2017

Archivo

Trabajo en...