Share
Se sei mai stato a una conferenza focalizzata sul codice, puoi sicuramente attestare il fatto che il numero di discorsi live-coding è incredibilmente basso. Il motivo per cui è ovvio: sono super, super hard! Immagina di programmare sul palco di fronte a centinaia di persone, quando, all'improvviso, qualcosa va storto e il tuo codice si rompe! Nella vita reale, alcuni minuti di debugging non sono un problema. Sul palco, anche un singolo momento di silenzio è l'incubo di un oratore.
Quindi, non dovremmo mai tentare simili discorsi? Assolutamente no! Devi semplicemente prepararti nel modo giusto. Fornirò alcuni suggerimenti in questo articolo.
Cos'è il codice in tempo reale? Questo si riferisce a uno stile di presentazione, in cui l'oratore limita il numero delle sue diapositive, a favore della scrittura degli esempi o delle demo in tempo reale. È uno stile di discorso incredibilmente pericoloso, ma può offrire vantaggi significativi per il pubblico.
Se sei di tipo nervoso, potrebbe non essere una buona scelta.
Certamente, quando si prepara un nuovo discorso, la domanda più importante da porsi è se c'è un valore nel fare una presentazione di codifica dal vivo. Ad esempio, se stai semplicemente fornendo una varietà di esempi, hai veramente bisogno di codificarli in tempo reale? Una diapositiva ben presentata non funzionerebbe altrettanto bene, alleviando allo stesso tempo lo stress e il potenziale di rottura?
Potresti prendere in considerazione l'idea di utilizzare il percorso di codifica dal vivo nei seguenti casi:
Personalmente, ti esorto a prendere le diapositive, a meno che tu non sia in grado di fornire un argomento abbastanza valido sul motivo per cui non saranno altrettanto efficaci. La codifica dal vivo richiede una quantità significativa di preparazione, così come piani di backup, per contrastare qualsiasi potenziale ostacolo che potrebbe sorgere durante la codifica. Tienilo a mente. Se sei di tipo nervoso, potrebbe non essere una buona scelta.
Pratica. Pratica. E quando hai finito, pratica ancora un po '.
Chiaramente, ogni discorso dovrebbe essere provato almeno una volta o due prima di essere dato di fronte a un pubblico dal vivo. Tuttavia, se intendi codificare in tempo reale, come regola di base, triplica il numero di prove. Codifica una volta la conversazione e poi ripeti il processo; più ripetizioni, meglio è!
Quando parli sul palco, dovresti aspettarti di oscurare almeno un paio di volte.
Queste insicurezze esistono in tutti gli oratori. Il modo più semplice per evitare il maggior numero possibile di errori è conoscere l'argomento (e come lo presenterai) e umanamente possibile. Pratica. Pratica. E quando hai finito, pratica ancora un po '.
Il tuo primo passo dovrebbe essere quello di aspettarti il peggio.
Quindi hai deciso di portare avanti una presentazione dal vivo in stile workshop. Buon per te! Il tuo primo passo dovrebbe essere quello di aspettarti il peggio. Chiediti: "Cosa succede se mi schianto e brucio completamente? E se la mia mente fosse vuota?"
Ho sempre salvato una copia del progetto finito prima del mio intervento. In questo modo, se il palco si ritirasse da me, per così dire, potrei sempre fare uno scherzo informale, autoironico, osservando come chiaramente non sono abbastanza talentuoso per eseguire questo tipo di discorso. Quindi, posso passare rapidamente al codice finito e fare del mio meglio per continuare da lì.
Uso religiosamente un'app per Mac, chiamata Dash.
Inoltre, considera la possibilità di creare una serie di piccoli frammenti, che possono rappresentare qualsiasi cosa, da una singola funzione, a un po 'di HTML, a un set di regole CSS. Ciò può servire a diversi scopi:
Io uso religiosamente un'app per Mac, chiamata Dash, tuttavia qualsiasi espansione di testo (o anche la funzionalità di creazione di snippet del tuo editor di codice) farà bene il trucco.
Pensa a ogni riga come a un debito mentale.
Ricorda: la codifica dal vivo non è una scusa per dimostrare quanto sei intelligente, o quanto velocemente puoi manovrare attorno al tuo editor di codice. L'obiettivo finale è, naturalmente, quello di insegnare al pubblico qualcosa che non sapevano prima di salire sul palco. Con questo in mente, fai del tuo meglio per strutturare il codice che scrivi in modo da non travolgere il pubblico. Certo, questo richiede un po 'di armeggiare per raggiungere l'equilibrio perfetto.
Come linea guida, scegli sempre il percorso più semplice attraverso il tuo codice. Se un pezzo di logica non è vitale per ciò che stai tentando di trasmettere al pubblico, allora taglialo (forse con un rapido avvertimento che, in un progetto del mondo reale, probabilmente aggiungerei un po 'di più qua e là ).
Fai del tuo meglio per essere incredibilmente sensibile a ogni linea che scrivi nel corso della tua presentazione. Pensa a ogni linea aggiunta come al debito mentale. Il pubblico è una spugna; alla fine, hanno assorbito tutto ciò di cui sono capaci in una seduta di quarantacinque minuti. Mantienilo semplice.
Parlare sul palco è un'esperienza spaventosa. Codificare sul palco è anche peggio!
Non ci sono due modi per farlo: parlare sul palco è un'esperienza spaventosa. Codificare sul palco è anche peggio! Se sei di tipo nervoso, trova un modo per rimuovere l'energia in eccesso un'ora prima di andare sul palco. L'energia meno sviluppata che hai quando parli, meno probabile è che le tue mani si agitino incontrollabilmente. Ecco alcuni suggerimenti:
Evita la tendenza a scrivere silenziosamente sul palco.
Come sviluppatori, trascorriamo la maggior parte dei nostri giorni di lavoro in silenzio, codificando. Ma, se scegli di cimentarti in una presentazione di codifica dal vivo, si verificherà un'interessante transizione: non solo codificherai, ma parlerai anche tu attraverso il processo, illustrando verbalmente ogni riga di codice.
Non dimenticare di continuare a parlare! Evita la tendenza a digitare silenziosamente sul palco. Questo è un modo unidirezionale per una recensione negativa. La chiave è riformulare ogni singola riga di codice in modo che chiunque nel pubblico possa capire, indipendentemente dal loro livello di abilità.
A volte, tutto si riduce a un po 'di fortuna.
Guarda: c'è una ragione per cui gli sviluppatori considerano ampiamente una presentazione dal vivo come estremamente pericolosa e raramente di successo. Se non sono preparati in modo adeguato, non appena le cose vanno male (e lo faranno), il pubblico rabbrividirà, mentre ti guardano in silenzio, ma tentano disperatamente di correggere il tuo errore.
A volte, però, tutto si riduce a un po 'di fortuna. Preparati come un matto, incrocia le dita e spera per il meglio. Se hai successo, potresti semplicemente mostrare al pubblico qualcosa che raramente (se mai) riesci a vedere in una conferenza. In bocca al lupo!
Accentsconagua