1. Onboarding de Nuevos Desarrolladores

Proceso estructurado para incorporar nuevos miembros del equipo de forma rápida y efectiva.

1.1 🎯 Onboarding Efectivo

Qué: Proceso para que nuevo desarrollador sea productivo rápidamente y se sienta parte del equipo.

Por qué: Mal onboarding = 6 meses para ser productivo. Buen onboarding = 2-4 semanas.

Quién: Nuevo dev + buddy/mentor + tech lead.

Cuándo: Desde día 1, primeras 4-6 semanas.

Cuánto: Inversión de 30 horas del equipo, reduce turnover y acelera productividad.

1.2 📅 Timeline Sugerido

1.2.1 Día 1: Setup y Bienvenida

Mañana (9-12h):

• Welcome meeting con equipo
• Setup laptop, accesos (email, Slack, GitHub, JIRA)
• Tour de oficina (si presencial)
• Lunch con equipo

Tarde (18h):

• Leer README principal del proyecto
• Clonar repositorios
• Setup ambiente de desarrollo local
• Primer build exitoso ✅

Objetivo: Sentirse bienvenido + ambiente funcionando.

1.2.2 Semana 1: Contexto y Primeros Pasos

Lunes-Miércoles:

• Onboarding general empresa (HR, benefits, cultura)
• Meeting 1-on-1 con manager
• Leer docs de arquitectura
• Explorar codebase (grep, code reading)
• Shadowing: observar daily standup, planning

Jueves-Viernes:

• Primer ticket: bug fix pequeño o mejora de docs
• Pair programming con buddy
• Primera PR (con mucha ayuda)
• Code review de PRs del equipo (observar)

Objetivo: Entender contexto + primera contribución pequeña.

1.2.3 Semana 2-3: Ramp Up

• Tickets de complejidad creciente
• Pair programming 2-3 veces/semana
• Participar activamente en dailies
• Hacer preguntas (crear cultura de curiosidad)
• Primera feature pequeña end-to-end

Objetivo: Autonomía creciente, confianza.

1.2.4 Semana 4-6: Autonomía

• Features medianas independientes
• Menos pair programming, más async support
• Participar en design discussions
• Onboarding de siguiente nuevo dev (enseñar = aprender)

Objetivo: Contribuidor full, integrado al equipo.

1.3 📚 Onboarding Docs Esenciales

1.3.1 1. GETTING_STARTED.md

Contenido:

Estructura Esperada:

1. Prerrequisitos: Versiones exactas de lenguajes, DBs y herramientas (Docker).
2. Instalación: Comandos paso a paso para levantar el entorno desde cero.
3. Configuración: Explicación de variables de entorno (.env) y secrets.
4. Ejecución: Cómo correr la app, tests y linters.
5. Troubleshooting: Solución a errores comunes de setup.
6. Verificación: Cómo confirmar que todo está funcionando ("It works!").

Ejemplo:

# Getting Started

## Prerequisites
- Node.js 18+
- Docker Desktop
- PostgreSQL 14+

## Setup (5 minutos)
1. Clone repo: `git clone ...`
2. Install deps: `npm install`
3. Copy env: `cp .env.example .env`
4. Start services: `docker-compose up -d`
5. Run migrations: `npm run migrate`
6. Start dev server: `npm run dev`
7. Open http://localhost:3000 (verificar puerto en .env/README)

## Verify Setup
- [ ] App loads sin errores
- [ ] Tests pasan: `npm test`
- [ ] Linter pasa: `npm run lint`

## Troubleshooting
**Error: "Port 3000 already in use"**
- Run: `lsof -ti:3000 | xargs kill -9`

**Need help?** Ask in #engineering-help Slack channel

1.3.2 2. ARCHITECTURE.md

Secciones:

• Overview diagram (C4 Context)
• Tech stack con versiones
• Estructura de carpetas
• Flujo request típico
• Decisiones arquitecturales (ADRs)
• Enlaces a docs detalladas

1.3.3 3. CONTRIBUTING.md

Contenido:

• Branch naming
• Commit messages (Conventional Commits)
• PR template y checklist
• Code review guidelines
• Testing requirements

1.3.4 4. ONBOARDING_TASKS.md

Estructura Esperada:

• Por Tiempo: Dividir tareas por Día 1, Semana 1, Mes 1.
• Accionables: Tareas concretas (leer X, instalar Y, deployar Z).
• Social: Incluir interacciones con el equipo (café, pair programming).
• Checkboxes: Formato interactivo para dar sensación de progreso.

Checklist interactivo (Ejemplo):

## Week 1
- [ ] Setup ambiente local
- [ ] Leer ARCHITECTURE.md
- [ ] Explorar codebase
- [ ] Completar ticket: #123 (docs update)
- [ ] Primera PR merged
- [ ] Conocer al equipo (lunch/coffee)

## Week 2-3
- [ ] Pair programming con 3 personas diferentes
- [ ] Fix bug: #456
- [ ] Implementar feature pequeña: #789
- [ ] Participar en retro
- [ ] Dar feedback sobre onboarding

## Week 4+
- [ ] Feature mediana end-to-end
- [ ] Presentar trabajo en team meeting
- [ ] Revisar PRs de otros

1.4 👥 Buddy System

What: Asignar mentor/buddy al nuevo dev.

Responsabilidades del Buddy:

• Responder preguntas (no juzgar ninguna pregunta)
• Pair programming primeras 2 semanas
• Code review de primeras PRs
• Introducir a equipo, cultura, unwritten rules
• Check-in diario primera semana, 2x/semana después

Perfil ideal:

• Mid-senior level (no junior, no staff)
• Paciente, buen comunicador
• Conoce bien el codebase
• Voluntario (no forzado)

Rotación: Rotar buddies cada 2-3 nuevos devs para evitar burnout.

1.5 🎓 Learning Path

1.5.1 Recursos Internos

1.5.2 Primeros Tickets

Características:

• Bien definidos (acceptance criteria claros)
• Scope pequeño (< 1 día)
• No críticos (ok si toma más tiempo)
• Varias opciones para elegir según interés

Ejemplos:

• Actualizar README con screenshots
• Agregar tests a función existente
• Fix typo en error messages
• Mejorar logging de endpoint específico
• Agregar validación faltante

1.6 🔍 Explorar Codebase

Técnicas:

1.6.1 1. Code Reading Sessions

• 30 min diarios leyendo código
• Seguir un flujo completo (HTTP request → DB → response)
• Anotar preguntas

1.6.2 2. Grep/Search Patterns

# Encontrar todos los endpoints
rg "@app.route\|@app.get" --type py

# Encontrar uso de función
rg "sendEmail" --type ts

# Encontrar TODOs
rg "TODO|FIXME"

1.6.3 3. Git Blame/History

# Ver quién escribió línea X
git blame archivo.py

# Ver commits recientes de archivo
git log --oneline archivo.py

# Ver cambios en función específica
git log -L :functionName:archivo.py

1.6.4 4. IDE Features

• "Find all references"
• "Go to definition"
• "Show call hierarchy"

1.7 📊 Metrics de Onboarding

1.8 💬 Check-ins Regulares

1.8.1 1-on-1 con Manager

Semana 1:

• ¿Cómo se siente en el equipo?
• ¿Algo no quedó claro?
• ¿Se necesita acceso a algo?

Semana 2:

• ¿Estás bloqueado en algo?
• ¿El buddy está siendo útil?
• ¿Qué podemos mejorar del onboarding?

Semana 4:

• ¿Te sentís integrado al equipo?
• ¿Qué te gustaría aprender next?
• Feedback del onboarding para mejorarlo

1.9 🎉 Celebrar Hitos

Cultura: Todos celebran, no solo manager. Hace sentir bienvenido.

1.10 🚫 Anti-patrones

1.11 📋 Onboarding Checklist (Manager/TL)

1.11.1 Antes del día 1

• [ ] Laptop y accesos configurados
• [ ] Buddy asignado (y aceptó)
• [ ] Primera tarea preparada
• [ ] Team notificado de llegada
• [ ] Calendario con meetings key
• [ ] Slack channels relevantes identificados

1.11.2 Día 1

• [ ] Welcome message en Slack
• [ ] Intro con equipo completo
• [ ] Tour de oficina/intro a herramientas
• [ ] Setup completado exitosamente

1.11.3 Semana 1

• [ ] 1-on-1 inicial (30 min)
• [ ] Primera PR revisada por buddy
• [ ] Invitado a todos los meetings de equipo

1.11.4 Mes 1

• [ ] Check-in semanal
• [ ] Primera feature merged
• [ ] Participando activamente en discusiones
• [ ] Survey de feedback de onboarding

1.12 📝 Template: Feedback Survey

Enviar después de 4-6 semanas:

Onboarding Feedback

1. En escala 1-5, ¿qué tan preparado te sentiste el día 1?
2. ¿Qué parte del onboarding fue más útil?
3. ¿Qué mejorarías del proceso?
4. ¿Tu buddy fue efectivo? ¿Por qué sí/no?
5. ¿Cuánto tiempo te tomó sentirte productivo?
6. ¿Algo faltó que hubieras necesitado?
7. Comentarios adicionales

Usar feedback para iterar proceso.

1.13 🌟 Onboarding Remoto

Desafíos extra:

• Menos interacciones casuales
• Difícil leer ambiente/cultura
• Setup puede ser más complejo

Soluciones:

1.14 📚 Recursos

• GitLab's Remote Onboarding
• The Missing README - Chapter on Onboarding
• First 90 Days - Michael Watkins