Hur man hackar i 5 enkla steg

Varför pratar inte fler om Hackathons? De är en spräng och levererar ofta gratis mat och spindlar. Men viktigast av allt är de ett utmärkt sätt för mjukvaruutvecklare att förbättra sin kompetensuppsättning på kort tid, samtidigt som de erbjuder icke-tekniska proffs en möjlighet att utföra en vision och få en idé till liv.

Om du är intresserad av att gå in i en, håller högskolor och teknikrelaterade organisationer dem hela tiden. Jag är stolt över att arbeta för ett företag (Asurion) som sponsrar en årlig hackathon, som producerar dussintals innovativa idéer och imponerande implementationer. Under årets händelse följde jag, utom att jag lyckades omge mig med stora teamkamrater, dessa fem steg för att optimera min hackathonupplevelse.

1. Välj något aktuellt

Många intressanta projekt kommer från hackathons, men efter att du varit på några kommer du att börja se några upprepningar. För att maximera nyheten, prova att välja en relativt ny teknik eller tema. Även om du inte vinner, lär du dig mer och utöka begränsningarna i din komfortzon.

Till exempel på grund av den enorma ökningen av hemassistentägande (129% år över år) beslutade vårt team att använda Amazon Echo för vårt hack. Vår tjänst, Soluto, ger omedelbart premiumstöd för teknikfrågor. Vi trodde att Echo kan vara en bekväm utgångspunkt för vår tjänst.

Din hackathon-idé behöver inte alltid förändra världen. Det kan vara något enkelt och roligt som inspireras av en spännande ny show, film eller spel. Jag deltog i min första hackathon för några år sedan när 2048 ursprungligen kom ut. Eftersom en av våra sponsorer var SendGrid, bestämde jag mig för att hacka ihop ett e-postdrivet 2048-spel. Det blev väl mottaget på grund av dess relevans vid den tiden.

2. Definiera en MVP

De flesta hackatoner varar mellan 24 och 72 timmar. Även om detta kan verka som att det är mycket tid att arbeta med, så är det inte, även om du tar med dig en sovsäck. Som sådan måste du definiera en minimalt hållbar produkt (MVP) som är möjligt för ditt team att skapa, samtidigt som du får tid att spara.

Du kan göra detta genom att begränsa din hack till några kärnfunktioner. Om din hack är för bred kommer varje funktion troligen att visas opolerad. Om du har idéer för hur du kan utöka din hack i framtiden, inkludera dem i din presentation som samtalspunkter. Publiken och domarna förlåter dig emellertid inte om du har en bra försäljningsnivå men inget konkret att visa för det.

Prisutdelning vid Asurion Hackathon 2017 (Nashville). Från vänster till höger: Barry Vandevier (domare och operatörspresident), Alex Hughes, Lucas Rudd, Jonathan Hughes, Daniel Cottone och Brandon Evans

3. Testa tredjepartsintegrationer tidigt

Många hacks använder applikationsprogrammeringsgränssnitt (API: er) för att integrera sin applikation med andra webbaserade tjänster. Du kan låta dina användare logga in via deras Google-konto, skicka ut tweets som kroniserar sin aktivitet i appen och mycket mer. Att använda API: er utvidgar din målgrupp, förenklar utvecklingsarbetet och berikar din användarupplevelse.

Tyvärr har API: er, genom design, sina begränsningar. Dessa tredjeparter arbetade mycket hårt för sina databaser och funktioner, och de kommer inte att låta dig använda dem utan dröjsmål. Vissa API: er kräver betalning, de flesta begränsar hur många samtal du kan ringa inom en viss tid och alla begränsar åtkomsten till deras data på något sätt. För att undvika missuppfattningar bör du testa ditt användningsfall för integration tidigt, kanske innan du skapar någon annan funktionalitet.

Jag lärde mig det på det svåra sättet. Vid ett tidigare hackathon satte mitt team in sig för att skapa en Facebook-applikation som identifierade vilka vänner du inte har interagerat med nyligen och gav dig möjligheten att återansluta dem. Vi byggde hela applikationen under första halvåret av hackathon innan vi startade API-integrationen. Det var bara ett problem: Facebook hindrar dig från att få information om dina vänner såvida de inte också har appen. Eftersom appen skulle vara värdelös tills en betydande del av befolkningen installerade den, var vi tvungna att helt omarbeta vår idé med mycket begränsad tid.

Vid Asurion Hackathon gynnade vi av att kunna använda interna API: er som vi har arbetat med tidigare. Ändå arbetade vi först med integrationerna, bara för att någonting skulle komma upp på vägen. Detta tillät oss att fokusera större delen av vår energi på att skapa och förfina användarupplevelsen.

4. Om det inte har gått sönder ska du inte fixa det

Om du har implementerat din MVP med tid att spara, kan du bli frestad att ändra den på något sätt. Ditt team bör inte ta detta beslut lätt. En hack är inte en redo att marknadsföra produkten. Sista minuten kodrefactoring har ingen plats vid en hackathon. Om din hack skulle kunna använda några ytterligare förbättringar eller funktioner som är vända mot användaren måste du utvärdera vilken risk kontra belöning för dessa förändringar är och ge dig själv tid att återhämta sig om något går fel. Minst skulle jag avstå från att göra några ändringar i hacket inom en timme efter din slutliga presentation. Vid någon tidpunkt måste du sluta bryta saker!

Detta betyder inte att du inte bör skapa en lista över möjliga ändringar att hantera vid en annan tidpunkt. Som tidigare nämnts är ett hack, om det görs rätt, bara en MVP, inte en färdig produkt. Men det borde inte hindra dig från att tänka på framtida iterationer av konceptet. Förhoppningsvis är ditt hack något du tror på, så känn dig fri att ta tillbaka projektet efter tävlingen är slut. Bara riskera inte att bryta något direkt innan din presentation. Talar om vilka…

5. Present som din hack beror på det (det gör det)

Vissa hackathons har sekventiella demonstrationer, medan andra har utställningar där domare checkar ut hacks på sin fritid. I vilket fall som helst spelar presentationen lika mycket, om inte mer, än själva hacket. Om du har ett fantastiskt projekt men inte kan förmedla dess awesomeness, vad är då poängen? Se till att ägna en betydande mängd av din tid åt att förbereda och öva din presentation.

Det är här att ha icke-utvecklare i ditt team kan vara oerhört användbart. Efter att ha definierat MVP kan dessa medlemmar i teamet planera hur de ska marknadsföra det parallellt med utvecklingen - så länge båda grupperna kommunicerar med varandra om stora förändringar. Utvecklare kan hjälpa till att fokusera på "vad", medan de andra hjälper till att förfina "varför".

Innan du planerar din tonhöjd måste du identifiera din publik. Om din hackathon bjuder in allmänheten att döma, kommer du att fånga deras uppmärksamhet och hålla den lätt på den snygga. Om du presenterar för företagens intressenter, integrera viktiga ekonomiska prognoser och exempel på mervärde för organisationen. Slutligen, om dina kolleger hackare betygsätter ditt projekt, gå över teknikbunten och visa upp komplikationerna i din arkitektur.

De mest minnesvärda presentationerna är vanligtvis de mest interaktiva. Det är en sak att bevittna ett program som används; det är en annan att uppleva det själv. Om du kan hitta ett sätt att tillåta publiken att demonstrera din produkt, gå till den (så länge du är medveten om dina potentiella kanter).

Om du följer dessa steg bör du lämna hackathon med en intressant, unik och väl genomförd leverans. Det betyder inte att du är garanterad att vinna, men det är mycket mindre viktigt än de färdigheter och erfarenheter du får genom att delta i dessa evenemang.

Om du är intresserad av att gå med i vårt team kan du gärna kolla in jobböppningarna i Soluto Nashville och skicka ett meddelande till mig!