Den sidste del af hackathon-trilogien. I Jeg talte om motivationen for at deltage i sådanne arrangementer. var dedikeret til arrangørernes fejl og deres resultater. Den sidste del vil besvare spørgsmål, der ikke passede ind i de to første dele.
Fortæl os, hvordan du startede med at deltage i hackathons.
Jeg læste til en kandidatgrad på University of Lappeenranta, mens jeg løste konkurrencer i dataanalyse. Min typiske dag så sådan ud: at stå op klokken 8, et par par på universitetet, så konkurrencer og kurser indtil midnat (mens afleveringen tæller, ser jeg forelæsninger eller læser artikler). Sådan en stram tidsplan bar frugt, og jeg vandt MERC-2017 dataanalysekonkurrencen (som endda blev diskuteret ). Sejren gav mig selvtillid, og da jeg ved et uheld stødte på information om SkinHack 2 hackathon i Moskva, besluttede jeg at besøge mine forældre og samtidig finde ud af, hvad et hackathon er.
Selve hackathonet viste sig at være ret sjovt. Der var to spor på dataanalyse med klare målinger og et datasæt med præmiepenge på 100 rubler. Det tredje spor var om app-udvikling med en præmie på 50k, og der var ingen deltagere. På et tidspunkt sagde arrangøren, at et vindue med en knap uden funktionalitet kunne vinde 50k, fordi præmien ikke kunne udbetales. Jeg begyndte ikke at lære at programmere applikationer (jeg konkurrerer ikke, hvor jeg nemt kan blive "vendt"), men for mig var det en klar besked om, at felterne i hackathons ikke er overfyldte.
Så løste jeg begge dataanalysespor alene. Jeg fandt en lækage i dataene, der gjorde det muligt for mig at få den ideelle hastighed, men kolonnen med lækagen var ikke i de testdata, som jeg modtog to timer før afslutningen af begivenheden (i øvrigt forstod jeg, at tilstedeværelsen af en "mål"-søjle i toget tæller ikke som en lækage ). Samtidig åbnede ranglisten, min indsendelse uden ansigt tog tredjepladsen ud af fem, der var et stort hul til den første, og jeg besluttede ikke at spilde tiden og gik.
Efter at jeg med et frisk sind havde analyseret, hvad der skete, fandt jeg en masse fejl (en af mine vaner er mentalt at scrolle gennem, hvad der skete med notesblokken og analysere fejlene, deres årsag, og hvad der kunne have været ændret - sådan en behagelig arv af et semi-professionelt pokerspil). Men én ting stod klart – der er meget værdi i hackathons, og jeg var simpelthen nødt til at implementere det. Efter denne begivenhed begyndte jeg at overvåge begivenheder og grupper, og det efterfølgende hackathon lod ikke vente på sig. Så endnu en, og endnu en...
Hvorfor laver du hackathons og ikke Kaglo?
Jeg kan ikke lide Kagle i øjeblikket. Fra et bestemt færdighedsniveau, uden særlige grunde til deltagelse, bliver kagle mindre nyttig end andre aktiviteter. Jeg deltog meget før, det lykkedes mig åbenbart på en eller anden måde at "komme af".
Hvorfor hackathons og ikke arbejde på dit eget projekt?
Jeg kan godt lide ideen om at lave noget fedt med mine egne hænder i et langsomt tempo. Fyrene fra ODS organiserede for alle, der vil bruge weekenden på at arbejde på deres projekt med ligesindede. Jeg tror, at jeg snart slutter mig til dem.
Hvordan finder du begivenheder?
Hovedkilde - hackathon.com (verden) og telegramchat (Rusland). Derudover vises meddelelser om begivenheder i annoncer på sociale netværk og på linkedin. Hvis du ikke finder noget, kan du se her: mlh.io, devpost.com, hackevents.co, hackalist.org, HackathonsNear.me, hackathon.io.
Udarbejder du en løsningsplan, inden du deltager, eller er alt afgjort i farten? For eksempel, en uge før hackathonet, tænker du: "Vi får brug for sådan en specialist her, vi bliver nødt til at lede efter den"?
Hvis hackathonet er til mad, ja, jeg gør mig klar. Et par uger før finder jeg ud af, hvad jeg skal gøre, finder ud af, hvem der kan være nyttige, og samler et hold venner eller deltagere fra tidligere hackathons.
Er det virkelig muligt at hacke et hackathon alene? Hvad skal man gøre, hvis der ikke er noget hold?
Data science hackathons er ægte (jeg er et levende eksempel på dette), jeg har ikke set købmandshackathons, selvom jeg også tror det. Desværre sætter arrangører nogle gange en grænse for minimumsantallet af deltagere på et hold. Jeg tror, det skyldes det faktum, at ikke alle "enspændere" når finalen (det vil sige, de går simpelthen med de første vanskeligheder); deltagelse i et hold holder stadig tilbage. Selv efter arrangementet forventes det, at du fortsætter arbejdet med projektet. Det bliver nemmere at føre projektet ud i livet med et team.
Generelt er mit råd altid at deltage med et hold. Hvis du ikke har dit eget hold, hjælper arrangørerne dig altid med at finde eller oprette et.
Hvordan takler du træthed under et hackathon?
Ved hackathon får du 2 dage til at arbejde, det er 48 timer (30-48 timer, lad os tage 48 for at tælle). Vi fjerner tid til søvn (16-20 timer), og efterlader ikke mere end 30. Heraf vil 8 timer (i gennemsnit) faktisk blive brugt på produktivt arbejde. Hvis du tilrettelægger dit arbejde korrekt (søvn, ernæring, ud i den friske luft, øvelser, minutter af mindfulness, ordentlig kommunikation med teamet og skiftende aktiviteter), så kan dybe arbejdstimer øges til 12-14. Efter sådan arbejde vil du føle dig udmattet, men det vil være behagelig træthed. Kodning uden søvn og pauser, afbrudt af energidrikke, er en opskrift på fiasko.
Har du dine egne færdige pipelines til hackathons? Hvordan har du fået dem, hvordan er de organiseret (de er i mapper med .py-filer, hver til sin opgave osv.) og hvordan begynder du selv at oprette disse?
Jeg bruger ikke helt færdige løsninger fra tidligere hackathons i nye, men jeg har min egen zoo af modeller og pipelines fra tidligere konkurrencer. Jeg behøver ikke at omskrive standardstykker fra bunden (for eksempel korrekt målkodning eller et simpelt gitter til at udtrække hensigter fra tekst), hvilket sparer mig for meget tid.
I øjeblikket ser det sådan ud: For hver konkurrence eller hackathon er der sin egen repo på GitHub, den gemmer notesbøger, scripts og lille dokumentation om, hvad der sker. Derudover er der en separat repo for alle slags "tricks" i boks (som korrekt målkodning med krydsvalidering). Jeg synes ikke det er den mest elegante løsning, men det passer mig lige nu.
Jeg ville starte med at gemme al min kode i mapper og skrive kort dokumentation (hvorfor, hvad, hvordan jeg gjorde det og resultatet).
Er det realistisk at forberede en MVP fra bunden på så kort tid eller kommer alle deltagere med færdige løsninger?
Jeg kan kun sige om projekter relateret til datavidenskab - ja, det er muligt. MVP for mig er en kombination af to faktorer:
- En levedygtig idé præsenteret som et produkt (dvs. malet på et forretningslærred). Der skal altid være en klar forståelse af, hvorfor og til hvem vi laver et produkt. Nogle gange vinder projekter med et velbegrundet design, men uden en prototype, præmier, og det er ikke overraskende. Desværre kan mange deltagere ikke ignorere nederlagets bitterhed og tilskrive deres fejl til arrangørernes kortsynethed, idet de fortsætter med at skære modeller for en ukendt person ved de næste hackathons.
- Nogle indikatorer på, at du kan lave dette produkt (applikation, kode, beskrivelse af rørledninger).
Det sker, at et hold kommer til et hackathon med en færdiglavet løsning og forsøger at "skræddersy" den til arrangørernes instruktioner. Sådanne hold afbrydes under teknisk screening, eller kun den del, de lavede på webstedet, "tælles". Jeg har ikke set sådanne hold som vindere, men jeg tror stadig, det er rentabelt for dem at spille på grund af den fremtidige værdi ().
Er der eksempler på at bringe håndværk implementeret ved hackathons til produktion/startup?
Ja. Jeg havde tre sager, da de bragte den i produktion. Én gang mig selv, to gange - med en andens hænder, baseret på mine ideer og kode, som jeg skrev på hackathonet. Jeg kender også et par teams, der fortsatte med at samarbejde med virksomheden som konsulenter. Jeg kender ikke de endelige resultater, men højst sandsynligt blev noget gennemført. Jeg har ikke selv organiseret startups, og det ved jeg ikke, at nogen har, selvom jeg er sikker på, at der er eksempler.
Efter at have deltaget i mange hackathons, hvilke råd ville du give dig selv, hvis du kunne gå tilbage i tiden?
- Taktik er vigtigere end manøvrer. Tænk på enhver løsning som et færdigt produkt. En idé, en Jupiter-laptop, en algoritme er intet værd, hvis det ikke er klart, hvem der skal betale for det.
- Inden du designer noget, skal du svare på spørgsmålet ikke "hvad?", men "hvorfor?" Og hvor?". Eksempel: Når du designer en ML-løsning, skal du først tænke på den ideelle algoritme: hvad modtager den som input, hvordan bruges dens forudsigelser i fremtiden?
- Vær en del af et team.
Hvad fodrer de normalt ved hackathons?
Normalt er maden ved hackathons dårlig: pizza, energidrikke, sodavand. Næsten altid er maden tilrettelagt i form af en buffet (eller serveringsbord), hvortil der er kæmpe kø. De giver normalt ikke mad om natten, selv om der var et tilfælde ved en konkurrence i Paris, hvor mad blev efterladt natten over - chips, donuts og cola. Jeg vil forestille mig arrangørernes tankeproces: "Så hvad spiser programmører der? Åh, præcis! Chips, donuts - det er alt. Lad os give dem dette affald." Dagen efter spurgte jeg arrangørerne: "Gunner, er det muligt at lave noget anderledes for natten? Nå, måske noget grød?” Efter det så de på mig, som om jeg var en idiot. Berømt fransk gæstfrihed.
Ved gode hackathons bestilles mad i kasser, der er opdeling i almindelige, vegetariske og kosher-måltider. Plus de sætter et køleskab med yoghurt og mysli - for dem, der vil have en snack. Te, kaffe, vand - standard. Jeg husker Hack Moscow 2 hackathon - de fodrede mig hjerteligt med borsjtj og koteletter med kartoffelmos i kantinen på 1C-kontoret.
Hackathons fornuft afhænger så at sige af arrangørernes professionelle sfære (for eksempel udføres de bedste hackathons af konsulenter)?
De bedste hackathons var fra arrangører, der enten havde arrangeret hackathons før eller deltaget i dem før. Måske er dette den eneste faktor, som kvaliteten af arrangementet afhænger af.
Hvordan forstår man, at du ikke er en noob, og det er tid til et hackathon?
Det bedste tidspunkt at tage til et hackathon er et år siden. Den næstbedste tid er nu. Så gå efter det, lav fejl, lær - det er okay. Selv et neuralt netværk - menneskets største opfindelse, siden hjulet og gradienten boostede over træer - kan ikke skelne en kat fra en hund i den første epoke af træning.
Hvilke "røde flag" indikerer umiddelbart, at begivenheden ikke bliver særlig god, og at der ikke er behov for at spilde tid?
- En klar beskrivelse af, hvad der skal gøres (relevant for produkthackathons). Hvis du under registreringen får en klar opgave, så er det bedre at blive hjemme. I min hukommelse var der ikke et eneste godt hackathon med tekniske specifikationer. Til sammenligning: Okay – gør os noget i forbindelse med at analysere lydsamtaler. Dårligt - lav os et program, der ville være i stand til at opdele en samtale i to separate lydspor for hver person.
- Lille præmiefond. Hvis du bliver bedt om at lave "Tinder til en online butik med AI", og præmien for førstepladsen er 500 euro og en minimumsholdstørrelse på 5 personer, er det nok ikke værd at spilde din tid (ja, det er et rigtigt hackathon, der var afholdt i München).
- Mangel på data (relevant for data science hackathons). Arrangører giver normalt grundlæggende oplysninger om begivenheden og nogle gange et eksempeldatasæt. Hvis de ikke har leveret det, så spørg, det vil ikke koste dig noget. Hvis det inden for 2-3 er uklart, hvilke data der vil blive leveret, og om de overhovedet vil blive leveret, er dette et rødt flag.
- Nye arrangører. Vær ikke doven og Google oplysninger om hackathon-arrangørerne. Hvis de afholder et arrangement af denne art for første gang, er der stor sandsynlighed for, at noget går galt. Hvis arrangøren og jurymedlemmerne derimod allerede har afholdt hackathons eller tidligere deltaget aktivt, er der tale om et grønt flag.
Ved et hackathon fortalte de mig: "Du havde den bedste løsning på kort tid, men undskyld, vi evaluerer teamwork, og du arbejdede alene. Nu, hvis du tog en studerende eller en pige til dit hold...”? Har du nogensinde oplevet en sådan uretfærdighed? Hvordan klarede du dig?
Ja, jeg har mødt det mere end én gang. Jeg er stoisk omkring alt, hvad der sker: Jeg gjorde alt, hvad der stod i min magt, hvis det ikke lykkedes, så må det være.
Hvorfor laver du alt det her?
Alt dette er bare af kedsomhed.
Kilde: www.habr.com