Blog>

Mario Querol
24 Ene 2023

Del aula a la oficina: Consejos de un junior

Tiempo de lectura 6 minutos
  • juniors
  • manual de supervivencia

Sumario Las segundas partes nunca fueron buenas… ¿O sí? Partiendo del Manual de supervivencia para juniors I la experiencia de un estudiante de FP que entra al mundo laboral contada en siete consejos

Siguiendo la línea de "Manual de supervivencia para Juniors I", esta entrada pretende continuar arrojando luz a aquellos que, como yo, empezamos a "meter el pie" en el mundo laboral.

Notas finales… graduación… crearse perfil de linkedin… nervios…. entrevista…. más nervios…. y al final, nos contratan como programador@ junior, ¡por fin!

Estábamos deseando entrar al mundo laboral para ver los frutos de nuestra formación y poder aportar valor a una empresa y un proyecto. Pero después de ser asignados a un proyecto y de presentarnos al equipo, nos encontramos un montón de cosas que no nos esperábamos.

Te cuento como es la experiencia de un "junior" mediante algunos consejos que intento mantener siempre presente en mi día a día.

Consejo nº1: Ser paciente

Una de las primeras cosas con las que me encontré, fue tener que adaptarme a los tiempos que tienen algunos trámites. Hay muchas cosas que no dependen de nosotros, ni de nuestros compañeros, ni a veces de nuestros jefes. Tendremos que ser pacientes hasta que se resuelvan.

El tema de permisos es una de ellas, ya que, lleva tiempo que nos den acceso a todas las plataformas. Todos los problemas que surgen de montarse el entorno en nuestro ordenador. Parece que solo es bajarse el proyecto y compilar, pero se puede complicar muchísimo. Comunicarse con cliente o parte del equipo que no esté dentro de nuestra empresa también puede llevar más tiempo del deseado.

Consejo nº2: No tener reparo en preguntar, somos Junior

No nos olvidemos de que trabajamos en equipo, y que nuestros compañeros más veteranos no van a tener problema en ayudarnos en cualquier momento. Aun así, muchas veces por no molestar o por no interrumpir, me he quedado con la duda, hasta que ya estaba tan bloqueado que no me quedaba otra que preguntar. No hace falta llegar a ese extremo, intento que cuando estoy con una tarea que se me ha asignado y llevo más de, por ejemplo, una hora dándole vueltas, me obligo a preguntar a mis compañeros. Siempre me han ayudado, no te preocupes por ser pesado, no lo serás, lo normal es que tengas dudas, ¡somos junior!.

Siempre me ha preocupado ser pesado y creo que no lo he sido, espero…

Consejo nº3: Seguridad

Este consejo lo intento aplicar en todos los ámbitos de mi vida.

Cuando he estado desarrollando y no estaba seguro al cien por cien seguro de lo que estaba haciendo, han sido las peores veces. Me generaba inseguridad. Luego si tienes que justificar las razones es más difícil, así que hagas lo que hagas, aunque te equivoques, hazlo con confianza. Mejor equivocarse teniendo las razones claras.

Consejo nº4: No tener miedo a romper nada

Muy relacionado con el tip anterior.

Al principio tenía inseguridad de que mis cambios pudieran romper algo en producción. Ya no es que a nuestr@ profe le vaya a dar un fallo. Es que hay un cliente final y un usuario utilizando el software que estamos haciendo.

Era una de mis preocupaciones cuando finalizaba una tarea por muchas pruebas que hiciera en local, pero poco a poco viendo que en nuestro equipo hacemos Code Review, que después de que nuestro código sea integrado va a pasar por un equipo de testing y que haya un git para gestionar las versiones, se me fue quitando esa inseguridad, y también se añade el hecho de que cuanto más conoces el proyecto más vas a poder saber el impacto que va a tener ese cambio.

Consejo nº5: Un Junior prueba

Como perfiles junior, no nos queda otra que probar, probar de nuevo y volver a probar.

Al principio no vamos a conocer el proyecto al completo, lo iremos entendiendo poco a poco según vayamos realizando tareas, así que, los primeros días cuando nos asignen una tarea lo mejor es probar y jugar con la aplicación para entenderla mejor, esto es un proceso lento, porque muchas veces no hay documentación o si la hay, no está actualizada, y si el proyecto es muy grande y lleva mucho tiempo, más aún, aquí es importante el primer consejo.

También probar después de que hayamos realizado una tarea, probar la funcionalidad que hemos añadido y la que ya había por si acaso la hemos alterado sin querer, aunque vaya a pasar más revisiones nuestras pruebas son muy importantes.

Consejo nº6: Centrarse en la tarea

Muchas veces me he visto en la situación que solucionando un bug o implementando nueva funcionalidad he visto cosas en el código que se podían mejorar y más de una vez he perdido el rumbo de la tarea inicial mejorando otra cosa. Me gusta aplicar la ley del boy scout, “Dejar el código mejor de lo que te lo has encontrado”, pero no hay que llevarla al extremo, ya que las tareas tienen un tiempo y un presupuesto asignado, si ves que tu mejora va a ser pequeña, rápida y no a va a tener un impacto en el funcionamiento hazla, pero en el caso de que no lo sea lo mejor es que te lo apuntes y lo comentes al jefe/jefa de equipo en la próxima reunión o que le mandes un mensaje y de esa manera podrá crearse una tarea específicamente para que sea solucionado.

Consejo nº7: Estar abierto al cambio

Recién salido del ciclo estaba obcecado en usar las tecnologías que había aprendido y en hacer solo backend porque lo único que sabía de frontend era HTML y CSS puro. Pero luego me cambió el chip ya que al final ¿por qué elegir una tecnología si realmente la había usado muy poco y no conocía muchas más? Una de las primeras cosas que aprendí fue que un programador tiene que saber adaptarse a todo tipo de situaciones, entornos de desarrollo, herramientas, etc. El problema es que es muy fácil acomodarse en un lenguaje en cuanto ya empiezas a manejarlo, pero ya tendremos tiempo de especializarnos, o no. Según vayamos probando nuevas tecnologías y herramientas iremos viendo que nos gusta más y que menos. En mi caso sé que me sigue gustando más el backend, pero ahora es distinto porque he hecho desarrollos en frontend en otros lenguajes y ahora me gusta el frontend, además en prácticamente todas las tareas de los pocos proyectos en los que he estado ha hecho falta desarrollar tanto en back como en front ya que son muy dependientes.

En definitiva, la diferencia entre el aula y la oficina es abismal, dos mundos distintos. Mi experiencia ha sido buena y me ha sorprendido gratamente. Sobra decir que todo tiene su tiempo, su parte buena y su parte mala. Pero lo que más valoro es independientemente de lo que esté haciendo y aunque a veces cueste más es estar aprendiendo en el proceso.

Autor

Mario Querol
Mario Querol

Desarrollador en dev&del

Aprendiz de Java Spring, Angular y lo que me echen.

Amante de la escalada capaz de trepar, literalmete, hasta la cima de sus objetivos.

¿Estás interesado?

Déjanos tus datos y contactaremos contigo lo antes posible