• La diferencia entre programar y ser desarrollador de software

    La diferencia entre programar y desarrollar es sutil pero importante. Para resaltarla, veamos cómo esta misma diferencia se manifiesta en una industria que podría parecer no tiene nada en común.

    Cuando los doctores trataban enfermedades, no pacientes

    El Doctor Jay Katz escribió en su libro de 1984 The Silent World Between Doctor and Patient:

    Los médicos se sentían obligados a atender las necesidades físicas y emocionales de sus pacientes y a hacerlo por su propia autoridad, sin consultar con sus pacientes sobre las decisiones que debían tomar. La idea de que los pacientes también puedan tener derecho a compartir la carga de las decisiones con sus médicos nunca formó parte del espíritu de la medicina.

    Imagínate despertar de una operación que no pediste, sin una parte de tu cuerpo, porque el médico asumió que 1) querías curarte de una enfermedad que no sabías que tenías, y 2) que lo que decidieron hacer era la única manera de hacerlo.

    Hoy en día, eso (casi) nunca sucede. Y la razón es que hace unos 50 años se crearon leyes de protección al paciente, tomando en cuenta el argumento de Katz: que los pacientes tienen puntos de vista completamente diferentes a los de la ciencia acerca de lo que constituye un tratamiento que valga la pena, y, por tanto, deben de ser consideradas en su plan de tratamiento. Escribió:

    Es peligroso afirmar que en la práctica de su arte y su ciencia, los médicos pueden confiar en sus intenciones benévolas, en su capacidad para juzgar qué es lo correcto o en su capacidad para realizar sus tareas con humanidad, paciencia, prudencia y sabiduría. No es tan fácil. La medicina es una profesión compleja y las interacciones entre médicos y pacientes también lo son.

    La práctica moderna de la medicina no trata enfermedades, sino pacientes. Esto significa que la persona que va a ser tratada está involucrada en la creación del plan de tratamiento desde un inicio. Conoce los pros y contras, y está informada de las implicaciones del procedimiento al que se va a someter.

    La relación doctor-paciente es muy similar a la del desarrollador-negocio.

    Por un lado, hay expertos en una ciencia, técnicamente adeptos, entrenados (y condicionados) para reconocer patrones y resolverlos con herramientas y procedimientos especializados. Del otro, síntomas evidentes y necesidades aparentes que pueden (o no) requerir de intervención técnica.

    La ciencia de la medicina está aún presente en las interacciones de los doctores con sus pacientes. Pero está recubierta por capas y capas de habilidades clave, como:

    1. Comunicación: Los médicos necesitan comunicar de manera clara y comprensible diagnósticos y tratamientos a los pacientes.
    2. Empatía y modales: Es esencial que los médicos muestren empatía y un buen trato para confortar y entender mejor a sus pacientes.
    3. Conocimiento ético y legal: Los médicos deben estar informados sobre las leyes y principios éticos que rigen la atención médica y la confidencialidad del paciente.

    ¿Volverías a consulta con un doctor que la única solución que te ofrece es una operación, y se niega a considerar otras opciones? ¿Tratarías con un doctor que no te da la información con tacto y paciencia, y se ocupa de que entiendas el significado de lo que te está diciendo?

    De programar a resolver problemas

    Algunas personas me voltean los ojos cuando hablo de que las dinámicas entre lo que hacemos en la industria del software y la medicina son muy similares. Sí, las consecuencias de las decisiones que tomamos nosotros, y las de los médicos, son muy diferentes. Sin embargo, propongo aprender de los modelos mentales que les ayudaron a otras personas, en otras profesiones, a resolver cierto tipo de problemas que también nosotros podemos encontrar, aunque en diferente nivel de complejidad.

    Programar es la tarea mecánica de escribir código y decirle a una máquina qué hacer. Desarrollar software se trata de resolver problemas — a veces a través de la escritura de código. Y para resolver problemas, tenemos que tratar con personas.

    Hoy, más que nunca, es vital para las personas que trabajamos en la industria de la tecnología reconocer que tenemos que recubrir nuestras habilidades técnicas con capas de habilidades blandas.

    Este es solo el inicio de la divergencia entre programar y desarrollar

    El 2 de junio de 2021 escribí:

    Con el aspecto técnico resuelto (parcialmente) por inteligencias artificiales, las discusiones técnicas dejarán de ser la parte más importante del desarrollo. Los programadores ahora se dedicarán a tener discusiones sobre la ética y seguridad del código generado por la computadora. Las tareas técnicas serán resueltas, en su mayoría, gracias a la ley de Moore. Desarrollar software ya no se tratará de programar.

    Aún habrá trabajos para escribir código, pero requerirán una alta especialización. Las personas que sigan escribiendo código lo harán para crear la infraestructura que soportará al resto del ecosistema: compiladores, IA, generadores de código, redes, etc.

    Dos años y medio después, seguimos encaminados a ese futuro. Y cada vez más rápido.

  • Así fue mi 2023

    Continuando lo que espero se convierta en un hábito, aquí está mi reseña del año pasado, 2023. La del 2022 la puedes leer aquí.

    Los destaques

    2023 se trató de aprender a estar cómodo con la incomodidad. Durante todo el año, hubo varios eventos que pusieron a prueba mi capacidad de mantenerme calmado y presente, tanto personal como profesionalmente.

    En retrospectiva, no fue un año fácil. Tampoco fue un año normal (no anticipo y tampoco espero tener un año similar de manera regular).

    Pero por más vertiginoso que haya sido, le agradezco a mi yo del pasado por haber tomado decisiones que me permitieron planear y ejecutar grandes cambios en mi vida, así como sobrellevar los que no había anticipado ni planeado.

    En orden vagamente cronológico, aquí algunos destaques de este año:

    • Me contagié de COVID. Hasta donde sé, solo he tenido COVID-19 una vez en mi vida.
    • Continué invirtiendo en mejorar mi salud financiera y relación con el dinero. Me siento orgulloso de cómo he logrado sanar todas esas heridas cognitivas y emocionales que me estaban haciendo vivir frustrado y con miedo, económicamente hablando.
    • Mi novia se mudó a vivir conmigo.
    • Luego nos mudamos a Guadalajara. Mi intención original era irme a CDMX, pero elegimos Guadalajara como un punto intermedio. Después de todo, la ciudad en la que terminaría no era una prioridad tan grande como irme de Colima.
    • Vi a Taylor Swift y Kurt en concierto (por separado). Aunque este año no hubo tantos conciertos como el año pasado, a los que fui fueron experiencias increíbles.
    • Retomé la terapia de manera regular. Regresé a la terapia Cognitiva Conductual con el mismo terapeuta que conocí durante pandemia.
    • Hice un esfuerzo más consciente por tomar vacaciones en forma, en vez de solo tener días sin trabajar. Hice varios viajes por placer, completamente desconectado del trabajo. Aprendí bastante sobre mí mismo en el proceso, y por fin pude conocer lo que es regresar de vacaciones sin preocuparme por cómo iba a pagarlo.
    • Este año tuve que hacerle cara al cambio. El cambio da miedo, y más cuando llegar por factores externos. Durante 2023, la única constante que las cosas cambiaban a cada rato. Personalmente, la ciudad, relaciones con amigos y familia, hábitos, rutinas, clima. Laboralmente, cambié de manager en 4 ocasiones, y terminé el año con 3 veces más reportes que con los que inicié.

    Los libros que leí

    Gravité mucho más hacia temas abstractos, lecturas menos tácticas. Aquí hay una lista de algunos de los libros que leí durante los últimos 12 meses, más o menos en orden cronológico:

    Mientras hacía esta recapitulación de las lecturas del año, noté algo interesante: leí más o menos la misma cantidad de libros que el año pasado, pero guardé digitalmente menos pasajes e ideas de ellos. En su lugar, subrayé más.

    Vuelos

    Uno de mis hobbies es aprender sobre aviones y aeronáutica — desde niño. Así que, naturalmente, soy un poco obsesivo con saber todos los detalles de cada avión al que me subo.

    Desde el año pasado, comencé a usar Flighty para llevar el registro de mis viajes. Aquí está la información de este año:

    • Tomé 23 vuelos, en 4 aerolíneas
    • Cubriendo una distancia de 35,658 km
    • Visité 8 aeropuertos diferentes en dos países (México y Estados Unidos)
    • Mi ruta más popular fue GDL → MEX
    • La aeronave que más utilicé fue el Boeing 737-800
    • La aerolínea que más usé fue Aeroméxico

    Mi salud mental/estabilidad emocional

    Continúo usando Daylio para llevar el seguimiento de mi salud mental y bienestar general. Estoy orgulloso de que este año llevé un registro mucho más detallado que el año pasado, con una entrada por cada día del año.

    Recientemente, Apple lanzó su propia aplicación de journaling. La comencé a usar casualmente, y me gusta mucho la integración que tiene con el sistema y las otras aplicaciones. Por lo pronto, Daylio sigue siendo mi aplicación principal, pero no descarto que Journal tome más prominencia en mi día a día.

    Mi resumen de 2023:

    • Registré 416 entradas y un total de 1843 actividades en el diario.
    • El mejor día de la semana, en promedio, fue el domingo.
    • Mi mejor mes, enero.
    • Mi estabilidad anímica fue de 84/100, 3 puntos menos que el año pasado. Tiene sentido, en retrospectiva.
    • De acuerdo al análisis, la actividad que más influencia tiene sobre mi estado de ánimo es una buena noche de dormir.

    Además, esto es lo que he hecho para promover mi salud mental y estabilidad emocional:

    No estoy expuesto a redes sociales. A finales del año pasado cerré mis cuentas de Twitter. Cuando Apollo dejó de funcionar en junio, también dejé de usar Reddit. Hoy en día la única red social que tengo y mantengo activamente es LinkedIn. Fuera de eso, no estoy expuesto a ningún tipo de contenido de redes sociales, más que por el ocasional enlace que me envían por iMessage, Telegram, o WhatsApp. Además, Facebook, Twitter, Instagram, Reddit y TikTok están bloqueados en la red de mi casa (uso eero Plus, y únicamente mis dispositivos tienen estas restricciones), así que si estoy en mi casa, aunque me manden contenido de redes sociales, no los puedo ver.

    Los últimos 3 o 4 meses del año, hice un esfuerzo puntual por dejar de usar mi teléfono. Esto a raíz de que me di cuenta (gracias a Screen Time) que por ahí de mitad de año, mi promedio de uso diario del teléfono andaba en las 3 o 4 horas. Me pareció inaceptable pasar tanto tiempo al día viendo un rectángulo de cristal. El último mes del año, mi uso del teléfono se ha reducido a un promedio de un poco más de una hora diaria, algunas semanas llegando a ser menos de 30 minutos.

    Separé mi espacio de trabajo de mi espacio de recreación y vivienda. Prácticamente, durante toda la pandemia, el espacio de trabajo dedicado (cuando tenía uno) estuvo en el mismo espacio físico que mi sala o comedor. Aprendí a la mala, que a la larga, trabajar y descansar en el mismo espacio físico no es bueno para mí. Cambiar de “modo trabajo” a “modo descanso” significaba dar 5 pasos de un sillón a otro. Una de las primeras cosas que busqué al mudarme, fue que mi espacio de trabajo estuviera fuera de mi hogar. Y ha funcionado de maravilla.

    Actividad física

    2023 fue… complicado. En general, no me siento tan cómodo con mi rendimiento en el año, y me costó mucho trabajo mantener algún tipo de rutina de ejercicio.

    Ejercicio

    Toma en cuenta que únicamente representan mis workouts, no mi actividad total durante el día. Los dos tipos de entrenamiento principales durante mi año fueron caminata y entrenamiento funcional.

    Caminar se ha vuelto mi ejercicio más común. Es lo que cupo en mi estilo de vida durante el año de manera constante, para bien o para mal.

    En general, en 2023 casi hice el doble de caminatas — casi todas las métricas subieron un 98 % comparación del año pasado.

    • Registré 483 sesiones de caminata (vs. 243 en 2022)
    • Di 1,221,825 pasos (vs. 662,417 en 2022)
    • Recorrí 1,005.4 km (vs. 547.14 km en 2022)
    • Quemé 136,600 kcal (vs. 72 000 en 2022)

    Otros datos:

    • Lo más que caminé en una sola sesión fueron 11,418 pasos, el 25 de junio.
    • Mi caminata promedio duró 33:40 minutos.
    • En total pasé 272 horas con 34 minutos caminando.

    Por temporadas, también hice Yoga. Usé mi suscripción de Apple Health+ para tomar las clases, que me gustaron bastante. Sigo haciendo Yoga de vez en cuando.

    Desde que me mudé a Guadalajara, utilizo bicicleta para ir a mi oficina de manera regular. Es un trayecto de más o menos 8 minutos, cuesta arriba de ida, y unos 5 de regreso. No es mucho, pero lo hago un par de veces al día, de lunes a viernes.

    Tomando en cuenta todas mis sesiones de entrenamiento del año:

    • Pasé 11 días con 8 horas y 34 minutos haciendo ejercicio.
    • La duración promedio de la sesión de entrenamiento fue de 33:40 minutos.
    • Quemé 136,603 kcal.
    • 111 bpm es mi frecuencia cardiaca máxima promedio cuando entreno.

    Sobre mi salud en general

    Estos datos también los saqué directamente de Apple Health. Toma en cuenta que uso un Apple Watch todos los días, pero no para dormir:

    • Promedio de 64 cuentas por minuto en mi frecuencia cardiaca en descanso.
    • Quemé 8 000 kcal totales por semana.
    • Dormí 8.2 horas diarias.

    Este año, el problema con mis pies (espolón calcáneo en ambos) se hizo más prominente. Comencé a usar plantillas de manera regular para mitigar la molestia, y a tomar de manera crónica antiinflamatorios y relajantes de músculos todas las mañanas. El dolor se ha hecho más molesto, y me ha impedido retomar algunas rutinas de ejercicio que me gustaban bastante (saltar la cuerda, correr, etc.). No descarto recurrir a cirugía el próximo año.

    Otra cosa importante del 2023, es que dejé de tomar alcohol y refresco. Al momento de escribir esto, llevo 228 días sin consumir ninguno de los dos, y planeo continuar con la tendencia. En 2024 me gustaría incluir productos de harina a esa lista.

    Mes a mes

    Aquí una visión más granular de lo que pasó mes con mes.

    Enero: No sucedió mucho, fue un mes bastante normal. Un par de idas a la playa a Manzanillo, y un par de escapadas a Guadalajara para intentar romper la rutina. Me hice un chequeo de salud general.

    Febrero: decidí que ya no quería estar en Colima, y comencé a planear la migración a otro estado. Platicando con mi novia, decidimos que lo queríamos hacer juntos.

    Marzo: me di cuenta de que mi pasaporte había expirado intentando hacer el check-in para un viaje de trabajo a Nueva York. Semana de vacaciones en La Paz y Los Cabos con amigos de mi novia, mi highlight siendo el día completo que pasamos en Balandra. Regresando de las vacaciones, se mudó a mi casa. Regresé con mi terapeuta del año antepasado porque sentí que necesitaba un chequeo rápido. Todo bien.

    Abril: no quise que me pasara lo mismo con mi visa, así que la renové aunque aún tuviera un año de vigencia. Comenzamos a buscar zonas para vivir en Guadalajara.

    Mayo: estuve en Nueva York por prácticamente la mitad del mes, en viajes separados. El primero fue por trabajo, para participar en un evento de la compañía. Y el segundo, vimos a Taylor Swift en concierto.

    Junio: a mediados nos mudamos a Guadalajara. Rentamos un Airbnb por 30 días para poder establecernos en lo que buscábamos un departamento permanente. Afortunadamente, lo encontramos la primera semana, y el resto del mes lo dedicamos a planear la mudanza definitiva. Fuimos a CDMX a la boda de una de mis mejores amigas.

    Julio: la primera mitad del mes estuvimos en mudanza gradual del Airbnb al nuevo departamento. La segunda mitad, la dedicamos a amueblarlo y a ir a Colima unas cuantas veces para recoger cosas que nos habían hecho falta.

    Agosto: se trató de asentarnos en el nuevo espacio, rutina y ambiente.

    Septiembre: seguimos estableciéndonos en la rutina. Mi novia me hizo notar algunos comportamientos que yo estaba teniendo, que sonaban a que la ansiedad/depresión estaba volviendo a aparecer. Regresé a terapia semanal.

    Octubre: mes bastante callado, donde seguimos únicamente enfocándonos en descifrar nuestra nueva rutina.

    Noviembre: le regalé a mi mamá y hermano un viaje a CDMX por sus cumpleaños, y di una charla en un evento público de la empresa donde trabajo. Se casó una prima y fuimos a su boda, y vimos a Kurt en concierto.

    Diciembre: me autorregalé un viaje a Hawái por mi cumpleaños número 30 (!). Mi novia y yo estuvimos disfrutando de las playas de O’ahu por 11 días. Al regresar de vacaciones a mitad de mes, desafortunadamente la empresa para la que trabajo tuvo layoffs. El resto del mes lo dediqué a terminar pendientes, visitar familia, y prepararme para el siguiente año.

    Las personas

    Agueda, Francisco, Vanessa, Jonathan, Carlos, Ilse, Carlos M., Sean, Isabel, Martha, Gerardo, Darwin.

    Fueron claves durante mi año. Gracias totales a cada una de ellas.

  • Sobreviví un layoff, y esto es lo que aprendí de mí mismo en el proceso

    Desde que comenzaron los rumores de que habría un layoff, hasta que recibimos la noticia de cuántas personas serían afectadas, pasaron aproximadamente 18 horas. Las 18 horas con más ansiedad que recuerdo vivido desde que inició la pandemia.

    Los layoffs son una realidad de la industria, sobre todo recientemente. Tan solo en 2023, 1,167 empresas de tecnología cortaron, en conjunto, a más de 250 000 personas.

    Me habían despedido de trabajos antes, pero un layoff pega diferente. Las ocasiones que me despidieron, por lo menos había una relación apreciable entre mi performance y la decisión de dejarme ir — claramente no lo estaba haciendo bien, y aunque no fue un momento agradable, pude entender el “por qué” y procesar mis emociones a través de ese lente.

    El prospecto de un layoff, en cambio, es que podrías no tener un empleo dentro de un par de horas, por factores que tú no tienes cómo controlar ni prever, y no puedes inferir qué futuro te espera. Es una moneda al aire.

    Hace poco me vi en la necesidad de enfrentar esta situación. Te quiero contar cómo lo viví, lo que aprendí de la experiencia, y darte algunos consejos de cómo sobrellevar la situación cuando te toque.

    Los rumores del layoff

    Los rumores de layoffs viajan rápido dentro de las empresas. Ya había terminado mi día de trabajo cuando por WhatsApp algunos compañeros me comentaron que sospechaban que al día siguiente sucedería uno.

    Comencé a hacer mi diligencia para intentar encontrar alguna confirmación oficial, pero no fue un esfuerzo muy productivo. Nadie sabía nada. Ni mi manager, ni su manager. Sin embargo, y sin entrar en detalles, varios factores apuntaban a que al día siguiente sucedería algo grande — y no pintaba bien.

    Después de un par de horas investigando sin tener más información que apuntara a algún lugar concreto, le dije a mi manager que me desconectaría y estaría al pendiente la mañana siguiente. Inmediatamente, fui con mi novia y le platiqué lo que estaba sucediendo. “Probablemente, haya un layoff mañana, y no sé si me va a tocar. Para que estés lista.”

    Intenté calmarme y distraerme. Fui al gimnasio, saqué a pasear a los perros. Para cuando me acosté, me sentía bastante tranquilo.

    Preparándome… por cualquier cosa

    A la 1  am, apenas un par de horas después de haberme ido a dormir, desperté de golpe, con palpitaciones. Estuve un poco menos de dos horas dando vueltas en la cama, imaginándome todos los posibles escenarios en los que me podría encontrar por la mañana. Hasta hice una lista mental de todas las personas que podría contactar en caso de que necesitara encontrar un nuevo empleo pronto.

    A las 3 am entendí que me iba a ser imposible dormir, así que me levanté. En la sala de mi departamento había una carga recién salida de la lavadora; me preparé un café, me puse mis audífonos y comencé a acomodarla. Luego desayuné, escuché otro podcast, vi una película y un documental, y a los primeros rayos de luz de la mañana salí a caminar con uno de mis perros.

    Cuando decidí que tenía que prepararme para lo que fuera a venir, lo primero que hice fue asumir que sucedería lo peor: me quedaría sin empleo ese día.

    Descargué mis recibos de nómina, en caso de que necesitara hacer algún trámite. También exporté mis performance reviews de los últimos dos años para sustanciar mi CV en caso de que tuviera que aplicar a nuevas vacantes pronto. Además, respaldé cualquier información personal que pudiera tener en mi computadora de trabajo en un disco duro externo.

    Una noticia importante sobre la empresa

    Tanto se ha escuchado en la industria de cómo las empresas ejecutan sus layoffs, que más o menos ya sabes qué esperar: por la mañana te va a llegar una invitación a una llamada con el CEO, donde se va a compartir “una noticia importante sobre la empresa”, e inmediatamente después te va a llegar un correo con más información.

    Eso fue justamente lo que sucedió.

    A las 8 am, cuando llegó una invitación para una llamada a las 10, mi computadora de trabajo estaba lista para ser devuelta prácticamente como nueva, en caso de ser necesario.

    Media hora antes del comunicado oficial, platiqué con uno de mis mentores — que también fue mi manager antes, y ahora es más un amigo — y, por 30 minutos, hablamos de viajes, playas, vacaciones y hoteles. Aunque sabíamos que activamente estábamos intentando distraernos para no pensar en lo que vendría pronto, nos seguimos mutuamente la corriente. Y tuvo éxito. 2 minutos antes de las 10, nos deseamos suerte, y cambiamos de llamada.

    El layoff

    Para las 10:15 am ya tenía la claridad que ansiaba tener. Sí, habría un layoff que impactaría a más del 10 % de la compañía. Pero yo no estaba dentro de la lista de personas afectadas.

    Las siguientes horas fueron una combinación extraña de sentimientos y emociones. Primero el alivio de aún tener empleo, luego la ansiedad de saber quién ya no, y la incertidumbre de qué significaría eso para los que nos quedamos. Luego, vino el ejercicio medio tétrico de revisar uno por uno los canales de Slack que frecuentaba, tratando de identificar quién simplemente no tenía Slack abierto, y quién ya no tenía acceso.

    Poco a poco, nombres familiares fueron apareciendo en LinkedIn compartiendo la noticia.

    Para el final del día, y después de múltiples llamadas con el equipo de liderazgo, donde se nos dio más claridad sobre lo que vendría después, fue cuando por fin empecé a entender las implicaciones de lo que había pasado.

    Me fui a dormir a las 5 pm.

    Lo que aprendí

    Todos tenemos una idea de cómo reaccionaríamos ante una mala noticia. Recientemente, aprendí que la que yo tenía no estaba para nada cercana a la realidad. El fenómeno psicológico de intentar anticipar cómo nos va a afectar emocionalmente una situación en el futuro se llama Affective Forecasting, y es uno de los puntos ciegos más grandes que sufrimos los humanos.

    Si hace un mes me hubieras preguntado cómo me afectaría emocionalmente sobrevivir un layoff, te hubiera respondido que sí, habría estado triste, pero no sería para tanto. Hoy te puedo decir, habiendo vivido exactamente eso, que no pude estar más en lo incorrecto.

    Lo que anticipaba simplemente como tristeza, es en realidad un cóctel, que viene y va, de frustración, incertidumbre, nerviosismo, pena, duelo, agobio, desesperación; mezclado con felicidad, agradecimiento, orgullo y optimismo. Y sí, sí fue para tanto.

    En retrospectiva, esta experiencia hizo darme cuenta de dos cosas. Primero, que me gusta mi trabajo, me siento capaz y contento con lo que hago, y me dolería perder la oportunidad de colaborar con las personas que tengo a mi alrededor. Bien dicen que uno nunca sabe lo que tiene hasta que lo pierde. En mi caso, el mero prospecto de poder perder mi empleo me detonó un ataque de ansiedad que me transportó a esos primeros meses de pandemia — horrible.

    Segundo, y más importante: que aún me queda mucho trabajo personal por hacer para continuar separando mi identidad personal de mi situación laboral. Entiendo que perder algo que valoras debería de provocarte una reacción — somos humanos, después de todo. Pero, personalmente, aspiro a desligar mi valor como persona de algo que en cualquier momento podría perder, incluso por factores externos y sin tener la más mínima injerencia. En esta ocasión, más que simplemente perder mi empleo, vi mi valor personal — relaciones, ego, status — directamente en riesgo.

    Consejos para sobrellevar el prospecto de un layoff

    Para cuando los rumores comiencen en tu compañía, puede ser demasiado tarde. Y probablemente entres en el mismo ciclo mental que yo, y todos con los que platiqué mientras sucedía, entramos recientemente: pánico, miedo, ansiedad, duelo anticipado.

    Pero si de algo sirve, aquí te dejo algunos consejos para sobrellevar el prospecto de layoffs en tu empresa. Estos son míos:

    Busca una red de apoyo emocional. Procura no aislarte durante este proceso, porque eso únicamente lo hará más difícil. Acércate con personas que sepas que tienen tu bienestar en mente, y que podrían apreciar las implicaciones de lo que significa pasar por una situación como esta. En mi caso, me apoyé con mi novia, dos amigos cercanos, y un puñado de personas dentro de la compañía. Aprecio que simplemente pasar por esto acompañado hizo que todo fuera un poco más sencillo para mí, por más desgastante que fue la experiencia en general.

    Asegúrate de tener una copia de cualquier evidencia que valide tus competencias, desempeño, o impacto en la empresa. Algo que como manager les digo a mis equipos, es que cualquier logro y aprendizaje que tengan dentro de la empresa es suyo: cuando ya no trabajen aquí, ese conocimiento, aprendizaje, orgullo, impacto se lo llevarán con ellos. De modo idealista, está muy padre. De manera práctica, necesitas una forma de comprobarlo. Mantén un diario de logros (o un brag document), y recopila retroalimentación constantemente de tus compañeros y tu manager. Estos deberías de tenerlos en un lugar que tú controles.

    Blíndate económicamente. No lo sé a ciencia cierta, pero puedo intuir que no la habría pasado con tanta angustia, si para este momento hubiera tenido un poco más de reservas de emergencia. Tal vez esté en lo incorrecto, y al pasar de nuevo por esta situación con más ahorros me sienta igual, o hasta peor — como dije arriba, creo que mi reto es cómo mi empleo moldea mi identidad. Además, el dinero también es un asunto emocional. Pero más vale prevenir.

    También le pedí a personas cercanas que aportaran sus perspectivas. Aquí están algunas de ellas:

    • Javier: Desde el punto de vista mental y emocional, soy mucho de reconocer que cada quien maneja estos procesos a su manera. Hay unos que necesitan tomarse tiempo de mental health, hay otros que mejor le dan al trabajo, otros usan actividades como ejercicio, leer, etc. Es muy importante saber qué es lo que te da ese centro, para poder recurrir a eso en momentos de crisis, y respetar el espacio de la gente que lo procesa de manera diferente.
    • Alex: Este es el momento de ser vulnerable, se vale llorar, gritar, golpear, blame, vent, etc. Si no permitimos que la emoción fluya, eventualmente nos va a explotar más tarde y va a ser más complicado. Escúchate, qué es lo que tú necesitas y sobre ello, hazlo, es el momento. Fortalecer o crear una red de apoyo con peers y hacer uso real de ella. Como manager, reconocer que la gente con la que trabajamos no es robot: que tenemos emociones y que de alguna u otra manera somos impactados. Lo comuniqué también con mi leadership, en este caso para dar visibilidad de no esperar la misma velocidad de trabajo de mi equipo, que la velocidad aminorará, que nuestros deadlines no serán alcanzados y serán empujados un poco más.

    ¿Qué sigue?

    Para como está la situación actual, creo que sería bastante ingenuo asumir que no se necesita estar preparado para un evento como este. Pero es difícil. En un mundo como en el que vivimos actualmente, el trabajo sigue ocupando una gran parte de nuestra vida. La idea — el prospecto — de perder algo a lo que le dedicas un tercio del tiempo que pasas despierto, es completamente abrumador.

    Además, como se mencionó arriba: cada quien lidia con esto como puede. No hay un playbook, o un set de pasos a cumplir para salir librado de una situación como esta. Lo laboral significa algo completamente diferente para cada quien: a algunos nos pega más que a otros. Así que creo que es responsabilidad de cada quien saber qué es lo que necesitamos para procesar el evento y metabolizar la experiencia.

    Finalmente, quiero aclarar que es prácticamente imposible capturar todo lo que pasa por nuestras mentes en situaciones como esta. Yo no tuve la oportunidad de reaccionar emocionalmente hasta que terminé de escribir este artículo, muchos días después: literalmente hice catarsis y me solté a llorar. Y fui de los afortunados que se quedaron — reconozco ese privilegio. Tan solo me puedo imaginar qué es lo que están pasando los que se fueron. A todos ellos, I’m here for you. ❤️

  • Por qué el standup meeting no funciona en tu equipo

    El standup meeting (o daily meeting) es una práctica común en la industria del software. Los miembros de un equipo exponen avances en su trabajo, usualmente respondiendo las siguientes preguntas: ¿qué hiciste ayer? ¿Qué vas a hacer hoy? ¿En qué estás atorado?

    La intención es integrar al equipo, revisar progreso, y desbloquear posibles trabas en el flujo de trabajo. Lo que realmente sucede es que entras a la llamada, pero únicamente pones atención cuando escuchas tu nombre, y durante el tiempo que te toca hablar. Fuera de eso, lo que dijeron tus compañeros te pasó de largo, y saliste de la llamada sin haber aprendido más de lo que ya sabías.

    ¿Te suena? A continuación quiero exponer algunos factores que tal vez no habías considerado, pero que están influenciando la forma en que tu equipo colabora. Al final, te comparto algunas preguntas para ponderar.

    El standup meeting en empresas que se dedican a terminar tareas

    Para una empresa que se dedica a terminar tareas, como una consultora, es tan importante cumplir con el plazo que le prometió a su cliente, que casi seguro el equipo va a tener un Project Manager asignado. Y seguro va a estar presente en el standup meeting.

    El PM, como tiene que reportar progreso, es el único presente y atento durante la duración completa de la llamada, mientras todos los demás se van pasando la batuta de la atención y presencia cada vez que les toca hablar — y únicamente cuando les toca hablar.

    Entras, esperas 10 minutos a que tus compañeros den su reporte de estado; cuando es tu turno, prendes tu micrófono y tu cámara, recitas lo tuyo, y vuelves a lo que hubieras preferido no dejar de hacer en primer lugar.

    De acuerdo con el PMBOK, el standup meeting es “una llamada colaborativa corta, en la que el equipo revisa progreso del día previo, declara intenciones para el día en curso, y resalta los obstáculos encontrados o anticipados”.  En realidad, cuando el standup meeting sucede en servicio de una sola persona, rara vez es corta o colaborativa.

    El rol del Project Manager en todo esto

    El standup meeting que más se practica en la industria es en servicio del PM, no del equipo.

    Desafortunadamente, el PM suele ser una figura contenciosa ante el equipo de desarrollo. Muchos desarrolladores ven a su PM no como un aliado, sino como un antagonista externo al equipo que pone los intereses de todos los demás — el cliente, finanzas, ventas — antes que el del equipo de desarrollo. No es respetado, sino temido. Y en algunos casos, hasta resentido.

    Ahora observa la dinámica del standup meeting a través de este lente. Si el único que realmente se beneficia de tener esa llamada es el PM, con todas las connotaciones antes mencionadas, no es de sorprenderse que tú y tu equipo vean esto como una enorme pérdida de tiempo. ¿Qué ganaste habiendo atendido esa llamada, y por qué le tienes que rendir cuentas a alguien externo?

    Este sentimiento de frustración puede crecer lentamente en el resto del equipo, hasta convertirse en un problema de desgaste crónico: burnout.

    Afortunadamente, la apreciación de la figura del PM es algo que se puede mejorar: si el PM busca maneras de integrarse más en el equipo, y demuestra que sí tiene sus intereses en mente; y si el resto del equipo amplía un poco sus perspectivas para entender los incentivos de la empresa que hacen que el PM se comporte de esa manera.

    Requiere tiempo, dedicación, e intención. Pero se puede.

    El standup meeting en empresas de producto

    Empresas que se dedican a resolver problemas (usualmente empresas de producto), en algunos casos, también se comportan como consultoras: optimizando para la finalización de tareas. Siguen los mismos patrones organizacionales que las consultoras (un PM por equipo, con standup meetings y Scrum), sin darse cuenta de que los incentivos bajo los cuales están operando son fundamentalmente incompatibles con cómo están organizadas.

    Desarrollar soluciones robustas es una labor altamente matizada y dependiente de contexto. Así que es probable que por varios días seguidos la contribución de alguien en el standup meeting será algo como “sigo investigando lo mismo de ayer”; las reuniones dedicadas a realmente avanzar la solución del problema involucran personas con el contexto necesario para apreciar los matices del problema.

    Rara vez, todo el equipo tiene algo que aportar ahí.

    ¿Entonces los equipos de producto no deberían de tener standup meeting?

    No quiero decir que los equipos de producto no deberían de tener llamadas para sincronizarse o colaborar. Quiero resaltar que seguir un formato y cadencia de llamada que dicta el libro de Project Management, sin considerar las implicaciones y necesidades del equipo, es una mala idea.

    En los equipos de producto más exitosos en los que he tenido el privilegio de participar como desarrollador no teníamos standup meetings diarios. Teníamos llamadas semanales donde se comentaban las cosas más importantes a nivel estrategia del producto: ¿qué hito estamos cerca de cumplir? ¿Quiénes se podrían ver afectados? ¿Tenemos los planes de lanzamiento listos?

    Como Engineering Manager, he traído esa práctica a mis equipos con un alto nivel de éxito. Los miembros del equipo se sienten con la autonomía y confianza de ejercer su juicio y sentido de agencia para comunicar lo que crean pertinente, sin forzar una estructura ante el equipo. Dejamos espacio para que sean las necesidades del equipo definir nuestras dinámicas.

    Por otro lado, trabajar en una empresa de producto que opera como consultora, de la manera más cuadrada posible, fue una de las experiencias profesionales más frustrantes y desmoralizantes de mi carrera.

    ¿Cómo hacer que los standup meetings sean útiles y aporten al avance de las iniciativas?

    Los standup meetings se usan sin realmente saber en servicio de quién — o qué — estamos teniendo la llamada. Y esto es un problema

    Así como cualquier framework en tu lenguaje de programación favorito, al momento de elegir alguna metodología de trabajo tienes que tener claro 1) qué problema estás intentando resolver, y 2) si realmente es un problema en primer lugar.

    Aquí te dejo algunas preguntas para ponderar. Si eres gerente, manager o director de la empresa:

    • ¿Cuáles son los incentivos de la empresa: terminar tareas, o resolver problemas?
    • ¿Está mi organización alineada de manera correcta con esos incentivos, o estoy queriendo forzar la metodología de trabajo?
    • ¿Los incentivos que influencian nuestra metodología de trabajo son los correctos?
    • ¿Cómo podemos balancear la relación del PM, en caso de que haya uno, con el equipo de desarrollo, y viceversa?

    Si eres desarrollador:

    • ¿Cómo puedo mantener al PM al tanto del progreso de mi trabajo sin necesidad de usar el standup meeting?
    • ¿Cómo puedo ser más proactivo en mi comunicación para que el PM no sienta que le estoy ocultando información?
    • Meta: ¿qué preguntas le puedo hacer a mi PM sobre su trabajo, para entender sus motivaciones y el contexto en el que él o ella tienen que ejecutar?

    Si eres Project Manager:

    • ¿Cómo puedo hacerle saber al equipo que mi trabajo es darle visibilidad y estructura al suyo?
    • ¿Qué puedo hacer para integrarme más al equipo y que no se me vea como un intruso que solamente llega a pedir cuentas?
  • Cómo identificar la experiencia en otros ingenieros

    ¿Cómo saber que alguien no tiene mucha experiencia haciendo lo que hace? Porque constantemente está subestimando el esfuerzo o la complejidad de las cosas que quiere hacer.

    Algunas frases características de alguien nuevo haciendo software:

    • Yo podría hacer este sistema completo en un fin de semana si me lo propusiera.
    • Esta solución es estúpida, hay una manera más óptima de hacerlo.
    • Mañana queda, solo hace falta implementar los manejadores de errores.
    • ¿Por qué decidieron usar esta tecnología habiendo una más nueva?
    • Si yo estuviera a cargo, nunca habría elegido esa plataforma. Hay opciones mucho más escalables y con mejor soporte.

    Una marca infalible para identificar que alguien tiene experiencia haciendo lo que hace — sobre todo si eso es software — es que aprecia que todo sistema se puede romper o fallar, dependiendo del contexto en el que está desarrollada la solución. Se aproxima al problema con un sentido de curiosidad, no de juicio, para entender por qué se tomaron las decisiones que se tomaron, y el contexto dentro del cual se diseñó la solución.

    La experiencia informa sus estimaciones y proyecciones de éxito. Hace espacio para tomar en cuenta cómo se debería de comportar la solución cuando pase “lo que no debería de poder pasar”.

    Mientras más experiencia adquieres en la industria del software, más logras apreciar que no existen soluciones perfectas: únicamente existen soluciones para las cuales todavía no se encuentran deficiencias.

    Por algo se dice que el único trabajo de un Ingeniero Senior, es decir, “depende”.

  • Gatekeeping: qué es, cómo identificarlo, y cómo combatirlo

    Gatekeeping. Cuidar ranchos. Creer que la forma en que tú ves el mundo es la única válida que existe. Y activamente invalidar las perspectivas de otras personas.

    Me gusta hablar del gatekeeping. Para mi sorpresa, cada vez que lo menciono, me preguntan a qué me refiero con “gatekeeping” o “cuidar ranchos”. Estoy escribiendo este artículo con dos objetivos; 1) tener un enlace para enviar la próxima vez que me pregunten, y 2) generar un poco más de conciencia al respecto — porque pienso que hace falta.

    Como muchos fenómenos sociales y culturales, promovemos o padecemos el gatekeeping sin saberlo — porque nadie nos explicó que existía, y simplemente somos víctimas… o victimarios. Sucede lo mismo con el gaslighting, por ejemplo.

    El gatekeeping es una de las principales razones por las que las comunidades de tecnología se pueden sentir tan hostiles y cerradas para las personas que están intentando incursionar en este mundo. Viene de la noción de que “si me costó tanto trabajo a mí, no debería ser más sencillo para ti”, acompañado de un toque de narcisismo al asumir que la otra persona quiere exactamente lo mismo que tú — o que desea obtener exactamente tus mismos resultados.

    Hacer gatekeeping es estar tan envuelto en tu propia idea del mundo, tu craft o tus gustos, que ignoras los deseos, necesidades y perspectivas de las personas que te rodean. Antepones tu versión de lo que es “correcto” a tus supuestas ganas de “apoyar”, y terminas compartiendo respuestas condescendientes, que lo único que hacen es hacer sentir mal a la persona, que lo único que quería era tu ayuda.

    Sufrir del gatekeeping, en contraste, no te hace sentir superior ni valida tus ideales. Al contrario, te hace sentir mal, te hace dudar de tus habilidades y tu potencial. Te hace creer que no vas por el camino adecuado, y refuerza en ti la idea de que hay una única forma “correcta” de hacer las cosas, lo que es completamente erróneo. Sufrir del “cuidarranchismo” también es desalentador y te puede llevar a resentir la ayuda de aquellos que genuinamente quieran ayudarte.

    Qué hacer para combatir el gatekeeping

    gatekeeping en la industria del software

    Si te das cuenta de que cuidas ranchos: felicidades, acabas de completar el paso más difícil. Ahora es momento de hacer cambios en cómo te conduces. Primero, cuando alguien te pida ayuda (o quieras dar un consejo espontáneo), hazte las siguientes preguntas:

    • ¿Reconozco que la otra persona tiene un objetivo muy particular que no necesariamente tiene que ver conmigo y mi historia?
    • ¿Comprendo las necesidades, capacidades y situación de la otra persona?
    • ¿Tengo la claridad mental necesaria para compartir mi aporte sin intentar validar mi preconcepción personal de lo que es correcto o válido?

    Segundo, recuerda que si hay algún ambiente en el que haya respuestas absolutas y 100% correctas, no es en el mundo de la tecnología. Lo que hoy es aceptado, mañana puede ser considerado una mala práctica. Una de las características más importantes para trabajar en esta industria es tener la mente abierta.

    Tercero, haz las paces con tu antiguo yo que hacía gatekeeping y se sentía orgulloso por ello.

    Está bien: parte del proceso de crecer personal y profesionalmente es darte cuenta de lo que está mal y no aporta, y hacer algo al respecto. Y en eso estás, así que date la oportunidad de reconciliarlo y seguir adelante.

    ¿Y si soy víctima del gatekeeeping?

    Si eres víctima de un cuidarranchos, debes de saber que no es tu culpa. Esta industria está llena de personas con hábitos reduccionistas y absolutistas, y no eres la única persona que está pasando por esto. Puede sonar como justificación para su comportamiento, pero no lo es.

    Así como hay muchísimas personas en tecnología que basan su identidad en estar bien y promover estas prácticas, hay otras tantas que estamos jugando juegos infinitos, con ganas de ver a nuestros colegas crecer. Me atrevería a decir que somos más los que genuinamente queremos darte las herramientas para que salgas a hacer lo que tienes que hacer.

    Primero, asimila este concepto y agregarlo a tu vocabulario. También, hazte el hábito de identificar los indicadores de que estás lidiando con un cuidarranchos, y de que deberías de enfocar tus energías en buscar otro lugar para pedir ayuda:

    • Te quieren vender una única idea de cómo hacer las cosas
    • Te chantajean mencionándote cómo podrías fallar si no usas lo que ellos te recomiendan
    • Hacen menos las contribuciones de otras personas en la industria a diestra y siniestra
    • Cuando, salen a respingar cuando dices que deberías agregar documentación a tu código, y no únicamente escribir código que se documente solo.)

    Segundo, ayuda a que más personas se hagan conscientes de esto. Mientras haya más personas con la conciencia de lo que hacer gatekeeping representa, será mucho más sencillo sacar a flote estas discusiones. Esto es importante porque creo que nos merecemos tener espacios seguros donde podamos sentirnos respaldados por una comunidad que nos quiera ver crecer.

    Si detectas que alguien está haciendo gatekeeping, hazlo notar.

    Haz ruido, levanta la voz, hazles ver lo que está sucediendo. Si estás en una posición de liderazgo en la que puedas tomar acciones concretas al respecto, hacerlo es tu responsabilidad.

    Da feedback, modera, lidera. Y si ni explicando razones se remedia la situación, ahí no es.

    En conclusión…

    Saber lo que es el gatekeeping no es una licencia para que agregues un buzzword tech a tu vocabulario y sigas como si nada. Lo que diferencia a los humanos del resto de los animales es nuestra habilidad de ponerle nombre a las cosas. Hemos desarrollado un lenguaje que nos permite comunicarnos, establecer reglas y llegar a acuerdos. La principal motivación de ponerle nombre a las cosas es poder explicarlas, estudiarlas y mejorarlas. Así que ahora que sabes lo que es, que existe y por qué es importante compartirlo, también tienes la responsabilidad de hacer algo al respecto.

    En resumen

    • ¿Quieres de verdad llegar a ser un 10X Developer? Deja de cuidar ranchos.
    • ¿Quieres hacer algo por tu comunidad? Ayuda a un cuidarranchos a dejar esos modos.
  • Soft Skills que aprendes en tu primer año haciendo software

    En una publicación en Medium, Anish, un recién graduado de un bootcamp, nos cuenta los Soft Skills que ha aprendido en su primer año como ingeniero de software. Un poco de historia:

    A veces no puedo creer que en mayo de 2022 prácticamente no sabía nada sobre ingeniería de software (aparte de ser un auténtico experto en hacer que mi computadora diga ‘¡Hola, mundo!’). Avancemos rápidamente hasta hoy, y llevo más de 1 año en mi carrera profesional como ingeniero de software en una agencia creativa, y puedo decir con seguridad que estoy disfrutando cada segundo de ello.

    A continuación, te dejo algunos extractos de las cosas que más resonaron conmigo.

    Mentalidad de constante crecimiento

    La mentalidad de crecimiento (o growth mindset, como también se le conoce), te invita a darte cuenta de que cualquier cosa que parezca difícil en primera instancia, es algo que eventualmente puedes dominar. Siempre y cuando le pongas la dedicación adecuada.

    Desde que conseguí mi primer trabajo como desarrollador, he estado constantemente expuesto a nuevas ideologías, tecnologías y conceptos casi todas las semanas. Sin adoptar una mentalidad de crecimiento, tener tantos temas diferentes que aprender puede sentirse abrumador e incluso desafiante en ocasiones, especialmente viniendo de un bootcamp.

    También comenta sobre la importancia de poner las cosas en perspectiva, y que la visibilidad a largo plazo también es clave para darte cuenta de cuánto has crecido:

    …el crecimiento es una serie de altibajos, pero si observas el panorama general y te mantienes firme, dentro de 10 años tu conjunto de habilidades seguramente te sorprenderá.

    Habilidades fuertes de comunicación son clave

    Cómo trabajar en un equipo pequeño hace que la comunicación efectiva sea un factor clave para tener éxito y seguir creciendo:

    Trabajar en una empresa pequeña, con un equipo de desarrollo de 3 personas (que incluye a dos directores generales), hace que mis responsabilidades sean mucho más claras, por lo tanto, mis habilidades de comunicación con mis directores, gerentes de proyectos, ejecutivos de nivel C y clientes deben ser elevadas, precisas y claras.

    Este punto me pareció particularmente importante:

    El resultado de comunicar de manera efectiva permite a la empresa tener una idea más clara de cómo avanza un proyecto, si existen obstáculos y si lo entregaremos a tiempo.

    Entre desarrolladores existe el chiste de que los Project Managers saben decir una sola frase: ¿cómo vamos? Hasta memes hay. Si tú eres uno de esos, te pregunto: ¿no será que tú tienes que mejorar tus habilidades de comunicación para que no te tengan que estar preguntando cómo vas a cada rato?

    Las oportunidades que te va a dar ser parte de un equipo

    Trabajar con otras personas no es lo mismo que trabajar en equipo. Anish explica:

    Ya sea en un evento social del equipo, reuniones sociales de la empresa, un evento organizado por un colega, o simplemente almorzando con diferentes departamentos, es importante conocer a otras personas en la empresa.

    He aprendido mucho de todos aquí. No sabía lo que era la redacción publicitaria hasta que hablé con nuestro departamento de redacción.

    Ahora que Anish sabe que existe algo que se llama Copywriting, puede explorar otra perspectiva que aumentará el valor de sus contribuciones más allá de escribir código. Lo mismo pasa cuando hablas con gente de negocio, marketing, operaciones, y demás.

    Desarrollar software se trata de resolver problemas para personas. Mientras más herramientas tengas para ver esos problemas desde diferentes perspectivas, más oportunidades vas a tener de hacer un impacto real.

    Saber en qué necesitas mejorar

    Ejercicio de humildad, sí. Esta es la actitud correcta (y otra vez, growth mindset):

    Básicamente, soy un ingeniero de software de nivel intermedio ahora. Trabajo de manera autónoma en su mayor parte, he comprendido cómo leer la documentación minuciosamente, mis habilidades de comunicación son excelentes, y he contribuido en varios proyectos divertidos e innovadores. Sin embargo, las oportunidades siempre superan a mis éxitos, y eso está bien, porque estoy comprometido a seguir aprendiendo.

    Y reconocer que el síndrome del impostor es algo con lo que vamos a tener que aprender a vivir:

    Los sentimientos de síndrome del impostor vienen y van hasta el día de hoy, incluso después de haber estado un año en mi carrera y estar al borde de ser un ingeniero de nivel intermedio. Estoy aprendiendo que abrazar el síndrome del impostor es parte del camino y que no estoy solo.

  • Burnout, explicado para desarrolladores de software

    Hablar del burnout en abstracto puede carecer de impacto real. Déjame explicarte.

    Imagina que intentas explicarle a un niño de 3 años por qué es mala idea meter un tenedor en una toma de corriente. Para que aprecie los peligros de ello, tendríamos que explicarle primero sobre electricidad, materiales y sus propiedades de conducción eléctrica, y luego sobre el concepto de “electrocutarse”.

    Eventualmente, ya sea por accidente o academia, cuando el niño se haga consciente de la progresión de eventos que lo llevan a sentir la descarga eléctrica en su cuerpo, y los efectos en su salud, proactivamente evitará acercar un objeto de metal a una toma de corriente.

    Sucede lo mismo cuando hablamos de burnout. Intentar explicarle a alguien por qué debería de hacer todo lo posible por prevenir el burnout asume que la persona tiene el suficiente autoconocimiento para reconocer su origen y los efectos que los síntomas tienen en ella.

    El burnout se manifiesta de manera diferente en cada uno de nosotros

    Una rápida búsqueda en internet te dará síntomas como:

    • Agotamiento y fatiga constante.
    • Bajo rendimiento laboral.
    • Sentimientos de impotencia y fracaso.
    • Irritabilidad constante.
    • Procrastinación.
    • Problemas de comunicación.

    Muchos de estos síntomas también pueden estar asociados a trastornos de salud mental, como la depresión o ansiedad. En caso de duda, consulta con un profesional

    Aun así, aunque indicativos, son subjetivos. ¿Qué significa realmente “agotamiento”? Tu umbral de cansancio podría ser el nivel de energía estándar de otra persona. ¿Qué es “irritabilidad constante”, y cómo se manifiesta en tu día a día? Respuestas diferentes dependiendo a quién le preguntes.

    Además, tenemos diferentes niveles de resiliencia ante las mismas situaciones

    Agregándole una variable más al problema: no a todos nos pegan de igual manera las mismas situaciones.

    Dependiendo de la historia personal de cada quien, lo que para uno pudiera una situación completamente normal y manejable, para otra persona pudiera ser un problema complejísimo de sobrellevar.

    La misma situación tiene un impuesto de estrés diferente para cada uno. Recuerda eso.

    Fugas de Memoria: Un modelo mental para entender el burnout si eres desarrollador de software

    En el mundo del software decimos que no hay aplicación sin errores; solamente hay aplicaciones cuyos errores todavía no descubrimos.

    De igual modo, el burnout no es algo que está prendido o apagado, sino una serie de factores compuestos que se van acumulando y acumulando hasta que evolucionan y te hacen “tronar”.

    Es como una fuga de memoria, o memory leak, en tu programa: si se encuentra en una parte de la aplicación que tu usuario no visita varias veces durante la sesión, no hay tanto por qué preocuparse — el sistema tiene suficientes recursos para gastar. Pero si la fuga está en un hot path de la aplicación, muy pronto se convertirá en un problema. El sistema se quedará sin espacio para memoria “desperdiciada”, y terminará forzando el cierre de la aplicación.

    Ningún programa es 100 % eficiente. La mayoría de los sistemas complejos, tanto en software, como en la naturaleza, producen desperdicios — y está bien. Así como los dispositivos en los que corren nuestros programas están diseñados para seguir funcionando aún con cierto nivel de desperdicio de memoria, los humanos somos naturalmente resilientes para lidiar con cierto nivel de situaciones adversas que si no se mantienen bajo control pueden evolucionar a un nivel de burnout que nos haga rompernos emocional, intelectual o profesionalmente.

    Como buen desarrollador de software que se preocupa por el rendimiento de su código, ya tienes el hábito de depurar tu aplicación constantemente para asegurarte de que estás usando los recursos de tu sistema de la mejor manera posible. Ahora, como persona consciente de la importancia de evitar el burnout, regularmente evalúa si tus hábitos, rutinas, ambiente y forma de llevar tu día a día está ayudándote a mantener un nivel sano de burnout.

    Prevenir es mejor que lamentar

    No existen soluciones absolutas para los problemas humanos. En este continuo de vida y carrera, todas las soluciones a los problemas de las personas comienzan con un “depende”, y esto no es una excepción para el burnout.

    Pero eso no es excusa para “hacernos de la vista gorda” y hacer como que tomar acciones en pro de prevenirlo no es importante simplemente porque aún no sufrimos los estragos del mismo.

    Al contrario, creo que es un llamado a la acción para invertir un poco más en el autoconocimiento, que en sí es un proceso. Ver el burnout como un botón que puede estar en encendido o apagado limita tu capacidad de entender sus matices y complejidad. Ofusca la combinación de factores que pueden estar influyendo en un área tan relevante de tu vida, como tener la capacidad de continuar trabajando en algo que te gusta.

    Si eres de las personas que tienen el privilegio de no haber experimentado el burnout en carne propia, te invito a que utilices el modelo mental de Fugas de Memoria para comprender la importancia de ser proactivos y evitar que el burnout se manifieste. Si, por el contrario, ya has experimentado el burnout, te invito a que reflexiones y aprendas a detectar los síntomas y cómo se manifiestan en ti, y a través del autoconocimiento tomes las medidas necesarias para evitar que vuelva.

  • Feedback: cómo darlo, tomarlo, y apreciarlo

    La retroalimentación, o feedback, es una de esas habilidades blandas que solemos ignorar hasta que nos enfrentamos a situaciones que la requieren. Pero aquí te digo algo: dar y recibir feedback no solo es crucial para tu desarrollo profesional, sino también personal.

    Creo que la razón por la que ignoramos la importancia de esta habilidad hasta que es muy tarde es muy obvia, y también muy humana: es incómodo. Es incómodo reconocer nuestros límites, y darnos cuenta de que hay cosas en las que necesitamos mejorar. O, incluso, que hay cosas que hacemos, que tienen efectos secundarios que ni siquiera habíamos considerado.

    Sin embargo, por más incómodo que sea, es importante que como profesionales del software desarrollemos la capacidad de dar, recibir, e integrar feedback. Después de todo, si nuestro trabajo se trata de ser lo suficientemente resilientes al enfrentarnos a problemas indefinidos, ¿por qué no deberíamos de invertir un poco en ser más resilientes en un ámbito más personal?

    El feedback que recibes moldea tu trabajo. Y tu vida.

    Hace más de 10 años, Héctor, uno de mis mejores amigos, me aconsejó que dejara de amargar a los demás si ya no quería ir a la universidad. “Si ya no quieres venir, no vengas, pero no estés aquí haciéndonos pasar un mal rato”. Ese fue mi último semestre en la escuela.

    Unos años después, un recién graduado de Stanford me despidió semanas después de entrar a la startup donde ya llevaba yo más de un año trabajando. La relación no inició de buena manera, y un martes por la mañana me subí a una reunión de Hangouts con él, y me dijo que yo era muy difícil para trabajar, y que ese era mi último día.

    ¿Doloroso? Sí. ¿Incómodo? Obviamente. ¿Útil? También.

    Durante mi carrera y vida personal, los momentos que han dejado huella son aquellos en los que recibí feedback. Tan directo como mi amigo diciéndome que ya no era divertido tenerme cerca, lo que me llevó a tomar una decisión que cambiaría la ruta de mi vida. O tan indirecto como alguien simplemente diciéndome que ya no quería trabajar conmigo, tomando una decisión por mí.

    Consciente o inconscientemente, das y recibes feedback todo el tiempo

    Pensaba que la retroalimentación era una actividad puntual que tenías que hacer y programar. Así como puedes quedar con tus amigos para salir a tomar algo, ¿quedamos para darnos feedback?

    Aunque sí funciona así en el contexto profesional (en el mejor de los casos), la realidad es que constantemente estás dando y recibiendo feedback. Estés consciente de ello o no.

    Las muecas o gestos que otros hacen cuando les cuentas tus ideas, también son una forma de feedback. ¿Se muestran emocionados y animados, o hacen gestos de duda y consternación? ¿Te hacen preguntas de seguimiento, o solo te escuchan, asienten, y pasan a lo siguiente?

    Y lo mismo aplica para ti. ¿Cuál es tu postura cuando alguien te está compartiendo sus ideas? ¿Estás presente en la conversación, escuchando, o solo estás oyendo las palabras que salen de su boca?

    Se trata del comportamiento y sus efectos, no de la persona

    Es clave separar el comportamiento de la persona.

    La Navaja de Hanlon, uno de mis modelos mentales favoritos, dice:

    Nunca atribuyas a malicia lo que puede se explicado por estupidez.

    En este caso, creo que aplica cambiar la palabra “estupidez” por “ignorancia”. No atribuyas a malicia, lo que puede ser explicado por ignorancia.

    Todos somos ignorantes en algunos aspectos. Y está bien. Cuando das retroalimentación de manera directa — es decir, con intención — lo que estás buscando es hacerle saber a la otra persona el efecto de su comportamiento en su entorno, obsequiándole el beneficio de la duda de que dicho efecto se encuentra en su punto ciego.

    Así, eliminas el componente personal de la retroalimentación e incrementas las probabilidades de que el comportamiento sea corregido.

    Héctor hizo exactamente eso conmigo hace una década. En vez de decirme “eres un amargado y ya no quiero tenerte cerca”, me hizo saber el efecto que mi comportamiento estaba teniendo en mi grupo de amigos. Y no solo eso: también me dio una sugerencia de cómo lo podía resolver.

    Y le estaré siempre agradecido.

    Si haces lo que Héctor hizo conmigo, la persona que reciba nuestro feedback no lo verá como un juicio a su identidad personal (ego), sino como una oportunidad de revisar o seguir teniendo un comportamiento: algo que está completamente dentro de su control. Y sí, el feedback también es importante para reforzar los comportamientos con efectos positivos de las personas.

    Hay miles de maneras de dar y recibir retroalimentación

    También es retroalimentación:

    • El compromiso que generamos en otras personas
    • El detalle con el que otras personas contribuyen a nuestras ideas después de que se las contamos
    • La postura que adoptamos al interactuar con otros
    • La calidad de atención que le prestamos a alguien
    • El nivel de energía con el que interactuamos
    • Entre otras…

    Haciéndote conscientes de esto, puedes apreciar la importancia de que, al compartir feedback puntual, tienes que hacerlo buscando resaltar aún más las características del comportamiento que quieres corregir o promover en la otra persona.

    Recuerda que el feedback no es un lujo, sino una necesidad para crecer como profesional y ser humano. La invitación es a que aceptes la retroalimentación como una parte integral de tu oficio, tanto interna como externamente, y estarás en el camino hacia una carrera más humana y sostenible en la ingeniería de software.

  • El código que escribiste hoy ya es legado. No te encariñes.

    Recuerdo la primera vez que escribí código en producción que me hizo sentir orgulloso. Había pasado un buen rato adentrándome en un dominio con el cual no estaba familiarizado. Cuando por fin pude entender cuál era el problema, y luego sentirme lo suficientemente competente para saber cómo resolverlo, me sentí el mejor desarrollador de software del mundo. That’s how it’s done, baby. Esa noche ni dormí de lo emocionado que estaba por haber encontrado una solución tan impecable para arreglar el bug que me habían asignado y así resolverle un problema a un cliente.

    Un par de semanas después, un colega intentando resolver otro bug se encontró con mi código y decidió era un blocker para él poder resolver su problema. Hizo lo que haría cualquier otro (buen) ingeniero: analizó el problema, entendió el contexto del problema que yo había intentado resolver, lo incorporó a su conocimiento de dominio, e implementó una solución que abarcaba tanto mi problema como el suyo.

    Cuando vi su Pull Request eliminando mi código, sentí una combinación entre frustración, vergüenza y hasta un poco de enojo. Pero recuerdo que principalmente me sentí “atacado”. Por alguna razón, el que otra persona hubiera venido a arreglar un error en el proyecto, y que parte de su solución fuera eliminar código que yo escribí… eso era algo personal. En su momento no dije nada, pero sí me quedé con esa insatisfacción por un buen rato.

    Un poco después, en otra empresa, me volvió a pasar. En esta ocasión, mi código no estaba intentando resolver un bug particular, sino que intentaba crear una base para construir otro feature dentro de la aplicación. El Pull Request de mi compañero no solamente lo eliminaba, sino que repensaba completamente la filosofía con la que se deberían construir los features subsecuentes.

    Ouch. Creo que en esta segunda ocasión sí le mencioné algo a mi manager, pero no dejé de tener una sensación incómoda.

    Luego pasó otra vez. Y luego otra. Y otra.

    Esto no dejó de pasar. Independientemente de la empresa en la que estuviera, eventualmente me iba a tocar revisar un Pull Request que modificara, o simplemente eliminara, código que yo había escrito.

    Hasta que entendí que fomentar el apego emocional al código que escribía no iba a ser sostenible. Invariablemente, alguien más llegaría a transformarlo o eliminarlo. Eso no iba a cambiar — es la naturaleza de trabajar en esta industria. Entonces lo que tenía que cambiar era la forma en como me relacionaba con mi código.

    No dejé de recibir Pull Requests que eliminaran mi código. Lo que sí cambió fue mi actitud al respecto.

    Déjame contarte cómo lo logré.

    Mascotas vs. Ganado

    Tu código es ganado, no mascota.
    Tu código es ganado, no mascota.

    Si me conoces, sabes que me encanta usar modelos mentales (en alguna ocasión incluso hablé sobre esto en un podcast), y me emociono cada vez que me encuentro uno nuevo para entender el mundo.

    Resulta que la comunidad de DevOps tiene un modelo mental apto para este problema: Mascotas vs. Ganado (Pets vs. Cattle). Cabe aclarar que en el mundo de DevOps, la unidad atómica de información no es una línea de código, sino un servidor, pero la analogía aún aplica para nuestro propósito. Te explico cómo aplicaría este modelo mental para desarrollo de software.

    DevOps Código
    Mascotas Un servidor que no se puede caer. Tiene que estar siempre disponible, y no tiene redundancia. Código que es indispensable y único, y no puede ser eliminado.
    Ganado Clústeres de servidores preparados para fallar y ser descartados si se necesita. Están diseñados con el manejo de fallas en mente, y su despliegue está automatizado. Código resiliente que está diseñado con flexibilidad en mente, y preparado para cuando inevitablemente falle o tenga que ser eliminado.

    La idea central, obviamente, es que una mascota tiene un lugar especial en tu vida. A una mascota la cuidas, nutres, procuras su bienestar, y te devastaría perderla. Por el contrario, el ganado está para cumplir un propósito en específico, ya sea trabajar o proveer de alimento, y no reparas en usarla para su propósito. Con la mascota te encariñas. Con el ganado, no.

    Es así como, aprendiendo de la experiencia de la comunidad DevOps, podemos entender que tenemos que ver el código que escribimos como ganado, y no como mascotas.

    El trabajo de un desarrollador de software es resolver problemas, no escribir código

    ¿Por qué nos es tan sencillo encariñarnos con el código que escribimos?

    Mi hipótesis es que, como desarrolladores, estamos acostumbrados a usar la lógica para resolver nuestros problemas, y nos es muy sencillo establecer una correlación directa entre la tarea mecánica de escribir código y nuestro valor como profesionales. Creemos que se nos paga por escribir código, cuando no es así.

    Puede sonar contra intuitivo. Después de todo, muchas personas iniciamos en esta industria porque nos gusta escribir código. Pero la realidad de tener una carrera en esta industria es que la única razón por la que alguien estará dispuesto a pagarnos el sueldo tan alto que nos hemos acostumbrado a esperar es porque amos a resolverles un problema, a ellos o a sus usuarios — que lo hagamos a través del código que escribes es otra cosa.

    Si tu única medida de valor es el código que escribes, no los problemas que resuelves, suena lógico que lo sientas como un ataque personal con carga emocional cuando alguien decide eliminar o modificar tu código.

    Matt Basta en su newsletter aborda un punto tangencial, pero igual de relevante, para el tema del que estamos hablando:

    A menudo escucho a gente bastante joven decir cosas como “Estoy aquí para crecer como ingeniero”. Crecer como ingeniero es mutuamente excluyente con cuánto duran tus contribuciones. “Crecer como ingeniero” significa convertirte en un mejor ingeniero, y convertirte en un mejor ingeniero (directa o indirectamente) significa mejorar en el uso de tus habilidades para crear valor. Al principio de tu carrera, el trabajo que realices probablemente tendrá mucha menos longevidad que el trabajo que realices más adelante, simplemente porque ganas madurez con el tiempo y aprendes a crear herramientas que tienden a ser útiles por más tiempo.

    A veces, el valor que generas se traduce en resultados técnicos. A veces, es la forma en que trabajas con las personas que te rodean (colaborando, asesorando, etc.). A veces, se trata de cómo apoyas al resto del equipo. Hay muchas formas de crear valor.

    Este es el verdadero aprendizaje: el código que escribes es únicamente una de las formas en las que se manifiesta el valor que agregas a tu equipo. ¿Por qué habríamos de darle un lugar tan prominente a algo que es inherentemente volátil, y que representa solo una de las muchas maneras en que nuestro valor profesional es manifestado?

    No te encariñes con tu código

    Como alguien que lo hizo profesionalmente por más de una década, reconozco lo satisfactorio que es escribir código que me gustaría viviera por siempre. Al mismo tiempo, como alguien que pasó por un arduo proceso de separar mi identidad personal de mi experiencia como desarrollador, reconozco que fomentar un apego emocional al aspecto técnico de nuestro trabajo no es una manera sostenible de llevar una carrera en esta industria.

    Sobre todo, si lo que quieres hacer es trabajar en lo que te gusta por mucho tiempo.

    Al final del día, tu impacto no son las líneas de código que escribes. Lo que realmente se queda es el problema que resolviste y cómo eso mejoró la experiencia del usuario o facilitó el trabajo de tu equipo. En ese sentido, tu trabajo es tan sustentable como los problemas que resuelves. Así que, la próxima vez que sientas un apego emocional hacia tu código, recuerda: no eres tus líneas de código; eres las soluciones que ofreces.

  • Elon Musk tiene un estilo de liderazgo que no deberías copiar

    La semana pasada salió la esperada biografía de Elon Musk, por Walter Isaacson

    Si me conoces, sabes que de mis principales intereses son la psicología y liderazgo. Esta es una rara oportunidad de descubrir lo que sucede en privado con una de las personas con más influencia en la industria de la tecnología. Sus modos (lo que se ve en público) no me encantan, pero el resultado a gran escala de sus esfuerzos es innegable.

    Compré la biografía porque quiero conocer los matices de su personalidad y estilo de liderazgo.

    Elon Musk Biography

    En el pasado ya ha habido libros que intentan contar una historia para prevenir a otras personas de seguir caminos que llevan a situaciones indeseables que tienen el efecto contrario.

    La pregunta es: ¿será que algunas personas van a leer esta biografía buscando justificación para ser igual de assholes que Elon?

    En el minuto 14 de la entrevista que le hicieron a Walter Isaacson sobre el libro abordan este tema, y su respuesta es bastante clara: nadie debería de intentar emular a Elon Musk; una biografía no es un libro de recetas. Sin embargo, no dudo que muchos vayan a leer esta biografía y sentirse validadas en sus modos hostiles de tratar a la gente que trabaja con ellas. Si a Musk le funciona, a mí debería funcionarme también.

  • Saber venderte como desarrollador no es echar mentiras

    ¿Alguna vez has intentado venderte, hablar sobre tus logros y habilidades, y te sientes inadecuado o incómodo? Si tu respuesta es que no, déjame entonces preguntarte: en tu currículum, ¿compartes ejemplos de cómo le ayudaste al negocio con tus habilidades de desarrollo, o simplemente tienes una lista de tecnologías como JavaScript, HTML y CSS?

    Ahí está.

    Es hora de enfrentar este problema.

    Auto-Sabotaje Técnico: por qué no sabes cómo venderte

    Muchos ingenieros, programadores y profesionales técnicos están alérgicos a la idea de “venderse”. Preferimos hablar en lenguajes de programación, no en el lenguaje del valor humano o del impacto en el negocio. Desde un punto de vista psicológico, es una forma de auto-sabotaje. Minimizamos nuestro valor al no saber comunicarlo de manera efectiva.

    Recuerdo una conversación con uno de mis mentores que cambió mi perspectiva. Me preguntó: “¿Por qué le tienes tanto miedo a venderte bien en la industria?” Mi respuesta fue rápida: “Porque no quiero echar mentiras.” Sin embargo, él me mostró que hablar de mis habilidades técnicas y el valor que agrego a los equipos, en términos que los responsables de presupuestos entienden, no es echar mentiras, sino traducción.

    Naturalmente, como yo no estaba acostumbrado a hablar en esos términos, cuando hablaba de “valor agregado” y en vez de “arquitectura de aplicaciones” sentía que estaba echando mentiras. Pero no: estaba hablando de exactamente lo mismo, solamente que desde otra perspectiva.

    Aprender a hablar el Lenguaje del Valor

    Traduce tu valor. Como desarrolladores de software, tenemos que comenzar a ver que vender nuestras habilidades no es manipulación, sino adaptación. No es cambiar lo que hacemos, sino cómo lo comunicamos. La clave aquí es entender que en una organización se hablan diferentes lenguajes, y que aprender a hablarlos aumenta nuestro valor y nos permite colaborar de manera más efectiva.

    Dominar el lenguaje del valor es esencial para tu desarrollo profesional. Esta habilidad no solo te beneficia diariamente como desarrollador de software, sino que se convierte en un factor decisivo al buscar un aumento, un nuevo trabajo o un rol más avanzado. Hablar en términos de valor puede ser la llave que abre la puerta a oportunidades que transformarán tu carrera.

    Consejos prácticos para venderte mejor

    Aquí hay algunos consejos prácticos para que comiences a perderle el miedo a venderte.

    Identifica y lista tus habilidades: Antes de poder traducir tus habilidades a un lenguaje más accesible, primero debes saber exactamente qué estás ofreciendo. Esto va más allá de las habilidades técnicas; piensa también en las habilidades blandas que has desarrollado. Por ejemplo, si eres bueno resolviendo conflictos dentro de tu equipo, eso es algo que también tiene gran valor.

    Consejo: usa el método STAR (Situación, Tarea, Acción, Resultado) para describir situaciones específicas donde demostraste tus habilidades, sea de liderazgo, trabajo en equipo o resolución de problemas.

    Encuentra un Traductor de Valor: Este puede ser un mentor, un colega de otra área o incluso un amigo que tenga habilidades para comunicar y entender tanto el mundo técnico como el empresarial. Ellos pueden ayudarte a encontrar las palabras y conceptos que transmitan tu valor de una manera comprensible para todos.

    Ejemplo: Si eres un experto en optimización de bases de datos, un “Traductor de Valor” podría ayudarte a describir esta habilidad como “mejorar la eficiencia operativa reduciendo los tiempos de espera para los usuarios”.

    Practica con Escenarios Reales: No basta con saber cómo traducir tus habilidades; debes practicar. Ya sea en entrevistas de trabajo, conversaciones con stakeholders o incluso en tus interacciones diarias con tu equipo, toma la oportunidad de hablar sobre tu valor. La próxima vez que tengas una revisión de desempeño o una conversación similar, intenta usar este nuevo lenguaje de “valor”. Prepara antemano cómo vas a describir tus contribuciones de manera que resuenen con tu audiencia, y después evalúa cómo fue recibido.

    Por ejemplo, la próxima vez que hables con un gerente de proyecto, un cliente o modifiques tu currículum, en lugar de decir que “implementaste un algoritmo de búsqueda eficiente,” podrías explicar que “mejoraste la experiencia del usuario al hacer que la búsqueda de información en la aplicación sea más rápida y precisa.”

    Recibe Retroalimentación y Ajusta: Después de cada intento de vender tu valor, busca retroalimentación. ¿Fue efectiva tu comunicación? ¿Hubo algo que pudiste haber dicho de una manera más clara? Utiliza estos aprendizajes para ajustar tu enfoque en el futuro.

    Aquí hay una oportunidad de ejercer la Mentalidad de Crecimiento: La habilidad de “venderse” es como cualquier otra habilidad: se puede aprender y mejorar. Mantén una mentalidad de crecimiento y estarás vendiéndote como un profesional en poco tiempo.

    Conclusión

    En definitiva, aprender a comunicar tu valor es mucho más que una técnica de negociación; es una inversión en tu crecimiento profesional y bienestar emocional. Al dominar el lenguaje del valor, no solo incrementas tus oportunidades para conseguir un mejor salario o avanzar a roles más prominentes. También ganas una nueva capa de autoconfianza, un sentido de propiedad sobre tu carrera que se traduce en un mayor cumplimiento personal y profesional.

    Así que no lo postergues; empieza hoy a traducir tus habilidades técnicas en términos de valor.

    No es solo un cambio de vocabulario; es una transformación completa que puede elevar tu carrera a nuevas alturas.

  • Finanzas personales para desarrolladores de software

    Hoy quiero hablar de finanzas personales y dinero. Particularmente, desde la perspectiva de un desarrollador de software en la industria de la tecnología.

    Las personas que trabajamos en la industria del software somos extremadamente afortunadas. Nuestras habilidades nos han puesto en posiciones privilegiadas donde, podemos asumir — o casi garantizar — que tendremos acceso a sueldos por mucho más altos que los del ciudadano promedio.

    De acuerdo con Glassdoor, el sueldo base promedio para un desarrollador de software en México ronda los $51,000 MXN mensuales (o un poco más de $600,000 MXN al año). Esta cifra no contempla otros tipos de compensación, como bonos de rendimiento y RSUs, que harían que la cifra real estuviera más cerca o sobre el millón de pesos anuales. Mientras tanto, datos oficiales de gobierno dicen que, durante el segundo trimestre de 2023, el sueldo promedio para profesionistas y técnicos en México fue de $7,300 MXN mensuales — o casi siete veces menos que un desarrollador de software.

    Finanzas personales y dinero. Gráfica que compara los sueldos mensuales promedio entre profesionistas y técnicos y desarrolladores de software en México.
    Gráfica que compara los sueldos mensuales promedio entre profesionistas y técnicos y desarrolladores de software en México.

    Con esta disparidad en mente, es evidente que como desarrolladores de software llevamos una ventaja significativa en la economía actual. Pero con este privilegio también viene una responsabilidad. La industria nos ha brindado un poder económico y una estabilidad que muchos otros no tienen, y es crucial reconocerlo y actuar con la seriedad y conciencia que esta posición merece. Hablar de promedios nos ayuda a notar tendencias, pero no nos habla de la experiencia de cada una de esas personas. Es esencial no olvidar que detrás de cada cifra hay historias individuales y luchas, y es nuestro deber como profesionales privilegiados actuar con responsabilidad.

    El problema con el discurso usual sobre finanzas personales

    Usualmente, cuando se habla de finanzas personales, el ángulo que se toma es el de cómo podemos maximizar el rendimiento. ¿Qué instrumento me va a traer más dinero? ¿Cómo le puedo ganar al mercado?

    El problema con el discurso usual sobre finanzas personales, creo, es que no aplica para desarrolladores de software. Ya le ganamos al mercado — simplemente por virtud de nuestra posición en la industria y los recursos a los que tenemos acceso. Nuestro sueldo base es 7 veces más alto que el del ciudadano mexicano promedio. De nuevo, sin contar bonos, ni otros tipos de estructuras de compensación comúnmente usadas en esta industria.

    Sanar mi relación con el dinero y finanzas personales requirió darme cuenta de la realidad

    Cuando comencé a ganar lo que yo consideraba “un buen sueldo”, allá por 2015, decidí que era hora de sumergirme en el mundo de las inversiones. Devoré un par de libros sobre finanzas, y me compré algunos cursos que, por un rato, me hicieron creer que ya estaba capacitado para manejar mi dinero. Pero esa sensación de competencia no duró mucho.

    Unos años después había multiplicado mi sueldo unas cuatro veces. A pesar de esto, sentía que el dinero se esfumaba aún más rápido, y mi percepción general sobre mi situación financiera era más negativa que cuando inicié a ponerle atención a esta área de mi vida.

    Por un tiempo seguí utilizando la misma estrategia de finanzas personales que había estado empleando hasta ese momento: buscar la manera de incrementar mi ingreso. Suponía que mi situación mejoraría con el siguiente aumento de sueldo. “Cuando por fin gane $50,000 al mes, ya no tendré estos problemas. No, cuando gane 60. No, 80.”.

    En 2021, a media pandemia, fue cuando encerrado y sin manera de ignorarlo, tuve que enfrentar el problema. Me seguía sintiendo descontento con mi salud financiera y mi relación con el dinero, y tenía la prueba empírica de que tener más no iba a ser la solución.

    Lo que sí me funcionó para mejorar mis finanzas personales: sanar mi relación con el dinero

    Decidí cambiar la forma en que estaba pensando resolver mi problema. Cambiar las tácticas por una visión más holística de la situación. Lo que tenía bastante claro es que no sabía por qué, aunque cada vez ganaba más dinero, no me sentía mejor, más completo o más feliz. Muchas veces, era al contrario.

    En mi caso, después de hablar con un par de asesores de finanzas personales, leer muchos libros, e intentar “descifrar el código”, entendí que lo que tuve que haber hecho era buscar cómo sanar mi relación con el dinero, y no elegir el vehículo de inversión que me diera mejor rendimiento.

    Descubrí que el dinero es un tema emocional y psicológico, no de números.

    El problema no era la falta de dinero, sino cómo verlo positivamente al tenerlo. Mis experiencias pasadas y la educación familiar sobre el dinero me dieron una perspectiva sesgada, impidiendo que lo disfrutara o me sintiera satisfecho con él.

    Entendí que estaba intentando resolver un problema emocional y psicológico con tácticas, lógica y matemáticas.

    Esto se manifiesta de manera diferente para cada uno, por supuesto. Pero te invito a reflexionar. ¿Qué narrativas e ideas con las que creciste pueden estar jugándote en tu contra? ¿Qué frases sobre el dinero creciste escuchando que ahora, sin darte cuenta, están interfiriendo con tu salud financiera?

    Los recursos que me ayudaron a sanar mi relación con el dinero

    A continuación te comparto los recursos que me ayudaron (y me siguen ayudando) a mejorar y mantener una relación positiva con el dinero, lo que da como resultado finanzas personales más sanas. Están en el orden sugerido de lectura.

    Empieza por The Psychology of Money de Morgan Housel. Si es tu primer acercamiento al mundo de las finanzas personales, y trabajas en esta industria, ese libro te ayudará a ganar un poco más de perspectiva sobre qué realmente significa invertir, más allá de tácticas, mercados, cuál es el “mejor instrumento”, etc. En este libro, Morgan Housel también habla sobre el aspecto social y psicológico que el dinero juega en nuestras vidas y sociedad.

    No desaproveches la oportunidad de iniciar sin vicios, malas experiencias, habiendo intentado “ganarle al mercado”, etc. Lo he leído por lo menos 3 veces durante los últimos dos años, y cada vez encuentro pasajes que me resuenan de maneras diferentes.

    El autor recientemente empezó un pódcast donde explora estos temas de manera más detallada. Te recomiendo comenzar con estos episodios:

    Define tu propia versión del éxito

    Lee Die With Zero de Bill Perkins para terminar de asentar el punto de que para tener “éxito en las inversiones”, primero tienes que definir qué significa ese éxito para ti. (Spoiler alert: no es una cantidad de ceros en el banco) Este libro toca temas un poco más profundos y filosóficos, como la muerte, el legado que quieres dejar en la tierra, y el factor que juega el ego en la toma de decisiones financieras. El argumento del autor es bastante claro aquí, deberías de optimizar tu vida para que cuando mueras, tu cuenta de banco esté en ceros. Interesante

    Si esta lectura se te hace muy rebuscada, o toca temas difíciles de digerir para ti, te recomiendo como alternativa que leas Your Money or Your Life. Este libro es un poco más táctico, pero la esencia de la idea principal está muy alineada a Die With Zero.

    Vuélvete más táctico con Ramit Sethi

    Finalmente, para definir las tácticas que realmente te funcionen a ti, te recomiendo el modelo mental de Ramit Sethi, en I Will Teach You to Be Rich. De manera práctica, el contenido de Ramit fue lo que me ayudó a salir de deudas, y comenzar a usar mi dinero de manera que me sintiera feliz, cómodo, y seguro. Actualmente, soy parte de su comunidad en línea, tomo las llamadas con él todos los meses, y participo en el canal de Slack.

    Las ideas sobre finanzas personales de Ramit pueden ser poco ortodoxas o hasta parecer contrarias de primera impresión, pero resonaron mucho conmigo y realmente fueron las únicas que me ayudaron a reconfigurar mis tácticas y estrategias financieras. Si quieres primero dar una probada de la filosofía de Ramit antes de comprar leer el libro, puedes ver su conferencia en Google (43 min), una de sus entrevistas con Tim Ferriss (1:27), o su show en Netflix (8 episodios de ~1 h).

    Ramit también tiene un pódcast donde entrevista a parejas y les ayuda con sus problemas de dinero. Es prácticamente terapia de pareja al rededor del dinero, en vivo. Se van bastante profundo.

    Todos estos libros los he comprado y regalado varias veces a mis amigos cercanos. Y planeo seguir haciéndolo. Actualmente, en mi librero tengo varias copias de cada uno, listos para ser entregados en un abrir y cerrar de ojos a alguien que crea le pueden servir.

    En resumen: si trabajas en software, ya le “ganaste al mercado”, y buscar cómo ganar un porcentaje extra de ganancia no va a hacer una diferencia real en tu vida si no sanas primero tu relación con el dinero.

    Por lo menos esa fue mi experiencia. Y si las charlas que he tenido con otras personas son indicador de algo, considero que muchas personas en esta industria estamos en la misma situación. Pero nos cuesta trabajo (o nos da pena) aceptarlo.

    Para resumir, mi recomendación es que primero trabajes en sentirte más segura de que tu relación con el dinero está sana, que entiendes por qué y para qué estás invirtiendo (más allá de agregarle ceros a tu valor neto).

    Ya que tengas eso claro, todo lo demás es aritmética básica. Ahora sí, enfócate en instrumentos, estrategias, etc. Si lo haces al revés y primero te metes a entender la mecánica de la inversión, puede que te encuentres en una situación como alguna de las personas que entrevista Ramit en su pódcast, que tienen 8 millones de dólares en el banco, pero como nomás acumularon sin un propósito, siguen batallando por comprar fruta orgánica porque cuesta 3 dólares más. 

  • Reactancia: lo que sientes cuando te hacen micromanagement

    Es probable que hayas experimentado una reacción emocional particular, aunque tal vez no sepas cómo se llama. Se llama reactancia, y es una reacción emocional que ocurre cuando sientes que tu libertad está siendo amenazada.

    La reactancia puede surgir en una variedad de contextos, pero en el mundo de la ingeniería de software, aparece cuando alguien en una posición de autoridad, como tu manager o líder de equipo, te dice exactamente cómo hacer tu trabajo. En nuestra industria, a esta práctica se le conoce coloquialmente como micromanagement. Seguramente habrás escuchado el término.

    La reactancia en acción

    Imagina que estás trabajando en un proyecto de software complejo. Has estado trabajando en él durante semanas, y has desarrollado un plan sólido para su implementación. Pero entonces, tu gerente, sin previo aviso, te dice que cambies tu enfoque y sigas un camino diferente sin una razón aparente. En lugar de considerar sus sugerencias de forma templada, sientes una ola de resistencia, frustración, o hasta enojo. Esto es la reactancia en acción.

    La reactancia es una respuesta natural a la amenaza percibida a nuestra autonomía. Como ingenieros de software, valoramos nuestra habilidad para resolver problemas y diseñar soluciones. Cuando alguien intenta imponer su camino, puede sentirse como una invasión a nuestra libertad para innovar y crear.

    De forma práctica, la reactancia se puede manifestar de diferentes maneras. Comúnmente, si estás experimentando reactancia, puede que sientas una fuerte resistencia a acatar las instrucciones y te sientas frustrado o hasta enojado. Puede también que comiences a procrastinar y dejar que el trabajo se apile. En casos extremos, la reactancia se puede manifestar como rebeldía, al sentirte obligado a hacer exactamente lo opuesto que te dijeron.

    La reactancia no se manifiesta igualmente para todos

    Es importante recordar que todos experimentamos esta reacción emocional de manera diferente. Al ser consciente de cómo se manifiesta en ti, puedes aprender a manejarla de manera más efectiva.

    Entonces, ¿cómo puedes manejar la reactancia?

    • 1. Reconoce tus emociones: Primero, tienes que ser consciente de que estás experimentando reactancia. Si te sientes frustrado o resistente después de recibir instrucciones, es posible que estés experimentando este fenómeno.
    • 2. Comprende la intención: A veces, las personas que nos dan instrucciones tienen buenas intenciones. Intenta entender por qué te las están dando. ¿Tienen experiencia que tú no tienes? ¿Están tratando de evitar un problema que han visto antes?
    • 3. Comunícate abierta y honestamente: Si sientes que tu libertad está siendo amenazada, habla con la persona que te está dando instrucciones. Explica cómo te sientes y propón alternativas que te permitan mantener tu autonomía. Recuerda que tú también puedes dar feedback a tus líderes. Si sientes lo contrario, analiza si es momento de cambiar de ambiente de trabajo.

    Si lo ves de esta manera, el estar consciente de la existencia de, y saber cómo manejar la reactancia es una cualidad importantísima en un desarrollador de software senior. Significa que son capaces de prevenir conflictos innecesarios, facilitar la implementación de nuevas ideas y mantener un alto nivel de motivación tanto en ellos mismos como en su equipo.

    Lo importante es que reconozcas cómo se manifiesta en ti

    La reactancia es una reacción emocional que todos hemos experimentado, especialmente cuando sentimos que nuestra libertad está siendo amenazada. En el ámbito de la ingeniería de software, esta amenaza puede presentarse cuando alguien en una posición de autoridad, como un gerente, nos dice exactamente cómo hacer nuestro trabajo, un fenómeno conocido como micromanagement.

    La reactancia puede manifestarse de varias formas, desde resistencia y frustración hasta procrastinación y rebeldía. Sin embargo, al reconocer estas emociones, comprender las intenciones detrás de las instrucciones que recibimos y comunicarnos de manera abierta y honesta, podemos manejar efectivamente la reactancia.

    Para un desarrollador de software, la capacidad de manejar la reactancia puede prevenir conflictos innecesarios, facilitar la implementación de nuevas ideas y mantener un alto nivel de motivación, tanto personalmente como dentro del equipo. Por lo tanto, entender y manejar la reactancia no solo te permitirá recuperar u sentido de autonomía, sino que también te equipa con las herramientas necesarias para prosperar en tu campo.

  • Problemas Zanahoria: la ilusión del éxito que percibimos en otras personas

    Hace unos días un amigo me compartió un artículo que exploraba una idea bastante interesante. Hablaba sobre la importancia de tener claro que lo que nosotros podemos percibir como éxito en otras personas, puede tener una agenda oculta detrás.

    Uri, en su blog:

    Durante la Segunda Guerra Mundial, cuenta la historia, los británicos inventaron un nuevo tipo de radar a bordo que permitía a sus pilotos derribar aviones alemanes por la noche.

    No querían que los alemanes supieran sobre esta tecnología, pero tenían que dar una explicación sobre sus nuevos e improbables poderes.

    Así que inventaron una campaña de propaganda que afirmaba que sus pilotos habían desarrollado una vista excepcional al comer “un exceso de zanahorias.”

    Si vas a engañar a la gente para que haga algo inútil, comer zanahorias en exceso parece ser una de las mejores opciones. Sin embargo, hay un problema: las personas que creían en la propaganda y trataban de obtener una super-visión estarían invirtiendo tiempo y esfuerzo en algo que no iba a funcionar.

    Llamo a esto “el Problema Zanahoria”.

    Me encanta cuanto es posible encapsular comportamientos sociales de manera tan sucinta en una idea.

    Continúa:

    Una vez que buscas Problemas Zanahoria, los ves en todas partes. Esencialmente, cada vez que alguien logra éxito de una manera que no quiere admitir públicamente, tiene que inventar una excusa para sus habilidades. Y eso significa engañar a un montón de gente para que (potencialmente) pierda su tiempo, o algo peor.

    Hay que hacer una nota aquí: el “éxito” no es absoluto, ni significa lo mismo para todos. Para mí, hoy en día el éxito significa tener la capacidad de moldear mi entorno en función de que me permita tener tranquilidad y la opción de tomar decisiones sin apuros. Pero sí, al inicio de mi carrera, “éxito” significaba otra cosa completamente diferente. El éxito para mí en aquel entonces estaba determinado por factores externos, como status, dinero, y “ser el mejor” en lo que hacía — programando.

    Además, que alguien no quiera admitir la razón de su éxito de manera pública no siempre es por malicia. A veces simplemente es porque genuinamente no lo sabe (falta de introspección y consciencia), o vergüenza (prefiero que creas que llegué a esa solución por mi gran genio, y no que anoche lloré de desesperación frente a la computadora intentando encontrar el problema).

    Por supuesto, una vez que sabes que tus supuestos modelos a seguir están haciendo [algo malo] para tener éxito, eso no significa que tú también tienes que hacerlo. Idealmente, encontrarás alguna otra manera de tener éxito en el mismo campo sin hacer cosas malas; si no, podrías simplemente decidir que este juego en particular no es uno en el que quieras participar.

    Una vez exploré este tema con mi terapeuta. Durante la sesión, le compartí mi enorme frustración por no ser “tan bueno” como algunos de mis compañeros de trabajo, y lo que me dijo en esa sesión me cambió la vida. “Si tuvieras la oportunidad, ¿cambiarías tu vida completa por la de esa persona simplemente para ser igual de bueno programando?” Mi respuesta fue no.

    Aprender a identificar Problemas Zanahoria me ha salvado de muchas frustraciones desde entonces. Ahora, cuando veo a alguien que considero un modelo a seguir haciendo algo a lo que aspiro, en vez de querer traducir de manera directa lo que yo percibo como “éxito”, procuro expandir mi perspectiva y ver la imagen completa.

    ¿Cambiaría mi vida completa por la de esa persona, simplemente para poder estar al mismo nivel en este aspecto particular?