Gran almuerzo y temas de aprendizaje [cerrado]

13

Hace poco revivimos el almuerzo para el departamento de programación de la empresa en la que trabajo. A todos nos preguntaron si teníamos alguna idea para una sesión y si estaríamos interesados en hacer una presentación. He tenido algunas ideas que van desde varios temas como:

Cómo pensar como un usuario al diseñar IU

o Diferencias en HTML5

A algunos compañeros de trabajo les di la vuelta a estas ideas para que parecieran gustarles. Sin embargo, me gustaría tener más ideas antes de profundizar en la creación de una presentación.

¿Cuáles son algunos temas excelentes para el almuerzo y el aprendizaje?

    
pregunta Kevin Wiskia 10.11.2010 - 22:24

8 respuestas

12

Algunos generales:

  • Desarrollo guiado por pruebas
  • Depuración en [IDE de elección] (también puede incluir cosas como la depuración remota o virtualizada)
  • Novedades en la última versión de (podría ser un IDE, un sistema de base de datos, lo que sea)
  • Patrones de diseño
  • Factores de seguridad en [tecnología de elección]
  • Factores de rendimiento en [tecnología de elección]
  • Continuaciones & cierres (he estado leyendo la fantástica serie de Eric Lippert sobre esto)
  • Descripción general de [nuevo idioma o tecnología de elección]

Pero recuerda que no tienes que elegir temas generales, también puedes hacer temas L & L en tu propio trabajo. Podría decirse que esto es aún más valioso porque la audiencia puede tener una idea de lo que haces (en lugar de suponer que todo sucede por magia). Por ejemplo, su instalador podría hacer un tema sobre cómo funciona la instalación, su líder de control de calidad podría hacer un tema sobre la preparación de entornos de prueba, su compilador podría hacer un tema sobre el proceso de compilación y, si su proyecto tiene una arquitectura interesante, tal vez no todos lo saben, entonces haz un tema sobre eso.

También recuerda que tu audiencia no está necesariamente compuesta solo de programadores. Es posible que también haya empleados de control de calidad y gerentes de proyectos, así que no asuma que los "patrones de diseño" no son un tema válido porque todos deben conocer los patrones de diseño.

Obviamente, no puedes entrar en demasiados detalles sobre algunos de estos (por ejemplo, no realices un análisis profundo de las ventajas y desventajas de cada patrón).

    
respondido por el JohnL 10.11.2010 - 22:55
9

Puedes jugar "Detectar el defecto".

Repase sus registros de seguimiento de errores y encuentre algunos lugares donde las personas escribieron código que fuera plausible pero horriblemente incorrecto de alguna manera sutil. Reescriba el código para disfrazar de dónde viene, pero conserve el error, colóquelo en la pizarra y tenga personas:

  • ver si pueden encontrar el error
  • averiguar cuál es la solución
  • describe cómo se pudo haber encontrado el error durante la revisión del código
  • proponer cambios en el idioma o herramienta que hubieran evitado el error
  • y así sucesivamente.

Neal Gafter y yo organizamos una serie de seis problemas de "detectar el defecto" y los presentamos a la audiencia en la última Conferencia de Desarrolladores de Noruega; fue muy divertido, y creo que la gente aprendió mucho.

    
respondido por el Eric Lippert 13.11.2010 - 01:43
7

La inversión de control y la inyección de dependencia son ideas poderosas que deben estar mucho más extendidas de lo que están actualmente.

    
respondido por el Adam Crossland 10.11.2010 - 22:34
2

Nunca he participado en una L & L, pero parece que básicamente estás trabajando con:

  • algo fácil de digerir en el transcurso de una pausa para el almuerzo
  • algo que ayudará a inspirar el debate y la retroalimentación interactiva

Creo que algo como plantear una pregunta sobre "cómo crees que hacemos X" y revelar la implementación actual sería interesante y estimulante para tus oyentes. Puede abstraer toda la programación de la ecuación, de modo que incluso los que no son codificadores podrían tener un golpe en ella.

Incluso podría abstraer un problema complicado que su compañía enfrentó como un acertijo o un rompecabezas. Como si tuviera que trabajar con una clavija cuadrada y un orificio redondo y, finalmente, simplemente cincelado la clavija cuadrada en una forma circular, cambiando el software estándar para satisfacer las necesidades de su empresa.

Creo que cualquier introducción que fomente el pensamiento técnico abre automáticamente una conversación interesante.

por ejemplo Tiempo / Optimización de procesos

¿Cómo aceleras la operación de tu camarero? Sirve un trozo de pastel y espera a que la persona termine. Agarra su plato y lo lleva a la cocina, luego sirve a la siguiente persona. ¿Cómo puedes satisfacer a tus clientes hambrientos más rápidamente si no te importan los platos que se acumulan?

Creo que las metáforas simples para describir los paradigmas que usas en el trabajo serían una buena idea para pensar mientras comes un sándwich.

    
respondido por el sova 10.11.2010 - 23:47
1

Sugiero prácticas ágiles como:

  • integración continua
  • programación de pares
  • reuniones de pie
  • radiador de información
  • planificación de poker
respondido por el user2567 11.11.2010 - 00:18
1

En su mayoría, utilizamos Lunch and Learns para cubrir las nuevas tecnologías que están surgiendo de la pila de software que utilizamos actualmente.

Por lo tanto, actualmente estamos en una pila de .NET 3.5 / 4, C #, Visual Studio 2010, etc., así que estamos preparando algo para el almuerzo y aprendemos sobre los siguientes temas:

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

Obviamente, su empresa puede estar en una pila diferente, pero podría adoptar el mismo enfoque.

Esto nos ha funcionado muy bien en lo que respecta a mantenernos al día con la tecnología, especialmente desde que el marco MVC de ASP.NET y el software asociado están creciendo a un ritmo rápido.

    
respondido por el mkchandler 11.11.2010 - 01:04
1

Me gustan las charlas que hablan sobre la historia de algo con lo que trabajo, especialmente las que profundizan lo suficiente como para darme una perspectiva adicional de mis muchos '¿Por qué es así?' tipo de preguntas.

Mucha gente, por ejemplo, no tiene idea de que PHP comenzó como un conjunto simple de scripts Perl para el manejo de una (P) ersonal (H) ome (P) edad.

Si su empresa utiliza una gran cantidad de software de código libre / abierto, hay una rica historia para discutir. Usted se sorprendería de cuánta gente piensa que Linus Torvalds escribió bash (cuando en realidad solo lo portó muy temprano).

Puedes investigar y desenterrar anécdotas divertidas, interesantes y, a menudo, informativas sobre casi cualquier tecnología si pasas el tiempo suficiente haciéndolo.

Esto tiene el beneficio adicional de incluir personas que de otra manera no participarían.

    
respondido por el Tim Post 11.11.2010 - 09:20
0

Dependiendo de la audiencia, podría cubrir algunos conceptos básicos y mejores prácticas, tales como:

  • OO
  • Trabajar a través del "Código Completo" de McConnell
  • Escribiendo código de seguridad
  • TDD
  • Patrones de diseño
respondido por el Hugo 14.11.2010 - 03:48

Lea otras preguntas en las etiquetas