La parte final de la trilogía del hackathon. EN Hablé sobre la motivación para participar en este tipo de eventos. se dedicó a los errores de los organizadores y sus resultados. La parte final responderá preguntas que no encajaron en las dos primeras partes.
Cuéntanos cómo empezaste a participar en hackathons.
Estudié una maestría en la Universidad de Lappeenranta mientras resolvía concursos de análisis de datos. Mi día típico era así: levantarme a las 8, algunas parejas en la universidad, luego concursos y cursos hasta la medianoche (mientras cuentan las presentaciones, veo conferencias o leo artículos). Un cronograma tan estricto dio sus frutos y gané el concurso de análisis de datos MERC-2017 (que incluso se discutió ). La victoria me dio confianza, y cuando accidentalmente encontré información sobre el hackathon SkinHack 2 en Moscú, decidí visitar a mis padres y al mismo tiempo descubrir qué es un hackathon.
El hackathon en sí resultó bastante divertido. Había dos pistas de análisis de datos con métricas claras y un conjunto de datos con un premio en metálico de 100 rublos. La tercera pista fue sobre desarrollo de aplicaciones con un premio de 50 y no hubo participantes. En un momento dado, el organizador dijo que una ventana con un botón sin funcionalidad podría ganar 50 dólares, porque el premio no se podía pagar. No comencé a aprender a programar aplicaciones (no compito donde me puedan “entregar” fácilmente), pero para mí fue un mensaje claro de que los campos en los hackathons no están abarrotados.
Luego resolví ambas pistas de análisis de datos solo. Encontré una fuga en los datos que me permitieron obtener la velocidad ideal, pero la columna con la fuga no estaba en los datos de prueba que recibí dos horas antes del final del evento (por cierto, luego entendí que la presencia de una columna “objetivo” en el tren no cuenta como fuga). Al mismo tiempo se abrió la clasificación, mi presentación sin rostro ocupó el tercer lugar de cinco, había una gran brecha con el primero y decidí no perder el tiempo y me fui.
Después de analizar con una mente nueva lo que sucedió, encontré un montón de errores (uno de mis hábitos es desplazarme mentalmente por lo que sucedió con el bloc de notas y analizar los errores, su causa y lo que podría haberse cambiado; un legado tan agradable). de un juego de póquer semiprofesional). Pero una cosa estaba clara: los hackatones tienen mucho valor y simplemente tenía que implementarlo. Después de este evento, comencé a monitorear eventos y grupos, y el posterior hackathon no se hizo esperar. Luego otro, y otro...
¿Por qué haces hackatones y no Kaglo?
No me gusta Kagle en este momento. A partir de un cierto nivel de habilidad, sin motivos específicos para participar, kagle se vuelve menos útil que otras actividades. Participé mucho antes, aparentemente logré “bajarme” de alguna manera.
¿Por qué hackatones y no trabajar en tu propio proyecto?
Me gusta la idea de hacer algo genial con mis propias manos a un ritmo lento. Los chicos de ODS organizaron para todos los que quieran pasar el fin de semana trabajando en su proyecto con personas de ideas afines. Creo que pronto me uniré a ellos.
¿Cómo encuentras eventos?
Fuente principal: hackathon.com (mundial) y chat de Telegram (Rusia). Además, los anuncios de eventos aparecen en publicidad en las redes sociales y en linkedin. Si no encuentra nada, puede buscar aquí: mlh.io, devpost.com, hackevents.co, hackalist.org, HackathonsNear.me, hackathon.io.
¿Preparas un plan de solución antes de participar o todo se decide sobre la marcha? Por ejemplo, una semana antes del hackathon, ¿piensas: “Necesitaremos tal o cual especialista aquí, tendremos que buscarlo”?
Si el hackathon es de comida, sí, me estoy preparando. Unas semanas antes, decido qué voy a hacer, descubro quién podría ser útil y reúno un equipo de amigos o participantes de hackatones anteriores.
¿Es realmente posible hackear un hackathon solo? ¿Qué hacer si no hay equipo?
Los hackathons de ciencia de datos son reales (yo soy un ejemplo vivo de esto), no he visto hackathons de comestibles, aunque también lo creo. Desafortunadamente, a veces los organizadores imponen un límite al número mínimo de participantes en un equipo. Creo que esto se debe al hecho de que no todos los "solitarios" llegan a la final (es decir, simplemente salen con las primeras dificultades), la participación en el equipo todavía se frena. Incluso después del evento, se espera que continúe trabajando en el proyecto. Será más fácil hacer realidad el proyecto con un equipo.
En general, mi consejo es participar siempre en equipo. Si no tienes tu propio equipo, los organizadores siempre te ayudarán a encontrar o crear uno.
¿Cómo afrontas la fatiga durante un hackathon?
En el hackathon te dan 2 días para trabajar, es decir, 48 horas (30-48 horas, tomemos 48 para facilitar la cuenta). Eliminamos el tiempo para dormir (16-20 horas), dejando no más de 30. De estas, 8 horas (en promedio) se dedicarán al trabajo productivo. Si organiza su trabajo correctamente (sueño, nutrición, salidas al aire libre, ejercicios, minutos de atención plena, comunicación adecuada con el equipo y cambio de actividades), las horas de trabajo profundo se pueden aumentar a 12-14. Después de ese trabajo te sentirás agotado, pero será un cansancio agradable. Codificar sin dormir y sin descansos, interrumpidos por bebidas energéticas, es una receta para el fracaso.
¿Tiene sus propios canales preparados para hackathons? ¿Cómo los conseguiste, cómo están organizados (están en carpetas con archivos .py, cada uno para su propia tarea, etc.) y cómo empezar a crearlos tú mismo?
No utilizo soluciones completamente listas para usar de hackatones anteriores en los nuevos, pero tengo mi propio zoológico de modelos y canalizaciones de competiciones pasadas. No tengo que reescribir piezas estándar desde cero (por ejemplo, una codificación de destino correcta o una cuadrícula simple para extraer la intención del texto), lo que me ahorra mucho tiempo.
Por el momento, se ve así: para cada competencia o hackathon hay su propio repositorio en GitHub, en él se almacenan cuadernos, scripts y pequeña documentación sobre lo que está sucediendo. Además, hay un repositorio separado para todo tipo de "trucos" en cuadros (como la codificación de destino correcta con validación cruzada). No creo que esta sea la solución más elegante, pero por ahora me conviene.
Comenzaría guardando todo mi código en carpetas y escribiendo documentación breve (por qué, qué, cómo lo hice y el resultado).
¿Es realista preparar un MVP desde cero en tan poco tiempo o todos los participantes vienen con soluciones ya preparadas?
Sólo puedo decir sobre proyectos relacionados con la ciencia de datos: sí, es posible. MVP para mí es una combinación de dos factores:
- Una idea viable presentada como producto (es decir, pintada en un lienzo empresarial). Siempre debe haber una comprensión clara de por qué y para quién fabricamos un producto. A veces proyectos con un diseño bien fundamentado, pero sin prototipo, ganan premios, y esto no es de extrañar. Desafortunadamente, muchos participantes no pueden ignorar la amargura de la derrota y atribuyen sus fracasos a la miopía de los organizadores, que continúan cortando modelos para alguien desconocido en los próximos hackatones.
- Algún indicador de que puedes hacer este producto (aplicación, código, descripción de pipelines).
Sucede que un equipo llega a un hackathon con una solución ya preparada e intenta "adaptarla" a las instrucciones de los organizadores. Estos equipos son aislados durante el control técnico o sólo se "cuenta" la parte que hicieron en el sitio. No he visto a estos equipos como ganadores, pero creo que todavía les resulta rentable jugar debido al valor futuro ().
¿Hay algún ejemplo de cómo llevar las artesanías implementadas en hackathons a producción/inicio?
Sí. Tuve tres casos cuando lo llevaron a producción. Una vez yo mismo, dos veces, con las manos de otra persona, según mis ideas y el código que escribí en el hackathon. También conozco a un par de equipos que continuaron cooperando con la empresa como consultores. No sé los resultados finales, pero lo más probable es que se haya completado algo. Yo no he organizado startups y no sé si nadie lo ha hecho, aunque estoy seguro de que hay ejemplos.
Después de participar en muchos hackathons, ¿qué consejo te darías si pudieras retroceder en el tiempo?
- Las tácticas son más importantes que las maniobras. Piense en cada solución como un producto terminado. Una idea, un portátil Júpiter, un algoritmo, no valen nada si no está claro quién los pagará.
- Antes de diseñar cualquier cosa, responda no a la pregunta “¿qué?”, sino “¿por qué?” ¿Y cómo?". Ejemplo: al diseñar cualquier solución de ML, primero piense en el algoritmo ideal: ¿qué recibe como entrada y cómo se utilizan sus predicciones en el futuro?
- Sé parte de un equipo.
¿Qué suelen alimentar en los hackathons?
Normalmente la comida en los hackathons es mala: pizza, bebidas energéticas, refrescos. Casi siempre la comida se organiza en forma de buffet (o mesa de servicio) ante el que hay una cola enorme. Por lo general, no proporcionan comida por la noche, aunque hubo un caso en una competencia en París donde se dejó comida durante la noche: papas fritas, rosquillas y cola. Me imagino el proceso de pensamiento de los organizadores: “Entonces, ¿qué comen los programadores allí? ¡Ah, exactamente! Patatas fritas, rosquillas, eso es todo. Démosles esta basura”. Al día siguiente les pregunté a los organizadores: “Chicos, ¿es posible hacer algo diferente para la noche? Bueno, ¿tal vez un poco de avena? Después de eso me miraron como si fuera un idiota. Famosa hospitalidad francesa.
En los buenos hackathons, la comida se pide en cajas, hay una división en comida normal, vegetariana y kosher. Además, pusieron una nevera con yogures y muesli, para aquellos que quieran tomar un refrigerio. Té, café, agua: estándar. Recuerdo el hackathon Hack Moscú 2: me alimentaron de todo corazón con borscht y chuletas con puré de patatas en el comedor de la oficina de 1C.
¿La cordura de los hackathons depende, por así decirlo, del ámbito profesional de los organizadores (por ejemplo, los mejores hackathons los llevan a cabo consultores)?
Los mejores hackatones fueron de organizadores que ya habían organizado hackatones antes o habían participado en ellos antes. Quizás este sea el único factor del que depende la calidad del evento.
¿Cómo entender que no eres un novato y que es hora de un hackathon?
El mejor momento para asistir a un hackathon es hace un año. El segundo mejor momento es ahora. Así que adelante, comete errores, aprende, está bien. Incluso una red neuronal, el mayor invento del hombre desde la rueda y el aumento de gradiente sobre los árboles, no puede distinguir un gato de un perro en la primera época del entrenamiento.
¿Qué “banderas rojas” indican inmediatamente que el evento no será muy bueno y no hay necesidad de perder el tiempo?
- Una descripción clara de lo que se debe hacer (relevante para hackatones de productos). Si durante el registro se le asigna una tarea clara, es mejor quedarse en casa. En mi memoria no había ni un solo hackathon bueno con especificaciones técnicas. A modo de comparación: está bien, haznos algo relacionado con el análisis de conversaciones de audio. Malo: haznos una aplicación que pueda dividir una conversación en dos pistas de audio separadas para cada persona.
- Pequeño fondo de premios. Si te piden que hagas “Tinder para una tienda online con IA” y el premio para el primer lugar es de 500 euros y un equipo mínimo de 5 personas, probablemente no valga la pena perder el tiempo (sí, este es un verdadero hackathon que fue celebrada en Múnich).
- Falta de datos (relevante para hackatones de ciencia de datos). Los organizadores suelen proporcionar información básica sobre el evento y, a veces, un conjunto de datos de muestra. Si no te lo han facilitado, pregunta, no te costará nada. Si dentro de 2 o 3 no está claro qué datos se proporcionarán y si se proporcionarán en absoluto, esto es una señal de alerta.
- Nuevos organizadores. No seas perezoso y busca en Google información sobre los organizadores del hackathon. Si es la primera vez que se celebra un evento de este tipo, existe una alta probabilidad de que algo salga mal. Por otro lado, si el organizador y los miembros del jurado ya han realizado hackathons o han participado activamente en el pasado, esto es una señal de alerta.
En un hackathon me dijeron: “Tuviste la mejor solución en poco tiempo, pero lo siento, evaluamos el trabajo en equipo y tú trabajaste solo. Ahora bien, si llevaras a un estudiante o una chica a tu equipo…”? ¿Alguna vez te has encontrado con tal injusticia? ¿Cómo te las arreglaste?
Sí, lo he encontrado más de una vez. Soy estoico ante todo lo que pasa: hice todo lo que estuvo a mi alcance, si no salió bien, que así sea.
¿Por qué estás haciendo todo esto?
Todo esto es sólo por aburrimiento.
Fuente: habr.com