agrandar la tarea

· osiux's blog

.org | .md | .gmi | .html

# problema(s) a resolver

A diario me encuentro con un problema a resolver que me lleva a meterme en mas problemas a resolver y no es fácil ni claro decidir cuándo detenerse, porque resolver problemas es divertido.

# perdiendo el foco

Intentando organizar el año, fui al living de casa a sentarme a escribir en papel un calendario del mes, esto lo hacemos siempre porque visualmente ayuda muchísimo tenerlo ahí a la vista de todos y todas, así en familia podemos coordinar o sincronizar los eventos e incluso hasta mi hijo mas pequeño pide tachar el día cuando este termina, y resulta que antes de sentarme a escribir algo, vimos el living desordenando y nos pusimos a ordenar, en ese orden llevé unos vasos a la cocina y como vi que había cosas por lavar, me puse a lavarlas, al volver encontré una bolsa con varios papeles y bueno ya que estaba me puse a verlos, terminé sacando fotos a lo que de alguna manera quería conservar y tirando el 98% del resto.

# agrandando la tarea

En el medio de todo esto venía pensando en retomar el uso de bullet journal 1, asi que una manera de registrar el calendario era comenzar a utilizar una libreta negra a estrenar y recordaba que una libreta roja de años anteriores ya tenía dibujado mi bullet journal abandonado, me puse a buscar la libreta roja y al mismo tiempo buscando templates por la web para tener de modelo por si no encontraba la libreta roja, en esta búsqueda mi mujer (que es la que encuentra todo en casa) dió con unas bonitas hojas de colores recortadas, que eran de mi proyecto de libretA7 2, asi que dije, buenísimo, voy por esto, y terminé viendo un video tutorial (porque no encontré un PDF) de como hacer tu propia bullet journal y en el medio de hacerla recordé porqué había abandonado su uso y es que lo que me gusta de anotar en papel es tener libertad total y no estructurarme dónde y cómo registrar, y por otro lado, la vista de calendario mensual es la que mas me resulta para organizarme, asi que pensé en armar una nueva libretA7 pero anexando en calendario al final.

# resolver extras innecesarios

Me puse a ver mi propio tutorial Capturar ideas en papel de Moleskine|HispterPDA|PockedMod y libreta artesanal 3 y al verlo, descubrí algunos links rotos, errores de indentación 4 y sintaxis y bue, ya que estaba corregí el post y como apuntaba a un repositorio git inexistente, verifiqué el correcto, cambié la URL y me puse a revisar mis scripts de generación de libretA7, terminé adaptándolos hasta que shellcheck 5 no dió mas errores y luego ejecuté los scripts para re-republicar los PDFs de ejemplos como este de vim-A7.pdf 6.

Uno de los links rotos era sobre reStructuredText 7, archivo que ni siquiera tenía versionado, recurrí a WayBackMachine 8 y encontré un snapshot 9 del 2013, luego de un copy+paste lo convertí a org-mode y una de las referencias decía "estará siempre disponible en http://pub.osiux.com/restructuredtext/reStructuredText.txt" y como no estaba, convertí de .org a .rst y re-publiqué para cumplir con lo de "estará siempre disponible" :P

# al final cuál era la tarea original?

Era tan simple como registrar eventos en un calendario de papel que finalmente no me llevó mas de 1 pomodoro 10 (confieso que el post sobre pomodoro también estaba perdido y tuve que recuperarlo).

Esta claro que me disperso fácilmente, pero también tenía muchos pendientes por resolver, algunos de ellos era consciente y sabía que los tenía que hacer, pero por otro lado pude re-encontrarme con algunas metodologías oxidadas, ver en libretas de hace 10 años que algunos pendientes ya los resolví y si bien otros siguen sin cambiar de estado (porque no son realmente críticos) veo un notable progreso y muchas buenas ideas que podría retomar en cualquier momento porque tengo un registro de ellas y una frase que descubrí anotada es...

el éxito es la suma de pequeños esfuerzos repetidos día tras día

...no recuerdo en que momento la anote, pero me gusto mucho volver a leerla, refuerza el concepto de seguir en la misma dirección, registrando, avanzando y reflexionando al respecto.

# sirvió para algo perder el tiempo?

La sensación mas común que tenemos siempre es la de perder el tiempo, que al final una pavada lleva un montón de tiempo y que hasta la tarea mas simple se complica!

Sin una metodología o una pausa para re-pensar un poco todo, es fácil enredarse y perderse, pero es simple revertir esta conducta con lápiz y papel si estás a solas o hablando con alguien sobre lo que estás por hacer, es importante estimar cada tarea, al menos catalogarlas en fácil, complicada, rápida, lenta, etc, lo más importante es poder priorizarlas, realmente es necesario resolverlas todas hoy? en paralelo? hay alguna otra alternativa? la puedo delegar? o posponer? en eso GTD 11 ayuda muchísimo y en el caso de haberlas realizado y sufrido en el camino, aprovechar el momento para una retrospectiva, sacarle provecho a lo aprendido.

# anotar y tachar dá un alivio enorme!

A continuación un listado de todas las tareas con las que me topé:

Como se puede apreciar, no fué una pérdida de tiempo o al menos fue bastante productiva, claro esta que esto sucedió durante 2 días de un fin de semana e hice todo al revés, la "lista de tareas", la escribí luego de realizarlas, pero si hubiese dedicado al menos 1 pomodoro a pensar y analizar antes de hacer, seguramente luego de los 25min hubiese tenido mucho tiempo disponible y muchas tareas en estado TODO o NEXT que algún otro día podría resolverlas, lo importante pasa por registrar las tareas y discriminarlas y/o detallarlas lo más posible para cuando tengas tiempo disponible.

# y que tiene que ver con el desarrollo de software?

Muchísimo! Como todo buen developer en mis inicios, saltaba al teclado como un ninja de la consola y es extradamente fácil enredarse con dependencias, liberías, bugs de entorno, "refactorizar" código "viejo" sólo porque "te duelen los ojos verlo" o simplemente ponerse a codear algo porque te resulta mas entrenido o a resolver una función super genérica en lugar de resolver el problema puntual que tenés enfrente o ponerse a hacer un nuevo kernel.

La gestión de un proyecto de software requiere de registrar tareas y dialogar con el equipo de trabajo y decidir en qué momento conviene hacerlas, cuál es prioritaria? qué puede esperar, qué se podría delegar, qué se puede resolver "quick & dirty" o qué requiere parar todo y hacerlo en "código bonito"

Sin dudas, es un ejercicio y de cada experiencia de la vida diaria se puede aprender y mejorar.

# ChangeLog