hábitos

No me gusta repetir trabajo ni tareas pesadas que se hacen una y otra vez y que de algún modo se pueden automatizar o al menos indicar lo pasos a realizar para que la siguiente vez no pierdas tanto el tiempo en recordar cómo se hacía ésto o aquéllo. Si te encuentras en esta situación a menudo, que sepas que puedes evitarlo.

Si es verdad que debemos poner el foco en aquello que aporta valor, en las tareas verdaderamente creativas y productivas, entonces tenemos que encontrar la forma de no tener que reinventar la rueda continuamente. No estoy hablando de tareas que hay que hacer sí o sí (como un parte de trabajo) y hablo en sentido general, no sólo desde el punto de vista del desarrollo de software, sino de hacer todo lo posible para que estas tareas ocupen el menor tiempo posible y, sobre todo, no tengamos que pensar reiteradamente cómo se hacían.

Voy a poner varios ejemplos:

• El proceso de publicar una nueva noticia en la web, ya sabes, crear el contenido, fijar bien la url, revisar el contenido, comprobar la estructura del mismo, revisar faltas de ortografía o de expresión, pedir la aprobación del mismo si es necesario, etc. Son varios pasos, sí, pero si este trabajo lo haces una vez cada varios meses, terminar olvidándolo y preguntándote ¿cómo había que poner el formato de las url?
• Si mantienes varias webs, como es mi caso, y además todas con Drupal, y dado que no las actualizo continuamente (actualizaciones de módulos, mejoras de diseño, etc.), puedes encontrarte con que cada vez que vas a actualizar una, tienes que volver a investigar cómo se hacía esto o aquello, como por ejemplo, cómo y dónde guardar una copia de seguridad, cómo etiquetar la nueva versión de la web en GIT o similar, cómo comprobar que la nueva actualización no ha roto nada, cómo desplegar para que no te quede ningún cabo suelto, comprobar la seguridad, etc.
• Llevo dos años usando la herramienta Scrivener para la creación de libros. Su proceso de compilación genera un fichero en format eBook, pdf, docx, etc. Sin embargo, después de generar el fichero tienes que comprobar varias cosas según tu flujo de trabajo y el propósito que tengas. Por ejemplo, si generas un eBook para Kindle, tienes (o deberías), revisar que el epub pasa las pruebas de validación con una herramienta como epubcheck, después tienes (o deberías) abrirlo con la herramienta Kindle Previewer y revisar página a página, y no digamos le proceso de publicación en Amazon.

En fin, son trabajos que realizas que requieren de varios pasos para su realización. Salvo que tengas una memoria prodigiosa, cada vez que los vayas a enfrentar algo se te quedará en el tintero.

¿Resultado? No se terminará del todo bien y se tardará más en realizarlo, aparte de lo tedioso que resulta tener que investigar algo porque lo has olvidado... Y si te fijas bien, parte de tu trabajo lo pasas realizando tareas que bien podrían estar bajo el paraguas de un procedimiento.

Llevo años procedimentando este tipo de tareas e intentando establecer una cultura y hábito en procedimentar en los ámbitos laborales en lo que me muevo.

Crear un procedimiento no es más, en esencia, que establecer en una simple guía los pasos para realizar una tarea. No estoy hablando de esas compañías que para hacerlo todo tienen un repositorio de procedimientos o normas más largos que El Señor de los Anillos, sino de sencillas guías que te puedes hacer tú mismo para evitar tener que recordar continuamente las mismas cosas y así hacerlas con mayor rapidez y seguridad.

Y esto se aplica a cualquier ámbito personal o profesional. ¿Qué sería si no la gestión de la configuración un proyecto software sin un procedimiento entendido por todos los desarrolladores?

Si lo tuyo es el marketing, es posible que tengas establecido cómo documentar tus próximas acciones comerciales así como sus resultados (= procedimientos).

Es sorprendente la cantidad de tiempo que se gana cuando tienes guías sencillas y prácticas para realizar tareas más o menos complejas.

Pero por otra parte, ¿cómo si no muchas personas de una organización, por pequeña o grande que sea, podrían trabajar sin seguir ciertas normas o esquemas de trabajo (= procedimientos)?

Lamentablemente en muchas organizaciones, se terminan aprendiendo las cosas no porque las leas en un documento de bienvenida o algo así, sino porque a algún compañero o compañera le endosan la tarea de explicarte cómo se hacen las cosas (por lo cual también es una pérdida de productividad para él).

Estos son algunos de mis procedimientos que más uso:

• Generación y revisión en la generación de epubs y pdf de cara a su publicación.
• Procedimiento de crear contenidos (como este) en las distintas webs así como su difusión.
• Uso de los repositorios de código para los proyectos en los que trabajo.
• Actualización y mantenimiento de mis webs con Drupal.
• Desarrollo de nuevas ideas y propuestas.
• etc.

Si en tu organización no hay procedimientos de trabajo de algún tipo, chungo. Y si en tu día a día, en la forma de organizarte o de afrontar los distintos proyectos en los que trabajas, pero aún.

Estoy convencido de que las personas más exitosas y las organizaciones que funcionan mejor tienen una fuerte cultura de establecer y usar procedimientos de trabajo ágiles, claro, porque su abuso puede suponer al final todo lo contrario de lo que se desea obtener.

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?.

Este es uno de los malos hábitos que debemos quitarnos de encima; el dejar rastros de código obsoleto va en contra de que este sea legible y fácil de entender.

Cualquiera que retome vuestro trabajo y se encuentre con él, lo primero que va a pensar es, ¿será esto un bug resuelto, lo habrán dejado ahí por alguna razón, será importante?. Este tipo de interrupciones en la lectura de líneas de software distraen del resto y crean dudas.

La razón por la que solemos dejar código comentado es obvia: nos cuesta mucho eliminar trabajo previo, pero es que precisamente esa labor de destrucción (eliminar algo que no está bien) y reconstrucción (re-crearlo para mejorarlo) es lo que aporta calidad a nuestro software. Entonces, ¿para qué dejar rastros de lo anterior?. Otra razón es que en ocasiones dudamos y no estamos seguros de las modificaciones que queremos introducir. Este último caso es fácil de resolver: una buena batería de tests nos deben indicar la solvencia o no de lo que cambiamos.

Por otra parte, ¿para qué está el repositorio de código?. Si modificamos algo y eliminamos un bloque, siempre lo podremos recuperar más adelante si hacemos una buena gestión en nuestro sistema de control de código fuente.

No es que haya que caer en extremismos; el desarrollar software tiene un componente lúdico y tampoco debemos ceñirnos rígidamente a las reglas, prácticas y buenos hábitos que sabemos que son necesarios para hacer un buen trabajo. Lo que indico aquí es que un software de producción y que debe ser mantenido y revisado, no debería tener bloques de código muerto.

"No dejemos código comentado: esto distrae a un futuro lector de nuestro trabajo y ensucia la solución"

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.

Una vez leí que cuando estamos en ese estado de fluidez completamente abstraidos y somos interrumpidos, necesitamos al menos veinte minutos para volver a un estado similar de concentración, es decir, a lo largo de varias semanas esto significa muchas horas de trabajo perdido, así de simple y así de abrumador.

Hay muchísimos momentos en los que somos interrumpidos y sacados a la fuerza de ese estado de fluidez.

Están los que yo llamo los vampiros de tiempo: personas e incluso buenos amigos que se sienten con el derecho de acercarse a tu puesto de trabajo para preguntarte de sopetón cualquier cosa que en ese momento necesitan o aquellos que creen que su tiempo es más valioso que el tuyo.

Clientes a los que se les ha acostumbrado a llamar por teléfono porque es más cómodo que describir un problema por mail.

Reuniones espontáneas y no planificadas porque a tu jefe o manager le ha entrado cierta urgencia o ansiedad que ahora va a intentar trasladar al equipo por falta de una mínima organización. Esto es lo que yo llamo el síndrome del jefe ansioso (y es una patología porque traslada ese estado al resto de su equipo).

Espacios abiertos en donde los teléfonos sonando o el rumor de conversaciones son constantes, hasta aquella chica que con sus hermosos tacones va dejando una sinfonía de pisadas que la identifican (y te irritan).

Un día cualquiera hace un par de años decidí contar el número de veces que era interrumpido y molestado a lo largo de la jornada laboral: conté catorce veces, incluidos unos quince mails irrelevantes para mi trabajo y responsabilidad.

Lo peor es que la mayoría de estas interrupciones se producen porque alguien necesita algo ti y eso que necesita es completamente ajeno a tu trabajo: no nos damos cuenta de que nos quitan precisamente el tiempo y tranquilidad necesarios para hacer un trabajo de calidad y no dejar bugs que nos pasarán factura más adelante.

Un desarrollador profesional evita estas innumerables e inútiles interrupciones. Aquí indico algunas sugerencias que para mí particularmente me han resultado efectivas:

• Identifica a los vampiros de tiempo: ante la insistencia de estos, quítatelos amablemente de encima poniendo el mínimo interés en sus peticiones. Con el tiempo dejarán de ir a por ti.
• Si tu jefe, coordinador o manager se acostumbra a trabajar con reuniones imprevistas, indícaselo claramente: seguramente no se de ni cuenta del impacto que esto puede tener para el trabajo. Puedo contar la experiencia con cierta persona de perfil comercial que aprovechaba las reuniones para hacer el trabajo directamente sobre una hoja de cálculo...
• Si tienes clientes que atosigan por teléfono, indícales amablemente que reporten las peticiones por mail o por el sistema de ticketing que uséis. Con el tiempo os lo agradecerán porque no hay nada mejor que describir un problema para entenderlo completamente.

Desde que comencé a aplicar esas sencillas técnicas tanto para mí como para el equipo que dirigía en ese momento, conseguimos un ambiente laboral mucho mejor y por tanto pudimos hacer un trabajo de mejor calidad. Gané de paso algunos conocidos que comenzaron a verme, digamos, algo mal, pero mi jefe notó al poco tiempo el cambio y la mejora en la productividad del equipo.

"No digo que tengamos que trabajar en un convento de clausura, sólo aplicar el sentido común en estas circunstancias y tener en cuenta que hay límites intolerables en la cantidad de interrupciones diarias, lo que revela una falta general de organización y productividad en el trabajo"