Tu primer mes en una startup deja huella. No hay una adaptación lenta, ni una semana viendo vídeos de orientación mientras esperas a que IT te proporcione un portátil. Desde el primer día, se espera que construyas, rompas y arregles cosas que personas reales utilizarán de verdad. Aprendí esto rápidamente tras unirme a Treevah, una empresa que desarrolla herramientas para ayudar a los buscadores de empleo a organizar sus candidaturas. Treinta días en un entorno de etapa temprana me enseñaron más sobre desarrollo de software de lo que cualquier aula o competición podría haberlo hecho.
El ritmo es implacable
En Treevah, el trabajo no espera a que te asientes. El equipo está presionando para pasar el producto de alfa a beta y, finalmente, a producción, lo que significa que cada tarea tiene peso. No hay lugar para trabajos de relleno o tareas que se archivan en la bandeja de entrada de un profesor. Cuando lanzas una funcionalidad, va directamente a usuarios que intentan hacer un seguimiento de plazos, entrevistas y seguimientos mientras buscan su próximo empleo.
El ritmo es agotador. Te mueves rápido cada día y la carga de trabajo se acumula más rápido de lo que esperas. Los plazos no son abstractos; están ligados a hitos que determinan si la empresa puede atender a más buscadores de empleo o corregir deficiencias en la experiencia actual. Esa pesadez te desgasta. Pero también crea una claridad difícil de encontrar en organizaciones más grandes. Cuando termino una tarea, puedo trazar una línea directa entre lo que construí y una persona que ahora tiene más facilidad para gestionar su búsqueda de empleo. Ese sentido de propiedad es poco común y hace que el cansancio valga la pena.
Las habilidades se potencian más rápido en producción
Antes de este verano, gran parte de mi energía se dedicaba a la oratoria y a los hackathons. Ambos me enseñaron a pensar con rapidez y a presentar ideas bajo presión. Los hackathons, especialmente, te entrenan para armar demos funcionales en cuestión de horas. Pero hay una diferencia entre un proyecto de fin de semana que impresiona a los jueces y el código de producción que tiene que sobrevivir al contacto con cientos de usuarios reales.
Pasar un mes centrado en el desarrollo web en Treevah cerró esa brecha. En la escuela, los proyectos vienen con protecciones. El alcance es fijo, los requisitos se entregan masticados y, si tu esquema de base de datos falla, puedes justificarlo en una diapositiva de una presentación. Dentro de una startup, tu esquema tiene que resistir porque buscadores de empleo reales están almacenando datos de candidaturas reales en él. El ciclo de retroalimentación es inmediato e implacable. Cuando una página carga lentamente o un formulario no se guarda, a nadie le importa tu nota; les importa si acaban de perder el rastro de una oportunidad.
Esa presión obliga al crecimiento. Aprendes a escribir código más limpio no porque una rúbrica lo exija, sino porque tú serás quien lo depure a medianoche. Aprendes a hacer preguntas más agudas durante la revisión de código porque desplegar un build roto significa que los usuarios reales se topan con un muro. Las oportunidades aquí simplemente impactan con más fuerza que los proyectos escolares. Los errores cuestan más y, por tanto, las lecciones se graban mejor.
La humillante realidad de los bugs
Si hay un mito que me gustaría destruir, es la idea de que cada bug de software es un fallo lógico dramático. Algunos lo son, por supuesto. Pero muchos de los bugs que encontré en Treevah eran exasperantemente pequeños. Se escondían a plena vista y me hicieron perder horas de vida.
Dos patrones aparecían constantemente. El primero eran reglas CSS duplicadas. Cuando varios desarrolladores tocan el mismo componente a lo largo de varios sprints, las hojas de estilo se inflan. Una persona añade una clase de utilidad de margen mientras otra escribe un valor de forma fija en el archivo del componente. Ninguna está mal de forma aislada. Pero juntas crean desplazamientos de diseño (layout shifts) o guerras de especificidad que hacen que un botón se vea bien en Chrome pero roto en Safari. Rastrear eso significa abrir las herramientas de desarrollo del navegador y navegar por los estilos computados línea por línea en lugar de leer una elegante lógica algorítmica.
El segundo era definir elementos fuera de sus divs padres. Un activador de modal o un menú desplegable podrían añadirse al nodo incorrecto en el DOM. La pantalla parece casi correcta, así que asumes que la estructura es sólida. Entonces aparece un conflicto de z-index, o un evento de clic se propaga al manejador incorrecto, y de repente un usuario no puede cerrar una ventana emergente que está cubriendo su formulario de solicitud. Estos no son acertijos de ciencias de la computación. Son errores espaciales y estructurales que se acumulan cuando te mueves rápido.
Algunos de estos errores tardaron semanas en encontrarse. Me quedaba mirando el código, me convencía de que la lógica era sólida y me adentraba en callejones sin salida que no llevaban a ninguna parte. La frustración es real. Sientes que se te escapa algo obvio, y así es. Pero la satisfacción de finalmente detectar una regla duplicada o una etiqueta de cierre mal colocada es sorprendentemente