Ideia principal

A experiência técnica se constrói num ciclo curto: você tenta, erra, procura, entende, corrige, e guarda algo da correção. Meia hora num bug limitado, um dia num endpoint que resiste, um problema retomado no dia seguinte — é esse desvio que ensina a reconhecer os sinais fracos de um código e a sentir que uma solução fácil demais esconde um custo.

Não é a dor que forma, é a possibilidade de análise. Enquanto o defeito couber num perímetro que dá para abrir, ler e ligar a uma decisão, ele ensina. Quando ele aparece num sistema que cresceu, cujas camadas se empilharam, cujas decisões são implícitas e cujos testes talvez validem uma compreensão errada da necessidade, ele não se liga mais a nada: ninguém mais sabe por que tudo desaba.

O gesto seguinte é então o remendo. Você não entende melhor, você acrescenta mais uma camada sobre uma arquitetura que nunca habitou.

Por que isso importa

Isso redefine o que é preciso proteger quando se quer que um time aprenda. Não é a presença de erros — eles vão existir — é o tamanho e o prazo de aparição deles, duas grandezas sobre as quais dá para agir pelo recorte, pelos testes e pela frequência de entrada em produção.

Isso também explica por que um time pode acumular anos de incidentes sem ganhar competência: os erros dele chegam sempre tarde demais e grandes demais para ensinar qualquer coisa.

Nuances e limites

Alguns erros tardios formam muito bem, desde que um dispositivo os torne analisáveis depois do fato: um post-mortem sério, uma cronologia reconstituída, um rastro de operação. A possibilidade de análise pode, portanto, ser restabelecida, a um custo que não é mais o do momento.

E um ciclo curto demais tem o próprio defeito: ele ensina o gesto local sem nunca expor aos efeitos de sistema que só aparecem em grande escala.

Questões em aberto

• Qual prazo máximo entre uma decisão técnica e a primeira consequência observável dela ainda mantém o ciclo formador?