Hvis du noen gang har vært på en kodefokusert konferanse før, kan du helt sikkert bekrefte at antall live-kodende samtaler er utrolig lave. Grunnen til at det er åpenbart: de er super, super harde! Forestill deg koding på scenen foran hundrevis av mennesker, når plutselig, går noe feil, og koden din bryter! I virkeligheten er et par minutter med feilsøking et ikke-problem. På scenen er selv et øyeblikk av stillhet et høyttalers mareritt.
Så bør vi aldri forsøke slike samtaler? Absolutt ikke! Du må bare forberede seg på de riktige måtene. Jeg gir noen tips i denne artikkelen.
Hva er Live Coding? Dette refererer til en presentasjonsstil, hvor høyttaleren begrenser antallet av hans eller hennes lysbilder, til fordel for å skrive eksemplene eller demoene i sanntid. Det er en utrolig farlig stil, men kan gi betydelige fordeler for publikum.
Hvis du er nervøs, kan dette ikke være et godt valg.
Når du forbereder en ny samtale, er det absolutt viktig å spørre deg selv om det er noen verdi i å gjøre en live-kodende presentasjon. For eksempel, hvis du bare gir en rekke eksempler, trenger du virkelig å kode dem i sanntid? Ville en godt presentert lysbilde ikke fungere like bra, samtidig som du lindrer litt stress og potensialet for brudd?
Du kan vurdere å ta den levende kodende ruten i følgende tilfeller:
Personlig vil jeg oppfordre deg til å komme til lysbildene, med mindre du kan gi et godt nok argument om hvorfor de ikke vil være like effektive. Live-koding krever betydelig forberedelse, samt sikkerhetskopieringsplaner, for å motvirke eventuelle potensielle blokkeringer som kan oppstå når du kodes. Husk på det. Hvis du er nervøs, kan dette ikke være et godt valg.
Øve på. Øve på. Og når du er ferdig, trene litt mer.
Klart, hver samtale bør repeteres minst en eller to ganger før de blir gitt foran et levende publikum. Men hvis du har tenkt å kode i sanntid, som en grunnleggende tommelfingerregel, tredobles antall repetisjoner. Kode deg gjennom samtalen en gang, og gjenta prosessen; Jo flere repetisjoner, desto bedre!
Når du snakker på scenen, bør du fullt ut forvente å blinke minst et par ganger.
Disse usikkerhetene finnes i alle høyttalere. Den enkleste måten å forhindre så mange feil som mulig er å kjenne emnet (og hvordan du presenterer det) så vel som menneskelig mulig. Øve på. Øve på. Og når du er ferdig, trene litt mer.
Ditt første skritt bør være å forvente det verste.
Så du har bestemt deg for å presse frem med en live workshop-presentasjon. Bra for deg! Ditt første skritt bør være å forvente det verste. Spør deg selv, "Hva skjer hvis jeg helt krasjer og brenner? Hva om tankene mine?"
Jeg lagrer alltid en kopi av det ferdige prosjektet foran diskusjonen min. På den måten skal scenen slippe ut fra under meg, så jeg kan alltid lage en uformell, selvsikkerhet, og se hvordan jeg tydeligvis ikke er talentfull nok til å utføre denne stilen. Da kan jeg raskt bytte til den ferdige koden, og gjør mitt beste for å fortsette derfra.
Jeg bruker religiøst en Mac-app, kalt Dash.
I tillegg bør du vurdere å lage en rekke mindre utdrag, som kan representere alt fra en enkelt funksjon, til litt HTML, til en CSS-regelsett. Å gjøre det kan tjene noen forskjellige formål:
Jeg bruker religiøst en Mac-app, kalt Dash, men en hvilken som helst tekstutvidelse (eller til og med kodeditorens brikkeopprettingsfunksjonalitet) vil gjøre trikset pent.
Tenk på hver linje som mental gjeld.
Husk: Live koding er ikke en unnskyldning for å demonstrere hvor smart du er, eller hvor raskt du kan manøvrere rundt kodeditoren din. Målet er selvsagt å lære publikum noe de ikke visste før du gikk på scenen. Med det for øye, gjør ditt beste for å strukturere koden du skriver på en måte som ikke overvelder publikum. Ganske vist krever dette litt tinkering for å oppnå den perfekte balansen.
Som en retningslinje, velg alltid den enkleste ruten gjennom koden din. Hvis et logikk ikke er avgjørende for det du prøver å formidle til publikum, så kutt det ut (kanskje med en rask advarsel om at du i et virkelighetsprosjekt vil legge til litt mer her og der ).
Gjør ditt beste for å være utrolig følsom for hver linje du skriver i løpet av presentasjonen din. Tenk på hver ekstra linje som mental gjeld. Publikum er en svamp; Til slutt har de gjennomvåt alt det de kan i ett førtifem minutt sittende. Hold det enkelt.
Å snakke på scenen er en skummel opplevelse. Koding på scenen er enda verre!
Det er ikke to måter å snakke om: å snakke på scenen er en skummel opplevelse. Koding på scenen er enda verre! Hvis du er nervøs, finn noen måte å fjerne overflødig energi en time før du går på scenen. Jo mindre oppbygget energi du har når du snakker, jo mindre sannsynlig at hendene dine vil riste ukontrollert. Her er noen tips:
Unngå tendensen til å skrive bort stille på scenen.
Som utviklere bruker vi de fleste av våre arbeidsdager i stillhet, koding bort. Men en interessant overgang vil finne sted, hvis du velger å prøve deg på en live kodende presentasjon: Ikke bare vil du være kodende, men du vil også snakke deg gjennom prosessen, muntlig illustrere hver linje av kode.
Ikke glem å fortsette å snakke! Unngå tendensen til å skrive stille på scenen. Dette er en envei til billett til en dårlig anmeldelse. Nøkkelen er å omformulere hver enkelt linje med kode på en måte som alle i publikum kan forstå, uavhengig av deres ferdighetsnivå.
Noen ganger kommer det hele til litt lykke.
Se, det er en grunn til at utviklere ser mye på en live-kodende presentasjon for å være utrolig farlig og sjelden vellykket. Hvis ikke forberedt på tilstrekkelig nok, så snart ting går galt (og de vil), vil publikum krype, mens de ser deg stille, men desperat forsøker å rette opp feilen din.
Noen ganger, men alt kommer ned til litt lykke. Forbered deg som gal, kryss fingrene, og håper på det beste. Hvis du lykkes, kan du bare vise publikum noe de sjelden (hvis noensinne) kommer til å se på en konferanse. Lykke til!