Freud no código: por que buscar aprovação externa sabota sua arquitetura

Há alguns anos, liderei a migração de um sistema legado para a nuvem. O projeto parecia simples no papel, mas no meio do caminho a equipe começou a implodir. As discussões técnicas se alongavam por horas, não por falta de conhecimento, mas porque ninguém queria ser o responsável por uma decisão que pudesse ser criticada depois. Escolhíamos ferramentas não pelo que resolviam, mas por serem "aprovadas" pela comunidade. O resultado foi um roadmap inchado, prazos estourados e uma sensação generalizada de frustração. Foi quando me lembrei de uma frase de Freud: "Aquele que conhece seus próprios desejos e espera pouco da aprovação dos outros manterá a frustração à distância." Na época, ela me pareceu óbvia. Hoje, depois de tantos projetos, entendo que ela descreve com precisão cirúrgica a raiz de muitos problemas em engenharia de software.

Freud não era engenheiro, mas entendia de conflitos internos. No ambiente técnico, a busca por aprovação externa se manifesta de formas sutis e destrutivas: o medo de sugerir uma arquitetura diferente da moda, a ansiedade antes de um code review, a tendência a superdimensionar soluções para parecer "profissional". A citação do psicanalista austríaco, publicada originalmente no contexto de autoestima e rotina diária, encontra um eco poderoso nos corredores de tecnologia. O que poucos percebem é que esse comportamento não é apenas psicológico — ele gera dívida técnica, sobrecarga cognitiva e decisões de infraestrutura que custam caro no longo prazo.

O ciclo vicioso da validação no código

Todo desenvolvedor já passou por isso: você escreve uma solução elegante, mas hesita em abrir o pull request porque teme que o revisor questione a abordagem. Então você adiciona comentários extras, refatora partes desnecessárias, insere padrões de projeto que não se aplicam — tudo para "agradar". O problema é que esse esforço não visa melhorar o software, mas sim garantir a aprovação alheia. Em termos freudianos, você está reprimindo seus próprios desejos técnicos (a solução mais direta) em favor de um ideal externo (o que acham que é correto). O resultado? Frustração, retrabalho e, muitas vezes, uma arquitetura que ninguém entende completamente.

Já vi equipes inteiras adotarem microsserviços porque "todo mundo está fazendo", sem sequer terem um domínio bem definido. A decisão foi tomada para agradar o CTO, que vinha de uma empresa onde microsserviços funcionavam, ou para impressionar em entrevistas futuras. O custo operacional — latência, complexidade de deploy, monitoramento — foi ignorado. Anos depois, o time estava preso a uma infraestrutura frágil, incapaz de evoluir sem grandes refatorações. A busca por aprovação externa, nesse caso, gerou dívida técnica que durou mais tempo do que qualquer emprego daqueles envolvidos.

Autoconhecimento técnico: o que sua equipe realmente deseja?

Freud insistia que conhecer os próprios desejos é o primeiro passo para evitar a frustração. Na engenharia, isso significa entender quais são os reais requisitos do sistema, as restrições do negócio e as competências da equipe. Não adianta desejar uma arquitetura de alto desempenho se o time não tem experiência em otimização de consultas. Nem adianta almejar 99,999% de disponibilidade se a empresa não tem orçamento para infraestrutura redundante. Conhecer os próprios desejos técnicos — e aceitá-los — é um exercício de honestidade que muitos profissionais evitam por medo de parecerem menos capazes.

Em um projeto recente de migração para nuvem, a equipe insistia em usar Kubernetes porque "é o padrão do mercado". Mas a aplicação era monolítica, com pouca variação de carga e uma equipe enxuta. Eu sugeri mantê-la em uma única instância com escalonamento vertical, pelo menos até que houvesse evidência de necessidade de orquestração. A resistência foi grande. Argumentei que o desejo real não era usar Kubernetes, mas sim ter escalabilidade e resiliência — e que isso poderia ser alcançado com soluções mais simples. Depois de alguns meses, a equipe percebeu que a abordagem simplificada reduziu a complexidade operacional e acelerou entregas. A frustração com a ferramenta "chique" foi substituída pela satisfação de uma escolha adequada.

O preço da aprovação: burnout e síndrome do impostor

A busca constante por validação tem um custo humano mensurável. Estudos mostram que a síndrome do impostor afeta entre 58% e 70% dos profissionais de tecnologia, e um dos gatilhos mais comuns é a comparação com colegas e a necessidade de provar competência constantemente. Quando você depende da aprovação dos outros para se sentir seguro tecnicamente, cada review, cada reunião de arquitetura, cada incidente em produção se torna uma ameaça à sua autoestima. Isso leva ao esgotamento — o famoso burnout que assola a indústria.

Já atuei como consultor em uma empresa onde os desenvolvedores passavam horas refinando dashboards e relatórios de status, em vez de escrever código. O motivo? O gerente só elogiava quem apresentava métricas "bonitas". A equipe aprendeu a priorizar a aparência dos relatórios em detrimento da qualidade do software. A frustração era geral: os devs se sentiam inseguros, o produto atrasava e o turnover disparou. Ao aplicar a lógica freudiana, ficou claro que o desejo real não era ter dashboards perfeitos, mas sim reconhecimento. Quando a empresa mudou a cultura para valorizar entregas funcionais em vez de relatórios polidos, a satisfação subiu e a produtividade real aumentou.

Como quebrar o ciclo na prática

Não se trata de abandonar a colaboração ou ignorar feedbacks. A frase de Freud diz "esperar pouco da aprovação dos outros", não "ignorar totalmente". A chave está em equilibrar a validação externa com a confiança interna. Em equipes de tecnologia, isso pode ser feito com práticas objetivas:

• Defina critérios claros de sucesso técnicos, não baseados em opinião, mas em métricas observáveis: latência, taxa de erros, tempo de deploy, cobertura de testes. Quando a decisão é medida, a aprovação pessoal perde peso.
• Adote code reviews com foco em aprendizado, e não em julgamento. Frases como "isso não está certo" devem ser substituídas por "o que você acha dessa alternativa?" ou "qual trade-off você considerou?". O revisor não é um juiz, mas um parceiro.
• Crie rituais de retrospectiva que incentivem a vulnerabilidade, onde os membros possam expressar dúvidas sem medo de represálias. Uma cultura que aceita "não sei" como resposta honesta reduz a necessidade de aprovação artificial.
• Desenvolva um plano de carreira que valorize a autonomia técnica, e não apenas a quantidade de tarefas concluídas. Profissionais que se sentem seguros em suas escolhas tendem a buscar menos validação externa.

Na infraestrutura em nuvem, especificamente, aprendi que o maior erro é escolher um serviço pelo hype, e não pelo problema. Já vi times adotarem bancos NoSQL porque "todo mundo fala bem", quando um relacional simples resolveria. Ou implementarem esteiras de CI/CD complexas demais para um projeto de três pessoas. A decisão técnica correta, muitas vezes, é a menos impressionante em um slide de apresentação, mas a mais robusta no dia a dia. Conhecer seus desejos — e aceitar que uma solução "feia" pode ser a mais eficaz — é um sinal de maturidade que poucos alcançam.

O paradoxo da segurança: quando a aprovação é necessária

Claro, há áreas onde a aprovação externa é indispensável — segurança da informação, por exemplo. Um profissional de segurança não pode "esperar pouco" da aprovação dos auditores ou das normas regulatórias. Mas aí o desejo não é pessoal, é do sistema. Freud falava de desejos individuais reprimidos, não de conformidade técnica. A diferença está no motivo: você segue uma política de segurança porque acredita nela (desejo interno) ou porque tem medo da punição (aprovação externa)? Quando a equipe internaliza a importância da segurança, a frustração diminui, mesmo que os controles sejam rígidos.

Em um cliente do setor financeiro, os desenvolvedores reclamavam constantemente dos processos de compliance. Achavam que a burocracia atrapalhava a inovação. Mas quando expliquei que cada regra existia para proteger os dados dos clientes — e que isso estava alinhado com o desejo deles de fazer um trabalho de qualidade — o discurso mudou. Eles começaram a ver a aprovação dos auditores não como um obstáculo, mas como uma validação de que estavam no caminho certo. O autoconhecimento, aqui, foi entender que o desejo real era segurança, e não liberdade irrestrita.

Uma perspectiva pessoal sobre o futuro do trabalho

Tenho observado que, com o avanço da inteligência artificial e a automação de tarefas repetitivas, a pressão por aprovação está se deslocando. Antes, o medo era de cometer erros sintáticos; agora, é de não saber usar as ferramentas certas ou de ser substituído por um modelo de linguagem. A síndrome do impostor ganhou novas camadas. A frase de Freud se torna ainda mais relevante: quem conhece seus próprios desejos — o que realmente quer aprender, que tipo de problemas quer resolver — e não depende da validação constante de colegas ou do mercado, mantém a frustração à distância. Isso não significa ser arrogante, mas sim ter clareza sobre o que importa para você.

Na minha experiência, os profissionais mais realizados tecnicamente são aqueles que conseguem separar o feedback técnico da aprovação pessoal. Eles ouvem críticas, mas não deixam que elas definam seu valor. Eles escolhem tecnologias com base em evidências, não em modismo. Eles constroem sistemas que funcionam, mesmo que ninguém bata palmas. E, no fim, são eles que mantêm a sanidade em um setor que muda a cada trimestre. Esperar pouco da aprovação dos outros não é um ato de rebeldia, é um ato de inteligência emocional aplicada à engenharia.

No blog CurriculoIA, frequentemente discutimos como o mercado de trabalho está evoluindo e exigindo novas habilidades. Mas a habilidade mais subestimada continua sendo a de se conhecer. Antes de escolher uma stack, antes de aceitar um feedback, antes de se comparar com o colega: pergunte-se o que você realmente deseja. Não o que o mercado diz que você deve desejar. A resposta pode ser desconfortável, mas é o único caminho para manter a frustração à distância — e construir software que realmente importa.