No pensaba que sería capaz de hacerlo. He visto mi evolución y la de mis compañeros estas tres semanas y parece increíble.
Esta es una frase habitual al terminar los proyectos. Los alumnos comienzan el viernes de la semana ocho con un lienzo en blanco y muchos conceptos desperdigados en su cabeza, algunos apuntes, varios ejercicios y muchos ejemplos. Cada miembro del grupo escoge el proyecto que realizará y con el que pondrá en práctica todos los contenidos del curso. Estas tres semanas son fundamentales para entender las relaciones entre todas las piezas de una aplicación full-stack.
¿Qué debe tener un proyecto final?
El mandato que reciben nuestros estudiantes es que deben realizar un CRUD completo con gestión de usuarios y 100% de cobertura de test.
Nuestros pipelines de CI/CD les obligan a mantener estos estándares o sus proyectos no suben a producción. Además, empujamos a algunos de ellos a explorar algunas tecnologías nuevas que no han aparecido durante el curso como React Native, Angular, NextJS, etc. Necesitamos apretar al máximo a cada estudiante y que se lleve el máximo posible.
Proyectos individuales
A diferencia de la mayoría de escuelas que imparten cursos de programación en formato bootcamp, los proyectos finales que realizan los alumnos de ISDI Coders son individuales. La razón por la que, desde la primera promoción, implantamos esta modalidad es porqué necesitamos que nuestros estudiantes entiendan en su totalidad las relaciones entre front-end, back-end, las peculiaridades de cada parte, etc. La mayoría de ellos ocuparán posiciones como front-end developers, pero tienen que ser capaces de interactuar con sus compañeros, entender las problemáticas de otras partes de una aplicación web y hablar su mismo lenguaje.
Otra razón fundamental que nuestros proyectos finales no sean grupales es porqué no queremos que ninguno de nuestros estudiantes se dedique a lo que le resulta más sencillo 🤷🏻♂️ Necesitamos mantener a nuestros alumnos fuera de su zona de confort hasta el último momento. Tenemos que hacerles practicar los skills de entender los problemas, hacer debugging, buscar soluciones y hacer buenas preguntas a sus compañeros o profesores. Debemos conseguir que se den cuenta que son capaces de resolver casi cualquier problema con este set de herramientas.
La tercera razon y, quizás, la más importante a corto plazo es que necesitamos brillen en sus entrevistas de trabajo. Deben poder explicar todas las partes de su aplicación desde el CSS hasta las rutas del servidor o el modelo de base de datos, pasando por el testeo de cada parte o las razones por las que tomó cualquier decisión. Para eso es vital no decir: “esta parte no la hice yo”.
Seguimiento a diario
El equipo de profesores se reúne diariamente con cada uno de los alumnos, hacen seguimiento de sus avances, les aprietan para que mantenga los estándares de calidad de código que les pedimos. Cada día tienen que terminar con un 100% de cobertura de código de lo que hayan hecho durante el día, SonarQube debe mostrar cero errores y LightHouse debe indicar que las páginas están optimizadas.
Lo importante es invisible a los ojos
De los 10 o 15 minutos que cada estudiante está presentando su proyecto, solo un tercio lo dedicamos a ver la aplicación funcionando. Sí, queremos ver que sea funcional y los usuarios puedan cumplir lo que se les promete, pero el grueso de la presentación lo dedicamos a ver y a hablar del código que han realizado. De nuevo, nuestros estudiantes ocuparán posiciones de desarrollador web, no como diseñadores. Empresas como SEAT:Code, Promofarma, Accenture, InfoJobs, Wallapop o Glovo les contratarán por la calidad de su código, no por sus dotes de diseño.
Sabemos que un diseño bonito abre puertas, pero también sabemos que no saber solucionar con mucha calidad una prueba de código (como las que pasa cualquier programador para entrar en una Compañía) te las cierra… y habla mal de la escuela.
