martes, diciembre 26, 2017

Esa es una buena pregunta...

"Esa es una buena pregunta...". Esa frase la he escuchado varias veces, sobre todo en presentaciones cuando alguien de los asistentes pegunta y el presentador no sabe la respuesta. ¿Es eso lo que la hace una buena pregunta, que el presentador no conozca la respuesta? No creo, quizás si fuera importante la pregunta entonces la persona que presenta ya conociera la respuesta.

Las buenas preguntas nos ayudan a comprender
El desconocer la respuesta no hace, necesariamente, a una pregunta buena. Para mi una buena pregunta es la que ayuda a entender o explicar mejor algún tema. Si la pregunta no aporta información relevante al tema entonces no es buena, independientemente de que se conozca su respuesta.

A veces no tenemos respuesta para las buenas preguntas y nos hacen darnos cuenta de lo que no sabemos del tema. Saber lo que no sabemos es importante y por eso muchas de las preguntas para las que no tenemos una respuesta son buenas; pero no son buenas porque no tengamos la respuesta. Sino porque nos hace conocer más del tema, que hay otras cosas por descubrir.

Dejemos de usar la frase: "Esa es una buena pregunta..." si es solo porque no conocemos la respuesta porque eso promueve preguntas para escenarios muy específicos que no aportan mucho al tema en general. Puede haber una pregunta donde la respuesta parece obvia y aclara algo que quizás puede ser ambiguo, esa puede ser una buena pregunta; pero si andamos buscando preguntas que nadie sabría la respuesta, solo porque esas son las "buenas" podemos perdernos de comprender mejor el tema.

Las buenas preguntas son las que nos ayudan a comprender.

martes, diciembre 19, 2017

Actitud en Proyectos Legacy

Los proyectos legacy... esos proyectos que por lo general fueron iniciados por alguien más. Aunque a veces fueron iniciados por nosotros mismos. Por lo general son viejos y ya no programamos así o en ese lenguaje. Alguien tiene que darles mantenimiento, corregirlos...

Cuando nos toca empezar a trabajar en un proyecto de esos a veces puede ser frustrante el tratar de moverle, agregarle funcionalidad usando herramientas "anticuadas" o usando convenciones de nombrado diferentes a lo que quisiéramos. Siempre está ese pensamiento, indecisión de: "Y si lo reescribimos"  o "seguiremos usando lo mismo". Es pesado trabajar en proyectos así, sobre todo si fue hecho de una manera poco organizada o si cuenta con mucha deuda técnica. Es fácil caer en quejas y empezar a verlo todo mal.

La experiencia de haber visto otros proyectos similares, de conocer diferentes arquitecturas, haber leído artículos sobre cosas que la gente intenta te ayuda a darte una idea de que estaban pensando los programadores anteriores y conocer por qué agregaron esa interfaz que a lo mejor no tiene sentido si solo tiene una implementación. La experiencia también puede hacernos arrogantes y ver con mayor desprecio ese proyecto que usa otras practicas a las que recomendarías o ya usamos y aprendimos que no son lo mejor para ese tipo de proyecto.

Si no tienes experiencias puede ser también frustrante porque no es algo que tú conoces y por lo tanto no es algo que recomendarías. A veces cuando uno empieza quiere usar lo que conoce, la tecnología con la que jugó en proyectos de prueba, que generalmente es algo nuevo. El querer usar lo último y que nos toque trabajar en un proyecto con tecnología vieja puede frustrarnos y sentir que estamos estancados. Sin aprender cosas que nos van a ayudar en el futuro.



Cuando tienes que trabajar en proyectos legacy que inició alguien más, la buena actitud con la que revisas el problema es parte de las habilidades necesarias para mejorarlo. Debemos pensar que el equipo anterior tomó decisiones con la mejor intención, con la información que tenían en ese momento.

Es fácil juzgar una vez que ves que el resultado no fue el esperado y tienes que corregirlo. Pero entrar al problema con quejas en lugar de entender el porqué de la situación, es más desgastante y puede ser más costoso porque puede haber cosas rescatables en el proyecto que no veras, además corres el riesgo de cometer los mismos errores por no entenderlos. 

Evita esa frustración, piensa que se hizo lo que se creyó mejor y éntrale al proyecto con una buena actitud, buscando dar soluciones en lugar de quejas. El primer paso es darte cuenta que está en ti cambiar las cosas.