Чудовий обід та вивчення тем [закрито]

Ми нещодавно відродили обід у навчанні для відділу програмування в компанії, в якій працюю. Нас усіх запитали, чи є у нас якісь ідеї для сеансу, і чи будемо ми зацікавлені зробити презентацію. У мене було кілька ідей, починаючи від різних тем, таких як:

Як мислити, як користувач при розробці інтерфейсу користувача

або Відмінності в HTML5

Кілька колег я кинув ці ідеї навколо, щоб здатися, що вони їм подобаються. Однак мені хотілося б ще декількох ідей, перш ніж я заглиблююся над створенням презентації.

Які чудові обіди та вивчайте теми?

Деякі загальні:

• Тест-керований розвиток
• Налагодження в [IDE за вибором] (ви також можете вводити такі речі, як віддалена або віртуалізована налагодження)
• Що нового в останній версії (може бути IDE, система бази даних, будь-яка інша)
• Шаблони дизайну
• Фактори безпеки [технології вибору]
• Фактори продуктивності в [технології вибору]
• Продовження та закриття (читайте про цю фантастичну серію Еріка Ліпперта)
• Огляд [вибору нової мови чи технології]

Але пам’ятайте, що вам не потрібно вибирати загальні теми, ви також можете робити теми L&L на власній роботі. Можливо, це ще цінніше, оскільки аудиторія може відчувати те, що ти робиш (а не припускати, що все це відбувається за допомогою магії). Наприклад, ваш хлопець із встановлення може зробити тему про те, як працює інсталяція, ваш керівник з питань якості може створити тему про підготовку тестових середовищ, ваш хлопець може створити тему про процес збирання, і якщо ваш проект має цікаву архітектуру, можливо, не всі знають про це, тоді робіть тему з цього приводу.

Також пам’ятайте, що ваша аудиторія не обов’язково складається лише з програмістів. У вас також можуть бути хлопці з QA та керівники проектів, тому не вважайте, що "Шаблони дизайну" не є дійсною темою, оскільки всі повинні знати схеми дизайну.

Очевидно, що ви не можете занадто детально розглянути деякі з них (наприклад, не займайтеся глибоким аналізом плюсів і мінусів кожної окремої картини).

Ви могли пограти в «Spot the Defect».

Перегляньте свої журнали відслідковування помилок і знайдіть місця, де люди написали код, який був правдоподібним, але жахливо помилявся в якийсь тонкий спосіб. Перепишіть код, щоб замаскувати, звідки він увійшов, але збережіть помилку, поставте її на дошці та майте людей:

• подивіться, чи зможуть вони знайти помилку
• з'ясувати, що таке виправлення
• опишіть, як помилку можна було знайти під час перегляду коду
• запропонувати зміни в мові чи інструменті, які б запобігли помилку
• і так далі.

Ми з Нілом Гафтером зібрали серію з шести проблем «вияви дефект» і подарували їх глядачам на останній конференції розробників Норвегії; це було дуже весело, і я думаю, люди багато чому навчилися.

Інверсія управління та введення залежності - це потужні ідеї, які мають бути набагато ширшими, ніж зараз.

Я ніколи не брав участі в L&L, але, здається, ви в основному працюєте з:

• щось легко засвоюється протягом перерви на обід
• те, що допоможе надихнути на обговорення та інтерактивний зворотній зв'язок

Я думаю, що щось подібне до того, щоб поставити запитання про те, "як ти думаєш, ми робимо X" і, врешті-решт, розкрити поточну реалізацію, було б цікаво та викликало думки для ваших слухачів. Ви можете абстрагувати все програмування з рівняння, щоб навіть не кодери могли бити його.

Можна навіть абстрагувати складну проблему, з якою ваша компанія зіткнулася як загадку чи загадку. Як, якби вам довелося працювати з квадратним кілочком і круглим отвором, і, врешті-решт, просто вишкрібайте квадратний кілочок у кругову форму - змінюючи фондове програмне забезпечення відповідно до потреб вашої компанії.

Я думаю, що будь-який вступ, який заохочує технічне мислення, автоматично відкриває цікаву розмову.

наприклад, оптимізація часу / процесів

Як прискорити роботу офіціанта з пирогом? Він подає шматок пирога і чекає, коли людина закінчить. Він хапає їх тарілку і відводить її на кухню, потім подає наступній людині. Як можна швидше задовольнити своїх голодних клієнтів, якщо вам не байдуже, як набирати страви?

Я думаю, що прості метафори для опису парадигм, які ви використовуєте на роботі, були б чудовою їжею для роздумів під час жування сендвіч.

Я пропоную спритні практики, такі як:

• безперервна інтеграція
• парне програмування
• стояти на засіданнях
• інформаційний радіатор
• планування покеру

Ми в основному використовуємо наш обід та навчання для висвітлення нових технологій, що виходять із стеку програмного забезпечення, який ми використовуємо в даний час.

Тож зараз ми знаходимось у стеці .NET 3.5 / 4, C #, Visual Studio 2010 тощо, тому ми робимо обід та вивчаємо наступні теми:

• ASP.NET MVC 3
• Nu-Get (.NET менеджер пакунків)
• тощо, тощо.

Очевидно, що ваша компанія може бути в іншій групі, але ви можете скористатися тим самим підходом.

Це дуже добре працювало для нас, якщо ми не в курсі технологій, тим більше, що рамки ASP.NET MVC та пов'язане з ними програмне забезпечення швидко зростають.

Я насолоджуюся розмовами, в яких обговорюється історія чогось, з чим я працюю, особливо розмови, які досить глибокі, щоб дати мені додаткове розуміння моїх багатьох "Чому це так?" тип питань.

Наприклад, багато людей не здогадуються, що PHP почався як простий набір скриптів Perl для управління віком (P) ерсональної (H) ome (P).

Якщо ваша компанія використовує багато безкоштовного програмного забезпечення з відкритим кодом, для обговорення є багата історія. Ви здивуєтеся, скільки людей думає, що Лінус Торвальдс написав баш (коли насправді він переніс його лише дуже рано).

Ви можете дослідити та викопати жартівливі, цікаві та часто інформативні анекдоти майже за будь-якою технологією, якщо витратите на це достатньо часу.

Це має додаткову вигоду від включення людей, які можуть інакше не брати участь.

Залежно від аудиторії, ви можете охопити деякі основні та найкращі практики, наприклад:

• ОО
• Робота над МакКоннеллом "Кодекс завершений"
• Написання захищеного коду
• TDD
• Шаблони дизайну