O que aprendi em quase 60 anos trabalhando com computadores

A tecnologia é o meio, e o problema que ela resolve é o fim. Levei quase seis décadas de computadores para entender que essa frase simples separa as carreiras que constroem alguma coisa das carreiras que colecionam ferramentas. Comecei antes de o mouse existir e antes de alguém usar a palavra "digital" para algo além de um dedo. Naquele tempo, programar exigia paciência monástica e tolerância a erros que levavam dias para se revelar.

A máquina daquela época explicava pouco, mas tinha uma virtude hoje rara: denunciava na hora quem fingia entender. O erro chegava com a delicadeza de um tijolo na testa. Esse regime formou um tipo de profissional que a maioria das empresas de hoje teria dificuldade até para entrevistar. Quem aguentava trabalhar assim desenvolvia uma relação honesta com a incerteza, habilidade que o currículo costuma omitir.

Quem começou a carreira com Ctrl+Z e backup automático talvez acredite que está protegido. Talvez esteja. Também pode estar apenas acumulando sorte, que é o recurso mais mal documentado de qualquer infraestrutura. A sorte tem um defeito grave para quem depende dela: costuma tirar férias justamente na semana do fechamento contábil.

Aprendi cedo que o computador obedece com uma lealdade assustadora. Ele faz exatamente o que mandaram, e isso é o pior que pode acontecer quando a ordem saiu errada. Levei uns cinco anos para essa ideia deixar de soar óbvia e começar a soar profunda. A maioria das pessoas passa a vida culpando o sistema enquanto ele funciona com perfeição, e o defeito mora em quem o alimentou. Essa confusão entre comportamento correto e resultado esperado está na raiz de boa parte dos desastres que acompanhei.

Trabalhei numa época em que o erro tinha consequência física. Uma fita magnética montada no lugar errado apagava semanas de trabalho em poucos minutos. O processamento em lote completava a pedagogia: você submetia o job de manhã e recebia no dia seguinte uma mensagem de erro de três linhas, aparentemente escrita para outra pessoa. Quem viveu isso desenvolveu uma habilidade que hoje aparece pouco no currículo e menos ainda em produção, que é pensar antes de executar.

Com o tempo, os ambientes ficaram amigáveis e o acesso se democratizou. Junto com o conforto chegou uma ilusão: a de que velocidade de execução equivale a velocidade de raciocínio. Essa equivalência sempre foi falsa, e quem confia nela aprende a errar mais depressa. Vi essa ilusão derrubar projetos inteiros, conduzidos por equipes que entregavam rápido e errado com uma regularidade digna de disciplina militar.

Os gerentes desses projetos confundiam movimento com progresso, e as reuniões sobre o que fazer duravam mais que o sistema em produção. Algumas dessas reuniões produziram apresentações belíssimas. O sistema, por sua vez, caía por falta de alguém que soubesse o que estava fazendo, com a pontualidade que faltava ao cronograma. Quem trabalhava de fato raramente era convidado para essas reuniões, o que talvez explique a beleza dos slides.

A experiência ensina que problema técnico prefere testar a avisar. Ele escolhe o pior momento possível e chega trazendo a informação mais incompleta que se pode imaginar. A decisão, claro, precisa sair imediatamente. Quem construiu repertório ao longo dos anos reconhece o padrão e age. Quem pulou essa etapa improvisa, e o improviso funciona com frequência suficiente para criar confiança excessiva, até a vez em que o estrago aparece na hora errada.

Atravessei do mainframe à nuvem, passando por todas as estações intermediárias. Cada ciclo chegou anunciado como a revolução definitiva e trouxe avanços reais, acompanhados de uma camada nova de problemas imprevistos. O padrão se repetiu tantas vezes que virou previsível. A tecnologia adora trocar de roupa e voltar dizendo que nasceu ontem. Quem viveu três ou quatro dessas revoluções aprende a receber a próxima com educação e uma dose saudável de desconfiança.

Levei décadas para admitir que os problemas de fundo quase sempre eram humanos. A tecnologia funcionava, e o atrito vinha da organização e dos incentivos mal calibrados ao redor dela. Aprendi isso na prática, pelo caminho mais caro, e desde então enxergo primeiro a camada humana de qualquer projeto. É ela que decide se o código vai rodar em produção ou apenas na demonstração para a diretoria.

Quando um sistema legado vira enigma, o problema costuma estar na memória institucional, e o código é apenas a vítima. A pessoa que sabia foi embora e o sistema continuou rodando por anos, até o dia em que uma regra de negócio mudou e ele ficou para trás. Chamo isso de arqueologia involuntária: a gente descobre como as coisas foram construídas no exato momento em que precisa mexer nelas.

A automação sempre gerou mais ansiedade do que merecia. Desde que me lembro de trabalhar com computadores, ouço variações da mesma pergunta: isso vai substituir as pessoas? A resposta honesta, depois de quase seis décadas de observação, depende de que pessoa estamos falando. A automação substitui quem repete tarefas sem entender o motivo e amplifica quem conhece o contexto e usa a ferramenta como extensão do raciocínio.

Essa linha sempre existiu, e hoje ela fica visível muito depressa. Quem resolve manualmente o mesmo problema toda semana só está treinando para repetir erro. Um script de dez linhas faria o serviço e ainda deixaria registrado como o serviço é feito, o que já seria mais documentação do que muita empresa produz por ano. Quem percebe isso tarde costuma descobrir o assunto pelo departamento pessoal.

Acompanhei várias ondas de automação. Cada uma criou trabalhos inéditos e eliminou outros que pareciam eternos, e o saldo em volume sempre foi positivo. O problema real estava na transição, que exige adaptação deliberada, justamente o tipo de esforço que as organizações adiam até o último minuto. Muita empresa prefere contratar uma ferramenta nova a explicar o próprio trabalho. Ferramenta aceita boleto. Processo exige confissão.

A inteligência artificial atual é a onda mais significativa que vi, e digo isso sabendo que já usei a palavra "significativa" para outras ondas. A diferença desta está no alvo. As anteriores automatizavam o que você fazia, e esta começa a automatizar como você pensa em fazer. Ferramentas que exigiam especialização profunda agora entregam resultado razoável com instrução básica, e o "suficientemente bom" ficou disponível para todo mundo.

Isso cria um problema novo, que é distinguir o suficientemente bom do realmente bom quando o primeiro sai de graça. A resposta que encontrei ao longo da vida tem um nome só: julgamento. Julgamento é a capacidade de olhar para um resultado e saber se ele resolve o problema real ou apenas parece resolver. Delegar pensamento sempre foi um atalho elegante para chegar mal informado, e a IA deixou esse atalho asfaltado e com pedágio barato. Esse critério se constrói com experiência acumulada e erro bem examinado, num ritmo que resiste a qualquer pacote promocional.

A tecnologia que você domina hoje vai ficar obsoleta, sempre e sem exceção. O profissional que se identifica com uma ferramenta específica está assinando um prazo de validade. O que dura é a capacidade de aprender e de abstrair princípios que atravessam contextos. Vi linguagens que eram o futuro virarem legado em menos de uma geração, e plataformas que dominavam o mercado sumirem antes que alguém organizasse o velório.

Quem atravessou todas essas mudanças foi, quase sempre, quem se apegou menos às ferramentas. Essa leveza exige uma humildade que contraria o instinto de especialização. Você investe anos aprendendo algo e, um dia, precisa recomeçar sem drama. Convém recomeçar antes que a mudança fique óbvia, porque quando todo mundo percebe, a vaga já foi preenchida. O mercado de tecnologia talvez seja o único lugar onde a experiência pode ser usada contra você.

Documentação ruim funciona como sabotagem passiva, quase sempre involuntária e sempre eficaz. Um sistema mal documentado vira propriedade de quem o construiu, e quando essa pessoa sai, vira problema de todos. Vi isso acontecer centenas de vezes, sempre em lugares onde a pressão por entrega atropela o cuidado com o processo, o que inclui quase todos os lugares.

A lógica desses ambientes é perversa. Documentar toma tempo agora, e o custo de pular essa etapa só aparece depois, um depois que parece muito distante quando o prazo vence amanhã. Um dia você vira o "depois" de alguém e precisa reconstruir do zero o que deveria estar registrado. O tempo economizado lá atrás volta multiplicado por dez, e quem economizou geralmente já mudou de emprego.

Resisti à gestão por muito tempo, como a maioria das pessoas com formação técnica. Achava que gerenciar era um jeito elegante de parar de fazer o que interessava. Estava parcialmente certo e completamente equivocado ao mesmo tempo. Gerenciar mal é mesmo uma das experiências mais frustrantes que existem, e o meu erro estava em supor que esse era o único caminho.

Depois de muita resistência, entendi que liderar times técnicos pede as mesmas habilidades de um problema complexo: decompor a situação e perceber cedo quando a abordagem está errada, antes que o custo fique alto demais. A diferença está na matéria-prima. Você troca sistemas por pessoas, e pessoas se comportam de forma pouco determinística, para desespero de quem gosta de previsibilidade. Esse é o maior desafio do trabalho e também a parte mais interessante dele.

Segurança sempre ocupou o último lugar na fila das decisões tecnológicas. Em todos os ciclos que acompanhei, o padrão foi o mesmo: antes do incidente, segurança é custo, e depois dele vira prioridade urgente. A distância entre essas duas posições se mede em prejuízo. Vi dados sensíveis expostos por descuidos que custariam centavos para evitar, e sistemas críticos vulneráveis por anos porque parar para corrigir parecia caro.

O argumento favorito nessas horas é que "nunca aconteceu nada", como se ausência de incidente equivalesse a ausência de risco. Esse raciocínio funciona perfeitamente até o dia em que alguém perde tudo. A superfície de ataque muda a cada ciclo, enquanto a disposição humana de subestimá-la permanece intacta desde o primeiro mainframe. Estatística de zero incidentes tem o hábito de mudar numa sexta-feira à tarde.

Qualidade de software sobreviveu a todos os ciclos, como tema e como problema. Metodologias e manifestos aparecem e somem, e construir algo que funcione bem por muito tempo continua difícil. Aprendi que qualidade nasce da cultura, e o processo apenas a organiza. Processo sem cultura vira burocracia. Cultura sem processo vira caos organizado. Quando os dois funcionam juntos, as pessoas se importam com o que entregam e têm condições de entregar bem. Esse ambiente é raro e se reconhece imediatamente. A falta dele também se reconhece, só que com mais barulho.

Tenho uma convicção que soa antiquada e que costumo guardar para mim: profundidade importa. Numa época que celebra quem sabe um pouco de tudo, continuo achando que o domínio profundo de algo específico cria o valor real. Os problemas difíceis pedem alguém que chegou fundo o bastante para enxergar de perto o que os outros ainda veem de longe. O bom generalista é aquele que já mergulhou em profundidades suficientes para conhecer o tamanho da própria ignorância. O Shell é um bom exemplo: parece simples por fora, e quem cava descobre um sistema operacional inteiro conversando em linha de comando.

A velocidade da mudança atual é real, e a ansiedade que ela provoca costuma ser maior que o problema. Cada geração de profissionais de tecnologia achou que vivia as maiores mudanças da história, e provavelmente todas tinham razão, cada uma no seu contexto. Com a experiência, a mudança vira paisagem. A gente aprende a andar nela com menos sobressalto, porque já atravessou coisas parecidas e sobreviveu para contar. A incerteza continua lá, e a relação com ela muda.

Os computadores de hoje explicam muito mais do que os da minha juventude e continuam obedecendo do mesmo jeito. Quem confunde a ferramenta com o propósito passa a carreira impressionado com as versões novas e frustrado com os resultados de sempre. Ferramentas novas chegam todo ano com promessas renovadas, e o problema continua esperando quem tenha paciência para entendê-lo. Conheço muita gente assim. Várias dessas pessoas ocupam cargos bonitos.

PS: Se alguma passagem deste texto trouxe de volta um susto em produção ou uma lição aprendida diante de um terminal, conte nos comentários. Sua história pode poupar alguém de repetir a mesma. Comentário bom também é log, só que com testemunha.