Hace un par de días, GitHub anunció que Copilot está ahora disponible de manera general.
Cualquier persona, hoy puede pagar $10 USD mensualmente por un compañero de pair programming creado con inteligencia artificial.
Buen momento para recordar lo que escribí hace casi exactamente un año:
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.
Si estás en la industria del software y piensas que tu único trabajo es programar, heads up. Le acaban de poner fecha de caducidad a tu carrera. Y tienes de dos: o te pones a refinar tus soft skills, o comienzas a especializarte en tecnologías fundamentales.
El término “comunicación” es tan amplio y dependiente del contexto del trabajo y la industria en la que uno se desempeña, que muchas organizaciones deciden simplemente no ponerle mucha atención. Adoptan una mentalidad de que “lo que importa es que las cosas se hagan, pero no importa cómo.”
La cultura de comunicación de tu empresa tiene un gran impacto en el resto de tu negocio. Cultivar una atmósfera de confianza es esencial para el éxito. El nivel de confianza que las personas en tu organización depositan en sus líderes y en ellos mismos, afecta la productividad, la salud de tus compañeros y la retención a largo plazo del equipo.
En su artículo, Adam menciona que existen principalmente dos tipos de empresas: las que quieren hacer las cosas en privado, y las que quieren hacer las cosas en secreto. La diferencia es sutil, pero el diablo está en los detalles.
Cualquier información que se comparta llamadas, mensajes directos o canales privados se pierde en el limbo. Esto le resta visibilidad al equipo, se pierde la trazabilidad del proceso de toma de decisiones, y en muy poco tiempo, la confianza del equipo se ve mermada por esta opacidad.
A muchos líderes les cuesta trabajo ver más allá de la meta puntual que tienen en frente, e ignoran las consecuencias de fomentar una cultura de comunicación que hace que los miembros del equipo se sientan asediados, estresados e inseguros.
Personalmente, estoy consciente de estos problemas y lo fácil que es caer en una situación donde el comportamiento por defecto es ocultar información. En mis equipos procuramos que cualquier llamada que tengamos con otros miembros quede resumida en un mensaje donde se listen los acuerdos a los que se llegaron. También, usamos canales de Slack públicos por defecto, y todos tenemos la expectativa de mover cualquier pregunta que nos hagan por DM a un canal público.
El Proyecto de Ley 5761-S, en la legislatura de Washington, dicta que las descripciones de vacantes deberán incluir detalles completos de la compensación que recibirá la persona contratada.
Puedes leer el documento final aquí. A considerar es que esto solamente aplicaría para compañías que tengan 15 o más empleados.
Espero que esto se vuelva práctica estándar eventualmente.
Y creo que es una excelente oportunidad para recalcar un punto que a muchas personas se les escapa: un lenguaje de programación no es lo mismo que una tecnología.
Los lenguajes son herramientas que te permiten razonar sobre problemas puntuales de maneras muy particulares.
Por ejemplo, intentemos razonar sobre el concepto del “paso del tiempo”. Para los que hablamos Inglés y Español, vemos el pasado como algo que está a la izquierda, y el futuro como algo que está a la derecha del presente. Los que hablan Árabe, al revés, ponen el pasado a la derecha y el futuro a la izquierda. Y los que hablan Mandarín, ponen el futuro arriba y el pasado abajo.{{{L. Boroditsky, “Does Language Shape Thought?: Mandarin and English Speakers’ Conceptions of Time”, Psicología Cognitiva 43: 1-22 }}}
Un lenguaje no solamente te permite resolver problemas particulares, sino que, además, cambia la manera en que entiendes el problema en primer lugar. Puedes hablar Mandarín perfecto, pero si te sigues refiriendo al pasado como algo que sucede a la izquierda del presente, no te van a entender cuando trates de explicarle el paso del tiempo a alguien en China.
Hay una distinción, sutil, pero importante, sobre lo que queremos expresar, y el contexto en el que lo expresamos.
Cuando el autor del Tweet original dice que “el lenguaje de SQL se ha mantenido vigente por más de 40 años” no se refiere a que no ha habido avances en la tecnología que le da el contexto necesario al lenguaje. SQL es un modelo mental tan poderoso para resolver problemas de organización, administración y escritura de datos, que trascendió su tecnología y se convirtió en un estándar de la industria. Hoy, si sabes SQL, puedes programar bases de datos utilizando diferentes tecnologías, como Oracle, MySQL, Access, PostgreSQL, Sybase, Microsoft SQL Server, y más.
Ahí es justamente donde yo dibujaría la línea. Si sabes SQL, un lenguaje que sigue siendo relevante después de 40 años, no significa que no tienes que preocuparte por el contexto en el que vas a usarlo. Ese contexto hoy en día es mucho más amplio y tiene muchos más matices que cuando la tecnología original fue inventada. Y la primera pregunta que cualquier persona experimentada te haría si le pides consejo porque quieres usar SQL para administrar una base de datos es, ¿tienes la certeza de que una base de datos relacional es la solución adecuada?
SQL permanecerá vigente indefinidamente mientras haya necesidad de resolver problemas de bases de datos relacionales. Pero la tecnología fundamental, el contexto en el que el lenguaje realmente brilla, puede cambiar, mejorar, empeorar, y sí, hasta desaparecer.
Saber cómo expresarte en un lenguaje de programación no es una bala de plata. Incluso me atrevería a decir que tener dominio de únicamente un lenguaje puede llegar a ser contraproducente. Porque para ser eficiente y efectivo programando, no solamente tienes que saber expresar la solución a un problema — también debes poder determinar si la solución que quieres expresar es la adecuada para el contexto de tu problema.
Es decir, tienes que saber si estás intentando usar Mandarín para explicarle a un Chino que ayer está a la izquierda.
Toda la diferencia entre el trabajo de producto vs. el de consultoría está en los incentivos que determinan el cómo se trabaja.
Hacer consultoría se trata de completar proyectos para un cliente. El objetivo es entregar a tiempo y cumplir con un contrato.
Si trabajas en consultoría, lo que importa es entregar en tiempo y forma, lo que significa que la calidad y exactitud técnica del desarrollo no es prioridad. Después de todo, hay una gran posibilidad de que una vez que se llegue a la meta, y el cliente esté satisfecho, no será necesario revisarlo ni mantenerlo a largo plazo. Se le resolvió el problema al cliente, se entregó a tiempo y con los requerimientos cumplidos, y ahora puedes pasarte a pensar en el siguiente proyecto sin voltear atrás.
Trabajar en desarrollo de producto se trata de resolver problemas para un usuario. El objetivo es agregar valor.
Al desarrollar un producto, lo que estás buscando es crear tecnología para resolverle un problema a tu usuario. Muy probablemente (si trabajas en un startup, por ejemplo) no habrá una guía para encontrar la forma óptima de agregar valor. Tendrás que experimentar, investigar, innovar. Pero más importante, trabajar en producto tiene la implicación de que el mismo equipo será el responsable de arreglar cualquier cosa que se rompa, y de saldar cualquier deuda técnica que se adquiera.
La fuente de frustración más grande que he experimentado es cuando he intentado desarrollar un producto como si trabajara en consultoría, y viceversa. Pero dejo esa historia para otra publicación.
Un verdadero Senior no va a caer en la trampa de simplemente ir a implementar cosas sin pensar en sus posibles consecuencias e implicaciones a largo plazo. No va a aceptar mediocridades, y va a presionar para mejorar procesos — no solamente dentro de su área.
Pocas organizaciones están preparadas para lidiar con el “pushback” que esto representa.
Muchos que dicen querer contratar ingenieros de este nivel, en realidad lo que quieren son desarrolladores “nivel Mid” con muchos años de experiencia resolviendo cierto tipo de problemas. Pero no Senior.
Un sistema operativo es más que una interfaz gráfica y un conjunto de API: es una manera de ver el mundo. La forma en que está diseñado e implementado modela la forma en que sus usuarios interactúan con él.
Las decisiones técnicas de la implementación de un sistema operativo informan, de manera directa o indirecta, como sus usuarios piensan acerca de las capacidades y potencial del sistema con el que están interactuando.
Por ejemplo, Windows y macOS, a nivel técnico, manejan de manera completamente diferente el ciclo de vida de una aplicación. En Windows, el proceso termina al cerrar la ventana. En macOS, un mismo proceso puede tener múltiples ventanas abiertas, y cerrar una ventana no afecta el ciclo de vida de la aplicación que la mantiene. Un usuario relativamente avanzado, como tú, puede estar consciente de las implicaciones de usar cada estrategia de manejo de memoria y emitir un juicio sobre cuál ofrece más ventajas sobre la otra. Pero un usuario normal lo único que sabe es que en Windows cerrar una ventana significa que el progreso que ha hecho en su documento se va a perder, mientras que en macOS no.
Creo que es una buena analogía para entender la importancia de tener cuidado al momento de diseñar, implementar y mantener una base de datos.
Las discusiones sobre qué motor de base de datos deberíamos emplear, si implementar una relacional o una basada en documentos, son bastante comunes. Las que intentan entender si el modelo de datos que estamos construyendo tiene sentido lógico, es semánticamente correcto y qué tipo de valor añade al negocio, no lo son tanto.
Una base de datos es útil en la medida en que los datos que almacena puedan ser manipulados, actualizados e interpretados. Los desarrolladores de software estamos muy acostumbrados a pensar en bases y modelos de datos únicamente como componentes transaccionales de nuestro proceso de desarrollo. “Tengo esta información aquí que necesito preservar de alguna manera”.
Lo que nos falta concientizar, en muchos casos, es que otras personas, como analistas de negocios, científicos de datos y tomadores de decisiones, y otros desarrolladores, dependen de que la data que nosotros manipulamos y almacenamos sea accesible.
Al igual que un sistema operativo influye en la percepción de las capacidades de una computadora, un modelo de datos moldea la forma en que otras personas resuelven problemas. Considera que la persona que va a utilizar tu base de datos está viendo su universo a través de tus decisiones de diseño e implementación. Aunque técnicamente tengas la información guardada, no va a servir de nada si esta no es accesible.
Aquí te dejo algunos consejos puntuales que puedes comenzar a implementar desde hoy para que tus datos sean más accesibles:
Comienza por tener buenas bases técnicas
Date cuenta de que no hay motor de base de datos que sea una bala de plata. Lo que te funciona para resolver cierto tipo de problemas, no necesariamente funcionará para otros. Habiendo dicho esto, es importante que sepas que tienes toda la flexibilidad del mundo para implementar soluciones combinadas. Por ejemplo, para el módulo de contratos puedes usar una base de datos no-relacional, orientada a documentos. Mientras que en tu módulo de analítica puedes utilizar una base de datos distribuida como Cassandra, y en tu módulo de perfiles de usuario una un poco más tradicional como PostgreSQL.
Sigue las mejores prácticas de cada tecnología que implementes. Si tienes bases de datos relacionales, normaliza tus tablas en caso de que esto agregue valor para tu caso de uso (si estás haciendo un sistema de analítica, mientras menos normalización mejor). Si tienes una base de datos basada en documentos, embebe los modelos que tengan relaciones para evitar joins a nivel aplicación.
Recuerda que una buena base técnica es únicamente el primer paso para tener modelos de datos accesibles.
Identifica tus datos y tus metadatados
Recuerda que hay dos tipos de datos:
Datos de primer grado (el contenido de un correo electrónico)
Y datos que describen los datos de primer grado, también conocidos como metadatos (quién le mandó el correo a quien, a qué hora, a través de qué cliente de correo electrónico, etc.).
La forma en que razono sobre estos tipos de datos es la siguiente: los datos de primer grado me permiten operar el día a día de mi negocio. Los metadatos me dan una visión de más alto nivel para detectar patrones de comportamiento de mis usuarios — incluso problemas potenciales que cuando se comiencen a ver reflejados en los datos de primer grado, será mucho más difícil corregir.
Aprende a identificar estos dos tipos de datos, y pregúntate si deberías de mantenerlos de manera integrada, o los metadatos deberían vivir en su propio repositorio de información. Toma tu decisión, y procura que este mismo patrón se siga en el resto de tu organización.
Procura la precisión semántica
“Precisión semántica” es solamente una manera rebuscada de decir que es primordial que todos los involucrados estén hablando de la misma idea en un momento dado.
Por ejemplo, ¿tienes claro qué es un “usuario activo” para tu negocio? En tu base de datos, este concepto pudiera estar simplemente representado por una tabla Users con una columna is_active, pero probablemente para el negocio un usuario activo es la relación intermedia entre la tabla de usuarios y la tabla donde están almacenados los contratos de servicio.
Una discrepancia así de sencilla en el significado de un factor tan básico del negocio, puede ocasionar muchísimos problemas. ¿Cómo podrás refactorizar el código de la aplicación que interactúa con usuarios sin causar efectos secundarios imprevistos? ¿Cómo podrá el negocio estar seguro de que los datos que reporta a los inversionistas son realistas?
Es importante que la forma en que diseñas tu base de datos esté informada por las necesidades del negocio. Después de todos, van a ser el negocio mismo el que se va a beneficiar o perjudicar como resultado de las decisiones técnicas que tomes. Ignorar esto es una receta para causar fricciones innecesarias y malentendidos entre equipos, además de que inherentemente estarás contaminando los datos que estás recabando.
Por eso recalco que se necesita precisión semántica — tanta como sea posible.
Aunque trabajes en un equipo de ingeniería, si tu trabajo es diseñar o mantener una base de datos, déjame decirte que tu rol está más cercano al negocio de lo que crees. De hecho, hasta cierto punto, la persona que diseña o mantiene una base de datos funge un punto de conexión entre el negocio y el equipo de desarrollo, pues está influenciando a través de sus decisiones técnicas a ambas partes sobre cómo razonar sobre los problemas que tienen enfrente.
Procura que tu base de datos sea un reflejo semánticamente preciso con respecto a lo que tu negocio necesita.
Haz que la data esté disponible par quien la necesite
Apóyate de herramientas como Panoply, Metabase o Tableau para habilitar la interpretación de los datos que mantienes.
Dependiendo de tu organización, es probable que no todo mundo necesite (o tenga permiso para) ver toda la información cruda. Procura tener una gobernanza de datos bien establecida para que haya forma de identificar si cierto dato en particular necesita ser visto por un stakeholder en particular.
Como parte del protocolo de manejo de datos con los equipos con los que trabajo, usamos réplicas de nuestras bases de datos para cuando otras unidades del negocio necesitan acceso a los datos crudos. Pero nunca les damos acceso a las instancias de producción. Esto puede variar de organización a organización.
Si sigues estos consejos, estarás haciendo algo porque tu trabajo no solamente sea correcto técnicamente, sino que además harás que sea útil y agregue valor a la organización. Toma en cuenta que esto es únicamente una parte de la ecuación, porque en mi mundo ideal, la gente de negocio sabría más de desarrollo de software. Y los desarrolladores de software se interesarían más por el negocio para el que trabajan.
Pero vamos paso a paso.
Gracias a Xavier Carrera por su feedback y ediciones en este artículo.
Subhro Saha comparte en su blog la siguiente idea: cuando muestres una propuesta para hacer algo nuevo, asegúrate de incluir el por qué no se debería de implementar en primer lugar.
El argumento es que al enfocarte únicamente en lo que podría salir bien, y los beneficios que podría traer la implementación de tu idea, te estás cegando a lo que podría salir mal. Al hacer el ejercicio de complementar tu propuesta con algún argumento de por qué lo que estás proponiendo sería una mala idea, tu propuesta se vuelve mucho más completa.
Subhro comenta:
El objetivo debería de ser presentar el argumento de “hombre de acero” — eso es, presentar las razones más interesantes del por qué no se debería de hacer algo.
En mis equipos de ingeniería promuevo crear RFCs para coordinarnos y definir el panorama de los proyectos en los que trabajamos. Una de las secciones más importantes del RFC para mí es la de “Implicaciones y puntos ciegos” de la propuesta. En esta sección, la tarea del autor es listar los efectos secundarios y cambios necesarios que deberían de ocurrir en la organización una vez que los cambios sean introducidos, así como cualquier punto ciego del que se tenga consciencia.
En el pasado, es justamente en esta sección donde nos hemos dado cuenta de que no solamente deberíamos implementar la solución propuesta, sino que deberíamos hacerlo rápido.
Tu tarea: procura complementar tus propuestas con argumentos en contra de ellas. Aunque suene contraproducente, hacer esto te ayudará a hacer propuestas más completas y con menos puntos ciegos y efectos secundarios indeseados.
Ben Adam, compartió en su blog su experiencia entrevistando y trabajando como Sr. Design Technologist en Amazon. La historia que comparte Ben está interesante, tomando en cuenta que solamente duró 10 meses en la organización.
Aquí te comparto algunas de los aspectos de su historia que más me llamaron la atención.
Amazon funciona como un conglomerado de mini-empresas
Cada una con sus propias metas, presupuestos, organigrama y formas de trabajar. La manera en como se coordinan es más similar a una empresa contratando los servicios de otra, que un equipo trabajando para un bien común. Por ejemplo, si un equipo necesita ayuda de otro para cumplir uno de sus objetivos, el primero puede financiar el incremento de personal del otro para hacerlo.
La normalización de procesos y estrategias únicamente existe únicamente dentro de estas mini-empresas
El puesto de Ben, como Sr. Design Technologist, es el puente entre los equipos de diseño y de desarrollo. Naturalmente, una de las primeras cosas que hizo fue intentar entender cómo funcionaba el sistema de diseño para las herramientas internas. Resulta que no había uno, sino 56.
En una empresa del tamaño de Amazon, donde solamente en el grupo en el que trabajó Ben eran 29 mil empleados, es imposible intentar planchar todo. Las necesidades de cada elemento de la organización son diferentes, y por eso es necesaria tanta granularidad en cómo se hacen las cosas.
Por más que nos quejemos de Excel, la realidad es que la mayoría de los negocios existen gracias una o más hojas de cálculo compartidas por correo electrónico. Y Amazon no es la excepción.
Como desarrolladores, por más que queramos automatizar absolutamente todo, tenemos que hacer las pases con la idea de que nuestros usuarios lo que quieren es resolver un problema — no usar tu software. Y si tu cliente puede resolver su problema con Excel (o cualquier herramienta que ya conozca, domine y tenga a su disposición), créelo: lo va a hacer.
Tu trabajo es entender la necesidad de la persona y hacer lo sensato para resolverla. Algunas veces tu solución tomará la forma de una solución a la medida, que diseñas y construyes desde cero. Algunas otras, agregarás valor simplemente al sentarte con tu cliente y explicarle cómo podría hacer su trabajo más fácil si organiza su información de cierta manera en la hoja de cálculo.
Mientras más rápido asimiles esto — que desarrollar software no siempre es escribir código — mejor.
En Amazon, la documentación es esencial
Jeff Bezos, famosamente, prohibió las presentaciones de PowerPoint en Amazon. En su lugar, todas las decisiones sustanciales se hacen acompañadas de documentos cuidadosamente redactados para un propósito en particular. Y sí, el proceso de redactar un documento puede ser un poco más tardado, pero al final de todo, termina siendo tiempo empleado de una manera mucho más efectiva.
Algunos de los documentos con los que se toman decisiones en Amazon:
PRFAQ – Press Release and Frequently asked questions: para presentar una nueva idea o inversión de tiempo o recursos. Empieza por cómo terminarías vendiendo esto a los stakeholders e intenta adelantarte a las preguntas que saldrán como parte de este anuncio.
OP1 –El plan a un año del equipo: qué van a hacer y cómo lo van a lograr. Este documento es un poco más completo, y entra en detalles estratégicos de cómo lograr los objetivos.
BRD – Business Requirement Document: qué es lo que se necesita hacer desde el punto de vista de negocio. Lista las cosas que deben suceder, a detalle, para lograr los objetivos.
Design Document – Documento de ingeniería donde se listan los detalles técnicos de la implementación y alternativas consideradas.
1 Pager – resumen ejecutivo con todos los detalles relevantes para poner a cualquier persona al día con la iniciativa.
Como he dicho antes, escribir documentación no tiene más que beneficios para la organización y los proyectos. Y si algún día quieres trabajar en Amazon, aprender a escribir buena documentación es una de las primeras cosas que tienes que aprender.
Trabajar en una compañía grande no es para todos
Finalmente, Ben, después de 10 meses de trabajar en una empresa a la que muchos aspiran entrar, se dio cuenta de que no era un buen lugar para él. Como dije anteriormente, este tipo de empresas requiere que tengas aspectos de tu personalidad muy particulares. Una excelente adaptabilidad al cambio, comodidad con la incertidumbre y al caos, etc.
Por mejor desarrollador que seas, si no estás cómoda con tu ambiente de trabajo será bastante difícil que lo puedas disfrutar y crecer sin sacrificar tu salud mental.
El mundo del desarrollo de software libre ha estado en las noticias últimamente. Desde la vulnerabilidad de Log4j que mandó a todo mundo a actualizar sus servidores, hasta las controversias por grandes compañías construyendo servicios y productos encima de productos de código libre sin honrar la naturaleza del mismo.
Con iniciativas como GitHub Sponsors, las compañías que dependen del software libre buscan incentivar que las personas que mantienen los proyectos sigan trabajando en ellos. Sin embargo, el panorama no se ve tan alentador para aquellos que tienen que lidiar con las implicaciones de mantener proyectos que son usados por millones de personas.
Esto es deprimente, por decir lo menos. Es deprimente porque no veo otra alternativa más qu dejar de escribir software. Después de todo, no puedo encontrar trabajo, no puedo hacer dinero trabajando en software libre, y el código que escriba puede terminar dañando a más personas de las que ayuda.
Mi interpretación del problema es que el propósito del software open source se ha pervertido a lo largo de los años. Inicialmente, la idea era poder colaborar para crear mejores soluciones. Durante un tiempo, cuando se construían las bases de la industria de la tecnología, eso era una realidad. Hoy en día, el que una solución sea de código abierto se utiliza como excusa para no dedicar tiempo a entender sus fundamentos.
¿Cuándo fue la última vez que realmente te dedicaste a entender la solución que un paquete de NPM implementaba? No importa, porque es de código abierto, y seguramente alguien más encontrará lo que está mal en ella — si es que hay algo mal, en primer lugar.
La comunidad de código abierto aporta muchísimo beneficio a la industria. ¿Cómo se logrará hacer que reconozca estos beneficios y corresponda de igual manera a la comunidad que habilitó su creación en primera instancia?
Aquí una idea de cómo puedes comenzar a influenciar un cambio positivo: si el producto en el que trabajas depende de una pieza en particular de código open source, pídele a los líderes de tu organización que asignen una parte del presupuesto para contribuir económicamente al mantenimiento de ese proyecto. Si la persona encargada no tiene habilitado un perfil de GitHub Sponsor, estoy seguro de que estará más que contenta de recibir un wire transfer mensualmente con la contribución de tu empresa.
El principal factor que desmotiva a algunos líderes de intentar el trabajo asíncrono, dicen, es que “es más tardado.”
Está codificado en nuestro ADN preferir resultados inmediatos. Si bien no podemos cambiarlo, sí podemos desarrollar la consciencia necesaria para entender que las personas (y por ende, organizaciones) que están dispuestas a demorar la gratificación inmediata, tienden a tener menos problemas, son más estables y gozan de mayor éxito.
Tomemos como ejemplo la imagen clásica que se usa para intentar comunicar la diferencia entre el trabajo duro y el trabajo inteligente.
Imagen usualmente usada para representar la diferencia entre trabajo duro y trabajo inteligente.
Observa cómo ambas soluciones aparentan resolver el problema de una manera u otra — pero ninguna de manera sostenible. Los que trabajan duro llegan tarde, cansados y probablemente no van a querer hacerlo de nuevo, mientras que el otro llegó con una esfera cuando le pidieron un cubo.
Una cultura de trabajo asíncrona les habría permitido considerar de manera consciente sus opciones. Darse cuenta de que empujar el cubo no es viable si quieren seguir trabajando ahí, y que llegar con una esfera tampoco lo es porque lo que les pidieron fueron cubos. Probablemente, un equipo trabajando de manera asíncrona, con todo lo que eso significa, habría llegado a la conclusión de que para llevar cubos de un lugar a otro, la mejor opción es rentar una camioneta que lo haga.
Sí, el trabajo asíncrono es un poco más tardado. Porque te pide disciplina, orden y que consideres cuidadosamente, a consciencia, las implicaciones de tus decisiones.
Sí, el trabajo asíncrono puede ser un poco más caro. Porque hace mucho más que apagar síntomas de los problemas.
El trabajo síncrono e inmediato subsana síntomas. El trabajo asíncrono y a conciencia resuelve problemas de raíz.
Creo que el trabajo asíncrono puede ser la clave para tener éxito en el 2023.
El éxito, independientemente de lo que signifique para cada quien, se consigue con el principio fundamental de identificar lo que funciona y lo que no, para luego hacer más de lo que funciona, y menos de lo que no.
El debate canónico entre líderes es sobre qué filosofía deberían impulsar en sus equipos para alcanzarlo: el trabajo duro, o el trabajo inteligente. Las personas que defienden cada punto piensan haber logrado encontrar la respuesta. Hay que trabajar más duro, y no tan inteligentemente — o al revés.
Incontables horas se han invertido en intentar encontrar el balance perfecto entre trabajar duro e inteligentemente. No te podría decir si se ha llegado a algo sustancial en esas discusiones, porque parece ser que la conclusión intelectualmente estimulante es que deberías de trabajar inteligente y duro al mismo tiempo.
Mi postura es que hay que ser lo suficientemente inteligente para identificar en qué trabajar duro. Y la filosofía de trabajo que te permite hacer eso, es el trabajo asíncrono.
Déjame explicarte. Vamos por partes.
Trabajo duro vs. inteligente
Analicemos la versión más polarizada de cada parte del argumento.
El que propone trabajar duro sugiere que el valor de la recompensa al final del camino es directamente proporcional al esfuerzo que costó conseguirla. Esta mentalidad te dice que mientras más tiempo y esfuerzo le inviertas a algo, mejor será el resultado. Y que si estás tomando atajos para conseguir tu objetivo, significa que no lo quieres tanto, ergo, no lo mereces. Sigue estrategias de productividad tradicionales y rudimentarias. Desvelos, estrés, sangre, sudor y lágrimas. El trabajador duro se siente orgulloso del sacrificio personal que significa conseguir su objetivo.
El que recomienda trabajar de manera inteligente busca atajos y la menor fricción posible. “El fin justifica los medios” es su frase favorita, y hará hasta lo imposible por ahorrarse tiempo, dinero y esfuerzo en virtud de obtener un resultado positivo. Encontrará fallas en los sistemas que le den una ventaja sobre sus competidores, y si resolver un problema no es cuestión de vida o muerte, no buscará la manera de hacerlo hasta que lo sea. El trabajador inteligente se siente orgulloso de haber logrado resultados adecuados por una fracción del esfuerzo que otros le invirtieron al mismo problema.
En ambos extremos de este espectro, los objetivos se cumplen y se llega al éxito.
El problema, y la razón por la que estos extremos son malos, es que ninguno de estos modelos de trabajo es sostenible a largo plazo en el contexto de un equipo u organización.
El trabajo duro termina por quemar a las personas. Las jornadas de trabajo son enloquecedoras, con horas interminables y retos imposibles, justificados por una cultura de sacrificio. Aquellas personas que forman parte de una cultura que glorifica el trabajo duro dejan de preocuparse por su bienestar y el de sus familias, y de alguna manera internalizan que cualquier cosa que valga la pena merece trabajo extenuante.
El trabajo inteligente, en su versión más extrema, produce soluciones frágiles e insostenibles. Estas soluciones, si bien cumplieron con objetivos puntuales, generan deuda técnica y organizacional, porque al estar construidas atajo sobre atajo, cambiar de dirección es cada vez más costoso y complicado. Además, una cultura en la que el fin justifica los medios, invita a sus integrantes a no buscar más allá de las soluciones rápidas y fáciles (“inteligentes”). Hace que las personas dejen de pensar de manera crítica, irónicamente.
Imagen usualmente usada para representar la diferencia entre trabajo duro y trabajo inteligente.
Los aspectos negativos de los extremos en este debate están representados en la imagen al inicio de esta sección.
Esta imagen, irónicamente, intenta comunicar los beneficios del trabajo inteligente. Pero analiza: los que empujan los cubos están trabajando obviamente de más, mientras que el que decidió esculpir una esfera tiene una tarea mucho más sencilla.
Observa cómo ninguno de los dos extremos resuelve el problema real: llevar un cubo de izquierda a derecha de la manera más eficiente posible. Los que trabajan duro llegaron tarde, cansados y probablemente no van a querer hacerlo de nuevo, mientras que el otro llegó con una esfera.
Cualquier extremo de esta discusión termina siendo perjudicial para la organización una vez aplicado. Es aquí donde debemos de buscar un punto medio que nos permita encontrar un balance entre el trabajo duro y el trabajo inteligente. Una manera de trabajar que nos permita tomar los mejores aspectos de los extremos y usarlos de una manera sana, que produzca resultados y que no cueste el bienestar de los miembros del equipo.
Ese punto medio es el trabajo asíncrono.
El trabajo asíncrono
Trabajar de manera asíncrona, en esencia, significa que cada miembro de la organización puede moverse de manera independiente, convergiendo en tiempo/espacio con otros solo en situaciones absolutamente necesarias.
Cuando se trabaja de manera asíncrona, los miembros de un equipo tienen el sentido de agencia necesario para tomar decisiones y hacerse responsables de sus consecuencias. Cuentan con la confianza de sus líderes, pues los objetivos son claros y los problemas a resolver tienen sustento. Trabajan en público, y son transparentes con sus procesos de deliberación. Sus mensajes son claros y asertivos, y no están atados a un horario de disponibilidad definido.
Valoran el resultado de su esfuerzo, no la magnitud del mismo.
Si el principio para alcanzar el éxito es hacer más de lo que funciona, y menos de lo que no, ¿cómo sabes cuál parte del proceso está funcionado y cuál no, si no tienes más que información anecdótica sobre ello? Al contrario de los modelos de trabajo síncronos, donde los problemas se resuelven en privado, a través de medios efímeros y con opacidad, el trabajo asíncrono deja una estela de información que puede ser utilizada para analizar y mejorar el proceso de toma de decisiones de la organización.
Hay que ser lo suficientemente inteligente para identificar en qué trabajar duro. Y el trabajo asíncrono ofrece un balance sostenible entre ambos mundos.
Trabajar de manera asíncrona puede ser considerado trabajo duro porque te reta a ser consciente de tus pensamientos y a estructurarlos para poder escribir ideas coherentes. Requiere que crees los sistemas de información necesarios en tu organización para poder delegar la toma de decisiones. Te obliga a confiar en tu equipo y a ser responsable de tu comportamiento y disciplina.
Trabajar de manera asíncrona también es trabajar inteligente porque estás haciendo que los miembros de tu equipo cuenten con la autonomía para tomar decisiones, incrementando su sentimiento de satisfacción y felicidad. ¿Sabes qué producen las personas satisfechas y felices? Buenos resultados. Eso es inteligente. Además, al trabajar de manera asíncrona, los miembros del equipo tendrán el tiempo y espacio necesario para ejercitar su creatividad y solucionar problemas de una manera más fundamental.
Trabajar duro en ser un mejor líder, y al mismo tiempo inteligente por fomentar una cultura laboral sana y que respete a las personas que se desarrollan en ella. No suena mal.
Conclusión
La decisión de trabajar duro o trabajar inteligente, a final de cuentas, termina siendo responsabilidad de cada quien.
Si tú, como líder, en tu organización fomentas una cultura de trabajo duro, hazlo con la conciencia de que las personas que trabajan contigo eventualmente van a cansarse y se van a ir.
Si, por el contrario, fomentas una cultura de trabajo “inteligente”, date cuenta de que probablemente estás creando una organización que produce soluciones frágiles y costosas.
Pero si fomentas una cultura de trabajo asíncrono, estarás asumiendo tu responsabilidad como líder de equipo. Crecerás personal y profesionalmente, mientras generas un ambiente de confianza, autonomía y responsabilidad compartida con tu equipo. Uno donde las personas se sentirán parte de una organización que respeta su tiempo, esfuerzo y pericia.
Así que, entre decidir trabajar duro o inteligente, recuerda que hay que ser lo suficientemente inteligente para identificar en qué trabajar duro.
Para un desarrollador de software es sencillo comprender por qué un proyecto se puede complicar. Entendemos las implicaciones y complejidades de desarrollar soluciones.
En una empresa tradicional, para bien o para mal, las personas que terminan tomando decisiones no siempre tienen el mismo nivel de entendimiento.
Tener el hábito de hacer demostraciones, demos, de tu trabajo ayuda a achicar esta brecha de entendimiento.
Un demo tiene el potencial de comprarte o ahorrarte problemas. Si del demo salen con más preguntas que respuestas, te compraste problemas. Si salen inspirados, con más ideas, te ahorraste problemas.
Es por eso que es importante que tomes los demos con seriedad. Porque a final de cuentas, desde un estricto punto de vista de negocio: si algo no funciona no sirve, y si algo no sirve, ¿para qué lo quiero? Un buen demo es tu oportunidad de evitar que alguien con poder de decisión a nivel negocio se haga esta pregunta.
Una de las banderas rojas más grandes es si tu jefe te contesta “a esta empresa se viene a trabajar, no a ponerse sentimental” cuando le comentas que una situación de tu trabajo te está afectando a nivel personal.
Para mí, esa es una señal inequívoca de estar en el lugar incorrecto para crecer profesional y personalmente.
Como líder de un equipo, tengo claro que mi objetivo principal no es exprimir el talento de las personas con las que tengo el privilegio de colaborar. Mi trabajo es propiciar las condiciones necesarias a nivel organizacional para que ese talento florezca por sí solo, y luego potenciarlo. Desafortunadamente, muchos “líderes” de equipo realmente funcionan como jefes, exigiendo sin aportar, promulgando sin poner el ejemplo. Y la frase “a esta empresa se viene a trabajar, no a ponerse sentimental” es el reflejo de esa mentalidad, donde lo que importa es el resultado y no la persona. Un medio para un fin.
Tú y yo somos parte de un sistema que, hora tras hora, está buscando exprimir la mayor cantidad de productividad de cada uno de nosotros. Eficiencia, dicen, es lo principal. Ser eficientes. Ser productivos. Si no estás siendo productivo, estás desperdiciando recursos. Si no maximizas tus horas de trabajo, estás siendo irresponsable.
Gran parte del reto es el contexto cultural en el que nos desarrollamos — especialmente en Latinoamérica, donde muchos hemos crecido con la idea de que lo que importa es el trabajo duro, y que reprobar (o que te corran) es lo peor que te podría pasar. Peor incluso que vivir angustiado, amargado o con ansiedad. Y cada día que paso trabajando con personas y buscando la manera de honrar su individualidad, metas y objetivos personales, me doy cuenta de la mucha falta que hace que los líderes en esta industria sean más humanos.
Si logras identificar las banderas rojas en tu empleo, y estás inseguro sobre si deberías buscar otro camino, déjame decirte que tienes muchas cosas a tu favor. El mercado está más caliente que nunca, y hay muchas empresas y organizaciones que están decidiendo apostar por la persona, más que por el output que generan. Solo tienes que levantar la cabeza y buscarlas.
Primero, hazte consciente de tu valía como persona, analiza tu propuesta de valor y, como dice Vicente Plata, no aceptes abusos.
