sábado, octubre 05, 2019

Bloqueos


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 problemas similares y conoce los problemas comunes con cada posible solución. Si no ha resulto algo similar entonces es capaz de investigar, realizando búsquedas más concretas que le dan una mejor respuesta para el problema en particular que se quiere resolver. Para una persona con más experiencia los bloqueos son cuando está esperando información de alguien más. Puede ser alguna respuesta del cliente, la definición por parte de otro equipo sobre que herramienta en particular se va a usar.

La principal diferencia es que la persona sin experiencia puede sentir que está bloqueada aunque el problema no involucre a otras personas. La persona sin experiencia acepta la idea de que está bloqueada porque no tiene idea de como resolverlo. Por otro lado, una persona con experiencia sabe que si no ha resuelto el problema por si misma aun, entonces no hay un bloqueo solo hay un retraso, debe de intentar otras formas, debe de investigar, debe de preguntar a otros miembros del equipo o personas externas incluso. Es decir tiene cosas que hacer para resolver el problema, no está bloqueada a que alguien más venga a resolverle el problema. La persona con experiencia no acepta la idea de tener un bloqueo si el resolverlo depende de sí misma.

¿Qué pasa con los bloqueos que tiene la persona con experiencia, esos bloqueos que son porque está esperando que el cliente le conteste o que alguien más termine otra parte del sistema? En esos bloqueos la persona encargada del sistema puede buscar en qué otra cosa se puede trabajar mientras se da algo de tiempo a quien debe de dar la información. Se agrega como tarea dar seguimiento a las respuestas que se están esperando. Se busca la forma de obtener esa información lo antes posible o de trabajar alrededor de eso para que en cuanto llegue la información se pueda incluir de manera rápida.

El patrón que se observa en estos ejemplos es que lo que para unos es un bloqueo para otros son tareas a realizar para poder avanzar en el proyecto. Eso significa que un bloqueo que puedes usar como excusa para no trabajar puede convertirse en una tarea, en trabajo que puedes realizar para poder progresar en el proyecto. El llamarlo bloqueo depende de lo que aceptes que puede ser un bloqueo para ti. Puede variar según tu nivel de experiencia; pero debes de tender a tener cada vez menos bloqueos hasta que puedas trabajar sin bloqueos. Debemos aspirar a ser profesionales que encuentran una solución a todos los problemas a los que nos enfrentamos para completar los proyectos.

Robert C. Martin comentó en una de sus presentaciones que: "...lo peor que podemos hacer como profesionales es nada", cuando hablaba del tema de no estar bloqueado.

lunes, septiembre 30, 2019

Comentar lo bueno

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 programe algo similar, puedo recordar esos comentarios que hice al código de alguien más y mejorar el código que yo mismo escribo, tomando en cuenta eso que comenté en la revisión.


Pero no solo es importante comentar las oportunidades de mejora, también es bueno comentar lo bueno de lo que se está revisando. Los comentarios buenos, que no recomiendan una mejora, sino que simplemente resaltan lo se hizo bien, ayudan a motivarme para hacer un buen trabajo. No solo busco que mi código se vea bien para que no me comenten como mejorarlo, ahora también me motivo a dar un extra porque sé que el equipo lo va a apreciar. Van a notar esos detalles extras, ese plus.

A veces puedo enfocarme en revisar que todo esté bien, comentar esas posibles mejoras y sentir que ya terminé la revisión; pero me doy cuenta que así como busco lo que se puede mejorar debo también buscar lo que quedó bien y también comentarlo. Cuando encuentre lo bueno y lo malo entonces ya puedo decir que terminé mi revisión. Claro que no se trata de siempre comentar, solo cuando se amerite. Si todos los comentarios son buenos, se pueden volver irrelevantes. La idea aquí es que, al revisar, debo poner atención a lo bueno también, así como lo hago con los posibles errores u oportunidades de mejora.

domingo, septiembre 22, 2019

Trabajando remoto. ¿Desde casa u oficina?

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 y me la llevo tranquilo haciendo que pase más tiempo en el trabajo. Cuando estoy en la oficina trato de trabajar más rápido, casi sin darme cuenta lo hago. Me imagino que es porque sé que no tengo todo el día y que en unas horas debo irme a casa.

Otra diferencia son las interrupciones, aunque en la oficina también pasan, son distintas; como el resto de las personas en la oficina conmigo no están trabajando en el mismo proyecto, se puede llegar a sentir un poco como distracciones, más que las que ocurren en casa. Puede ser por lo mismo de que en la oficina siento el tiempo más limitado.

El traslado es otra característica, aun estando remoto hay traslado si voy a una oficina a "remotear". Como que aquí no tiene mucho sentido ser remoto si de todos modos me estoy trasladando a una oficina. Algunas veces me gusta porque aprovecho para escuchar música o algún podcast, disfruto manejar (si trabajo muchos días desde casa, casi no manejo). Por otro lado es agradable la semana que me quedo en casa y veo que no gasté en gasolina esa semana.

Me gusta la sensación de ir a la oficina y terminar todo a tiempo para poder irme a casa y ya no pensar en el trabajo; pero también extraño estar en casa todo el día, estar con la familia desde temprano aunque esté trabajando incluso hasta un poco más tarde.

La idea de la oficina fue tener un equipo y trabajar juntos; pero al equipo también le gusta trabajar remoto y a veces es más fácil revisar código viendo la pantalla de la otra persona compartiéndola y hablando con un headset usando herrarmientas como Slack, Zoom, Skype, etc. la otra persona y yo estamos viendo la pantalla de frente, cuando estamos en persona hay más distracciones y alguien ve la pantalla de lado.

Empiezo a dudar si es buena idea tener una oficina para equipos de desarrollo de software.

sábado, julio 20, 2019

Editor de texto obscuro y editor de texto claro


Estos últimos meses he regresado a programar tiempo completo, además de realizar tareas administrativas y administración de proyectos. Esto ha hecho que tenga que programar un rato en la mañana, luego atender unas juntas, después programar otro rato por la tarde y en las noches. No siempre estoy en el mismo lugar, por lo general durante el día voy a una oficina donde trabajo en un monitor externo y en la noches trabajo desde la laptop en mi casa.

He notado que cuando estoy en el monitor externo y la luz de la oficina está detrás de mi, no es tan intensa en la pantalla, usar el fondo de pantalla obscuro ayuda a sentir la vista cómoda mientras programo. Uso macOS y Windows, afortunadamente ambos sistemas operativos tienen un Dark Mode para esas ocasiones que prefiero usar el editor de texto con un tema obscuro.

Cuando estoy en la casa desde la laptop, ya sea una PC o la Macbook Pro, tiendo a usar el fondo claro. También ha pasado si estoy con un monitor externo que está justo debajo de un foco, el fondo obscuro en estas ocasiones no se siente cómodo. Esto es, en parte, porque me reflejo en la pantalla y siento que leo mejor si tengo el fondo claro y es más fácil navegar entre aplicaciones que tienen el fondo claro siempre, ya que hay algunas que no soportan el fondo obscuro, como Slack (también hay las que no soportan un tema claro, como Spotify).

A veces siento que debo elegir un tema, usar ese y acostumbrarme; pero no logro decidirme si solamente usar fondo claro u obscuro y en cierto modo me gusta usar los dos, de ese modo el fondo del editor no es excusa para no ponerme a programar. Algo similar me pasa con los teclados, me gusta poder usar cualquier layout sin estar quejándome como he visto a otros o como lo llegué a hacer yo mismo.

sábado, mayo 11, 2019

Trabajando bajo presión

No es raro encontrar ofertas de empleo donde como parte de las habilidades requeridas se pide trabajar bajo presión. Esto generalmente es una bandera roja. Puede ser un lugar en el que no hay un proceso definido para realizar las cosas o que los tiempos estimados son muy optimistas y por lo tanto se necesita sacar el trabajo para "ayer".

En las empresas chicas es común que haya presión por sacar el trabajo rápido. En una empresa grande es fácil pasar semanas sin trabajar y que apenas se note; pero en empresas chicas, donde el dinero y el personal es menor, es más notorio cuando el trabajo no se termina a tiempo.

Aún cuando se haya planeado todo a detalle siempre hay cosas que se salen del plan, por ejemplo: puede ser que un cliente no entrego la información a tiempo, que el trabajo era más complicado de lo esperado, el resultado que el cliente esperaba era otro y ahora necesita que se haga de otra manera lo antes posible y esto nos va afectar la fecha de entrega final, etcétera. No se puede asegurar que las cosas van a salir bien siempre y eso es parte del trabajo, no te enojes, míralo como parte del proceso. Puede ser fácil apuntar a la persona culpable de que las cosas no hayan salido bien y concentrarse en eso; pero si te concentras en eso puedes sentir frustración por pensar que tienes que pagar (con tu trabajo y tiempo) los errores de alguien más. Piensa que es un trabajo en equipo, si algo salió mal es parte del trabajo, no es algo personal.

Puedes llegar a sentir que todo urge; sentir una presión por terminar todo a la carrera, que debes apurarte para entregar. Ante estos escenarios es necesario que haya tranquilidad con la presión. Con esto no me refiero a tener un actitud desdeñosa; sino a tener una actitud calmada.


Para sentirte cómodamente con la presión debes despegarte del problema. Ve la situación como si fuera un problema que le pasa a alguien más. En ocaciones es más fácil ver la solución de los problemas de los demás. A veces es obvio como resolver el problema; pero estamos tan metidos en el problema y presionados por resolverlo que puede ser que no vemos las soluciones que están frente a nosotros. Si ves el problema desde una perspectiva despegada entonces puedes ver el problema con una actitud tranquila (como si no fuera tu problema). No siempre es fácil despegarse del problema, es cuestión de seguir practicando.

Es importante conocer las causas del problema para poder encontrar una solución. Es necesario, al buscar estas causas no concentrarnos en culpables. No se trata de ver qué persona tuvo la culpa del problema donde nos encontramos. La idea de buscar causas es entender el problema, la idea no es apuntar dedos ni estarse quejando, las quejas no ayudan, solo harán que te sientas peor. Una vez que entiendes el problema, con una buena actitud, puedes concentrate en la solución.

Debes verte como la solución al problema y hacer el trabajo necesario para arreglarlo, un paso a la vez porque no siempre se puede arreglar todo al mismo tiempo, procura que tu solución no sea trabajar toda la noche. Atendiendo el problema con calma; pero progresando en la solución es lo que puedes hacer. Siempre manteniendo la calma.

Sentirse a gusto con la presión es una habilidad de valor, si tomas esto en cuenta, esa oferta de empleo que pide que sepas trabajar bajo presión puede no ser tan mala, siempre y cuando la remuneración sea la adecuada. Trabajar bajo presión no tiene que ser estresante para ti. Si los clientes o jefes están presionados es problema de ellos. No se trata de que no te importe o que seas indiferente a sus necesidades, se trata de que mantengas la calma para pensar claro y dar soluciones. Y que logres disfrutar tu trabajo porque estás haciendo tu mejor esfuerzo por solucionar problemas. Solucionar problemas puede ser divertido.

domingo, enero 13, 2019

¿Cuándo lo tengo que terminar?


Me ha pasado que le pido a alguien que me ayude con cierta tarea de desarrollo de software y me pregunta que cuándo lo tiene que terminar. Mi respuesta generalmente es: "lo antes posible"; pero la persona que va a hacer el trabajo es quien debería de decirme cuándo considera que va a estar listo, claro que su respuesta debe estar justificada. Tampoco se trata de que invente un número.

Parece que estamos acostumbrados a que alguien más nos diga para cuándo ocupa lo que nos pide y nosotros ya veremos como le hacemos para cumplir con esa fecha. Quizás sea que esta costumbre la tenemos porque así se nos enseña en la escuela. Se nos pide un proyecto de tarea y se nos da una fecha de entrega. Es curioso; pero generalmente desarrollar el proyecto se toma todo el tiempo que tenemos... ni más, ni menos.

Se nos enseña que la persona que pide el trabajo nos dirá para cuándo lo quiere listo. No nos enseñan que como profesionales, somos nostros, los que debemos dar estimados.

Lo hacemos, también, porque al preguntar en cierta forma estamos evadiendo la responsabilidad de entregar algo completo en la fecha dada. Porque podemos alegar después que no quedó completo por falta de tiempo y sentir que no fue nuestra culpa. Podríamos decir que nos da miedo equivocarnos.

Si hacemos seguido eso que nos da miedo, después ya no nos dará miedo. Podemos intentar hacer estimados seguido.  Al principio es normal equivocarse, puede que seamos muy optimistas y después darnos cuenta que es más trabajo del previsto. Aun así debemos seguir practicado estimar el trabajo que nos piden. Incluso cuando no hay fecha límite, pensemos en: "¿Qué tengo que hacer y cuánto tiempo me tomará cada tarea?". De ese modo vamos practicando y podemos revisar al final del proyecto si tomamos en cuenta (en la estimación original) todo el trabajo que en realidad tuvimos que realizar.

La próxima vez que nos pidan un proyecto, recordaremos esos detalles que se nos pasaron en el proyecto anterior y los tomaremos en cuenta. Así cada vez, la estimación será más apegada a la realidad y en lugar de preguntar para cuándo, ahora nosotros daremos la fecha aproximada en que puede estar listo eso que nos piden, claro que siempre agregando algo de margen para los imprevistos.

jueves, noviembre 15, 2018

Email para el Seguimiento

En varios equipos de desarrollo con los que trabajo se ha dejado de usar el correo electrónico como principal forma de comunicación, para ahora usar herramientas de mensajería instantánea. Herramientas como: Skype, Slack o similares son comunes. Todo esto está bien porque permite una mayor interacción entre el equipo de desarrollo. Hay una retroalimentación rápida sobre el trabajo a realizar.

Esta mayor interacción también provoca que haya muchos mensajes que leer, de ahí surge la necesidad de tener canales o "conversaciones" específicas para cada proyecto. Sirve tener canales específicos porque así podemos ver toda la información relacionada a cierto proyecto en un solo lugar. Esto ha influido para que cada vez se use menos el correo electrónico entre los equipos de desarrollo con los que trabajo.

El problema de los mensajes instantáneos surge cuando se necesita ver el panorama general del proyecto. Es difícil dar seguimiento a grandes bloques o módulos al leer los detalles de la conversación. Herramientas de administración de proyecto ayudan a tener toda la conversación agrupada a una tarea; pero a veces hay muchos lugares dónde buscar el estatus de las tareas. A veces no queda otra que leer los mensajes del chat del día para saber cómo vamos.


El correo electrónico me sirve en esos casos porque no es tan instantáneo. Se puede incluir a varias personas en la conversación y no se necesita una respuesta de cada uno al momento. Solo con que respondan cuando tengan algo que decir y en un solo mensaje te den todas las respuestas que necesitas. A veces en los mensajes se pierde la secuencia porque contestan varios al mismo tiempo y dan una respuesta por mensaje y mandan dos o más mensajes para una sola respuesta, mientras otros hacen los mismo y ya se revolvió todo. Por correo recibes una respuesta por cada miembro del equipo e idealmente viene toda la opinión o informe que requieres de esa persona en un párrafo explicado. A veces por la flojera de pensar y dar un reporte se prefiere escribir varios mensajes de una línea y puede ser más complicado darle sentido a la idea del mensaje completo.

He notado que cada vez es más común que no revisen el correo electrónico, no es raro que tenga que avisar por mensaje que les he enviado un correo electrónico que requiere respuesta. A veces van y lo leen y me contestan por mensaje. Para mi es difícil darle seguimiento a las cosas de ese modo. Porque eso me exige, en cierta manera, estar atento a los mensajes, que pueden ser muchos.

Usando el correo electrónico puedo programar un tiempo para hacer las preguntas que necesito enviar o escribir los reportes que necesito enviar y si la respuesta es por correo entonces puedo dejar que se acumulen en mi buzón mientras sigo trabajando en otras tareas. Una vez que tenga tiempo puedo ir y procesar mi bandeja de entrada. No puedo hacer lo mismo con los mensajes.  Los mensajes distraen más y puede que si me dan los datos que necesito por mensaje, al momento que tengo tiempo de revisarlo ya han enviado muchos mensajes más y es difícil encontrarlo. Por eso prefiero las respuestas a mis correos por correo electrónico, el seguimiento es más fácil.

¿No les pasa lo mismo?