Dicas para ensinar usando o Live Coding

11

Estou envolvido no primeiro ano de programação e curso de algoritmos. Em uma palestra recente, decidi apresentar o material usando a codificação ao vivo , o que essencialmente significava que eu me sentava atrás do teclado e escrevia o código e o avaliava, usando o emacs para facilitar o processo.

Isso foi bem-sucedido e os alunos comentaram o quanto apreciavam o formato mais (inter) ativo. Como essa foi minha primeira tentativa de usar esse formato de ensino, sei que ele não funcionou perfeitamente. Alguns dos problemas estavam relacionados a não ser tão experiente com o emacs como eu deveria ser, e outros a permitir que as perguntas dos alunos me levassem muito longe do meu roteiro. Eu sei que posso fazer melhor.

Quais são algumas diretrizes para ministrar palestras (e outras demonstrações) usando palestras de codificação ao vivo?
Quais são as armadilhas a evitar?

Dave Clarke
fonte
2
Tenho minhas reservas sobre a codificação ao vivo (principalmente em relação à taxa de transferência e à ilusão de entendimento). No entanto, duas sugestões: 1) Você já pensou em usar sistemas de resposta em sala de aula para estruturar perguntas? 2) Não tenho ideia de como isso é prático, mas usar algo como ideone.com pode ser interessante porque os alunos podem acessar seu código após a aula e executá-lo sem precisar instalar nada.
Raphael
@ Rafael: Eu tive a atenção deles muito melhor do que antes, o que certamente é uma vantagem. Suas duas sugestões são muito boas. 1) Atualmente, apenas as pessoas que realmente seguem oferecem algum tipo de feedback. 2) Meu idioma não está na lista. Dito isto, todo o código está disponível nos slides (que eu ignorei).
Dave Clarke

Respostas:

8

Aqui estão algumas dicas e armadilhas que coletei depois de usar a codificação ao vivo por uma semana e depois de conversar com um colega.

DOs

  • Prepare um script para seguir e tente cumpri-lo.
  • Limpe os buffers frequentemente para focar na parte relevante.
  • Inicie novamente para cada novo tópico.
  • Use uma fonte maior.
  • Domine a ferramenta que você está usando, para evitar perder muito tempo com trivialidades.
  • Tem funções em segundo plano pré-codificadas. Se não for particularmente relevante, verifique se eles podem ser importados, em vez de aparecer no arquivo de trabalho.
  • Idealmente, trabalhe em um idioma que forneça feedback imediato. Os idiomas com um shell interativo são os melhores nesse aspecto.
  • Ao usar um digitado, forneça o tipo esperado da função que você está escrevendo. Isso fornece uma luz orientadora para os alunos.
  • Cometer erros livremente (embora não muitos). Passo a passo como eles devem ser corrigidos.
  • Não se esqueça - uma imagem pinta mais que mil palavras: intercale slides e o quadro branco / preto trabalha com sua sessão de codificação.
  • Tenha slides de resumo dos pontos abordados
  • Às vezes, ao modificar o código, talvez faça uma cópia e modifique a cópia. Isso fornece um ponto de comparação.
  • Limpe o código periodicamente.
  • Aceite que você cometerá erros e permita abertamente que os alunos o corrijam - isso facilita seu trabalho e os capacita.
  • Escreva código em seu próprio estilo. Por exemplo, você pode ter copiado o código de outro lugar. Mas isso será difícil de reproduzir. Melhor escrever no seu próprio estilo. Por exemplo, eu sempre escrevo funções com caril, porque eu programo principalmente Haskell. Mas o ML padrão usa o idioma com menos frequência. Esperar funções ao curry é o erro mais comum que cometi na aula.
  • Fisicamente, verifique se o seu espaço está bem configurado. Bom teclado, na altura certa, cabos todos nos lugares certos, obstáculos físicos fora do caminho, etc. Reserve um minuto antes de começar a colocar seu espaço trabalhando para você, não contra você.
  • Uma abordagem é escrever o que os alunos dizem, mesmo que esteja errado. Isso leva os alunos a fazer a codificação e a correção. É uma boa ideia limpar o código no final. Essa abordagem pode criar um modelo de atenção e interação em sala de aula, porque os alunos precisam prestar atenção para acompanhar o que está acontecendo.

Não é

  • Não otimize seu código rapidamente e quebre-o de maneira que não possa corrigi-lo.
  • Evite falar com o computador. Converse com os alunos!
  • Evite muita digitação, especialmente do código padrão. Utilize seu ambiente para ajudá-lo a cuspir os modelos para você.
  • Se você usar um editor de texto, evite rolar constantemente. Isso causará enjoo aos que tentam seguir.
  • Se você usa um editor de texto, antes de fazer alterações radicais no seu código, avise os alunos que você fará isso, para que eles possam rastrear o que está acontecendo.
Dave Clarke
fonte
1
Quantos alunos estão na sua turma? Gosto dos seus DOs em relação à interatividade, mas me pergunto como isso chega a 50, 100, 250 alunos.
Raphael
1
Você publica seu código depois da aula? Imagino um repositório do Github em que os alunos podem navegar pelas diferentes versões que você criou (talvez incluindo uma versão polida e de comentários que nunca apareceu na sala de aula) e observar as diferenças. Eles também poderiam clonar o repositório para usar facilmente algoritmos escritos como sub-rotinas em suas tarefas de casa (se isso for desejável).
Raphael
1
Você prepara testes de unidade para executar seu código? Não tenho certeza se isso é apropriado em todas as aulas (o foco é aprender os princípios de linguagens de programação, desenvolvimento de software ou algoritmos?), Mas pode ensinar algumas práticas recomendadas ao longo do caminho.
Raphael
2
1) 128 pessoas registradas para a turma, apesar de 60 a 80 aparecerem. 2) Já tenho o código nos slides, mas não os uso. Portanto, os alunos têm uma versão do que eu faço, nunca nenhuma das etapas intermediárias. Não tenho muita certeza de quão interessante é ter todas as variações. 3) Não, não, embora eles escrevam especificações informais. O foco está no aprendizado de uma primeira linguagem de programação e de alguns algoritmos / estruturas de dados. Eu concordo, no entanto. Os testes de unidade são algo que consideraremos integrar mais fortemente ao curso. Obrigado pelas perguntas / dicas implícitas.
Dave Clarke