Cambiar de empresa cada 2 años te está frenando como dev

La cultura del salto perpetuo

En la industria tech se volvió casi religión cambiar de empresa cada dos años. El argumento es siempre el mismo: mejor sueldo, nueva tecnología, más crecimiento. Y sí, en el corto plazo tiene sentido. Pero hay un costo oculto que pocos devs calculan.

Cuando saltás constantemente, nunca llegás a ver las consecuencias reales de tus decisiones técnicas. No ves cómo envejece tu código, cómo escala (o no) tu arquitectura, qué pasa cuando el sistema que diseñaste tiene que soportar 10x más tráfico.

Los problemas complejos necesitan tiempo

Los problemas técnicos realmente interesantes no se resuelven en sprints de dos semanas. Se resuelven en meses o años de iteración, observación y refinamiento.

Pensá en estos escenarios:

• Optimización de performance: Identificar qué queries de base de datos se vuelven lentas cuando tenés millones de registros
• Arquitectura que escala: Ver cómo tu microservicio se comporta cuando otros equipos empiezan a usarlo de formas que no anticipaste
• Debugging de prod: Encontrar esos bugs sutiles que aparecen solo con datos reales y años de uso
• Refactoring estratégico: Cambiar gradualmente un sistema crítico sin romper nada

Estas experiencias no las tenés en tu primer año en una empresa. Las tenés cuando llevás tiempo suficiente para ver la evolución completa.

La diferencia entre usar y entender

Cuando cambiás seguido, aprendés a usar herramientas y frameworks. Pero no aprendés por qué existen, qué problemas resuelven realmente, cuándo usarlos y cuándo evitarlos.

// Esto lo sabés hacer en cualquier lugar
const data = await fetch('/api/users')
  .then(response => response.json())

// Esto solo lo entendés después de mantener APIs por años
// ¿Qué pasa si esta llamada falla?
// ¿Cómo manejo timeouts?
// ¿Qué hago con datos inconsistentes?
// ¿Cómo debugging cuando algo anda mal en producción?

La diferencia entre un dev junior y uno senior no está en conocer más frameworks. Está en haber visto suficientes proyectos fallar para anticipar dónde van a surgir problemas.

El mito de la tecnología nueva

"En mi nueva empresa usan React 18, GraphQL y Kubernetes." Genial. Pero, ¿sabés por qué eligieron esa stack? ¿Entendés qué problemas resolvía el sistema anterior? ¿Podés comparar trade-offs reales?

Cuando saltás constantemente, siempre estás en modo "aprender la nueva stack". Nunca llegás a la fase donde realmente dominás las herramientas y podés tomar decisiones arquitectónicas informadas.

Además, la mayoría de las "tecnologías nuevas" que vas a encontrar son variaciones de cosas que ya existen. El valor real está en entender los conceptos subyacentes, no en conocer la sintaxis de turno.

Señales de que estás creciendo de verdad

Estas cosas solo pasan cuando te quedás el tiempo suficiente:

• Ownership real: Ser responsable de un sistema desde la concepción hasta el mantenimiento a largo plazo
• Mentoría: Ayudar a otros devs a evitar errores que vos ya cometiste
• Decisiones de arquitectura: Tomar decisiones técnicas importantes y vivir con las consecuencias
• Debugging avanzado: Resolver problemas que requieren conocimiento profundo del sistema
• Optimización: Hacer mejoras que requieren entender el contexto completo

Cuándo sí vale la pena cambiar

No estoy diciendo que nunca cambies. Hay situaciones donde saltar es la decisión correcta:

• Estancamiento técnico: Si tu empresa usa tecnología obsoleta y no hay planes de actualización
• Falta de desafíos: Si ya dominaste tu rol y no hay oportunidades de crecimiento
• Problemas culturales: Ambiente tóxico, micromanagement, falta de autonomía
• Diferencia salarial significativa: Si la brecha es muy grande y tu empresa actual no puede competir

Pero si cambiás solo porque "ya pasaron dos años" o porque querés probar la tecnología nueva, probablemente te estés frenando.

La ventaja competitiva de quedarse

Los devs que se quedan 3-5 años en una empresa desarrollan algo que no se puede conseguir saltando: contexto profundo. Conocen la historia de las decisiones, entienden por qué las cosas son como son, pueden hacer cambios informados.

Este conocimiento es extremadamente valioso. Las empresas lo saben y lo pagan bien. Un dev que entiende profundamente el negocio y la tecnología vale mucho más que alguien que sabe usar el framework de moda.

Construir una carrera sostenible

La carrera de un dev no es una colección de tecnologías en el CV. Es la capacidad de resolver problemas complejos, tomar buenas decisiones técnicas y construir sistemas que funcionen a largo plazo.

Esas habilidades se desarrollan con tiempo y experiencia. No con saltos constantes.

Si estás pensando en cambiar de empresa, hacete estas preguntas:

• ¿Ya dominé los desafíos de mi rol actual?
• ¿Entiendo profundamente cómo funciona nuestro sistema?
• ¿Puedo anticipar y prevenir problemas antes de que ocurran?
• ¿Hay oportunidades reales de crecimiento donde estoy?

Si la respuesta a las primeras tres es no, tal vez valga la pena quedarse un poco más.

Preguntas frecuentes

¿No me voy a quedar atrás técnicamente si no cambio seguido?

No necesariamente. Podés aprender nuevas tecnologías en tu empresa actual, en proyectos personales, o en capacitaciones. Lo importante es la profundidad, no la variedad superficial.

¿Qué pasa si mi empresa no me aumenta el sueldo?

Ese es un problema real. Pero antes de saltar, intentá negociar. Un dev con conocimiento profundo del sistema tiene leverage. Si aún así no funciona, ahí sí considerá cambiar.

¿Cuánto tiempo es "suficiente" en una empresa?

No hay una regla fija, pero generalmente necesitás al menos 2-3 años para ver un ciclo completo de desarrollo, deployment y mantenimiento. Para problemas realmente complejos, pueden ser 4-5 años.