RH
Article
(01)

Adiós al FOMO: Por qué dejé de perseguir cada nuevo framework

Roberto Hernando reflexiona sobre cómo superar el FOMO tecnológico y la ansiedad de aprender cada nuevo framework, recuperando la pasión por el código real.

Por
498 Vistas
productividadbienestardesarrollo-webcarrera-tecnicareflexionsoft-skills

¿Alguna vez habéis sentido que el mundo del desarrollo va más rápido que vuestro cerebro?

Seguro que os ha pasado. Os levantáis un martes cualquiera, abrís Twitter o vuestro lector de feeds favorito y, ¡pum!, tres nuevos frameworks de JavaScript han aparecido, dos librerías de estado que usabas ayer ahora están "deprecated" y parece que si no estás usando una base de datos vectorial con IA generativa para hacer un simple formulario de contacto, estás viviendo en el pleistoceno. Esa sensación tiene un nombre: FOMO (Fear Of Missing Out), y durante mucho tiempo, fue mi sombra constante.


No os voy a mentir, hubo una época en la que mi obsesión por "estar a la última" me consumía. Me pasaba los fines de semana haciendo tutoriales de cosas que ni siquiera necesitaba en mi trabajo diario, solo por el miedo a que, en una entrevista o en una charla de café, alguien mencionara una tecnología y yo no supiera de qué me estaba hablando. Me sentía como un hámster en una rueda infinita: corría cada vez más rápido, pero no llegaba a ninguna parte. Al final del día, estaba agotado, con la cabeza llena de sintaxis a medias y, lo peor de todo, había dejado de disfrutar de lo que más me gusta: programar.


La trampa de la novedad constante

Mi punto de inflexión llegó hace un par de años. Estaba intentando implementar una solución para un cliente utilizando el framework de moda de ese mes. Me pegué tres días peleándome con una documentación incompleta, errores de tipado extraños y una comunidad que aún no sabía ni cómo resolver los problemas básicos. Al cuarto día, frustrado y con el plazo de entrega acechando, decidí borrarlo todo y hacerlo con lo que ya sabía: JavaScript puro y un poquito de sentido común. ¿El resultado? Lo terminé en tres horas.


Ese día me di cuenta de algo fundamental que a veces olvidamos con tanto ruido: a nuestros clientes, jefes o usuarios finales les da exactamente igual si usamos el último compilador escrito en Rust o si nuestro CSS se genera de forma mágica en el servidor. Lo que les importa es que la aplicación funcione, sea rápida y resuelva su problema. Me sentí un poco tonto, la verdad. Había pasado meses intentando ser un "experto en todo" y me había olvidado de ser un "solucionador de problemas".


¿Por qué me parece importante parar este ritmo?

La salud mental en nuestra industria es un tema serio. El agotamiento o burnout no siempre viene por exceso de trabajo, a veces viene por esa presión invisible de sentir que tus conocimientos caducan cada seis meses. He visto a desarrolladores brillantes dejar la profesión porque sentían que nunca sabían lo suficiente. Es una carrera de fondo, no un sprint de 100 metros, y si intentas esprintar durante toda tu vida laboral, te vas a romper.


Además, hay una verdad incómoda que pocos dicen: la mayoría de estos "nuevos paradigmas" son conceptos antiguos con un nombre más moderno y un logo más bonito. Cuando dejas de obsesionarte con la superficie y empiezas a mirar los fundamentos, te das cuenta de que si entiendes bien cómo funciona el protocolo HTTP, cómo se gestiona la memoria o cómo estructurar una base de datos, el framework que elijas es, en gran medida, secundario.


Lo que he aprendido: De la ansiedad a la maestría

Ahora sigo una filosofía mucho más relajada que me ha devuelto la pasión por el código. Ya no intento aprenderlo todo "por si acaso". Ahora aplico lo que llamo el aprendizaje bajo demanda. ¿Que necesito hacer una app móvil y nunca he usado React Native? Pues me pongo con ello cuando surge el proyecto. Pero no voy a pasarme tres noches sin dormir aprendiendo las entrañas de una herramienta que quizás nunca use de forma profesional.


He vuelto a disfrutar de los fundamentos. Me he pasado meses profundizando en patrones de diseño y en arquitectura de software limpia. Y sabéis qué, eso me sirve para cualquier lenguaje. Es mucho más gratificante entender el porqué de las cosas que simplemente memorizar el cómo se escribe una función en el framework de turno. He recuperado el placer de "cacharrear" sin presión. Ahora, si pruebo algo nuevo, es por pura curiosidad intelectual, no por miedo a quedarme atrás.


// Antes mi mente era algo así:
while(newFrameworkReleased) {
  try {
    learn(everything);
    burnout++;
  } catch (anxiety) {
    stayUpLate();
  }
}

// Ahora es más productiva:
if (problemNeedsSolution) {
  const tool = selectBestTool(knowledgeBase);
  solveProblem(tool);
  enjoyLife();
}

Reflexiones finales

Si estás leyendo esto y sientes ese nudo en el estómago cada vez que ves una nueva tendencia en GitHub, respira. No pasa nada por no saberlo todo. De hecho, es imposible saberlo todo. Los mejores desarrolladores que conozco no son los que conocen todas las librerías, sino los que saben leer una documentación, entender los problemas de fondo y aplicar soluciones sólidas. Parad de intentar ser enciclopedias andantes y empezad a ser artesanos del código.


Mi recomendación personal es que elijas un stack con el que te sientas cómodo, lo domines de verdad y, a partir de ahí, explores lo nuevo con curiosidad pero sin agobios. Tu pasión por programar te lo agradecerá, y tu salud mental también. Al final, programar es un juego de lógica y creatividad, y es difícil ser creativo cuando estás en modo pánico. Volvamos a disfrutar de crear cosas, que para eso empezamos en esto, ¿no?

© 2026
Roberto Hernando
|