Este no es el típico hackathon, esto es ReleaseBeforeReady

Mientras que un hackathon convencional existe porque una empresa decide organizar un evento para atraer desarrolladores y conseguir usuarios para sus productos, en RbR no tenemos esa dinámica. No hay jueces evaluando lo que creas. No hay premios como recompensa. Hasta parece que no hay una razón para asistir.

La verdadera razón para participar en un RbR es muy única: reunirte con desarrolladores talentosos a construir tecnología por el simple gusto de hacerlo. Así cada evento se llena, y todos nos quedamos esperando el siguiente. Esto sucede porque nuestros objetivos son distintos.

El objetivo es generar una comunidad que construya usando tecnología, que comparta cómo lo crea y que todos aprendamos de ella. El evento solo es una excusa para reunirnos y cumplir estos objetivos. De ahí hemos empezado a tener una comunidad que trasciende lo digital y se mantiene activa en un canal de WhatsApp con gente de varias ciudades.

En el último evento que realizamos en Bogotá, una de las frases que más recuerdo fue la de René cuando explicaba la dinámica. René pertenece al equipo de 500 Latam y fue el organizador principal del RbR de Bogotá. Al inicio del evento, mientras explicábamos la dinámica a los asistentes primerizos, René aclaró que en RbR él viene a construir como un participante más. Que si le querían hacer un pitch, lo hicieran la próxima semana en el contexto de Colombia Tech Week, donde también organizó un evento llamado 500 Tintico Pitch Day diseñado específicamente para eso.

En RbR una cosa es muy clara: todos venimos a crear algo. No hay turistas.

Hemos intentado tener mentores, pero todos están tan enfocados en construir que a veces no se acercan a ellos. O cuando necesitan ayuda, terminan preguntando a otros asistentes del evento. El rol de mentor parece ser cubierto por todos, y tal vez esa sea la respuesta: en RbR todos somos mentores y aprendices al mismo tiempo. (Aunque si tienes ideas de cómo mejorar el rol de mentor o cómo lo harías tú, contáctame y platiquemos).

Se preguntarán cómo llegamos a esta dinámica tan particular. Cómo se nos ocurrió hacer un evento así. La realidad es que Santiago, René y yo llevamos muchos años participando en eventos y comunidades de programación.

Por ahí de octubre del 2008, Santiago y César trajeron un evento llamado Super Happy Dev House de Silicon Valley. El primero nos juntó a 8 personas en nuestra casa. Después lo organizamos muchas veces, llegando a tener hasta 250 personas en un evento donde Google nos prestó sus oficinas.

Después les ayudé a organizarlo en la Ciudad de México. En ese evento el objetivo era juntarnos 12 horas a crear por gusto. El SHDH tenía como pilares ser productivo, divertido e inclusivo. Al final del evento presentábamos lo construido en lightning talks de 5 minutos. De este evento aprendimos mucho; hoy seguimos llevando a la práctica lo que aprendimos del SHDH.

Los últimos eventos en el DF (en ese momento todavía era Distrito Federal) siempre tenían más de 150 asistentes. Todos crecimos mucho. La sala se llenaba de energía. En el SHDH México City 10 vinieron los creadores del evento desde Silicon Valley, incluyendo a Jeff Lindsay, quien nos dio una lightning talk sobre las apps que creaba en 4 horas. Pudimos trabajar al lado de personas que creaban startups por allá y darnos cuenta de que todos podíamos ser buenos desarrolladores si le dedicábamos el tiempo correcto. Lo que faltaba eran lugares donde compartir y aprender más rápido.

Hoy estos eventos siguen en Silicon Valley, pero nosotros preferimos hacer un formato ligeramente distinto. También aprendimos que eventos de 150 o más asistentes requieren espacios más grandes y son mucho más complicados de manejar. Al día siguiente acabas tan cansado que no quieres saber del evento por un rato.

René y Santiago organizaron muchos Startup Weekends. También se conocieron organizando uno en Mérida. René entró al equipo de 500 después de esto, y hoy René y Santiago llevan trabajando juntos mucho tiempo. Yo participé en muchos, algunos como participante, otros como mentor, aunque no organicé ninguno.

Yo por esas fechas organizaba un evento llamado ChelaJS con Jeduan. Ese evento salió de tropicalizar BeerJS de Silicon Valley. Tomamos la idea de juntarnos a tomar chela y platicar con otros desarrolladores, le agregamos charlas para que las conversaciones fueran mucho más dirigidas a hablar de programación. Muchas de las pláticas del evento salían de las conversaciones que teníamos en el after de eventos anteriores.

Santiago ha participado en un game jam de indie gaming llamado Ludum Dare, donde muchos desarrolladores se reúnen a programar juegos nuevos basados en lo que vota la comunidad. Tienen varios días para crear y al final son evaluados por los desarrolladores que participaron. En Ludum Dare no hay premios físicos; los participantes se llevan mucho street cred de la comunidad y los derechos de lo que crearon. Galcon, que nos gusta mucho, fue creado en ese evento.

Hoy el ecosistema es mucho más maduro que el de esas épocas: hay mucha más inversión y startups. Después de la pandemia, nos faltaba un evento que sintiéramos que era del estilo que nos gustaba, y decidimos crearlo combinando mucho de lo aprendido. Como verán, nos hemos inspirado mucho en estos eventos para crear Release before Ready y VibeRacing.

En RbR, la única moneda que tiene la comunidad es qué construyes y qué enseñas. Los participantes tienen mucha libertad de trabajar en lo que ellos consideren valioso y así llevarse una experiencia única al final del día. Cada persona elegirá su canvas, elegirá su estilo y podrá entregar algo único.

Eso, junto con que vivimos un momento muy acelerado en tech donde salen nuevas herramientas todos los días, crea una combinación perfecta. Poder ver cómo alguien crea algo con estas nuevas herramientas, poder acercarte a cualquier persona del evento y pedirle que te enseñe qué está haciendo y cómo hacerlo es muy gratificante.

Tanto para la persona que recibe el conocimiento, pero más interesante aún, para la persona que lo enseña. El poner en palabras algo que apenas estás aprendiendo te hace verlo de una manera distinta, te permite entenderlo mucho mejor. Sobre todo cuando alguien pregunta algo que no has intentado, la respuesta siempre es "No sé, pero veamos qué pasa", y entre los dos participantes de esta plática pasan cosas increíbles.

Los últimos días he estado releyendo "Zen and the Art of Motorcycle Maintenance" y pensando mucho sobre el tema de remover los incentivos equivocados en RbR.

Es curioso cómo RbR se llena siempre. Los boletos se acaban, la gente se va feliz, y todo esto sin premios, sin jueces, sin nada de lo que supuestamente hace atractivo a un hackathon (aunque el swag nos empieza a quedar bonito). Esta paradoja me ha hecho reflexionar sobre qué es lo que realmente motiva a la gente a crear.

En los eventos que tienen premios, generalmente alguien de marketing o business buscó crear algo por el bien de la empresa, entonces la gente va a atacar ese objetivo. Genera una dinámica bastante rara, casi como ir a trabajar en sábado.

Lo que me gusta mucho de cómo Pirsig en el libro explora la diferencia entre Calidad clásica y Calidad romántica es que captura perfectamente lo que pasa en RbR.

Para Pirsig, la Calidad es ese reconocimiento intuitivo de cuando algo está "bien" —no puedes definirla de antemano, pero la reconoces inmediatamente cuando la encuentras. Es como saber cuándo una motocicleta está perfectamente afinada sin necesidad de medidores. El problema surge cuando intentas definir la Calidad externamente: en cuanto estableces criterios fijos, ya no es verdadera Calidad—se convierte en mero cumplimiento de especificaciones.

Cuando hay jueces y premios, todos persiguen la misma definición externa de calidad: métricas, features, lo que creen que los jueces quieren ver. Pero cuando quitas esos incentivos externos, algo interesante sucede: la gente empieza a buscar su propia definición de Calidad, esa que reconoces cuando la ves pero que permanece indefinida hasta que la creas.

Esta indefinición no es un problema—es precisamente lo que permite que emerja la motivación intrínseca. Sin objetivos externos impuestos, cada persona debe encontrar su propia brújula interna de lo que vale la pena crear. Al final del día, quitar los premios y los jueces permite que lo importante sea lo que cada uno considera correcto. Cada participante se convierte en su propio mecánico de motocicletas, sintiendo cuando algo está bien afinado, cuando el código fluye, cuando la solución es elegante no porque alguien más lo diga, sino porque tú lo sientes.

Simplemente pensar qué construiría en un período de 12 horas donde nadie me dé instrucciones es un problema retador al principio. Es enfrentarte a esa hoja en blanco sin un manual de mantenimiento. Pero después de un ratito, la gente curiosa pasa de 0 a 10 ideas que quiere construir. Descubren que cuando no hay un destino impuesto, el viaje mismo se vuelve el punto—y ese viaje está lleno de posibilidades.

Una de las cosas bonitas del evento es que no sabremos qué vendrá. Sabremos que vienen cosas muy buenas cuando juntas a las personas correctas.

No nos preocupamos por objetivos a corto plazo. No medimos el éxito por el número de startups que salen o por las contrataciones que se hacen. Esas cosas suceden, pero son efectos secundarios de algo más fundamental: crear un espacio donde la curiosidad y la creatividad se encuentran con la tecnología.

La magia está en las conversaciones inesperadas, en el momento cuando alguien te muestra una manera de crear que no conocías, en la satisfacción de terminar algo que no sabías que podías hacer. Es en ese desarrollador que nunca había usado IA y sale del evento habiendo creado su primer chatbot. Es en ese fotógrafo que documenta el evento y descubre que puede automatizar su flujo de edición con código.

Durante las presentaciones siempre resuena el "No sabía que podía crear esto". Muchos asistentes terminan felices de mostrar el resultado de lo que construyeron y 12 horas antes probablemente no creían que fuera posible. En la CDMX pasó esto con la demo de Elisa Rodríguez, donde presentó un sitio de reservas que tenía el sandbox de Stripe y guardaba en Google Spreadsheets. Simple, funcional, y creado en una tarde por alguien que no se consideraba "técnico".

Me llena de orgullo que hoy René sea nuestro experto en Replit, después de haberlo descubierto y dominado en uno de nuestros eventos.

Como dice nuestro manifiesto: "Algo extraordinario sucede cuando nos reunimos con frecuencia con la intención de dar más a la comunidad de lo que esta nos da a nosotros. No podemos predecir exactamente qué oportunidades surgirán, pero sabemos que participar con el corazón abierto, buena vibra y ganas de compartir siempre rinde frutos."

Tendremos 3 RbRs en los próximos 45 días:

• Palo Alto - 13 de septiembre
• Guadalajara - 20 de septiembre
• Ciudad de México - 18 de octubre

Si esta dinámica de crear y compartir te resonó, te esperamos en estos eventos para aprender en conjunto. No necesitas ser un desarrollador experimentado. No necesitas tener una idea revolucionaria. Solo necesitas curiosidad y ganas de crear.

Como decimos en cada evento: "Done is better than perfect". Y como aprendimos de Ludum Dare y todos los eventos que nos inspiraron: los mejores proyectos nacen cuando no hay jueces mirando, solo creadores compartiendo.

Nos vemos en el próximo RbR. Trae tu laptop, tu curiosidad y tus ganas de crear algo que no existía esta mañana.