De junior a senior: lecciones que cambiaron cómo escribo código

El camino del que nadie habla

Cuando empecé mi carrera, pensaba que convertirme en ingeniero senior se trataba de aprender más frameworks y escribir más código. Siete años después, sé que los mayores saltos vinieron de cambiar cómo pienso sobre el software, no de las herramientas que uso.

Lección 1: La simplicidad es la habilidad más difícil

Yo junior amaba el código ingenioso. Yo senior elimina código ingenioso.

// What I wrote at year 1 — "look how smart I am"
const result = data.reduce(
  (a, b) => ({ ...a, [b.type]: [...(a[b.type] || []), b] }),
  {},
);
 
// What I write now — readable, debuggable, maintainable
const grouped = new Map<string, Item[]>();
for (const item of data) {
  const existing = grouped.get(item.type) ?? [];
  existing.push(item);
  grouped.set(item.type, existing);
}

La segunda versión es más larga, pero cualquier ingeniero puede entenderla en segundos. La primera requiere análisis mental cada vez que alguien la lee.

La regla: el código se lee 10 veces más de lo que se escribe. Optimiza para quien lo lee.

Lección 2: Entiende el problema antes de escribir código

Al principio de mi carrera, empezaba a codear en cuanto entendía el requerimiento. Ahora paso la mayor parte de mi tiempo en:

1. Entender el problema real — no solo qué pidieron, sino por qué
2. Explorar el espacio de soluciones — siempre hay varios enfoques
3. Identificar restricciones — plazos, sistemas existentes, habilidades del equipo
4. Escribir un breve documento de diseño — incluso 5 viñetas obligan a claridad

El código más rápido de entregar es el que no escribes. A veces la mejor solución es un cambio de configuración, una mejora de proceso o rechazar un requerimiento.

Lección 3: Los tests son sobre confianza, no cobertura

Antes me obsesionaba con el 100% de cobertura. Ahora escribo tests que me dan confianza para hacer deploy.

// ❌ Testing implementation details
test("calls setLoading before fetch", () => {
  // Brittle — breaks on any refactor
});
 
// ✅ Testing behavior
test("shows user profile after successful load", async () => {
  render(<UserProfile userId="123" />);
  expect(await screen.findByText("Jane Doe")).toBeInTheDocument();
  expect(screen.getByText("jane@example.com")).toBeInTheDocument();
});

Concéntrate en:

• Rutas críticas — checkout, autenticación, mutaciones de datos
• Casos límite que ya te mordieron antes — bugs de zonas horarias, estados vacíos, actualizaciones concurrentes
• Tests de integración sobre tests unitarios — testea los contratos entre sistemas, no funciones individuales

Lección 4: La comunicación es un multiplicador

La mayor sorpresa de mi carrera: la diferencia entre un buen ingeniero y uno genial es principalmente comunicación.

Cosas que aprendí a hacer:

• Escribir descripciones de PR claras — explica el por qué, no solo el qué
• Documentar decisiones, no solo código — el tú del futuro agradecerá al tú del presente
• Plantear preocupaciones temprano — "Creo que este plazo es arriesgado porque..." es más valioso que entregar tarde
• Pedir ayuda — los mejores ingenieros que conozco hacen más preguntas

Un ingeniero senior que escribe código promedio pero comunica brillantemente entrega más valor que un genio que trabaja aislado.

Lección 5: Apodérate del sistema, no solo de tu código

Los ingenieros junior arreglan bugs. Los ingenieros senior arreglan los sistemas que crean bugs.

Cuando algo se rompe, me pregunto:

• ¿Por qué este bug llegó a producción?
• ¿Qué cambio de proceso o herramienta evitaría esta clase de bug?
• ¿Es suficiente nuestro monitoreo para detectar esto antes?

Esto puede significar configurar mejores reglas de linting, agregar un chequeo pre-commit, mejorar pipelines de CI/CD o crear un runbook para incidentes comunes. El objetivo es hacer que el equipo sea más rápido, no solo tú.

Lección 6: La deuda técnica es una decisión de negocio

No toda la deuda técnica es mala. Algunas son intencionales — lanzar rápido para validar una idea antes de invertir en una solución perfecta. La habilidad está en reconocer:

• Deuda intencional — documentada, con plazo, con un plan para resolverla
• Deuda accidental — acumulada por atajos que nadie registró
• Bit rot — código que alguna vez fue bueno pero no se mantuvo al día con los requisitos cambiantes

Cuando propongo un refactor ahora, lo enmarco en términos de negocio: "Esto reducirá nuestro tiempo de despliegue de 45 minutos a 8 minutos, desbloqueando al equipo para lanzar tres releases por día en lugar de uno."

Lección 7: Mentorizar te hace mejor

Enseñar te obliga a entender las cosas a un nivel más profundo. Cada vez que explico un concepto a un ingeniero junior, encuentro huecos en mi propio entendimiento.

Formas concretas en las que mentorizo:

• Pair programming — no dar clases, sino pensar en voz alta juntos
• Code review como enseñanza — explica el por qué detrás de las sugerencias
• Crear espacios seguros para fallar — dejar que los juniors asuman proyectos desafiantes con redes de seguridad

Los mejores equipos en los que he estado tenían una cultura donde todos enseñan y todos aprenden, sin importar el título.

Lo que le diría a mi yo junior

1. Lee más código del que escribes — estudia cómo los grandes ingenieros resuelven problemas
2. Invierte en fundamentos — estructuras de datos, redes y conceptos de SO se acumulan para siempre
3. Construye cosas fuera del trabajo — los side projects te enseñan lo que el trabajo enterprise no puede
4. Encuentra un mentor temprano — una conversación puede ahorrarte meses de ensayo y error
5. Ten paciencia — la maestría se mide en años, no en sprints

El viaje de junior a senior no es una línea recta. Es una serie de cambios de mentalidad, cada uno abriendo una nueva forma de pensar sobre el software y los equipos. Abraza la incomodidad de no saber — ahí es donde ocurre el crecimiento.