Taverna /dev/All

Prove que você está errado!

Essa é uma provocação que eu criei há um tempo e, surpreendentemente, anda me ajudando muito no dia-a-dia. Mesmo quando ele não envolve programação diretamente.

Depois de consumir alguns materiais sobre ciência, deu pra entender que o cientista é basicamente uma pessoa que busca sempre provar que está errado.

A razão é simples: infinitas evidências a favor não provam que algo está certo, mas uma evidência contrária prova que algo está errado. Por isso o ideal é buscar uma evidência contrária e, na falta delas, pode-se afirmar que há uma certa probabilidade de estar certo.

Fiquei pensando porque, mesmo com testes, alguns códigos continuam cheios de bugs (meus, inclusive) e percebi que isso vem da incansável busca pelas provas a favor, nunca pelas provas contra. Isso cria um viés por vezes imperceptível.

Então eu comecei a pensar sempre em formas de provar que eu estou errado. O resultado anda bem positivo, já que eu basicamente tento tirar esse viés de achar que está certo e, por consequência, montar um teste que seja voltado a isso.

Eu sei que existem umas técnicas bem interessantes sobre testes que até permutam linhas e tal, mas é engraçado como isso se aplica até em pipelines, por exemplo. Por vezes eu me deparo com pipelines focados em fazer deploy do software e não em prever um deploy falho por natureza. Mesmo a API estando 100% coberta pelos testes, será mesmo que aqueles 15ms de tempo de resposta não seriam o bastante pra falhar o pipeline?

Ah, mas isso já existe, são testes de carga, testes de performance, testes de X…Y…Z… Mas me parece que o ponto comum em todos esses testes é de encontrar aquela evidência contra e provar que tem algo errado no código.

Talvez isso pareça um negativismo tóxico em longo prazo. Mas, se a ciência busca as evidências contrárias, por quê eu não posso buscá-las também? O interessante é que, partindo do pressuposto de que podemos estar errados, ficamos mais humildes e propensos a receber um feedback desfavorável, seja ele do teste ou de alguém do time. Dessa forma, não há negativismo e, sim, uma atitude positiva. Pense um pouco no código que testa uma funcionalidade quando o programador pensa:

a) “Como fazer agora para esse teste passar?”
b) “Como fazer agora pra provar que meu código está errado?”

E, pensando bem, esse é o centro de ideias como o Chaos Monkey. Prove que sua infraestrutura está errada.

Já faz mais de um ano que eu espalho essa ideia do “prove que você está errado” com meus colegas de trabalho e resolvi jogar essa ideia aqui. Não sei se o pessoal acaba achando legal pra não contrariar um maluco ou se realmente faz sentido em algum lugar fora da minha cabeça maluca.

Pra quem estiver interessado em ouvir um pouco sobre essa loucura, eu gravei sobre isso aqui.

Abraços!
Ataxexe

4 Curtidas

Excelente e pertinente provocação!

1 Curtida

Que belos pontos estes!

Acho que é importante este posicionamento pelas seguintes razões.

Insegurança pessoal natural

Vejo isto acontecer demais da conta: as pessoas querem estar certas e se sentem absolutamente sem chão quando não estão. E neste processo escrevem validações que são no mínimo belevolentes: temem validar os casos que podem mostrar erros em suas soluções.

E isto não consegue evitar o inevitável, apenas o atrasa. A realidade muitas vezes (não sempre) sempre está lá.

O que me leva ao segundo ponto.

Solipsismo

Direto vejo pessoas entrarem em um estado absolutamente solipsista no qual a realidade que pregam e mostram é a aquela que está única e exclusivamente em suas mentes. Por isto disse acima que a realidade nem sempre está presente.

Parece estranho o que vou dizer, mas já vi diversas vezes este solipsismo se espalhar para além do ponto original, seja por que quem diz isto está em uma posição de poder, ou mesmo por carisma, não raro mais pelo segundo que pelo primeiro. Um exemplo interessante é a quantidade infindável de coisas que vemos em nossa área que com o tempo somem tais como “microservices como boa prática e não como possível solução arquitetural”, “nosql substituindo relacional” e a lista vai…

Aqui acho que entra também o medo (ou seria insegurança (ou seria vergonha)) de aceitar o fato de que você pode fazer uma proposição em um momento (mesmo que pra si mesmo) e que ela pode estar errada, o que leva você a um estado de auto defesa.

E ei Ataxexe… coloca este podcast lá na lsita do /dev/All pro pessoal acompanhar! Achei muito legal!

2 Curtidas

Ótima leitura! Texto pequeno e super útil, não só para uma nova visão, como para lembrar sempre :smiley:

1 Curtida

itexto