Archivo de la etiqueta: colaboración

Cómo crecer tu carrera en software de manera responsable

En el mundo del desarrollo de software, muchas veces nos centramos en la tecnología y en aprender nuevos lenguajes de programación o herramientas.

Sin embargo, hay un aspecto que suele pasar desapercibido: la agencia que cada desarrollador tiene sobre su carrera profesional. En este artículo, exploraremos la importancia de tomar las riendas de nuestro propio crecimiento y éxito.

Elegir dónde y con quién trabajar: un aspecto clave

Es común que los desarrolladores pongan mucho énfasis en la tecnología con la que trabajarán, pero elegir dónde y con quién trabajar es igual o más importante. Un ambiente laboral tóxico o poco estimulante puede frenar nuestro desarrollo profesional, además de afectar nuestra calidad de vida y salud mental. Por ello, es crucial investigar y seleccionar cuidadosamente las empresas y equipos con los que colaboraremos, asegurándonos de que compartan nuestros valores y objetivos.

Sí, está bien que una de tus metas sea trabajar con la tecnología de moda — llámese Elixir, Clojure, o TypeScript. Pero toma en cuenta que toda la tecnología es una ola, nada más. Se va a ir, y mañana habrá algo nuevo que será la sensación.

¿Sabes qué es lo que no se va tan fácil? El daño de sufrir burnout por haber trabajado en una empresa sin visión clara, con comunicación horrible, y con liderazgo tóxico.

No te quemes de a gratis.

El éxito es encontrar un camino hacia delante

Todos enfrentamos obstáculos y desafíos en nuestra carrera profesional. El éxito no se trata de tener un camino perfecto y libre de problemas, sino de nuestra habilidad para encontrar soluciones y avanzar entre las opciones que realmente tenemos a nuestro alcance.

Ser resilientes y adaptarnos a las circunstancias nos permitirá seguir creciendo a pesar de las dificultades.

Las habilidades blandas: el secreto para crecer profesionalmente

Es fácil caer en la trampa de pensar que, como desarrolladores, solo necesitamos mejorar nuestras habilidades técnicas. Pero las habilidades blandas, como la comunicación, el trabajo en equipo y la empatía, son extremadamente importantes para nuestro crecimiento profesional. Estas competencias nos permiten colaborar eficazmente con nuestros colegas, resolver conflictos y generar soluciones creativas a los problemas que enfrentamos.

Aparte, toma en cuenta que cada día que pasa, si lo único que sabes es programar, tu carrera está en más riesgo.

Impacto vs. conocimiento: crecimiento exponencial

Medir nuestro progreso solamente en función de cuánto sabemos puede hacernos crecer de manera lineal, es decir, mejorar poco a poco en nuestras habilidades técnicas sin realmente avanzar en nuestra capacidad para resolver problemas reales y generar valor. Sin embargo, si nos enfocamos en buscar tener un mayor impacto en nuestro trabajo y en la comunidad, nuestro crecimiento será exponencial. Colaborar en proyectos de código abierto, compartir nuestro conocimiento con otros y contribuir al desarrollo de nuevas soluciones nos ayudará a aumentar nuestra influencia y a expandir nuestras oportunidades profesionales.

La responsabilidad es tuya

La responsabilidad de crecer en la carrera de desarrollo de software va más allá de aprender nuevas tecnologías y herramientas. Debemos elegir cuidadosamente dónde y con quién trabajamos, ser resilientes ante los desafíos, desarrollar nuestras habilidades blandas y buscar tener un mayor impacto en nuestro entorno. Al tomar las riendas de nuestra carrera profesional, no solo mejoraremos como desarrolladores, sino que también contribuiremos al crecimiento de nuestra comunidad y de la industria en su conjunto.

Demuestra por qué no se debería de implementar la propuesta

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.

Software Libre: ¿Vale la pena involucrarse?

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.

Gavin Howard, escribiendo en su blog:

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 trabajo asíncrono le gana por mucho al trabajo duro

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.

SQLite no usa Git: ¿por qué?

Interesante página en el sitio de SQLite, explicando por qué no usan Git para administrar el código del proyecto:

SQLite no usa el sistema de control de versiones Git. En su lugar, usa Fossil, que es un sistema de control de versiones específicamente diseñado y escrito para soportar SQLite.

Personalmente no sabía de la existencia de Fossil, pero su propuesta de valor se ve bastante atractiva. Especialmente si tomamos en cuenta las razones que motivaron a que los administradores del código de SQLite decidieran que Git no era una opción para ellos:

  1. Git no ofrece visibilidad granular del contexto en el cual se hizo alguna contribución
  2. Hace demasiado difícil encontrar los sucesores de algún commit en particular
  3. El modelo mental de Git es innecesariamente complejo
  4. Git no lleva el recuento histórico de los nombres de las ramas
  5. Requiere soporte administrativo
  6. Es una experiencia de usuario pobre

Observa cómo ninguna de las razones que SQLite expone para no usar Git tienen que ver con la validez de la tecnología, sino con el impacto que esta tiene en las personas que tendrán que interactuar con ella.

Tip: Recuerda que tu software existe para resolverle un problema a tu usuario. Independientemente de la excelencia técnica de tu solución, si esta no le ayuda a tu usuario a resolver su problema, no estás cumpliendo tu cometido.

Software Habitable

En la industria del software estamos constantemente hablando de cómo hacer mejor software. Pero rara vez nos detenemos a preguntarnos qué, realmente, es lo que significa que una aplicación sea mejor.

El autor de esta publicación ofrece una forma interesante para pensar acerca de esto: los programadores deberíamos de crear software habitable.

La habitabilidad es la característica de un código fuente que le permite a programadores, codificadores, arregladores de errores y personas externas, integrarse a trabajar en él entendiendo su construcción e intención, para poder cambiarlo cómodamente y con confianza.

Al crear software habitable, las personas que trabajan en él tendrán más oportunidades de crear valor para sus usuarios.

Algunas cosas que contribuyen a hacer que un software sea inhabitable, por ejemplo: abuso de abstracciones innecesarias, sobreingeniería y atajos innecesarios.

Enlace: http://akkartik.name/post/habitability

Cómo vencer el síndrome del impostor

Todos sufrimos del síndrome del impostor.

Tan solo basta con hacer una búsqueda en Twitter para darte cuenta de que no estás sola. A unos nos vuelve paranoicos. A otros nos paraliza completamente, mientras que a varios simplemente nos atormenta en cada decisión que tomamos en nuestra vida profesional.

Cuando hablamos del síndrome del impostor también estamos hablando, hasta cierto punto, de vergüenza. Seguramente a ti también en tu niñez te dijeron que estar mal es algo que deberías de evitar a toda costa. Probablemente en varias ocasiones te dijeron, como a mí, que si no tenías algo bueno que aportar, mejor no aportaras nada.

Vivir el día a día con síndrome del impostor es agobiador. Sobre todo si trabajas en equipo. Y aún más, si trabajas en un ambiente ultra competitivo como lo es el desarrollo de software. El miedo de exponer una idea y quedar mal, como el que no sabe. El síndrome del impostor hace que nada de lo que tienes que aportar pueda salir a la luz. Pero todo esto se puede prevenir.

Considera lo siguiente: así como no mandarías código a producción sin probarlo o validarlo, tampoco deberías de convertir ideas en código sin antes pulirlas con tu equipo.

La próxima vez que sientas miedo de quedar “mal parada” por compartir tu idea de solución con el resto del equipo, recuerda: eso también es hacer software. Estás probando la viabilidad de la idea. Si escribir tests te ayuda a confiar más en tu implementación, exponer tus ideas con tu equipo y recibir feedback de ellas te ayuda a confiar más en que vas por el camino correcto.

Vencer el síndrome del impostor es tarea de todos

Si bien cada quien lo experimenta de manera diferente, todos en algún momento de nuestra vida nos hemos identificado (o nos vamos a identificar) con este síndrome. Creo que es una de las pocas cosas en las que todos podemos estar de acuerdo: el síndrome del impostor es algo que tenemos que tratar.

Y considero que es responsabilidad de todos los que estamos en esta industria buscar maneras de erradicarlo.

Recientemente, me compartieron una técnica que ha hecho maravillas para mí y mis equipos. Nos ha ayudado a bajar la barrera de entrada a discusiones, y al mismo tiempo, ha ayudado a que las soluciones a las que llegamos como equipo sean más diversas y ricas en perspectivas. La técnica se llama Wrong Answers Only, o “respuestas incorrectas únicamente”, pero me gusta más el nombre en Inglés.

Wrong Answers Only se trata de poner como regla, en cualquier discusión de equipo, que únicamente se vale compartir respuestas incorrectas.

La barrera de entrada ahora es mucho más baja, porque ahora lo que no quieres es estar en lo correcto. Dale rienda suelta a tu imaginación, y di lo primero que se te venga a la mente. Conforme va avanzando la reunión, la abundancia de ideas que no están atadas a la expectativa de tener que estar bien comienza a ofrecer un panorama mucho más amplio y diverso de soluciones posibles.

Poco a poco, utilizando esta técnica, los miembros del equipo ganamos confianza en nosotros mismos y aprendemos que estar mal es parte del proceso de aprendizaje. Y mientras más nos demos cuenta de lo anterior, más se rompe la asociación de que estar en lo incorrecto es un juicio directo sobre nuestra valía y capacidades como profesionales.

Liderazgo efectivo: La importancia de las reuniones 1on1 en equipos de desarrollo

Profesionalmente, crecí en un ambiente que desde muy al inicio me enseñó la importancia de ver primero a la persona y luego su utilidad. Y aún recuerdo el primer 1on1 (one-on-one, o una plática uno a uno) que tuve con mi líder.

Hoy sé lo afortunado que fui.

Aún no tenía tanta experiencia en la industria. Y, como muchos, pensaba que el rol del líder era regañarme, presionarme o criticar mi trabajo (luego entendí que lo que yo pensaba era un líder, en realidad era un jefe). La sorpresa que me llevé cuando en mi primer 1on1 con él, durante una hora, en vez de reclamarme por lo que es lo que estaba haciendo “mal” (a mi parecer), me preguntó que cómo me podía ayudar para que lo que estaba haciendo bien fuera más sencillo.

En ese momento fue cuando entendí el trabajo de un líder: crear conexiones con las personas con las que trabaja, entender qué los motiva y buscar la manera en que sus labores diarias sucedan en la periferia de sus intereses personales.

En una industria que está tan acostumbrada a enfocarse en el aspecto utilitario de las cosas, una conexión humana puede sentirse como un vaso de agua fría en el desierto.

A lo largo de mi carrera en software he conocido personas que, a pesar de llevar años trabajando con su equipo, nunca han intercambiado una palabra más allá de un reporte de progreso. Líderes que no saben que su equipo está quemándose porque no están haciendo aquello que los motivó a aplicar a su empresa en primer lugar. Contribuidores individuales que únicamente tienen visibilidad de lo que tienen que hacer de aquí al viernes.

No es sorpresa que tantas personas estén descontentas con lo que hacen 8 horas al día.

Líder: ¿cuándo fue la última vez que saliste de una llamada con tus reportes y saliste con un mejor entendimiento de qué puedes hacer para ayudarles a tener más éxito?

Ten 1on1s regulares. Hablen de qué los motiva. Hablen de qué les causa estrés. Haz un esfuerzo por ir más allá del dashboard de Jira, y si algo no está funcionando, entiende por qué. Luego busca la manera de arreglarlo. Sé ese líder que van a recordar porque no solo pedía resultados, sino que ayudaba al equipo a conseguirlos.

El 1on1 es una oportunidad para ambas partes. No la desaproveches.

Ser líder es como jugar una partida de póker

No sabes qué cartas te van a tocar. Pero cuando te las dan, debes de tomarte el tiempo para analizar cada una y ver cómo encaja con las otras que tienes en tu mano.

Una sola carta, aislada, no gana una partida. No importa si en tu mano tienes un 10, A, Q, J y K, si no sabes que juntos hacen una Escalera Real. Solamente tenías que cambiar el orden en que la veías.

Sucede lo mismo con las personas.

Liderar un equipo no se trata simplemente de cumplir metas o de alcanzar resultados estrictos. Se trata de reconocer las habilidades (y debilidades) de cada uno de los miembros del equipo.

Como líder, así como cuando juegas una partida de póker, tu única tarea es optimizar para sacarle el mayor provecho a las piezas con las que cuentas. Y la manera más sencilla de perder es no saber reconocer lo que tienes.