De un curso de Flash a frontend developer en una startup con Jesús Olazagoitia

Entrevista publicada en Web Reactiva, suscribete a nuestra newsletter para Developers

En el episodio 311 de Web Reactiva, Jesús Olazagoitia nos contó su evolución desde diseñador gráfico hasta desarrollador frontend en una startup. Su historia revela verdades incómodas sobre cómo realmente se construye una carrera en tecnología.

No es la típica historia de éxito meteórico. Es mejor. Es real.

Organizar eventos tech potencia tu red profesional ¶

Jesús no se despertó un día pensando “voy a organizar la WordCamp Logroño”. Le obligaron las circunstancias. El meetup local crecía, la gente se implicaba, y alguien tenía que dar el paso.

La presión vino de la propia comunidad: “Oye, podemos hacer algo más grande”.

Por qué los eventos locales importan más de lo que crees ¶

• Crean conexiones reales: Cara a cara, sin filtros de LinkedIn
• Generan oportunidades inesperadas: Tu próximo trabajo puede estar en esa charla
• Te posicionan como referente: Ser el organizador te convierte en el punto de contacto
• Desarrollan habilidades transferibles: Gestión de proyectos, negociación, liderazgo

La WordCamp Logroño recibió 100 propuestas de charlas. Para un evento en una ciudad pequeña, eso es extraordinario. Demuestra que hay hambre de conocimiento y conexión en todas partes.

El síndrome del impostor del organizador ¶

“No pensábamos que iba a ser tan difícil”, admite Jesús. La inconsciencia inicial es una bendición. Si supieran todo lo que implica organizar un evento desde cero, probablemente no lo habrían intentado.

Pero ahí está la lección: a veces hay que ser inconsciente y lanzarse.

Los proyectos personales son tu mejor currículum ¶

HeliBlocks nació de una frustración personal. Jesús tenía un WordPress headless con un frontend en Next.js. El problema: los estilos del editor no se transferían al frontend.

Su solución: una herramienta que convertía HTML y CSS en bloques editables de WordPress.

El proceso de un proyecto personal real ¶

• Identifica un problema que te molesta: No uno que crees que debería existir
• Construye la solución más simple: Resuelve tu caso específico primero
• Publícalo aunque sea imperfecto: Mejor algo funcionando que algo perfecto en tu disco duro
• Escucha feedback real: Los usuarios te dirán qué necesitan realmente
• Sé valiente para cerrar: Reconoce cuándo algo no funciona y ciérralo

HeliBlocks no triunfó como esperaba Jesús. WordPress lanzó funcionalidades similares. La gente no creaba bloques como él imaginaba. Pero le dio algo más valioso: credibilidad técnica.

Cómo un proyecto “fallido” le consiguió trabajo ¶

Durante la pandemia, una empresa lo contactó porque uno de sus empleados conocía HeliBlocks. No vieron su CV. Vieron su código en GitHub. Analizaron cómo trabajaba, su estructura de proyecto, su documentación.

El código fue su entrevista.

Esta es la diferencia entre un proyecto personal y un tutorial completado: uno demuestra que puedes resolver problemas reales, el otro solo que puedes seguir instrucciones.

Puedes ver más sobre los proyectos de Jesús en su web personal y conectar con él a través de LinkedIn.

Las bases técnicas sobreviven a las modas ¶

Jesús vivió la evolución completa del frontend: desde cortar imágenes en Photoshop hasta la complejidad actual de webpack, bundlers, y frameworks.

Su consejo es tajante: “Las bases las tienes que saber bien porque mañana te va a cambiar el framework”.

Lo que nunca pasa de moda ¶

• HTML semántico: La estructura sigue siendo la base de todo
• CSS profundo: “Si sabes CSS te vas a ahorrar unas cuantas líneas de JavaScript”
• JavaScript vanilla: Entender cómo funciona por debajo te hace mejor con cualquier framework
• Programación asíncrona: El concepto que más problemas causa y más se necesita

La historia del web component que nadie se atrevía a tocar es reveladora. Jesús lo había hecho con TypeScript, tests unitarios, documentación completa. Pero el equipo no sabía cómo trabajar con esas herramientas.

El peligro de adelantarse demasiado ¶

Crear algo que funciona perfectamente pero que tu equipo no puede mantener es un fracaso técnico. La mejor solución no siempre es la más avanzada, sino la que el equipo puede entender y evolucionar.

Esta experiencia de enseñar y transmitir conocimiento la puso en práctica Jesús en Developer contra las cuerdas, donde enseñó diseño a desarrolladores, demostrando que compartir conocimiento es tan valioso como tenerlo.

El trabajo remoto exige mayor esfuerzo ¶

“Para trabajar en remoto hay que trabajar un huevo”, dice Jesús sin rodeos. La percepción de que el trabajo remoto es más relajado es un mito peligroso.

La presión invisible del trabajo remoto ¶

• Sobrecompensación constante: Necesitas demostrar que estás siendo productivo
• Ausencia de validación visual: Nadie te ve trabajando 8 horas en la oficina
• Autogestión total: Sin supervisión directa, la autodisciplina es crítica
• Aislamiento social: Falta la validación casual de colegas

Jesús describe la ansiedad perfectamente: “Si llevas ocho horas y no has publicado nada, vienen los sudores fríos”.

Por qué funciona para algunos y destruye a otros ¶

El trabajo remoto amplifica tus características naturales. Si eres autodisciplinado, te hará más productivo. Si tiendes a la procrastinación, te hundirá.

No es para todos, y está bien admitirlo.

Sal de tu zona de confort ¶

Jesús pasó 17 años en la misma empresa. Desde que terminó sus estudios hasta después de los 30. Era cómodo, conocía el entorno, tenía seguridad.

Pero también tenía un problema: la empresa era PHP, él quería hacer JavaScript moderno.

Las señales de que necesitas moverte ¶

• Tus intereses divergen del negocio: Quieres aprender React, pero todo es WordPress
• Te has vuelto demasiado cómodo: No hay retos que te hagan crecer
• Tus habilidades se oxidan: El mercado avanza, tú te quedas atrás
• Sientes que hay “vida más allá”: Curiosidad por cómo trabajan otros equipos

La pandemia forzó el cambio. Las empresas necesitaban desarrolladores remotos urgentemente. Jesús tenía el perfil y la experiencia, pero sobre todo, tenía proyectos que demostraban su capacidad.

El equilibrio entre estabilidad y crecimiento ¶

No se trata de saltar de empresa cada seis meses. Se trata de reconocer cuándo la estabilidad se ha convertido en estancamiento.

Jesús encontró el punto medio: trabajo para una startup (crecimiento) más freelancing (estabilidad económica).

Simplifica lo complejo crea valor ¶

Open Data La Rioja es un ejemplo perfecto. Los datos del gobierno estaban ahí, pero eran inútiles: “un chorizo que no se entiende para nada”.

Jesús los tomó y creó visualizaciones comprensibles: gráficos de nacimientos, consumo eléctrico, combustible.

El valor está en la traducción ¶

• Datos técnicos → información comprensible
• APIs complejas → interfaces intuitivas
• Código especializado → herramientas usables
• Procesos manuales → automatización simple

El proyecto tuvo doble propósito: hacer los datos útiles para ciudadanos y enseñar contribución open source a desarrolladores locales.

Por qué importa la contribución local ¶

Seis personas colaboraron en el proyecto. Ninguna había contribuido antes a código abierto. Ahora saben crear pull requests, entender flujos de trabajo colaborativo, participar en proyectos más grandes.

Es desarrollo de talento local en acción.

La evolución del frontend según quien la vivió ¶

Jesús empezó cortando imágenes para HTML estático. Vivió la llegada de CSS, JavaScript, jQuery, los primeros frameworks, la explosión de herramientas de build, y la situación actual.

Su perspectiva: “Ahora sí que veo un poco de sentido común”.

Lo que ha mejorado ¶

• Menos magia: Las herramientas son más explícitas sobre lo que hacen
• Mejor developer experience: Hot reload, debugging, error messages
• Estándares maduros: CSS Grid, ES6+, APIs modernas del navegador
• Ecosistema estable: Menos cambios disruptivos cada mes

Lo que sigue siendo difícil ¶

Hacer una paginación infinita con un desplegable en JavaScript vanilla sigue siendo complejo. Los frameworks no han eliminado la complejidad, la han organizado mejor.

Las lecciones para tu carrera ¶

La historia de Jesús no es única, pero sí instructiva. No hay trucos mágicos ni atajos secretos. Hay trabajo consistente, proyectos reales, y la valentía de salir de la zona de confort cuando es necesario.

El patrón del crecimiento profesional ¶

1. Domina las bases: HTML, CSS, JavaScript sin frameworks
2. Construye cosas reales: Proyectos que resuelvan problemas que tengas
3. Participa en comunidades: Meetups, eventos, contribuciones open source
4. Documenta tu trabajo: GitHub público, blogs, charlas
5. Sal de tu zona de confort: Cuando la comodidad se vuelve estancamiento
6. Mantén múltiples opciones: Freelancing + trabajo fijo, múltiples skills

La importancia de la comunidad local ¶

La tecnología es global, pero las oportunidades son locales. Conocer a la gente de tu ciudad, región, o comunidad tech puede ser más valioso que tener 10,000 seguidores en Twitter.

El síndrome de la base perfecta ¶

No esperes a “estar listo” para empezar a construir cosas. Jesús empezó HeliBlocks para resolver su problema específico, no para cambiar el mundo. Lo importante es empezar.

La perfección es enemiga del progreso. El código que publicas imperfecto es infinitamente más valioso que el código perfecto que nunca ve la luz.

Tu próximo proyecto no tiene que ser revolucionario. Solo tiene que ser tuyo.