El mito del senior técnicamente perfecto
Cuando era junior, pensaba que ser senior significaba saber más tecnologías, escribir código más elegante, y resolver problemas más rápido. Después de años en la industria, descubrí que eso es solo una parte pequeña de la ecuación.
Los mejores seniors que he conocido no son necesariamente los que más saben técnicamente. Son los que hacen que los proyectos avancen, que los equipos funcionen mejor, y que los problemas se resuelvan antes de convertirse en crisis.
Comunicación: la habilidad más subestimada
Saber decir "no sé"
Un junior intenta parecer que sabe todo. Un senior dice "no sé, pero lo investigo y te cuento". La diferencia es enorme.
Admitir que no sabes algo:
- Evita que tomes decisiones basadas en suposiciones
- Abre la puerta a que otros aporten su conocimiento
- Genera confianza porque demuestra honestidad
Explicar lo técnico a no técnicos
Puedes ser el mejor desarrollador del mundo, pero si no puedes explicarle al product manager por qué algo va a tomar dos semanas en lugar de dos días, vas a tener problemas.
La habilidad de traducir complejidad técnica a impacto de negocio es lo que te hace valioso en reuniones de planificación, conversaciones con clientes, y decisiones de producto.
Escribir bien
Documentación, mensajes de Slack, PRs, emails. Un senior pasa gran parte de su día escribiendo. Si tus mensajes son confusos, generas trabajo extra para todos.
Escribir claro significa:
- Ir al punto rápido
- Estructurar la información
- Anticipar las preguntas que van a surgir
- Proponer soluciones, no solo describir problemas
Ownership: hacerte responsable de verdad
El junior termina tareas, el senior termina proyectos
Un junior hace lo que le piden. Un senior se asegura de que lo que se pidió realmente resuelva el problema.
Esto significa:
- Cuestionar requerimientos que no tienen sentido
- Pensar en edge cases antes de que alguien los mencione
- Hacer seguimiento después del deploy para verificar que funciona en producción
- Avisar proactivamente si algo se va a atrasar
Cuando algo falla, no buscar culpables
"El backend me mandó datos mal" es una respuesta de junior. "Debí haber validado esos datos en el frontend, voy a agregar esa validación" es una respuesta de senior.
No se trata de echarte la culpa de todo. Se trata de enfocarte en soluciones en lugar de excusas.
El código no es tuyo, es del equipo
A los juniors les cuesta que otros modifiquen "su" código. Los seniors entienden que el código es del equipo, y que si alguien lo puede mejorar, bienvenido sea.
Esto también significa escribir código que otros puedan entender. El código clever que solo tú entiendes no es buen código.
Toma de decisiones: vivir con la incertidumbre
Nunca vas a tener toda la información
Los juniors quieren especificaciones perfectas antes de escribir una línea de código. Los seniors entienden que eso casi nunca existe.
Aprender a tomar decisiones con información incompleta es fundamental. Esto incluye:
- Identificar qué información es crítica y cuál es nice-to-have
- Saber cuándo una decisión es reversible y cuándo no
- Avanzar con supuestos documentados cuando es necesario
Las decisiones reversibles no necesitan ser perfectas
¿Qué librería de componentes usar? ¿Cómo nombrar esta función? ¿Dónde poner este archivo?
Estas son decisiones reversibles. No pierdas horas debatiendo. Decide, avanza, y si después resulta que había una mejor opción, cambias.
Las decisiones irreversibles (arquitectura fundamental, elección de base de datos, contratos de API públicos) sí merecen más análisis.
Aprender a decir "depende"
Los juniors quieren respuestas absolutas. "¿React o Vue?" "¿Microservicios o monolito?" "¿SQL o NoSQL?"
La respuesta senior es siempre "depende". Depende del contexto, del equipo, de los requerimientos, del timeline. La habilidad está en saber de qué depende y hacer las preguntas correctas.
El meta-skill: saber cuándo aplicar qué
Quizás lo más difícil de ser senior es saber cuándo aplicar cada habilidad.
- ¿Cuándo insistir en hacer las cosas bien vs cuándo entregar rápido?
- ¿Cuándo documentar todo vs cuándo el código se explica solo?
- ¿Cuándo escalar un problema vs cuándo resolverlo solo?
- ¿Cuándo refactorizar vs cuándo dejar la deuda técnica para después?
No hay respuestas universales. Lo que funciona en una startup de 5 personas no funciona en una empresa de 500. Lo que funciona en un MVP no funciona en un sistema crítico.
Cómo desarrollar estas habilidades
Busca feedback activamente
No esperes a tu review anual. Pregunta a tus compañeros: "¿Qué podría haber hecho mejor en ese proyecto?" La mayoría de la gente no da feedback honesto a menos que lo pidas explícitamente.
Observa a los seniors de tu equipo
No solo qué hacen técnicamente, sino cómo se comunican, cómo manejan conflictos, cómo toman decisiones. Mucho se aprende observando.
Sal de tu zona de comfort
Ofrécete para presentar en una reunión. Escribe documentación para algo que nadie entiende. Lidera un proyecto pequeño. Las habilidades blandas se desarrollan practicando, no leyendo sobre ellas.
Conclusión
Ser senior no es un título que alguien te da después de X años. Es una forma de trabajar que combina habilidades técnicas con comunicación, ownership y criterio para tomar decisiones.
Lo técnico se puede aprender en cursos y tutoriales. Estas otras habilidades solo se aprenden trabajando, fallando, y mejorando. Y la buena noticia es que puedes empezar a desarrollarlas desde el día uno, sin importar tu nivel.
