Pocas cosas generan más debate en una comunidad técnica que intentar definir qué significa ser junior, senior o experto. Bueno, quizás si un MERGE en producción está justificado… pero eso es otro tema del que ya hablaremos. Hoy vamos a hablar de galones o etiquetas, como queráis llamarlo, de cómo se reparten sin criterio y de por qué seguimos viendo ofertas para “junior con 3 años de experiencia” como si eso tuviera sentido alguno. Y es que para mí no lo tiene.
Junior no es sinónimo de becario
Vamos al grano. Un perfil junior no es alguien que no sepa nada. Es alguien que está empezando, sí, pero con una base ya formada, aunque sea mínima. No es un becario que necesita que le expliquen qué es un JOIN, pero tampoco es alguien que se siente cómodo optimizando una consulta compleja en un entorno con 3.000 conexiones simultáneas.
El problema es que muchas empresas confunden junior con “alguien barato que haga lo que un senior, pero por la mitad del sueldo”. Ahí vienen esas ofertas delirantes que piden de 1 a 3 años de experiencia, conocimiento de media docena de tecnologías, disponibilidad 24/7 y espíritu “proactivo”. Y todo eso, claro, a cambio de un salario que apenas supera al de prácticas. La trampa es evidente: quieren que hagas de todo, cobres poco y no te quejes. Si encima sonríes, mejor.
Pongamos un ejemplo concreto en nuestro terreno. El junior DBA es el encargado de realizar tareas totalmente procedimentadas sin salirse del guión. No se le puede exigir más. Es el que aún lanza un BACKUP DATABASE desde Management Studio, feliz de ver el mensaje de éxito, sin pensar en restaurarlo después para comprobar que realmente sirve. Y cuando falla, su primera reacción es: “pero si la copia terminó sin errores”. Es normal, es parte del camino, pero ahí está la diferencia.
Y ojo, no es que tener 2 o 3 años de experiencia te haga automáticamente senior. Ni mucho menos. Pero llamar junior a alguien que lleva 3 años comiéndose marrones de producción es no entender nada.
Senior no es el junior que lleva más tiempo
La etiqueta de senior se ha convertido en una medalla que muchos se cuelgan demasiado pronto. Como si el calendario fuera el único juez válido. Y no. Ser senior implica haber visto cosas. Muchas cosas. Implica haber roto entornos, haberlos arreglado, haber tomado decisiones técnicas difíciles y haber lidiado con sus consecuencias. Ser capaz de evaluar el coste de una mala decisión antes de que reviente todo un domingo a las 3AM.
Un ejemplo de DBA senior: sabe que hacer un BACKUP no es suficiente, que hay que automatizar la validación de restauraciones, que conviene pensar en RPO y RTO antes de que el CTO lo pregunte, y que poner todos los backups en la misma SAN que la base de datos es tan útil como poner un extintor dentro del fuego. Además, cuando revisa un plan de ejecución, no se queda en el dibujito bonito: entiende qué decisiones está tomando el optimizador y sabe cuándo necesita una intervención manual.
No necesariamente dará la solución más elegante, pero sí una que funcione, que no comprometa la seguridad y que no mate el rendimiento del sistema. Porque un senior de verdad no solo sabe lo que hace, sino por qué lo hace. Y lo más importante: también sabe cuándo no hacerlo.
Las horas que se cuentan (o no se cuentan)
Aquí entra uno de los mitos más persistentes del sector: las dichosas 5.000 horas para ser senior, y las 10.000 para ser experto. Un concepto que hemos heredado casi como dogma y que muchos repiten como si fuera una verdad revelada. La famosa teoría de la práctica deliberada que, si alguna vez tuvo sentido en el contexto del violín o el ajedrez, se ha degenerado por completo en el mundo técnico.
Porque no, no basta con acumular horas para ser mejor. Si tu jornada consiste en encender el PC, abrir Management Studio y hacer lo mismo que hiciste ayer, anteayer y hace dos años, entonces lo que estás sumando no son horas de experiencia, sino horas de repetición. Y eso no te convierte en senior. Te convierte en alguien que sabe repetir procesos.
La práctica solo te lleva a la maestría cuando es desafiante, consciente y dirigida a mejorar. Si no hay errores, reflexión y aprendizaje, da igual cuántas horas pongas: seguirás en el mismo punto. He visto gente con 2.000 horas de trabajo real, bien guiado, bien sufrido y bien reflexionado, que vale más que otros con 15.000 horas de pulsar “Next” en el asistente de instalación.
Así que si alguien te dice que ya ha superado las 10.000 horas y por tanto es experto, pregúntale si puede explicarte qué hace exactamente el Cardinality Estimator en SQL Server o cómo se comporta el Query Store bajo una carga de lectura intensiva. Si pone cara de “eso no lo he tocado”, ya tienes la respuesta.
El mito del experto
Y luego están los expertos. Esa palabra maldita que ha perdido su valor en LinkedIn. Todo el mundo es “experto” en algo. Hay quienes se autodefinen expertos en SQL Server por haber creado 4 procedimientos almacenados, un par de vistas y haber leído la documentación de sp_whoisactive.
Aquí conviene diferenciar. Un experto funcional puede ser brillante operando un entorno concreto: conoce de memoria las rutinas de mantenimiento, maneja la seguridad de usuarios sin pestañear, y sabe cómo lidiar con el sistema en el día a día. Pero un experto técnico va un paso más allá: entiende las tripas, cómo funciona realmente el optimizador de consultas, cómo afectan las estadísticas al plan de ejecución, o por qué tu índice columnstore se viene abajo con ese patrón de inserción masiva.
Ambos perfiles son valiosos, pero no son lo mismo. Y lo que más abunda son los que creen que ser expertos funcionales les convierte en gurús universales. Y no es así.
Un experto de verdad también sabe cuándo callarse y escuchar. Porque cuanto más sabes, más consciente eres de lo que te queda por aprender. Así de simple.
¿Y los niveles intermedios?
Esto es algo que muchas organizaciones siguen sin entender. No todo el mundo entra en la categoría binaria de junior o senior. Hay una progresión natural, pero parece que da miedo nombrarla. Habría que hablar más de perfiles middle, semi-senior, advanced junior o como demonios queramos llamarlos, pero con definiciones claras y expectativas razonables.
Piénsalo en términos prácticos: un middle DBA ya ha gestionado despliegues, se ha peleado con deadlocks y sabe cómo monitorizar correctamente el entorno. No es alguien a quien quieras dejar al mando de una arquitectura distribuida en microservicios con réplicas en 4 regiones de Azure, pero tampoco es el novato que lanza un TRUNCATE en producción sin comprobar antes si hay backup.
La falta de estas categorías intermedias genera frustración. Los juniors que progresan se sienten estancados, y los seniors reales se queman porque tienen que apagar fuegos sin ayuda suficiente. Así que sí, necesitamos más niveles, pero sobre todo, más claridad y menos ego en las etiquetas.
La falacia de la experiencia acumulada
Este es otro punto clave. Tener 5 años de experiencia no significa nada si has pasado esos 5 años repitiendo el mismo trabajo que hacías el primer mes. Lo que tienes entonces no son 5 años de experiencia, sino 1 mes de experiencia repetido 60 veces. Y eso, lo siento, no es lo mismo.
La experiencia que cuenta es la que desafía, la que te obliga a aprender algo nuevo, a tomar decisiones, a equivocarte y mejorar. Si tu trabajo durante años ha sido ejecutar tareas repetitivas en una base de datos que ni siquiera entiendes, difícilmente puedes reclamar el título de senior.
Y sí, esto pasa más de lo que creemos. Entornos donde la innovación técnica es nula, donde todo se hace igual “porque siempre ha funcionado”, y donde el único cambio en cinco años ha sido cambiar de proveedor de café. Luego llega alguien con 2 años en un entorno exigente y en 6 meses demuestra más criterio que tú. Duele, pero es real.
Entonces, ¿cómo se pasa de junior a senior, y de senior a experto?
Pasar de junior a senior requiere algo más que cumplir con lo que te encargan durante mucho tiempo. Hacer backups, monitorizar jobs o ejecutar scripts que te da otro está bien, pero no es suficiente. El salto se produce cuando empiezas a cuestionar lo que haces, a entender por qué se hace de una manera y no de otra, y a proponer alternativas. Un junior ejecuta. Un senior piensa y decide. Ese cambio de chip no viene solo con las horas, viene con iniciativa y curiosidad técnica.
Si eres junior, ten iniciativa. Pégate a los senior y a los expertos, y que te expliquen lo que hacen y por qué. Cuando escales una incidencia, pregunta si puedes participar en la solución. No siempre la carga de trabajo lo va a permitir, pero cuando se pueda, la mayoría de los buenos profesionales estarán encantados de explicarte las cosas. Y créeme: no tengas miedo a preguntar. Nadie que merezca la pena tiene miedo a que aprendas y le quites el trabajo. Al contrario: queremos que mejores para que puedas hacer más cosas tú, y nosotros podamos vivir mejor. Porque un equipo fuerte se construye compartiendo, no guardando secretos como si fueran recetas de la abuela.
Luego está el paso de senior a experto. Aquí la cosa se complica, porque ya no se trata solo de resolver problemas en tu día a día, sino de anticiparlos. El experto sabe detectar patrones, entender tendencias y diseñar sistemas para que el fuego no llegue a prenderse. Y, además, sabe explicarlo a otros. Porque si no eres capaz de transmitir tu conocimiento, tu “expertise” se queda en ego. Un verdadero experto enseña, documenta, comparte. Ahí está parte de la diferencia.
¿Y hace falta dar un “extra” fuera del trabajo? Seamos claros: sí. Si te limitas a lo que ves en tu jornada laboral, avanzarás, pero despacio, muy despacio. El que llega más lejos es el que dedica tiempo a seguir estudiando, probando, rompiendo cosas en entornos de pruebas, leyendo papers, explorando novedades y enfrentándose a problemas que quizás no le toquen aún. La gente que crece es la que tiene curiosidad más allá de su checklist diario.
Ojo, tampoco se trata de romantizar las jornadas interminables de autoestudio como si fueran la única vía. No es sano ni sostenible trabajar 8 horas y estudiar otras 8. Pero la realidad es que los mejores profesionales que he conocido no apagaban el ordenador al terminar de trabajar y se olvidaban de todo. Seguían investigando, aunque fuera con un proyecto personal, un curso puntual o trasteando con la última versión de SQL Server en una máquina virtual.
Con todo esto, ¿qué valor tiene realmente una etiqueta?
La respuesta honesta es, depende de quién la use y para qué. Para muchos reclutadores es simplemente un filtro. Algunos managers se lo toman como una excusa para pagar menos. Para los técnicos, un arma de doble filo: puede abrirte puertas o hacer que te pidan milagros.
Pero hay algo que no cambia: los títulos no te salvan cuando el clúster se cae, cuando hay que restaurar un backup sin dormir o cuando el rendimiento se desploma sin motivo aparente. En esos momentos, solo cuenta lo que sabes hacer. Y lo que sabes transmitir.
Porque si algo he aprendido después de más de una década en este mundo, es que el respeto profesional no se gana con etiquetas, sino con hechos. Con decisiones acertadas bajo presión, con humildad para reconocer errores y, sobre todo, con ganas de seguir aprendiendo aunque tengas el CV lleno de palabras bonitas.
Y aquí viene la idea final: ser junior, senior o experto no es un estado fijo. Es un proceso continuo. Hoy puedes ser senior en SQL Server 2019, pero si dejas de aprender, mañana serás el que se quedó atascado en técnicas de hace una década. El mercado no espera a nadie, y el conocimiento tampoco.
Conclusión
Las etiquetas junior, senior y experto seguirán existiendo, pero lo importante es no tomárselas demasiado en serio. Sirven como orientación, sí, pero no son la verdad absoluta. Mucho menos en un sector donde el conocimiento evoluciona a la velocidad del rayo y donde lo que hoy dominas, mañana está obsoleto.
Así que, la próxima vez que alguien te diga que es senior porque ha superado las 5.000 horas, o experto por las 10.000, recuerda que también hay quien cree que el MERGE bien hecho existe. Nosotros no lo hemos visto. Pero tampoco hemos visto unicornios.
