TRILHOS DE ENSINO

Os cálculos

Durante os quatro meses seguintes, encontrámo-nos de duas em duas semanas e, passo a passo, fomos descobrindo O Fantástico Mundo de Rubi et al. O curso abordou a linguagem Ruby, Ruby on Rails, Javascript e algumas ferramentas populares para RoR aplicações como Devise, Pundit, Sidekiq ou Carriewave.

Cada aluno tinha também um mentor, que era responsável por motivar os alunos e verificar o seu trabalho entre as reuniões.

O plano de ataque

Como professor, vim preparado com 3 anos de experiência com Ruby on CarrisO objetivo é obter uma experiência de 10 anos com programação em geral e algumas apresentações com questões e exercícios para fazer.

Para além de um pequeno curso de gestão de Linux que tinha feito anteriormente, não tinha qualquer experiência de ensino. Quanto aos alunos, só sabia que iam ser dez e que tinham origens muito diferentes - para alguns deles, era a primeira vez que tinham contacto com a programação, enquanto outros tentaram aprender C ou Ruby sozinhos antes de se inscreverem no curso.

Decidi tomar duas resoluções - serei paciente e explicarei tudo se for necessário (nada de "já falámos sobre isso"). A primeira resolução resistiu ao teste do tempo, mas a segunda - obviamente - não. Decidi não fazer nenhuma preparação especial em relação às coisas que ia ensinar - trabalho com Ruby/Rails todos os dias e sinto-me bastante confiante nas minhas capacidades nessa área. No máximo, eu li as apresentações que eu tinha.

O desafio

Uma das primeiras coisas que se tornou absolutamente clara para mim logo após o início do curso - não se pode explicar tudo. É uma perceção muito triste para alguém como eu, que gosta de aprofundar e descobrir como as coisas funcionam, mas no tempo limitado de uma reunião há apenas um limite para o que se pode ensinar e que pode ser lembrado pelos alunos. Acontece que se pode ser um programador Ruby muito decente sem saber exatamente como é que os Arrays são representados na memória ou como é que o Devise funciona exatamente.

As aulas decorriam aos sábados e domingos, das 9 às 17 horas. É importante compreender que ensinar é um trabalho bastante cansativo - para além de explicar a matéria, também é necessário estar sempre pronto para responder a perguntas relacionadas (ou não tão relacionadas) e resolver vários problemas que os alunos têm.

O café é seu amigo, mas o mais importante é a já mencionada paciência. Para as pessoas que nunca programaram antes, conceitos que são óbvios para os programadores - como loops, tipos ou mesmo variáveis - precisam de ser aprendidos e não é um processo instantâneo. Se programas há XX anos, consideras a matemática fácil e consegues enumerar todos os paradigmas de programação conhecidos a meio da noite, pode ser difícil colocares-te na pele de uma pessoa que não sabe bem de que lado do sinal de igual fica o nome da variável. Mas é vital que o faças. Conceitos básicos como variáveis, loops ou arrays tornam-se tão naturais que é difícil compreender como é que alguém não os entende de imediato, mas são mais difíceis do que parecem para "nós programadores".

Uma dificuldade adicional, especialmente no início do curso, foi explicar esses conceitos para que fossem bem compreendidos. Na minha opinião não é possível aprender Rails sem aprender Ruby - embora eu saiba que alguns argumentam que não é o caso. É verdade que Rails tem seus próprios padrões e muitas coisas podem ser lembradas ao invés de aprendidas no começo. No entanto, eu acho que para se tornar um desenvolvedor RoR consciente, é necessário um entendimento moderado de Ruby, OOP ou SQL é uma obrigação. Ensinar as pessoas a programar é bastante diferente de ensinar Rails - enquanto que com Rails há muita coisa que se pode esperar que seja simplesmente aceite ou acreditada (ninguém precisa de saber como funcionam os callbacks no início - apenas o que podem fazer), os conceitos de programação devem ser explicados com mais detalhe.

Envolver a força

Então, como é que se faz isso?

Pacientemente.

Provavelmente, parece que estou sempre a repetir-me, mas nunca é demais salientar a importância da paciência. Mesmo os meus alunos mais motivados são conhecidos por cometerem um erro de sintaxe aqui e ali - faz parte do processo normal de aprendizagem e não há realmente nada a fazer para um professor para além de mostrar qual é o erro e como o corrigir. Com o tempo, eles aprenderão a corrigi-los sozinhos, mas isso requer muito mais do que um ou dois erros.

Outro aspeto a ter em conta é que o Ruby não é tão fácil como parece. Se começou a aprender Ruby com conhecimentos de C/Java/Python, provavelmente tudo parecia tão limpo, agradável e simples. Tente pensar sobre isso, e vai notar:

1. Para que servem os parênteses? Devo usá-los? Não devo?
2. O que é isso? próprio coisa? Por vezes, tenho de o utilizar (por exemplo. attr_writer – self.variable = ...), por vezes não o faço (attr_reader – variável) e às vezes não consigo! (private def some_method – self.some_method irá provocar um erro)
3. Blocos. Aposto que mesmo alguns programadores experientes (de diferentes linguagens) precisariam de um pouco mais do que o esperado para compreender #inject

Para além da simples correção dos erros, há a questão de transferir a sua compreensão das coisas para os seus alunos. Para isso, é necessária muita flexibilidade. Alguns alunos ficaram satisfeitos com o facto de Array ser apenas uma lista ordenada de elementos. Outros precisavam de uma analogia mais visual, como uma prateleira com lugares numerados onde se podem colocar coisas. Dei por mim a explicar as mesmas coisas várias vezes de formas diferentes - o que é um exercício bastante desafiante!

Mas, como eu disse antes, não se pode explicar tudo. Quando eu estava explicando relações em Rails, era mais um "é assim que se faz, e isso permite que você faça isso e aquilo. Se você quer isso, é incrível". Felizmente ninguém me perguntou como isso funciona - eu não acho que desenvolvedores juniores precisam saber sobre reflexões.

Posicionamento situacional

Devido ao formato do nosso curso (reuniões de dois em dois fins-de-semana e longas pausas), tivemos de garantir que os períodos entre esses fins-de-semana são produtivos para os nossos alunos - sem eles praticarem durante esse tempo, o curso não funcionaria de todo.

Alguns dos meus colegas de trabalho aceitaram ser mentores dos alunos do curso. O trabalho dos mentores consistia em verificar os exercícios que eram atribuídos durante as reuniões de fim de semana e ajudar com questões que surgiam durante a sua realização. Os alunos estavam a comunicar com os mentores através do Slack.

Fui mentor de dois dos meus alunos. Era uma forma significativamente diferente de ensinar - e cheia de armadilhas. Uma coisa que percebi um pouco tarde demais é que um bom programador deve ser independente - eles devem pelo menos tentar resolver os problemas sozinhos antes de pedir ajuda. E estar sempre disponível no Slack não só me tomava muito tempo, como também não inspirava essa independência.

Não me interpretem mal - muitas das perguntas que me foram feitas como mentor eram válidas e responder-lhes era aprofundar os conhecimentos dos alunos. No entanto, é muito fácil entrar no "modo professor" e explicar novamente todas as questões das reuniões do fim de semana. Na perspetiva atual, penso que o papel de um tutor consiste em dar uma visão geral, fornecer ligações úteis e fazer algumas perguntas que possam ajudar a encontrar a solução. Ocasionalmente, pode haver explicações, mas não deve ser a maior parte delas.

A utilização da inteligência

Todos os alunos são diferentes. Uma das maiores dificuldades foi ajustar o ritmo do curso de modo a que fosse o mais adequado para todos os alunos. Devido às diferentes origens e ao nível geral de facilidade em aceitar novas ideias entre os alunos, é uma tarefa quase impossível.

O nosso prazo era de 9 reuniões - vezes 2 dias vezes 8 horas dadas nós 144 horas para passar de 0 a Ruby-herói. Era fundamental fazer todo o programa neste tempo - o que por si só obrigava a um ritmo bastante rápido. As primeiras três reuniões foram todas sobre Ruby - depois uma reunião para SQL, depois RoR e uma reunião para JS pelo meio.

Como professor, tive sempre de saber quem compreendia mais ou menos parte do material que estava a apresentar. Por vezes, bastava perguntar se tinham percebido, outras vezes fazia pequenos testes. Por exemplo, pedi a todos os meus alunos que me enviassem as suas próprias definições de conceitos de Ruby, como classe, próprio, método, variável etc., no Slack. Se alguma questão fosse particularmente pouco clara, eu voltava atrás e tentava explicá-la novamente.

Ilusão e Realidade

Resumindo, ensinar foi uma tarefa ainda mais difícil do que eu pensava. Também pode ser muito gratificante. No entanto, é um trabalho árduo e os seus efeitos não dependem apenas do professor - o esforço do próprio aluno é ainda mais importante na sua aprendizagem. Isto faz com que o ensino seja muito diferente da programação, onde normalmente podemos ser donos de todos os sucessos e fracassos. É importante recordar esta diferença.

Também nos obriga a pensar em questões em que normalmente não pensamos - explicar as coisas também nos dá uma melhor compreensão das mesmas. Desta forma, o ensino também pode fazer de si um melhor programador.