Nao Sei So Sei Que Foi Assim

o guia incompleto de quem só sabe que deu certo

Tem gente que entrega trabalho, tem outra que entrega relatório, e tem um terceiro grupo que entrega aquilo que no português brasileiro chamamos de consenso de Emergência. Eu pertenço ao terceiro grupo. Minha vida profissional inteira pode ser resumida num único gesto: mostrar a tela, dar shrug e dizer que não tenho fórmula, só registro de que funcionou. A expressão serve para situações reais. Não é preguiça, é reconhecimento de que o fenômeno aconteceu mas o mecanismo é escuro. Eu já vi desenvolvedor sênior resolver erro de deploy com três retries e um sleep de 47 segundos sem documentar nada. Eu já vi analista de dados refazer uma planilha do zero porque o arquivo original tinha uma fórmula mascarada que puxava dados de uma aba que ninguém mais lembrava. Eu já vi gerente aprovar apresentação porque o visual estava bom e o cliente assentiu. O ponto não é zoar. O ponto é que existe prática válida mesmo quando não existe explicação transparente. O problema é que quando você tenta transformar isso em processo, a coisa desanda. Eu tentei documentar um procedimento de backup de banco Postgres numa empresa de logística em 2023. O script rodava, o log dizia sucesso, mas quando testei restore, faltava uma linha de compressão que eu não tinha anotado porque naquela noite o problema era outro. Gastei quatro horas refazendo e ainda assim deixei passar um constraint de lock_timeout que quebrava rotas de entrega pela manhã. A lição foi simples: anotar sucesso não basta. Tem que anotar condição de falha, horário de execução, versionamento do driver e se o disco estava em uso por outra tarefa.

Minha técnica atual é diferente. Em vez de escrever manual passo a passo, eu mantenho um caderno de campo com três colunas: o que deu certo, o que quase não deu, e o que eu repetiria de cabeça fria. Parece besteira, mas depois de dois anos e meia essa coluna segunda virou meu maior ativo. Eu consigo ver padrões de risco sem precisar reconstruir o passado inteiro. Quando um colega pergunta como eu fiz aquela migração de tabela com 14 milhões de linhas sem lockar a produção, eu respondo: não sei explicar em três linhas, mas o log mostra que rodamos em dois janelas de 15 minutos com idle entre elas e um vacuum parcial antes. Se quiser, passo o arquivo de acompanhamento. Ele não é bonito, mas é real. Outra armadilha comum é achar que expressão informal é sinal de amadorismo. Eu vejo bastante gente tratar tudo que não tem fórmula visível como amadorismo, mas a verdade é que experiência sensível existe em várias áreas. Nutricionista que ajusta dose de suplemento baseado em resposta clínica, técnico de áudio que ajusta equalização de palco sem analisador, cozinheiro que regulua sal por olho. Em TI não seria diferente. Eu já calibrei configuração de timeout em API de pagamentos olhando latência de rede e taxa de erro em janela de 30 segundos. Não tenho curva teórica para apresentar, tenho número na tela e confirmação do operador. Isso vale como evidência, desde que registrado. O risco maior não é não saber explicar. É fingir que sabe. Já vi pessoa criar slide com arquitetura hipotética só para impressionar diretoria, e o sistema queimou em produção duas semanas depois porque a premise era errada. Eu prefiro entregar documento cru com limitações declaradas. A honestidade técnica economiza reunião e prejuízo. Quando eu entrego algo que não tenho certeza absoluta, eu marca o que é observação, o que é hipótese e o que é fato. As pessoas respeitam mais do que imaginam.

Se você quer adotar postura semelhante na sua rotina, o caminho prático é este: pare de tentar transformar intuição em dogma e comece a transformar intuição em registro. Use planilha simples. Anote data, contexto, variável controlada e resultado. Releia semana a semana. Quando vir repetição, aí sim você transforma em procedimento. O inverso também funciona. Quando algo falha e você não consegue reproduzir, anota falha, anota condições e deixa arquivado. Com tempo, seu arquivo vira base de conhecimento que sobrevive a você. Tem limite disso? Tem. Método empírico sem controle nunca substitui validação estruturada em escala crítica. Se seu sistema gera receita direta, risco de segurança ou impacto regulatório, intuição isolada é insuficiente. Nesses casos, o caminho é combinar observação com teste controlado. Você usa registro de campo como hipótese geradora, não como prova final. Eu fiz isso recentemente com um job de processamento de lote que oscilava entre sucesso rápido e timeout aleatório. Anotações sugeriam variação de carga de rede. Teste controlado confirmou, mas revelou também um gargalo em buffer de memória que minhas observações sozinhas não mostrariam. O registro abriu caminho, o experimento fechou a prova. Se quiser começar hoje, não precisa de ferramenta cara. Planilha, bloco de notas ou caderno físico funcionam. O segredo é constância, não formato. Anotações esparsas geram ruído. Anotações diárias geram padrão. Padrão gera confiança. Confiança gera autonomia. Autonomia é o que permite dizer com propriedade, em determinado dia, que o fato ocorreu sem precisar defender teoria que você ainda não domina.

Existe também o lado humano, que as empresas costumam ignorar. Pessoa que admite não saber tende a cometer menos erro crônico do que quem finge domínio. Eu já vi colega recusar aprovação de mudança porque sentia something off, mesmo sem explicação técnica articulada. Mudança foi analisada com calma, encontrou edge case real, e salvou o time de dor de cabeça. O silêncio analítico também é dado. Aprender a escutá-lo, e a registrá-lo, é habilidade profissional tão válida quanto qualquer outra. No fim das contas, nao sei so sei que foi assim não precisa ser frase de escape. Pode ser ponto de partida para registro sério. Basta tratar observação como matéria-prima, não como conclusão. O trabalho é converter matéria-prima em evidência. Evidência é o que sustenta decisão. Decisão sustentável é o que mantém sistema funcionando quando ninguém está olhando.