Comenzar en el mundo laboral no es sencillo y trabajar en empresas tecnológicas menos aún.
El paso del mundo académico al mundo laboral es muy grande y requiere un cambio de mentalidad. Ya no tienes profesores, tienes jefes y la relación con ellos va a ser totalmente diferente.
Los primeros días de trabajo en una empresa que desarrolla software suelen ser un poco caóticos. Estás un poco descolocado, no entiendes nada, no tienen suficiente tiempo para ti e incluso puede ser que no dispongas de tu propio equipo. Mi consejo en estas situaciones (que son más habituales de lo que parece) es mantener la calma y no ponerse nervioso.
La empresa suele ser consciente de estas situaciones. Se tiene en cuenta (sobre todo si eres junior) que no vas a empezar a producir desde el día uno.
En estos primeros días lo mejor es familiarizarte con tu entorno de trabajo, tus compañeros y leer mucha documentación que suele ser la tarea más habitual en estos primeros días de trabajo.
Pregunta cuando tengas dudas
Mi primer consejo es que no te estreses los primeros días si no tienes mucho trabajo o te falta algún permiso para acceder a alguna parte del proyecto que tienes asignado. No dudes en realizar preguntas si te hacen una presentación de la empresa o de tu proyecto en el que estás asignado. ¿Qué tecnologías usáis? ¿Cúanto tiempo lleva el proyecto en marcha?… En mi opinión mostrar interés en tu empresa/proyecto es algo positivo y demuestra que te interesas por tu nuevo trabajo.
Pasadas varias semanas ya habrás comenzado a realizar algún pequeño cambio de un módulo o habrás comenzado a implementar alguna nueva funcionalidad. Mi consejo de nuevo es preguntar si no tienes algo claro. Los perfiles junior a veces preguntan menos de lo debido. Si eres nuevo en el puesto de trabajo es imposible que no te surjan mil y una preguntas. No consiste en cansar a la gente con preguntas muy seguidas, pero sí realizar preguntas constructivas como por ejemplo:
- A la hora de realizar un commit ¿Qué políticas seguís (Git flow, etiquetado de ramas…)?
- ¿Cómo realizáis las subidas a producción?
- Puedes hablar con un compañero tuyo con más experiencia y contarle de manera resumida como vas a implementar una funcionalidad que te han encargado. Por ejemplo: voy a crear un controller X basándome en este otro controller. Para realizar el nuevo servicio he observado que el servicio Y se parece mucho a lo que me han pedido. Es una buena forma de encarrilar tu primer desarrollo.
- Normalmente tu primera tarea será relativamente sencilla y es probable que la mayoría del código ya exista o sea muy parecido al que debas realizar. Pregunta si vas a hacer grandes cambios en el código.
De esta forma, poco a poco irás ganando competencias en tu primer proyecto.
Donde fueres haz lo que vieres
Suena viejuno pero es una realidad. Relacionado prácticamente en todos los ámbitos de tu nueva empresa: horas de comida, comportamiento y por supuesto en la manera de codificar.
Quizás te llame la atención este último punto. En mi opinión seguiría la misma manera de programar que la que me encuentre en un proyecto. Respetaría la misma estructura de los métodos, la misma manera de realizar los logs, la misma nomenclatura de las variables…
No olvides que estás en un equipo de desarrollo y se trabaja de manera conjunta. ¿Qué pasa si hay métodos están mal implementados? ¿los cambio y los refactorizo por una solución más elegante? ¡Pregunta! A priori no sabes por qué se ha realizado «mal» ese código. Puede haber un motivo concreto o se está esperando una refactorización que depende de un arquitecto. Puedes ser también que el código sea malo… pero debes preguntar siempre que modifiques algo que se aleja de la tarea que te han pedido. Este punto es muy importante porque puedes «romper algo» ya que no tienes tanta experiencia ni en el proyecto ni como desarrollador.
Si te atascas di exactamente donde
Algo muy habitual en desarrolladores junior. Te bloqueas completamente en una tarea que te han dado. Es complicada y hay muchas cosas que no entiendes. Mi consejo es que la dividas en tareas más sencillas y empieces por aquello que entiendes mejor. Si trabajas con una aplicación spring boot con persistencia al menos podrás hacer las entidades (aunque no conozcas todos los campos). Puedes implementar el controlador y devolver algún valor en duro hasta que sepas que tipo de objeto debes devolver.
Todo ello va orientado a decirle a tus compañeros donde te has atascado de manera exacta. Con esta manera de proceder demuestras que razonas bien y que vas paso a paso avanzando en tu tarea. La persona que te ayuda se puede centrar en el punto de error concreto y no tendrá que repasar todo lo que se te ha pedido.
Estos consejos están basados en mi opinión personal, pero me han ayudado siempre que he entrado a nuevo proyecto (no necesariamente siendo junior).
Juan Pardo Palazón
Responsable técnico de laboratorio en MÉTRICA LAB
[email protected]
