Share
Om du någonsin varit med på en kodfokuserad konferens innan kan du säkert bevisa att antalet live-kodande samtal är otroligt lågt. Anledningen till att det är uppenbart: de är supera, super svåra! Föreställ dig att du kodar på scen framför hundratals människor, när allt plötsligt, något går fel, och din kod bryts! I det verkliga livet är några minuters debugging ett icke-problem. På scenen är även ett enda ögonblick av tystnad en högtalares mardröm.
Så ska vi aldrig försöka med sådana samtal? Absolut inte! Du måste helt enkelt förbereda på rätt sätt. Jag ger några tips i den här artikeln.
Vad är Live Coding? Detta hänvisar till en presentationsstil, där talaren begränsar antalet hans eller hennes bilder, för att skriva exemplen eller demon i realtid. Det är en otroligt farlig typ av pratstund, men kan ge betydande fördelar för publiken.
Om du är nervös, kan det här inte vara ett bra val.
Visserligen, när du förbereder ett nytt samtal, är den viktigaste frågan att fråga dig själv om det finns något värde i att göra en live-kodande presentation. Om du till exempel bara ger en rad exempel, behöver du verkligen koda dem i realtid? Skulle en väl presenterad glid inte fungera lika bra, samtidigt som du lindrar dig av lite stress och potentialen för brott?
Du kan överväga att ta live-kodningsvägen i följande fall:
Personligen vill jag uppmana dig att nå fram till bilderna, om inte du kan ge ett tillräckligt bra argument om varför de inte kommer att vara lika effektiva. Live-kodning kräver en betydande mängd förberedelser samt säkerhetskopieringsplaner, för att motverka eventuella väsentliga blockblock som kan uppstå när du kodar. Kom ihåg det. Om du är nervös, kan det här inte vara ett bra val.
Öva. Öva. Och när du är klar, öva lite mer.
Det är uppenbart att varje prat bör repeteras minst en eller två gånger innan den ges framför en levande publik. Men om du tänker koda i realtid, som en grundläggande tumregel, tripplar du antalet repetitioner. Koda dig igenom talet en gång och upprepa sedan processen. ju fler repetitioner desto bättre!
När du talar på scenen borde du helt förvänta sig att vara tom minst ett par gånger.
Dessa osäkerheter finns i alla högtalare. Det enklaste sättet att förhindra så många fel som möjligt är att känna till ämnet (och hur du presenterar det) såväl som mänskligt möjligt. Öva. Öva. Och när du är klar, öva lite mer.
Ditt första steg bör vara att förvänta sig det värsta.
Så du har bestämt dig för att driva fram med en live-presentationsstil. Bra för dig! Ditt första steg bör vara att förvänta sig det värsta. Fråga dig själv: "Vad händer om jag kraschar helt och brinner? Vad händer om mitt sinne blanks?"
Jag sparar alltid en kopia av det färdiga projektet före mitt samtal. På så sätt skulle scenen falla ut från under mig, så att säga kan jag alltid göra ett avslappet, självförstörande skämt och notera hur jag tydligt inte är tillräckligt talangfull för att utföra denna typ av prat. Sedan kan jag snabbt byta till den färdiga koden och göra mitt bästa för att fortsätta vidare därifrån.
Jag använder religiöst en Mac-app, kallad Dash.
Dessutom överväga att skapa en mängd mindre utdrag, som kan representera allt från en enda funktion, till en viss HTML, till en CSS-regler. Att göra det kan tjäna några olika syften:
Jag använder religiöst en Mac-app, kallad Dash, men vilken textutvidgare (eller till och med kodredigeringsprogrammets kodningsfunktionalitet) gör tricket snyggt.
Tänk på varje linje som mental skuld.
Kom ihåg: live kodning är inte en ursäkt för att visa hur smart du är, eller hur snabbt du kan manövrera runt kodredigeraren. Slutmålen är givetvis att lära publiken något som de inte visste innan du steg på scenen. Med det i åtanke, gör ditt bästa för att strukturera koden som du skriver på ett sätt som inte överväldigar publiken. Visserligen krävs det lite tinkering för att uppnå den perfekta balansen.
Som riktlinje väljer du alltid den enklaste vägen genom din kod. Om en logik inte är avgörande för vad du försöker vidarebefordra till publiken, klippa ut det (kanske med en snabb varning att i ett verkligt världsprojekt skulle du troligen lägga lite mer här och där ).
Gör ditt bästa för att vara otroligt känslig för varje rad som du skriver under din presentation. Tänk på varje extra linje som mental skuld. Publiken är en svamp; så småningom har de blivit uppslukade allt som de kan klara i en fyrtiofem minuters sittande. Håll det enkelt.
Att prata på scenen är en läskig upplevelse. Kodning på scenen är ännu värre!
Det finns inga två sätt på det: att tala på scenen är en läskig upplevelse. Kodning på scenen är ännu värre! Om du är nervös, hitta något sätt att ta bort överflödig energi en timme innan du går på scenen. Den mindre uppbyggda energin du har när du talar, desto mindre sannolikt kommer dina händer att skaka okontrollerbart. Här är några tips:
Undvik tendensen att skriva tyst på scenen.
Som utvecklare spenderar vi majoriteten av våra arbetsdagar i tystnad och kodar bort. Men en intressant övergång kommer att äga rum om du väljer att pröva din hand vid en live-kodande presentation: Du kommer inte bara att koda, men du kommer också att prata dig igenom processen, som muntligt illustrerar varje rad kod.
Glöm inte att fortsätta prata! Undvik tendensen att skriva tyst på scenen. Detta är en enkel väg till biljett till en dålig recension. Nyckeln är att omformulera varje enskild kodlinje på ett sätt som alla i publiken kan förstå, oavsett deras kompetensnivå.
Ibland kommer allt till lite tur.
Titta: Det finns en anledning till att utvecklare anser att en live-kodande presentation är otroligt farlig och sällan framgångsrik. Om inte förberedd för tillräckligt nog, så snart sakerna går fel (och de kommer), kommer publiken att krypa, när de ser dig tyst, men försöker desperat att rätta till ditt misstag.
Ibland kommer det hela till lite tur. Förbered dig som galen, korsa dina fingrar och hoppas på det bästa. Om du lyckas kan du bara visa publiken något som de sällan (om någonsin) får se på en konferens. Lycka till!
Accentsconagua