De ingeniero industrial a CPTO full-stack: Cómo aprendí a programar y liderar tecnología por accidente
Suspendí programación en primero de Ingeniería en Diseño Industrial. No solo me costó: la suspendí completamente. Si alguien me hubiera dicho entonces que acabaría siendo CTO/CPO de una startup tech, escribiendo código full-stack y tomando decisiones de arquitectura, me habría reído.
Esta es la historia de cómo un ingeniero industrial que no entendía los conceptos básicos de programación acabó siendo el líder técnico de Voicit, nuestra startup de HR tech. No es la típica historia de “siempre me gustó programar”. Es más caótica, más real y espero que más útil para otros ingenieros que se plantean si pueden hacer una transición similar.
El primer fracaso: cuando la programación no tenía sentido
Primer año, asignatura de programación. La suspendí completamente.
No era solo que no entendiera la sintaxis: no captaba la lógica fundamental. ¿Cómo le dices a un ordenador qué hacer? ¿Por qué esta secuencia de palabras hace que pase algo? Todo el concepto me parecía abstracto y desconectado del mundo físico al que estaba acostumbrado como estudiante de ingeniería.
Tuve que repetir la asignatura, y ahí fue cuando algo hizo clic.
El momento “Aha”: entender la lógica
Cuando repetí programación, algo cambió fundamentalmente en mi cabeza. Fue uno de esos raros momentos de “¡OHHHH, así funciona!”. De repente, el flujo lógico tenía sentido. Programar no era memorizar sintaxis, era descomponer problemas en pasos lógicos.
Ese momento de comprensión fue transformador, aunque no sabía que definiría mi carrera.
Los años de hardware: robots, drones y cosas reales
Después de esa asignatura, no toqué código en dos años. Estaba ocupado con ingeniería mecánica, modelado 3D y todos los aspectos físicos del diseño industrial.
Luego, en tercero, fui de intercambio a la Universidad Politécnica de Valencia. Ahí cambió todo.
Tuvimos que desarrollar un robot y me ofrecí para la parte de programación usando Arduino y C++. Ya sabía algo de C++ por la asignatura repetida, y la idea de crear comportamiento para un robot físico me fascinó.
Ya no era programación abstracta: era hacer que algo real se moviera y “pensara”.
Ese verano, compré mis propios componentes y traté de construir un mini-dron. Eso me llevó a una beca de colaboración desarrollando un dron más grande con electrónica más potente. Horas y horas aprendiendo software embebido, electrónica y dominando la impresión 3D.
Cuando me gradué, me había enamorado de la robótica. Por eso me metí directo en el máster de Ingeniería Mecatrónica.
El pivote inesperado: de hardware a UI/UX
Durante el máster, empecé unas prácticas en Ortoplus, un laboratorio dental. Se suponía que trabajaría en impresión 3D, pero de alguna forma acabé como diseñador de producto haciendo UI/UX.
Esta transición parece aleatoria, pero mi background como diseñador me dio ventaja. Siempre me había interesado el diseño gráfico, incluso había hecho algo de freelance diseñando equipaciones deportivas. Tener ojo de diseñador hizo la transición a UI/UX natural.
Me obsesioné. Estudiaba sistemas de diseño, analizaba apps y pasaba horas hablando con los programadores a diario, aprendiendo cómo funcionaban realmente las aplicaciones.
Un día me dejaron crear una pantalla HTML. Lo hice totalmente mal, pero esa experiencia práctica me enseñó más que cualquier tutorial.
Desarrollo web: el mundo abrumador de demasiados conceptos
Cuando empecé a ponerme serio con el desarrollo web, la cantidad de conceptos era abrumadora.
Frontend, backend, DevOps: cada mundo tiene una profundidad increíble. Viniendo del mundo relativamente directo de la ingeniería mecánica, era como entrar en un laberinto donde cada camino lleva a diez caminos más.
Empecé con Django y Python, aprendí un poco, pero cuando Voicit se hizo real, migramos todo a React con JavaScript y Node.js. La decisión fue sobre escalabilidad y compartir el mismo lenguaje entre frontend y backend.
Con el tiempo, mi stack técnico evolucionó más. Hoy desarrollo el frontend en JavaScript (aunque planeo migrarlo a TypeScript algún día) y el backend en TypeScript. Este enfoque mixto no es ideal desde una perspectiva purista, pero refleja la realidad de una startup en crecimiento: tomas decisiones basándote en necesidades inmediatas y mejoras gradualmente el código.
La transición de ingeniería física a desarrollo web fue mentalmente desafiante. Pasas de construir cosas que puedes tocar a construir experiencias digitales que solo existen en navegadores.
Convertirme en CPTO por necesidad, no por elección
Cuando levantamos nuestra primera inversión de 100k€, intentamos contratar un CTO. Fue imposible. Así que asumió el rol como CPTO y contraté a un excelente programador que se convirtió en mi maestro.
Durante ese período, me enfocaba en frontend y usuarios mientras él manejaba backend y DevOps. Aprendía constantemente de él: cada decisión técnica, cada elección de arquitectura.
Luego decidió irse.
El momento de la verdad: nadar o hundirse
Cuando nuestro programador se fue, sentí una presión enorme. Las opciones eran claras: o me las apaño con el backend y DevOps, o la empresa muere.
También estaba nuestra extensión de navegador construida con Svelte que tenía que aprender y mantener. De repente, no solo mantenía una app React: era responsable de todo el stack técnico.
Me di cuenta de que era "consigo sacar esto adelante" o "consigo sacar esto adelante". No había tercera opción.
Eventualmente volvió, pero para entonces había decidido que ambos seríamos full-stack. Cuando se fue de nuevo, estaba preparado.
El choque con la realidad de DevOps
A medida que escalamos usuarios, decidí externalizar DevOps porque sentía que estaba más allá de mis conocimientos. Pasamos de pagar 200€ a 600€ en infraestructura más los costes de la empresa externa.
Mirando atrás, probablemente podríamos haber aguantado más tiempo con la infraestructura vieja. Esa migración fue cara y probablemente prematura.
Cuando esa empresa quebró, me ayudaron a migrar las dependencias y hacer la transición a GitHub Actions. Aprendí mucho sobre pipelines de CI/CD y, aunque aún no soy experto en DevOps, puedo resolver problemas según surgen.
Mi viaje por los lenguajes de programación
Mirando atrás, mi progresión por los lenguajes cuenta la historia de mi transición:
- C++ (Universidad) - Donde entendí por primera vez la lógica de programación con Arduino
- Python/Django (Voicit inicial) - Mi primer intento de desarrollo web
- JavaScript (Frontend) - Desarrollo React que aún uso hoy
- TypeScript (Backend) - Añadido para mejor type safety y experiencia de desarrollo
- Svelte (Extensión navegador) - Aprendido por necesidad al mantener nuestra extensión
El setup mixto de JavaScript en frontend y TypeScript en backend no es perfecto, pero refleja la realidad de startup: optimizas para entregar, no para pureza técnica. Algún día migraré el frontend a TypeScript por consistencia, pero ahora mismo, las funcionalidades para usuarios tienen prioridad sobre la elegancia del código.
Cómo trabajo hoy: híbrido diseñador-desarrollador
Hoy, diseño y desarrollo están completamente integrados en cómo trabajo. Cuando hablo con usuarios y detecto una necesidad, entiendo cómo abordarlo técnicamente.
Obviamente, esto significa que ninguna parte obtiene un 10 perfecto, pero sigo la estrategia de lanzar rápido e iterar basándome en feedback.
Abandoné completamente los roadmaps a largo plazo. Solíamos planificar funcionalidades hasta 2 años adelante: ¡una locura total! Ahora planifico máximo 3 meses porque las prioridades cambian constantemente, y lo que sabías hace un mes es diferente de lo que sabes hoy.
Las ventajas del background en diseño industrial
Creo que mi formación me da ventajas específicas que los graduados en informática pura podrían no tener:
- Mejor comprensión del usuario - El diseño industrial te enseña a pensar en cómo interactúan realmente las personas con objetos
- Pensamiento en sistemas - Aprendes a ver el producto completo, no solo el código
- Resolución de problemas basada en restricciones - La ingeniería física te enseña a trabajar dentro de limitaciones reales
- Sensibilidad de diseño - Puedo moverme entre arquitectura técnica y experiencia de usuario naturalmente
Consejo para ingenieros que quieren hacer la transición
Soy terrible dando consejos de aprendizaje estructurado, pero aquí está mi camino pragmático:
- Empieza con frontend - Es visual e inmediato. Puedes ver lo que hace tu código
- Entiende que necesitarás backend - Cuando llegues a ese muro, aprende backend para conectar todo
- Eventualmente aprende DevOps - Cuando necesites alojar todo en algún sitio
La clave es aprender por necesidad, no por currículo.
Lo que echo de menos y lo que amo
A veces echo de menos los días de electrónica e impresión 3D. Hay algo satisfactorio en construir cosas físicas.
Pero lo que realmente disfruto es hacer cosas que funcionan: ya sea un robot que se mueve correctamente o una app que resuelve un problema real para usuarios.
La realidad de ser fundador técnico
Hoy manejo desarrollo, decisiones de roadmap, diseño, gestión de incidencias, algo de ventas y programación. Suena abrumador, pero cuando la necesidad impulsa el aprendizaje, te sorprendería lo que puedes absorber.
La verdad es que la mayoría de decisiones técnicas no son sobre conocer la solución “perfecta”: son sobre entender trade-offs y avanzar con información imperfecta.
Para otros ingenieros considerando este camino
Si eres ingeniero de otra disciplina pensando en aprender a programar para crear productos, esto es lo que he aprendido:
- Tu background en ingeniería es una ventaja, no una limitación
- No necesitas ser un programador perfecto para liderar productos técnicos
- Entender usuarios y sistemas a menudo importa más que conocer cada framework
- Aprender construyendo cosas reales es más efectivo que seguir tutoriales
La transición de hardware a software, de contribuidor individual a líder técnico, no es solo aprender a programar. Es aprender a pensar en sistemas, priorizar bajo incertidumbre y construir cosas que la gente realmente quiere.
Y a veces, la mejor preparación para eso es suspender programación en primero y tener que resolverlo desde cero.
Si eres ingeniero pensando en hacer una transición similar, me encantaría escuchar tu historia. El camino de ingeniero a fundador técnico es diferente para cada uno, pero los desafíos son sorprendentemente similares.