El mundo necesita más desarrolladores

Basado en nuestra charla “El mundo necesita más devs”.

Se estima que en Estados Unidos este año se necesitarán 1,4 millones de desarrolladores de software, pero sólo se graduarán 400.000 personas de esta carrera.

Estudié Ingeniería de Software, la que ahora sé que es la profesión más demandada del mundo. Sin embargo, en la universidad no sabía si quería dedicarme 100% a la programación por cómo me imaginaba que era ser programadora.

Y es que los sesgos y estereotipos abundan en el mundo del desarrollo.

Los estereotipos

Si eres una persona más influenciada por las películas probablemente asocias “programadores” a hackers en piezas oscuras, rodeados de muchísimas pantallas con código verde inentendible.

“The Matrix” (1999)

O tal vez interns con actividades recreativas de alguna compañía FAANG.

“The Internship” (2013)‌‌

Si estás más sesgado por las series, tal vez se te vienen a la cabeza hombres nerds con pocas habilidades sociales rompiéndola con sus startups en Silicon Valley.

Serie “Silicon Valley” de HBO. Muy buena.

Por otro lado, las personas que tienen experiencias de empresas más tradicionales seguramente piensan en programadores recluidos a un área especial, con la que no tienen mucha comunicación.

Fact checking: ¿cómo es ser desarrollador(a)?

Llevo un año y medio trabajando como developer (dev) y, aunque hay cosas con las que uno sí se relaciona, desarrollar no es como lo pintan las películas. Incluso, ser desarrolladora en Fintual no es como me lo imaginaba en la universidad.

En el mundo existe una creciente demanda de desarrolladores que no estamos siendo capaces de suplir. Por eso, quiero desmitificar cinco puntos sobre lo que se piensa de la vida de un desarrollador de software (y que yo misma pensaba antes de dedicarme a esto).

Disclaimer: los siguientes puntos se basan completamente en lo que ha sido mi experiencia en Fintual y como practicante en Platanus. Aunque estos puntos sí aplican a algunas empresas, no necesariamente en todas es así.

Mito 1: “Los devs programan todo el día”

"Se puede escuchar su fuerte e ininterrumpido teclear de líneas de código a kilómetros."

Obviamente programamos harto, es nuestra pega principal. En el caso de Fintual, los devs somos full-stack, programamos web y mobile y además nos encargamos del testing y QA.

Pero desarrollar software no es escribir líneas de código el 100% del tiempo.

Una primera parte es entender el problema que tienes que atacar y el código involucrado. Después viene todo un proceso creativo de pensar las mejores maneras de solucionarlo. Es muy distinto escribir un código que funcione a escribir un buen código que funcione, a nivel de diseño.

En todo el proceso no estás solo/a. Es clave la comunicación con el resto del equipo de devs: resolver dudas, discutir problemas, iterar las mejores soluciones, etc. A veces conversaciones de pasillo pueden resolver bugs de horas.

Escribir código también te ayuda a pensar. Aunque después lo tengas que refactorizar completo.

Así que, no. Los devs no programan todo el día porque el desarrollo es mucho más que las líneas de código que escribimos.

En Fintual, además, puedes hacer otras cosas si quieres y te gusta. Esta libertad me parece clave para mantener la motivación del equipo de desarrollo si tienen otros intereses además de la programación.

En mi caso, he podido participar en temas de contenido con presentaciones, posts y videos. Además estoy en un team que nació porque quisimos empezar un protocolo para casos de violencia sexual. También soy mentora para las reuniones 1:1 que tenemos los devs en que conversamos de nuestra motivación y preocupaciones.

Estas cosas me encantan porque puedo hacer algo distinto que, al final, complementa mi trabajo como desarrolladora.

Mito 2: “Te asignan tareas, tú no tomas las decisiones”

A veces puede sentirse así cuando uno toma tarjetas de un backlog. Si no participaste de la creación y priorización de las tarjetas, es fácil perder el panorama general de lo que estás programando.

De hecho, este era uno de nuestros problemas con Scrum. Lo que hicimos en Fintual fue cambiar nuestra metodología de desarrollo a Shape Up para aumentar la autonomía del equipo de devs.

Ahora no tomamos tarjetas de Trello. En vez de eso, los devs recibimos un pitch, que es un documento con una idea a desarrollar en seis semanas. Es una solución en base a un problema o motivación, ni muy concreta ni muy abstracta.

Shape Up de Basecamp.

Por un lado, cualquier persona de la empresa puede tomar la decisión de lo que se debería desarrollar en Fintual. Por otro lado, los devs tomamos las decisiones sobre cómo abordar el problema que tenemos que desarrollar.

Además, Shape Up es una muy buena manera de priorizar lo que queremos hacer como empresa. Nos llegan muchos mensajes por el chat con recomendaciones al producto o comentarios: “por qué no tienen inversión para menores de edad, quiero abrirle cuenta a mis hijos”, “por qué no hay inversiones compartidas, como hacer una vaca” o “cuándo sale el dark mode”, etc. Con esta metodología, estas ideas sólo se van a hacer realidad cuando alguien del equipo les de forma (o las shapee), por lo que naturalmente vamos a desarrollar los proyectos más prioritarios y que consideremos que tengan mayor impacto.

Mito (o no-tan mito) 3: “El área TI”

“El departamento TI (Tecnologías de la Información) como un sector aparte de la empresa, con desarrolladores que nadie entiende y que necesitan de un representante para comunicarse con el resto del equipo. El último eslabón en la pirámide empresarial.”

Esto es muy común en empresas más tradicionales. Sin embargo, creo que esta concepción inevitablemente va a cambiar mientras más empresas se “tecnologicen”.

En nuestro caso, Fintual es una empresa de tecnología dedicada a las inversiones. Al ser una fintech nuestro core es la tecnología y por eso casi un tercio del equipo somos devs.

Video de Fintual: Salto tecnológico

Your browser does not support the video tag.

Como cualquier persona de la empresa puede proponer shapes para desarrollar, dependemos mucho de la comunicación que tenemos los developers con el resto del equipo. Hacemos nuestro mejor esfuerzo para explicar claramente los puntos técnicos de una feature, porque es la única manera para sacar adelante mejores proyectos. Esto no lo lograríamos si estuviéramos en un área aislada de la empresa, en que la comunicación necesariamente fuera a través de un intermediario (ej. Andrés, nuestro CTO).

Mito 4: “Vives apagando incendios”

“Desarrollar es un continuo de solucionar bugs urgentes y se necesita de una persona dedicada a esto al 100%.”

Nuestro objetivo es crear un ambiente seguro para desarrollar, pero es imposible reducir a cero los errores. Eso significa que alguna persona del equipo tiene que “ponerse la capa” cuando se detecta un bug urgente o se cae la aplicación.

Si esa persona es la misma todo el tiempo, es inevitable que su motivación se extinga y se desgaste por la presión que involucra un trabajo así.

Existen distintas maneras de evitar esto, que se basan en que esta persona encargada no sea fija. En Google los ingenieros de software tienen periodos on-call. En Fintual tenemos a nuestros superhéroes.

Nuestros superhéroes del equipo de soporte. Ven issues y tarjetas de mejora continua

Los devs rotamos entre ciclos de building de Shape Up y ciclos como equipo de soporte. Eso significa que sólo algunas semanas nos toca resolver urgencias: cuando tomamos el rol de Batman o Big Boss.

Batman está atento a problemas del producto y prioriza y resuelve issues que aparezcan de nuestra aplicación. Big Boss se encarga de las urgencias de operaciones y que todos los días salga bien el cierre contable de los fondos.

Es agotador tomar este tipo de roles, pero aprendes mucho de ellos también. Lo importante es lograr un equilibrio para que los desarrolladores no se desgasten excesivamente por estas tareas de urgencias.

Mito 5: “Los devs son robots 🤖”

El último estereotipo: “los desarrolladores somos robots sin sentimientos, guiados por la racionalidad.”

Tenemos nuestras dudas a veces.

La parte más “humana” y menos robótica/racional de los devs es esencial en un equipo de desarrollo.

Dependemos mucho unos de otros y el trabajo en equipo es indispensable para sacar adelante buenas features. Es imposible si cada desarrollador trabaja solo/a por su lado.

Dado esto, las instancias de feedback (que todavía estamos iterando) resultan clave para revisar qué cosas estamos haciendo bien y qué podríamos mejorar. Al final nuestro desempeño impacta a todo el equipo.

Como cuenta Andrés en su clase sobre manejo de equipos de desarrollo, esta visión de que los desarrolladores no son personas es ridícula. Por eso, uno de los cuatro puntos que remarca para hacer software bien es invertir en las personas, lo que significa considerar sus motivaciones y emociones (muy relacionado a lo que contaba sobre el primer mito).