Ser senior no es saber más frameworks: es romper menos cosas

Durante mucho tiempo pensé que ser mejor developer era saber más cosas.

Más frameworks.

Más patrones.

Más herramientas.

Más servicios cloud.

Más comandos.

Más siglas.

Y sí, aprender importa.

Pero cada vez tengo más claro que ser senior no va de acumular tecnologías.

Va de otra cosa mucho menos vistosa:

romper menos cosas.

No porque no toques nada.

No porque tengas miedo.

Sino porque entiendes mejor el impacto de lo que tocas.

El senior no es el que escribe más rápido#

Escribir código rápido está bien.

Pero en proyectos reales casi nunca gana quien escribe más líneas.

Gana quien entiende:

• qué problema hay que resolver
• qué no conviene tocar
• qué impacto tiene un cambio
• qué partes dependen de esa decisión
• qué puede romperse en producción
• qué necesita pruebas
• qué debe documentarse
• qué debe esperar

Un junior suele preguntar:

> ¿cómo lo implemento?

Un perfil más senior debería preguntar también:

> ¿deberíamos implementarlo así?

Esa diferencia parece pequeña, pero cambia mucho.

Saber decir “espera” también es técnica#

A veces el mejor aporte técnico no es escribir código.

Es frenar.

No por bloquear.

No por miedo.

Sino por entender que hay cambios que parecen pequeños y no lo son.

Ejemplos:

• tocar autenticación
• cambiar permisos
• modificar contratos de API
• actualizar dependencias críticas
• cambiar una migración
• tocar DNS
• modificar pagos
• mover lógica compartida
• borrar código “que parece muerto”

Hay cambios que necesitan plan.

Hay cambios que necesitan pruebas.

Hay cambios que necesitan rollback.

Y hay cambios que directamente no compensan.

El senior piensa en producción#

En local casi todo parece más fácil.

No hay usuarios.

No hay datos raros.

No hay concurrencia.

No hay tráfico.

No hay horarios.

No hay clientes esperando.

Producción es otra película.

Un cambio aparentemente inocente puede afectar a:

• formularios
• emails
• sesiones
• caché
• colas
• permisos
• integraciones externas
• SEO
• rendimiento
• logs
• monitorización

Por eso ser senior no es solo saber hacer que algo funcione.

Es saber qué puede pasar cuando funciona fuera de tu máquina.

Menos ego, más contexto#

Una señal de madurez técnica es dejar de necesitar demostrar que sabes.

No hace falta reescribir todo.

No hace falta meter la última librería.

No hace falta cambiar una arquitectura entera para demostrar criterio.

A veces lo mejor es:

• entender el sistema actual
• mejorar una parte pequeña
• dejar tests
• documentar una decisión
• reducir riesgo
• no introducir complejidad innecesaria

El ego quiere dejar huella.

El criterio quiere dejar el sistema mejor de lo que estaba.

El código legacy enseña mucho#

Trabajar con legacy puede ser frustrante.

Pero también enseña una lección importante:

el código que está ahí sobrevivió.

Puede estar feo.

Puede estar acoplado.

Puede tener nombres horribles.

Puede no tener tests.

Pero probablemente lleva años resolviendo un problema real.

Llamarlo basura es fácil.

Entender por qué existe requiere más oficio.

Antes de cambiar un sistema legacy, conviene preguntar:

• qué problema resolvía
• quién lo usa
• qué dependencias tiene
• qué datos toca
• qué reglas de negocio esconde
• qué pasaría si falla
• qué parte podemos cubrir con tests antes de tocar

Eso también es ser senior.

Revisar código no es buscar culpables#

Una revisión de código buena no debería ser una demostración de superioridad.

Debería ser una forma de proteger el proyecto.

Un buen review mira:

• claridad
• impacto
• seguridad
• rendimiento
• consistencia
• mantenibilidad
• pruebas
• posibles efectos secundarios

Y también cuida el tono.

Porque el objetivo no es que alguien se sienta pequeño.

El objetivo es que el código llegue mejor a producción.

La experiencia también se nota en lo que no haces#

Con los años aprendes que no todo problema necesita:

• una nueva dependencia
• un nuevo patrón
• una nueva abstracción
• un microservicio
• una cola
• IA
• event sourcing
• Kubernetes
• una migración masiva

A veces basta con una función clara.

O una query mejor.

O un índice.

O un formulario bien validado.

O una alerta.

O una página mejor escrita.

La experiencia te ayuda a no sobredimensionar soluciones.

Ser senior también es hacer fácil el trabajo de otros#

Un buen developer no solo resuelve su tarea.

También deja el camino más claro para quien viene después.

Eso puede ser:

• un README útil
• un test que explica un caso raro
• un nombre mejor
• una decisión documentada
• un error más claro
• un log que ayuda
• una migración reversible
• un PR pequeño
• una explicación honesta

Muchas veces eso vale más que una solución brillante que nadie entiende.

Checklist personal#

Si tuviera que resumirlo, para mí ser senior se parece más a esto:

• [ ] preguntar antes de tocar zonas críticas
• [ ] entender impacto antes de implementar
• [ ] separar análisis de ejecución
• [ ] escribir menos código si resuelve igual
• [ ] proteger producción
• [ ] documentar decisiones importantes
• [ ] revisar con respeto
• [ ] no meter complejidad por ego
• [ ] saber decir “no lo sé”
• [ ] dejar el sistema un poco mejor

Conclusión#

Ser senior no es saber más frameworks.

Tampoco es tener más años en LinkedIn.

Ni escribir más rápido.

Ni opinar más fuerte.

Para mí, ser senior es entender que el código vive dentro de un sistema.

Un sistema con usuarios, negocio, datos, errores, mantenimiento, equipo y producción.

Y cuanto más entiendes eso, menos necesidad tienes de demostrar.

Simplemente intentas romper menos cosas.

Y dejar mejores decisiones detrás.