Estamos entrando en una etapa donde parecer senior empieza a importar más que pensar como uno

A medida que voy creciendo en el mundo del desarrollo, y claro, cuanto más crece el ecosistema, empiezo a ver algo que se vuelve cada vez más evidente.

Parece que estamos entrando en una etapa donde, muchas veces, parecer avanzado técnicamente empieza a tener más peso que pensar con madurez técnica real. Y no hablo de ego. Ni de desarrolladores queriendo “hacerse los seniors”. Tampoco de una crítica fácil a juniors.

Creo que el problema es más profundo.

Me explico: Estamos en una industria donde cada vez hay más herramientas, más contenido técnico, más automatización, más frameworks, más inteligencia artificial y más exposición constante a decisiones que, hace algunos años, probablemente aparecían mucho más adelante en una carrera profesional.

Hoy un desarrollador recién arrancando puede leer sobre microservicios, Kubernetes, CQRS, DDD, event-driven architecture, sistemas distribuídos, observabilidad o escalabilidad, incluso antes de haber pasado suficiente tiempo entendiendo bugs reales, siguiendo trazas, leyendo código legacy o intentando comprender por qué un sistema aparentemente simple se rompe por una dependencia lateral que nadie vio venir.

Eso no es necesariamente malo, pero sí puede generar una presión silenciosa bastante peligrosa.

Porque en el medio de tanta exposición técnica, empieza a instalarse una idea sutil: que crecer profesionalmente también implica verse avanzado.

Y no, no tiene por qué ser así.

El seniority empezó a volverse visual

Tiempo atrás, cuando uno pensaba en alguien realmente senior, lo asociaba más con ciertas capacidades difíciles de fingir. Y no me refiero a una herramienta puntual ni a un framework de moda. Hasta te diría que tampoco con una arquitectura sofisticada.

Sino con cosas bastante menos vistosas.

Notábamos una capacidad para tomar decisiones con criterio. Veíamos que entendía de trade-offs, que diseñaba soluciones razonables. Si había que trackear problemas, encontraba fácil la causa raíz. Podía leer (y entender) un sistema completo y saber cuándo y cómo simplificarlo. Eso sigue siendo seniority, pero hoy, la percepción externa cambió.

Ser senior visualmente parece verse como otra cosa: Hablar de Kafka, de Kubernetes, de Redis, de escalabilidad, de arquitectura distribuida, de CQRS, de patrones avanzados.

Y aclaro algo importante: ninguna de esas herramientas o conceptos es el problema.

El problema aparece cuando el lenguaje técnico empieza a reemplazar el pensamiento técnico. Cuando empezamos a admirar complejidad antes de preguntarnos si esa complejidad era necesaria.

Eso, para mí, es una señal bastante fuerte de algo que está cambiando en la cultura de desarrollo de software.

La ansiedad silenciosa de “ya debería saber esto”

Todo eso, hace que para los perfiles que recién están comenzando, se genere una sensación de incomodidad grande, una presión silenciosa, y en el equipo no se habla de esto.

Sin embargo, si prestamos atención, estas cosas aparecen y se externalizan camufladas. Están en frases que uno escucha seguido:

“Todavía me cuesta entender arquitectura.”

“No entiendo muy bien cloud.”

“No sé si debería entender mejor system design.”

“Me sigue costando seguir trazas en sistemas grandes.”

“No termino de entender bien ciertos flujos.”

“Uso IA para destrabarme demasiado.”

“No sé si ya debería saber esto.”

Y muchas veces eso no nace de falta de capacidad, sino de comparación.

Hoy un desarrollador no solo compara su trabajo con su equipo. También compara su crecimiento con las cosas que lee en portales como Linkedin, en los threads de conversaciones, en roadmaps que cualquiera comparte, opiniones, etc.

Entonces aparece una presión rara. Si crecer lleva tiempo, parecer que creciste empieza a sentirse como una forma de compensarlo. Y ahí nace una ansiedad bastante peligrosa.

Cuando confundimos complejidad con madurez

Una de las cosas que más veo en equipos o proyectos es una asociación implícita que casi nunca se dice, pero muchas veces se actúa.

“Si es complejo, debe ser más profesional.”

“Si tiene muchas capas, debe estar mejor diseñado.”

“Si usa más infraestructura, debe escalar mejor.”

“Si suena más sofisticado, debe ser más senior.”

Y eso, primero que no tiene por qué ser así, y encima, puede empujar malas decisiones.

Se empiezan a meter patrones antes de necesitarlos. Factory, Strategy, CQRS, DDD, capas innecesarias, abstracciones tempranas, interfaces para absolutamente todo, wrappers sobre wrappers, separación excesiva de responsabilidades incluso cuando el problema todavía es pequeño.

O aparece infraestructura por prestigio.

Kafka, orquestación, colas, servicios fragmentados, despliegues complejos, Kubernetes, caches distribuidas o diseños hiper desacoplados en productos que todavía podrían vivir perfectamente con una arquitectura mucho más simple.

El resultado no siempre es escalabilidad, a veces es todo lo que se quiso evitar, un desastre súper complejo que nadie entiende.

Y, ¿Sabés qué? Complejidad sin necesidad suele terminar en:

• más deuda técnica,
• más debugging difícil,
• más onboarding lento,
• más puntos de falla,
• menos claridad.

Hay una idea que cada vez me parece más cierta:

puede empujar malas decisiones. Diseñar algo complejo puede impresionar. Diseñar algo simple suele requerir más seniority.

Porque simplificar exige criterio, no solo conocimiento. Y eso se gana con la experiencia.

La IA aceleró otra ilusión: producir no siempre es comprender

No descubro nada al decir que la llegada de la IA en desarrollo de software cambió todo, muchas cosas para bien, claro.

Sí, generamos boilerplate más rápido, ni hablar de pedir ayuda para tests, o resolver estructuras repetitivas. También para entender errores más rápido, pedir refactors, probar ideas, entre otros.

Eso es valioso, pero la moneda tiene dos caras, y del otro lado, también apareció otra ilusión bastante sutíl.

Es posible producir mucho código sin necesariamente consolidar comprensión profunda. Código que funciona pero no se entiende. Fixes que cierran tickets pero no resuelven la causa raíz del problema. Refactors que “limpian” pero no consideran dependencias.

La velocidad puede ocultar vacíos de criterio. Y eso no es un problema de la IA. Es un problema de cómo usamos la herramienta.

Porque una respuesta rápida no reemplaza pensamiento técnico, y productividad no siempre significa madurez.

Nunca fue tan fácil producir código. Y, a la vez, nunca fue tan fácil esconder vacíos de comprensión detrás de velocidad.

Entonces, ¿qué empieza a parecer realmente senior?

Con el tiempo, cada vez me convenzo más de que el seniority real no siempre se nota en lo que alguien menciona, sino en cómo piensa.

Un desarrollador empieza a madurar mucho cuando puede entender trade-offs, no solo tecnologías.

Cuando deja de preguntar únicamente “¿qué herramienta usamos?” y empieza a preguntarse “¿qué costo trae esta decisión?”.

Cuando puede leer un sistema completo.

Cuando entiende que arquitectura no siempre significa agregar piezas, sino muchas veces reducirlas.

Cuando puede debuggear profundo y buscar causa raíz en lugar de aplicar parches rápidos.

Cuando puede simplificar algo sin romperlo.

Cuando entiende impacto técnico y también impacto de negocio.

Y algo que muchas veces se subestima: cuando puede enseñar sin inflar complejidad para parecer más importante.

Eso, para mí, es pensamiento senior. No necesariamente sonar más técnico, sino pensar con más profundidad.

Tal vez el problema no son los desarrolladores. Tal vez es lo que estamos premiando.

No creo que hoy estemos formando developers menos capaces. Creo que estamos formando desarrolladores dentro de un ecosistema que muchas veces premia:

• visibilidad antes que profundidad,
• velocidad antes que comprensión,
• complejidad antes que criterio,
• apariencia técnica antes que madurez técnica.

Y eso inevitablemente genera ansiedad. La ansiedad de querer sonar más sólido de lo que todavía uno tuvo tiempo de construir.

Tal vez crecer técnicamente nunca fue una carrera por hablar más complejo.

Tal vez el verdadero crecimiento empieza cuando dejamos de preocuparnos tanto por parecer senior… y empezamos a construir el tipo de criterio que, con el tiempo, hace que uno realmente piense como uno.