Fazer os seus alunos escreverem código sem instalar nada

O quarto de hora perdido no começo de cada aula

Num dia de formação, instalar um ambiente de desenvolvimento raramente custa menos de vinte minutos. E custa sobretudo atenção: enquanto você ajuda três pessoas, as outras esperam, e o grupo se dispersa antes mesmo de ter escrito uma linha.

O problema se repete a cada sessão, e se agrava em três situações muito comuns:

• As máquinas bloqueadas. Num centro de formação ou numa empresa, o aluno não é administrador da própria máquina. Nenhuma instalação é possível sem passar pelo setor de TI.
• O equipamento heterogêneo. Três versões de Windows, dois Mac, um portátil com Linux: o mesmo procedimento nunca funciona em todos.
• As formações curtas. Em meio dia, vinte minutos de instalação representam quase um décimo do tempo total.

Um editor que vive no navegador elimina essa etapa: o aluno abre um link, ou lê um código, e escreve.

O que roda num navegador, e o que não roda

É preciso ser claro sobre o perímetro, porque é aí que nascem as decepções. Um navegador executa muito bem as bases de uma linguagem, e nada do que toca o sistema.

O que funciona cobre o essencial de uma iniciação: exibição, entrada pelo teclado, condições, laços, funções, listas e dicionários, tratamento de erros, e as primeiras noções de orientação a objetos. Na prática, todo o programa dos três ou quatro primeiros dias de uma formação em Python.

O que não funciona se resume ao que sai do ambiente isolado: as interfaces gráficas, a leitura e a escrita de arquivos, as chamadas de rede, e as bibliotecas externas que seria preciso instalar. Um programa que desenha uma janela ou que lê um arquivo CSV precisa de um ambiente instalado.

Esse limite não é um defeito da ferramenta: é o que garante que o programa de um aluno não toque em nada além da sua própria página.

Mostrar, e depois deixar fazer

Uma aula de código bem-sucedida alterna dois tempos, e o segundo chega mais cedo do que se imagina. Enquanto o formador digita sozinho, o grupo desiste: os alunos copiam sem pensar, ou esperam o fim para começar.

A disposição que funciona melhor dá os dois ao mesmo tempo: cada um tem o seu próprio editor e trabalha nele, vendo o seu ao lado, ao vivo. Você escreve um exemplo, ele aparece na tela deles; eles se inspiram, adaptam, erram, recomeçam — sem ter de escolher entre olhar e fazer.

Três hábitos tornam esse dispositivo mais eficaz:

• Escreva o exemplo diante deles, inclusive os seus erros de digitação. Ver um formador corrigir um erro de indentação vale mais do que um código perfeito que aparece de uma vez.
• Deixe que eles ocultem a sua tela quando quiserem se concentrar. O objetivo não é que olhem você, é que escrevam.
• Retome o comando nos momentos-chave. Um botão que coloca todos em modo leitura vale mais do que pedir silêncio três vezes.

O laço infinito, e as outras armadilhas do iniciante

O primeiro while mal escrito sempre chega, muitas vezes no primeiro quarto de hora. Numa máquina comum, ele congela tudo, o aluno entra em pânico, e você perde o fio da aula por três minutos.

Um ambiente pensado para o aprendizado interrompe esses programas sozinho, depois de alguns segundos, com uma mensagem que explica o que aconteceu. Diga isso aos seus alunos desde o início: saber que não podem quebrar nada os deixa claramente mais ousados, e a ousadia é exatamente o que se procura nessa altura.

As outras armadilhas clássicas se tratam mais pela pedagogia do que pela ferramenta:

• A mensagem de erro que não se lê. Reserve um tempo para ler um erro em voz alta, por inteiro, na primeira vez. O reflexo se pega rápido.
• A confusão entre exibir e retornar. Ela merece um exercício só para si, cedo na progressão.
• O copiar e colar sem entender. É o argumento mais forte para dar a cada um o seu próprio editor: copia-se menos facilmente quando é preciso rodar o próprio programa.

Recuperar o trabalho de cada um

Uma aula de código não produz nada durável se o trabalho desaparece ao fechar a aba. E é justamente o que acontece com a maioria dos ambientes de teste online, onde o código vive no navegador e em nenhum outro lugar.

Dois usos já justificam, sozinhos, recuperar os arquivos. Primeiro a correção posterior: reler com calma o que cada um produziu diz mais sobre o aprendizado do grupo do que uma volta pela sala. Depois a continuidade: retomar na semana seguinte onde o aluno parou, em vez de recomeçar tudo.

Na prática, cada participante deve poder baixar o seu arquivo com a extensão certa, e o formador recuperar o conjunto do grupo de uma vez. É um detalhe de uso que muda a relação com o trabalho produzido: o que se leva embora conta.

O que essa abordagem não substitui

Um editor online é uma ferramenta de aula, não um ambiente de trabalho. Seria desonesto deixar acreditar que ele basta para formar um desenvolvedor.

Assim que a formação avança, os seus alunos precisam aprender a instalar um ambiente, a usar um terminal, a gerenciar dependências e um controle de versões. Essas competências fazem parte da profissão, e empurrá-las para longe demais torna a transição brutal.

O bom lugar do editor online fica, portanto, no começo e nos momentos coletivos: as primeiras aulas, as demonstrações, os exercícios curtos, os grupos em máquinas bloqueadas. No resto do tempo, a instalação se torna ela mesma um objeto de aprendizado — mas num momento escolhido, e não imposto numa segunda-feira às 9h15.