Makan Siang Luar Biasa dan Topik Belajar [ditutup]

Kami baru-baru ini menghidupkan kembali makan siang di belajar untuk departemen pemrograman di perusahaan tempat saya bekerja. Kami semua ditanya apakah kami punya ide untuk suatu sesi, dan apakah kami akan tertarik untuk melakukan presentasi. Saya punya beberapa ide mulai dari berbagai topik seperti:

Cara berpikir seperti pengguna saat mendesain UI

atau Perbedaan dalam HTML5

Beberapa rekan kerja saya melemparkan ide-ide ini di sekitar untuk menyukai mereka. Namun, saya ingin beberapa ide lagi sebelum saya menggali terlalu jauh untuk membuat presentasi.

Apa sajakah topik makan siang yang enak dan belajar?

Beberapa yang umum:

• Pengembangan Berbasis Tes
• Debugging di [IDE of choice] (Anda juga bisa melempar hal-hal seperti debugging jarak jauh atau virtual)
• Apa yang baru dalam versi terbaru (bisa berupa IDE, sistem basis data, apa pun)
• Pola desain
• Faktor keamanan dalam [teknologi pilihan]
• Faktor kinerja dalam [teknologi pilihan]
• Lanjutan & penutupan (membaca seri fantastis Eric Lippert tentang ini)
• Tinjauan umum [bahasa baru atau teknologi pilihan]

Tapi ingat Anda tidak harus memilih topik umum, Anda dapat melakukan topik L&L pada pekerjaan Anda sendiri juga. Bisa dibilang, ini bahkan lebih berharga karena audiens bisa merasakan apa yang Anda lakukan (daripada menganggap itu semua terjadi dengan sihir). Misalnya, instal Anda dapat melakukan topik tentang cara instal bekerja, arahan QA Anda dapat melakukan suatu topik tentang mempersiapkan lingkungan pengujian, build build Anda dapat melakukan suatu topik pada proses build, dan jika proyek Anda memiliki arsitektur yang menarik yang mungkin tidak semua orang sadari, lalu lakukan topik tentang itu.

Juga ingat bahwa audiens Anda tidak hanya terdiri dari programmer. Anda mungkin memiliki orang-orang QA dan manajer proyek di sana juga, jadi jangan berasumsi bahwa "Pola desain" bukan topik yang valid karena semua orang harus tahu pola desain.

Jelas Anda tidak bisa terlalu detail tentang beberapa di antaranya (misalnya, jangan terlibat dalam analisis mendalam tentang pro dan kontra dari setiap pola tunggal).

Anda bisa memainkan "Spot the Defect".

Telusuri log pelacakan bug Anda dan temukan beberapa tempat di mana orang menulis kode yang masuk akal tetapi sangat salah dalam cara yang halus. Tulis ulang kode untuk menyamarkan dari mana asalnya tetapi simpan kutu, letakkan di papan tulis, dan minta orang-orang:

• lihat apakah mereka dapat menemukan bug
• mencari tahu apa perbaikannya
• jelaskan bagaimana bug itu dapat ditemukan selama tinjauan kode
• usulkan perubahan pada bahasa atau alat yang akan mencegah bug
• dan seterusnya.

Neal Gafter dan saya mengumpulkan serangkaian enam masalah "tempat cacat" dan menyampaikannya kepada hadirin pada Konferensi Pengembang Norwegia terakhir; itu sangat menyenangkan, dan saya pikir orang belajar banyak.

Inversi Kontrol dan Ketergantungan Injeksi adalah ide-ide kuat yang harus jauh lebih luas dari yang ada sekarang.

Saya tidak pernah berpartisipasi dalam L&L tetapi sepertinya Anda pada dasarnya bekerja dengan:

• sesuatu yang mudah dicerna selama istirahat makan siang
• sesuatu yang akan membantu menginspirasi diskusi dan umpan balik interaktif

Saya pikir sesuatu seperti mengajukan pertanyaan tentang "bagaimana menurut Anda kami melakukan X" dan akhirnya mengungkapkan implementasi saat ini akan menarik dan membangkitkan pikiran bagi pendengar Anda. Anda dapat abstrak semua pemrograman dari persamaan sehingga bahkan non-coders dapat melakukannya.

Anda bahkan bisa mengabstraksi masalah rumit yang dihadapi perusahaan Anda sebagai teka-teki atau teka-teki. Seperti jika Anda harus bekerja dengan pasak persegi dan lubang bundar dan akhirnya hanya dipahat pasak persegi menjadi bentuk melingkar - mengubah perangkat lunak saham sesuai dengan kebutuhan perusahaan Anda.

Saya pikir setiap pengantar yang mendorong pemikiran teknis secara otomatis membuka percakapan yang menarik.

misal Optimasi Waktu / Proses

Bagaimana Anda mempercepat operasi pelayan Anda yang melayani pai? Dia menyajikan sepotong kue dan menunggu orang tersebut selesai. Dia mengambil piring mereka dan membawanya ke dapur, lalu melayani orang berikutnya. Bagaimana Anda bisa memuaskan pelanggan lapar Anda lebih cepat jika Anda tidak peduli dengan hidangan yang menumpuk?

Saya pikir metafora sederhana untuk menggambarkan paradigma yang Anda gunakan di tempat kerja akan menjadi makanan yang bagus untuk dipikirkan saat mengunyah sandwich.

Saya menyarankan praktik lincah seperti:

• integrasi berkelanjutan
• pemrograman pasangan
• berdiri rapat
• radiator informasi
• perencanaan poker

Kami kebanyakan menggunakan Makan Siang dan Pembelajaran kami untuk membahas teknologi baru yang keluar dari tumpukan perangkat lunak yang saat ini kami gunakan.

Jadi saat ini kami berada di tumpukan .NET 3.5 / 4, C #, Visual Studio 2010, dll. Jadi kami melakukan makan siang dan mempelajari topik-topik berikut:

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

Jelas perusahaan Anda mungkin berada di tumpukan yang berbeda, tetapi Anda bisa mengambil pendekatan yang sama.

Ini telah bekerja sangat baik bagi kami sejauh mengikuti teknologi, terutama karena kerangka kerja ASP.NET MVC dan perangkat lunak terkait tumbuh dengan cepat.

Saya menikmati pembicaraan yang membahas sejarah sesuatu yang saya kerjakan, terutama pembicaraan yang mendalam hanya cukup untuk memberi saya wawasan tambahan tentang banyak saya 'Mengapa ini seperti ini?' jenis pertanyaan.

Banyak orang, misalnya tidak tahu bahwa PHP dimulai sebagai sekumpulan skrip Perl sederhana untuk pengelolaan usia (P) ersonal (H) ome (P).

Jika perusahaan Anda menggunakan banyak perangkat lunak bebas / sumber terbuka, ada banyak sejarah untuk dibahas. Anda akan terkejut betapa banyak orang berpikir bahwa Linus Torvalds menulis bash (padahal sebenarnya dia hanya porting sangat awal).

Anda dapat meneliti dan menggali anekdot yang lucu, menarik, dan sering informatif pada hampir semua teknologi jika Anda menghabiskan cukup waktu untuk melakukannya.

Ini memiliki manfaat tambahan termasuk orang yang mungkin tidak berpartisipasi.

Bergantung pada audiens, Anda dapat membahas beberapa dasar dan praktik terbaik, seperti:

• OO
• Bekerja melalui "Kode Lengkap" karya McConnell
• Menulis kode aman
• TDD
• Pola desain