Es vital cuidar la salud mental en un sector en el que reinan las prisas, el síndrome del impostor y la necesidad imperiosa de aprender el-último-framework-que-los-dominará-a-todos. Sin embargo, ni en la Universidad, ni en los Ciclos Formativos de Grado Superior, ni en los bootcamps se presentan tips para que tengamos (al menos) nociones básicas para evitar o prevenir un deterioro de nuestro bienestar personal. Es por esto que en esta ocasión, no vamos a escribir sobre microservicios, arquitecturas hexagonales, principios SOLID, AWS… Sino de algo igual de importante que los conocimientos técnicos (o incluso más): las soft-skills.
Tú no eres tu código
Las críticas a tu código no son críticas hacia tu persona. Esa pull request que has hecho con toda la ilusión del mundo y en la que te has pegado horas y horas no se parece, en absoluto, a ti. No se parece a ti ni cuando te la rechazan ni cuando te la aceptan. No tienes que trasladar esas críticas al ámbito personal.
Si hoy no es el día… Déjalo
Pienso firmemente que en nuestro sector muchas de las tareas que hacemos diariamente requieren de «inspiración». Esta inspiración, casi artística, es necesaria para que seamos capaces de enfrentarnos a los problemas en tiempo y forma… Y hay veces que no estamos inspirados/as, hay que reconocerlo. ¿Cuántas veces nos enfrascamos con una nueva funcionalidad que no conseguimos sacar adelante y, mágicamente, al día siguiente la tenemos a la media hora? Dedicar más horas a un problema cuando estamos frustrados/as, cansados/as y desanimados/as es seguir echándole leña al fuego.
No existe la solución perfecta
Siempre escucharemos un «pero», un «depende» y un «yo no lo habría hecho así». Incluso estas palabras saldrán inconscientemente de nuestra cabeza cuando, dentro de 6 meses, veamos el código que hemos escrito hoy y que creemos que es perfecto. Y está bien. Hay que asumir que nadie es perfecto/a y que estamos en un continuo proceso de aprendizaje. El objetivo es que siempre propongamos soluciones adecuadas al conocimiento y tiempo que dispongamos para implementarlas.
Good bye, síndrome del impostor
«Wow, acabo de llegar a este proyecto y todos/as saben muchísimo más que yo».
«¿De verdad sirvo para este trabajo?»
«No entiendo cómo los/as demás entienden las cosas tan rápido».
«Siempre termino preguntando las mismas tonterías, deben pensar que soy idiota».
Es triste, pero creo que todos/as conocemos a alguien de este sector que ha dicho alguna de estas frases (o una de sus infinitas derivaciones). Incluso puede que nosotros/as las digamos y las sintamos en nuestras carnes.
Lo que quiero decir es que a un/a desarrollador/a de software se le exige mucho, y es normal que se abrume y se compare directamente con los/as demás. Se le exige que sepa sobre: el-último-framework-que-los-dominará-a-todos, las-metodologías-ágiles-más-ágiles-jamás-propuestas, el-lenguaje-de-programación-más-rápido-y-más-seguro, microservicios, arquitectura hexagonal, etcétera, etcétera, etcétera. Además, también se le recuerda aquella historia de usuario que debería haber entregado para ayer.
Y está bien reconocer que no conoces X estilo arquitectural, que nunca has trabajado con Y framework y que quizás la historia de usuario se subestimó en la sprint planning. Nada de eso te hará peor desarrollador o desarrolladora de software, ni nadie va a pensar lo malo/a que eres comparado/a con tus compañeros/as.
Pregunta absolutamente todo
Viene de la mano del anterior consejo, pues como nadie nace sabiendo, hay que preguntar. Rodéate de seniors y/o personas con mayor experiencia en el proyecto, con el lenguaje o con el estilo arquitectural que estéis empleando. Verás que en la mayoría de ocasiones es mejor preguntar que asumir cómo se hacen las cosas. Además, normalmente éstas «cosas» tienen su razón de ser, pues cada proyecto tiene sus necesidades específicas.
Registra las decisiones que tomes
Para ahorrarte futuros dolores de cabeza, deja en un registro público las decisiones que tomes, junto con la argumentación de por qué has tomado esa decisión.
«Se decide dividir el microservicio que gestiona el stock de productos en dos: uno que gestiona únicamente los productos que se compran por la web y otro que gestiona los productos que se compran en tienda. Esto es, porque, por semántica, consideramos que son dos dominios del problema diferentes. Además, permitirá hacer un escalado de recursos más adecuado en días como el Black Friday».
«Se decide posponer la hora de inicio de las dailies a las 9:30 para favorecer la conciliación laboral de aquellos/as padres/madres que tienen que llevar a sus hijos/as al colegio».
«A partir de ahora, el pipeline de Jenkins comprobará que nuestro código tenga un 85% de cobertura de test para asegurarnos de que hay test implementados que cubren una gran parte de la lógica implementada».
Hay días en los que hay que cambiar el café por las tilas
Si estás leyendo este artículo es porque probablemente te dediques a este sector. Y, como buen/a desarrollador/a, te gustará el café. Sin embargo, en un sector en el que hay momentos de tensión como las subidas a PRO los viernes, las historias de usuario que no van a llegar al fin de sprint o los hotfix temporales que tienen que hacerse rápidamente para levantar de nuevo el servicio, creo firmemente que hay días en los que hay que cambiar el café por las tilas. De nada sirve andar nervioso/a todo el día, y menos, cuando la situación requiere calma y tomar decisiones de manera inteligente. Recuerda que muchas veces creemos que nuestro hotfix es inofensivo y que va a solucionar el defecto… Pero de repente aparecen 7 nuevos que no habíamos contemplado. En el mejor de los casos, tenemos test…
Los inicios siempre son complicados
Nuevos/as compañeros/as, nuevas tecnologías, nuevas metodologías, nuevos estilos arquitecturales, nuevos problemas, nuevas propuestas de solución, nuevos diseños funcionales… ¿Y todavía piensas que vas a rendir exactamente igual que los/as que llevan meses o años en el proyecto?
StackOverflow es nuestro amigo
Y no pasa nada por reconocerlo, no nos hace peores desarrolladores/as, ni tampoco nos tiene que hacer sentir impostores/as. Todos/as lo hemos utilizado, y es realmente útil. Sobre todo, acuérdate de copiar la parte de la respuesta y no el de la pregunta.
Somos unos/as privilegiados/as
Casi el 100% de personas que han estudiado algo relacionado con el desarrollo de software y que quieren trabajar en este sector están trabajando. Además, cobrando un buen salario. Considero que somos unos/as privilegiados/as por trabajar en un sector en el que, día a día, tenemos la oportunidad de transformar el presente, digitalizándolo. Esta profesión tiene momentos maravillosos, como ese hotfix que funciona correctamente, esa subida a producción el viernes que no da ningún problema el fin de semana y esos descansos del café (o tila) en los que, seamos sinceros/as, hablamos de desarrollo de software, porque nos apasiona.
Hasta aquí, mi humilde opinión sobre cómo creo que podemos ser un poquito más felices trabajando en este sector. Evidentemente, podemos coincidir o no, así que me gustaría conocer tu opinión sobre el papel de las soft-skills intrapersonales e interpersonales en el sector, además de si añadirías algún consejo más a la lista. Gracias de antemano.
Desde Hiberus, le damos mucha importancia a la felicidad de nuestros/as trabajadores/as. Es por ello que en nuestro equipo contamos con profesionales de diferentes ámbitos, desde la psicología, organización de eventos, comunicación e incluso un Chief Happiness Officer, que hacen de la experiencia de trabajar en Hiberus algo memorable.
