Ottimo pranzo e argomenti di studio [chiuso]

Recentemente abbiamo ripreso il pranzo a scuola per il dipartimento di programmazione della società per cui lavoro. Ci è stato chiesto se avevamo idee per una sessione e se saremmo interessati a fare una presentazione. Ho avuto alcune idee che vanno da vari argomenti come:

Come pensare come un utente durante la progettazione dell'interfaccia utente

o Differenze in HTML5

Alcuni colleghi ho lanciato queste idee per sembrare che mi piacciano. Tuttavia, vorrei avere qualche idea in più prima di approfondire la creazione di una presentazione.

Quali sono alcuni ottimi pranzi e apprendi argomenti?

Alcuni generali:

• Test Driven Development
• Debug in [IDE di scelta] (puoi anche lanciare cose come il debug remoto o virtualizzato)
• Cosa c'è di nuovo nell'ultima versione di (potrebbe essere un IDE, un sistema di database, qualunque cosa)
• Modelli di progettazione
• Fattori di sicurezza in [tecnologia di scelta]
• Fattori di prestazione in [tecnologia di scelta]
• Continuazioni e 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 argomenti L&L sul tuo lavoro. Probabilmente, questo è ancora più prezioso perché il pubblico può avere un'idea di ciò che fai (piuttosto che supporre che tutto avvenga per magia). Ad esempio, il tuo ragazzo dell'installazione potrebbe fare un argomento su come funziona l'installazione, il tuo capo QA potrebbe fare un argomento sulla preparazione degli ambienti di test, il tuo ragazzo della costruzione potrebbe fare un argomento sul processo di costruzione e se il tuo progetto ha un'architettura interessante che forse non tutti ne sono a conoscenza, quindi fai un argomento al riguardo.

Ricorda inoltre che il tuo pubblico non è necessariamente composto solo da programmatori. Potresti avere anche ragazzi addetti al controllo qualità 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 puoi entrare in troppi dettagli su alcuni di questi (ad esempio, non impegnarti in un'analisi approfondita dei pro e dei contro di ogni singolo schema).

Puoi giocare a "Trova il difetto".

Esamina i log di tracciamento dei bug e trova alcuni luoghi in cui le persone hanno scritto codice plausibile ma terribilmente sbagliato in qualche modo sottile. Riscrivi il codice per nascondere la provenienza, ma preserva il bug, mettilo sulla lavagna e chiedi alle persone:

• vedere se riescono a trovare il bug
• capire qual è la correzione
• descrivere come il bug potrebbe essere stato trovato durante la revisione del codice
• proporre modifiche alla lingua o allo strumento che avrebbero impedito il bug
• e così via.

Neal Gafter e io abbiamo messo insieme una serie di sei problemi di "individuazione del difetto" e li abbiamo presentati al pubblico durante l'ultima Norwegian Developers Conference; è stato molto divertente e penso che la gente abbia imparato molto.

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

Non ho mai partecipato a un L&L ma sembra che tu stia sostanzialmente lavorando con:

• qualcosa facilmente digeribile nel corso di una pausa pranzo
• qualcosa che aiuterà a ispirare la discussione e il feedback interattivo

Penso a qualcosa come porre una domanda su "come pensi che facciamo X" e rivelare alla fine l'attuale implementazione sarebbe interessante e stimolante per i tuoi ascoltatori. Puoi sottrarre tutta la programmazione dall'equazione in modo che anche i non programmatori possano avere una botta.

Potresti persino astrarre un problema complicato che la tua azienda ha affrontato come un enigma o un enigma. Come se dovessi lavorare con un piolo quadrato e un foro rotondo e alla fine semplicemente scalpellare il piolo quadrato in una forma circolare, cambiando il software di magazzino in base alle esigenze della tua azienda.

Penso che qualsiasi introduzione che incoraggi il pensiero tecnico apre automaticamente conversazioni interessanti.

ad es . ottimizzazione tempo / processo

Come si accelera il funzionamento del cameriere che serve una torta? Serve un pezzo di torta e aspetta che la persona finisca. Prende il loro piatto e lo porta in cucina, quindi serve la persona successiva. Come puoi soddisfare i tuoi clienti affamati più rapidamente se non ti preoccupi che i piatti si accumulino?

Penso che semplici metafore per descrivere i paradigmi che usi al lavoro sarebbero un ottimo spunto per pensare mentre sgranocchiamo un panino.

Suggerisco pratiche agili come:

• integrazione continua
• programmazione in coppia
• alzarsi in piedi riunioni
• radiatore di informazioni
• pianificare il poker

Utilizziamo principalmente il nostro Lunch and Learns per coprire le nuove tecnologie che stanno uscendo dallo stack di software che attualmente utilizziamo.

Quindi attualmente siamo su uno stack .NET 3.5 / 4, C #, Visual Studio 2010, ecc. Quindi facciamo un pranzo e apprendiamo sui seguenti argomenti:

• ASP.NET MVC 3
• Nu-Get (.NET Package Manager)
• ecc. ecc.

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

Questo ha funzionato davvero bene per noi per quanto riguarda la tecnologia, soprattutto dal momento che il framework ASP.NET MVC e il software associato stanno crescendo rapidamente.

Mi piacciono i discorsi che parlano della storia di qualcosa con cui lavoro, in particolare i discorsi che approfondiscono quanto basta per darmi ulteriori informazioni sui miei molti "Perché è così?" 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'età (P) ersonale (H) ome (P).

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

Puoi cercare e approfondire aneddoti divertenti, interessanti e spesso informativi su quasi tutte le tecnologie se passi abbastanza tempo a farlo.

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

A seconda del pubblico, potresti trattare alcune nozioni di base e le migliori pratiche, come ad esempio:

• OO
• Elaborazione del "Codice completo" di McConnell
• Scrivere codice sicuro
• TDD
• Modelli di progettazione