Bữa trưa tuyệt vời và tìm hiểu chủ đề [đóng cửa]

Gần đây chúng tôi đã hồi sinh bữa ăn trưa để học cho bộ phận lập trình trong công ty tôi làm việc. Tất cả chúng tôi đều được hỏi liệu chúng tôi có ý tưởng nào cho một phiên không, và liệu chúng tôi có hứng thú với việc thuyết trình không. Tôi đã có một vài ý tưởng từ nhiều chủ đề khác nhau, chẳng hạn như:

Cách suy nghĩ như người dùng khi thiết kế UI

hoặc sự khác biệt trong HTML5

Một vài đồng nghiệp tôi đã ném những ý tưởng này xung quanh để có vẻ thích chúng. Tuy nhiên, tôi muốn có thêm một số ý tưởng trước khi tôi đi quá xa vào việc tạo ra một bài thuyết trình.

Một số bữa ăn trưa tuyệt vời và tìm hiểu chủ đề là gì?

Một số cái chung:

• Hướng phát triển thử nghiệm
• Gỡ lỗi trong [IDE lựa chọn] (bạn cũng có thể đưa vào những thứ như gỡ lỗi từ xa hoặc ảo hóa)
• Có gì mới trong phiên bản mới nhất của (có thể là IDE, hệ thống cơ sở dữ liệu, bất cứ thứ gì)
• Mẫu thiết kế
• Yếu tố bảo mật trong [công nghệ lựa chọn]
• Các yếu tố hiệu suất trong [công nghệ lựa chọn]
• Tiếp tục & kết thúc (đã đọc loạt tuyệt vời của Eric Lippert về điều này)
• Tổng quan về [ngôn ngữ mới hoặc công nghệ lựa chọn]

Nhưng hãy nhớ rằng bạn không phải chọn các chủ đề chung, bạn cũng có thể thực hiện các chủ đề L & L trên chính công việc của mình. Có thể cho rằng, điều này thậm chí còn có giá trị hơn bởi vì khán giả có thể cảm nhận được những gì bạn làm (thay vì cho rằng tất cả xảy ra bằng phép thuật). Ví dụ: anh chàng cài đặt của bạn có thể thực hiện một chủ đề về cách cài đặt hoạt động, khách hàng tiềm năng QA của bạn có thể thực hiện một chủ đề về chuẩn bị môi trường thử nghiệm, anh chàng xây dựng của bạn có thể thực hiện một chủ đề về quy trình xây dựng và nếu dự án của bạn có kiến ​​trúc thú vị có thể không phải ai cũng biết, sau đó làm một chủ đề về điều đó.

Cũng nên nhớ rằng khán giả của bạn không nhất thiết chỉ bao gồm các lập trình viên. Bạn cũng có thể có những người QA và người quản lý dự án, vì vậy đừng cho rằng "Mẫu thiết kế" không phải là một chủ đề hợp lệ vì mọi người đều phải biết mẫu thiết kế.

Rõ ràng là bạn không thể đi sâu vào quá nhiều chi tiết về một số trong số này (ví dụ: không tham gia vào một phân tích sâu sắc về ưu và nhược điểm của từng mẫu).

Bạn có thể chơi "Spot the Defect".

Xem qua nhật ký theo dõi lỗi của bạn và tìm một số nơi mọi người viết mã hợp lý nhưng sai lầm khủng khiếp theo một cách tinh tế nào đó. Viết lại mã để ngụy trang nguồn gốc của nó nhưng bảo tồn lỗi, đưa nó lên bảng trắng và có người:

• xem họ có thể tìm thấy lỗi không
• tìm ra cách khắc phục
• mô tả cách tìm lỗi có thể được tìm thấy trong quá trình xem xét mã
• đề xuất thay đổi ngôn ngữ hoặc công cụ có thể ngăn chặn lỗi
• và như thế.

Neal Gafter và tôi tập hợp một loạt sáu vấn đề "phát hiện ra khuyết điểm" và trình bày cho khán giả tại Hội nghị các nhà phát triển Na Uy vừa qua; đó là rất nhiều niềm vui, và tôi nghĩ mọi người đã học được rất nhiều.

Inversion of Control and Dependency Injection là những ý tưởng mạnh mẽ cần được phổ biến rộng rãi hơn nhiều so với hiện tại.

Tôi chưa bao giờ tham gia L & L nhưng có vẻ như bạn đang làm việc với:

• một cái gì đó dễ dàng tiêu hóa trong thời gian nghỉ trưa
• một cái gì đó sẽ giúp truyền cảm hứng thảo luận và phản hồi tương tác

Tôi nghĩ một cái gì đó giống như đặt ra một câu hỏi như "bạn nghĩ chúng tôi làm X như thế nào" và cuối cùng tiết lộ việc thực hiện hiện tại sẽ rất thú vị và kích thích tư duy cho người nghe của bạn. Bạn có thể trừu tượng hóa tất cả các chương trình ra khỏi phương trình để ngay cả những người không phải là lập trình viên cũng có thể có một cú đánh vào nó.

Bạn thậm chí có thể trừu tượng một vấn đề phức tạp mà công ty của bạn phải đối mặt như một câu đố hoặc câu đố. Giống như nếu bạn phải làm việc với một cái chốt vuông và lỗ tròn và cuối cùng chỉ cần đục cái chốt vuông thành một hình tròn - thay đổi phần mềm chứng khoán cho phù hợp với nhu cầu của công ty bạn.

Tôi nghĩ rằng bất kỳ giới thiệu nào khuyến khích tư duy kỹ thuật sẽ tự động mở ra cuộc trò chuyện thú vị.

ví dụ: tối ưu hóa thời gian / quy trình

Làm thế nào để bạn tăng tốc hoạt động phục vụ bánh của bạn? Anh phục vụ một miếng bánh và đợi người ăn xong. Anh lấy đĩa của họ và mang nó vào bếp, sau đó phục vụ người tiếp theo. Làm thế nào bạn có thể làm hài lòng khách hàng đang đói nhanh hơn nếu bạn không quan tâm đến các món ăn chất đống?

Tôi nghĩ những phép ẩn dụ đơn giản để mô tả các mô hình bạn sử dụng tại nơi làm việc sẽ là thức ăn tuyệt vời để suy nghĩ trong khi nhai bánh sandwich.

Tôi đề nghị thực hành nhanh như:

• hội nhập liên tục
• lập trình cặp
• đứng lên họp
• tản nhiệt thông tin
• lập kế hoạch chơi bài

Chúng tôi chủ yếu sử dụng Bữa trưa và Tìm hiểu của chúng tôi để bao quát các công nghệ mới sắp ra khỏi ngăn xếp phần mềm mà chúng tôi hiện đang sử dụng.

Vì vậy, hiện tại chúng tôi đang sử dụng ngăn xếp .NET 3.5 / 4, C #, Visual Studio 2010, v.v. để chúng tôi ăn trưa và học theo các chủ đề sau:

• ASP.NET MVC 3
• Nu-Get (Trình quản lý gói .NET)
• Vân vân.

Rõ ràng công ty của bạn có thể ở trên một chồng khác, nhưng bạn có thể có cùng một cách tiếp cận.

Điều này đã làm việc rất tốt cho chúng tôi khi theo kịp công nghệ, đặc biệt là khi khung ASP.NET MVC và phần mềm liên quan đang phát triển với tốc độ nhanh.

Tôi thích những cuộc nói chuyện thảo luận về lịch sử của một cái gì đó mà tôi làm việc cùng, đặc biệt là những cuộc nói chuyện đi sâu vừa đủ để cho tôi cái nhìn sâu sắc hơn về nhiều người 'Tại sao lại như vậy?' loại câu hỏi.

Ví dụ, nhiều người không biết rằng PHP bắt đầu như một tập lệnh Perl đơn giản để quản lý tuổi (P) ersonal (H) ome (P).

Nếu công ty của bạn sử dụng nhiều phần mềm miễn phí / nguồn mở, có một lịch sử phong phú để thảo luận. Bạn sẽ ngạc nhiên khi nhiều người nghĩ rằng Linus Torvalds đã viết bash (trong khi thực tế anh ta chỉ chuyển nó từ rất sớm).

Bạn có thể nghiên cứu và đào bới những giai thoại hài hước, thú vị và thường có nhiều thông tin về hầu hết mọi công nghệ nếu bạn dành đủ thời gian để làm việc đó.

Điều này có lợi ích bổ sung bao gồm cả những người có thể không tham gia.

Tùy thuộc vào đối tượng, bạn có thể bao gồm một số điều cơ bản và thực tiễn tốt nhất, chẳng hạn như:

• Ôi
• Làm việc thông qua "Hoàn thành mã" của McConnell
• Viết mã bảo mật
• TDD
• Mẫu thiết kế