Ottimo pranzo e apprendi argomenti [chiuso]

Alcuni generali:

• Test Driven Development
• Debugging in [IDE di scelta] (puoi lanciare anche cose come il debug remoto o virtualizzato)
• Novità nella versione più recente di (potrebbe essere un IDE, un sistema di database, qualunque sia)
• Modelli di design
• Fattori di sicurezza in [tecnologia di scelta]
• Fattori di rendimento in [tecnologia di scelta]
• Continuazioni e amp; chiusure (ho letto la fantastica serie di Eric Lippert su questo)
• Panoramica di [nuova lingua o tecnologia di scelta]

Ma ricorda che non devi scegliere argomenti generali, puoi anche fare degli argomenti L & L sul tuo stesso lavoro. Probabilmente, questo è ancora più prezioso perché il pubblico può avere un'idea di quello che fai (piuttosto che presumere che tutto avvenga per magia). Ad esempio, il tuo install install potrebbe fare un argomento su come funziona l'installazione, la tua guida di QA potrebbe fare un argomento sulla preparazione degli ambienti di test, il tuo build guy potrebbe fare un argomento sul processo di build e se il tuo progetto ha un'architettura interessante che forse non tutti ne sono a conoscenza, quindi fare un argomento su questo.

Ricorda inoltre che il tuo pubblico non è necessariamente composto solo da programmatori. Potresti avere anche ragazzi di QA e project manager, quindi non dare per scontato che "I modelli di progettazione" non siano un argomento valido perché tutti devono conoscere i modelli di progettazione.

Ovviamente non è possibile entrare troppo nel dettaglio di alcuni di questi (ad esempio, non effettuare un'analisi approfondita dei pro e dei contro di ogni singolo pattern).

Potresti riprodurre "Spot the Defect".

Passa attraverso i registri di tracciamento dei bug e trova alcuni posti in cui le persone hanno scritto codice che è stato plausibile ma terribilmente sbagliato in qualche modo sottile. Riscrivi il codice per nascondere da dove proviene, ma conserva il bug, lo metti sulla lavagna e chiedi alla gente:

• controlla se riescono a trovare il bug
• scopri quale sia la correzione
• descrive come è stato possibile trovare il bug durante la revisione del codice
• proporre modifiche alla lingua o allo strumento che avrebbe impedito il bug
• e così via.

Neal Gafter e io abbiamo messo insieme una serie di sei problemi "individuare il difetto" e li abbiamo presentati al pubblico durante l'ultima Norwegian Developers Conference; è stato molto divertente, e penso che le persone abbiano imparato molto.

L'inversione del controllo e dell'iniezione delle dipendenze sono idee potenti che devono essere molto più diffuse di quanto non lo siano attualmente.

Non ho mai partecipato a una L & L, ma sembra che tu stia fondamentalmente lavorando con:

• qualcosa facilmente digeribile nel corso di una pausa pranzo
• qualcosa che ti aiuterà a ispirare discussioni e feedback interattivi

Penso che qualcosa tipo porre una domanda su "come pensi che facciamo X" e alla fine rivelare l'attuale implementazione sarebbe interessante e stimolante per i tuoi ascoltatori. È possibile astrarre tutta la programmazione dall'equazione in modo che anche i non codificatori potrebbero avere un problema.

Potresti anche astrarre un complicato problema che la tua azienda ha affrontato come un enigma o un enigma. Come se dovessi lavorare con un piolo quadrato e un buco rotondo ed eventualmente scolpire il piolo quadrato in una forma circolare, cambiando il software di scorta in base alle esigenze della tua azienda.

Penso che qualsiasi introduzione che incoraggia il pensiero tecnico apre automaticamente un'interessante conversazione.

es. Ottimizzazione del tempo / processo

Come acceleri l'operazione del cameriere che serve la torta? Serve un pezzo di torta e aspetta che la persona finisca. Afferra il loro piatto e lo porta in cucina, poi serve la prossima persona. Come puoi soddisfare i tuoi clienti affamati più rapidamente se non ti interessa accumulare i piatti?

Penso che le semplici metafore per descrivere i paradigmi che usi al lavoro siano un ottimo spunto di riflessione mentre mangi su un sandwich.

Suggerisco pratiche agili come:

• integrazione continua
• coppia programmazione
• alzare le riunioni
• radiatore di informazioni
• pianificazione del poker

Per lo più utilizziamo il nostro Lunch and Learns per coprire le nuove tecnologie che escono dallo stack di software che attualmente utilizziamo.

Quindi attualmente ci troviamo su uno stack .NET 3.5 / 4, C #, Visual Studio 2010, ecc. quindi stiamo facendo un po 'di pausa e apprendiamo sui seguenti argomenti:

• ASP.NET MVC 3
• Nu-Get (Gestore pacchetti .NET)
• ecc., ecc.

Ovviamente la tua azienda potrebbe trovarsi su uno stack diverso, ma potresti adottare lo stesso approccio.

Questo ha funzionato molto bene per noi al passo con la tecnologia, soprattutto perché il framework MVC di ASP.NET e il software associato stanno crescendo a un ritmo rapido.

Mi piacciono i discorsi che discutono la storia di qualcosa con cui lavoro, in particolare discorsi che approfondiscono quel tanto che basta per darmi ulteriori informazioni sui miei molti "Perché è così com'è?" tipo di domande.

Molte persone, ad esempio, non hanno idea che PHP sia iniziato come un semplice insieme di script Perl per la gestione di un'era (P) ersonale (H) ome (P).

Se la tua azienda utilizza molti software gratuiti / open source, c'è una ricca storia da discutere. Sareste sorpresi dal fatto che molte persone pensino che Linus Torvalds abbia scritto bash (quando in realtà lo ha fatto solo molto presto).

Puoi dedicarti a ricerche e ricerche su aneddoti umoristici, interessanti e spesso informativi su quasi tutte le tecnologie se passi abbastanza tempo a farlo.

Questo ha l'ulteriore vantaggio di includere persone che altrimenti potrebbero non partecipare.

A seconda del pubblico, potresti fornire alcune nozioni di base e best practice, ad esempio:

• OO
• Lavora con il "Codice completo" di McConnell
• Scrittura di un codice sicuro
• TDD
• Design Patterns