Background Image
DESARROLLO DE SOFTWARE

Incorporación eficaz como desarrollador junior

Daniel Scheufler headshot

February 9, 2022 | 7 Minuto(s) de lectura

Cuando uno entra por primera vez en una empresa, es natural que sienta cierta ansiedad. Quieres rendir bien en el trabajo que te acaban de adjudicar. Quiere labrarse una buena reputación y ser capaz de contribuir. Añádele una pizca de probarte a ti mismo y obtendrás una potente mezcla de emociones que te llevarán a pensar "¡tengo que hacerlo yo mismo!

Pero de ahí surge la preocupación de cómo, cuándo e incluso si debes pedir ayuda cuando te atasques. ¿Se espera de ti que lo resuelvas todo sin molestar a los miembros de tu equipo? ¿Y cómo determinar la diferencia entre asegurarse de poder contribuir y ser una "carga"?

Empecemos por eliminar algunos conceptos erróneos

Girl at work in a meeting

La incorporación como desarrollador junior va a requerir trabajo, tanto por tu parte como por parte de tu equipo. Por lo tanto, no es razonable esperar que lo hagas todo tú solo. Pero no te preocupes, el hecho de que seas tú quien reciba la mayor parte de la instrucción no significa que seas el único que se beneficie de la interacción. Al enseñar, el profesor aprende mejor el material.

Pero, ¡espera! Aún hay mejores noticias. Con algunas acciones inteligentes y de valor añadido, incluso como nuevo miembro de un equipo, puedes tener un impacto positivo. Y todas esas acciones pueden resumirse así: Haz primero todo lo que sepas hacer. Después, pide ayuda.

Puedes explorar estas acciones examinando la experiencia de incorporación de un desarrollador junior. En este contexto, tú, el ingeniero junior, puedes esperar conocer parte del trabajo, pero definitivamente no todo. Dada la función que desempeñas, sería razonable suponer que el objetivo de contratarte es descargar a otros miembros del equipo de parte del trabajo de nivel junior. Entonces, ¿cómo puedes, como desarrollador junior, actuar para lograr ese objetivo de la forma más rápida y eficaz?

Tu trabajo es aprender

La respuesta más breve: tienes que aprender. Tienes que aprender sobre los sistemas en los que trabajas. Tienes que aprender formas eficaces de trabajar. No necesita sólo una guía de respuestas. Necesita desarrollar las habilidades necesarias para alimentarse.

Three Women working around a laptop

Y tienes que desarrollar la confianza de que, mientras haces todas estas cosas, sigues aportando valor. No caigas todavía en la trampa de compararte con tus compañeros de equipo. Habrá un momento para ello, pero no es ahora. En lugar de centrarte en las diferencias entre lo que tú puedes conseguir y lo que consiguen los desarrolladores veteranos, céntrate en si estás haciendo todo lo que puedes hacer o no.

Aplicando la mentalidad de "haz todo lo que sabes hacer", puede que consigas un ticket recomendado para ti. El primer paso para poder completar el trabajo es simplemente saber qué hacer. ¿Puede explicar en inglés qué hay que hacer para completar el ticket? ¿Necesita cambiar cuándo se abre un modal? ¿O añadir alguna entrada a un formulario?

Empieza por escribir lo que tienes que hacer. Busca la forma de articularlo. Ahora, si te quedas atascado, aún habrás añadido algo de valor. Has reducido el problema a una serie de acciones concretas. Además, todo está por escrito y es transferible.

Así, cuando el desarrollador senior venga a ayudarte, puedes estar seguro de que lo has entendido. No has dejado al desarrollador senior adivinando en qué punto del proyecto estás o qué entiendes. Has proporcionado un punto de partida, lo cual es estupendo. Y lo que es más, ¡hiciste la carga más fácil sin escribir una sola línea de código todavía!

Volviendo a los pasos escritos... Si estás seguro de que esto es correcto y sabes cómo implementarlo, ¡pruébalo y escribe algunas pruebas para ello! De este modo, el ordenador ayuda a confirmar que el código funciona como se espera. Pero asegúrate de delimitar el tiempo de trabajo. No te vayas cuatro horas y vuelvas al senior para comprobarlo. En lugar de eso, apóyate en Inspeccione-Adaptar de la práctica ágil. Intente utilizar un ciclo de iteración más corto.

Poner "guardarraíles" en su proceso

Timer on a desk

Personalmente sugiero utilizar un Pomodoro como una buena estructura de trabajo. Un Pomodoro es un simple temporizador de cocina. Ajústalo para 25 minutos de trabajo concentrado cada media hora y utiliza esos 5 minutos sobrantes para evaluar lo que has hecho o para beber un poco de agua. Puedes pasar uno o dos Pomodoros, no más de una hora, retocando nuestra solución. Después, haz que lo comprueben. De esta forma podrás progresar un poco y seguir recibiendo feedback sobre tu trabajo y sobre tu dirección por parte del desarrollador senior.

Supongamos que vuelves a ver los pasos que has escrito. En lugar de estar seguro o totalmente confundido en esta coyuntura, estás algo seguro de que es el camino correcto, pero no sabes cómo hacerlo. En tal circunstancia, no saltes inmediatamente a pedir ayuda. En lugar de eso, tómate un tiempo para investigar cuál es el enfoque adecuado. Incluso la simple búsqueda de "cómo {hago X}" puede empezar a dar buenos resultados.

Aquí hay un paso fundamental. NO te limites a copiar cualquier respuesta que encuentres en tu producto de trabajo. Como desarrollador junior, el objetivo es empezar a añadir valor, tanto ahora como a largo plazo. Esto requiere un grado de autosuficiencia para lograrlo. Así pues, uno de nuestros objetivos laborales debe ser aprender, y no se aprende si uno se limita a copiar. Así pues, tómate tu tiempo para comprender las respuestas que vas encontrando. Eso puede significar recurrir a StackOverflow abierto en una ventana y el editor en otra mientras escribes manualmente una versión de la solución que estás viendo.

De nuevo, apliquemos aquí la técnica Pomodoro. El tiempo puede ayudarte iterativamente. Y puedes mejorar iterativamente tu trabajo sin interrumpir constantemente al desarrollador senior. Si usted no ha llegado a probar la respuesta todavía, sólo mostrar y contar. Esto puede mostrar a tu desarrollador senior dónde estás buscando respuestas, y dónde puede ayudarte mejor como tu mentor.

Effectively Onboarding as a Junior Developer - Body Image -4

Ahora, abordemos la última posibilidad externa que puedes encontrar mientras investigas. Supongamos que ninguna de las respuestas en Internet es realmente útil. Quizá muestren partes de una solución, pero nada directamente para tu reto. Eso podría significar que la táctica destilada de "necesito {hacer X}" necesita refinarse. O puede que estés haciendo algo único, y eso está bien. Busquemos la forma de que la pelota siga avanzando, antes de correr a buscar ayuda.

En el caso de los desarrolladores de software, a menudo nos encontramos con ejercicios de "pseudocódigo" en las entrevistas. Te propongo que utilices esta misma técnica para aumentar esa táctica de "necesito {hacer X}". Como parte de cualquier flujo de trabajo más amplio, hay pequeños pasos.

Piensa, por ejemplo, en cómo calcular el precio de un carrito en una aplicación de comercio electrónico. Necesitará completar el precio total y los impuestos debidos. Para calcular el precio total, es posible que tenga que hacer algunos cálculos sencillos de precios unitarios y, a continuación, aplicar cupones. Para obtener los impuestos, es posible que tenga que averiguar qué artículos están sujetos a impuestos y qué tipos debe utilizar. Entonces puede calcular el impuesto de cada artículo. Pero fíjate en lo que ha pasado. Has descompuesto el reto. Tomó el concepto 'Quiero {hacer X}' que en este caso era 'Calcular el Total del Carrito' y lo dividió en los pasos para llegar allí. Luego miró esos pasos y los dividió aún más.

Algunas firmas simples y comentarios en pseudo-código podrían verse así:

Al desglosar el trabajo, has reflexionado sobre él. Has añadido valor, igual que cuando compartiste los primeros pasos. Has reducido el trabajo a "Quiero {hacer X}". Ahora el miembro superior del equipo puede venir a ver el plan de trabajo. Desde aquí es fácil hacer correcciones o sugerir implementaciones. Quizá encuentren los pasos que te has saltado. Como hemos enumerado nuestros pasos de trabajo, podrán verlo más fácilmente o les permitirá hacer preguntas más específicas. Y como siempre, ponle tiempo a esto. Tómate un par de Pomodoros como mucho para dar un paso adelante. Después, pide feedback y ayuda.

Code example

Mantén tus ciclos sencillos. Haz todo lo que sepas hacer y luego pide ayuda. Añadirás un poco de valor en cada paso. Obtendrás retroalimentación iterativa rápida. Esto te permite equilibrar la petición de ayuda con un buen progreso. Al dedicar tiempo de forma proactiva a pasar de un paso a otro, aumentas la confianza de tu equipo en tu aptitud. Además, seguirá recibiendo la ayuda necesaria para progresar sin quedarse atascado en ningún sitio durante demasiado tiempo. Al dedicar tiempo a trabajar en el problema usted mismo, aumenta su aptitud para seguir contribuyendo a largo plazo. ¿Y quién sabe? A este paso, puede que seas tú quien dirija la próxima incorporación.

Para obtener más información sobre Improving y nuestros actuales puestos vacantes, póngase en contacto con nosotros¡!

Desarrollo de software

Reflexiones más recientes

Explore las entradas de nuestro blog e inspírese con los líderes de opinión de todas nuestras empresas.
Asset - Lead with Purpose: A Guide to Delegation Image 1
LIDERAZGO

Dirigir con determinación: Guía para delegar

Una guía para empezar a delegar cuando no sabes por dónde empezar como nuevo líder.