O Que Significa Pragmático

O que é pragmatismo na prática

Pragmático não é um adjetivo bonito que se usa em reuniões de empresa. É uma forma de decidir quando o resultado importa mais que a teoria. No dia a dia, isso se traduz em uma regra simples: testa, vê o que funciona, e descarta o resto. Point. A palavra vem do grego pragmatikos, que significava "relativo à ação". Quem fala em pragmático costuma ser aquele colega que interrompe a discussão sobre qual framework usar e pergunta qual deles resolve o problema de verdade. Não é inteligência, é economia de esforço.

O que significa pragmático em contextos do cotidiano

Quando alguém diz "seja pragmático", na verdade está dizendo que o modelo perfeito não existe. Na minha experiência com integração de sistemas legados, já vi gente passar duas semanas argumentando entre REST, GraphQL ou antes de perceber que o gargalo era um banco Oracle dos anos 90 que não suporta conexão simultânea acima de 50 usuários. A solução pragmática foi simplesmente adicionar um cache Redis e pronto. Dois dias de trabalho, não duas semanas de debate. O pragmatismo se manifesta em decisões que parecem sujas de fora. Aceitar um workaround temporário sabendo que vai precisar refatorar depois. Escolher a biblioteca menos elegante que Resolve o problema hoje em vez da mais modular que talvez resolva daqui a seis meses. Essa última chamada é a que mais gera conflito em equipes.

Como reconhecer pragmatismo real versus preguiça disfarçada

Essa é a linha tênue que separa pragmatismo de irresponsabilidade. O pragmatista de verdade documenta o débito técnico. Anota o workaround, coloca num issue no tracker, marca para refatorar no próximo sprint. O que chamo de falso pragmático simplesmente esquece e torce para que ninguém perceba. Um indicador prático: pergunte qual é o plano B do colega quando o workaround quebrar. Se ele souber responder, é pragmatismo. Se responder "ai quebra a gente vê", provavelmente é improviso por preguiça. A diferença é mínima no dia a dia mas se revela rapidamente sob pressão.

Quatro situações onde o pragmatismo falha miseravelmente

Primeiro, em projetos de segurança crítica. Aviões, dispositivos médicos, sistemas financeiros de alta frequência — nesses contextos, a teoria existe justamente porque alguém já caiu nessa armadilha antes. Ignorar o modelo estabelecido por ser "mais prático" aqui não é pragmático, é negligência. Segundo, quando o time todo pensa igual. Pragmatismo em grupo homogêneo vira atalho coletivo. Já vi equipe inteira descartar testes automatizados sob o argumento pragmático de que "o cliente não vê código". Vendo o que deu errado depois: três semanas de hotfix em produção, custo estimado de 40 horas-homem desperdiçadas. Terceiro, em produtos com ciclo de vida longo. Um workaround que funciona por seis meses vira dívida impagável em dois anos. A diferença entre projeto pontual e produto sustentável é exatamente essa escala temporal.

Quarto, quando pragmatismo vira sinônimo de falta de padrão. Se cada desenvolvedor decide sozinho o que é pragmático, o código vira um mosaico de decisões isoladas que ninguém consegue manter. Nesse caso, a solução pragmática é estabelecer convenções mínimas e aceitar a rigidez como preço da navegabilidade.

A métrica que eu uso para testar se uma decisão é pragmaticamente sólida

Simplificação excessiva: se a explicação da solução cabe em menos de duas frases para qualquer pessoa do time, provavelmente é viável. Complexidade que exige uma apresentação de 20 slides para ser compreendida raramente é pragmática, independente do quão brilhante soa no papel. Aprendi isso na hard way durante um projeto de migração de dados onde a equipe passou três meses desenhando a arquitetura ideal antes de escrever uma única linha de código. Quando finalmente começamos a extrair dados reais, descobrimos que 80 por cento dos registros tinham formato inconsistente — algo que uma amostra de duas semanas teria revelado. Migramos para um script bagunçado que funcionou. Refatoramos depois, quando o caminho estava claro.

Ferramentas práticas para aplicar o raciocínio pragmático

Não existe toolkit oficial, mas dois artefatos que uso recorrentemente são o decision log e o timebox. O primeiro é um arquivo simples onde registro decisões com data, alternativa rejeitada, e motivo. Quando o problema reaparece seis meses depois, releio e vejo se a lógica ainda se sustenta. O segundo é um limite de tempo rígido para pesquisa e discussão antes de executar. Duas horas para decidir qual biblioteca usar é pragmatismo. Dois dias é procrastinação disfarçada. Um detalhe importante: pragmatismo exige dados, não intuição. Antes de descartar um approach por parecer complexo demais, peça um número. Quanto tempo leva implementar? Quantos bugs históricos esse padrão já resolveu? Qual é o custo de manutenção mensal? Sem esses dados, o que você chama de pragmatismo pode ser apenas viés de conforto. Outro ponto que pouca gente menciona: pragmatismo funciona melhor em equipes pequenas. Com mais de oito pessoas, o custo de alinhamento sobre o que é "prático" cresce exponencialmente. Nesse cenário, convém institutionalizar decisões pragmáticas via guidelines escritas em vez de debater cada caso individualmente.

Uma história específica de workaround que virou dívida

Em 2023, integrei um sistema de pagamento usando uma API de terceiro cuja documentação era incompleta. A documentação oficial falhava ao descrever o comportamento em casos de timeout paralelo — quando dois pedidos chegavam simultaneamente, o serviço retornava status 200 mas processava apenas um. A solução tecnicamente correta seria implementar um lock distribuído, mas o prazo era apertado. O workaround pragmático: adicionei um campo sequence_id gerado pelo cliente e fiz retry com backoff exponencial. Funcionou. Quase. Três meses depois, um pico de tráfego gerou colisão de sequence_ids porque o gerador local não era perfeitamente distribuído. Perdi oito horas investigando. A refatoração levou uma semana. O aprendizado foi duplo. Primeiro, workaround sem data de expiração é bomba-relógio. Segundo, quando o prazo aperta, o pragmatismo exige que eu estime honestamente quanto tempo a dívida vai custar depois, e inclua esse custo no planejamento inicial. Se não cabe no orçamento, a decisão pragmática é recusar o prazo, não esconder o risco.

Alternativas quando pragmatismo não se aplica

Existem contextos onde o pragmatismo é o pior conselho possível. Arquitetura de microserviços em fase inicial de projeto, por exemplo — decidir pragmaticamente qual serviço nasce primeiro frequentemente leva a acoplamento estrutural que fica pior com o tempo. Nesses casos, a abordagem pragmática é menos pragmática que a abordagem teórica com revisões de design agendadas. Também funciona mal em regulamentações. Se a lei exige auditoria de logs, não adianta ser pragmático e dizer que "ninguém vai ler". O risco regulatório supera qualquer economia de implementação. Pragmatismo é ferramenta, não filosofia de vida. O que diferencia quem domina pragmatismo de quem apenas improvisa é a honestidade sobre os limites. Se você conseguearticular quando NÃO deve ser pragmático, provavelmente sabe quando deve. O inverso também é verdadeiro: quem nunca admite situações onde pragmatismo falha tende a superutilizá-lo até o prejuízo aparecer.

Para quem quer aprofundar sem perder tempo, o livro Pragmatic Programmer de Andrew Hunt e David Thomas continua sendo a referência mais próxima de um manual prático. Não é leitura obrigatória, mas cobre exatamente essas nuances entre pragmatismo e atalho de forma concreta. Alternativamente, grupos de discussão como o /r/programming no Reddit frequentemente debatem casos reais que ilustram essas fronteiras. O pragmatismo nunca responde perguntas abstratas sobre o que seria ideal. Ele responde, de forma áspera e às vezes inconveniente, qual é a melhor decisão com os recursos disponíveis agora. Essa distinção parece óbvia até o momento em que você precisa escolher entre o projeto perfeito daqui a seis meses e o sistema que funciona hoje.