El camino del junior en la ingeniería del software

En este artículo no pretendo definir que es un junior en ingeniería, ni los requisitos que se deben cumplir para terminar el ciclo de junior en la carrera como ingeniero de software. Sin más preámbulos empecemos.

Descubriendo lo poco que sabemos y lo mucho que falta por aprender

Cuando se comienza en el mundo del software de manera profesional después de haber cursado semestres en la universidad, se empieza o por lo menos en un principio con un chip de grandeza (difícil no tener ese sentimiento después de haber sido el mejor en los tiempos estudiantiles), el cual se desmorona al poco tiempo de empezar a trabajar y rápidamente queda en evidencia que no sabíamos tanto como creímos. Eso “mucho” que aprendimos en la academia al final termina siendo poco para lo que profesionalmente se necesita.

Un sentimiento que no tarda en llegar es el pánico ocasionado por el ‘cómo voy a lograr esto’, acompañado en ocasiones del síndrome del impostor. Si llega a pasar esto lo que podría decirte después de más de una década trabajando en esto es: NO TE PREOCUPES, en su mayoría todos pasamos por allí y casi todos somos personas empáticas que sabemos lo que es ese sentimiento.

Si lo anterior ocurre lo primero que debes hacer es expresar aquellas cosas que no sabes a tu líder, si es un buen líder comprenderá y realizará contigo un plan de trabajo. En caso de tener un mal líder como aquel tirano que no escucha a su equipo y tiene cero empatía (aún existen) podría recomendarte que hables con tus compañeros de equipo y junto a ellos comiences un plan de mejora profesional en el cual poco a poco suplas esos vacíos técnicos que poseas.

Algo que jamás debes de hacer es callar y esperar que las cosas se resuelvan por si solas. En su lugar debes conservar un hambre de conocimiento que sin importar la experiencia y tiempo nunca disminuya.

Tu opinión es importante, ¡Eres un valioso miembro del equipo!

Algo con lo que me he topado en todos los proyectos donde he trabajado es la poca participación de los junior durante discusiones técnicas (obvio siempre habrá la excepción a la regla pero no es la norma), tal vez por pena, tal vez por desconocimiento, tal vez por miedo a equivocarse o también pudiendo ser todas las anteriores.
Sin importar cual sea la cuestión no calles y siempre comenta las dudas que tengas o da los aportes que consideres que deben darse. Puede sonar cliché lo anterior, pero cuando lo hagas podrás empezar a notar los siguiente:

  • Tu duda en varios casos la tendrán también otras personas del equipo.
  • Tu conocimiento tendrá un crecimiento exponencial al despejar las dudas y retarte a ti mismo.
  • Esa duda que tienes en algún momento la tuvo otro miembro del equipo.

No te juzgues tanto

El ser nuevos en un equipo o tener poca experiencia regularmente se cae en hacer comparaciones con los miembros mas experimentados del equipo y podrías experimentar no sentirte tan ‘pro’.

Siempre debes recordar que este camino de programación es un camino largo y sin fin el cual apenas estás empezando. Aprende a valorar cada paso del camino que des y compárate a ti mismo en retrospectiva, verás cómo tu conocimiento mes tras mes va en un crecimiento constante.

Mi consejo personal es “Sé una esponja” absorbe todo el conocimiento/trucos que más puedas de las personas con más experiencia en el equipo siempre ignorando las mañas y aquellas cosas que consideres que no son éticas. Soy un fiel creyente que el autoaprendizaje es la clave del éxito pero el poder tener una persona de la cual aprender es invaluable, ¡aprovechala!.

Del afán solo queda el cansancio

El objetivo de tu trabajo siempre debe ser calidad y no cantidad. En esta profesión se sufre una necesidad constante de entregar bastante desarrollo sacrificando la calidad para lograrlo ¡Grave error!, aunque siendo sincero este problema no es solo de los junior, aunque parezca sorprendente muchos senior también sufren de lo mismo.

Junto a la calidad de tu desarrollo debe ir acompañado de la validación de cada escenario posible que puede pasar en producción, mi consejo aca es: Ser desconfiado, desconfía de todo. ¿Por qué? porque entre más desconfiado seas más validaciones vas a realizar, ¿Afectará producción ejecutar este script? ¿Debería validar más escenarios de prueba? ¿Ya tuve en cuenta X cosa? ¿Es mejor preguntarle a otro miembro por X cosa? ¿Qué pasaría si llega a pasar X cosa?.

Las anteriores junto a más preguntas son las que debes estar en constante ejecución, entre más experiencia tengas verás que muchos de los errores que se comenten al principio es exceso de confianza.

Enfocate

Este mundo de programación es gigantesco, repito: gigantesco. Nunca vas a terminar de aprender todo lo que hay, porque verás que cuando hayas terminado con algunos temas (lenguajes, nubes, frameworks, herramientas, etc) nacerá uno nuevo cada mes, por esta razón te aconsejo toma un tema y especialízate en ello antes de empezar con otro tema.

Hay una frase que dice “Un mar de conocimiento y un centímetro de profundidad” este es un grave error al momento de comenzar en este mundo, caer en la necesidad de abarcar muchas cosas al tiempo nos hará perder especialidad en temas que son importantes. Busca aquello que te apasione (y necesite el equipo/proyecto) y conviértete en un especialista, después busca más y más temas para aprender.

Para finalizar, la búsqueda constante de retos, la solución sin acabar de problemas, el conocimiento sin fin que existe, hacen de esta carrera la mejor de la historia. ¡Disfrutala!

2 comentarios en «El camino del junior en la ingeniería del software»

  1. 1. Después de varios años parcialmente desconectado del mundo TI, cuando volví fue abrumador la cantidad de aplicaciones hoy en día, no se nada en comparación con lo que me falta por aprender y debo mantener viva esa sed de conocimiento.

    2. Siempre me gusta dar mi opinión a pesar de que en ocasiones suene pendejo.

    3. El tema de la calidad es aplicable siempre y cuando el cliente este dispuesto, en ocasiones los tiempos de entrega no dan para aplicar una arquitectura compleja o simplemente el proyecto no es tan complejo, pero por suerte se puede refactorizar.

    4. Por suerte encuentre que me apasiona el tema de las interfaces de usuario, aunque llegue por casualidad me quede por pasión.

    Considero que un buen equipo de trabajo debe incluir equilibrio, buena comunicación y un buen liderazgo no solo en el campo TI sino en cualquier rubro hasta la construcción.

    PD: Este post me llego más que el último que escribiste a la fecha de este comentario (Me falta seniority para llegar a opinar con criterio).

    Responder

Deja un comentario