Una de mis maneras favoritas de procrastinar es leer blogs de ingeniería. Hay ratos donde el código no está brotando por lo que decido dejar de pegarme cabezazos, pero tampoco quiero ser absorbido por las redes sociales. Así, después de 15-20 minutos, tengo algún conocimiento nuevo en vez de haber leído un artículo de Buzzfeed sobre las peores cirugías de Hollywood. Eso lo dejo para el fin de semana.

En esos afanes estaba cuando encontré este artículo de Isidora de Fintual. Si no lo ha leído, lo recomiendo plenamente. Porque tiene mucha razón: el trabajo de programador / desarrollador / dev está lleno de mitos o miedos que te pueden dejar fuera de un camino muy bacán. Yo no quise ser programador por un par de años porque me convencí de que algunos eran ciertos y terribles. Y, como todo en esta vida, la respuesta no era tan simple. Así que decidí, a modo de complemento a ese artículo, dejarles algunos que me dije a mí mismo durante mucho tiempo y que resultaron ser patrañas.

MIEDO #1:

Uno de mis mayores miedos era lo abstracto del trabajo del programador. Solo ve las “letritas de colores” y habla de deploys, estructuras de datos y optimizaciones de flujos. No hay nada tangible al final del día, pensaba yo.

Mucho color y pocas nueces

Por esto prefería el trabajo de analista de datos / negocios: creía que era más tangible y aterrizado. Uno estaba haciendo una presentación, una planilla, un vehículo hacia una decisión de negocio. Pero lo que carecen es de ese placer maker de exponer masivamente tu trabajo. No se me malinterprete: son roles bacanes, muy necesarios y donde se aprende mucho. Sin embargo, uno hace la presentación, la gerencia llega a una decisión, y se archivan los gráficos para acumular un figurativo polvo digital. 

¿Y eso cómo es más tangible o aterrizado que terminar un ciclo con un nuevo botón, gráfico, módulo de la aplicación? Por más abstracto que haya sido el approach, el feature está a la vista, igual que su impacto. Dólares ganados, minutos ahorrados a clientes u otros programadores, bugs prevenidos. Al final del día, un producto digital puede ser mucho más tangible (y satisfactorio) que otros tipos de trabajos.

MIEDO #2:

Uno está muy expuesto o vulnerable. En muchos trabajos solamente se evalúa el resultado final: si la presentación quedó bonita y el análisis da confianza, el cómo se llegó al resultado es secundario. En la programación, en cambio, lograr el objetivo del ciclo o shape es lo más fácil: lo difícil es hacerlo de una manera en que el código sea legible, robusto, fácil de mantener y de extender. Como dice un amigo acá en Chipax: “Cualquiera puede echar unas líneas de código. No cualquiera es ingeniero de software.” Esto significa que se revisa todo tu trabajo. Toda decisión, hasta el nombre de una variable, puede ser cuestionada. Si tomaste la ruta fácil, vas a quedar expuesto cuando tus compañeros revisen tu código.

Y esto es cierto. Uno es muy vulnerable en este sentido. Quizás por esto es tan común el síndrome del impostor: tu trabajo va a recibir correcciones todos los días y te vas a sentir juzgado. Lo que no es cierto es que esto sea algo malo: depende totalmente del equipo. De hecho, esto permite que el feedback o mentoría sea en la programación mucho más valioso que en otro tipo de trabajo. Si uno se siente apoyado y mentoreado, esta megaexposición te hace mejorar rapidísimo y la incertidumbre incluso termina siendo menor. Están todas las cartas sobre la mesa, y la responsabilidad es 100% compartida entre todo el equipo. 

MIEDO #3:

Uno está muy solo. Fake news. Old news. Ya no se programa solo. Como dice Isidora en el artículo, las metodologías modernas como Shape Up permiten que entre los programadores decidan cómo dividirse las tareas (y, potencialmente, hacer algunas entre varios: el pair programming es muy efectivo en algunos casos).

Además #1: tu código va a ser revisado por varios compañeros.

Además #2: vas a tener dudas y vas a conversar cómo atacar el problema con más gente.

Además #3: probablemente vas a trabajar con una persona de diseño y otra de product management que te guiarán.

Que no hayan reuniones inútiles no significa que se esté solo: significa que, cuando estamos juntos, realmente son momentos de trabajo fructífero.

MIEDO #4:

Vas a hacer lo mismo toda tu vida. Esto es mentiroso de muchas formas. Primero, aunque programaras todos los días, difícilmente harías lo mismo: dado que todo lo repetitivo se automatiza (it’s part of the trade), siempre se está haciendo algo que nunca se ha hecho. Segundo, los career paths de los programadores no son tan monótonos o cortos como se puede imaginar. Efectivamente se puede avanzar en seniority en lo técnico. Pero además se avanza en habilidades blandas como el manejo de expectativas, la estimación de plazos, la asignación de recursos, etc.: labores donde un ingeniero tiene las mejores herramientas para brillar. Con los ingenieros de software en puestos de management con los que me ha tocado hablar, de hecho, el problema es el opuesto: echan en falta dedicarle horas a escribir líneas de código. Si al final del día, el tema es muy entretenido.

En conclusión

No quiero cerrar esto con tintes de libro de autoayuda barato. Todos sabemos que los miedos nos limitan, pero también a veces son útiles. Al final del día, es nuestro instinto de supervivencia hablándonos. Creo que la moraleja es un poco más matizada: nuestros miedos parten como generalizaciones.

Es importantísimo de a poco desmontar estas concepciones y basar nuestras decisiones de vida en datos. Creo que estoy diciendo, simplemente, que no le creas todo a la televisión. Mejor háblale a algún desarrollador: somos más simpáticos y con más vitamina D de lo que te imaginas.