Ficar Preso É o Objetivo

Aprendi a programar nos anos em que ficar preso era a única opção. Um build que não compilava e uma mensagem de erro que não apontava para lado nenhum. Um conceito que se recusava a encaixar por mais vezes que eu relesse a mesma página. Não que estivesse sozinho com isso. Havia toda uma escada para sair do bloqueio: reler a documentação, mais devagar. Tirar da prateleira o livro gasto. Remexer num projeto mais antigo que tinha resolvido algo adjacente. Perguntar ao colega da secretária ao lado, e se a parede sobrevivesse a tudo isso, escrever o problema com cuidado e publicá-lo num fórum, e depois esperar, às vezes dias, que um desconhecido com as cicatrizes certas respondesse.

Hoje escrevo código todos os dias com dois modelos ao meu lado, e a escada inteira colapsou num único degrau. Colo o erro e a resposta chega antes de eu ter acabado de formar o meu próprio palpite. Isso é aceleração a sério, e aceito a troca a toda a hora. Mas passei mais de uma década a subir a velha escada à mão, e consigo sentir com alguma precisão o que deixa de acontecer nesse momento. Havia algo que corria na minha cabeça entre os degraus, e agora não chega a ter oportunidade de começar. Já apontei para esse algo em ensaios anteriores, sempre de passagem. Merece o olhar completo.

O que faziam as horas de bloqueio

Estar preso nunca foi tempo morto. Era o estado em que a minha imagem da máquina era corrigida mais depressa.

Eis o que acontece dentro de um bug que não faz sentido. Tens na cabeça uma imagem de como o sistema funciona, e o sistema acabou de fazer algo que essa imagem diz ser impossível. Então fazes experiências. Formulas uma hipótese, testas, vês falhar, revês. Cada palpite falhado elimina mais uma forma de a máquina poder funcionar. Quando finalmente encontras a correção, a correção é quase o menos importante. O que fizeste de facto foi encontrar o sítio exato onde a tua imagem estava errada, e redesenhá-la.

Mesmo dentro do melhor bug, boa parte do tempo vai para andar às voltas, reescrever, reconfirmar o óbvio. A aprendizagem vive nos momentos em que um palpite se encontra com a máquina e morre. Mas esses momentos não acontecem se não tiveres ficado na sala durante o resto.

É por isso que ainda me lembro, anos depois, do bug que comeu uma semana, e não consigo recordar uma única funcionalidade que tenha saído sem sobressaltos. A funcionalidade tranquila nunca tocou na minha imagem do sistema. O bug redesenhou-a.

Os conceitos que se recusam a encaixar funcionam da mesma maneira. Andas à volta deles, tentas um enquadramento, vês ruir, tentas outro. Quando a ideia finalmente assenta, assenta numa estrutura que as tuas tentativas falhadas construíram, e é por isso que fica. A leitura, a documentação e a revisão também corrigem uma imagem, e apoio-me nas três. Mas uma correção só se fixa onde uma tentativa lhe abriu lugar. A explicação que recebes antes de teres lutado escorrega. A mesma explicação depois de vinte minutos de palpites falhados assenta, e fica.

A velha escada era lenta, e a lentidão não era toda desperdício. Para perguntar ao colega ou ao fórum, tinhas primeiro de comprimir o problema numa pergunta a que outra pessoa pudesse responder, e a compressão, por si só, resolvia metade deles. Quem alguma vez terminou uma descrição cuidadosa e a apagou sem a publicar, com a resposta de repente na mão, conhece o efeito. O livro também nunca te entregava uma resposta nua; obrigava-te a ler o capítulo à volta dela, e era no capítulo que os três bugs seguintes ficavam evitados. E enquanto esperavas por uma resposta, as tuas próprias experiências continuavam a correr, porque esperar de mãos vazias era insuportável. Havia ajuda em todos os degraus. Simplesmente chegava devagar o suficiente para continuares a pensar entretanto.

A remoção é silenciosa

Agora põe um modelo no loop. O build parte, colas o erro, a solução chega, segues em frente. Medido em output, isto é estritamente melhor, e não vou fingir o contrário. O problema é o aspeto que a troca tem por dentro. Nada no momento a assinala. O diff é idêntico ao que terias escrito ao fim de três horas de luta. O histórico de commits de quem percebe o sistema e de quem subcontratou todas as paredes é exatamente igual, até ao dia em que deixa de o ser.

Porque o código nunca foi o produto dessas três horas. O produto era a imagem corrigida, e o código era o recibo dela. Toma o atalho e continuas a receber o recibo, enquanto a imagem continua errada de uma forma que nenhuma suite de testes vai revelar. Um aprendiz que nunca fica preso não está numa estrada mais rápida para o mesmo destino. Está numa estrada rápida para um destino diferente, fluente a produzir software de que tem uma imagem ténue, e essa fragilidade só se mostra no dia em que a AI ao seu lado está errada e nada nele o sabe.

A versão nostálgica está errada

Muito daquilo em que fiquei preso não me ensinou nada que valesse as horas. A caça ao ponto e vírgula em falta. O build que partiu por um acidente de ambiente que ninguém podia ter previsto. A flag não documentada, o mismatch de versões, a tarde perdida com uma ferramenta que era simplesmente má. Essas paredes ensinaram-me algum folclore de ferramentas, e folclore de ferramentas é precisamente a carga que as máquinas hoje transportam melhor do que eu alguma vez transportei. Dissolver esse tipo de parede num instante é para isso que as ferramentas servem.

As horas de bloqueio que me construíram eram de outro tipo, e distinguir os dois tipos é o ensaio inteiro. Eram as horas em que o obstáculo era a minha própria imagem errada. O sistema seguia as suas próprias regras, a minha ideia dessas regras não, e a luta era o processo de o descobrir. Um tipo era um imposto. O outro eram propinas.

Consegues distingui-los antes de a resposta chegar, não só depois. Pergunta se a parede está dentro do problema ou ao lado dele. Um mismatch de versões está ao lado do problema: resolvê-lo não muda nada na forma como vais escrever o próximo programa. Uma função a devolver um valor que a tua imagem diz ser impossível está dentro: resolvê-la muda aquilo que sabes. Na dúvida, trata a parede como estando dentro durante vinte minutos e vê se a tua compreensão se move.

Escolher onde ficar preso

Portanto a competência mudou de forma. Antes era resistência, porque ficar preso era obrigatório em todo o lado. Agora é opcional em todo o lado, o que o transforma num orçamento, e a competência é alocação.

Gasto o meu deliberadamente. Quando o trabalho de retrieval que faço para os domínios jurídico e da saúde se porta mal de uma forma que me surpreende, vou lá à mão, porque a surpresa significa que a minha imagem do sistema está errada, e esse é o tipo de bloqueio que compensa. Mas a surpresa é um sinal que se ganha. Só dispara onde existe uma imagem detalhada para a realidade contradizer, e é por isso que o teste para principiantes lá atrás pergunta pela parede, não pelo sentimento. Quando um agente em quem deleguei tropeça num sítio que eu podia ter previsto, deixo as ferramentas absorvê-lo, porque já não há nada que esse atrito me possa ensinar. A pipeline de delegação que construí existe precisamente para eu poder entregar as paredes de que já aprendi tudo. As que ainda não, continuo a escalá-las eu mesmo, de propósito, mais devagar do que conseguiria.

Delega sem culpa. O programador que sente uma vergonha vaga de cada vez que o modelo o desbloqueia tem o enquadramento errado, como se a virtude vivesse no próprio atrito. Nunca viveu. O atrito foi sempre apenas o meio para chegar à imagem. Gasta-o onde a tua imagem ainda é ténue.

E gastá-lo não é sentimentalismo, é economia. À medida que gerar código fica barato, o trabalho que mantém o preço é distinguir output certo de errado, e esse discernimento constrói-se a partir de imagens corrigidas. O hábito também se transfere. Cada bug que força uma hipótese contra um sistema a correr é uma repetição do mesmo movimento que mais tarde apanha uma sugestão errada em código que nunca viste. Chega uma afirmação confiante, e algo em ti sabe que a deve testar.

Se estás a aprender agora

Fica preso de propósito, e fica preso em ponto pequeno. Escolhe problemas dimensionados para que estar preso signifique vinte minutos de pensamento a sério, não um fim de semana perdido. O que queres é contacto frequente com a tua própria imagem errada, em pedaços suficientemente pequenos para conseguires resolvê-los.

Tenta primeiro, sempre. Escreve a tua versão partida, forma o teu palpite sobre o bug, e só depois traz a AI, e trá-la como o tutor que revê a tua tentativa, não como o motorista que te leva a passar ao lado do problema. Pergunta-lhe onde falhou o teu raciocínio, não apenas qual é a resposta. Discute com ela. A correção do tutor assenta precisamente porque a tua tentativa construiu o lugar onde ela encaixa. Salta a tentativa e as mesmas frases não ensinam nada.

Depois testa-te. Desliga a AI e reconstrói a coisa, e enquanto reconstróis, diz porque é que cada parte ali está, como se tivesses um colega ao lado a perguntar. A reconstrução, por si só, pode ser fingida com a memória de teclas que viste premir. O porquê não pode. Se ambos sobreviverem, as horas de bloqueio fizeram o seu trabalho e a compreensão é tua. Se não sobreviverem, tens na mão um recibo de uma aprendizagem que nunca aconteceu, e é melhor descobri-lo agora, numa coisa pequena, do que dentro de um sistema com o teu nome.

As máquinas vão oferecer-te uma saída de todas as paredes para o resto da tua carreira, e na maior parte das vezes deves aceitá-la. Muitas paredes são ruído, e limpar ruído é para isso que as ferramentas servem. As paredes certas são onde a tua imagem da máquina se constrói. Aprende a distingui-las, recusa a saída nessas, e deixa a parede fazer o seu trabalho. Ficares preso nas paredes certas é o objetivo.