Lo que la facultad me enseñó que un bootcamp no puede

Silvano Puccini
Full Stack Engineer
Hay una pregunta que me hacen seguido: ¿para qué cursar una carrera universitaria si con un bootcamp ya podés conseguir trabajo? La respuesta corta es que no compiten por el mismo problema, y darme cuenta de eso me llevó cursar las dos cosas al mismo tiempo.
Este análisis no aplica a quien elige un solo camino y lo hace bien. Aplica al momento específico de cursar una carrera formal de sistemas (TUDAI) y un máster full stack orientado a producto (ConquerBlocks) en paralelo, y notar qué te da cada uno que el otro no.
Criterio
Lo que la formación teórica te obliga a hacer
En la facultad, materias como Estructuras de Datos y Bases de Datos no te enseñan a shippear rápido. Te obligan a preguntarte por qué una estructura es mejor que otra antes de usarla, no porque la documentación lo diga, sino porque entendés el costo real de cada decisión: qué pasa con la complejidad cuando el dataset crece, por qué una normalización mal pensada te va a perseguir en producción.
La restricción de este camino es el tiempo: entender el fundamento antes de construir algo funcional lleva mucho más que un tutorial de fin de semana.
La decisión fue no saltearme eso, aunque significara avanzar más lento en portfolio visible mientras cursaba.
La consecuencia: cuando en un proyecto real elijo una estructura de datos o diseño una relación de base de datos, no es porque "así se hace", es porque entiendo el tradeoff que estoy aceptando.
Lo que la formación práctica te obliga a hacer
En el máster full stack, la lógica es inversa: construís primero, entendés en el camino. Los módulos de frontend, backend y deploy te ponen frente a un problema real (un formulario que no valida bien, un deploy que rompe en producción y no en local) antes de que tengas la teoría completa para explicarlo.
La restricción acá es la profundidad: resolvés el síntoma rápido, pero el por qué de fondo a veces queda pendiente hasta que lo pisás de nuevo en otro proyecto.
La decisión fue aceptar esa velocidad como parte del aprendizaje, no como un atajo tramposo. Se aprende distinto resolviendo bajo presión real que leyendo con calma.
La consecuencia: hoy puedo entregar algo funcional rápido, y cuando algo falla en producción, no me paraliza, porque ya viví ese tipo de quiebre antes, en un contexto donde tenía que resolverlo ya.
Lo que ninguno de los dos reemplaza
La facultad no te enseña a shippear bajo la presión de un cliente real esperando una fecha de entrega. El máster no te enseña por qué un algoritmo se vuelve inviable cuando el volumen de datos se multiplica por cien. Cursarlos juntos no fue eficiente en el sentido de "menos horas invertidas", fue eficiente en el sentido de que ninguna de las dos formaciones tapó el punto ciego de la otra.
Una tensión que no está resuelta
Lo que todavía no tengo claro es cuánto de este cruce escala más allá de mi propio caso. ¿Tiene sentido para alguien que ya tiene años de experiencia en producción? ¿O el valor real está solo en el momento de arranque, cuando todavía no sabés en qué dirección vas a especializarte?
Sospecho que el cruce importa más al principio, cuando todavía no sabés qué tipo de problemas vas a tener que resolver. Eso es lo que quiero seguir documentando a medida que el criterio técnico se define más.
Esta forma de pensar la formación (qué te da la teoría, qué te da la práctica, y dónde se necesitan las dos) es exactamente el tipo de análisis que hago cada semana en El Radar. Si te interesa esta línea, suscribite. Una nota por semana, directo en tu casilla.
Newsletter
¡No te pierdas! Mantenete cerca del radar.
Recibí semanalmente lo que estoy construyendo: artículos, recursos técnicos y reflexiones sobre el futuro del diseño digital. Sin spam, solo arquitectura.