Qual è il modo migliore per strutturare i workshop per l'avvio dei programmatori?

Sembra che tu sia sulla strada giusta, ma che gli studenti possano ottenere il materiale e usarlo giorno per giorno è necessario avere un po 'di tempo in cui possono portare il loro vero codice dal lavoro del giorno o da qualsiasi altra cosa, e pratica su quello.

Le aree di messa a fuoco e la struttura suonano bene. Alcuni pensieri:

• Dato che una volta la chiave è di introdurre le persone a pulire il codice, assicurati che ogni singolo pezzo di codice di esempio sia in realtà pulito a meno che tu lo stia usando come esempio negativo. Sembra un gioco da ragazzi, ma spesso il cattivo codice si insinua e rovina la tua reputazione (reputazione) come istruttore.
• Utilizza gli esempi negativi in modo costruttivo. Mostrare esempi negativi, specialmente quando non appartengono a nessuno nel gruppo, è spesso un modo per ottenere un coinvolgimento del gruppo nel processo, consente un buon brainstorming ("perché su earth fai X? "e così via) senza che sembrasse che tu stia attaccando uno qualsiasi dei discenti del gruppo. Puoi iniziare col trovare solo l'esempio peggiore possibile in assoluto, ma poi rendere meno difficili da criticare altri esempi negativi man mano che i workshop vanno avanti.
• Avere dei partecipanti responsabili di alcuni dei contenuti (tramite pecha kuchas) è una buona idea. Questo li aiuterà a diventare buoni comunicatori sullo sviluppo oltre al contenuto che stanno imparando.
• Legare esercizi, presentazioni, esempi, al lavoro che stanno facendo "per davvero", laddove possibile.
• Prova ad avere una sorta di check-in o contatto con il gruppo durante le settimane di riposo (le settimane tra gli incontri del workshop) - forse qualcosa per renderli responsabili della continuazione dell'esperienza di apprendimento, se anche solo un blog post o un'aggiunta a un wiki di gruppo.

Questo seminario sembra solido. Sicuramente mi assicuro che ci siano documenti o letture consigliate da portare a casa. Alcuni potrebbero obiettare che i partecipanti non leggeranno i materiali che gli dai, ma io contestano che se è interessante, e c'è valore aggiunto, gli sviluppatori seguiranno. Il libro Head First Design Patterns è fantastico e una lettura super divertente. Magari introdurre degli estratti da lì e consentire agli sviluppatori di vedere il suo valore, quindi suggerire di leggerlo tra una sessione e l'altra. Ha una media di $ 25 (credo) e vale ogni centesimo.

Questo seminario si abbinerà perfettamente all'obiettivo. Ci sono alcuni buoni libri disponibili sul mercato come l'approccio TDD di Kent Beck, Refactoring - Migliorare il design del codice esistente - Martin Fowler, Clean Code - Un manuale di Agile Craftman Ship di Robert C. Martin. Dovresti raccomandare al partecipante di leggere il libro in cui questi concetti hanno descritto in dettaglio bocz non possiamo coprire tutto in un singolo workshop.

Sembra perfetto per me, ho avuto esperienze organizzandone una. Consiglierei di fare delle sessioni mattutine seguite da un esempio di design e poi di sviluppare i casi di test per lo stesso progetto nel pomeriggio (qualcosa del genere per essere coerenti con il modello dell'insegnamento). Ho avuto una sessione pratica la mattina e ho ricevuto lamentele da parte dei candidati in passato richiedendo che la sessione pratica venisse gestita il pomeriggio anziché la mattina.

Il feedback ha anche sottolineato che è più tempo da dedicare perché le persone hanno più dubbi che capire qualcosa sulla teoria. Spero che ti aiuti :) Buona fortuna!

Puoi anche provare a dividere il gruppo in sottogruppi, ad esempio 4 gruppi di 4, dare a tutti la stessa attività di programmazione di base, quindi mescolare il codice in un altro gruppo e fare in modo che ogni gruppo aggiunga alcune funzionalità aggiuntive. Mostrerà loro l'importanza di scrivere codice gestibile meglio di qualsiasi lezione prolissa.