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 comodo. 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, solo usar ese y acostumbrarme; pero no logro decidirme si solo 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?

lunes, octubre 22, 2018

Micromanagement al Rescate

Hace ya un buen tiempo me tocó trabajar con un equipo de desarrollo que tenía problemas a la hora de dar resultados. Siempre había un pretexto o detalle que se les iba y por alguna u otra cosa no se entregaban las características requeridas en el programa. Este era un equipo que lo administraba el cliente directamente. Nuestra empresa solo "rentaba" a los programadores.

Algo que intentó el administrador de proyectos para "rescatar" al equipo, fue realizar lo que se conoce como micromanagement. El micromanagement (o microgestión en español) es cuando la persona encargada de administrar, o dirigir a otra, le da instrucciones al detalle de lo que hay que hacer. Esto es algo que por lo general se busca evitar ya qué es cansado para ambas partes.

Cuando supe que se intentaría "rescatar" al equipo usando micromanagement no me pareció una buena idea. Supuse que eso traería más problemas. Me comentaron que sería una medida temporal en lo que "salíamos del hoyo". Contra mis pronósticos parece que la medida dio algo de resultados. El equipo empezó a entregar tareas y quedaron expuestas las causas de los problemas del equipo, haciendo posible realizar correcciones. Algunas de. estás correcciones no tan agradables; pero fueron necesarias para bien del proyecto.

Una vez realizadas las correcciones necesarias para que el equipo funcionara mejor, se pudo regresar a un ambiente menos controlado y se pudo seguir avanzando en el proyecto.


Esa no ha sido la única vez que la microgestión nos ha ayudado a sacar adelante un proyecto. En otra ocasión me tocó a mi detener un proyecto y volverlo a empezar desde cero. Lo que hicimos para que el proyecto no se saliera nuevamente de control fue que lo iniciamos programando todos juntos en la misma maquina. Éramos un equipo distribuido por lo que todos nos conchabamos a una junta por GoToMeeting y el "chofer" compartía pantalla y empezaba a programar mientras los demás íbamos viendo. Eramos 4 personas en la llamada. Al principio me parecía un desperdicio de recursos estar los cuatro viendo como definir algunas clases; pero ahora que veo hacia atrás, creo que fue una buena decisión porque eso logro sacar al proyecto adelante.

Después de un tiempo dejamos de conectarnos para programar y cada quien trabajaba en cierto módulo; pero no permitía que subieran código fuente al repositorio hasta que lo revisara yo mismo. Al principio había varias observaciones en los commits que me solicitaban; poco a poco fueron disminuyendo. Pasado algún tiempo dejé de revisar todo el código fuente y ahora solo nos preocupábamos porque la funcionalidad estuviera ahí y pudimos trabajar sin micromanagement. Se tenía una junta en las mañanas para tener el plan del día y con eso era suficiente.

El micromanagement es algo que por lo general se ve como malo, yo mismo me he quejado de eso en este blog; pero también puede ser una práctica que puede ayudar al equipo a salir adelante en ciertas ocaciones.

jueves, julio 19, 2018

Atención al Detalle

Hay varias cosas que distinguen a los profesionales de los aficionados, una de esas es la atención al detalle. Cuando estás empezando a programar lo que te puede interesar es crear algo, que funcione y quizás eso evite que te fijes en los detalles que le harán la vida fácil a tus usuarios.

Un caso común que he visto que se omite es el de permitir al usuario usar solo el teclado para navegar en tu aplicación. Es algo que me pasó en los primeros programas en los que trabajé, sobre todo cuando el proyecto no era web, cuando era un ejecutable y en esos se debe especificar el "tab order" explícitamente. Y a veces por hacer que el programa funcionara y poder decir que ya estaba listo olvidaba verificar el orden de todos los tabs y definir labels que permitieran navegar fácilmente sin necesidad del ratón.

La atención no es solo al momento de programar, también es importante al realizar todas las  actividades de tu trabajo. La comunicación es una parte importante para el éxito de un equipo de programación. Debes poner atención al detalle de como te expresas, debes ser capaz de dar una explicación tanto técnica, en caso de ser necesaria, como una explicación que personas no técnicas puedan entender el problema y la solución que se está planteando. Debes evitar que los clientes o jefes se sientan ignorados. Contestar rápidamente a peticiones, no necesariamente con la solución, quizás solo informando que vas a investigar, es una atención a la otra persona y ayuda a la comunicación. Nadie está tan ocupado como para no poder contestar que vas a revisar lo que te piden. Y ya que lo revises, avisa. Evita que te tengan que preguntar nuevamente por cosas que ya te pidieron.

De la misma forma cuando se te pide que realices ciertas actividades como documentar es importante que pienses en la persona que va a consumir esos documentos. Dar toda la información posible para que sea de utilidad lo que escribes y que la otra persona no tenga que buscarte para pedir que aclares qué quisiste decir. A veces no te salvas de eso por más explicado que esté; pero por lo menos ya lo aclaraste para ti cuando lo escribiste.

Básicamente estoy hablando de entregar las cosas completas y bien hechas, sin detalles pendientes. Esa es la diferencia entre una persona profesional en la que se puede confiar y una persona aficionada a la que hay que revisarle todo lo que hace porque no tienes la garantía de que: lo que hizo, lo hizo bien.

La experiencia ayuda a poner más atención, cuando eres principiante es fácil pasar por alto los detalles; pero además de la experiencia, la mentalidad para hacer las cosas bien es muy importante. Ten la intensión de hacer las cosas bien terminadas, sin detalles pendientes y así lograras ser una persona profesional y confiable.

jueves, julio 12, 2018

Programando cerca de los cuarenta

Después de los 35 casi no se ven programadores...

He trabajando muchos años para una empresa de desarrollo en Tijuana, cuando entré era el más joven. Al pasar los años han llegado nuevos, se han ido otros y ahora soy de los mayores. Cuando hay una reunión la mayoría son más jóvenes que yo. Lo noto también en los grupos de usuarios o comunidades de programadores.

He notado que varias ofertas de empleo solicitan programadores jóvenes. No todas tienen limite de edad; pero si vemos a los aspirantes al puesto o incluso si nos damos una vuelta a la empresa es fácil encontrar que la mayoría de los programadores son veinteañeros.

A veces bromeo, cuando veo las ofertas de empleo que tienen un limite de edad, diciendo que después de cierta edad se nos olvida programar y por eso ya no se ven programadores mayores. Sé que no es que se nos olvide; pero entonces... ¿Por qué a cierta edad ya no se ven tantos programadores?

Creo que tiene que ver con hecho de que cualquier empleado ha sido contratado para aportar a la empresa. Aunque no estés en una posición donde te toque vender directamente un producto, la empresa te contrata para que aportes y ayudes hacer crecer la empresa. De lo que se trata es de dar algo de valor al negocio.

Al principio le puedes aportar valor a la empresa programado. Después, cuando tienes experiencia programando, quizás le aportas más valor a la empresa si le ayudas a coordinar y dirigir a los programadores más jóvenes. O quizás sea importante que ayudes a la empresa a hablar con los clientes y "traducir" lo que el equipo de desarrollo quiere comentarles. Al tener una mayor madurez es más fácil entender ciertas cuestiones del negocio y puedes ayudar a interpretar los requerimientos del cliente y convertirlos en acciones concretas que el programador joven pueda realizar.

Leo seguido en blogs que: no nos contratan para escribir código, que nos contratan para dar soluciones.  Es cierto, no es el código que escribes lo que quiere tu empleador o cliente, es lo que se puede hacer con el código lo que interesa. De igual forma, al tener cierta experiencia esa experiencia puede aprovecharse para ayudar a dar mejores soluciones a la empresa, aunque eso implique que no te quede mucho tiempo para programar a ti.



Es importante estar de cerca al código, para no ser irrelevantes en los aspectos técnicos; pero como programadores llegando a los cuarenta no debemos tener miedo de dejar de programar para aportar a la empresa de otra manera. Quizás ahora en lugar de programar código nos toque programar reuniones...