Lo que los hackathons te enseñan y los trabajos no pueden enseñarte
He competido en hackatones en México, Canadá, Estados Unidos, Turquía y Argentina. Gané algunos, perdí la mayoría y envié cosas en 48 horas de las que todavía estoy orgulloso, y cosas que me avergonzaría mostrarle a alguien hoy.
Nada de eso importa tanto como lo que aprendí sobre la construcción.
No construyas desde cero
La primera lección te llega en la tercera hora: no tendrás tiempo para construir todo tú mismo, y todo lo que construyas desde cero probablemente lo desecharás de todos modos.
Esto suena obvio. No lo es.
Los ingenieros, especialmente los que inician su carrera, tienen una tendencia hacia la construcción. Queremos escribir la solución personalizada, implementar el patrón elegante y ser dueños de cada línea. En un hackathon, ese instinto te destruirá. Tienes 48 horas. Si dedica 12 de ellos a escribir un sistema de autenticación personalizado en lugar de conectar uno existente, ya ha perdido.
La verdadera innovación en un hackathon es la recombinación creativa: tomar cosas que ya existen y ensamblarlas de una manera que nadie ha probado antes. Eso es todo. Esa es la habilidad.
Y aquí está la cuestión: eso también es la creación de productos fuera de los hackatones. Simplemente pretendemos que no lo es.
El producto no es código
Existe una ilusión persistente entre los ingenieros de que crear un producto significa escribir un código elegante. Que la calidad del código base es la calidad del producto.
Los hackathons rompen esa ilusión de la manera más visceral posible.
Envías algo unido con cinta adhesiva y llamadas API. El código es feo. La arquitectura es cuestionable. Y luego un usuario lo prueba y dice: “Esto resuelve mi problema”. Y te das cuenta: el producto no es el código. El producto es la respuesta a la pregunta de alguien.
Todo lo demás (la arquitectura limpia, la cobertura de las pruebas, los refactores) es mantenimiento. Mantenimiento importante. Pero mantenimiento al fin y al cabo. El producto existía en el momento en que resolvió el problema de alguien, independientemente de cómo se viera debajo del capó.
Aprender a priorizar la compresión
En un trabajo normal, los ciclos de retroalimentación se miden en semanas o meses. Usted envía una función, espera análisis, discute en retrospectiva, planifica la próxima iteración. Es civilizado y lento.
En un hackathon, el ciclo de retroalimentación se mide en horas. Construyes algo a las 2:00 p. m., lo demuestras a las 4:00 p. m., te dicen que es confuso a las 4:15 p. m. y lo reconstruyes a las 6:00 p. m. La compresión es brutal y educativa.
Lo que se aprende es priorización por eliminación: no “¿qué deberíamos construir?” pero “¿qué podemos darnos el lujo de no construir y aun así entregar algo significativo?”
Ese instinto (la capacidad de identificar lo que es esencial y lo que es bueno tener) es extraordinariamente difícil de desarrollar fuera de entornos con limitaciones de tiempo. Los sprints intentan simularlo. Los plazos intentan imponerlo. Pero nada replica la claridad de “nos quedan 16 horas y la demostración es al mediodía”.
No todo el mundo prospera bajo presión
Quiero tener cuidado aquí porque la narrativa de la cultura del ajetreo en torno a los hackatones es tóxica y errónea.No todo el mundo hace su mejor trabajo a las 3 a.m. No a todo el mundo le gusta construir bajo presión. Y nunca defenderé la falta de sueño o el sufrimiento como requisitos previos para una buena ingeniería. La salud y el bienestar emocional no son negociables.
Lo que he observado es que algunas personas necesitan algo específico para hacer su mejor trabajo: que los dejen en paz. Nada de enfrentamientos. Sin registros. Sin “sincronizaciones rápidas”. Sólo espacio, silencio y un problema claro. Los hackathons accidentalmente proporcionan esto (largos bloques ininterrumpidos de trabajo profundo) y para ciertos constructores, ese entorno desbloquea algo que las oficinas de planta abierta nunca podrán lograr.
Los tiradores de hilos
Los mejores constructores que he conocido en hackatones comparten un rasgo que no llamaría inteligencia exactamente. Tampoco es experiencia ni sabiduría.
Es la capacidad de seguir un hilo hasta que se resuelve.
Encuentran un error, una pregunta, una incertidumbre arquitectónica, y no cambian de contexto. Tiran del hilo. Leen el código fuente. Intentan el tercer enfoque. Se quedan con el malestar de no entender hasta que llega la comprensión.
He visto a desarrolladores junior con este rasgo superar a los senior que tenían más conocimientos pero menos tenacidad. En un lapso de 48 horas, la persona que se niega a abandonar un problema sin resolver siempre superará a la persona que sabe más pero se rinde antes.
Qué se transfiere al mundo real
Obviamente, algunas habilidades se transfieren. Aprendes una nueva plataforma, un nuevo marco, una nueva cadena: ese conocimiento es tuyo para siempre. Concreto. Portátil.
Pero las transferencias más profundas son menos visibles:
Colaborar con constructores de élite te enseña sus modelos mentales. Dos o tres días ininterrumpidos trabajando junto a ingenieros que piensan diferente a ti (observando cómo descomponen los problemas, qué herramientas utilizan, cómo depuran) es una educación que no puedes replicar en un entorno de trabajo normal. Se necesitarían meses de programación en pareja para absorber lo que absorbes en un solo fin de semana de hackathon.
Aprendes lo que realmente te gusta construir. Cuando el tiempo es escaso, gravitas hacia el trabajo que te da energía en lugar del trabajo que te asignan. Esa señal es valiosa. Te dice algo sobre tu carrera que ningún test de personalidad te dirá jamás.
Se desarrolla tolerancia a la imperfección. En producción, nos obsesionamos con los casos extremos. En los hackathons, enviamos errores conocidos y TODOs abiertos. Aprender a estar bien con eso (a entregar algo imperfecto que funcione) es un músculo que se atrofia en entornos que optimizan demasiado la calidad a expensas de la velocidad.
La verdadera comida para llevar
Los hackatones no te enseñan a codificar más rápido. Te enseñan a decidir más rápido. Qué construir, qué omitir, en quién confiar, cuándo girar y cuándo lanzar algo feo que resuelva un problema real.
Esas decisiones son el trabajo real de la ingeniería. El código es simplemente cómo los ejecutas.
Diego Jiménez Vergara — Ingeniero de Infraestructura de IA y DevOps. Competidor de hackathon en 5 países y múltiples ecosistemas blockchain.