Archivo de la etiqueta: programadores

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 experience. Este 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 y 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.

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

Cosas que no te enseñaron en la escuela, pero debes saber para trabajar en la industria del software

A continuación te comparto cosas que no te enseñaron en la escuela, pero que debes de saber si quieres trabajar en la industria del software.

  1. Tú te pones tus propias metas. En la escuela tenías la comodidad de llevar un “plan de estudios”. Sabías lo que seguía en cada paso. Acá afuera nadie va a entregarte un plan de estudios para tu carrera profesional. Tienes que definirlo por ti misma.
  2. No tienes que pedir permisos. ¿Quieres aplicar para un trabajo? ¿Te urge cambiar de tecnología? ¿Te gustaría ganar en dólares y vivir en LATAM? ¿Tu sueño es trabajar para un unicornio? ¿Lo que quieres es pasar más tiempo con tu familia? Date. Nadie te detiene.
  3. Debes de tomar decisiones por tu cuenta. En la escuela te condicionaban a aprender una metodología preestablecida. Salirte del protocolo era castigado. En la vida real tienes que aprender a tomar decisiones y a hacerte responsables de sus consecuencias. Nada más.
  4. Puedes irte en cualquier momento. Tenía un profe que se quejaba de los alumnos diciendo “es que ustedes creen que las cosas van a ser como ustedes quieran”. ¿Y por qué no? Si estás en un trabajo o situación que no te favorece, ¿para qué te quedas? No te pongas la camiseta.
  5. Se espera que sepas colaborar, no que te sepas todos los lenguajes de programación del mundo. Saber más lenguajes de programación solo significa que sabes más lenguajes de programación. Aprende a resolver problemas colaborando — técnicos, de negocio, de usuario.
  6. Saber hacer la pregunta correcta es más importante que ser una enciclopedia de conocimiento. Expandiendo en el punto anterior un poco. “No es la respuesta de StackOverflow, es que sepas lo que tienes que Googlear para encontrarla.”
  7. Programar es un medio para resolver problemas, no un fin. Sí, yo sé que es bien divertido programar. Te aconsejaría que no te clavaras únicamente en eso. Puedes programar toda la vida y no resolver ningún tipo de problema. Y te van a pagar por resolver problemas.
  8. Una solución que es correcta el día de hoy, mañana puede ser considerada ineficiente. Yo creo que en software no hay soluciones “exactas”, sino soluciones “ideales para la situación actual, con el conocimiento que tenemos”.
  9. Existen lenguajes más aptos para resolver ciertos tipos de problemas. Hay desde “lenguaje especializado” que es complicado de aprender, pero te dará soluciones compactas, a “lenguaje genérico” que es fácil de aprender, pero será lejos del ideal para resolver todo.
  10. Mientras más “escalas” de posición, se trata menos del código y más de las personas. Las habilidades más valiosas de alguien considerado “Sr.” son las sociales y de liderazgo. Gente que programe “bien” hay un montón.
  11. Necesitas una red de apoyo. Sí o sí. Rodéate de gente que te quiera ver crecer y que comparta tus principios y valores.
  12. Aprende a valorar tu trabajo. Costo ≠ Valor.  No cobres por el esfuerzo físico que lleva hacer una tarea. Cobra por el valor del problema que estás resolviendo.

Originalmente compartí este hilo en Twitter, donde también puedes seguirme.

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.