Forem: Dennis Tobar

Un código feo pero útil es mejor que un código bien organizado pero sin uso

Dennis Tobar — Mon, 13 Apr 2026 16:07:34 +0000

La belleza excepcional del código fuente es aquella que logra ser clara en lo que hace.

En la construcción de código, siempre nos enfrentamos a crear elementos de apoyo que son los que nos permiten escalar soluciones (fáciles o no tanto) en el futuro.

Pensar bien en el presente nos hace tener cimientos sólidos para que siga creciendo el software en el futuro. Con cada decisión podemos ir abarcando mejor la evolución del software, pero, en ocasiones, ese romanticismo del código "bien estructurado" compite directamente con el código que debe hacer lo que tiene que hacer.

Me ha tocado en un par de ocasiones hablar con personas que no comparten su código en forma libre diciendo: "está mal hecho" o "no seguí normas". Yo también fui parte de ese grupo. Con el tiempo comprendí que un código mal escrito (sin formato, normas, etc.) es, en ocasiones, lo que permite que un experimento o una idea loca se aplique y validar si funciona o no.

Obviamente, después hay que dedicar tiempo a embellecerlo o al menos, asegurar que si un próximo humano que lo lea, comprenda qué es lo que se trae entre manos el código.

¿Cuál es mi postura?

Validación primero, belleza después: Si el código hace lo que debe, ¡celebramos con un café! Ya habrá tiempo para refactorizar y "embellecerlo" para el próximo humano que lo lea.
Cero vergüenza: Compartir el código "sucio" es un acto de honestidad técnica. Permite detectar errores antes y colaborar sobre la realidad, no sobre una quimera de perfección.
Cimientos, no adornos: Prefiero mil veces un sistema con cimientos firmes y terminaciones rústicas, que un edificio de cristal con bases de arena.

No hay que sentir vergüenza por lo hecho: si hace lo que queremos ¡bien!, podemos tomarnos un café e ir a celebrar.

Resiliencia vs. Perfección: Por qué tu sistema debería saber fallar

Dennis Tobar — Tue, 07 Apr 2026 13:55:00 +0000

El optimismo ciego es negligente, pero el pesimismo extremo es una receta perfecta para la parálisis.

El mito del "Mundo Ideal"
Casi todo en el software se basa en instancias donde todo funciona "según lo planeado": las redes no fallan, los datos son perfectos y los procesos no tienen desviaciones. Pero la realidad nos supera:

Datos sin máscara de ingreso.
Personas sin segundo nombre.
ISBN con códigos incorrectos.

Prever cada error es imposible; toma tiempo y recursos que no tenemos. Quizás la fórmula mágica sea generar caídas inteligentes.

Degradación controlada y UX
Debemos construir momentos donde el sistema identifique que no puede seguir y ejecute una caída de emergencia controlada. No es lo mismo un "Error interno" que explicarle al usuario qué validar para que su aterrizaje sea tranquilo.

Si el sistema falla, que sea una degradación controlada que nos permita medir el problema y solucionarlo rápido.

Menos reglas, mejores cimientos
Un sistema no es mejor por tener 10 capas de validación que lo vuelven inutilizable. Se trata de tener las reglas correctas para operar con confianza ante la incertidumbre.

¿En tu equipo están invirtiendo tiempo en prevenir lo imposible o en ser resilientes para cuando lo inevitable ocurra?

Publicado originalmente en LinkedIn
Imagen creada con IA

Aprende a pelear tus batallas

Dennis Tobar — Fri, 30 Aug 2024 13:09:12 +0000

En nuestra vida como personas, tendremos muchas veces que colaborar con otras para lograr nuestras metas y objetivos. Nuestra naturaleza humana nos lleva a tener ideales, sueños y metas propias. Todos anhelamos algo y deseamos cumplir nuestros objetivos, considerando que siempre nos relacionaremos con alguien más.

Es en este contexto que la vida nos lleva a integrarnos a grupos desde pequeños: la escuela nos impulsa a trabajar en equipo o a hacer amistades. Siempre estaremos en grupos, aunque no siempre podamos elegir a sus integrantes.

Todos somos únicos e irrepetibles, con nuestras virtudes, defectos e historias personales distintas. Por lo tanto, llegar a un consenso puede ser difícil cuando hay posiciones extremas. En estos casos, es importante aprender a negociar y entender que no siempre se gana todo. A veces, ambas partes deben ceder para lograr un acuerdo satisfactorio.

Conócete a ti mismo

¿Cómo podemos negociar si no nos conocemos bien? Este paso es fundamental para saber qué estamos dispuestos a ceder y qué no en una negociación, y en general, en la vida.

Conocer tus fortalezas y debilidades te ayudará a identificar qué puedes negociar y cómo te afectan ciertas propuestas. Por ejemplo, si eres muy disperso, quizás no seas el más indicado para liderar una negociación.

Tus valores también son importantes, ya que guían tus decisiones. Si alguien te propone algo que va en contra de tus principios, ¿estarás dispuesto a ceder?

Aprende a comunicarte

La comunicación efectiva es clave para cualquier negociación. No solo debes saber expresar tus ideas claramente, sino también escuchar activamente a los demás. ¿cómo podemos debatir si nos vuesta escuchar? o ¿cómo planeamos mostrar nuestro punto de vista si no nos involucramos en la conversación?

Escuchar activamente significa prestar atención a lo que el otro dice, sin interrumpir y sin juzgar. También implica intentar comprender su punto de vista, aunque no estés de acuerdo.

La asertividad es otra habilidad importante. Asertivo significa ser capaz de expresar tus opiniones y necesidades de manera clara y respetuosa, sin ser agresivo ni pasivo.

Desarrolla el pensamiento crítico

El pensamiento crítico te ayudará a analizar las situaciones de manera objetiva y a tomar decisiones informadas.

Ponerte en el lugar del otro te permitirá entender mejor su perspectiva y encontrar soluciones que satisfagan a todos.

Evita las emociones fuertes durante las negociaciones. Tómate un tiempo para pensar antes de responder y evita hacer comentarios hirientes.

Ideas concretas

Practica la escucha activa: Dedica tiempo a escuchar a los demás sin interrupciones.
Identifica tus fortalezas y debilidades: Haz una lista y reflexiona sobre cómo puedes aprovecharlas en una negociación.
Define tus valores: Clarifica qué es importante para ti.
Prepara tus reuniones: Anticipa posibles preguntas y objeciones.
Sé flexible: Está dispuesto a ceder en algunos puntos para alcanzar un acuerdo.
Mantén la calma: Evita las discusiones acaloradas.

Imagen | Obtenida por IA desde Microsoft Designer

Gestiona tu tiempo y las prioridades

Dennis Tobar — Sat, 27 Jan 2024 20:39:05 +0000

El tiempo es realmente el único capital que tiene cualquier ser humano, y lo único que no puede permitirse perder.
Thomas Edison

Cuando estamos realizando cualquier tarea, sea laboral o no, aparecen en muchas ocasiones subtareas o nuevas cosas que hay que hacer que a simple vista parecen ser efectos colaterales de una lista de tareas. En algunos casos la lista de tareas se ve rápidamente inundada por varias subtareas, las cuales conforman una tarea grande. Es decir, una tarea grande que se dividió en varias tareas pequeñas ahora exige su tiempo al juntarse con las tareas pequeñas de otra tarea grande.

Un ejemplo de esto lo podemos encontrar en las tareas del hogar en pandemia, o en el caso de quienes estamos con teletrabajo: las tareas del trabajo se mezclan con las tareas del hogar, y al intentar picar las tareas en pequeñas tareas, se nos mezclan un poco los mundos y roles. Al finalizar el día hemos visto que no hemos logrado nada... hay un caos organizacional.

Ordenemos la casa... y los juguetes

En el libro Make Time, los autores apuntan a que debemos guardar los juguetes antes de irnos a dormir, es decir, ordenar nuestro día, terminar de cerrar la puerta de la oficina o cerrar la sesión del computador con el fin de terminar la jornada laboral y comenzar a vivir otra de nuestras facetas.

Los autores nos invitan a que al final del día hagamos una pequeña introspección de lo que hicimos, actualicemos nuestro diario laboral y dejemos anotado lo que queremos hacer temprano o durante el día siguiente. Esta invitación nos permite tener el efecto de cerrar el día, muy útil si estás trabajando de casa y no sueltas el computador, y comenzar a vivir otras dimensiones de la vida.

¿Qué es un diario laboral y para qué nos sirve?

Un diario laboral es nuestra memoria escrita que nos ayuda a registrar lo que haremos en el futuro, lo que hemos hecho en el presente y revisar lo que hicimos en el pasado. Este diario no solo debe ser una agenda para anotar cosas laborales, sino que también pueden ir emojis o estrellas que nos ayuden a revisar día a día cómo iniciamos la jornada, cómo nos vamos, nuestras victorias y nuestras derrotas.

Recomiendo que este diario sea escrito con puño y letra, ya que esto nos ayuda a centrarnos en nuestro trabajo. Al cabo de un mes, cuando hagamos una retrospectiva personal, podemos celebrar las cosas que salieron bien, identificar las áreas de mejora y tener un lugar donde ver emojis de cómo nos sentimos con el trabajo: si vemos 6 meses de caritas tristes o enojadas es una señal.

Esto es un insumo clave para ir mejorando nuestro trabajo, no tan solo para la empresa, sino que con uno mismo, es verse cómo vamos creciendo y superando nuevas metas.

Planifica, resulta más cómodo

Al inicio de nuestra vida laboral, uno cree que, por tener una persona que lidera un equipo, debemos hacer todo lo que nos indica en el orden esperado, sin tener un espacio para autoorganizarse. Sin embargo, esto es falso, ya que todos tenemos un espacio para poder planificar, desde cosas muy simples hasta cosas más complejas.

Por ejemplo, podemos planificar nuestro día, nuestros descansos, nuestro ritmo de trabajo, los puntos que hay que ver en el orden propuesto, priorizar una determinada función. Lo importante es que nunca perdamos de vista que nos han encargado una labor, y que tanto nuestro líder como nuestro equipo esperan que la cumplamos en el plazo.

Planificar ayuda a seguir una secuencia de pasos, a generar más pasos que debemos cumplir y a mejorar nuestro enfoque en "lo importante" del día. El ir por el mundo sin una planificación nos genera un mundo más espontáneo, pero a la vez más incierto. Por ejemplo, si te preguntan "¿qué vas a hacer hoy?", no puede haber una duda o una respuesta de "no sé", ya que denota que no has podido observar qué hay que hacer en el trabajo. Por eso, detente y planifica una secuencia de pasos.

Aprende a decir que no y a descansar

El impulso de terminar el trabajo, el entusiasmo que uno le pone al código e incluso saber que estamos en una racha de desarrollo no deben ser excusas para decir "no" en determinados casos.

Como es parte del ADN de los trabajadores, hay personas que creen que la palabra "no" está fuertemente arraigada en su ser, y que por la dependencia de poder, el "no" solo puede venir de parte de los jefes y líderes. Sin embargo, en realidad cualquier persona puede ejercer el "no", solo que hay que tener dos cosas claras:

Tienes un argumento de peso para decir "no".
Tienes que decirlo con tacto.

En ocasiones me he encontrado con colegas que dicen "no" de forma cerrada, es decir, sin motivos. El jefe frunce el ceño y lo anota en su "lista negra imaginaria" por decir "no". Mientras que otros, en especial quien me enseñó a decir "no", me decían que con un argumento de peso o claro no basta, sino que hay que decirlo con tacto, pero sin rodeos.

No puedo hacer ese código ya que tengo una cola de tareas bastante larga, y necesito tiempo para poder reducir la cantidad de tareas pendientes. Sugiero que lo hables mañana con el equipo a ver quien puede asumir la tarea.

Otra cosa que también debemos valorar es el descanso, ya que estamos en pleno apogeo de desarrollo y creemos que el código va espectacular. Sin embargo, las leyes de la física dicen que "todo lo que sube tiene que bajar". Cuando llega ese bajón anímico o de productividad, es una deuda bastante grande que debemos pagar por el cansancio acumulado durante el apogeo de desarrollo. ¿No sería mejor extender ese apogeo por algunos días más si descansamos adecuadamente? Desde luego que sí. Por eso, te invito a saber descansar todos los días, así como a dejar tiempos de descanso en tu día. Tu cerebro te lo agradecerá, en especial si te tomas 15 minutos cada hora para soltar el teléfono, el computador y aburrirte sin sentirte culpable por no hacer nada.

El trabajo nunca acaba

Sientes que estás llegando al final de la lista de trabajo y dices "¡yay, menos para ser feliz!", pero en el computador de tu líder o jefe ya hay una planilla de Excel con tu nombre y 10 tareas más. El trabajo nunca acaba, y como tal, debemos esforzarnos para sacar consistentemente tareas todos los días, en función de la complejidad. Sin embargo, y desde ya, hay que mentalizarnos de que el trabajo nunca acaba, ya que siempre hay un botón nuevo, una nueva imagen que subir, un error que corregir, o el cliente quiere XYZ en la interfaz W.

En algunos ambientes se demoniza a quien no ha hecho todas las tareas y se va del lugar de trabajo. Esto nos hace sentir culpables si de 5 tareas planificadas solo sacamos 3. La invitación es a ver el vaso medio lleno: ya son 3 cosas menos que hacer del trabajo. Y aunque tu cola de tareas hubiera 1 sola tarea y no lo lograste, aún así, uno no debe partir sin culpa si conscientemente le dedicó tiempo al trabajo (muy distinto es la procrastinación).

Resumen por Bard

Guarda los juguetes: Termina tu día laboral y comienza a vivir otra faceta de tu vida.
Lleva un diario laboral: Es tu diario de vida, tu memoria escrita que te ayuda a anotar lo futuro, marcar lo que has hecho en el presente y revisar lo que hiciste en el pasado.
Planifica: Ayuda a seguir una secuencia de pasos, a generar más pasos que debemos cumplir y a mejorar nuestro enfoque en "lo importante" del día.
Aprende a decir que no y a descansar: Di no con tacto cuando tengas una cola de tareas bastante larga, y descansa todos los días para evitar el agotamiento.
Mentalízate que el trabajo nunca acaba: El trabajo siempre tendrá algo nuevo que hacer, así que céntrate en sacar consistentemente tareas todos los días.

Ideas concretas

Lleva un registro de tu día a día. No hay fórmula o mecanismo perfecto... inventa sobre la marcha y haz lo ajustes que más te sirvan
Tienes derecho a aburrirte tranquilamente: anda caminando un día sin audífonos por la calle, date una vuelta un poco más larga para llegar a tu trabajo o siéntate a ver las nubes o escuchar la lluvia por algunos minutos...
Elimina las distracciones: ¿el teléfono vibra cada cierto rato?, en silencio se ve mejor... al menos por 30 minutos

Imagen | Generada por deepai.org en base al título del post

La colaboración como parte del proceso

Dennis Tobar — Thu, 18 Jan 2024 16:46:30 +0000

En la larga historia de la humanidad (y del mundo animal también), aquellos que aprendieron a colaborar e improvisar de la forma más efectiva han prevalecido.

Tercer post de 55, ¡vaya que será un año largo! En esta ocasión escribiré un poco de un tema que me encanta: la colaboración como parte del proceso de desarrollo de software. En sí, el ser humano está destinado a pertenecer a un grupo de personas. Es muy difícil que alguien logre la magnificencia por sí solo, sino que requiere un grupo que lo apoye.

Un ejemplo burdo, pero que ilustra bien el punto: el Rayo McQueen, en la carrera que nos introduce a Cars, no ganó la Copa Piston debido a que despreció a su equipo y dijo "soy un espectáculo de un solo hombre". Luego, como es habitual en las películas de Pixar, se nos muestra la redención del Rayo, con amigos de Radiador Springs y siendo respetuoso con el Rey.

Es por eso que hoy, ahondaré en qué significa colaborar, los desafíos y las ventajas que tenemos al colaborar con las personas en el desarrollo de software.

La colaboración en el desarrollo de software

Siempre que comenzamos una nueva tarea, idea o proyecto, nos encontramos con la necesidad de compartir con alguien más nuestros pensamientos para comprobar que estamos en lo correcto. Esto nos permite confirmar, desmentir o descartar una idea preconcebida por nuestro cerebro.

La colaboración es la forma en que encontramos para trabajar juntos con el fin de lograr una determinada tarea. Desde las parejas que recién están viviendo juntas hasta milicias con miles de efectivos, todos constituyen equipos de trabajo. Estos equipos deben contar con algunos principios rectores:

Identificar la tarea por hacer y cómo se logra el éxito: ¿Qué hay que hacer?
Contar con una persona que funja de líder o cabecilla del grupo: ¿Con quién coordinamos los esfuerzos?
Contar con una estrategia para abarcar la problemática: ¿Cómo lo haremos?

Desde luego, existen otros principios rectores de la colaboración, pero estos son los más básicos. Nos permiten identificar qué tipo de trabajo y sus objetivos. La colaboración, por lo tanto, consta de una problemática, personas y objetivos.

Cómo lo hacemos en el software

La colaboración en el software no dista mucho de la colaboración en otros ambientes laborales, sino que considera ritmos distintos y formas diversas de ponerse de acuerdo. En general, hay diversas metodologías que ponen diversos liderazgos en las conversaciones o roles. Para sintetizar, siempre hay un líder por parte de los clientes, así como un líder por la parte del equipo de desarrollo. Ambos liderazgos son encargados de poder representar los intereses de ambas partes.

Hace un par de semanas, escribía acerca de la importancia de tener una comunicación fluida entre ambas partes y la posibilidad de la colaboración para lograr que el proceso informático llegue a buen puerto. La colaboración es el puente que nos permite idear y centrar nuestras ideas en pos del bien común: la solución del problema a cambio de dinero.[1]

En el software no podemos pensar en que todos somos partícipes de las mismas discusiones o las mismas decisiones, sino que hay diversos niveles y mecanismos de colaboración, ya que cada persona tiene una responsabilidad distinta con el equipo y para el equipo de trabajo.

Lo importante es que cada persona conozca bien su rol, su deber y responsabilidad con el resto de los pares del proyecto, grupo o equipo: nadie debe estar a la deriva o sin asignación por falta de coordinación.

¿Cuáles son los desafíos en la colaboración?

Como elaboraba en el primer post, existen desafíos de comunicación, gestión de conflictos y creación de una cultura organizacional que nos permita aportar con libertad y confianza al propósito común.

La comunicación: La comunicación es esencial para la colaboración eficaz. Los equipos colaborativos deben establecer canales de comunicación claros y eficaces para compartir información y resolver problemas.
La gestión de conflictos: Los conflictos pueden surgir en cualquier equipo, pero pueden ser especialmente problemáticos en los equipos colaborativos. Los equipos colaborativos deben tener un proceso para gestionar los conflictos de manera constructiva.
La cultura organizacional: La cultura organizacional puede influir en la capacidad de los equipos para colaborar eficazmente. Los equipos colaborativos deben tener una cultura que fomente la colaboración y el trabajo en equipo.

Estos desafíos deben ser abordados por las personas que interactúan entre sí, y no deben darse necesariamente por estructuras externas. Es decir, casi la autoorganización que nos deja entrever los principios del Manifiesto Ágil, donde cada equipo y participante del grupo es partícipe activo en la gestión de tareas y del cambio en función del objetivo que se necesita lograr.

No existen equipos que no colaboran, sino que colaboradores que no se sienten parte del equipo

En general, como la mayoría de los posts de esta primera parte, apunto a la persona: cada una es única e irrepetible, por lo cual debemos ser conscientes de que cada una es un mundo y posee diversos valores, principios, problemas y virtudes.

Así como existen personas que se entregan por los demás en forma gratuita, abren caminos ante los problemas y están atentos a las necesidades de los demás, también hay personas que solo se dedican a su trabajo, sin compartir más allá de lo que sea necesario. Son verdaderas islas de conocimiento. Ambas formas de trabajar son valoradas y respetadas, ya que hay personas que son celosas en cómo se muestran a sus colegas, como personas que son muy abiertas en sus relaciones laborales y personales.

Hay que considerar que el llamado a colaborar debe ser en tonos inclusivos para todas las personas. Se debe dar la libertad de compartir y expresar ideas sin recriminación y sin objeto de burlas, por muy mala idea que parezca. A veces, dos ideas malas pueden formar una gran idea. Aquí la invitación a mantener el respeto y a dar el espacio para que todas las voces puedan ser escuchadas y representadas en función de la pertinencia de la discusión.

El sentirse parte de un equipo no significa que uno deba inmolarse por el equipo, pero sí debe manifestarse en el compromiso y el acuerdo común de lograr alcanzar el objetivo que se ha puesto en común. Si no, se pierde la necesidad de contar con un equipo.

Por último, no olvidar que hay personas que son introvertidas. Por lo tanto, brindar ese espacio de discusión en ocasiones puede ser hasta muy molesto para este tipo de personas. Debemos contar con más mecanismos para poder manifestar nuestras ideas con tranquilidad. Quizás en un foro común, una anotación en una tarjeta de un tablero Kanban o buzón de ideas. Hay que buscar ese medio.

¿Cómo podemos colaborar mejor o practicar la colaboración en nuestros espacios?

Este tema nunca es fácil de plantearnos, ya que antes debe existir un momento base o momento cero sobre el cual debemos partir haciendo pequeñas mejoras progresivas para ir evaluando cómo mejorar, qué cambiar y qué no repetir a futuro.

Lo que tenemos que tener claro es realizar un diagnóstico de nuestra situación actual, situando métricas cualitativas y cuantitativas de cómo es nuestra colaboración. Esto permitirá saber qué podremos priorizar en el corto, mediano y largo plazo, así como fijarnos en cómo podemos medir nuevamente en un plazo razonable (por ejemplo, 3 meses).

Tras el diagnóstico podrían salir algunas de estas ideas...

Invertir en formación: La formación puede ayudar a los equipos a desarrollar las habilidades necesarias para colaborar eficazmente, no solo usando mejores herramientas, sino también en la formación de habilidades conductuales (blandas o soft skills) para mejorar nuestra expresividad de ideas o conexión de las mismas.
Revisar los ciclos de reuniones de equipo: Comprobar si es necesario menos reuniones, pero de más calidad en lugar de pocas reuniones pero sin fundamento del porqué hacerlas.
Utilizar las herramientas y técnicas adecuadas: Los equipos deben utilizar las herramientas y técnicas adecuadas para apoyar la colaboración, no solo para resolver problemas, sino también para generar confianza entre los participantes del equipo. No podemos confiar en desconocidos.

Resumen (por Bard)

La colaboración es esencial para el éxito en el desarrollo de software. Permite a los equipos compartir ideas, conocimientos y recursos para crear soluciones de alta calidad.
Existen tres desafíos principales a la colaboración en el desarrollo de software: la comunicación, la gestión de conflictos y la cultura organizacional.
Los equipos colaborativos deben tener canales de comunicación claros y eficaces para compartir información y resolver problemas. También deben tener un proceso para gestionar los conflictos de manera constructiva.
La cultura organizacional debe fomentar la colaboración y el trabajo en equipo. Esto significa crear un entorno de confianza y respeto donde todos los miembros del equipo se sientan valorados y escuchados.
Para mejorar la colaboración en el desarrollo de software, los equipos deben realizar un diagnóstico de su situación actual y desarrollar un plan de acción. Este plan puede incluir medidas como la formación, la revisión de los ciclos de reuniones y el uso de herramientas y técnicas adecuadas.

Consejos concretos

Destina un viernes en la tarde a hacer un ejercicio de revisión de la semana: no sacas mucho reunirte para delegar trabajo, sino que úsalo para cerrarlo.
Lleven un registro común de tareas que deben realizar, aunque no sean del mismo proyecto, así podrán saber qué está haciendo cada uno (Tablero Kanban es el ejercicio visual simple que podemos obtener)
Da tiempo para que todas las personas puedan opinar en un tema o consulta concreta, así como dejar abierto un canal secundario en caso de necesitar privacidad o un medio para compartir ideas más complejas.

Notas

[1] Y satisfacción personal, obvio 😅

[2] Sino, recordemos a la persona que vendió piedras como mascotas, una idea tonta que le dio US$ 2 millones... vendiendo piedras

[3] Método Kaizen, por Asana, lectura recomendada si quieres mejorar un poco en un plazo fijo, por ejemplo, el nacimiento de esto se debe a la reflexión interna y cómo ir mejorando un poco más la habilidad comunicativa de escribir 💓

Entregar y recibir feedback de calidad

Dennis Tobar — Fri, 12 Jan 2024 14:45:59 +0000

“La clave para aprender es la retroalimentación. Es casi imposible aprender algo sin ella”.
Steven Levitt.

Segundo post y hoy hablaré un poco acerca de cómo entregar y recibir feedback o retroalimentación de calidad y de forma positiva. Este post resumirá algunos aspectos claves de cómo ejercitar correctamente nuestra forma de comunicación más usual que poseemos a la hora de corregir tareas.

De por sí, el feedback es una herramienta esencial para el desarrollo personal y profesional, pero ¿cómo podemos dar y recibir retroalimentación en forma efectiva y de calidad?

¿Qué es una retroalimentación y porqué es importante?

La retroalimentación es una parte esencial, no solo del desarrollo de software, sino también de la vida en general. Es el mecanismo con el cual recibimos una confirmación de que nuestras acciones o pensamientos están bien realizados o son necesarias correcciones.

Cuando hablamos de desarrollo de software, tendemos a pensar que es exclusiva cuando realizamos un Pull Request (o Merge Request o mergear el código) y esperamos que una persona nos confirme que el código está bien. Sin embargo, también hay otros momentos donde aparecen las retroalimentaciones, como en la toma de requerimientos o en los resultados de las pruebas.

Por ejemplo, en la toma de requerimientos, es importante que los desarrolladores reciban retroalimentación de los usuarios para comprender sus necesidades y expectativas. En los resultados de las pruebas, es importante que los desarrolladores reciban retroalimentación de los testers para identificar y corregir errores.

Las retroalimentaciones son importantes porque nos permiten confirmar que las decisiones y cambios que estamos haciendo están en el camino correcto o debemos enmendar el curso para poder satisfacer las necesidades de nuestros usuarios. Este paso es necesario, ya que nuestro análisis podría haber dado 5 tareas y pensar que tenemos las 5 tareas listas, pero en realidad 1 ha presentado errores, por lo cual se hace necesario escuchar el problema y presentar un cambio para solucionarlo.

Entonces, si es algo que nos permite mejorar, ¿por qué debemos ejercitar una cultura de retroalimentación constructiva?

La retroalimentación te cambia la vida... en todo sentido

Las palabras tienen el poder suficiente para crear realidades, no imaginemos como los encantamientos de Harry Potter, pero sí poseen la capacidad de cambiar el comportamiento de las personas en función de las palabras y el tono en que se usen para poder entregar un mensaje o una retroalimentación.

Es posible que sientas que tu trabajo es bastante completo y prolijo, pero a la hora de la revisión es posible que no esté perfecto, quizás solo bien, pero a los ojos del revisor, que en ocasiones puede ser implacable, está todo mal y nada funciona. Por lo cual, se hace necesario que ante esta negativa podamos hacer un cambio positivo en la vida de la persona que está solicitando la revisión.

No está demás recordar que, al igual que el arte, la informática tiene una componente creacionista bastante grande, por lo cual en ocasiones, alterar el producto original podría desembocar en una serie de emociones y sentimientos negativos desde la persona que solicita la revisión. El famoso ego trastocado que se manifiesta.

Por tanto, la retroalimentación puede producir un cambio en la vida de la persona revisada, ya que en función de lo indicado como comentarios o sugerencias, la persona tendrá un cambio de comportamiento en relación a la parte previa de la revisión. Puede ser una persona que acepte, negocie o niegue los cambios propuestos, ya que su ego se ve afectado tanto por no haber entendido el problema como por el hecho de que su obra está siendo modificada.

Demos retroalimentación constructiva

Una retroalimentación constructiva es una conversación o mensajes que nos permiten indicar de manera abierta, honesta, específica y respetuosa los puntos de mejora o corrección sugeridos, siempre recordando que se revisan acciones realizadas o decisiones tomadas, y que no es un proceso para criticar o hacer sentir mal a la persona que solicita la revisión.

Antes de comenzar una retroalimentación, y habiendo revisado el trabajo entregado, debemos pensar qué queremos decir:

¿Qué puedo destacar del trabajo?
¿Qué funcionó bien y qué sugerencias de correcciones puedo dejar?
¿Son relevantes las sugerencias o simplemente es ser quisquilloso o quisquillosa?

Estas preguntas nos permiten identificar qué queremos comunicar, idealmente en positivo, a la persona a la que tenemos que entregar su retroalimentación.

Cuando ya tengas listos tus comentarios, te sugiero elegir un momento ideal para hacerlo (no, 5 minutos antes de terminar la jornada no es un buen momento), donde se pueda generar un espacio de tiempo necesario y de calidad donde se pueda propiciar una conversación. En cambio, si es un comentario escrito, evalúa enviarlo durante la jornada laboral, quizás a media mañana o tras el almuerzo, para que la persona sienta la oportunidad de leerlo tranquilamente.

Para estructurar tu mensaje, la invitación es a comenzar con lo positivo que se ha revisado, lo que resultó de la revisión y qué cosas nos sorprendieron de lo realizado ("una buena implementación del algoritmo", "no sabía que se podía hacer con Y y funcionó de maravillas").

A la hora de comenzar a apuntar a los aspectos que no funcionaron o negativos, en lugar de solo indicarlos, también es tu deber y responsabilidad con la otra persona de dar espacios y sugerencias de mejoras en tonos constructivos, centrándote en aspectos laborales y no en cómo es la persona ("creo que la forma en que lo abordaste podría funcionar en otros contextos, pero acá te conviene seguir Z... si no sabes cómo hacerlo, puedo contactar con Y para que dé algunos consejos").

Al finalizar, establece una pauta o una guía que nos permita saber que las recomendaciones serán realizadas, por ejemplo, anotar los compromisos adquiridos, las mejoras propuestas y ponerse de acuerdo de cuándo volver a evaluar si los nuevos cambios funcionaron o no.

Recibamos retroalimentación

Sí, la informática puede lastimar el ego. Desde ese PR que es rechazado por ser incompleto hasta requerimientos mal implementados porque no entendimos al cliente. Si no te gusta sentir tu ego lastimado, creo que la carrera no es para ti.

Ya que subiste ese PR y ves el comentario de "No, tu código no será fusionado", siempre debemos estar dispuestos a escuchar los motivos del rechazo o lo negativo que hemos hecho. Debemos practicar la escucha activa, o con atención, de lo que nos dicen. En ocasiones nuestro cerebro se cierra a que "yo tengo la razón", pero por lo general esa falta de empatía y capacidad de escuchar por la negación hace que la frustración salga a flote. Por tanto, cuando veas la cruz roja o el momento de escuchar lo negativo, intenta no cerrar tu mente. Es todo lo contrario, es abrirla para entender qué podemos hacer mejor.

No entendí eso de chequear los enteros

Si tienes una duda, no te quedes con la pregunta, ¡haz la pregunta! La retroalimentación es útil si tú también puedes entender lo que te están diciendo. Es mejor pecar por preguntar que pecar por ignorancia. Además, es gratis y es una conversación o una comunicación que te está ayudando a ser una mejor persona o un mejor trabajador. No son solo palabras al viento "por que sí". Es la instancia donde pueden compartir conocimiento, experiencia y hablar de código. Ambos están ahí porque les llama la atención, les gusta o son personas buenas para programar. No desperdicies tu oportunidad.

Por último, considera estas dos cosas:

No es un proceso de evaluación de cómo eres como persona. Siempre hablamos del trabajo.
Es posible que seamos desordenados para programar, pero a la hora de presentar nuestro trabajo debemos ser lo más pulcros posible, para que la evaluación se centre en lo que hicimos y no sea un juicio de valor de nuestro ser o creencias y vivencias.

Las retroalimentaciones son procesos de aprendizaje y conversación, por lo cual no "hay que tomarse todo a pecho". Hay que meditar lo que nos han dicho.

"tu código es desordenado", podemos consultar cómo ordenarlo
"no es la solución que esperaba", ¿me ayudas a saber cómo la harías?"

Seamos agradecidos del proceso

Quienes brindan retroalimentación deben practicar constantemente la compasión, el entendimiento y la reflexión activa sobre cómo comunicar lo bueno, lo malo y lo mejorable de algo. Por su parte, quienes la reciben deben considerar practicar la paciencia, la comprensión y adoptar la actitud de mejora continua.

Este proceso no nace ni está enraizado en nuestra labor porque debe existir, sino que debemos verlo como un espacio de aprendizaje conjunto, en el que ambas partes ganan.

Resumen (por Bard)

Para dar retroalimentación de calidad, debemos:

Centrarnos en el trabajo, no en la persona.
Ser específicos y concretos en nuestros comentarios.
Ofrecer sugerencias de mejora.
Elegir un momento y lugar apropiados para dar la retroalimentación.

Para recibir retroalimentación de calidad, debemos:

Estar abiertos a escuchar comentarios negativos.
Hacer preguntas para aclarar lo que no entendemos.
No tomarnos los comentarios a pecho.

Consejos concretos

No abuses de la posición de dominancia o experiencia a la hora de dar feedback
Siempre hay algo positivo qué destacar, ¡recuérdalo!
Recuerda que en ese código o análisis hay tiempo invertido, ¡no lo desperdicies ni lo menoscabes!
Todos fuimos juniors o aprendices un día, ¡sé un buen guía a quien está comenzando!
Anota en columnas las cosas buenas, malas, mejorables y lo que no entendiste. Añade un pequeño espacio para acciones concretas que tomarás como retroalimentador (hacer que lea X o hablar con Y para que lo guíe).

Notas

[1] Imagina cuántas veces se acuerdan de nuestras familias cuando "fallan los sistemas"... aunque la culpa no es del sistema informático

[2] Obviamente si no estás pagando un servicio de QA o coaching.

[3] Aprendemos a la fuerza, pero en general no existen los linters cuando iniciamos nuestro camino... después aparecen los linters y otras lindas herramientas, pero al principio muchos creen que "estamos hackeando Facebook con una lata de Monster"

Imagen por deepai.org al poner el título como prompt

La importancia de la comunicación en el desarrollo de software

Dennis Tobar — Thu, 04 Jan 2024 14:00:00 +0000

Lo que no se comunica no existe.

Este primer post de la serie tratará acerca de la comunicación como eje articulador del desarrollo de software. Esta disciplina humana requiere que las personas seamos capaces de establecer lazos de comunicación con el fin de resolver algún problema o satisfacer alguna necesidad, ya sea una necesidad empresarial, personal o simplemente la curiosidad de establecer alguna forma de trabajar.

El ser humano es un ser netamente social: necesitamos del otro para poder meditar, pensar, aplicar y resolver problemas de esta índole o de otra especie de problemas. Desde siempre, yendo a nuestros ancestros, el ser humano ha estado organizándose en tribus o en clanes para poder sobrevivir. Antiguamente era para que los depredadores no nos comieran; actualmente es para estar insertos en la sociedad y progresar en conjunto (o al menos eso se supone…).

¿Qué implica comunicarse en el desarrollo de software?

La comunicación es un elemento básico para las relaciones humanas. El nacimiento de un sistema, pantalla o elemento de software siempre nace de la necesidad de alguien más, ya sea por automatizar un proceso manual, mejorar flujos de trabajo o resumir un gran volumen de información para obtener resultados que le ayuden en su toma de decisiones.

El hecho de comunicarse en el desarrollo de sistemas tiende a verse solo como escuchar lo que debo hacer, pero no sé cómo hacerlo ni qué implica hacerlo. Esto guarda un peligro a la hora de implementar una solución, ya que las personas tienden a tener áreas de conocimiento diversas, lo que varía desde el tipo de lenguaje usado, más o menos profesional, hasta el detalle de lo que buscan. Cada persona entiende y comprende el mundo de distintas formas: no es lo mismo un gerente de ventas que un vendedor. Mientras el primero requiere conocer volúmenes de ventas, stock de productos y tendencias de mercado, el segundo solamente debe operar la caja, sin importarle demasiado los demás detalles.[1]

Si un desarrollador de software no es capaz de escuchar y entender las necesidades de un usuario, no será capaz de crear un sistema que satisfaga las necesidades de sus usuarios.

Contrapartes y ánimos

Siempre en una conversación existen dos personas, entidades o seres que intercambian palabras, es decir, mensajes, que afectan las respuestas al ambiente: las famosas respuestas a los estímulos. En esta relación existe una interdependencia entre ambas partes, en la que las dos quieren lograr algo: los desarrolladores quieren entender qué deben hacer con el sistema, mientras que las personas usuarias quieren solucionar su problema o mejorar su calidad de vida laboral con esta implementación. Los roles están claros.

Al tener este grado de interdependencia, existe una especie de dominación implícita por dominio de conocimiento: el informático sabe más de computación, por lo que tiene la razón. Esta suerte de dinámica de poder es contraproducente en ciertos ambientes o situaciones donde la autorregulación es clave para que ambas partes ganen. En "The Successful Software Manager" de Herman Fung[2], se dice que una de las habilidades blandas que debe poseer el líder de un equipo es la capacidad de negociación.

Esto implica que tanto desarrolladores como usuarios deben tener el ánimo y la intención de querer escucharse y hablar entre sí, independiente del lenguaje usado o las competencias que posea cada uno.

Construyendo un camino juntos

Debido a que debemos practicar una escucha activa a las personas que colaboran en este camino, no solo a nuestros clientes o usuarios, sino también a nuestros colegas, podemos comenzar a edificar un camino juntos para resolver problemas.

La confianza es un camino bastante frágil que debe construirse todos los días, en cada reunión, en cada compromiso adquirido. Los lazos comunicativos pueden perderse rápidamente en caso de que alguna de las partes incumpla sus compromisos o ignore las recomendaciones indicadas por la otra persona que está dando a conocer sus problemas para que sean resueltos.

El respeto hacia las personas es un sentimiento que debemos guardarle a todas las personas, independientemente de la posición que ocupen en la organización y cuál sea su involucramiento en el desarrollo del software. Grandes sistemas se han caído porque son socavados por las personas que lo operan, no por quienes lo crean.

Cuando las personas se comunican de forma abierta y honesta, es más probable que se construya confianza y respeto mutuos, y por tanto, será más fácil crear o mejorar cualquier cosa o problema, no tan solo en software.

¿Qué podemos hacer para mejorar la comunicación?

Por lo general, cuando se lee que "hay problemas de comunicación", la respuesta suele ser generar más canales de comunicación. Sin embargo, lo que realmente se necesita es hacer un par de preguntas claves:

¿Cuál es el mensaje que tengo que entregar?
¿Está suficientemente claro para las personas que lo reciben? ¿A cuáles personas?
Esas personas, ¿realmente deben ser informadas o notificadas?
Mi mensaje, ¿tiene un llamado a la acción o es informativo?

Los problemas de comunicación no derivan necesariamente de la ausencia de canales, sino de la falta de prolijidad del mensaje y el formato de emisión del mensaje.

Por ejemplo, si estamos en una reunión y se toman decisiones importantes, si no quedan escritas y se socializan, los acuerdos serán retomados en función de la memoria de cada persona, en lugar de poder recurrir a un medio persistente donde las personas que intervienen son las indicadas para hacer alguna acción con la conversación.

Por tanto, la invitación que sacamos de este pequeño texto es a interactuar adecuadamente con las personas, apoyarlas y forjar una relación sincera y cordial para lograr el objetivo de ambas partes.

Resumen (por Bard)

Para mejorar la comunicación en el desarrollo de software, es importante:

Entender las necesidades de las partes interesadas.
Ser claro y conciso en la comunicación.
Escuchar activamente a las demás personas.
Ser respetuoso y abierto a las opiniones de los demás.

Notas

[1] Demás está notar que hay personas que aman esos detalles, pero por lo general son tareas totalmente separadas.

[2] Libro en Google Play

Imagen desde deepai.org usando como prompt el título del post

Inicio de una serie

Dennis Tobar — Thu, 28 Dec 2023 12:01:30 +0000

Empezar una nueva serie de entradas que no son de informática, en un blog de informática, es difícil, porque siempre hay alguien que pregunta "¿y a mí qué me importa?, yo solo quiero que mi código funcione". Hace tiempo que quería hacer esta serie de posts para compartir un poco de mi experiencia profesional, las lecturas que he hecho, los aprendizajes que he tenido, los aciertos y los errores (y sí, he cometido muchos).

He decidido hacer esta serie para hablar de mis dos pasiones: la informática y las relaciones humanas en el desarrollo de software. Aunque parezcan temas muy distintos, en realidad están relacionados. Ambos se ocupan de resolver problemas de la humanidad, y el factor humano siempre está presente en cómo hacemos las cosas.

En un mundo cada vez más digitalizado y con más formas de comunicarnos y expresarnos, es importante entender cómo las personas y las máquinas interactúan entre sí. Por lo cual, la exploración de esta serie irá en el sentido de cómo la informática y las relaciones humanas se entrelazan y ayudan a la construcción de mejores productos y servicios a las personas.

¿Estamos relacionados?

Claro que la informática y las relaciones humanas están interrelacionadas, porque siempre respondemos a las necesidades de otras personas. Ese es el ethos de cualquier sistema informático o proceso que implique la interacción entre humanos y máquinas.

Según Humberto Maturana, los seres humanos y las máquinas somos complementarios. Los humanos tenemos la intuición y la capacidad de crear cosas nuevas, mientras que las máquinas aportan eficiencia y precisión. Sin embargo, las máquinas no hablan, no razonan por sí mismas, no sienten emociones y no responden a estímulos del entorno.

Los desarrolladores de software, ya trabajemos en sistemas complejos o simplemente en hacer que los botones funcionen, necesitamos constantemente de otras personas para cumplir nuestros objetivos, recibir retroalimentación, cambiar y adaptarnos al entorno de trabajo. Por eso, nos relacionamos estrechamente con otras personas, ya sea de forma presencial, como en reuniones o pasillos, o de forma digital, como en videollamadas, mensajes de Slack o similares.

Las habilidades blandas son necesarias para lograr el objetivo de poder comunicarnos, compartir información y puntos de vista, ya que es parte de la humanidad ser "un ser social". Por tanto, es necesario revisar el cómo nos comportamos, cómo hablamos, cómo nos enfrentamos a desafíos y cómo resolvemos los problemas como un conjunto de personas que trabajan en pos de las personas usuarias.

¿Qué espero de esta serie?

Quiero compartir lo que he aprendido en 15 años de carrera como informático. No pretendo tener la razón absoluta, pero espero que mi experiencia ayude a otros a mejorar. Quiero hablar de temas que a menudo se pasan por alto, como la importancia de las relaciones humanas en el desarrollo de software.

En esta serie, hablaremos de comunicación, habilidades blandas y aprendizaje autodidacta. No es una guía para implementar algoritmos o resolver problemas de relaciones humanas, porque estos temas son muy contextuales.

Espero que esta serie te sea útil. Si tienes alguna pregunta o comentario, no dudes en dejarme un mensaje.

¿Qué herramientas usarás?

Usaré Bard para corregir la gramática y la ortografía de mis posts. También usaré imágenes generadas por IA para ilustrar conceptos complejos. Creo que estas herramientas me ayudarán a crear posts más completos e informativos.

Pare, mire y escuche...

Dennis Tobar — Mon, 17 Jul 2023 18:08:08 +0000

En la cultura vial, el Pare, mire y escuche es una secuencia de acciones que debe hacer una persona que conduce un automóvil ante de un cruce ferroviario con el fin de evitar un accidente por cruzar sin precaución.

A pesar que esta secuencia de acciones parece inofensiva y no aporta en mucho, sí puede salvar vidas, ya que es una indicación de prestar atención al entorno con tres simples pasos:

Parar el movimiento del automóvil,
Mirar si existe señales o evidencia del tren en ambos sentidos, y
Escuchar si el tren ha hecho sonar su bocina.

En el ámbito del desarrollo de software también aplicamos el mismo principio de "parar, mirar y escuchar" antes de hacer código, ya que el código tiene su origen que permite resolver un problema o necesidad de una persona o grupo de personas: un código siempre tiene un objetivo, desde un inofensivo Clippy hasta un virus o ransomware.

Por lo general, uno de los primeros instintos del desarrollador es sentarse a imaginar el cómo resolver el problema: revisar las bases de datos, imaginar la arquitectura de servidores, pensar en cómo invocar ese servicio en la nube o, simplemente, armar su árbol mental de diseño de solución, sin considerar el resto del mensaje de nuestros usuarios y usuarias.

Antes de tirar una línea de código, de ponerse a discutir una idea, de lanzar la pelota contra el piso o hablar con el pato en tu computador, nos debemos preguntar: ¿entendí lo suficiente para poder comenzar?, ¿soy capaz de explicar el proceso a otras personas?, ¿sé quiénes son los actores involucrados?, ¿tengo claro el elemento entregable?

Por tanto, apliquemos el pare, mire y escuche:

paremos y veamos si tenemos claridad de lo que tenemos que hacer,
miremos el contexto del problema a resolver o la solución propuesta, y
escuchemos las ideas de los demás actores y personas involucradas en el diseño de la solución.

Es tedioso preguntar, pero ganamos

Sí, es un trabajo tonto el que he propuesto, y "¿cómo se te ocurre que tenemos que preguntar al cliente tonteras?"... en ocasiones se da el caso que el cliente asume cosas de su dominio laboral que son importantes considerar en el diseño de la aplicación. Recordemos que desarrolladores y clientes hablamos idiomas distintos y poseemos distintos objetivos laborales, por lo cual hay precondiciones o lenguaje que no entendemos y viceversa. Aquí se hace fundamental el parar si no entendemos algo, mirar y comprender la explicación y escuchar todo lo que el cliente nos quiera decir, con atención y dejando espacio para que explique todo: al final preguntamos ideas, sino, se va por la tangente un problema e incluyen más problemas de los que estamos resolviendo.

Mejor pecar de precavido que condenarse por incauto

A veces las personas no dicen "no sé" por miedo a ser tachadas por ignorantes o sin la capacidad de estar habilitados a estar en la reunión, es decir el famoso síndrome del impostor. Este es un pequeño trauma que acarreamos desde la época escolar donde la ignorancia no es valorada positivamente y se tacha como un "tope para el aprendizaje constante a los demás estudiantes".

En este caso, parar una reunión porque no entendemos algo o simplemente debemos ahondar en un tópico que parece irrelevante está bien, ya que eso permite descubrir a la otra persona que su proceso, idea o problema no está siendo comprendido por ti, quien es la persona que le pondrá pantallas, reglas e interacción al proceso. Por eso, no tenga miedo en preguntar...

La palabra de advertencia: no se pase de la raya...

Está bien preguntar si no sabemos, pero obviamente, no debemos preguntar todo o absolutamente todo lo que veamos, escuchemos y percibamos del cliente. Es decir, hay cosas o dominios que son de común conocimiento (validaciones de datos u obligatoriedad de ciertos procesos por temas legales), las cuales no son necesarias preguntar directamente al cliente.

Así mismo, considera que no existen los levantamientos perfectos, por lo cual muchas de las cosas que tendrás dudas o primeras aproximaciones de solución no serán perfectas, ni debes esperar la perfección para hacerlo, ya que no existe el requerimiento perfecto, solo una idea de cómo se hacen las cosas y cómo deberían funcionar o la salida esperada.

Imagen | Cruce FC Urquiza y RN 14, Pcia Corrientes.JPG, Geogast, Wikimedia Commons CC-BY-SA 3.0

Descanso

Dennis Tobar — Tue, 28 Mar 2023 12:53:46 +0000

«El arte del descanso es una parte del arte de trabajar».

Steinbeck

El descanso es una parte esencial del ser humano donde nos desconectamos del día a día y nos permitimos que nuestra parte más allá del trabajo se pueda expresar en lo que nos interesa más allá del día a día.

Tener este espacio de esparcimiento colabora a desarrollar ideas, relajarnos del estrés del día a día o simplemente saber que hay más vida después del trabajo. Estos espacios nos ayudan a olvidar que el código no compila, el jefe no paga bien o hay que hacer X, Y, Z cosas en el trabajo y nos regala momentos de distracción para compartir en casa o lo que más nos gusta hacer en el día.

Al igual que las personas que realizan deportes, las personas que trabajamos desarrollando código o resolviendo problemas necesitamos de un descanso para poder recuperar fuerzas y energías tras un desgaste mental de pensar y estudiar cada elemento que vamos creando en el trabajo. Esta semejanza con el ejercicio físico tiende a ser una explicación bastante sencilla de que el trabajo mental también genera desgaste en el ser humano, ya que a pesar que no hay un ejercicio físico, sí existe una fuga de energía mental y nos cansa por igual que las personas que su labor se basa principalmente en ejercer fuerza física.

Descansar debe ser un tiempo que debemos dedicarnos a los quehaceres del hogar, cocinar recetas de cocina, jugar videojuegos -o mejor aún, hacer algún deporte-, leer algo que no se relacione con el trabajo, o simplemente beber un té al atardecer mientras vemos al horizonte, sin el teléfono que nos moleste (desconexión digital). Dejemos que el cerebro descanse...

Cuando era chico, yo dejaba de jugar en la consola con la excusa, que me inventaron los adultos de, dejar descansar a la consola. Quizás era inocente, pero dejaba de jugar con la consola y luego iba al patio a hacer otras cosas, hacer volar la imaginación con juegos imaginarios que nadie más soñó.

No debemos sentirnos culpables por descansar, no tiene que existir el remordimiento por parar un momento y tomar un segundo impulso. Si existe la culpa de detenernos, quizás valga la pena reflexionar el porqué nos sentimos así... ¿será que el trabajo es mucho?, ¿no puedo parar mientras otros trabajan?.

Al finalizar, considerar que el exceso de descanso también es perjudicial, ya que genera nuestro amigo procrastinación que es la actitud de dejar las cosas importantes de lado por un bienestar temporal. La clásica imagen de la procrastinación es navegar por YouTube, Facebook, Instagram o Tik Tok viendo videos, publicaciones o memes que nos alegran un rato, pero nos alejan del trabajo, en ocasiones por largas horas.

Aprendamos a balancear nuestro tiempo de descanso y nuestro tiempo laboral, busquemos un pasatiempo no informático, y saquemos la mejor parte de nosotros para poder sentirnos vivos y no esclavos del trabajo.

Imagen | La Sieste - Van Gogh

Está bien no saber de todo

Dennis Tobar — Fri, 29 Jul 2022 00:49:53 +0000

Cuando acabas un curso o mejoramiento en tu carrera, te das cuenta que el mundo está a tus pies, has adquirido nuevas técnicas y nuestra barra de MP se incrementa en 10 puntos. (si jugaste un RPG, sabes a lo que me refiero).

El aprender nuevas cosas siempre debe ser bienvenido, en especial en la vida, ya que el ser humano nunca deja aprender, ya sea por transferencia de conocimiento (cursos, legados u oralidad) o basado en la experimentación del mundo que nos rodea. Sin embargo, a medida que avanzamos en edad descubrimos que el mundo es más complejo de lo que podíamos comprender, las relaciones de conceptos se van volviendo intrincadas y la generación de nuevo conocimiento va exigiendo más detención y comprensión de los fenómenos que ocurren para que se produzcan los sucesos.

Como podrás sospechar, casi todas las áreas del conocimiento poseen áreas más específicas. Tomemos a las personas que estudian Medicina: hay personas que son Médicos Generales, quienes estudian Cardiología, Geriatría, etc., y se debe a que se interesan en trabajar en determinadas áreas, como atención de personas adultas mayores (Geriatría) o atención en mujeres (Ginecología), lo cual no quiere decir que dejen de comprender el cuerpo humano en forma general.

Así mismo ocurre con las personas que estudiamos informática o desarrollo: necesitamos una base común de entendimiento, ya sea la algoritmia o resolución de problemas, hasta lograr conocer y comprender el funcionamiento de determinadas áreas dentro de la administración de software: PMO que llevan control del proyecto, QA quienes se aseguran de la calidad, etc.

Aprendamos de todo, pero...

En un inicio, la inclinación natural de una persona que desconoce qué camino seguir, es intentar aprender de todo ya que algo saldrá de ahí, pero ese gasto de energía y tiempo no será recompensada a tiempo o no necesariamente es útil para poder trabajar en un rol dentro de los productos de software.

Que no se entienda mal: aprender un poco de todo está bien, pero querer aprender y comprender todo es casi una tarea titánica, y a la larga querer dominar todos los temas, y su casi imposibilidad, podría generar frustración dentro de la carrera como desarrollador, ya que al ver la limitaciones de aprendizaje y entendimiento, es posible que nos "tiremos para abajo" y nuestro ego y autoestima se vean afectados por no lograr lo propuesto.

Como dije, aprender un poco de todo no te convierte automáticamente experto en hacer todo, solo te da un pequeño pie para poder seguir un determinado camino y luego mejorar tus habilidades en tu camino. Si el conocimiento que posees es más basal o teórico, más fácil podría ser la adaptación a nuestras herramientas o ideas: si sabes Javascript, es posible que puedas aprender Node, Vue, Svelte, etc., pero si sabes React como origen, es posible que te cueste migrar a otras librerías.

Cada camino tiene sus desafíos

En sí, aprender una nueva forma de hacer las cosas tiene su propio camino de aprendizaje: no podemos planear ser desarrolladores en Python si entendemos un poquito de resolución de problemas, o no podemos pretender ser pilotos comerciales si no entendemos lo básico de la aerodinámica. Adquirir nuevas habilidades consiste en avanzar y generar estos lazos cognitivos entre el hacer y experimentar los resultados. Cuando damos un paso nuevo, avanzamos, cuando nos equivocamos, podemos avanzar el doble, pero lo importante es centrarnos en la meta de aprender correctamente un determinado concepto.

No te compares

Nuevamente, no te compares con alguien a la hora de ver habilidades técnicas, ya que todo depende de la mirada que observemos las cosas. Tengo colegas que son SAP developer, 5 estrellas MVP de Microsoft y un largo etc., lo cual es una alegría para ellos que han podido lograr esas cosas en su camino de aprendizaje. Tienen un área de conocimiento específico, mientras que otros colegas solo han trabajado para el mismo jefe toda su vida: son expertos en su negocio, en su nicho de mercado que encontraron.

Ninguno sabe más que el otro, solo que están en mercados distintos, haciendo cosas distintas. No te guíes por las caras felices en LinkedIn o en otras redes sociales: ellos también desconocen muchas cosas.

Evita ser el hombre orquesta

Un hombre orquesta es una persona que sabe tocar muchos instrumentos al mismo tiempo, solo, sin mayor ayuda, ya que domina la técnica de tocar cada instrumento con distintas partes de su cuerpo.

El hombre orquesta es un ser que, a pesar que tenga dichas habilidades, no es un maestro en la mayoría de sus instrumentos que toca, o quizás tenga una habilidad más desarrollada en algunos más que otros.

Al ser un hombre que puede hacer de todo, el día que no puedas ya que requiere conocimientos más acabados (por ejemplo, implementar una IA entrenada sin un algoritmo genérico), te podrás sentir frustrado y desafiado a tener que aprender algo nuevo por sentir la presión laboral y social de "ser perfecto".

En resumen

Dedicate a aprender bien lo que quieras aprender
No te compares con otras personas
Pequeños pasos para lograr un gran objetivo
Evita saber un poco de todo: poco pero bien a que mucho pero no muy bien.

Imagen | One-man band street performer - 1.jpg por Alan Light

El fracaso es parte del camino

Dennis Tobar — Tue, 05 Jul 2022 22:07:48 +0000

7 de la tarde, un café que perdió su sabor y calidez hace horas y un tic tac que no cesa de fondo, mientras contempla la pantalla incrédulo ese fallo que impide que se marche a casa, con solo una línea de texto en rojo: TEST FAILED. Dispuesto a rendirse, toma su bolso y parte triste a casa por no terminar bien su trabajo

¿Te parece familiar este micro cuento? Nunca es satisfactorio llegar al final de la jornada sabiendo que no has podido terminar lo que te propusiste, ya sean por limitaciones de tu conocimiento, herramientas que son lentas o procesos de desarrollo que no son adecuados: a veces nos refugiamos en las excusas para culpar nuestros fracasos, sean colectivos o individuales, con el fin de no mostrar la cara de la culpa por no haber cumplido con algo propuesto.

Fracasar en una meta es parte del camino, no siempre vamos a poder lograr lo que nos proponemos, ya sea por impericia personal, temas colectivos de tu equipo de trabajo, o simplemente mala suerte -o el Universo dice que no-. En ocasiones tendremos planeado nuestro trabajo en forma ideal, pero el día a día quieren otras cosas: situaciones de urgencia laboral, problemas personales, reuniones no programadas, etc.

El fracaso no es sinónimo de malo

Vivimos en una realidad donde el éxito mueve masas, genera likes o follow en redes sociales, y eso aumenta nuestro ego, sin lugar a dudas, ya que nos hace ser importantes, pero a su vez, las personas que no están "en la ola" se sienten inferiores. (sí, está documentado que las RRSS afectan a las personas)

El darse una vuelta por diversas redes sociales nos hacen pensar que las personas apareciendo con sus títulos universitarios o estrechando la mano de cierta persona lo hicieron sin esfuerzo es minimizar ese logro: detrás de cada historia hay sangre, esfuerzo, sudor y lágrimas que no son visibles en la foto, solo nos quedamos con esa sonrisa y mostrando ese cartón.

El fracaso queda oculto, no es algo que queramos que vean o sepan que lo hemos pasado: la ignorancia es ridiculizada y apuntada como "burro" o "no sabes nada" (acá hay más expresiones y cómo la cultura en LATAM nos formó con esta concepción de fallar = malo)

Una oportunidad de aprendizaje

En otras culturas, el fracaso se ve como una oportunidad de crecimiento: no se apunta con el dedo el hecho que falles, sino que se valora el hecho de intentar, hacer, fracasar, reflexionar y seguir.

En el caso del desarrollo de software, siempre debemos hacer no un mea culpa sino que ir revisando en qué parte nuestros levantamientos, implementaciones, desarrollos o expectativas de solución no fueron satisfactorias o a la altura del producto creado.

¿En equipo?
El buscar culpas en equipo no se trata de apuntar el dedo y humillar a quien ha cometido una falta, es buscar el cómo cometer menos errores (no podemos tener procesos ausentes de errores) y poner medidas que nos eviten repetir la experiencia. Aquí, la experiencia del Project Manager, CTO o quien lidere el área es importante, ya que el encontrar errores es frustrante para el equipo, pero a la vez debe ser una experiencia de crecimiento, y aquí este rol debe ser muy activo y proactivo en lograr que los integrantes descubran el cómo mejorar colectivamente para ser mejores y más fuerte en el futuro.

¿Cómo documentamos?
La memoria colectiva es importante para que las próximas generaciones -recuerda, nadie es eterno- no comentan los mismos errores que tuviste en tu tiempo, y que sean capaces de tener entornos seguros y confiables.

Lo más fácil de crear es un reporte de issue, donde se haga un proceso de levantamiento del issue: causas probables, efectos en el producto, soluciones implementadas y medidas remediales a futuro. Este pequeño ejercicio permite identificar la raíz del problema, efectos derivados y cómo lo intentamos solucionar como equipo.

En otros ambientes (DevOps o SRE) podríamos encontrarlo como post-mortem del problema, donde el área hace público, a una organización o un público objetivo, el problema, como fue solucionado y cómo lo podemos resolver. (por ejemplo, el post-mortem de la caída de us-west-1 de AWS en diciembre).

En resumen

Fracasar es parte del camino, nunca haremos todo perfecto.
No te acomplejes por fallar, siempre puedes seguir adelante.
Reflexiona, corrige, aprende.
Pone tareas o medidas remediales que ayuden a no cometer nuevamente el problema.
Sé amable y escucha las reflexiones que se logran como equipo.

Y el joven al día siguiente se dio cuenta que, tras revisar su computador, que el test nunca debía validarse, debido a que un desarrollador que le antecedió puso una prueba que se contradecía con el negocio. Cambió la prueba y añadió su prueba, al ver el verde, cerró el issue en JIRA, tomó un café caliente y se regaló una rosquilla del cesto al centro de su empresa: fue el mejor desarrollador del mundo por un instante

Imagen | Windows 9x Blue Screen of Death recreated in Fixedsys.svg