Archivo de la etiqueta: habilidades blandas

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.

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.

El nombre que le pones a las cosas sí importa

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

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

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

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

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

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

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

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

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

Razones comunes para que los desarrolladores busquen nuevos empleos

StackOverflow compartió en su blog los resultados de una encuesta que aplicaron a 500 desarrolladores de software. La idea era encontrar los factores que  actualmente están jugando un papel importante en el mercado laboral de desarrolladores.

Las respuestas podrían parecer obvias para cualquier persona que trabaje en el medio. Sin embargo, creo que es buena idea analizarlas un poco más allá simplemente compartir el número de personas que prefieren tal cosa en lugar de otra.

Los resultados

Why are you looking for, or open to, a new job? 65% Better salary/pa, 39% wanting to work with new technologies, 36% Better work /life balance, 35% Growth or leadership opportunities

Para buscar nuevas oportunidades, 65 % lo hacen por un incremento de salario. Esto no debería de sorprenderle a nadie. En los últimos meses, sobre todo, se ha visto un incremento sustancial en la inflación de los salarios para personas que trabajamos en software. Hay varios factores que podrían estar influyendo en esto: la pandemia, la devaluación de la moneda, que cada vez hay empresas con más recursos para “quemar”.

Al momento de considerar empresas para unirse, el 56 % quieren que la empresa le ponga atención al developer experienceEste dato sí me sorprendió, pero tiene sentido. Conforme los retos se van haciendo más complejos y los equipos se van haciendo más distribuidos, lo que quieren los desarrolladores es que las empresas realmente inviertan en la infraestructura para soportar sus esfuerzos.

Hace unos años, la discusión sobre el developer experience era relativamente sencilla, porque había un alto grado de probabilidades de que los problemas se mitigaran simplemente eligiendo el cliente de git adecuado para el equipo. Hoy en día, los desarrolladores esperan que haya una infraestructura para colaborar, empujar código a producción, resolver conflictos, recabar datos, y más. Y no solo eso, sino que esperan que haya un equipo encargado de soportar dicha infraestructura.

Aquellas empresas que reparen en invertir en mejorar y facilitar el trabajo de los desarrolladores la van a tener muy difícil contratando reteniendo talento.

Lo que hace que una empresa sea poco atractiva tiene que ver con el nivel de micromanagement de la organización. Me sorprendió conocer que hay algunas organizaciones prohíben a sus desarrolladores usar Stack Overflow. Fuera de eso, la mayoría de los desarrolladores están de acuerdo en que lo que quieren es que la cultura de la empresa no esté basada en el control y la desconfianza.

También me sorprendió la tercera razón más popular que hace que una empresa no sea atractiva para un desarrollador: que no tengan los recursos para darle confianza en su trabajo. ¿A qué se refiere esto? Algunas ideas:

  • Que no haya un proceso de retroalimentación establecido
  • Opacidad en el proceso de toma de decisiones
  • Una estructura organizacional demasiado plana
  • Y, retomando el punto anterior, indiferencia por el developer experience

La reputación de la empresa es primordial para el descubrimiento inicial de oportunidades. De acuerdo con los resultados de la encuesta, 47 % de los desarrolladores toman más en serio las recomendaciones de oportunidades que vienen de su red personal (familiares y amigos) que cualquier otro medio. Hace poco escribí sobre este fenómeno:

Es mucho más importante, para tu desarrollo profesional y tu superación personal, estar con las personas correctas, que en la compañía con el nombre más conocido.

Bien dicen que la publicidad de boca en boca es la más efectiva.

Conclusiones

El mercado laboral está más “caliente” que nunca. Y veo que muchas de las conversaciones al rededor del tema se enfocan en cómo se puede hacer para contratar más personas, pero lo que leo entre líneas de estas respuestas es que deberíamos estar hablando mucho, mucho más de cómo retener el talento que ya tenemos en nuestras compañías.

Si pudiera hacer sugerencias accionables para 1) retener al talento que tienes y 2) hacer tu compañía más atractiva para otros desarrolladores, te diría, en orden de importancia:

  • Invierte en facilitar el trabajo de tu equipo. Desarrolla infraestructura que ayude a que tus desarrolladores se puedan enfocar más en el qué, y no el cómo de hacer su trabajo. Pule los procesos de desarrollo, despliegue y revisión de código. Establece procesos claros par resolver conflictos.
  • Mejora tu cultura de colaboración. Promueve el dar y recibir feedback de manera orgánica y constante. Asegúrate de que los desarrolladores tienen la visibilidad necesaria para tomar decisiones y hacerse responsables de sus acciones. Empodera a tu equipo.
  • Hazlos sentir orgullosos de trabajar en tu compañía. 
  • Súbeles el sueldo. Índice de inflación anual, multiplicado por 2. Al menos.

5 Soft Skills para dominar si desarrollas software

Los Soft Skills son imprescindibles para cualquier desarrollador de software. Puede que seas capaz de codificar mientras duermes, pero si no tienes la capacidad de comunicarte te encontrarás en una situación incómoda. Y a menos que pretendas trabajar por tu cuenta para siempre, no es lo ideal.

Un estudio en el estado de Sonora demuestra que los mismos desarrolladores de software dicen que los Soft Skills son igual o más importantes que conocer ciertas tecnologías.

Este artículo te enseñará los Soft Skills principales que pueden ayudarte a hacer o deshacer tu carrera como desarrollador de software.

Comunicación

La buena comunicación es una habilidad esencial para cualquier trabajo profesional. Pero es especialmente importante para los desarrolladores de software que son serios con su trabajo. Desarrollar software, a final de cuentas, se trata de resolver problemas — para y con otras personas.

No importa si trabajas por tu cuenta como freelancer o en un equipo de desarrollo, vas a tener que comunicar ideas complejas a otras personas. Lo único que cambia es el medio. El diseño de una API comunica cómo debería ser utilizado tu servicio. Cómo redactas reporte de un bug comunica muchas veces no solamente lo que se debe de resolver, sino cómo debería de resolverse.

Los desarrolladores de software, como personas lógicas que somos, tendemos a pensar en términos de unos y ceros. Pero tener esta misma mentalidad al momento de comunicarnos con otras personas, especialmente personas que no tienen nuestra misma formación, no hace otra cosa más que perjudicar nuestra carrera.

Aprende a comunicar, y verás cómo tu código e ideas se vuelven 100% más efectivos.

Negociación

Los desarrolladores de software también tendrán que negociar con personas. Es raro el escenario en el que no tendrás la necesidad de discutir con otra persona para resolver un problema.

Si trabajas eres freelancer, por ejemplo, tendrás que negociar fechas de entrega, alcance del proyecto y hasta tu compensación. Si eres parte de un equipo, tendrás que encontrar la manera de llegar a acuerdos con respecto a metodologías de trabajo, herramientas y hasta qué convenciones seguir.

¿Usarás tabs o spaces?

¿Por qué deberíamos de usar Ruby y no Elixir?

¿Deberíamos desarrollar este feature antes de refactorizar el sistema?

No hay manera de que te escapes de tener que negociar cuando desarrollas software. Incluso, si lo piensas, diseñar una API se trata meramente de negociar qué es lo que el usuario te debe de dar vs. lo que tú le vas a regresar.

Ser excelente negociando hará tu vida desarrollando software mucho más productiva. No

Habilidades interpersonales

Empatía, tacto, persuasión, liderazgo, entre otras. Las habilidades interpersonales son importantes cuando hay que interactuar con otros miembros del equipo para que no se sientan molestos o disgustados por tu presencia. No es divertido tener un compañero grosero, combativo, que se queja de todo y no sabe cómo adaptarse al grupo.

Pero, yo diría, son mucho más importantes porque desarrollar software, al final del día, se trata de resolverle problemas a las personas.

Muy rara vez se desarrolla un software para que funcione en un vacío. Es casi seguro que si estás desarrollando una aplicación o sistema, o implementando un algoritmo, es porque alguien, en algún lado, necesita resolver un problema. Es aquí donde las habilidades interpersonales marcan la diferencia entre un software mediocre (dogmático, apegado a las ideas del programador) y un software realmente útil (usable, que resuelve los problemas del usuario).

Cuando desarrollamos software tenemos que tener siempre en mente a nuestro usuario. Por más novedosa que sea nuestra arquitectura, o más eficiente sea nuestro algoritmo — nada de eso importa si no estamos resolviendo el problema de la persona que usará nuestro desarrollo.

Sucede exactamente lo mismo en el contexto del equipo de desarrollo: ¿de qué sirve que seas el que más sabe de algún tema si nadie quiere trabajar contigo?

Eres una persona, y te mueves en un mundo de personas. No dejes que tus habilidades interpersonales se echen a perder.

Trabajo en equipo

Complementando a las habilidades interpersonales, viene el trabajo en equipo. Que es similar, pero no lo mismo. El trabajo en equipo es uno de los Soft Skills más citados en currículums, pero no muchos saben realmente qué significa.

Más allá de poder comunicar ideas complejas a tus compañeros, y de poder “llevar la fiesta en paz”, la habilidad de trabajar en equipo se podría resumir en la siguiente frase: tú no eres lo más importante del equipo.

Debes de ser capaz de observarte dentro del contexto del equipo, y ver cómo puedes apoyar, no cómo puedes obtener más control. Un desarrollador que sabe trabajar en equipo gestiona soluciones, delega responsabilidades y apoya en lo que puede. Pero nunca bloquea esfuerzos, acapara responsabilidades o tiene actitud de “quítate, yo lo hago”.

Seguramente has escuchado el término 10x Programmer — hace referencia a un programador que hace el trabajo de 10 personas, presumiblemente porque es tan bueno. Pero piénsalo de esta manera: un 10x Programmer no solamente hará el trabajo de 10 personas, sino que hará que 10 personas no quieran trabajar con él o ella. Y, a largo plazo, esa es una posición en la que no quieres estar. Muy bueno tirando código, pero insoportable al momento de colaborar.

No seas ese rockstar.

¿Quieres ser un 10x Programmer? Trabaja en equipo y haz que 10 personas crezcan para cumplir sus metas y objetivos.

Paciencia

Seguido me preguntan qué es lo que se necesita para poder desarrollar software profesionalmente. Muchas personas no se esperan que la respuesta que usualmente comparto es: paciencia. Un Soft Skill que usualmente pasa desapercibido porque es personal.

Desarrollar software es como armar un rompecabezas en tu cabeza. Solamente que no sabes cómo se debería de ver el diseño final, ni qué tamaño debería tener, ni si está en la orientación correcta. Si te frustras fácilmente, no sabes cómo lidiar con incertidumbre, y buscas la gratificación inmediata de todas tus experiencias, probablemente serás miserable desarrollando software.

No solamente deberás ser paciente con tus propios problemas — cuando estés intentando encontrar un error en un programa o aprendiendo una nueva tecnología. También deberás de ser paciente con personas que no hablan el mismo idioma que tú, o que no tienen la misma experiencia empírica. Tendrás que explicar conceptos complejos a personas que no saben de lo que estás hablando, y te harán preguntas sin sentido. Deberás lidiar con cientos de intentos fallidos para configurar alguna parte de tu stack.

Desarrollar software es un ejercicio de paciencia constante.

Si no eres paciente contigo mismo, y con las personas que te rodean en tu industria, probablemente la pasarás mal.

Y si estás leyendo esto porque apenas estás considerando iniciar tu carrera desarrollando software, te ofrezco una disculpa. Sé que puede sonar nada divertido, y hasta como una advertencia de que no lo hagas. Pero, por experiencia propia te digo: hasta las veces que perdí la paciencia y lloré porque no podía configurar una simple tabla en mi aplicación de iOS valieron la pena. Porque durante los siguientes 10 años pude aprender de los mejores, viajar por el mundo, hablar en conferencias y mi código hoy corre en cientos de millones de dispositivos. Porque fui paciente.

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.

Cómo destacar tu currículum en el mundo del desarrollo de software

Lo he dicho en algunas ocasiones, en mi pódcast y en mis seminarios web: si juegas bien tus cartas, tu currículum solamente lo necesitarás la primera vez que busques empleo. Al inicio de tu carrera.

Aun así, probablemente te verás en la necesidad de mandar un CV, currículum, carta de vida, o como le digas, a una empresa para solicitar empleo. Y por eso te quiero regalar un consejo como alguien que constantemente revisa currículums de candidatos: cuéntame una historia.

Al contarme una historia, tu currículum te hará ver muchísimo más atractivo, y podremos entablar una conversación. Si todo sale bien, te ofreceré un empleo.

Te explico.

No digas lo obvio

Imagina conmigo la siguiente situación: entro a una tienda de deportes porque quiero comprar una bicicleta. ¿Crees que alguien me va a convencer de comprar una bicicleta diciéndome que tiene dos ruedas?

Por supuesto que no.

Sucede exactamente igual con un currículum. Cuando aplicas a una posición que requiere habilidades especiales, y dentro de tu CV solamente listas que sabes esas habilidades, no estás diciendo nada. No me estás llamando la atención. No te estás diferenciando.

¿Qué te hace diferente?

Ahora imagina que el vendedor se toma el tiempo de preguntarme para qué quiero una bicicleta, si ya tengo experiencia, y demás. ¿Qué pasaría si aprovecha esa información? Me ofrecería una bicicleta que me ayudará a cumplir mi meta de hacer ciclismo de montaña. Me contaría cómo el marco de fibra de carbono es más ligero pero más resistente, y por qué eso es bueno para mí. Haría una demostración de por qué el tamaño de la rueda de esta bicicleta en particular me ayudará a cansarme menos.

El vendedor entendió mis necesidades, y creó una historia al rededor de ellas para vender el producto. Jugó bien sus cartas, y el resultado es que yo salí de la tienda con mi bicicleta nueva.

Te invito a cuestionarte si realmente listar que sabes usar Photoshop e Illustrator le agregan valor a tu propuesta como diseñador gráfico. O si decir que sabes hacer balances de cuentas te diferencia como contador.

 

Cómo contar una historia en tu currículum

En mi artículo ¿A los 36 ya soy muy viejo para buscar trabajo en TI?, compartí lo siguiente:

Te aconsejaría tomar nota de cuáles sí son tus habilidades que te distinguen, y aprender a venderlas mejor a empresas que sí busquen lo que tienes que ofrecer.

Regla #1 del marketing: conoce a tu cliente. ?

Es una pena que las escuelas actualmente hagan ver la creación de un currículum como algo burocrático, cuando en realidad es 100 % marketing. Recuerda, el marketing se trata simplemente de vender.

Y la regla #1 del marketing es conocer a tu cliente.

Volvamos al escenario del vendedor de bicicletas. Yo quería comprar una bicicleta para hacer ciclismo de montaña. ¿Crees que habría comprado una bicicleta en esa tienda si me hubieran ofrecido una bicicleta de pista? Obviamente no. Pero el vendedor hizo algo crucial: investigó cuáles eran mis necesidades.

¿Sabes qué es lo que quiere la empresa para la que estás aplicando? Porque por ahí deberías comenzar. Y una vez que sabes por qué están buscando nuevos integrantes para su equipo, puedes comenzar a crear una propuesta de valor adecuada.

En este punto debería de comenzar a hacerte sentido lo que te digo. No simplemente listes tus habilidades. Evita decir cosas obvias. Enfócate en vender tu historia, y responder las siguientes preguntas:

  • ¿En dónde culminan tus habilidades?
  • ¿Cómo las has usado antes?
  • ¿Qué resultados favorables hubo?

Habiendo dicho esto, a continuación te muestro cómo puedes traducir una lista de habilidades en un párrafo que hará que tu currículum sobresalga.

 

  • Proceso creativo: esto es lo que te hace diferente. Tienes un proceso creativo, y gracias a él es que eres tan prolífico con tus contribuciones.
  • Tanto gráfico, como web y de correo: les estás diciendo que tus habilidades de diseño son multidisciplinarias. Implicas que conoces varias herramientas y sabes cómo utilizarlas para su propósito específico.
  • Incrementar sus ventas en un 35 %: esto es lo que ata con moño tu historia. Es por esto que todas tus habilidades son relevantes para la empresa. En este caso, les estás diciendo por qué te deberían contratar. Contigo en el equipo aumentan sus probabilidades de vender más.

El conjunto de esos tres factores, aderezados con datos particulares de tu perfil, es la historia que te va a hacer sobresalir.

Esto es casi una plantilla. Úsala a tu conveniencia.

Notas finales

Recuerda que un buen currículum no hará que te contraten. La idea de un currículum es entablar una conversación. Vender la idea de por qué vale la pena enviarte un correo pidiéndote una llamada. Hacerte parecer lo suficientemente interesante para que cuando te hablen, te pregunten por tu proceso creativo, no por comandos de Photoshop.

Pero sobre todo, ten en cuenta que el mejor currículum no es el que se envía, es el que se demuestra. Como dije al inicio, si juegas bien tus cartas, tus contribuciones, aportaciones, experiencia, y colegas hablarán por ti.

Que tu trabajo sea excelente.