Entradas

Pláticas casuales, conexiones reales

Imagen
Las pláticas casuales son esas conversaciones que tienes con una persona a la que no conoces tanto y, por eso mismo, no tienes mucha confianza como para hablar de cualquier cosa. Estas suelen ocurrir, por ejemplo, cuando recién te presentan a alguien; pero donde más me toca que pasen es poco antes de iniciar una junta, mientras estamos esperando que lleguen todas las personas requeridas. Lo que se habla son cosas sin importancia, cosas que quizás son obvias (como que está haciendo frío). Hace tiempo no me gustaba tener estas conversaciones. De hecho, aún no sé si me gustan porque a veces no sé qué decir y no me agrada mucho decir lo obvio o hablar de un tema cliché. Sin embargo, a través de los años me he dado cuenta de que esas conversaciones tienen su valor. No es por el tema en sí, sino porque ayudan al equipo a tener una relación, a romper el hielo e incluso a formar, poco a poco, una amistad con el resto del equipo. He notado que muchas personas que se dedican a la tecnología como...

Tú, no eres tu código

Imagen
Escribir código puede sentirse muy personal, sobre todo si pasas mucho tiempo pensando en él, diseñando, escribiendo, editando y quizás reconstruyendo módulos para lograr que se vea mejor. Puedes sentir orgullo por el código que escribes y por lo tanto, llegar a pensar que es parte de ti; pero la verdad es que: el código, no es parte de ti, es solamente algo más que hiciste. Tú, no eres tu código. El código representa el nivel que tenías cuando lo escribiste; pero no te representa a ti como persona. Eso significa que está bien hablar de tu código con confianza, ver las fallas y oportunidades de mejora sin sentir que estamos hablando de las fallas de la persona que lo escribió. Una cosa es hablar de las fallas del código y una muy distinta hablar de las fallas de la persona. Lo mismo aplica a las ideas acerca de la arquitectura y los procesos que debemos seguir para crear un producto de software. Alguien puede sugerir que se use algo diferente o usar algo de manera distinta. Esa persona...

Primero la pregunta y después el contexto

Imagen
A veces cuando alguien quiere hacerme una pregunta, empieza por darme contexto sobre el tema del que va a preguntar. Me empiezan a explicar cómo fue que llegaron a la pregunta que tienen en mente. Algunos comienzan por explicarme lo que han intentado para resolver el problema que enfrentan, me explican el porqué de esos intentos. Ha habido, incluso, ocaciones en que me explican las respuestas que han encontrado en internet; pero todo esto sin haberme hecho la pregunta todavía. Comprendo que me dan el contexto para ayudarme a encontrar la mejor respuesta, también lo hacen para que no crea que no han intentado encontrar la respuesta por su cuenta; o quizás para que no piense que me consultan sin tener una buena razón. Entonces empiezan por justificar el porqué de la pregunta sin siquiera haberme hecho la pregunta todavía.  El contexto de la pregunta es importante, sirve para saber de qué estamos hablando en realidad, lo cual es bueno para dar una respuesta correcta. Entender el porqu...

Fighting Frustration

Imagen
Some days things don't go the way I expected, sometimes people don't agree with my opinion or with what I feel is "obviously" more important to do. It's easy to start thinking that some people just don't care, if only they leave me alone and allow me to do my work, I can change the company. I can blame others when things go bad and start thinking that is their fault because they have a different opinion than mine. But the true is that if something goes wrong, with the project I'm working, it's my fault. I should be responsible to finish the project, in time and budget, and because of that, I have to deal with all the bureaucracy that needs to be dealt with. I have to realize that I need to do that as part of my job. Besides, is not that people don't care is just that they have a different (and valid) approach than mine. How do I deal with the frustration? Well... first I need to stop complaining, because if I start to focus in the bad...

Bloqueos

Imagen
Una de las preguntas típicas de las juntas matutinas en los equipos de desarrollo de software es ¿Hay algún bloqueo? Si lo hay, se trata de ver qué es lo que está esperando esa persona y encontrar la forma de que se desbloquee; pero ¿Qué son los bloqueos? Los bloqueos son obstáculos que te impiden realizar o avanzar en tu trabajo. Evitan que puedas seguir progresando en el proyecto. He notado que es común en las personas con menos experiencia decir que tienen un bloqueo cuando están batallando, debido a su poca experiencia, en la forma de resolver un problema. Han intentado varias formas y se empiezan a quedar sin ideas de como puede ser resuelto el problema o como pueden cumplir con el requerimiento especificado. Al quedarse sin opciones de qué intentar dicen que tienen un bloqueo con la tarea y que a menos que alguien les diga como resolverlo, no se puede avanzar en la tarea. En personas con más experiencia, ese tipo de bloqueos no ocurren, una persona con experiencia ha visto...

Comentar lo bueno

Imagen
La intensión de que alguien más revise mi trabajo es poder encontrar posibles errores o revisar que haya tomado en cuenta detalles importantes. Se puede aprender cuando alguien más revisa lo que haces. Los code reviews es un ejemplo de eso, se revisa el código y se ve qué es lo que se puede mejorar, se critica el estilo y la manera en la que se implementó la solución en el código. Los comentarios en la revisión del código ayudan a darme cuenta de lo que hice mal o de lo que pude haber hecho mejor y me hace crecer porque la siguiente vez que implemente algo similar sabré a que (otras) cosas debo poner atención, en base a esos comentarios. También revisar el código de alguien más, con la intención de encontrar oportunidades de mejora, me ayuda a mí. No solamente le ayuda a quien escribió el código, también me ayuda a mí porque soy consciente de esos detalles que quizás no los hubiera visto si no hubiera revisado el código con la única intención de buscar mejoras. Después, cuando pro...

Trabajando remoto. ¿Desde casa u oficina?

Imagen
Casi toda mi carrera de programador o ingeniero de software la he realizado de manera remota, aunque ha habido temporadas en las que sí estuve trabajando desde una oficina como parte de un equipo; pero la mayoría del tiempo lo he trabajado desde casa. Actualmente a veces voy a la oficina y trabajo un turno completo desde allí, otras veces lo hago desde casa; pero siempre de manera remota, el resto de las personas trabajando en los proyectos están en otra parte. No es lo mismo trabajar de manera remota o a distancia que trabajar desde casa. Una diferencia es el tiempo que estás disponible para trabajar, cuando voy a la oficina y allá dejo el equipo (la laptop y cuaderno con notas) no puedo seguir trabajando cuando ya llegué a la casa, lo mismo pasa a la mañana siguiente. Ha pasado que me piden algunos cambios rápidos y debo esperar a llegar a la oficina para atenderlos. Esta es la principal diferencia, cuando estoy desde casa siento que tengo todo el día para terminar mis tareas...