Ótimos almoços e tópicos de aprendizado [fechado]

Recentemente, revivemos o almoço em aprendizados para o departamento de programação da empresa em que trabalho. Todos nos perguntaram se tínhamos alguma idéia para uma sessão e se estaríamos interessados ​​em fazer uma apresentação. Eu tive algumas idéias que variam de vários tópicos, como:

Como pensar como um usuário ao projetar a interface do usuário

ou diferenças no HTML5

Alguns colegas de trabalho, joguei essas idéias para parecer gostar delas. No entanto, gostaria de mais algumas idéias antes de me aprofundar na criação de uma apresentação.

Quais são alguns ótimos almoços e tópicos de aprendizagem?

Alguns gerais:

• Desenvolvimento Orientado a Testes
• Depurando no [IDE de escolha] (você também pode incluir coisas como depuração remota ou virtualizada)
• O que há de novo na versão mais recente do (pode ser um IDE, um sistema de banco de dados, qualquer que seja)
• Padrões de design
• Fatores de segurança em [tecnologia de escolha]
• Fatores de desempenho em [tecnologia de escolha]
• Continuações e fechamentos (lendo a fantástica série de Eric Lippert sobre isso)
• Visão geral de [novo idioma ou tecnologia de escolha]

Mas lembre-se de que você não precisa escolher tópicos gerais; também pode fazer tópicos de L&L em seu próprio trabalho. Indiscutivelmente, isso é ainda mais valioso, porque o público pode ter uma ideia do que você faz (em vez de assumir que tudo acontece por mágica). Por exemplo, seu técnico de instalação pode fazer um tópico sobre como a instalação funciona, seu líder de controle de qualidade pode fazer um tópico sobre a preparação de ambientes de teste, seu técnico de construção pode fazer um tópico no processo de criação e se o seu projeto tiver uma arquitetura interessante que talvez nem todo mundo está ciente, então faça um tópico sobre isso.

Lembre-se também de que seu público-alvo não é necessariamente composto apenas por programadores. Você também pode ter funcionários de controle de qualidade e gerentes de projeto. Portanto, não assuma que "Padrões de design" não seja um tópico válido, pois todos devem conhecer padrões de design.

Obviamente, você não pode entrar em muitos detalhes em alguns deles (por exemplo, não faça uma análise profunda dos prós e contras de cada padrão).

Você pode jogar "Spot the Deect".

Percorra seus registros de rastreamento de bugs e encontre alguns lugares onde as pessoas escreveram um código que era plausível, mas terrivelmente errado, de alguma maneira sutil. Reescreva o código para disfarçar sua origem, mas preserve o bug, coloque-o no quadro branco e peça às pessoas:

• ver se eles conseguem encontrar o bug
• descobrir qual é a correção
• descrever como o bug pode ter sido encontrado durante a revisão de código
• propor alterações ao idioma ou ferramenta que teriam evitado o bug
• e assim por diante.

Neal Gafter e eu reunimos uma série de seis problemas "identificamos o defeito" e os apresentamos ao público na última Conferência Norueguesa de Desenvolvedores; foi muito divertido, e acho que as pessoas aprenderam muito.

Inversão de controle e injeção de dependência são idéias poderosas que precisam ser muito mais difundidas do que atualmente.

Eu nunca participei de um L&L, mas parece que você está basicamente trabalhando com:

• algo facilmente digerido ao longo de uma pausa para o almoço
• algo que ajudará a inspirar discussões e feedback interativo

Eu acho que algo como fazer uma pergunta sobre "como você acha que fazemos o X" e, eventualmente, revelar a implementação atual seria interessante e instigante para seus ouvintes. Você pode abstrair toda a programação da equação, para que até os não-codificadores possam ter problemas.

Você pode até abstrair um problema complicado que sua empresa enfrentou como um enigma ou quebra-cabeça. Como se você tivesse que trabalhar com uma cavilha quadrada e um orifício redondo e, eventualmente, esculpir a cavilha quadrada em uma forma circular - alterando o software de estoque para atender às necessidades da sua empresa.

Acho que qualquer introdução que incentive o pensamento técnico abre automaticamente uma conversa interessante.

por exemplo , otimização de tempo / processo

Como você acelera a operação do garçom que serve torta? Ele serve um pedaço de torta e espera a pessoa terminar. Ele pega o prato e leva para a cozinha, depois serve a próxima pessoa. Como você pode satisfazer seus clientes famintos mais rapidamente se não se importa com a acumulação de pratos?

Eu acho que metáforas simples para descrever paradigmas que você usa no trabalho seriam um ótimo alimento para se pensar enquanto mastigam um sanduíche.

Sugiro práticas ágeis como:

• integração contínua
• programação em par
• reuniões de pé
• radiador de informação
• planejamento de poker

Usamos principalmente o Lunch and Learns para cobrir novas tecnologias que estão saindo da pilha de software que usamos atualmente.

Atualmente, estamos em uma pilha do .NET 3.5 / 4, C #, Visual Studio 2010 etc., para que possamos almoçar e aprender sobre os seguintes tópicos:

• ASP.NET MVC 3
• Nu-Get (Gerenciador de Pacotes .NET)
• etc etc.

Obviamente, sua empresa pode estar em uma pilha diferente, mas você pode adotar a mesma abordagem.

Isso funcionou muito bem para nós no que diz respeito a acompanhar a tecnologia, especialmente desde que a estrutura do ASP.NET MVC e o software associado estão crescendo rapidamente.

Gosto de conversas que discutem a história de algo com o qual trabalho, especialmente conversas que são aprofundadas o suficiente para me dar uma visão adicional dos meus muitos 'Por que é assim que é?' tipo de perguntas.

Muitas pessoas, por exemplo, não têm idéia de que o PHP começou como um conjunto simples de scripts Perl para gerenciamento de uma idade (P) pessoal (H) ome (P).

Se a sua empresa usa muitos softwares de código aberto / gratuito, há um histórico rico a discutir. Você ficaria surpreso com quantas pessoas pensam que Linus Torvalds escreveu bash (quando, na verdade, ele só o portou muito cedo).

Você pode pesquisar e desenterrar anedotas engraçadas, interessantes e muitas vezes informativas sobre praticamente qualquer tecnologia, se você gastar bastante tempo fazendo isso.

Isso tem o benefício adicional de incluir pessoas que de outra forma não poderiam participar.

Dependendo do público, você pode abordar alguns princípios e práticas recomendadas, como:

• OO
• Trabalhe no "Code Complete" de McConnell
• Escrevendo código seguro
• TDD
• Padrões de design