Olá 👋
Chegou aqui porque alguém indicou este post por você ter sugerido uma ideia de como o Exercism poderia melhorar?
Antes de a nossa equipe investir tempo explorando a sua ideia, ela espera que você leia isto e reflita se a sua ideia já pode ter sido pensada antes e quais armadilhas ela pode conter.
Ao acrescentar essas considerações e as possíveis armadilhas à sua sugestão, e ao refletir por que a sua ideia pode não ter sido implementada ainda, você provavelmente vai receber uma resposta mais rápida e mais positiva.
Afinal, 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.
Ela ficou muito conhecida depois que John F. Kennedy a citou.
Esta é a citação original:
Existe, num caso assim, uma certa instituição ou lei; digamos, para simplificar, uma cerca ou um portão erguido atravessando uma estrada.
O reformador do tipo mais moderno se aproxima dela alegremente e diz: "Não vejo utilidade nisso; vamos tirar isso daqui."
Ao que o reformador do tipo mais inteligente fará bem em responder: "Se você não vê utilidade nisso, eu é que não vou deixar você tirar isso daqui. Vá pensar. Depois, quando você puder voltar e me dizer que vê a utilidade disso, talvez eu permita que você a destrua."
A ideia da Cerca de Chesterton é que, se você não entende por que algo está ali, provavelmente também não entende por que deveria ser removido.
Da mesma forma, se você não entende por que algo não está ali, provavelmente também não entende por que foi deixado de fora.
Uma regra simples de lembrar é: "Não remova uma cerca antes de saber por que ela foi erguida."
Como isso se aplica ao Exercism?
No Exercism, temos a sorte de ter muitas pessoas entrando na nossa comunidade o tempo todo e compartilhando seus pensamentos e ideias.
Muitas dessas ideias são novas, inovadoras, empolgantes e destravam o nosso raciocínio.
Então, se você tem uma ideia ou sugestão, ela é muito bem-vinda!
No entanto, com mais frequência as pessoas postam ideias que já foram discutidas muitas vezes antes.
Responder a essas ideias e revisitar ou justificar de novo as nossas decisões pode consumir demais o tempo e a energia da nossa equipe.
Este artigo quer ajudar a proteger esse tempo e essa energia.
O Exercism foi projetado, arquitetado e construído por milhares de pessoas muito talentosas.
É um produto muito intencional: as coisas estão ali porque foram projetadas para estar ali, e muitas vezes são deixadas de fora porque foram projetadas para ficar de fora.
Quase tudo no Exercism já foi debatido, discutido e reformulado muitas vezes.
Então, antes de postar a sua ideia, pergunte-se se já podemos tê-la considerado e por que talvez tenhamos feito as coisas de um jeito diferente do que você está sugerindo.
E lembre-se: quanto mais óbvia a sua ideia parece, mais provavelmente ela já foi discutida e debatida muitas vezes. Então, quando você apresentá-la, apresente-a já com as possíveis ressalvas e armadilhas.
Se você tiver o instinto de dizer "por que não simplesmente ...", então quase certamente ela entra nessa categoria.
Nunca tenha medo de postar, mas pense bem nas coisas antes!
Você tem um exemplo?
Uma frustração comum é que estudantes enviam código para mentores que não passa nos testes.
Uma sugestão igualmente comum é "Por que não rodar os testes automaticamente na CLI antes de alguém enviar o seu código?"
Parece uma ótima ideia: a CLI só precisa chamar um comando para rodar os testes e não deixar o estudante enviar se eles estiverem quebrados.
Então, primeiro: o que significa "só chamar um comando para rodar os testes"?
Significa escrever um script para cada uma das 52 linguagens do Exercism, capaz de rodar os testes e verificar o resultado.
Dá um pouco de trabalho, mas é factível.
Mas também significa escrever esse script de modo que ele rode no Windows, no MacOSX e no Linux, em todas as versões e configurações possíveis. Isso dá muito trabalho (se é que não é uma quantidade ilimitada de trabalho).
"Por que tem que ser todas as configurações?", você pode perguntar.
Bom, porque você está bloqueando ativamente alguém de usar o Exercism, a menos que essa pessoa consiga rodar o script.
Isso também significa que ele nunca pode falhar.
Se, por algum motivo, o script não roda, o estudante fica totalmente bloqueado.
Um bug em um desses 52*3*n scripts significa que o estudante não consegue mais usar a trilha naquele sistema operacional.
Como você testa isso?
Não tem como.
Mas, você diz, bastaria adicionar uma flag --skip-tests.
É uma boa sugestão, mas ela nos leva de volta ao ponto de partida: as pessoas podem optar por ignorar os testes quando quiserem.
Só que agora ficamos numa situação em que é um pouco menos provável que testes quebrados sejam enviados, então os mentores têm uma expectativa menor disso, o que significa que é mais chocante e confuso quando os testes estão quebrados.
"Mas as pessoas não fariam isso, de modo geral", você pode argumentar. É verdade, em algumas linguagens em que rodar os testes leva 0,5s.
Mas, nas linguagens em que rodar os testes leva 20s, ter que esperar 20s a mais para enviar é incrivelmente frustrante para os estudantes, então pular os testes finais se tornaria algo comum.
Independentemente de onde essa conversa vá parar, está claro que há muito mais complexidade envolvida aqui do que parece à primeira vista. Há desafios técnicos a considerar, problemas de fluxo de trabalho a pensar e a constatação de que as trilhas são diferentes o bastante para que algo rápido e fácil para uma seja penoso para outra.
Então, em vez de apresentar a sugestão "por que não rodar os testes antes do envio", vamos fazer uma pergunta: "Por que as pessoas postam soluções que não passam nos testes?"
E aí as coisas ficam interessantes.
A resposta geral é: porque elas estão travadas ou confusas.
E precisam de ajuda.
O que significa que o envio de testes quebrados é um sinal muito importante para os mentores de que esse estudante precisa de ajuda.
Sim, é frustrante, porque os mentores não sabem de imediato se o código está "correto" ou não. No entanto, eles podem baixar o código e rodá-lo para verificar (o que a maioria dos mentores faz em soluções não triviais) e então saber com 100% de certeza se está correto ou não.
E os estudantes que estão travados e precisam de ajuda não ficam ainda mais travados, precisando de mais ajuda, mas chegam a um mentor que consegue ver e sugerir correções mais rápido.
Observação: na verdade, estamos resolvendo isso rodando os testes no servidor. É um projeto grande e caro, mas que vale o esforço pela experiência melhor do estudante e, principalmente, por poupar tempo e energia dos nossos mentores.
Mais alguma coisa?
Três coisas:
-
Este artigo no Second Order Thinking vale a leitura. A citação "Não remova uma cerca antes de saber por que ela foi erguida" vem desse post.
- O livro The Thing, de G.K. Chesterton, está disponível aqui https://archive.org/details/G.K.ChestertonTheThing.
- A sua ideia pode muito bem ser nova e ótima. Não tenha medo nem vergonha de sugeri-la!
