A cerca de Chesterton

Olá 👋 Estás aqui porque alguém te encaminhou para este artigo em resposta a uma ideia tua sobre como o Exercism poderia ser melhorado? Antes de a nossa equipa investir tempo a explorar a tua ideia, espera que leias isto e consideres se a tua ideia já terá sido pensada antes, e que armadilhas poderá conter. Ao acrescentares essas considerações e potenciais armadilhas à tua sugestão, e ao pensares porque é que a tua ideia ainda não terá sido implementada, é provável que tenhas uma resposta mais rápida e mais positiva.

---

Então, o que significa a “Cerca de Chesterton”?

A Cerca de Chesterton é uma ideia inspirada numa citação do livro The Thing, de 1929, do escritor G.K. Chesterton. Tornou-se bastante conhecida por ter sido citada por John F. Kennedy. Esta é a citação original:

Existe, num caso desses, uma certa instituição ou lei; digamos, para simplificar, uma cerca ou um portão erguido em travessia de uma estrada. O tipo mais moderno de reformador aproxima-se alegremente dela e diz: “Não vejo utilidade nisto; vamos deitá-la abaixo.” Ao que o tipo mais inteligente de reformador fará bem em responder: “Se não vês a utilidade dela, eu é que não te deixo deitá-la abaixo. Vai-te embora e pensa. Depois, quando puderes voltar e dizer-me que vês a utilidade dela, talvez te deixe destruí-la.”

A ideia da Cerca de Chesterton é esta: se não compreendes porque é que algo está ali, provavelmente não compreendes porque é que deveria ser removido. Da mesma forma, se não compreendes porque é que algo não está ali, provavelmente não compreendes porque é que foi deixado de fora.

Uma regra simples para guardar é esta: “Não removas uma cerca enquanto não souberes porque é que foi erguida em primeiro lugar.”

E que relevância tem esta ideia para o Exercism?

No Exercism, temos a sorte de ter imensas pessoas a juntar-se à nossa comunidade a toda a hora, e a partilhar os seus pensamentos e ideias. Muitas dessas ideias são novas, inovadoras, empolgantes, e desbloqueiam o nosso pensamento. Por isso, se tens uma ideia ou uma sugestão, és bem-vindo a partilhá-la!

No entanto, é mais frequente as pessoas publicarem ideias que já foram discutidas muitas vezes. Responder a essas ideias, e voltar a abordar ou a justificar as nossas decisões, pode esgotar imenso a nossa equipa. Este artigo pretende ajudar a proteger esse tempo e essa energia.

O Exercism foi pensado, concebido e construído por milhares de pessoas muito talentosas. É um produto muito intencional: as coisas estão lá porque foram concebidas para estar lá, e muitas coisas ficam de fora porque foram concebidas para ficar de fora. Praticamente tudo no Exercism já foi debatido, discutido e reestruturado muitas vezes.

Por isso, antes de publicares a tua ideia, pergunta-te se já a teremos considerado, e porque é que teremos feito as coisas de forma diferente do que estás a sugerir. E lembra-te: quanto mais óbvia a tua ideia parecer, mais provável é que já tenha sido discutida e debatida muitas vezes. Por isso, quando a apresentares, apresenta-a já com as ressalvas e as armadilhas potenciais. Se tiveres o impulso de dizer “porque não apenas ...”, então é quase certamente disso que se trata.

Nunca tenhas medo de publicar, mas pensa bem nas coisas primeiro!

Tens algum exemplo?

Uma frustração comum é que os alunos submetem aos mentores código que não passa nos testes. Uma sugestão igualmente comum é: “Porque não correr automaticamente os testes na CLI antes de alguém submeter o seu código?” Parece uma ótima ideia: a CLI pode simplesmente chamar um comando para correr os testes, e não deixar o aluno submeter se estiverem a falhar.

Então, para começar, o que significa “chamar simplesmente um comando para correr os testes”? Significa escrever um script para cada uma das 52 linguagens do Exercism, capaz de correr os testes e verificar o resultado. Dá algum trabalho, mas é possível.

Mas também significa escrever esse script de forma a que corra em Windows, MacOSX e Linux, em todas as versões e configurações possíveis. Isso dá muito trabalho (para não dizer um trabalho sem fim). “Porque é que tem de ser em todas as configurações?”, podes perguntar. Bem, porque estás a bloquear ativamente alguém de usar o Exercism a menos que consiga correr esse script. Isso também significa que o script nunca pode falhar. Se, por alguma razão, o script não correr, o aluno fica completamente bloqueado. Um bug num desses scripts 52*3*n significa que um aluno deixa de conseguir usar o track naquele sistema operativo. Como é que testas isso? Não testas.

Mas, dizes tu, podias simplesmente acrescentar uma flag --skip-tests. É uma boa sugestão, mas leva-nos de volta ao ponto de partida: as pessoas podem optar por ignorar os testes sempre que quiserem. Só que agora ficamos numa situação em que é um pouco menos provável que se submetam testes que falham, pelo que os mentores têm uma expectativa mais baixa disso. Isso significa que é mais chocante e confuso quando os testes falham mesmo.

“Mas as pessoas não fariam isso de um modo geral”, podes argumentar. É verdade, para algumas linguagens em que correr os testes demora 0,5s. Mas, para as linguagens em que correr os testes demora 20s, ter de esperar 20s extra para submeter é incrivelmente frustrante para os alunos, por isso ignorar os testes finais tornar-se-ia a norma.

Independentemente de onde esta conversa vá parar, é evidente que há aqui muito mais complexidade do que parece à primeira vista. Há desafios técnicos a considerar, problemas de fluxo de trabalho a ponderar, e a constatação de que os tracks diferem tanto entre si que algo que é rápido e fácil para um é penoso para outro.

Por isso, em vez de apresentares a sugestão “porque não correr os testes antes da submissão”, façamos uma pergunta: “Porque é que as pessoas publicam soluções que não passam nos testes?” E aí as coisas tornam-se interessantes. A resposta geral é que estão bloqueados ou confusos. E precisam de ajuda. O que significa que submeter testes que falham é uma heurística muito importante para os mentores de que este aluno precisa de ajuda. Sim, é frustrante porque os mentores não sabem imediatamente se o código está “correto” ou não. No entanto, podem descarregar o código e corrê-lo para verificar (o que a maioria dos mentores faz em soluções não triviais) e depois sabem com 100% de certeza se está correto ou não. E os alunos que estão bloqueados e precisam de ajuda não acabam mais bloqueados, a precisar de ainda mais ajuda, mas sim a chegar a um mentor que consegue ver e sugerir correções mais depressa.

Nota: Na verdade, estamos a resolver isto correndo os testes do lado do servidor: uma tarefa grande e dispendiosa, mas que vale o esforço pela melhoria da experiência dos alunos e, sobretudo, por poupar tempo e energia aos nossos mentores.

Mais alguma coisa?

Três coisas:

1. Este artigo no Second Order Thinking é uma boa leitura. A citação “Não removas uma cerca enquanto não souberes porque é que foi erguida em primeiro lugar” é deste artigo.
2. The Thing, de G.K. Chesterton, está disponível aqui: https://archive.org/details/G.K.ChestertonTheThing.
3. A tua ideia pode realmente ser nova e ótima. Não tenhas medo nem vergonha de a sugerir!