El primer mes de un programador junior: tareas reales, code reviews y qué se espera de vos en tu primer trabajo

Resumen ejecutivo

• El primer mes de un programador junior se parece poco a un curso: vas a pasar más tiempo leyendo código existente y configurando el entorno que escribiendo funcionalidades nuevas.

• Las tareas típicas son tickets chicos, arreglos de bugs y cambios acotados que pasan por code review antes de llegar a producción.

• Lo que el equipo evalúa no es cuánto sabés, sino cómo preguntás, cómo recibís feedback y si tus pull requests son fáciles de revisar.

• Al final tenés una lista de chequeo semana por semana para llegar bien parado al cierre del período de prueba.

Conseguiste el trabajo. Después de meses de cursos, proyectos y entrevistas, llega el lunes de arranque y aparece una duda nueva: ¿qué se espera de mí? Ya explicamos qué hace un programador y cómo conseguir tu primer trabajo en tecnología. Esta guía cubre lo que pasa en el medio: las primeras cuatro semanas en un equipo real, contadas tarea por tarea.

Semana 1: entorno, accesos y mucho código ajeno

La primera semana casi no vas a entregar nada, y está bien. Lo habitual es:

• Configurar el entorno: clonar los repositorios, instalar dependencias, levantar el proyecto en tu computadora y pedir accesos (repositorio, gestor de tickets, chat del equipo, entornos de prueba). Casi siempre algo falla; anotá cada paso porque tu experiencia sirve para mejorar la documentación del equipo.

• Leer código existente: recorré la estructura de carpetas, cómo se nombran las cosas, dónde están los tests. Elegí un flujo concreto (por ejemplo, el login) y seguilo de punta a punta.

• Conocer al equipo: quién decide prioridades, quién revisa código y a quién preguntar por cada tema. Muchas empresas te asignan un buddy o mentor; aprovechalo.

Semana 2: tus primeros tickets

Los primeros tickets suelen estar elegidos para que conozcas el código sin riesgo: un texto mal escrito, un bug visual, un test que falta, un campo nuevo en un formulario. El flujo típico es:

1. Tomás el ticket y lo movés a "en progreso" en el tablero.

2. Creás una rama a partir de la principal con un nombre descriptivo.

3. Hacés el cambio, corrés los tests y probás a mano.

4. Abrís un pull request con una descripción clara.

5. Alguien del equipo lo revisa, deja comentarios y vos corregís hasta que lo aprueban.

Si nunca trabajaste con pull requests, la documentación de GitHub sobre pull requests explica el flujo completo.

Cómo funcionan los code reviews

El code review es la revisión de tu código por otra persona antes de integrarlo. No es un examen: es la forma en que el equipo cuida la calidad y comparte conocimiento. Las prácticas de revisión de código que publica Google lo dicen claro: el objetivo es que la salud del código mejore con cada cambio, no que sea perfecto.

Cómo hacer pull requests fáciles de revisar

• Chicos: un cambio por pull request. Cuanto más corto, más rápido te lo revisan.

• Con contexto: en la descripción poné qué cambiaste, por qué y cómo probarlo. Si es visual, sumá una captura.

• Revisados por vos primero: antes de pedir revisión, leé tu propio diff y sacá código de prueba, comentarios viejos y cambios que no van.

Cómo recibir comentarios

• Respondé todos los comentarios, aunque sea con "listo".

• Si no entendés un pedido, preguntá: "¿Te referís a X o a Y?".

• Si no estás de acuerdo, explicá tu razonamiento con respeto; a veces el revisor no tenía todo el contexto.

• Anotá los comentarios que se repiten: son tu lista de cosas para mejorar.

Cada vez más equipos usan agentes de IA que abren o revisan pull requests. Si querés entender qué cambia eso para un junior, leé qué tiene que aprender un programador junior cuando los agentes ya arrancan pull requests.

Semana 3: reuniones y ritmo del equipo

Para la tercera semana ya vas a estar en el ritmo de las reuniones habituales: la daily (una actualización breve de qué hiciste, qué vas a hacer y si estás bloqueado), la planning del sprint, la review y la retrospectiva. En la daily no hace falta contar todo: tres frases alcanzan. En la retrospectiva, animate a decir qué te costó; para el equipo es información valiosa sobre su onboarding.

Cuándo y cómo pedir ayuda

Es el punto donde más se equivocan los juniors, por exceso o por defecto. Una regla práctica es la de los 30 minutos: si llevás media hora trabado sin avanzar, preguntá. Y preguntá bien:

• Qué querías lograr.

• Qué probaste.

• Qué error o resultado obtuviste.

• Cuál es tu hipótesis.

Preguntar así muestra que intentaste y le ahorra tiempo a quien te ayuda. Hacelo en el canal del equipo en lugar de por privado cuando la duda puede servirle a otros.

Semana 4: qué evalúa el equipo

Al cerrar el primer mes, y más todavía al final del período de prueba, el equipo suele mirar:

• Si tus entregas avanzan de forma constante, aunque sean chicas.

• Si incorporás el feedback y no repetís los mismos errores en los reviews.

• Si comunicás a tiempo cuando algo se demora.

• Si entendés el producto, no solo el código.

Para lo que viene después, tenemos una guía sobre qué esperan de vos en el período de prueba de tu primer trabajo tech.

Lista de chequeo semana por semana

• Semana 1: entorno funcionando, accesos completos, un flujo del código entendido de punta a punta, notas de instalación compartidas.

• Semana 2: primer pull request aprobado e integrado.

• Semana 3: participación activa en la daily y la retrospectiva, dos o tres tickets cerrados.

• Semana 4: una conversación de feedback con tu líder o mentor, con dos cosas para mejorar el mes siguiente.

Cursos recomendados de Coderhouse

Si todavía estás preparándote para ese primer trabajo, la carrera de Desarrollo Full Stack te hace trabajar con Git, ramas y proyectos en equipo, muy parecido a lo que vas a vivir en una empresa. Si tu objetivo es backend, la carrera de Desarrollo Backend profundiza en APIs y bases de datos.

Preguntas frecuentes

¿Es normal no entender el código del proyecto en el primer mes? Sí. Los proyectos reales tienen años de historia y decisiones que no están documentadas. Lo esperable es que entiendas las partes que tocás, no todo.

¿Cuántos tickets se espera que cierre un junior el primer mes? Depende del equipo y del tamaño de los tickets. Importa más la tendencia: que cada semana avances más rápido y con menos correcciones.

¿Qué hago si me dejan muchos comentarios en un code review? Tomalo como aprendizaje, corregí todo y anotá los patrones. A todos los juniors les pasa en sus primeros pull requests.

¿Puedo usar IA para programar en mi primer trabajo? Preguntá la política del equipo antes. Si está permitido, usala para entender código y generar tests, pero revisá todo lo que proponga antes de subirlo.