Great Lunch and Learn Topics [fermé]

Nous avons récemment relancé le déjeuner en apprentissage pour le département de programmation de l'entreprise pour laquelle je travaille. On nous a tous demandé si nous avions des idées pour une séance et si nous serions intéressés à faire une présentation. J'ai eu quelques idées allant de divers sujets tels que:

Comment penser comme un utilisateur lors de la conception de l'interface utilisateur

ou différences en HTML5

Quelques collègues j'ai jeté ces idées pour sembler les aimer. Cependant, j'aimerais avoir plus d'idées avant de creuser trop loin dans la création d'une présentation.

Quels sont les grands déjeuners et apprendre des sujets?

Quelques généralités:

• Développement piloté par les tests
• Débogage dans [IDE de votre choix] (vous pouvez également ajouter des éléments comme le débogage distant ou virtualisé)
• Quoi de neuf dans la dernière version de (pourrait être un IDE, un système de base de données, peu importe)
• Modèles de conception
• Facteurs de sécurité dans [la technologie de choix]
• Facteurs de performance dans [la technologie de choix]
• Continuations et fermetures (j'ai lu la fantastique série d'Eric Lippert à ce sujet)
• Aperçu de [nouvelle langue ou technologie de choix]

Mais rappelez-vous que vous n'avez pas à choisir des sujets généraux, vous pouvez également faire des sujets L&L sur votre propre travail. On peut dire que cela est encore plus précieux parce que le public peut avoir une idée de ce que vous faites (plutôt que de supposer que tout se passe par magie). Par exemple, votre installateur pourrait faire un sujet sur le fonctionnement de l'installation, votre responsable QA pourrait faire un sujet sur la préparation des environnements de test, votre gars de la construction pourrait faire un sujet sur le processus de construction, et si votre projet a une architecture intéressante qui peut-être tout le monde n'est pas au courant, alors faites un sujet à ce sujet.

N'oubliez pas non plus que votre public n'est pas nécessairement composé uniquement de programmeurs. Vous pouvez également avoir des gars de QA et des chefs de projet, alors ne supposez pas que les "modèles de conception" ne sont pas un sujet valide car tout le monde doit connaître les modèles de conception.

De toute évidence, vous ne pouvez pas entrer dans trop de détails sur certains d'entre eux (par exemple, ne vous engagez pas dans une analyse approfondie des avantages et des inconvénients de chaque modèle).

Vous pouvez jouer "Spot the Defect".

Parcourez vos journaux de suivi des bogues et trouvez des endroits où les gens ont écrit du code qui était plausible mais horriblement mauvais d'une manière subtile. Réécrivez le code pour masquer d'où il vient mais conservez le bogue, placez-le sur le tableau blanc et demandez aux gens:

• voir s'ils peuvent trouver le bug
• comprendre quel est le correctif
• décrire comment le bogue a pu être trouvé lors de la révision du code
• proposer des changements de langue ou d'outil qui auraient permis d'éviter le bug
• etc.

Neal Gafter et moi avons rassemblé une série de six problèmes de «détection des défauts» et les avons présentés au public lors de la dernière conférence des développeurs norvégiens; c'était très amusant et je pense que les gens ont beaucoup appris.

L'inversion du contrôle et l'injection de dépendances sont des idées puissantes qui doivent être beaucoup plus répandues qu'elles ne le sont actuellement.

Je n'ai jamais participé à un L&L mais il semble que vous travaillez essentiellement avec:

• quelque chose de facile à digérer au cours d'une pause déjeuner
• quelque chose qui aidera à inspirer la discussion et la rétroaction interactive

Je pense que quelque chose comme poser une question sur "comment pensez-vous que nous faisons X" et finalement révéler l'implémentation actuelle serait intéressant et stimulant pour vos auditeurs. Vous pouvez faire abstraction de toute la programmation de l'équation afin que même les non-codeurs puissent y avoir un coup.

Vous pouvez même résumer un problème compliqué auquel votre entreprise a dû faire face comme une énigme ou un casse-tête. Comme si vous deviez travailler avec une cheville carrée et un trou rond et finalement ciseler la cheville carrée en une forme circulaire - en changeant le logiciel de stock en fonction des besoins de votre entreprise.

Je pense que toute introduction qui encourage la réflexion technique ouvre automatiquement une conversation intéressante.

Ex : optimisation temps / processus

Comment accélérez-vous les opérations de votre serveur de tarte? Il sert un morceau de tarte et attend que la personne ait fini. Il attrape leur assiette et l'emmène dans la cuisine, puis sert la personne suivante. Comment pouvez-vous satisfaire vos clients affamés plus rapidement si vous ne vous souciez pas des plats qui s'accumulent?

Je pense que de simples métaphores pour décrire les paradigmes que vous utilisez au travail seraient une excellente source de réflexion tout en grignotant un sandwich.

Je suggère des pratiques agiles telles que:

• Intégration continue
• programmation en binôme
• réunions debout
• radiateur d'information
• planifier le poker

Nous utilisons principalement nos Lunch and Learns pour couvrir les nouvelles technologies qui sortent de la pile logicielle que nous utilisons actuellement.

Donc, actuellement, nous sommes sur une pile .NET 3.5 / 4, C #, Visual Studio 2010, etc., donc nous faisons un déjeuner et apprenons sur les sujets suivants:

• ASP.NET MVC 3
• Nu-Get (Gestionnaire de packages .NET)
• etc.

Évidemment, votre entreprise peut être sur une pile différente, mais vous pouvez adopter la même approche.

Cela a vraiment bien fonctionné pour nous en ce qui concerne la technologie, d'autant plus que le cadre ASP.NET MVC et les logiciels associés se développent à un rythme rapide.

J'apprécie les discussions qui discutent de l'histoire de quelque chose avec laquelle je travaille, en particulier des discussions approfondies juste assez pour me donner un aperçu supplémentaire de mes nombreux "Pourquoi est-ce ainsi?" type de questions.

Beaucoup de gens, par exemple, n'ont aucune idée que PHP a commencé comme un simple ensemble de scripts Perl pour la gestion d'un âge (P) ersonal (H) ome (P).

Si votre entreprise utilise beaucoup de logiciels libres / open source, il y a une histoire riche à discuter. Vous seriez surpris du nombre de personnes qui pensent que Linus Torvalds a écrit bash (alors qu'en fait il ne l'a porté que très tôt).

Vous pouvez rechercher et trouver des anecdotes humoristiques, intéressantes et souvent informatives sur presque toutes les technologies si vous passez suffisamment de temps à le faire.

Cela présente l'avantage supplémentaire d'inclure des personnes qui pourraient autrement ne pas participer.

Selon le public, vous pouvez aborder quelques notions de base et meilleures pratiques, telles que:

• OO
• Travaillez avec le "Code Complete" de McConnell
• Écrire du code sécurisé
• TDD
• Modèles de conception