Lo que no nos contaron a los devs (y me hubiera gustado saber antes de empezar mi carrera)
La semana pasada cumplí 500 minutos entregando mentorías gratuitas en la plataforma ADPList. He conversado con desarrolladores y diseñadores en todos los niveles de experiencia. Si quieres agendar 30 minutos conmigo, dale click a este link.
Hace exactamente 20 años empecé la carrera de ingeniería en informática en la ciudad de Valdivia, Chile. Informática (o ciencias de la computación) era catalogada como la carrera del futuro. La verdad, no me puedo quejar. Esa carrera me ha otorgado mucha satisfacción, pese a que en 5 años más seré reemplazado por un robot con inteligencia artificial.
Bromas aparte, mi carrera fue de mucha teoría y algunas veces poca práctica. La mayor parte de mis compañeros y yo, queríamos empezar a programar lo antes posible y saltarse esos largas charlas de matemática y física.
Informática no es la excepción y como pasa la mayoría de las carreras profesionales, el futuro parece prometedor y lleno de posibilidades, pero al momento de comenzar tu primer trabajo te llega la primera sacudida de realidad.
Cada proyecto de software es un universo único de personas, oportunidad de negocio y stack de herramientas. No somos pocos quienes nos hemos enfrentado a unos cuantos (inesperados) desafíos.
Este post trata de conocer ese “lado B” de las cosas que me hubiese gustado conocer, para así manejar expectativas más realistas.
0️⃣ La ilusión de comenzar de cero
Una de las preguntas frecuentes que tengo al momento de hablar con un recién salido de la universidad es el miedo a comenzar a aportar a un proyecto. El primer “pull request” o la potencial burla de como luce ese código primerizo.
Va a ser muy raro que comiences de cero en tu primer trabajo.
La mayoría de las veces trabajarás en proyectos que ya tienen cientos de líneas de código escritas por otros desarrolladores. Si usan Git y una plataforma como Github o Bitbucket, vas a poder tener acceso a “pull requests” cerradas con comentarios y cambios. Y si. Descifrar el código fuente y atar cabos entre esos “pull request” va a ser desafiante.
Pero volviendo al punto principal, no vas a partir de cero. De hecho, pasarás más tiempo solucionando errores de otros que escribiendo código desde cero.
🤖 Aprende lo antes posible a escribir código que humanos puedan entender
Yo sé que estamos en la era de Github Copilot y las herramientas de IA están apareciendo como frameworks de frontend.
Pese a que tenemos mucho código fuente disponible de forma pública en Github y NPM (como paquetes o librerías), te sugiero dominar lo antes posible el arte de escribir código limpio y sencillo de entender.
¿Qué significa esto? Podría escribir un post entero sobre este arte pero te puedo contar sobre algunas formas de abordarlo.
Una máxima es: “Leer es mejor que escribir”. Cuando te piden hacer un fix, es mejor pasar más tiempo entendiendo la causa y lo que ya existe, para así tener la solución al problema. Si sabes usar la herramienta “blame” de Git puedes dar con la persona que hizo el cambio y preguntarle porque lo hizo así.
Me gusta igual la frase “Un documento simple es mejor que nada”. Si creaste una función compleja (y en especial al momento de ser revisada en un “pull request”) crea 1 o 2 líneas de explicación/contexto. Lo mismo si creaste un “pull request”con más de 500 líneas de cambios. Deja comentarios aquí y allá para guiar a tu equipo. Si estás trabajando en un proceso complejo que involucra APIs y apps, crea un documento simple explicando como funciona y casos borde que tu equipo debe considerar.
Y sobre el código fuente, optimiza para simplificar primero. No te preocupes de problemas de performance o rapidez si todavía no tienes el uso que se requiere para ponerle la suficiente atención.
✅ Tus tareas o “to-dos” van a estar incompletos. La estimación será un desafío.
Una de las ventajas y desventajas del primer trabajo es que lo vas a romantizar. Vas a construir en tu mente un ideal que fue alimentado por las experiencias que te contaban en la universidad y de otros pares.
Una de las áreas que produce más frustración es cuando comienzas a recibir tus primeras tareas y ves que no contienen todo el detalle que esperabas. ¿Es como si el “product manager” o “scrum master” no hicieron su trabajo? No necesariamente.
Esto es perfectamente normal porque construir software no es un proceso lineal y perfecto. Los que deciden los features cambian de parecer constantemente y pueden que tu ticket o tarea no tenga la última actualización de lo que se espera.
Lo anterior también hace complicada la estimación de esa tarea. Aquí el objetivo es aprender de lo demás y expandir esa habilidad en el “campo de batalla”. La experiencias en tus primeros proyectos te va a ayudar mucho.
🌲 Las habilidades blandas son importantes
Parecido a lo que me pasó en la universidad, en tu primer proyecto vas a querer comenzar a programar de inmediato. Eso es otro mito, ya que debes considerar un período de capacitación, que entre empresas varía (puede durar de 2 semanas a 1 mes).
Si crees que solo estarás programando, estás equivocado. Habrá reuniones con frecuencia (más de las que piensas) donde deberás tener la capacidad de comunicar ideas y sugerencias. Y algunas veces porque no, entregar el estado de un proyecto.
Algo que he reiterado varias veces en el newsletter es la capacidad para ser conciso y explicar temas sin tecnicismos. Eso es un super-poder que te llevará lejos y que lamentablemente, nadie te lo va enseñar. La única forma de avanza y adquirirlo es exponiéndote a situaciones que estarán fuera de tu zona de relajo o comfort.
Otra habilidad blanda que se ve en menos es tu capacidad de ser empático y ayudar al resto. Es difícil, pero reducir los prejuicios cuando trabajas con otras personas y por defecto ponerte en modo escuchar y ayuda, te va a llevar lejos. -
Seguro habrán muchísimas más cosas para agregar a esta lista.
La clave está en aplicar estos y otros puntos, tener paciencia y los pies en la tierra
¡Disfruta del desarrollo software y de aprender!
Felipe
Cuéntame que te pareció este post:
PS: Por si te lo perdiste, ayer lancé otro episodio del podcast con Leo Soto. Una lección sobre como distinguirse en el desarrollo de software ⭐️
