Archivo de la etiqueta: compasión

El Triángulo de la Documentación de Código

Hace un tiempo propuse que deberías escribir código que se documente solo, y luego agregarle documentación. En el artículo original, escribí:

La idea de que “tu código debería de documentarse solo” no es un get out of jail free card para no documentar tu código. Las ocasiones en tu carrera profesional donde escribir documentación no agrega valor a tu trabajo son muy pocas. Tan pocas, de hecho, que no se me viene ninguna a la mente. ¿Tal vez cuando estás trabajando en un proyecto propio? Pero hasta Damian Conway dijo que “la documentación es una carta de amor que le escribes a tu yo del futuro”.

Hoy me encontré una idea que aumenta mi punto: El Triángulo de la Documentación de Código.

Este modelo mental nos dice que toda pieza de código está documentada en 3 dimensiones distintas, cada una respondiendo una pregunta muy particular.

  • ¿Qué?: Tu código, en sí, explica lo que estás haciendo.
  • ¿Por qué?: Los comentarios que le agregas a tu código, explican tu proceso de toma de decisiones y la razón de tus soluciones.
  • ¿Cómo?: El contexto dentro del cual estás desarrollando tu programa; la descripción original del problema.

Si te enfocas en escribir código que “se documente solo”, en un futuro no sabrás por qué llegaste a esa solución, ni cómo esa solución es apropiada para el problema original.

Recuerda, agregar documentación a tu código (en forma de comentarios, glosarios, RFCs, pruebas, etc.), no es una admisión que no fuiste lo suficientemente inteligente para escribir “buen” código, sino un acto de compasión. Demuestra tu interés porque la siguiente persona que modifique tu código pueda enfocarse en agregar valor al proyecto — y, muy probablemente, esa siguiente persona vas a ser tú.

“A esta empresa se viene a trabajar, no a ponerse sentimental”

Una de las banderas rojas más grandes es si tu jefe te contesta “a esta empresa se viene a trabajar, no a ponerse sentimental” cuando le comentas que una situación de tu trabajo te está afectando a nivel personal.

Para mí, esa es una señal inequívoca de estar en el lugar incorrecto para crecer profesional y personalmente.

https://twitter.com/Swanros/status/1472986970947080193

Como líder de un equipo, tengo claro que mi objetivo principal no es exprimir el talento de las personas con las que tengo el privilegio de colaborar. Mi trabajo es propiciar las condiciones necesarias a nivel organizacional para que ese talento florezca por sí solo, y luego potenciarlo. Desafortunadamente, muchos “líderes” de equipo realmente funcionan como jefes, exigiendo sin aportar, promulgando sin poner el ejemplo. Y la frase “a esta empresa se viene a trabajar, no a ponerse sentimental” es el reflejo de esa mentalidad, donde lo que importa es el resultado y no la persona. Un medio para un fin.

Hace unos meses escribí:

Tú y yo somos parte de un sistema que, hora tras hora, está buscando exprimir la mayor cantidad de productividad de cada uno de nosotros. Eficiencia, dicen, es lo principal. Ser eficientes. Ser productivos. Si no estás siendo productivo, estás desperdiciando recursos. Si no maximizas tus horas de trabajo, estás siendo irresponsable.

Gran parte del reto es el contexto cultural en el que nos desarrollamos — especialmente en Latinoamérica, donde muchos hemos crecido con la idea de que lo que importa es el trabajo duro, y que reprobar (o que te corran) es lo peor que te podría pasar. Peor incluso que vivir angustiado, amargado o con ansiedad. Y cada día que paso trabajando con personas y buscando la manera de honrar su individualidad, metas y objetivos personales, me doy cuenta de la mucha falta que hace que los líderes en esta industria sean más humanos.

Si logras identificar las banderas rojas en tu empleo, y estás inseguro sobre si deberías buscar otro camino, déjame decirte que tienes muchas cosas a tu favor. El mercado está más caliente que nunca, y hay muchas empresas y organizaciones que están decidiendo apostar por la persona, más que por el output que generan. Solo tienes que levantar la cabeza y buscarlas.

Primero, hazte consciente de tu valía como persona, analiza tu propuesta de valor y, como dice Vicente Plata, no aceptes abusos.

El nombre que le pones a las cosas sí importa

“En las ciencias de la computación, hay únicamente dos problemas difíciles de responder: la invalidación de un caché, y cómo nombrar cosas.” — Phil Karlton

La cultura del Internet después modificó este refrán para incluir errores de enumeración de índices, pero esa es otra historia.

La realidad es que Phil tenía mucha razón: decidir cómo nombrar las entidades que manipulamos al programar es una de las tareas más difíciles de nuestra profesión. No por nada es tan común ver variables, métodos, clases, funciones, o cualquier otro elemento de programas, con nombres genéricos, como x, builder o manager.

Algunos argumentan que invertir tiempo en nombrar los componentes de un programa de manera coherente es una pérdida de tiempo. Las veces que he participado en discusiones donde se intenta impulsar la idea de que alguien debería poder diferenciar una variable X de otra simplemente por el nivel de sangría del código son demasiadas. Creo que desafortunadamente esto es otra muestra de lo inusual que es el sentido de compasión en la industria de la tecnología.

Al igual que agregar documentación completa a tus proyectos, usar nombres descriptivos y semánticamente correctos es un acto de compasión.

El lenguaje es el medio a través del cual los humanos razonamos sobre las ideas de nuestro día a día. Al compilador no le importa el nombre de tu variable, pero a la persona que va a leer y contribuir a tu código sí. Y como siempre, es importante recalcar que esa persona puedes ser tú mismo, años después.

Utilizar nombres descriptivos y semánticamente correctos para los componentes de tu programa no solamente hace más accesible la lectura de tu código. También te ayuda a razonar mejor sobre la solución que estás implementando. En algunos casos, hasta te podría salvar, potencialmente, de introducir vulnerabilidades de seguridad críticas.

Conforme he ganado experiencia colaborando en esta industria, he encontrado una relación, casi directa, entre el nivel de atención a la nomenclatura y semántica de los componentes de un programa y su fiabilidad.

Después de todo, me pregunto: si no te tomaste el tiempo de nombrar algo de una manera correcta y con sentido, ¿realmente habrás entendido el problema que estás intentando resolver?

Ruby remueve lenguaje que promueve el abuso

Aquí vamos de nuevo. Alguien en una comunidad de programadores hizo una broma sexista, y en vez de tomar medidas al respecto, se pusieron a discutir sobre los matices que hacían que la broma fuera aceptable. ¿Sorprende? No. ¿Aceptable? Tampoco. ?‍♂️

Si salió algo positivo de todo esto, es modificaron la página oficial de Ruby, removiendo lenguaje que promovía este tipo de conductas abusivas.

Creo que nunca me había puesto a pensar el efecto en las comunidades que la frase “los miembros deben asumir que los comentarios tenían buenas intenciones”.

Tip: Independientemente del comentario, la intención y el impacto de tus palabras no son equivalentes. Por mejores que sean tus intenciones, si tu comentario tiene un impacto negativo, eso es lo que cuenta. Sé responsable.

Enlace: https://github.com/ruby/www.ruby-lang.org/pull/2690/files

Trabajo remoto: encuentra uno antes de que sea demasiado tarde

Deberías de buscar trabajar de manera remota tan pronto como puedas en tu carrera.

Muchos piensan que para trabajar de manera remota necesitas estar en el pináculo de tu carrera. Que la progresión es Jr., Mid., Sr., trabajo remoto. Pero la realidad es que para trabajar de manera remota se necesitan más soft skills que conocimientos técnicos. Te lo dice alguien que nunca ha trabajado en una oficina en toda su vida.

Trabajar de manera remota no solamente es atractivo porque (probablemente) te pagarán en una moneda extranjera. Aunque sea bastante relevante para tu calidad de vida, hay algo mucho más profundo a lo que me gustaría que le prestaras atención: trabajar de manera remota es un ejercicio de paciencia, tolerancia y humildad. Tendrás la oportunidad de trabajar con personas de todo el mundo, con pasados completamente diferentes al tuyo, motivaciones diametralmente opuestas y habilidades que ni siquiera podrías haber imaginado que se podrían obtener.

Al trabajar de manera remota te expondrás a otras maneras de resolver problemas. Ideologías de trabajo que tal vez no hagan sentido para ti; principios y valores que harán cuestionarte si estás haciendo lo suficiente.

Es por eso que es tan importante que tengas esta experiencia tan pronto como puedas en tu carrera. Porque así no tendrás un marco de referencia de “la forma correcta” de hacer las cosas. Estarás menos viciado, y será mucho más fácil adaptarte al cambio sin juzgar el proceso. Desarrollarás habilidades que te ayudarán a ser mucho más eficiente, productivo y tolerante. Y más que una tecnología o lenguaje de programación, la base de tu carrera será tu tolerancia, eficiencia, adaptabilidad y compasión.

Como dice Seth Godin, la tolerancia crea resiliencia en los humanos. Tolerancia a diferentes habilidades y preferencias nos ayuda a trabajar con diversidad de pensamiento, técnica y experiencia. La combinación de estos factores produce mejores resultados al final del día.

Así que no, no te esperes a ser el mejor en cierta tecnología para buscar un trabajo remoto. Exponte al reto.

Gana perspectiva antes de que encuentres una “forma correcta de hacer las cosas” que funcione únicamente en tu burbuja.